到目前为止，我们一直在培养一个“全栈超级天才” Agent：它既会做计划，又会写代码，还能自己跑测试。
但在人类真实的企业里，我们很少会让一个人包揽所有活儿。为什么？因为人会陷入“当局者迷”——自己写的代码，怎么看都觉得顺眼，测不出 Bug。

Agent 也是如此！如果你让同一个 Agent 写代码，再让它自己 Review（审查），它大概率会说：“完美！直接发布！”
为了打破这种幻觉和盲点，工业界引入了 多智能体协作（Multi-Agent System）。

本篇，作为卷 5（Agent 系统）的收官之作，我们将探讨如何把一群大模型组织成一个“虚拟软件公司”，让它们各司其职，甚至互相“吵架”。

---

1. 为什么需要多 Agent？单一角色的天花板

让一个大模型同时扮演产品经理、研发和测试，在工程上会遇到极其致命的瓶颈：

1. 上下文混乱（Context Confusion）
   当系统里充斥着需求文档、前端代码、后端 SQL 和测试报错日志时，这个“全栈 Agent”的注意力会严重分散，往往顾此失彼。
2. 缺乏制衡（Lack of Checks and Balances）
   没有任何机制能阻止它把一个低级错误直接合并进主分支。
3. 系统提示词（System Prompt）过载
   你不可能在一个 Prompt 里同时写上“你要像乔布斯一样懂产品”和“你要像极客一样严谨抠代码”，这会让模型人格分裂。

解法：角色分工（Role-playing）
我们实例化出三个完全独立的 Agent，赋予它们不同的系统提示词和权限：

• 产品经理 Agent：只负责写文档，只有写 Markdown 的权限。
• 研发 Agent：只负责写代码，拥有改写文件的权限，但无权合并代码。
• 测试 Agent：只负责找茬，拥有运行 npm test 的权限。

---

2. 怎么协作？靠的是“交付物契约（Artifact Contract）”

把三个 Agent 凑在一起，不是让它们在聊天框里漫无边际地“侃大山”。
AI 如果没有约束地聊天，很容易聊飞，甚至互相附和（“你说得对，咱们下班吧”）。

在工程上，多 Agent 的协作绝不是“聊天”，而是流水线式的“交接棒”。这个交接的凭证，就叫交付物契约。

一个典型的多 Agent 工作流：

1. 产品经理 Agent 收到老板的一句话需求：“加个微信登录”。
   • 它开始工作，最终产出一份结构化的 PRD.md（产品需求文档）。这是它的交付物。
2. 研发 Agent 被唤醒。它不听产品经理啰嗦，它只看那份 PRD.md。
   • 它根据文档写出代码 login.js。这是它的交付物。
3. 测试 Agent 被唤醒。它拿到 PRD.md（对比标准）和 login.js（测试对象）。
   • 它跑完测试，产出一份 Test_Report.json（报错清单）。

核心原则：Agent 之间不直接对话，只通过“读写文件/文档”来交流。这就极大地降低了沟通噪音，保证了确定性。

---

3. 冲突处理：当 Agent 们“吵起来”怎么办？

如果测试 Agent 发现代码有 Bug，它该怎么办？
它不能自己去改代码（越权），它必须把问题打回给研发 Agent。这就形成了协作中的冲突与反馈循环（Feedback Loop）。

为了防止它们俩因为一个无解的 Bug 互相踢皮球（陷入死循环），我们必须设计一个合并与仲裁策略（Merge & Arbitration Strategy）。

常见的冲突处理模式：

1. 主管仲裁模式（Hierarchical）
   • 引入一个更高的 Manager Agent（主管）。
   • 研发说代码没问题，测试说跑不通。主管介入，阅读双方的报告，做出裁决：“研发，你去改第 15 行；测试，你去更新测试用例。”
2. 最大循环次数（Max Retries）
   • 研发和测试最多只能互相打回 3 次。
   • 超过 3 次依然不通过，立刻冻结流程，并呼叫真正的人类来当裁判。
3. 少数服从多数（Voting）
   • 在高安全场景下（比如评估某段代码是否有安全漏洞），同时召唤 3 个安全专家 Agent。如果 2 个说有风险，1 个说没有，则判定为高风险打回。

---

4. 本篇产出：多角色协作模板（产品/研发/测试）

下面是一个标准的多 Agent 协作工作流配置模板。如果你使用类似 MetaGPT、CrewAI 或 Autogen 这样的多智能体框架，底层的配置逻辑几乎和这份模板一模一样：

# 虚拟软件研发团队配置 (Virtual Dev Team)

agents:
  - role: "Product_Manager"
    goal: "澄清模糊需求，拆解出可验收的业务规格。"
    backstory: "你是一个极其严谨的资深产品经理，绝不允许需求有任何模棱两可的地方。"
    tools: ["web_search", "read_historical_prds"]
    deliverable: "Requirement_Spec.md"  # 交付物契约

  - role: "Senior_Developer"
    goal: "根据产品规格编写健壮、可维护的代码。"
    backstory: "你是一个拥有 10 年经验的 Node.js 极客。你只看文档写代码，从不自己脑补需求。"
    tools: ["edit_file", "run_linter", "read_codebase"]
    deliverable: "Source_Code (Git Branch)" # 交付物契约

  - role: "QA_Engineer"
    goal: "寻找代码中的漏洞，确保代码满足产品规格。"
    backstory: "你是一个以找茬为乐的测试工程师。你对代码极其苛刻，必须用测试脚本证明它没问题。"
    tools: ["run_tests", "read_file"]
    deliverable: "Test_Report.json" # 交付物契约

workflow:
  # 定义流水线顺序与循环条件
  steps:
    - step_1: Product_Manager 产出 Requirement_Spec.md
    - step_2: Senior_Developer 阅读 Requirement_Spec.md，产出代码
    - step_3: QA_Engineer 运行测试，产出 Test_Report.json
    
  feedback_loop:
    condition: "If Test_Report.json 包含 errors"
    action: "打回 step_2，并将 Test_Report 附带给 Senior_Developer"
    max_retries: 3
    on_max_retries_exceeded: "suspend_and_alert_human" # 超过 3 次，人类介入

---

5. 卷 5 结语与复盘

至此，卷 5：Agent 系统 的全部核心内容已完结。

回顾这 7 篇文章，我们完成了一次从“聊天机器人”到“自动化数字员工”的跨越：

1. Agent 核心：我们学习了 ReAct 循环，懂得了“停止条件”是防止破产的关键。
2. 拆解与记忆：我们用 Planner 拆解了复杂任务，用三层记忆和上下文折叠治好了 Agent 的失忆症。
3. 自检与并发：我们抛弃了玄学的“脑补”，引入了可执行的 Checklist，并用队列和幂等解决了并发崩溃。
4. 长任务与协作：我们用事件日志实现了断点续跑，最后用多 Agent 协作打破了单一角色的能力天花板。

下一步去哪儿？
现在，你的系统不仅懂知识（卷 4），还会自动干活（卷 5）。它看起来已经可以替代一个外包团队了。
但是，老板问了你一个极其尖锐的问题：“你怎么证明你这套 Agent 系统，比我雇 5 个应届生还要靠谱？它改代码的成功率到底是多少？出了线上事故谁背锅？”

为了回答这些问题，接下来的 卷 6：评测、可观测、成本与上线，我们将进入整个教程中最具工业级价值、也是把玄学变成工程的终极篇章！