DevNull 知识库

Appearance

23｜协作机制：handoff、agents-as-tools 与 A2A ​

上一篇选定了编排模式。但编排模式只说"谁负责什么"，没说 agent 之间控制权怎么传递。

orchestrator-worker 里，编排者调 worker，是"调一下拿结果"还是"把整个对话交出去"？这两种机制差别很大，直接影响谁能看到用户、谁对最终回答负责。本篇讲两种控制传递机制，以及跨框架协作的 A2A 协议。

两种控制传递 ​

业界（OpenAI Agents SDK 是典型）把 agent 间的控制传递分成两种：handoff 和 agents-as-tools。差别在"谁拥有最终回答"。

AIOps 概念图：handoff 和工具化

handoff：控制权整个交出去 ​

handoff 是一个 agent 把整个对话的控制权交给另一个 agent。交出去之后，接收的 agent 直接面对用户，负责后续回答，原 agent 退出。

python
# triage agent 把控制权 handoff 给日志分析 agent
triage_agent = Agent(
    name="分诊",
    instructions="判断告警类型，路由给对应专家。",
    handoffs=[log_analysis_agent, metric_analysis_agent],
)

handoff 的特点是：接收方 agent 直接回应用户，能看到完整对话历史，自己决定后续怎么走。这适合"分诊后整个交给专家"的场景——分诊 agent 判断这是日志问题，把对话交给日志分析 agent，日志分析 agent 接手后直接和用户交互，分诊 agent 不再插手。

适合用 handoff 的场景：专家应该接管整个后续交互、需要专家直接面对用户、路由本身是工作流的一部分。

代价：handoff 后原 agent 失去控制，全局视角变弱。如果专家 agent 走偏了，原 agent 没法纠正。多个 handoff 链起来后，谁对最终结果负责会变模糊。

agents-as-tools：编排者保留控制权 ​

agents-as-tools 是编排者把其他 agent 当工具调用。被调用的 agent 返回结果，但控制权始终在编排者手里，编排者拼最终回答。

python
# 编排者把日志分析 agent 当工具调用
orchestrator = Agent(
    name="编排",
    instructions="调用专家获取分析结果，自己汇总最终回答。",
    tools=[log_analysis_agent.as_tool(), metric_analysis_agent.as_tool()],
)

被调用的 agent 不直接面对用户，只返回结果给编排者。编排者可以并行调多个、可以组合多个结果、可以加统一的安全护栏。

适合用 agents-as-tools 的场景：编排者要保持控制、要组合多个专家的输出、要在统一地方加护栏。运维排查多数场景适合这个——编排者（主 agent）调用日志分析、指标分析、Runbook 检索，自己汇总成带证据的报告。

怎么选 ​

判断标准很简单：专家该不该直接面对用户？

该直接面对，用 handoff——专家接管整个后续。不该直接面对，用 agents-as-tools——编排者调专家拿结果，自己面对用户。

两者可以混用。分诊 agent handoff 给某个专家，专家接管后仍然可以把别的 agent 当工具调，处理自己的子任务。

A2A：跨框架协作 ​

handoff 和 agents-as-tools 都是在同一个 agent 框架内协作。如果两个 agent 来自不同框架、不同供应商呢？

Google 在 2025 年 4 月推出的 A2A（Agent-to-Agent）协议解决这个。它是一个开放标准，让不同框架、不同供应商的 agent 能互相发现、通信、协作。现在由 Linux Foundation 托管，Google、Atlassian、Salesforce 等几十家公司支持。

A2A 和 MCP 的分工 ​

A2A 和 MCP 不是竞争，是互补，管的是不同层面。

AIOps 概念图：A2A 和 MCP 分工

MCP 是 agent-to-tool：agent 怎么连接工具、API、外部资源。第 24 篇会讲。agent 用 MCP 调搜索引擎、数据库、第三方 API。

A2A 是 agent-to-agent：agent 之间怎么协作、委派任务、管理共享工作流。agent A 用 A2A 把一个子任务交给 agent B，agent B 处理完返回结果。

text
agent A ──A2A──→ agent B
   │                │
  MCP              MCP
   │                │
 工具/API         工具/API

一个完整的 agentic 系统里，agent 之间用 A2A 协调，每个 agent 用 MCP 连自己的工具。A2A 管 agent 间，MCP 管 agent 接工具，两层不冲突。

什么时候用 A2A ​

A2A 的价值在跨框架互操作。如果所有 agent 都是你自己用同一个框架建的，A2A 用不上——框架内部的 handoff 或 agents-as-tools 更直接。

A2A 适合：agent 来自不同团队、不同框架、不同供应商，需要协作。比如 ops-assistant（自建）要和一个第三方监控平台的 agent 协作，两边框架不同，A2A 提供统一通信标准。A2A 还支持 agent 发现——agent 能发现其他 agent 及其能力，MCP 做不到这点。

运维场景里，A2A 目前还偏新。多数项目所有 agent 自建，用 handoff 或 agents-as-tools 就够。A2A 在需要接入外部 agent 生态时才显出价值。

两个反模式 ​

不管用哪种机制，有两个反模式要避免。

delegation loop（委托循环）。agent A 把任务委派给 B，B 又委派回 A，A 又委派给 B，无限循环。CrewAI 现在默认关掉 delegation 就是防这个。设计协作时要明确每个 agent 的职责边界，不让任务在 agent 间来回弹。

python
# 防委托循环：记录委派链，检测环
def handoff(from_agent, to_agent, task, chain):
    if to_agent in chain:
        raise DelegationLoop(f"检测到委托循环: {chain + [to_agent]}")
    return to_agent.run(task, chain + [to_agent])

retry storm（重试风暴）。一个 agent 失败后重试，触发另一个 agent 失败，又触发重试，连锁反应。需要全局速率限制和重试上限，不能让每个 agent 各自无限重试。

handoff 和 agents-as-tools 这两种机制，在 OpenAI Agents SDK 里就是同名概念，CrewAI 的 delegation 是 handoff 的变体。框架给了现成实现，但 delegation loop、retry storm 这些反模式框架不一定防得住——CrewAI 后来默认关掉 delegation 就是防循环，说明框架也在补这些判断。理解了原理，用框架时才知道哪些坑要自己防（第 25 篇展开框架对应关系）。

协作机制之后 ​

agent 间的协作机制讲完了：同框架内用 handoff 或 agents-as-tools，跨框架用 A2A。但还有一个外部集成问题：agent 要用的工具，如果不想每个 agent 都自己实现一遍，怎么共享？

下一篇讲 MCP。它解决跨客户端共享工具的标准协议——一个工具按 MCP 暴露后，任何 agent 都能发现和调用。