多 Agent 与项目
Day 26 - Multi-Agent Collaboration Basics
今日目标
能设计 Planner/Research/Writer/Reviewer 角色分工，判断什么时候需要多 Agent。
学习安排
| 时间 | 模块 | 做什么 |
|---|---|---|
| 0-10 分钟 | 核心概念 | 通读当天术语表，圈出 3 个你最想在工作里用上的概念。 |
| 10-25 分钟 | 阅读输入 | 精读当天章节重点，只抓问题、思路、结论。 |
| 25-45 分钟 | 实践任务 | 动手完成输出模板，必须产出一份可复用产物。 |
| 45-55 分钟 | 追问与反思 | 回答追问练习，标记卡住的概念。 |
| 55-60 分钟 | 复盘与作业 | 整理自检清单，定下明天要复习的一点。 |
核心概念
| 术语 | 中文解释 | 应用场景 |
|---|---|---|
| multi-agent | 由多个 Agent 组成、通过分工与协作完成单个 Agent 难以完成任务的多 Agent 系统 | 任务可拆分、需要多领域知识或需要并行调研时 |
| role division | 角色分工，把整体任务按职责拆给不同 Agent，每个 Agent 只负责一段明确的工作 | 分析任务拆成规划、检索、写作、审查四段 |
| planner | 负责拆解任务、制定执行计划的 Agent，输出结构化步骤和负责人 | 把模糊问题变成可执行的分析路径 |
| executor | 按计划执行具体动作、调用工具的 Agent，如检索资料、查日志、查指标 | Research Agent 执行检索与数据采集 |
| reviewer | 检查其他 Agent 产出的 Agent，核对事实与格式，返回修改意见 | 报告交付前的事实与格式把关 |
| context sharing | 上下文共享，多个 Agent 共用同一份上下文，保证信息一致 | Planner 把任务约束传给下游所有 Agent |
| context isolation | 上下文隔离，每个 Agent 只看自己需要的上下文，减少噪声与成本 | Research Agent 不读 Writer 的写作风格说明 |
| orchestration | 编排层，控制多 Agent 的启动顺序、消息传递、结果汇总与错误处理 | 流水线按 Planner 到 Reviewer 的顺序驱动 |
| when-not-to-use-multi-agent | 判断何时不该用多 Agent：任务不可拆分、单 Agent 已够用、协作成本大于收益时 | 简单问答任务保持单 Agent |
| coordination | 协作机制，Agent 之间的通信、任务交接与结果合并方式 | 定义 Research 的产出如何交给 Writer |
| group intelligence | 群体智能，通过多 Agent 分工与交互，整体涌现出超过单个 Agent 的能力 | 多路并行调研后汇总成完整结论 |
阅读重点
- 对应章节：第 10 章「多 Agent 协作」：协作框架、上下文共享与隔离、角色分工、群体智能。
- 关注点：
- 多 Agent 解决什么问题：单 Agent 上下文有限、职责混杂、难以并行。
- 协作框架有哪几种形态：串行流水线、层级委派、群组并行，各自适合什么任务。
- 上下文共享与隔离怎么取舍：共享保一致，隔离降噪声与成本。
- 什么时候不该用多 Agent：任务不可拆、单 Agent 已够、协作成本过高时保持简单。
- 补充材料：
- LangGraph 官方文档中关于多 Agent 编排与状态传递的部分。
- OpenAI Agents SDK 文档中关于 Handoff（任务交接）与多 Agent 工作流的部分。
理解检查
- 多 Agent 解决什么问题？什么任务不适合多 Agent？
- 多 Agent 会引入哪些额外复杂度？成本具体体现在哪里？
- 上下文共享和隔离如何取舍？举一个必须共享、一个必须隔离的例子。
- Planner 和 Executor 的职责如何划分？谁来拆任务，谁来执行？
实践任务
背景：QA 团队想用多 Agent 自动产出「技术问题分析报告」。请把「开启 WAF 后 Nginx CPU 升高」这个真实场景设计成四 Agent 协作流程。
- 第 1 步：选一个你最近处理过的技术问题作为协作目标。
- 第 2 步：用下面的输出模板，为 Planner、Research、Writer、Reviewer 四个 Agent 分别填写输入、输出、工具、上下文边界、失败处理。
- 第 3 步：检查三个问题：任务是否真的可拆分；协作成本是否可接受；单 Agent 是否更简单。
- 第 4 步：写一句结论，说明这个场景该用多 Agent 还是单 Agent，理由是什么。
输出模板
系统目标：[这个多 Agent 系统要完成什么任务]
触发条件：[什么时候启动协作]
Agent 1：Planner
- 输入：[用户问题或原始任务]
- 输出：[任务拆解清单：步骤、负责人、先后顺序]
- 工具：[规划时需要的工具]
- 上下文边界：[能看到什么，看不到什么]
- 失败处理：[拆解失败怎么办，如追问用户补充信息]
Agent 2：Research
- 输入：[Planner 给出的检索步骤]
- 输出：[检索到的资料与数据，附来源]
- 工具：[知识库检索、日志查询、指标查询]
- 上下文边界：[只做检索，不写结论]
- 失败处理：[检索为空时标注缺口并继续]
Agent 3：Writer
- 输入：[Research 整理好的资料]
- 输出：[Markdown 报告草稿]
- 工具：[报告模板、格式化工具]
- 上下文边界：[只接收整理好的资料，不自行查数据]
- 失败处理：[资料不足时在报告中标注待验证]
Agent 4：Reviewer
- 输入：[Writer 的报告草稿]
- 输出：[审查意见：事实错误、格式问题、缺失项]
- 工具：[事实核对工具、格式检查工具]
- 上下文边界：[只看报告与对应证据，不看原始日志]
- 失败处理：[问题严重时退回 Writer 修改，最多 [n] 轮]示范输出
系统目标：分析开启 WAF 后 Nginx CPU 升高的可能原因，输出带验证步骤的 Markdown 报告
触发条件：用户提交技术问题
Agent 1：Planner
- 输入：开启 WAF 后 Nginx CPU 升高，请帮我分析可能原因，并给出验证步骤
- 输出：分析路径，包括确认时间窗口、对比 WAF 开关前后指标、检查 access log、检查 upstream 响应、汇总假设
- 工具：任务模板库
- 上下文边界：只看到用户问题与约束，不看日志数据
- 失败处理：信息不足时列出需要用户补充的字段
Agent 2：Research
- 输入：Planner 的分析路径
- 输出：WAF 开关前后的 CPU 指标、Nginx access log 摘要、知识库相关文章
- 工具：query_metrics、query_logs、知识库检索
- 上下文边界：只看到检索步骤，不参与报告写作
- 失败处理：某段时间日志缺失时标注缺口，继续检索其他数据
Agent 3：Writer
- 输入：Research 的资料与数据
- 输出：分析报告草稿，含假设、证据、验证步骤
- 工具：报告模板
- 上下文边界：只接收整理好的资料
- 失败处理：证据不足的结论统一标注为待验证
Agent 4：Reviewer
- 输入：Writer 的报告草稿
- 输出：审查意见，例如 WAF 规则命中数未引数据、验证步骤缺回滚方案
- 工具：事实核对工具、Markdown 格式检查
- 上下文边界：只看报告与对应证据
- 失败处理：问题严重时退回 Writer 修改，最多 2 轮追问练习
- 上下文共享和隔离如何取舍？什么信息必须共享，什么信息必须隔离？
- Planner 和 Executor 的职责如何划分？边界不清会出现什么问题？
- Reviewer Agent 是否真的能提升质量？什么情况下 Review 会变成重复劳动？
- 如果只能保留两个 Agent，你会保留哪两个，为什么？
常见误区
- 多 Agent 不一定比单 Agent 好：多 Agent 增加协作成本、上下文同步成本和调试难度，任务不可拆分时不要硬上。
- 把角色当成聊天人设而不是职责边界：没有定义输入输出，Agent 之间会互相抢活或互相等待。
- 让所有 Agent 共享一个巨大的上下文：噪声与成本同时上升，上下文隔离失效。
- Reviewer 与 Writer 用同一个模型同一套指令，等于自己检查自己，没有独立证据时提升有限。
进阶扩展
- 多 Agent 调度器：真实系统里由编排层决定并发数、超时、重试与资源配额，而不是简单串行调用。
- 群体智能：多 Agent 通过竞争与投票涌现决策，但需要评估与护栏控制成本和出错风险。
- 上线监控：每个 Agent 的轨迹、消息与延迟都要可观测，否则多 Agent 的问题难以定位。
今日作业
- 完成四 Agent 协作设计文档，四个 Agent 的输入、输出、工具、上下文边界、失败处理都要写全。
- 找出一个你手上「看起来可以多 Agent 化」的任务，写三条不用多 Agent 的理由。
- 把 Day 20 的单 Agent 工具 Demo 拆成 2 个 Agent，对比复杂度的变化。
- 记录一个你在分工上拿不准的点，明天用消息格式设计来验证它。