多 Agent 与人机协作

多 Agent 与人机协作

多 Agent 是组织结构设计，不是数量竞赛：让多个具有不同角色、工具、记忆或权限的 Agent 协同完成任务。技术模式（主管-员工、辩论、投票、市场竞价，以及编排框架）见 Agent 架构与多智能体，本页只讲产品决策：什么时候值得上多 Agent、编排模式怎么选、上下文怎么隔离与共享、怎么观测与控成本、人怎么进团队，以及一份反模式清单。

本文从 Agent 产品设计深度篇 分流而来。先记住三个判断：

• 多 Agent 是花钱买并行度与上下文隔离：官方实测 token 消耗约 15 倍，收益不量化就不该上
• 先单 Agent，评测证明收益后再多 Agent：这是官方原则，也是社区血泪教训的共识
• 人是团队的一部分：编排者、监督者、审批者三种角色，长期运行必须有治理

单 Agent vs 多 Agent 的决策

官方实测：先把账算明白

Anthropic 的实测是目前最权威的取舍数据：以 Claude Opus 4 为主、Sonnet 4 为子 Agent 的多 Agent 系统，在其内部研究评测上比单 Agent Opus 4 好 90.2%，但 token 消耗约为普通对话的 15 倍；在 BrowseComp 上 token 用量单独解释了约 80% 的表现差异（多 Agent 研究系统）。

拆开看这笔账：多 Agent 的收益是三个——并行度（多个子任务同时跑）、上下文隔离（每个子 Agent 只看自己那部分，主 Agent 不被过程淹没）、专业化（每个子 Agent 配专属工具与提示词）；代价也是三个——token 倍数、编排复杂度（拆任务、合并结果、异常处理）、调试成本（失败跨 Agent 传播，定位难）。

用一张表把账算出来再决定：

这个账本解释了为什么「先单 Agent」是理性而非保守：多 Agent 的 90.2% 提升中，token 用量单独解释了约 80% 的表现差异——一部分提升来自「花了更多 token」而不是结构本身。如果单 Agent 加预算（更长的思考、更多的检索尝试）也能拿到接近的结果，多 Agent 的结构性收益就要重新评估。

适用条件：任务天然可拆、子任务可并行、可各自隔离上下文、失败代价高；失效条件：任务强依赖、必须共享同一上下文、失败代价低——先算账，算不明白就当不值得。

任务画像：适合与不适合

官方口径要背下来：大多数编码任务不适合多 Agent——它们需要所有 Agent 共享同一上下文、Agent 间强依赖（多 Agent 研究系统）；官方点名的适合场景是重度并行、信息量超出单一上下文窗口、需要对接大量复杂工具的研究类任务（汇总口径见 Agent 产品设计深度篇）。

三个典型任务套一遍画像，直观感受差异：

社区实证：linux.do 7-Agent 流水线复盘

社区实践与官方建议互证。linux.do 上有团队复盘自研的 7-Agent 研发流水线（需求分析、架构、审查、编码、测试、部署），结论是链路冗余、职责边界模糊；回复中多名实战者直言「多 Agent 是无效的副作用」——上下文混乱、无效沟通，主张「一个上下文内的 multi mode 比 multi agent 更适合」；另有回复提醒「生产系统不敢用」「这么多 Agent 一个小问题都得跑半天」（linux.do 讨论帖）。

对产品经理的三条启示：

• 从众上多 Agent 是预算与口碑双输：流水线「看起来完整」不等于「跑得快」，链路里的每一步都要真金白银的 token 与维护成本
• 职责边界模糊是组织设计问题：先写清楚每个 Agent 的输入、输出、验收标准，再谈要不要拆——边界都画不清，拆了只会更乱
• 决策顺序固定：工作流 → 单 Agent → 人工复核 → 评测证明收益 → 才考虑多 Agent

画像自检：五个问题

立项前逐题自检，五个都答「适合」才值得继续：

• 任务能拆成 ≥2 个相互独立的子任务？
• 每个子任务都能独立验证完成质量？
• 子任务不需要共享同一上下文？
• 并行执行带来的收益能量化（时间、质量）？
• 失败代价足够高，值得为质量多付 5-15 倍成本？

有一个答不上来，就先跑单 Agent——多 Agent 不会让「说不清」的任务变清楚，只会让说不清的复杂度放大十倍。

混合形态：不必全 Agent 化

「单 Agent vs 多 Agent」不是二选一。Anthropic 的官方建议是先找最简单的方案，只在确有收益时增加复杂度（Building Effective Agents）——很多产品的最终形态是「工作流外壳 + 局部多 Agent」：

• 评估-优化循环：生成 + 评估两个 Agent 只在「生成质量是瓶颈」的环节启用，其他环节单 Agent 完成
• 并行投票：只在「结论需要稳健」的单点启用（如风险判断投 3 票），而不是整条流水线拆成多个 Agent
• 对抗式复核：独立上下文里的复核子 Agent 审查产出——「干活的人不给自己打分」，是官方推荐的并行模式（Claude Code 最佳实践）

适用条件：任务整体不适合多 Agent，但存在 1-2 个可独立验证的质量瓶颈环节；失效条件：把每个环节都改成「生成 + 评估」对，成本直接翻倍——混合形态的边界是「评测证明该环节确实需要」，而不是「听起来更稳」。

编排模式的产品含义

三种委托方式

多 Agent 怎么把任务交出去，产品上对应三种协作关系（原语机制见 Agent 架构与多智能体 与 OpenAI Agents SDK）：

选择规则：

• 用户需要随时接管、任务结果需要逐步校验 → 工具调用式（主 Agent 保留监督）
• 任务阶段边界清晰、每个阶段是专家活 → handoffs（把责任一起交出去）
• 任务并行探索、结果统一汇总 → orchestrator-worker

失效条件：无论哪种模式，委派质量都决定上限；模式解决的是「控制权结构」，解决不了「子任务写不清楚」——那是下一节的问题。

委派质量：把子任务写清楚

Anthropic 的工程经验：子任务描述含糊会导致重复劳动；子 Agent 把产物写入文件系统、只传引用给主 Agent，避免「传话游戏」式的信息失真（多 Agent 研究系统）。

委派模板，五个字段缺一不可：

适用条件：子任务可独立验证（有测试、有格式检查、有终态）；失效条件：子任务无法独立验证时，委派模板写得再细也是空转——先让子任务可验证，再谈委派。

依赖关系与责任链

子任务之间不总是并行，编排前先画依赖图：

• 无依赖 → 并行扇出（并行度高才能摊薄 token 倍数，这是多 Agent 账本的关键变量）
• 顺序依赖 → 串行传递，前一个子任务的产物是后一个的输入
• 部分依赖 → 按层并行：同层无依赖的一起跑，层与层之间同步

责任链要提前约定：控制权可以移交，最终责任不随控制权移交。handoffs 模式下用户抱怨「刚才那个 Agent 做的事」，产品上要能追溯到原始 Agent 与交接记录；orchestrator-worker 模式下主管对汇总结果负全责，子 Agent 对各自产物负责。责任链写进 trace 与审计，是事故定责的前提。

失效条件：依赖图画错（把有依赖的子任务标成并行）会导致合并结果互相覆盖——画完图先人工走查一遍「每个子任务的输入是否都已在场」。

上下文隔离与共享

多 Agent 的上下文策略是最容易被拍脑袋的决策，先分清两个概念：

• 隔离上下文：每个子 Agent 只有自己的上下文，主 Agent 只收结论——防污染、可并行、省 token；代价是共享事实要显式传递
• 共享上下文：所有 Agent 读写同一份上下文/黑板——简单直接；代价是互相污染、上下文爆炸、调试困难

产品决策：共享「状态」，不共享「上下文」。需要跨 Agent 共享的，用结构化载体——数据库（任务进度、审批状态）、文件系统（产物、草稿）、消息总线（事件通知），而不是把所有东西堆进 prompt：

适用条件：子任务间只依赖「结果」时隔离收益最大；失效条件：把「共享状态」做成「共享上下文」是高频翻车点——状态要结构化、可查询、可权限控制，而上下文是「当前这轮模型看到的全部文本」，两者混用等于既丢了隔离又丢了效率（上下文工程的取舍见 Agent 架构与多智能体 的「上下文工程」一节）。

三个结构化载体的分工：

选择标准：状态要被查询 → 数据库；状态要被读取/编辑 → 文件系统；状态要通知 → 消息总线。不要为了「统一」把所有东西塞进一个载体。

每个子任务的上下文预算也要在设计期核算：子任务读多少资料、产出多大产物、主 Agent 汇总时塞多少——超预算的方案在设计阶段砍掉，而不是上线后靠压缩硬扛（上下文溢出的组合治理见 Agent 架构与多智能体）。

可观测性与调试

日志与 tracing

多 Agent 的可观测性要求比单 Agent 高一个维度：单 Agent 只需回答「这个任务怎么失败的」，多 Agent 还要回答「失败在哪个子任务、归因到哪个 Agent、token 花在哪一步」。上线前必须能回答三个问题：

• 复现：trace 回放失败案例——哪条执行链、哪个子 Agent、哪次工具调用开始跑偏（主流 SDK 内置 tracing，如 OpenAI Agents SDK）
• 归因：token 与成本按子任务/子 Agent 拆分——15 倍的账花在哪，预算优化的靶子在哪
• 审计：谁在什么时候让 Agent 做了什么——多 Agent 链路上的责任划分依据

trace 的最小字段集：parent/child 关联 ID、子任务状态机（pending / running / waiting_approval / done / failed）、每次工具调用的参数与结果摘要、token 统计、审批记录。没有 trace 的多 Agent 无法上线——这不是可选项（AgentOps 体系见 Agent 架构与多智能体）。

多 Agent 的运营指标集（比单 Agent 多三类）：

每月把归因层数据拉出来看一遍：哪个子任务永远失败、哪个子任务 token 占比畸高——多 Agent 系统的坏味道通常先在这些数字里露头。

定位问题的顺序建议：先看归因层数字（哪个子任务失败最多）→ 再打开失败任务的 trace 回放（哪一步开始跑偏）→ 最后用失败样本构造评测回归（修完不再复发）。按这个顺序走，多 Agent 的调试成本可以从「大海捞针」降为「按图索骥」。

面向用户的透明度

面向用户的设计原则：像看项目看板一样看 Agent 团队。终端用户需要的是：

• 子任务列表：这个任务被拆成了几步，现在进行到第几步
• 当前执行步骤：正在做什么、用了什么工具、结果如何（与 Agent 工具与 MCP 产品化 的工具展示 UX 同一套原则）
• 汇总报告：结论可点回来源、失败如实标注、人工介入点明确

适用条件：任务可拆分成对用户有意义的步骤（调研、报告、客服）；失效条件：任务拆分成用户看不懂的技术碎片时，展示子任务列表只是噪音——按用户角色切粒度：终端用户看进度与结论，运营/PM 看子任务链与成本，工程看完整 trace。

多 Agent 的运营成本

成本模型与预算护栏

成本模型一句话：多 Agent 成本 = 单次调用成本 × 任务拆分倍数 × 调用量。15 倍是官方实测的典型值而不是上限——并行投票、辩论类模式按参与 Agent 数线性放大；一个任务拆成 N 个子任务，基础输入 token 就近似 ×N（每个子任务都要重新读任务说明与部分共享资料）。

估算流程（方法见 LLM 成本测算 的三步法）：

1. 先单 Agent 跑通任务，测出基线 token/任务
2. 按拆分数与并行度估算倍数（orchestrator-worker 通常 5-15 倍，投票按参与数 ×N）
3. 乘工程系数（多 Agent 的重试、评测、失败重跑更频繁，取 1.3-1.5 甚至更高）
4. 对照收益（成功率提升 × 失败代价）决定值不值

账本示例（沿用 LLM 成本测算 的口径）：

• 单 Agent 基线：每任务输入 50k token、输出 5k token，按输入 $3/M、输出 $15/M 计，单次 ≈ $0.225
• 拆成 5 个子任务的 orchestrator-worker：每个子任务都要重读任务说明与共享资料，输入膨胀到 30k × 5 + 主 Agent 汇总 30k ≈ 180k，输出约 20k → 单次 ≈ $0.84，约 3.7 倍
• 加工程系数 1.3（重试、失败重跑、评测）→ 实际约 5 倍
• 决策：任务成功率从 70% 提到 90%，每 100 个任务少失败 20 个；单次失败损失 > $1.5（约 5 倍成本差）才值得，否则不划算

注意：15 倍是官方在研究型任务上的实测，业务任务通常没有那么多并行探索，实际倍数要自己测——用上面的流程跑一遍再立项，别拿别人的倍数替自己算账。

多 Agent 的降本杠杆（按见效排序）：

• 缓存共享前缀：任务说明、共享资料放在 prompt 前缀并保持格式稳定，多个子任务命中 prompt 缓存折扣（计费模型见 LLM 成本测算）
• 小模型干杂活：分类、摘要、格式整理类子任务用低成本模型，关键推理才用旗舰
• 降并行度：5 路并行改 3 路，多数任务收益损失有限，token 直接省约 40%
• 结果复用：同一子任务的结果缓存，重复请求不重跑

适用条件：成本已超预算、收益差一口气时；失效条件：降本动了关键子任务的模型或并行度，成功率掉回单 Agent 水平——每次降本都要盯任务层指标回归。

预算护栏三条，缺一不可（与 Agent 产品设计深度篇 的成本防护一致）：

• 任务级：max_turns 步数上限、max_tokens 上限、单任务成本上限，超出即终止
• 账户级：单用户/单租户日限额，超限降级或限流
• 告警：单日成本环比突增（如 >50%）立即告警排查；成本看板按产品、功能、用户拆分

失效条件：护栏设了但没有降级路径 = 空转——预算用尽时的行为要预先定义（降级为单 Agent、降为每步确认、或转人工），而不是让任务静默卡死。

什么时候拆回单 Agent

出现以下信号之一，就把多 Agent 拆回单 Agent（或降级为工作流）——这是成本纪律而不是失败：

拆回不是推倒重来：子任务模板、委派描述、评测集都是资产，保留下来，等任务复杂度或模型能力变化后再评估是否重启多 Agent。

人机协作团队

人类的三重角色

多 Agent 不是无人团队，人类在其中可以扮演三种角色，产品要为每种角色设计界面与时机：

HITL 的设计要点（与 Agent 产品设计深度篇 的「人在环内」一节配套）：

• 检查点式介入：LangGraph 的 interrupt 机制允许在任何节点暂停并检查、修改 Agent 状态后再继续，适合「先看再放行」的高风险步骤（LangGraph 官方文档）
• 审批流可恢复：OpenAI SDK 的审批流支持「运行暂停 → 人类批准/拒绝 → 从暂停点恢复」，拒绝结果还会反馈给模型学习（OpenAI Agents SDK — Running Agents）
• 挂起等待而非超时失败：审批可能要等几分钟甚至几小时，Agent 必须能「挂起等待」——长任务与人协作是持久化执行框架的标准场景（同上）

审批流的四种结果都要实现（LangGraph 的 interrupt 语义，LangGraph 官方文档）：

审批超时也要有策略：超时默认拒绝（安全优先）还是超时自动放行（效率优先）——取决于操作的可逆性；不可逆操作一律超时默认拒绝。

失效条件：审批点太多 → 用户疲劳、形同虚设。经验值：单任务 1-3 个真风险点；把审批设在可逆操作上是浪费注意力，把不可逆操作漏掉审批是玩火。

长期运行 Agent 的团队治理

多 Agent 系统长期运行时，产品团队要按「运维一个团队」的标准治理，而不是按「运维一个函数」：

• 值班（on-call）：Agent 挂起、失控、成本异常时谁响应；SLO 建议跟踪任务成功率、人工接管率、单任务成本三个数
• 事故响应：能暂停全部 Agent、回滚策略版本、还原 trace、撤销副作用（补偿操作或人工恢复流程）
• 权限回收：session 级授权、定时回收、人员离职/换岗自动回收——长期运行的 Agent 权限只会膨胀，不会自动收缩
• 确定性机制优先：靠提示词自觉的约束（「不要写入该目录」）会失效，零例外保证的动作要用 hooks 等确定性机制实现（Claude Code 最佳实践）
• 代理权动态调节：系统反复失败时自动回退到更保守的交互方式（每步确认、降级单 Agent），避免无人值守静默失控（Claude Code 最佳实践）
• 告警分级：P0（Agent 失控、越权、成本爆炸）→ 立即响应并暂停相关 Agent；P1（成功率跌破基线）→ 当日处理；P2（指标劣化趋势）→ 排期处理——分级写进值班手册，否则值班的人不知道该不该叫醒别人

事故复盘四问：失败在哪一个子任务？归因到哪个 Agent？trace 能否复现？防回归评测补了没有？——四问答不齐，复盘就是走形式。

反模式清单

评审多 Agent 方案时逐项打勾，命中任何一项都要先解释再立项：

总结：多 Agent 是昂贵的组织变革，不是免费的架构升级。评审时先算账、再画依赖、三定责任、四补观测、五设护栏——五步都走完，多 Agent 才有资格立项。

来源说明

本文为原创整理，产品决策结论引用以下权威来源，访问验证日期 2026-08-24：

• Anthropic — How We Built Our Multi-Agent Research System：多 Agent 实测数据（90.2%、15 倍、80% 归因）、编排模式、委派质量、终态评测
• Anthropic — Building Effective Agents：工作流先行的复杂度原则
• OpenAI Agents SDK 与 Running Agents：handoffs、审批流、max_turns 预算、tracing
• LangGraph — 官方文档：interrupt 检查点式介入、持久化执行
• Anthropic / Claude Code — Best Practices：确定性机制、代理权动态调节、验证闭环
• linux.do — 多 agent 协作，研发流水线交流！：7-Agent 流水线社区复盘
• 本站 Agent 架构与多智能体、工具调用与 MCP、LLM 成本测算：技术模式与成本方法
• 本站 Agent 产品设计深度篇：代理权、确认点、成本防护与人机协作框架（本页的上游枢纽）

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用