多 Agent 不是“多开几个模型更聪明”。每增加一个 Agent，就增加一份指令、一套工具和策略、一次路由判断、一段上下文边界与一个可能失败的交接。如果拆分只为了角色扮演，系统会得到更多重复研究、互相转交和难以归因的错误，却没有新增能力。

本文面向已经有单 Agent 工作流、开始遇到提示词过长、工具权限冲突或专业任务混杂的开发者。你需要理解工具调用、状态机与并发任务。核心问题只有两个：什么时候值得拆，拆开后谁拥有最终回答。

Handoff 把回答所有权交给专家，而 Agent as tool 由管理者保持所有权

图 1（1600 × 900）：WEB/SUN 原创 SVG。拓扑由回答所有权决定，不由“看起来像几个角色”决定。

默认从一个 Agent 开始

OpenAI 的 Building agents 路线先把模型、工具、知识、控制逻辑与评测视为同一系统；其中的编排与 handoff 指南建议尽可能从一个 Agent 开始，只在能力隔离、策略隔离、prompt 清晰度或 trace 可读性得到实质改善时增加专家。一个任务包含“搜索、总结、写作”并不自动需要三个 Agent；它也许只需要一个 Agent 调三个确定性工具。

值得拆分的信号更具体：

  • 两类任务需要互斥的工具与权限，例如公开检索和财务写入。
  • 指令与验收标准确实不同，放在一起会互相干扰。
  • 某个阶段需要独立模型、上下文或合规策略。
  • 专家结果能定义成稳定、可验证的输入输出契约。
  • trace 中能够分别衡量路由和专家质量。

不值得拆的信号是“提示词很长”但没有先整理结构、工具边界和检索；或者希望不同 Agent 互相辩论就自然得到正确答案。并行生成更多意见会增加覆盖面，也会增加成本和冲突，仍需要一个有明确规则的合并者。

Handoff 与 Agent as tool：先决定所有权

官方指南给出两个基本模式。Handoff 用于专家应接管当前分支并拥有下一条用户回复的场景；分流 Agent 把控制权移交给账单、退款或技术支持专家。后续 turn 通常继续由该专家处理，直到明确返回或再次交接。

Agent as tool 用于管理者始终拥有最终答复、专家只提供有界能力的场景。研究管理者可以调用“法律资料抽取”和“技术事实核验”专家，然后由自己合并。官方Agents as tools 示例把这类专家包装成工具，工具名与描述成为管理者的路由面。

判断问题可以简化为一句：用户下一次追问时，应该继续找谁？若专家需要持续掌握该分支的策略与语境，handoff 更自然；若专家结果只是报告、分类或摘要，manager-style 更稳定。不要在同一路径中随意混用，让最终答复所有者不断变化。

所有权还包括失败和审批。handoff 后的专家触发高风险工具，审批应恢复同一个专家运行；Agent as tool 失败时，管理者决定重试、换专家、降级还是向用户说明，专家不能越过管理者直接发最终文案。

每次交接都用任务信封

不要把完整聊天记录和一句“继续处理”交给专家。交接输入应是结构化任务信封：

type DelegatedTask = {
  taskId: string;
  objective: string;
  nonGoals: string[];
  inputs: ArtifactRef[];
  constraints: string[];
  expectedOutput: JsonSchemaRef;
  evidenceRequired: string[];
  deadline: string;
};

objective 只描述一个可完成结果；nonGoals 防止专家扩大范围；inputs 引用不可变 artifact，而不是复制无限上下文；expectedOutput 让合并者能校验；证据要求决定引用、测试或 trace。身份、权限与租户仍由运行上下文提供，不允许上游 Agent 在文本中授予权限。

OpenAI 的Agent 定义指南强调专家应有清晰的名称、指令、工具和输出契约。把边界写进类型和工具集合，比在 prompt 中反复声明“只做自己的工作”更可靠。专家只拿到必要上下文，也降低不可信数据跨节点传播的风险。

用任务账本阻止重复工作

多 Agent 重复通常来自三个原因：任务没有稳定 ID；多个 worker 不知道别人已领取；结果以聊天消息存在，无法复用。解决方式是一份应用拥有的任务账本，而不是让 Agent 互相口头汇报。

每个任务记录 queued → leased → completed | failed | cancelled，并包含规范化输入哈希、负责人、租约到期、依赖、输出 artifact 和验证状态。领取任务采用原子租约；只有租约持有者能提交对应 revision。worker 超时后可被重新领取，但提交前检查是否已有完成结果。

去重键由“任务类型 + 规范化输入 artifact 版本 + 约束版本”组成。两个专家都需要同一份网页摘要时，应引用同一个已完成 artifact，而不是各自抓取。若目标不同，例如一个抽取事实、一个审查授权，它们即便输入相同也不是重复任务。

结果先写 artifact store，再把引用交给下游。artifact 包含 schemaVersion、来源、生成配置、验证状态和内容哈希。这样合并者知道用的是哪一版，失败恢复时也不必让专家重新研究。

并行只用于真正独立的分支

并行前画依赖图。不同来源的资料核验、不同平台的兼容检查可以并行；“先确定接口，再为接口写实现”不能并行猜测。若两个分支会修改同一文件、同一订单或同一计划，应用应指定唯一写入者，其他 Agent 只提交建议或独立 patch artifact。

合并必须有一个 owner 和确定规则。它先验证所有 artifact 的 Schema 与证据，再处理冲突：事实冲突回到来源；策略冲突交给优先级规则或人工；文风冲突由合并者统一。不要再创建一个没有规则的“裁判 Agent”让它凭感觉投票。

为每条路径限制 handoff 次数、嵌套深度、同一专家重复进入次数和总预算。检测到 A→B→A 时，运行器应中止路由并输出缺少的决策信息，而不是继续互相转交。一个专家不应把任务原样再委派给具有相同契约的专家。

上下文过滤与最小权限

Handoff 可能需要对话连续性，但不等于传递全部内部 trace。按专家契约过滤历史：保留用户目标、已确认事实、必要工具结果与审批状态；删除其他专家的内部草稿、无关私人数据和不可信指令。给用户可见的历史与给专家执行的 state 可以是不同视图。

工具按专家最小化。路由 Agent 通常只需分类，不该拥有退款工具；研究专家需要只读检索，不该能发布；最终管理者可能能申请动作，但高风险工具仍要审批。多 Agent 不能成为绕过原有授权的方式。

分层评测，而不是只评最终答案

OpenAI 的评测最佳实践指出，架构从单次调用走向工作流、单 Agent 和多 Agent 时，非确定性入口随路由、工具与交接增加。评测需要拆开：

  • 路由准确率：是否选择正确专家，是否应该保持单 Agent。
  • 交接完整度：任务信封是否包含必要输入和非目标。
  • 专家契约：输出是否满足 Schema、证据和权限边界。
  • 重复率：相同去重键是否只执行一次，缓存是否被复用。
  • 合并质量：冲突是否被发现，最终论断能否追溯 artifact。
  • 控制流：是否出现 ping-pong、超深嵌套、预算越界或遗漏审批。

最终答案优秀但路由错误，可能只是碰巧；只看答案会让成本和风险逐步上升。保留 task、handoff、tool、artifact 与 merge 的 trace，才能把失败归到真正节点。

失败模式与取舍

常见错误包括：按部门名而非契约拆 Agent；handoff 后管理者仍偷偷改写专家答复；专家作为工具却直接与用户沟通；用共享聊天代替任务账本；多个 Agent 同时修改同一资源；完整上下文无过滤传播；用多数投票代替来源核验。

多 Agent 的收益是隔离复杂指令、工具和策略，也带来额外延迟、令牌、状态与评测成本。只有当隔离收益能被指标证明时保留拆分；否则合并回一个 Agent 加普通工具，通常更清晰。

结论

多 Agent 架构首先是所有权和任务系统，而不是角色数量。先以单 Agent 为基线，在契约或权限真正改变时拆分；用 handoff 转移回复所有权，用 Agent as tool 保持管理者所有权；所有交接经过结构化任务信封，所有工作进入带租约、去重键和 artifact 的账本。

当系统能回答“谁负责最终回复、谁正在做这项任务、结果保存在哪里、为什么没有重复做”，多 Agent 才带来可控的专业化，而不是并行的混乱。

Sources