跳到主要内容

Handoff、Agents as Tools 与 A2A

学到多 Agent 之后，这三个概念很容易混在一起：

  • 任务到底是该 handoff
  • 还是把下游 Agent 当成 tool
  • 还是应该走 A2A

这三个词都和“把工作交给别的执行单元”有关，但它们解决的问题并不一样。

这里集中处理一个问题：

把 handoff、agents as tools 和 A2A 放在同一张设计坐标里，看清它们分别适合什么边界。

1. 先看最短区分​

可以先用这组定义建立直觉：

  • handoff：把主导权交给另一个 Agent
  • agents as tools：主 Agent 保持主导，只调用下游 Agent 完成一段工作
  • A2A：和另一个独立 Agent 系统按协议协作

先把这一层分清，后面的设计判断会轻松很多。

2. 它们分别在回答什么问题​

2.1 handoff 回答的是“谁来继续主导任务”​

常见情况是：

  • 先由一个总入口 Agent 接住请求
  • 再根据领域、权限或任务类型，把后续流程交给另一个 Agent

交接之后，新的 Agent 成为当前任务的主要执行者。

这类模式常见于：

  • 问题分流
  • 多领域专家协作
  • 不同阶段需要不同主控角色的系统

2.2 agents as tools 回答的是“主 Agent 是否只需要借用下游能力”​

这里的关键不是“对面是不是 Agent”，而是：

  • 当前系统是否还需要一个明确的主控 Agent
  • 下游能力是不是只负责一个局部任务
  • 主流程是否仍应保持在同一条运行链里

如果答案是肯定的，下游 Agent 往往更适合作为 tool。

这类模式常见于：

  • 主 Agent 统一管理状态
  • 下游只处理一个专长任务
  • 希望把观察、评估和错误处理收敛在一条链里

2.3 A2A 回答的是“如何与另一个独立 Agent 系统协作”​

A2A 的重点不是“交不交主导权”，而是：

  • 对方是不是独立系统
  • 是否需要远程任务状态
  • 是否需要任务产物、异步更新和跨系统协作

当下游已经不是“系统内部一个节点”，而是“另一套 Agent 服务”，A2A 才开始变得重要。

这类模式常见于：

  • 跨团队 Agent 协作
  • 远程长任务
  • 需要明确任务状态、产物和异步交付的场景

3. 一张关系图​

这张图里最需要记住的是：

  • handoff 会改变主导者
  • agents as tools 不改变主导者
  • A2A 讨论的是跨系统协作接口

4. handoff 什么时候更合适​

更适合 handoff 的信号有这些：

4.1 任务后半段已经进入另一个领域​

例如：

  • 总入口先做分流
  • 财务问题交给财务 Agent
  • 法务问题交给法务 Agent

4.2 后续流程需要新的系统提示和工具集​

如果下一个阶段需要：

  • 完全不同的系统提示
  • 完全不同的工具权限
  • 完全不同的输出责任

让新 Agent 接管，边界会更清楚。

4.3 交接本身需要被显式记录​

有些系统需要清楚回答：

  • 谁把任务交出去
  • 为什么交出去
  • 交给了谁
  • 从哪一步开始由另一个角色负责

这时 handoff 会比普通 tool 调用更合适。

5. agents as tools 什么时候更合适​

5.1 主控链路必须保持统一​

如果系统希望：

  • 统一记录 trace
  • 统一管理 state
  • 统一控制预算、超时和重试

那么把下游 Agent 包装成 tool，通常更稳一些。

5.2 下游 Agent 只是局部专长能力​

例如：

  • SQL 生成 Agent
  • 检索摘要 Agent
  • 表格格式化 Agent
  • 图表建议 Agent

这些能力已经带一点 Agent 性质，但并不需要接管整个任务。

5.3 希望减少协作复杂度​

很多系统一开始就把多个角色拆得太开，结果往往是：

  • 状态来回传
  • 错误不好追
  • 测试边界变模糊

如果主控 Agent 仍然足够清楚，agents as tools 往往是更收敛的做法。

6. A2A 什么时候更合适​

6.1 下游本来就是独立 Agent 服务​

例如：

  • 一个 research agent 平台
  • 一个采购审批 agent 服务
  • 一个企业内统一的合同审阅 agent

这类对象不只是“某个工具”，而是一套独立任务系统。

6.2 任务不是短同步调用​

如果下游需要：

  • 排队
  • 异步执行
  • 分阶段返回状态
  • 最后交付 artifact

就已经更接近 A2A 的任务模型。

6.3 需要跨组织或跨边界协作​

A2A 的价值经常出现在：

  • 团队之间
  • 服务之间
  • 平台之间

这里关注的不只是功能调用，而是协作接口和任务契约。

7. 一个很实用的判断表​

问题更接近哪种模式
下一个执行者是否应成为新的主导者handoff
主 Agent 是否仍需保留统一主控agents as tools
下游是否只是一个局部专长能力agents as tools
下游是否是独立远程 Agent 系统A2A
是否需要远程任务状态、产物和异步回传A2A
是否只是做领域分流和职责转交handoff

8. 一个常见误区​

常见误区主要有两种。

8.1 把所有多 Agent 都做成 handoff​

这样做的问题在于：

  • 主控很快消失
  • trace 被切碎
  • 回归测试难度变高

很多本来适合 agents as tools 的场景，没有必要一上来就交主导权。

8.2 把所有远程协作都当成 tool call​

这样做的问题在于：

  • 任务状态被压扁成一次调用
  • artifact 和进度信息不好表达
  • 异步长任务会很别扭

这类场景往往更接近 A2A。

9. 设计顺序建议​

一个比较稳的顺序是：

  1. 先从 agents as tools 开始
  2. 确认哪些场景真的需要 handoff
  3. 只有在跨系统协作时，再进入 A2A

这样做的好处在于：

  • 主控边界更清楚
  • 复杂度增长更慢
  • 回归与观测更容易收拢

10. 和哪些文档一起看最顺​

11. 小结​

先要分清的，不是术语，而是控制权、责任边界和协作对象：

  • handoff 讨论主导权切换
  • agents as tools 讨论主控链路里的局部能力复用
  • A2A 讨论独立 Agent 系统之间的协作接口

把这三层分清之后，多 Agent 设计会稳很多。