Multi-agent Handoff：多个 Agent 之间怎么交接？

今天先记住

Multi-agent Handoff（多 Agent 交接）不是“多叫几个模型一起干活”。它真正要解决的是：当任务跨越不同职责边界时，谁接手、带着哪些上下文接手、接手后谁负责最终结果。

它在大地图里的位置

今日坐标

规划 / 决策 → Multi-agent Handoff

txt

用户目标
  -> 上下文 / 记忆
  -> ▶ 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

前面讲失败恢复，是单个执行链路坏了之后怎么收住。今天往外扩一圈：如果一个 Agent 不适合继续处理，系统可以把控制权交给另一个更合适的 Agent。但交接本身也是一次状态变化，不能只靠一句“让专家来”糊过去。

它到底是什么

Handoff 是控制权的显式转移。一个 Agent 判断当前任务已经进入另一个职责区间，于是把任务、必要上下文、当前状态、限制条件和期望输出交给下一个 Agent。

这里最重要的是“显式”。如果 A 只是调用 B 当工具，A 仍然负责组织最终答案；如果 A handoff 给 B，B 往往会成为新的主处理者。工程上要把这两种关系分清，否则日志里看起来有很多 Agent，实际责任边界全是糊的。

为什么 Agent 里会用到它

单个 Agent 可以覆盖很多事，但上下文、权限、工具和评价标准不可能无限堆。写文档、改代码、查资料、审安全、发生产部署，本来就是不同职责。

交接的价值不在“角色扮演更丰富”，而在减少错位：让有部署权限的 Agent 处理发布，让懂代码库的 Agent 改文件，让审查 Agent 只看风险。这样失败时也能定位：是路由错了、上下文没带够，还是接手 Agent 的工具边界不对。

怎么判断它有没有用

如果任务需要不同权限，比如“读仓库”和“发生产”不能放在同一条无差别链路里，handoff 就有意义。
如果只是一个 Agent 调一次搜索、再整理答案，用工具调用就够了，不必拆成多个 Agent。
如果交接后没人知道最终由谁验收，这不是多 Agent，而是责任漂移。
一个可用的 handoff 至少要说清：为什么交给它、带哪些上下文、禁止做什么、完成后回到哪里。

一个小例子

txt

Input:
用户说：“把今天的 AI Agent Daily 写好、发布，并确认不要泄露隐私。”

Process:
1. Writer Agent 根据路线写 Markdown。
2. Reviewer Agent 接手，只检查敏感信息、结构和日期是否一致。
3. Publisher Agent 接手，只负责 git add 指定文件、commit、push。

Output:
状态从 draft -> reviewed -> published。
如果 Reviewer 发现私密日志，状态变成 blocked，不允许 Publisher 接手。

这个例子能用来判断真实系统：好的交接会改变系统状态，并留下“谁在什么条件下接手”的记录；差的交接只是把同一段上下文丢给另一个模型再赌一次。

常见误区

把多 Agent 当成越多越好。Agent 越多，交接成本、日志复杂度和责任边界都会增加。
只设计角色名，不设计交接条件。比如“研究员”“工程师”“审查员”听起来清楚，但什么时候切换才是关键。
交接时丢上下文。下游 Agent 不知道用户目标、限制和前面做过什么，就会重复劳动或做错方向。
交接后没有回收机制。任务完成后要么返回主控，要么结束流程，不能无限转派。

今天自测

tool calling 和 handoff 的责任边界有什么区别？
一个 Agent 交给另一个 Agent 时，至少应该带上哪三类信息？
如果多 Agent 系统出了错，你会先查路由条件、上下文传递，还是工具权限？为什么？

Multi-agent Handoff：多个 Agent 之间怎么交接？ ​

今天先记住 ​

它在大地图里的位置 ​

它到底是什么 ​

为什么 Agent 里会用到它 ​

怎么判断它有没有用 ​

最近冒出来的词 ​

一个小例子 ​

常见误区 ​

今天自测 ​