AI Coding 别急着给 AI 配 多 个 Agent：先判断你的问题值不值得并行

某天下午，交付研发在问题反馈群里贴出一张接口耗时的截图。问题不算紧急，也没有谁要立刻救火。负责这个服务的同事只说了一句：“最近偶尔慢一下，能不能先看看是不是哪条调用链绕远了？” 有人顺手把仓库和几段日志交给代码 Agent。十来分钟后，它列出三个可疑位置，还给出一版修复建议。群里很快有了新提议：既然一个 Agent 看得不够全，干脆再开几个，分别查依赖、补测试、做安全审阅。听上去合理，甚至很像把一个人的工作拆给一个小团队。 可真正做过复杂项目的人会有一点犹豫：大家查的到底是不是同一件事？改动会不会撞在一起？那些看上去都说得通的结论，谁负责证明它们是对的？多开几个 Agent，也许能更快，但也可能只是更快地把同一份误解扩散开。 这就是本文要讨论的问题：编码任务何时该让单 Agent 深入推进，何时值得拆成并行工作单元？判断依据不是模型品牌或并发数，而是依赖关系、共享状态与可验证性。 ## 一、先把热闹放一边：多 Agent 不是单 Agent 的升级版 把多 Agent 理解成“一个 Agent 不够聪明，所以多开几个”，从起点上就偏了。 单 Agent 和多 Agent 的区别，不是智力等级，而是**控制流与协作成本的选择**。单 Agent 擅长把一个连续问题从头走到尾：它能保留因果链，持续根据新观察修正自己的理解，也不需要把中间状态翻译成别人看得懂的交接材料。多 Agent 擅长把一个问题拆成多个边界清晰、依赖较弱、可独立验收的工作单元，然后并行推进。 这和人类研发没有本质不同。一个工程师排查一条复杂请求链路，往往比四个人各自读四分之一日志再互相转述更有效；但当你需要同时盘点模块依赖、跑安全扫描、补测试矩阵、评估三种迁移方案时，让同一个人串行做完，又会让等待时间和上下文切换成为瓶颈。 所以，正确的问题不是： > 我能不能多开几个 Agent？ 而是： > 这个任务里，哪些部分可以独立地产生证据，而不需要依赖其他部分尚未完成的判断？ 注意关键词是“证据”，不是“回答”。一个 Agent 给出一段分析，只是一个候选观点；它跑出一组测试、找到一条可复现调用链、生成一个可审阅的 diff，才是能被后续环节消费的工程证据。 Claude Code 的官方说明很能说明这一点：dynamic workflows 的典型场景不是随便把任何任务切碎，而是全仓库排查、性能审计和安全审计。这类任务天然可以把搜索空间切分，并让独立验证过滤误报。与此同时，官方也明确提醒它会消耗显著更多 Token。并发不是免费午餐，它只是把等待时间、协调成本和模型成本重新分配。 先用一张图建立一个简单直觉。真正的分界线，不是任务“大不大”，而是任务能否在不丢失关键因果关系的前提下被切开。  ## 二、单 Agent 真正的边界，不是“上下文短”这么简单 讨论多 Agent 时，最常被提到的理由是“单 Agent 上下文会迷失”。这个判断有一半对，一半太粗糙。 长上下文确实解决不了所有问题。代码库越大，Agent 越容易遇到三种失真：第一，它找到了很多相关文件，却无法分辨哪一条调用链才是当前 bug 的根因；第二，它把很久以前的设计约束和当前实现混在一起；第三，它为了把信息塞回上下文，把关键细节压缩成摘要，随后又在摘要里丢掉了边界条件。 但这不等于“多 Agent 自动解决上下文问题”。如果每个子 Agent 只拿到被裁剪过的二手摘要，问题反而更糟。一个人读过原始日志，另一个人只读到“支付状态异常”，第三个人再根据第二个人的总结写修复建议，信息会在交接中不断损耗。多 Agent 系统最危险的失败模式，不是某个 Agent 明显犯错，而是所有 Agent 都基于同一个不完整事实集做出了看似合理的结论。 因此，单 Agent 的第一条结构性边界应当表述为： > **当一个任务的有效上下文不能再由单一工作流稳定管理，并且这些上下文可以被划分为边界明确的证据集合时，才值得考虑拆分。** 例如，做一次依赖升级前的影响分析，可以让不同 Agent 分别盘点运行时依赖、构建依赖、测试依赖和已知兼容性风险。每个 Agent 都直接读取原始 `package-lock.json`、构建脚本和代码引用，而不是彼此转述。最终交给主 Agent 的不是四段散文，而是四份结构化清单：受影响文件、风险等级、复现命令、尚未确认的假设。 第二条边界是“既当运动员又当裁判”。单 Agent 写完代码后再自己检查，很容易出现确认偏差。它已经相信某个方向是对的，于是审阅时更倾向于寻找支持它的线索，而不是主动证伪。这个问题在模型上表现得尤其明显：同一个上下文、同一种提示、同一份错误理解，会在“实现”和“自检”两个阶段重复出现。 不过，给它再配一个“评审 Agent”也不是充分条件。两个 Agent 如果读的是同一份提示、使用相同模型、没有测试输出和运行时证据，往往只是两位风格不同的评论员。真正降低相关性的方法是改变评判依据：让测试、静态检查、SAST、类型系统、基准测试和人工业务验收成为裁判；让评审 Agent 只负责解释失败、寻找遗漏和提出反例。 第三条边界才是工程拆解。单 Agent 可以规划，但它很难天然拥有“文件所有权、变更冲突、发布窗口、回滚策略”这些研发流程里的约束。它会倾向于把问题当成一段连续推理，而不是一组有依赖、有负责人、有验收门槛的工作包。多 Agent 的意义，正是在这里把“谁做什么、何时交付什么、谁有权合并”显式化。 ## 三、并行的最小单位不是 Agent，而是可验收的 Work Unit 很多团队一上来就讨论角色：要不要一个架构师 Agent、一个测试 Agent、一个安全 Agent、一个 Review Agent？角色当然有用，但它不是第一个问题。第一个问题应该是：**什么叫一个能被独立执行和验收的 Work Unit？** 一个合格的 Work Unit 至少要写清五件事： - 目标：它到底要减少什么不确定性，或完成什么可观察的改动。 - 输入：它能读取哪些原始文件、日志、文档和工具结果。 - 边界：哪些文件、分支、环境或权限不属于它。 - 验收：命令、测试、扫描规则或人工问题是什么。 - 交付物：它最终提交的是 diff、测试报告、风险清单，还是决策建议。 这五项里最容易被跳过的是验收。没有验收条件的拆解，只是把一个大 prompt 改成几个小 prompt；没有交付物格式的协作，只会把主 Agent 的上下文变成会议纪要垃圾场。 以“给支付服务增加审计日志”为例，下面三种拆法看起来相似，效果却完全不同。 第一种是糟糕拆法：A Agent 研究怎么改，B Agent 也研究怎么改，C Agent 写代码，D Agent 看看有没有问题。每个人都能碰同一批文件，最后主 Agent 收到四份重叠建议。这里没有边界，也没有减少任何实际依赖。 第二种是可用拆法：一个 Agent 只绘制当前支付路径并标出状态变更点；一个 Agent 只盘点现有日志字段、脱敏规则和留存约束；一个 Agent 只为既有路径补充失败用例；实现 Agent 在独立 worktree 中完成最小改动。前三个 Agent 都是只读的，输出各自可复核的事实；实现 Agent 以这些事实作为约束，而不是把它们当作“灵感”。 第三种是更成熟的拆法：在上述基础上，引入集成者。集成者不重新发明实现方案，它负责检查四件事：输入证据是否足够、变更是否越界、自动验证是否全绿、是否触发人工审批。此时系统才开始像一个研发小队，而不是一群聊天机器人。  这里有一个特别实用的原则：**并发数应该由可独立验收的 Work Unit 数量决定，而不是由账户允许的子 Agent 上限决定。** GitHub Copilot CLI 的 `/fleet` 文档也是同样的逻辑。它强调主 Agent 会先判断任务能否拆成彼此依赖较少的子任务；并发适用于多个独立步骤，而本质上串行的任务不一定能获得收益。把这个原则带回团队，就能避免一种常见浪费：为了“用上多 Agent”而把一个需要连续推理的 bug 硬切成十几块。 ## 四、哪些单 Agent 问题，真的值得并行 现在给出一份更具体的清单。它不是“多 Agent 万能场景表”，而是判断任务结构的起点。 第一类，**大范围、只读、可分片的发现任务**。例如一次安全审计、废弃 API 搜索、许可证盘点、迁移影响分析、全仓库死代码候选扫描。它们的共同点是：每个 Agent 可以负责明确的目录、服务或规则集合；多数工作不修改源代码；最后可以用统一格式汇总发现。Claude Code 官方把代码库级 bug hunt 和安全审计作为动态工作流场景，正是因为这类问题的搜索空间天然可以并行，而每个发现还需要独立验证。 第二类，**相互独立的测试与证伪任务**。同一个功能准备上线时，可以让一个工作单元补充单元测试边界，一个工作单元验证 API 契约，一个工作单元运行静态扫描与依赖漏洞检查，一个工作单元从反例角度审阅需求。它们不必共享写权限，也不该抢同一个文件。真正的效率来自“同时增加不同类型的证据”，而不是同时生成更多代码。 第三类，**多个方案的并行探索**。比如把一个旧服务迁移到新框架，可以让三个 Agent 分别给出最小兼容迁移、渐进式双写迁移和一次性重写方案。这里的并行不是为了让三个人一起修改代码，而是为了让决策者拿到可比较的成本、风险、回滚路径和验证计划。探索完成后必须收敛到一个方案，再进入单一实施主线。 第四类，**模块边界清楚的批量改动**。例如多个相互独立的服务需要做同样的配置升级，或单仓库中几个互不共享核心文件的包需要补测试。前提是每个工作单元有独立 worktree、独立测试命令和明确的代码所有者。此时并行可以显著缩短墙钟时间，但集成阶段仍需要检查接口兼容和依赖顺序。 第五类，**需要不同专业视角的评审**。性能、安全、可观测性和可维护性往往不是同一条检查表。让不同的只读评审 Agent 以不同问题集审阅同一个候选 diff，是合理的；但每个评审都必须输出具体位置、失败条件和可复现步骤。泛泛而谈的“代码质量不错，但建议优化”不应该占用主流程的上下文。 把这些场景收束成一句话： > 当工作可以并行地产生相互补充、可独立验证的证据时，多 Agent 才有意义。 ## 五、哪些问题不值得并行，甚至应该刻意保持单线 与其罗列一百个适合并行的案例，不如把不适合并行的情况讲透。因为大多数浪费，恰恰发生在这里。 第一种，**根因尚未确定的单点故障排查**。当所有线索都指向一条连续请求链路时，最需要的是一个主体持续保留时间线、假设和反证。把日志、代码和监控拆给不同 Agent，往往会让每个人都只看到局部症状。此时应让一个单 Agent 沿着 `symptom -> trace -> state transition -> reproduction -> fix` 深挖，并在关键假设处调用只读子 Agent 做局部验证，而不是把主线拆散。 第二种，**高耦合的核心模型或数据迁移**。数据库 schema、核心领域模型、共享鉴权逻辑、账务规则、公共 SDK 这些地方，文件看起来可以分开，语义却高度耦合。多个 Agent 并行写代码，最常见的结果是每个 diff 局部都合理，合并后却违反了同一个不变量。此时更适合先由单 Agent 或人类架构师定义不变量、迁移顺序和回滚点，再在执行阶段谨慎并行外围适配。 第三种，**共享且不可复制的环境操作**。生产数据库、真实第三方账户、唯一的测试租户、存在副作用的支付或发信环境，都不应该让多个 Agent 竞态操作。并行会让“谁先写、谁后读、是否已经执行过”的状态变得难以确认。即使技术上能同时运行，也应通过队列、幂等键和互斥锁把关键动作串行化。 第四种，**验收条件尚不明确的需求实现**。需求方只说“把体验做得更好”，而没有用户路径、错误状态、指标和取舍标准时，开再多 Agent 也只会制造更多不同版本的猜测。先把不确定性还给产品或业务方，写出验收契约，再谈并行。多 Agent 不能替你补齐一个不存在的需求。 第五种，**需要连续设计判断的重构**。例如把一套历史包袱很重的权限系统重新分层。局部代码改动可以并行，但“目标边界是什么、哪些兼容层保留、哪些概念废弃”必须由一个统一的设计主线维护。否则每个 Agent 都会在局部做出看似合理、整体却彼此冲突的架构决定。 下面这张图不是为了把任务简单分成黑白两类，而是提醒团队：并发的最大敌人是隐藏依赖和不可验证性。  ## 六、真正的多 Agent，不是“多写代码”，而是“多增加证据” 理解了适用边界，团队就可以把角色重新定义得更工程化一些。 最常见的误区是让多个 Agent 都扮演“全能工程师”：都可以读全部代码、改任何文件、跑任何命令、最后都提交一个实现。这种设计把冲突交给最后的合并环节，等于把最难的问题延后爆炸。 更稳妥的设计是让多数 Agent 成为**证据生产者**，只有少数 Agent 拥有写权限。一个简单的分工可以是： - `Repo Scout`：只读，负责建立调用链、模块边界和已有约束。 - `Test Analyst`：只读或只写测试目录，负责列出可证伪假设和最小复现。 - `Security Reviewer`：只读，负责找危险输入、依赖风险和权限越界。 - `Implementer`：在独立 worktree 中改动指定文件，并附带测试。 - `Verifier`：不改代码，只运行测试、类型检查、扫描和差异审阅。 - `Integrator`：检查交付物是否满足任务契约，决定合并、退回或升级给人。 这套分工的关键不是角色名字，而是权限。读代码、提出反例、运行测试、修改生产逻辑、合并分支，风险等级完全不同。把它们全部授权给一个“聪明 Agent”，会让自动化很流畅，也会让事故半径很大。 GitHub Copilot CLI 已经把这种思路做成了产品能力：子 Agent 有独立上下文，内置 `code-review` Agent 是只读的，`rubber-duck` 被设计成从不同模型视角给出第二意见。工具在替你提供分工的脚手架，但是否真的形成独立证据，仍取决于你有没有把测试、权限和交付物设计清楚。 再强调一次：**不要把“独立上下文”误解成“独立事实”。**上下文隔离可以减少主对话被噪声淹没，但事实仍然需要通过仓库、日志、测试和工具输出来对齐。Agent 之间最好的沟通方式不是长篇讨论，而是引用可追溯的工件。 ## 七、从一个 Agent 走向一个小队：最小落地路径 不需要一开始就搭建一个能够自动调度十几个 Agent 的复杂平台。对多数团队，更可靠的起点是一个很小的闭环。 第一步，挑一个适合并行的只读任务。比如每周一次的依赖风险盘点，或一次明确范围内的 API 废弃调用扫描。不要拿核心支付重构、生产故障或跨系统迁移做第一场试验。 第二步，把任务写成 Work Unit 契约。明确范围、输入、禁止动作、输出格式、验证命令和时间预算。只要这一步还写不清，说明任务尚不适合并行。 第三步，只开两个或三个子 Agent。一个负责发现，一个负责验证，一个负责集成。先证明交接工件能减少主 Agent 的上下文负担，再谈扩容。很多团队第一次就开十六个，是因为他们把“并发数”误当成“成熟度”。 第四步，所有写操作放入独立 worktree，所有合并经过同一组自动验证。Git worktree 的价值不是“同时多开几个目录”这么简单，它把不同尝试的文件状态隔离开，让每个变更都能被审阅、测试和丢弃。没有隔离的并行写入，本质上只是多人同时改同一个工作台。 第五步，度量端到端结果，而不是只看 Agent 看起来多忙。至少记录：任务完成率、验证通过率、人工退回率、平均修复轮数、单位任务成本、合并冲突率，以及从开始到可合并的墙钟时间。只有当这些指标改善，才说明多 Agent 真正在提升工程效能。 最后，为每条自动化链路保留人工升级点。Agent 不应该在“再试一次”和“继续烧钱”之间无限循环。遇到重复失败、风险动作、验收歧义或共享环境冲突时，系统应带着证据暂停，把决定交回人类。 ## 结语：先拆问题，再增加 Agent 多 Agent SWE 的机会是真实的。它让代码审计、批量迁移、测试补全、风险扫描和多方案探索第一次能够以更低的等待成本同时推进。工具厂商正在把并行子 Agent、隔离 worktree 和异步任务管理变成默认能力，这意味着“一个人指挥多个受限工作单元”会越来越常见。 但这不是“单 Agent 时代结束”的证据。单 Agent 仍然是连续推理、根因排查、架构主线和高耦合变更的默认选择。多 Agent 不是替代它，而是在任务可分解、证据可独立验证时，把研发流程里的并行性释放出来。 真正值得记住的判断只有一句： > **不要因为工具允许你开 16 个 Agent，就去寻找 16 个任务；应该先找到能够独立验收的工作单元，再决定需要几个 Agent。** 下一篇，我们把这个判断继续落到工程底座上：任务图怎样表达依赖？为什么 worktree 只是隔离的起点？权限、验证器、可观测性和人工升级又该如何共同组成一支真正可控的“虚拟研发小队”？ ### 参考资料 - [Anthropic：Introducing dynamic workflows in Claude Code](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code) - [GitHub Docs：Running tasks in parallel with the `/fleet` command](https://docs.github.com/en/copilot/concepts/agents/copilot-cli/fleet) - [GitHub Docs：About custom agents in Copilot CLI](https://docs.github.com/en/copilot/concepts/agents/copilot-cli/about-custom-agents) - [JetBrains：Air Launches as Public Preview](https://blog.jetbrains.com/air/2026/03/air-launches-as-public-preview-a-new-wave-of-dev-tooling-built-on-26-years-of-experience/)