Agent 工程对照
← 返回框架对照

多 Agent · 第 7 章

Agent 间通信

多个 Agent 之间怎么传消息、怎么归并结果?

通信形态跟着隔离粒度走:从 Pi 的参数进、事件出,到 openJiuwen 的点对点加发布订阅。

协作有多灵活

  1. 参数进、事件出
  2. Pi
  3. Codex
  4. DeepSeek
  5. openJiuwen
  6. 点对点 + 发布订阅

定性示意:只表示先后,间距没有数值含义。

场景建议

编辑判断

按你的需求,倾向哪种做法

借鉴的是那一家的设计,不等于选用那个框架。

场景

子代理要能中途回报进展

可续跑的子代理有专用的 report 工具,唯一收件人是父代理,默认在父代理最近的安全步边界送达。

场景

消息要能区分「唤醒对方」与「留言」

InterAgentCommunication 带 trigger_turn 开关:为真时收件方开新回合,为假时等下次运行再读。

场景

多种协作模式都要支持

同一条消息总线同时支持点对点与发布订阅,另有层级、接力与子代理即工具三种团队形态。

场景

委派出去就不管了

子代理是独立进程,任务走参数、结果走 JSON 事件流,还支持并行与链式两种编排。

容易踩的坑

  • 让子代理能给父代理发消息之前,先想清楚权限:DeepSeek 的 report 工具不接受收件人参数,收件人由子代理的父会话推出,避免子代理冒充或越级。

四家怎么做

差异与源码

openJiuwen

消息总线支持点对点与发布订阅,监督者的派活走点对点并行

team_runtime 下的 MessageBus 同时支持点对点(send)与发布订阅(publish / subscribe),主题按团队与会话隔离。层级团队里,子代理以 AgentCard 的形式出现在监督者的工具列表中;监督者一次发出的多个工具调用会被分成两组:调用子代理的走总线点对点发送、用信号量限制并发(默认 10),普通工具交给基类照常执行,两组并行后按原顺序归并结果。另有 handoff(接力)与 hierarchical_tools(子代理即工具)两种团队形态并存。

适合
需要多种协作拓扑(层级、接力、广播)并存的团队编排。
代价
点对点与发布订阅都要维护主题隔离与订阅关系,心智负担较重。

此后的变化

  • 2026-W41 →

    新增跨团队的 Team Organization:Leader 消息先落共享数据库再发唤醒事件,按收件团队建 receipt,处理成功后 ack,重新绑定时重投未确认消息。原格的消息总线之上多了一层带确认的可靠投递,当前限同一进程、同一数据库实例。

Codex

消息是协议里的一等条目,带收件人和「是否唤醒对方」开关

Agent 之间传的是 InterAgentCommunication:作者与收件人都是 AgentPath,可以抄送多个收件人,内容可以加密。关键字段是 trigger_turn——为真时收件方把它当作新任务开一个回合,为假时只是一条消息,等收件方下次运行时读到。进入模型上下文时它会被渲染成 AgentMessage,加密内容前面附上消息类型(NEW_TASK 或 MESSAGE)、任务名与发件人。这类条目会写进 rollout,恢复时照常重放(见「中断与恢复」一行);另有 agent_communication.rs 按派生、消息、跟进、结果四种类型记录遥测。

适合
消息需要持久化、可重放,并区分「派新任务」与「普通通知」的场景。
代价
消息是协议条目,扩展字段要改协议并同步所有前端。

此后的变化

  • 2026-W42 →

    原格写 trigger_turn 为假的消息只在收件方下次运行时读到。新增默认关闭的 wake_on_agent_messages:开启后这类消息到达已结束的根会话时会开一个新回合,沿用上一回合的上下文;被打断的会话、Plan 模式和子代理不自动唤醒。

  • 2026-W40 →

    仅排队的 Agent 消息在会话卸载后保留在内存信箱,向已卸载的 Agent 发消息不再触发重新加载;消息顺序跨卸载与重新加载保持,Agent 被移除或所在的树关闭时丢弃。

  • 2026-W39 →

    AgentMessageBoard 接口新增内存后端(临时会话、同树共享)与远程 HTTP 客户端,消息面板的存储位置变为可替换;另加 defer_mailbox_preemption,让 Agent 消息等到下一次请求再送达,而不是在推理或评论边界打断采样。

DeepSeek Harness

通信按方向拆开:父发子用控制工具,子回父用 report,结果带类型化结束原因

父到子与子到父是两个独立的包。tool-subagent-control 给父代理 send_message、interrupt_agent 与 list_agents:消息成为子代理的下一个排队回合,不能改变正在进行的工作;中断只停当前回合,排队的消息保留。tool-subagent-report 给可续跑的子代理一个 report 工具,唯一的收件人是启动它的父代理,默认在父代理最近的安全步边界送达。子代理跑完时返回这里的 SubagentResult:输出取最后一条非空助手消息,结束原因与回合的词汇对齐,另加 refusal;非正常结束时附带不超过 4096 字节、不含工具输入与凭据的诊断信息。

适合
要严格控制谁能给谁发消息、子代理能否回报的系统。
代价
父发子、子回父、中断、列举分属不同工具与包,组合时要逐一安装与配置。

此后的变化

  • 2026-W41 →

    实验性 Agent Team 删除独立 outbox,团队消息直接写入目标 Agent 的普通 inbox,借用现有 agent-message 来源保留真实发送者;不再保证重启后重试与去重,升级前未投递的旧消息保留可读但不再投递。

Pi

进程边界就是通信协议:任务走命令行参数,结果走 stdout 的 JSON 事件流

内核没有 Agent 间通信;示例扩展把子代理做成一个独立的 pi 进程,用 --mode json -p --no-session 启动,任务作为参数传入,父进程逐行解析子进程 stdout 上的 JSON 事件,收集消息、累计用量与结束原因。通信是单向的:子代理运行期间父代理不能再发消息给它,只能中止——先发 SIGTERM,5 秒后仍未退出就 SIGKILL。扩展的 README 另外提供并行(最多 8 个任务、同时 4 个)与链式(用 {previous} 占位符把上一步输出传给下一步)两种编排。

适合
一次性委派、不需要中途沟通的任务,例如并行调研或流水线式分步处理。
代价
运行中无法补充信息,只能中止重来;每个子代理都是一个新进程。
横向读这一行

通信的形态跟着隔离的粒度走。Pi 用独立进程,通信退化成「参数进、事件流出」,运行中无法对话;Codex 把消息做成协议里的一等条目,带收件人与是否唤醒对方的开关;DeepSeek 把父发子与子回父拆成两个独立的包,方向和权限都显式建模;openJiuwen 最通用,一条消息总线同时支持点对点与发布订阅。越往后,协作越灵活,也越需要回答「谁有权给谁发消息」这个问题。

这个问题为什么存在

第 7 章

多 Agent 协作

受限子代理、消息总线与验证者:编排多个循环