专家分工
不同 Agent 负责不同领域，减少一个 Agent 什么都做导致的上下文混乱。
面向程序员 · Agent 协作架构课
多 Agent 协作
单 Agent 适合边界清楚的任务。复杂企业任务常常涉及需求澄清、资料检索、系统分析、内容撰写、质量评审和安全审批。多 Agent 协作的价值，是把不同职责拆给不同专家，再用清晰的契约和主控编排合成一个结果。
不是越多越好
只有职责、工具、权限或评审视角不同，拆分才有价值。
主控要明确
需要一个编排者负责路由、状态、冲突和最终交付。
契约要稳定
每个 Agent 的输入、输出、证据、错误和边界要写清楚。
结果要可评审
多 Agent 增加能力，也增加成本、延迟和责任不清的风险。
multi-agent orchestration
supervisor / handoff
需求澄清 Agent
补齐目标、范围、用户和约束。
→
主控 Agent
分派任务、合并状态、控制交付。
系统分析 Agent
对齐接口、数据、权限和影响面。
→
评审 Agent
检查完整性、风险和可验收性。
contract
输入输出契约
输入输出契约
state
共享任务状态
共享任务状态
review
冲突仲裁
冲突仲裁
01 · 先给定义
多 Agent 协作是把复杂任务拆给多个专家 Agent
每个 Agent 负责一类明确任务：有人澄清需求，有人检索资料，有人分析系统，有人撰写产物，有人评审质量。协作的重点不是数量，而是边界。
主控编排
由主控 Agent 或工作流引擎决定谁先做、谁后做、结果怎么合并。
输入输出契约
每个 Agent 必须有稳定输入、输出、错误、证据和质量标准。
评审仲裁
不同 Agent 结论冲突时，要有规则决定谁复核、谁仲裁、怎么记录依据。
一句话面试版
可直接背
多 Agent 协作是把复杂任务按专业、工具、权限或流程阶段拆给不同 Agent，再由主控编排它们的输入输出、共享状态、冲突处理和最终交付。
02 · 为什么协作
单 Agent 简单，但复杂任务容易职责过重
单 Agent 把检索、分析、执行、撰写、评审都放在一个上下文里，容易忘步骤、混证据、误用工具。多 Agent 可以把复杂度拆开。
适合流程短、风险低、工具少
例如简单问答、单文档总结、固定模板生成。优点是链路短、成本低、调试简单。
适合流程长、角色多、质量要求高
例如生成企业 PRD、复杂排障、安全审计、竞品调研。每个环节需要不同知识、工具或评审视角。
多 Agent 的真实价值
不是炫技
- 1降低上下文干扰：每个专家只看自己需要的材料。
- 2隔离权限风险：敏感工具只开放给特定 Agent。
- 3提高产物质量：撰写和评审分开，减少自说自话。
- 4便于调试复盘：每个环节的输入输出都能单独检查。
03 · 拆分判断
只有边界真的不同，才值得拆成多个 Agent
多 Agent 会带来协调成本、延迟和调试难度。拆分前先问：职责是否不同、工具是否不同、权限是否不同、质量检查是否独立。
应该拆
- 1专业不同：产品、研发、测试、安全、法务视角不同。
- 2工具不同：检索 Agent 读知识库，执行 Agent 调业务 API。
- 3权限不同：某些 Agent 能看敏感资料，其他 Agent 不能看。
- 4质量独立：需要评审 Agent 从另一个角度检查结果。
不该拆
- 1只是为了听起来高级，把一个简单流程拆成很多角色。
- 2各 Agent 输入输出没有边界，最后还要人工重新整理。
- 3任务本身很短，一个 Agent 加检查清单就能完成。
- 4没有主控，多个 Agent 互相聊天但没人负责最终交付。
04 · 协作模式
常见模式有主控编排、接力交接、专家调用和评审仲裁
不同模式适合不同任务。入门时先掌握这四种，基本能覆盖大多数企业场景。
主控编排
主控 Agent 负责分派任务、汇总结果、控制流程和最终交付。
接力交接
当前 Agent 判断自己不适合继续时，把控制权交给更合适的 Agent。
专家当工具
主控 Agent 调用专家 Agent 获取结果，但控制权仍在主控手里。
评审仲裁
评审 Agent 检查产物质量、指出冲突、给出评分和修订建议。
主控编排
适合 PRD、排障、调研这类多阶段任务，由主控维护全局状态。
→
专家调用
主控需要系统影响面时，调用系统分析 Agent 输出结构化报告。
接力交接
客服 Agent 发现需要退款审批，把控制权交给售后审批 Agent。
→
评审仲裁
撰写 Agent 输出 PRD 后，评审 Agent 按检查表打分和改写。
05 · 主控编排
多 Agent 系统必须有人管全局
主控 Agent 不一定自己做所有事情，但它要知道目标、状态、谁负责什么、哪些结果可信、什么时候交付。
1
接收目标
识别用户要交付什么，以及质量标准是什么。
2
拆分任务
判断需要哪些专家 Agent，以及先后顺序。
3
分派执行
把必要上下文传给对应 Agent，避免过度共享。
4
合并结果
汇总证据、冲突、风险、产物和待确认问题。
5
交付结果
输出最终产物，并说明依据、假设和风险。
supervisor routing
伪代码
supervisor(goal, state):
if missing_requirement_context(state):
return call("requirement_clarifier", state)
if missing_enterprise_evidence(state):
return call("retrieval_agent", state)
if system_impact_unknown(state):
return call("system_analyst", state)
draft = call("prd_writer", state)
review = call("prd_reviewer", draft)
return merge_and_deliver(draft, review)06 · 交接方式
Handoff 和 Agent as Tool 的区别在控制权
这两个概念很常被问。面试时可以用“转接人工客服”和“请专家给意见”来区分。
把控制权交出去
当前 Agent 判断另一个 Agent 更适合接管，例如客服 Agent 把退款审批交给售后 Agent。交接后，新 Agent 负责继续对话和执行。
主控调用专家能力
主控 Agent 把某个子任务交给专家 Agent，拿到结构化结果后继续自己编排。专家像一个高级工具，不接管全局。
选择建议
简单判断
- 1需要换负责人继续处理用户任务，用 Handoff。
- 2只需要专家给一份分析结果，用 Agent as Tool。
- 3高风险动作交接时，要显式传递权限、原因、状态和待确认事项。
07 · 输入输出契约
多 Agent 协作成败，取决于契约是否清楚
没有契约，Agent 之间会互相猜。契约要定义输入、输出、证据、错误、质量标准和禁止事项。
每个 Agent 的契约字段
必备
| 字段 | 说明 |
|---|---|
role |
负责什么，不负责什么。 |
input |
需要哪些上下文、资料和参数。 |
output |
必须返回什么结构和字段。 |
evidence |
结论需要哪些来源和引用。 |
errors |
无法完成时如何返回阻塞原因。 |
qualityBar |
怎样算结果可用。 |
agent contract
JSON 示例
{
"agent": "system_analyst",
"role": "分析需求对现有系统、接口、数据和权限的影响",
"input": {
"requirement": "string",
"evidenceDocs": ["docId"],
"knownConstraints": ["string"]
},
"output": {
"impactedModules": ["string"],
"apiChanges": ["string"],
"dataFields": ["string"],
"permissionRisks": ["string"],
"openQuestions": ["string"]
},
"mustNot": ["凭空编接口", "绕过权限规则"]
}08 · 共享状态
多 Agent 不能共享一团乱上下文
共享状态不是把所有对话都扔给每个 Agent。更好的做法是维护一个结构化任务状态，每个 Agent 只读取自己需要的部分。
统一目标
所有 Agent 都要知道最终交付物和验收标准，避免各做各的。
证据仓库
检索 Agent 产出的资料摘要和 sourceId 进入共享证据区。
中间产物
PRD 草稿、影响面分析、评审报告都作为可追踪产物保存。
权限过滤
敏感资料只给有权限的 Agent，不能默认全员共享。
shared task state
结构示例
{
"goal": "生成商品导入失败明细 PRD",
"status": "reviewing",
"evidence": [
{ "sourceId": "product-import-prd-v2", "summary": "现有导入流程" },
{ "sourceId": "api-import-task-result", "summary": "任务结果接口字段" }
],
"artifacts": {
"systemImpact": "artifact-system-analysis-v1",
"prdDraft": "artifact-prd-v2",
"review": "artifact-review-v1"
},
"openQuestions": ["行级错误明细是否需要支持下载？"],
"decisions": ["本期只支持运营后台查看失败明细"]
}09 · 评审和仲裁
多个 Agent 的结论可能冲突，必须有仲裁规则
多 Agent 不是投票游戏。系统要知道哪些结论来自证据，哪些只是建议；冲突时按证据、权限和领域优先级处理。
有来源的结论优先
引用现有接口文档和 PRD 的结论，比无来源的推测更可信。
谁负责谁说了算
接口影响以系统分析 Agent 为准，文案结构以撰写 Agent 为准，风险以评审 Agent 为准。
高风险冲突升级
涉及权限、合规、成本、排期的重大冲突，要标记给人确认。
评审 Agent 不只是挑错
质量门
评审 Agent 应该输出评分、缺失项、证据问题、风险等级、修改建议和是否允许交付。它不应重写一切，否则会和撰写 Agent 职责混乱。
10 · 权限和安全
多 Agent 增加了权限面，也增加了泄露和误操作风险
每个 Agent 可能有不同工具和资料权限。不要因为它们都属于同一个系统，就默认可以互相传递全部上下文。
只给必要能力
检索 Agent 不需要写数据库，撰写 Agent 不需要执行退款工具。
敏感资料不乱传
只传摘要、字段和 sourceId，避免把完整敏感文档扩散给所有 Agent。
高风险工具要审批
任何写操作、外发、删除、退款、批量修改都要确认和审计。
每个角色可追踪
记录谁调用了谁、传了什么摘要、用了什么工具、产生了什么结果。
安全设计底线
必须讲清
多 Agent 里的每个 Agent 都要当成独立执行单元治理：单独权限、单独工具白名单、单独日志、单独失败处理。不要让某个 Agent 通过另一个 Agent 间接绕过权限。
11 · 常见坑
多 Agent 最容易输在协调，而不是输在模型能力
很多多 Agent 系统看起来很热闹，实际产出反而更差。原因通常是边界、契约、状态和评审没有设计好。
角色多但价值少
拆出来的 Agent 没有独立工具、知识或判断标准，只会增加延迟。
结果无法合并
每个 Agent 输出格式不同，主控只能靠猜测拼接。
上下文越传越乱
无关资料和过期结论被反复传播，后续 Agent 继续放大错误。
没有最终责任方
每个 Agent 都完成了自己的部分，但最终交付物没人兜底。
12 · 评测指标
评测多 Agent，要同时看协作质量和最终质量
只看最终回答不够。还要看分工是否合理、交接是否清楚、冲突是否处理、成本是否可接受。
任务是否被分给了正确 Agent，是否存在重复劳动。
每个 Agent 输出是否符合 schema，证据和错误是否完整。
不同 Agent 结论冲突时，是否能解释和仲裁。
相比单 Agent，质量提升是否值得额外延迟和调用成本。
13 · 企业案例
用多 Agent 生成商品导入失败明细 PRD
这个案例适合面试讲解，因为它天然需要产品、资料、系统、撰写和评审多个视角。
1
主控 Agent
接收目标，判断需要澄清需求、检索资料、系统分析、PRD 撰写和质量评审。
2
需求澄清 Agent
补齐用户角色、导入方式、失败明细展示范围、下载和重新导入边界。
3
资料检索 Agent
查历史 PRD、接口文档、错误码表、权限规范，并输出 sourceId 和摘要。
4
系统分析 Agent
分析需要新增哪些字段、接口、数据表、权限和异常处理。
5
撰写和评审 Agent
撰写 Agent 输出 PRD 草稿，评审 Agent 按完整性、可实现性、风险和验收标准打分。
PRD multi-agent team
分工表
Supervisor:
owns goal, state, routing, final delivery
Requirement Clarifier:
output: scope, users, open questions
Retrieval Agent:
output: evidence summaries with sourceId
System Analyst:
output: impacted modules, API changes, data fields, permission risks
PRD Writer:
output: structured PRD draft
Reviewer:
output: scorecard, missing items, risk list, go/no-go decision
这个案例的关键点
面试友好
多 Agent 的价值不是让几个模型互相讨论，而是把 PRD 生成拆成可复盘的专业环节。每个 Agent 都有明确输入输出，主控 Agent 负责合并证据、处理冲突并交付最终 PRD。
14 · 面试问答
回答多 Agent，要体现克制和工程边界
面试官往往不喜欢“多开几个 Agent 就好了”的回答。要讲清什么时候拆、怎么编排、怎么评测和怎么控风险。
Q1：什么是多 Agent 协作？
A：多 Agent 协作是把复杂任务按专业、工具、权限或流程阶段拆给不同 Agent，再由主控 Agent 或工作流引擎编排它们的输入输出、共享状态、冲突处理和最终交付。
Q2：什么时候需要多 Agent？
A：当任务涉及明显不同的专业视角、工具权限、流程阶段或独立评审时适合拆分。比如 PRD 生成可以拆成需求澄清、资料检索、系统分析、撰写和评审。如果任务很简单，用单 Agent 更好。
Q3：Handoff 和 Agent as Tool 有什么区别？
A：Handoff 是把控制权交给另一个 Agent，让它继续处理任务；Agent as Tool 是主控 Agent 调用专家 Agent 获取结果，但全局控制权仍在主控手里。
Q4：多 Agent 最大的工程难点是什么？
A：难点在编排和边界，包括任务路由、输入输出契约、共享状态、权限隔离、冲突仲裁、日志审计和成本控制。Agent 数量越多，协调成本越高。
Q5：怎么评估多 Agent 是否值得？
A：要和单 Agent 基线比较，看最终质量是否提升，错误是否减少，是否更容易复盘，以及额外的延迟和成本是否可接受。如果只是复杂度变高、质量没有提升，就不值得。
15 · 练习和速查
练习目标：能画出一张多 Agent 架构图
学完这一课，要能把一个复杂任务拆成角色、契约、共享状态和最终交付链路。
客服质检多 Agent
拆成转写 Agent、规则检查 Agent、情绪风险 Agent、评审 Agent，并写出输出契约。
排障多 Agent
拆成日志分析、监控分析、发布变更分析、根因评审四个 Agent，说明谁做仲裁。
PRD 多 Agent
为 PRD 团队写一张分工表：角色、输入、输出、证据、错误和质量标准。
一页速查卡
复习
- 1多 Agent 是按专业、工具、权限或流程阶段拆分复杂任务。
- 2不要为拆而拆；单 Agent 能稳定完成，就先别复杂化。
- 3常见模式：Supervisor、Handoff、Agent as Tool、Reviewer。
- 4协作关键：主控编排、输入输出契约、共享状态、冲突仲裁。
- 5企业落地要控制权限、上下文隔离、日志审计、成本和延迟。