什么时候需要多个 Agent
并行加速、角色分工、风险隔离，三种真实场景
本页解决的问题
先给结论「什么时候需要多个 Agent」要解决的关键问题是什么？
并行加速、角色分工、风险隔离，三种真实场景
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
用户要求整理今日 AI 新闻。一个 Agent 要依次搜索 5 个网站，总耗时 25 秒。
改成 5 个子 Agent 同时去搜，每个负责一个来源，最后主 Agent 汇总，总耗时 5 秒。
关键：这些搜索互不干扰，天然适合并行。
让同一个 Agent 写完代码再审自己的代码，它很难发现自己的错误，就像自己检查自己的作文。
分成两个 Agent：Writer 写代码，Reviewer 审代码。Reviewer 不知道 Writer 的思考过程，只看最终代码，更容易发现问题。
关键：角色隔离让审查真正有效。
主 Agent 在整理一份 50 页的报告。其中需要解析几个 PDF 附件。
如果 PDF 解析出错（格式损坏、超时），直接在主 Agent 里做会导致整个任务崩溃。
分出子 Agent 单独处理 PDF：成功了就汇报结果，失败了就报告「这个文件有问题」，主 Agent 继续工作不受影响。
关键：子任务的失败被隔离了。
一个任务拆成多个子 Agent 并行执行
分发任务
① 一个 Agent 真的做不到吗？（很多时候只是 Prompt 没写好）
② 增加的复杂度值得吗？（多 Agent 意味着更多协调成本、更多出错可能）
③ 有没有更简单的方案？（比如用工具并行调用就能解决，不必真的分 Agent）
「三种真实场景」里的算法代价曲线
「并行加速、角色分工、风险隔离，三种真实场景」真正训练的不是背诵步骤，而是识别重复工作：输入变大时，程序到底多做了多少次比较、移动或递归。
先找重复工作，再谈快慢
「并行加速、角色分工、风险隔离，三种真实场景」可以拆成输入规模、每轮做什么、以及是否能缩小下一轮范围三个问题。Big-O 是描述增长趋势的语言，不是对每台机器的精确计时；常数、内存和真实数据分布也会影响最终结果。
别把理论最优当成无条件最优
面对 AI 写出的算法，先用小输入手算一遍，再用逐渐放大的数据做基准测试。这样才能把「并行加速、角色分工、风险隔离，三种真实场景」从一句结论变成可检查的性能判断。
从「三种真实场景」走到「并行加速的流程示意」
「三种真实场景」先把问题落在「⚡ 并行加速 同时搜索 5 个来源，比一个一个搜快 5 倍 点击展开案例 真实案例：新闻简报 用户要求整理今日 AI 新闻。一个 Agent 要依次搜索 5 个网站，总耗时 25 秒。 改成 5 个子 Agent 同时去搜，每个负责一个来源，最后主 Agent 汇总，总耗时 5 秒。 关键： 这些搜索互不干扰，天然适合并行。 角色分工 一个写代码，一个审代码，互相制衡 点击展开案例 真实案例：代码审查 让同一个 Ag…」上；到了「并行加速的流程示意」，讨论继续推进到「一个任务拆成多个子 Agent 并行执行 主 Agent 分发任务 → 同时执行 搜索 A 搜索 B 搜索 C → 汇总结果 判断标准： 在你加第二个 Agent 之前，先问自己： ① 一个 Agent 真的做不到吗？（很多时候只是 Prompt 没写好） ② 增加的复杂度值得吗？（多 Agent 意味着更多协调成本、更多出错可能） ③ 有没有更简单的方案？（比如用工具并行调用就能解决，不必真的分 Agent） 不是…」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
算法题换成真实任务后，先找出重复工作，再问输入规模如何变化，最后用一个小基准验证理论判断。这样不会把复杂度记成脱离场景的标签。
- 「三种真实场景」：⚡ 并行加速 同时搜索 5 个来源，比一个一个搜快 5 倍 点击展开案例 真实案例：新闻简报 用户要求整理今日 AI 新闻。一个 Agent 要依次搜索 5 个网站，总耗时 25 秒。 改成 5 个子 Agent 同时去搜，每个负责一个来源，最后主 Agent 汇总，总耗时 5 秒。 关键： 这些搜索互不干扰，天然适合并行。 角色分工 一个写代码，一个审代码，互相制衡 点击展开案例 真实案例：代码审查 让同一个 Ag…
- 「并行加速的流程示意」：一个任务拆成多个子 Agent 并行执行 主 Agent 分发任务 → 同时执行 搜索 A 搜索 B 搜索 C → 汇总结果 判断标准： 在你加第二个 Agent 之前，先问自己： ① 一个 Agent 真的做不到吗？（很多时候只是 Prompt 没写好） ② 增加的复杂度值得吗？（多 Agent 意味着更多协调成本、更多出错可能） ③ 有没有更简单的方案？（比如用工具并行调用就能解决，不必真的分 Agent） 不是…
最后的「最后把结论落到实践」把讨论落到「并行加速、角色分工、风险隔离，三种真实场景」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。