AG-UI 与 A2A 之间：多智能体流式事件如何保持语义一致
发布时间：
真实的多智能体应用通常不只有一条流。前端通过 AG-UI 接收 SSE 事件，Supervisor 维护会话，领域 Agent 通过 A2A 传递任务状态，最下游系统可能又提供自己的 SSE。每一层都有不同的事件模型。
如果只把它们当作字符串流转发，文本看起来正常，任务状态却很容易出错。
先建立统一事件模型
适配层至少要明确正文片段、正文结束、结构化状态快照、工具调用、等待输入、成功与失败终态，以及会话状态增量。不同协议的名称可以不同，但必须存在明确映射表，不能用“是否有文本”推断任务是否完成。
终态事件的顺序
一个常见问题是正文流还未关闭，就发送结构化确认卡。前端可能把卡片挂在仍在生成的消息中，后续文本又覆盖状态。
更稳妥的顺序是：
- 发送最后一个正文片段；
- 关闭当前正文消息；
- 发送状态增量；
- 发送状态卡片或工具调用；
- 最后更新任务状态。
必要时可以把一个下游终态拆成“关闭正文”和“发送结构化状态”两个上游事件。
HITL 不是错误
人机协同的等待状态必须贯穿所有协议层：前端按钮或文本先转换为 AG-UI tool response，再由 Supervisor 传递为 A2A FunctionResponse，最终恢复领域 Agent 和下游任务。
input-required 表示任务仍然存在，不能被适配成 completed。同时要区分按钮确认和纯文本修改；用户说“把标题改短一点”时，不应被自动合成为确认执行。
使用确定性控制点
模型适合语义路由，但显式停止、取消、任务转交和终态判定需要更强的确定性。普通意图可以优先经过 LLM 路由，停止命令保留规则快路径，模型失败时再回退完整规则。领域 Agent 内部的固定转交也可由代码合成，避免模型忘记调用转交工具后直接输出文本。
ID 与可观测性
前端 thread ID、A2A context ID、远端 task ID、领域 session ID 和待恢复工具调用 ID 应分别建模。只有明确规定为一一映射的标识才能复用。
跨协议链路应传播统一 trace context，并观察路由回退率、等待输入停留时间、正文完整率、终态冲突、断流恢复次数与事件转换延迟。流式协议适配的目标不是“让文字显示”，而是让文本、状态、交互和终态在每一层表达同一个业务事实。