Agent Runtime 事件总线：把流式输出、工具调用与子代理状态收进同一控制面

#核心结论

Agent Runtime 的主接口不该再只是“等模型跑完后返回一段文本”。LangGraph 1.2.3 把 RemoteGraph 的 v3 streaming、消息与 tool-call projection、子代理命名等能力推到 release 面；OpenAI Agents SDK 则把 tracing、tool 结果类型、realtime 语音对象、sandbox 失败可重试性和 SSE/MCP 传输稳健性持续前移。对 AI 全栈架构师来说，这说明 Agent 系统已经进入一个更明确的工程阶段：真正需要稳定的是事件总线和控制面，而不是某一轮 prompt 的最终字符串。

#技术背景

早期 Agent 应用常把运行时看成黑盒：输入任务，等待输出答案，中间过程只有零散日志。这个模式在简单问答里尚可接受，但一旦进入工具调用、handoff、多步执行、实时语音或长任务恢复，就会暴露三个问题。

第一，系统无法稳定区分“模型在想”“工具在跑”“子代理已接手”“用户主动取消”和“运行时异常退出”。第二，产品侧只能看到最终回复，看不到中间事件，自然也无法做审批、回放或局部恢复。第三，开发和运维缺少统一上下文，调试时只能同时翻模型日志、业务日志和外部工具日志，成本很高。

LangGraph 近期 release 里的 v3 streaming、messages/tool-call projections、subagent naming，和 OpenAI Agents SDK 官方 tracing 文档、release 里的 tracing export、realtime、sandbox retryability 等信号，实际都在指向同一个演进方向：Agent Runtime 必须被建模成事件驱动系统。

#架构影响

第一，Agent 平台需要一个稳定的内部事件语义。最少要区分用户输入、模型 token、结构化消息、工具请求、工具结果、handoff、子代理生命周期、人工审批、取消、中断和错误恢复。否则一旦接入不同框架或模型提供方，应用层就会被各种临时事件格式污染。

第二，子代理不应再是“隐形函数调用”。LangGraph 在 release 中单独强化了被工具分派的 subagent 命名，这意味着多 Agent 编排正在从“能不能分发任务”转向“分发后能不能识别身份、追踪责任和回放链路”。如果没有稳定的 agent identity，团队很难回答某一步决策到底由谁做出。

第三，Tracing 不再只是 observability 附件，而是运行时控制面的一部分。OpenAI Agents SDK 文档已经把 LLM 生成、tool calls、handoffs、guardrails 和 custom events 明确纳入 tracing 范围。对生产系统来说，这使 trace 可以同时服务调试、风控、人工审核和回归评测。

第四，实时能力会倒逼事件总线设计。Realtime 语音、自定义 voice object、SSE/WebSocket transport、tool-end hook 和 sandbox retryability 都不是“前端特性”，而是运行时事件模型是否稳定的直接体现。系统如果只围绕最终文本建模，就无法优雅处理这些中间态。

#实现路径

1. 先定义统一事件信封。至少包含 run_id、trace_id、agent_id、step_id、event_type、timestamp、sequence、payload 和 recoverable 这些字段，让模型框架、工具网关和前端都围绕同一协议对接。
2. 把工具与子代理都纳入显式状态机。不要只记录“调用成功/失败”，而要记录 planned、started、streaming、waiting_human、completed、cancelled、retryable_error 等状态，这样系统才能做局部恢复与审批分流。
3. 让 tracing 与业务审计共用主键而不是各记各的。运行时 trace 里应能关联模型调用、工具输入输出、handoff、用户确认和最终结果，避免观测链路与审计链路分裂。
4. 为多种传输方式做边界抽象。SSE、WebSocket、浏览器实时语音、CLI streaming 都应映射回统一事件层，而不是让上层业务代码感知每种 transport 的细节。
5. 把失败恢复做成一等能力。对 sandbox、外部工具或子代理返回的可重试错误，系统应区分自动重试、人工接管和彻底失败三类处理，而不是把所有异常都折叠成一次 run fail。

#风险边界

事件越细，系统越容易被噪音淹没。不是所有 token、所有中间变量、所有工具入参都应该长期保存。若没有分层采样和敏感字段治理，事件总线会很快变成新的数据负担和隐私风险源。

另一个边界是，不要把“有 streaming”误解成“有控制面”。真正重要的不是把 token 一段段吐出来，而是系统是否能稳定表达状态迁移、子代理身份、错误可恢复性和人工介入点。没有这些语义，streaming 只是更花哨的输出通道。

还要避免把框架自带 tracing 直接等同于组织级可运营性。官方 SDK 或框架提供的是基础事件采集能力，真正的生产控制面还需要补上策略版本、租户隔离、审批记录、数据脱敏和保留周期。

#验证清单

1. 一次 Agent 运行里，模型输出、工具调用、handoff、子代理状态和错误事件是否共享同一 trace_id 或等价关联键。
2. 子代理是否有稳定身份标识，而不是只在日志里出现一段模糊文本。
3. 前端、API 网关和后台 worker 是否消费同一套事件语义，而不是各自维护一套状态机。
4. 系统是否能区分可重试错误、人工接管错误和终止性错误，并给出不同处理路径。
5. tracing 中是否对敏感输入输出做了显式治理，而不是默认全量持久化。
6. 当某个 tool call 或 handoff 中途失败时，是否能局部恢复或重放，而不必重跑整个任务。

#采用建议

建议先在高价值但可控的内部 Agent 上落地这套模式，例如研发 Copilot、运维排障 Agent 或需要人工审批的流程 Agent。第一阶段只统一事件模型与 trace 主键；第二阶段补上工具/子代理状态机与失败恢复；第三阶段再把实时语音、多传输协议和更复杂的多 Agent 编排纳入同一控制面。底层中间件选型可以参考 消息队列架构选型：短期在线协调不一定需要 Kafka，关键事件需要长期回放时才应该进入 Kafka、Pulsar 或云 Pub/Sub 这类事件流系统。判断这套架构是否有效的标准，不是 demo 是否更丝滑，而是线上故障发生时，团队能否快速回答四个问题：哪一个代理在执行、它调用了什么、为什么失败、下一步能否只恢复局部而不是整轮重跑。