一个 Agent 能干的活，为什么非要组个团队？
英文标题：一个 Agent 能干的活，为什么非要组个团队？
多 Agent 不一定更快、更省。结合 Anthropic 的架构建议，聊聊研发流程里的交接成本，以及主 Agent、Skill、内置 subagent 和编排平台各自适合解决什么问题。
3.2 KB
589 B
188.9 KB
8.1 KB
中文
最近看一些 AI Coding 工作流，总有一种熟悉感：产品、架构、开发、测试，每个岗位安排一个 Agent，再找个主管负责协调。角色设定、消息总线、共享记忆一应俱全，俨然一家五脏俱全的小公司。
看着这套阵容，给一个表单加个字段，多少都有点不好意思开口了。
配图为 AI 辅助生成。
如果一个 Agent 已经能理解需求、读代码、修改和测试，为什么要先拆开，再让几个 Agent 互相解释一遍？
Anthropic 最近的文章 When to fold subagents into your main agent loop，讨论的正是哪些子 Agent 可以收回主循环。也就是让同一个 Agent 保留工作上下文，持续调用工具、检查和修正，直到把事情做完。
他们观察到，部分企业改用一个主 Agent，按需加载 Skills 和工具后，质量往往更好，成本和延迟也可能下降。其中一家客户的耗时约减半。
这些经验主要来自企业业务 Agent，不能直接外推所有研发任务。但文章指出的一个现象很值得琢磨：Agent 架构，正在复制企业的组织架构。
交接这件事，Agent 也躲不过
人类团队有产品、开发、测试，有它存在的理由：人的时间有限，经验和专业能力也不同。但这些理由，不能原封不动地搬到几个使用相同模型的 Agent 身上。
给它们分别冠上“资深架构师”“高级开发”的头衔，并不意味着招到了两个经验不同的人。不同指令和上下文可能有帮助，但效果仍然得看结果。
日常研发中，很多分工其实只是同一件事的不同阶段。比如给接口增加筛选条件，Agent 发现空字符串和未传参数在旧逻辑里含义不同，于是保留兼容处理，再补一条测试。刚查到的细节，下一步就能用上。
如果实现和测试各交给一个 Agent，后者就得重新弄清楚：这个兼容处理从哪来的，是产品要求还是历史包袱？如果交接里没写，它只能再查一遍，或者按自己的理解补测试。
当然可以要求前一个 Agent 把细节都写下来。但判断哪些探索结果值得保留，本身就是工作。交接写少了会漏，写多了又得重新消化。我们在人类团队里已经受够了交接成本，没必要因为 Agent 不会抱怨，就默认它们之间的交接免费。
Anthropic 的另一篇架构文章也建议，沿着能隔离的上下文分工，同一功能的实现和测试往往应该放在一起。这比照着研发岗位排座位，更接近问题本身。
流程沉淀下来，不必每一步都换个 Agent
读仓库说明、沿用请求封装、修改后运行检查、交付时附上验证结果，这些要求完全可以写进 Skill，配上脚本和工具，让主 Agent 按需读取。规范复用了，前面理解的需求和做过的决定也还在。
这里最容易混淆的是，“需要遵循另一套做事方法”和“需要另一个 Agent 来做”。比如修改代码前要先分析影响范围，把分析步骤写进 Skill 就能承接，不一定要先叫来一个分析师，等它交报告。
Codex 的 Skills 文档就介绍了这种按需加载方式。业务知识可以分开维护，不必全部塞进初始提示词，也不必每增加一种能力就另开会话。
对于修 Bug、补交互、改接口、重构模块，我会先让一个主 Agent 完成闭环，遇到明确瓶颈再分工。微服务和领域建模的经验可以用在工具接口、数据归属和业务规则上，不用把每个模块都变成一个会思考的角色。
当然，Skill 承接的是做事方法。跨天任务的状态保存、失败恢复、审批和权限检查，仍然需要程序或平台来保证。Skill 里写了“发布前必须通过检查”，发布接口也得真去检查这个条件，否则只是一份措辞严格的说明书。
哪些活，值得分头干？
开发等设计，测试等开发，拆成三个 Agent 也不会改变依赖关系。而一个主 Agent 同样可以并行调用独立工具，读文件、查资料不一定要先组个团队。
值得拆的，是能独立走一段、再带回结果的工作。比如一个故障有几种可能原因，可以分别查日志、最近的变更和依赖服务；大仓库里互不相关的模块，也可以分头探索。
独立审查也有价值。让另一个 Agent 拿着需求和最终产物检查，有机会发现实现者沿着原有思路没注意到的问题。它不必接手每一步实现细节，检查范围和交付结果也比较明确。
这类协作，我会先用 Codex、Claude Code 内置的 subagent。分派、等待和收集结果已经有人做了，没必要为几次有边界的分工，再维护一套角色和消息系统。
不过内置也有开销。Claude Code 的 Agent Teams 文档明确提到，团队模式会使用更多 token；顺序任务、同文件修改和依赖较多的工作，更适合单会话或 subagent。几个终端同时刷日志，不能直接算效率提升。
我会看一件很实际的事：子任务交出去以后，主 Agent 能不能继续做有用的工作？如果它只能原地等报告，报告回来还得重读一遍代码，增加的分工很可能没省下多少时间。
平台的价值，也得分开算
像 Multica 这样的代表性产品，从官方介绍看，它驱动已有的 coding agent，提供任务分配、运行记录、审核和用量统计。团队需要知道任务谁在做、卡在哪里、花了多少钱，这些都有实际用途。
但管理一百个任务，和把一个任务拆成十个 Agent，是两件事。前者解决管理和可见性，后者是否提高执行效率，还得单独证明。不能因为我们需要一个看板，就顺带接受看板背后一整套角色流转。
保留看板、审批和运行记录，让单个任务由主 Agent 加 Skill 完成，必要时调用子 Agent，一样能构成完整的研发工作流。我不认同的是先安排好一套角色，再让每个小修改都走几轮需求复述、计划生成和阶段总结。
具体产品是不是更慢、更贵，也不能只凭一次使用感受下结论。模型选择、缓存、重试和平台排队都会影响结果。越是复杂的方案，越应该拿实际任务做对照。
可以拿同一批真实任务，对比原生 Agent 加 Skill、内置 subagent 和外部编排。模型、权限与验收标准尽量一致，比较通过率、总耗时、人工返工和实际费用，失败与重试也算进去。
Anthropic 的迁移工具包也是逐项替换、前后对照，并没预设单 Agent 一定赢。
我的倾向很明确：常规研发先把一个 Agent 用好。加人能解决问题就加，只是多几个框、多几份交接文档，我宁愿省下这笔钱。毕竟招人都知道先确认工作量，轮到按 token 付费的 Agent，反倒一下子大方起来了。
English / 原文
最近看一些 AI Coding 工作流，总有一种熟悉感：产品、架构、开发、测试，每个岗位安排一个 Agent，再找个主管负责协调。角色设定、消息总线、共享记忆一应俱全，俨然一家五脏俱全的小公司。
看着这套阵容，给一个表单加个字段，多少都有点不好意思开口了。
配图为 AI 辅助生成。
如果一个 Agent 已经能理解需求、读代码、修改和测试，为什么要先拆开，再让几个 Agent 互相解释一遍？
Anthropic 最近的文章 When to fold subagents into your main agent loop，讨论的正是哪些子 Agent 可以收回主循环。也就是让同一个 Agent 保留工作上下文，持续调用工具、检查和修正，直到把事情做完。
他们观察到，部分企业改用一个主 Agent，按需加载 Skills 和工具后，质量往往更好，成本和延迟也可能下降。其中一家客户的耗时约减半。
这些经验主要来自企业业务 Agent，不能直接外推所有研发任务。但文章指出的一个现象很值得琢磨：Agent 架构，正在复制企业的组织架构。
交接这件事，Agent 也躲不过
人类团队有产品、开发、测试，有它存在的理由：人的时间有限，经验和专业能力也不同。但这些理由，不能原封不动地搬到几个使用相同模型的 Agent 身上。
给它们分别冠上“资深架构师”“高级开发”的头衔，并不意味着招到了两个经验不同的人。不同指令和上下文可能有帮助，但效果仍然得看结果。
日常研发中，很多分工其实只是同一件事的不同阶段。比如给接口增加筛选条件，Agent 发现空字符串和未传参数在旧逻辑里含义不同，于是保留兼容处理，再补一条测试。刚查到的细节，下一步就能用上。
如果实现和测试各交给一个 Agent，后者就得重新弄清楚：这个兼容处理从哪来的，是产品要求还是历史包袱？如果交接里没写，它只能再查一遍，或者按自己的理解补测试。
当然可以要求前一个 Agent 把细节都写下来。但判断哪些探索结果值得保留，本身就是工作。交接写少了会漏，写多了又得重新消化。我们在人类团队里已经受够了交接成本，没必要因为 Agent 不会抱怨，就默认它们之间的交接免费。
Anthropic 的另一篇架构文章也建议，沿着能隔离的上下文分工，同一功能的实现和测试往往应该放在一起。这比照着研发岗位排座位，更接近问题本身。
流程沉淀下来，不必每一步都换个 Agent
读仓库说明、沿用请求封装、修改后运行检查、交付时附上验证结果，这些要求完全可以写进 Skill，配上脚本和工具，让主 Agent 按需读取。规范复用了，前面理解的需求和做过的决定也还在。
这里最容易混淆的是，“需要遵循另一套做事方法”和“需要另一个 Agent 来做”。比如修改代码前要先分析影响范围，把分析步骤写进 Skill 就能承接，不一定要先叫来一个分析师，等它交报告。
Codex 的 Skills 文档就介绍了这种按需加载方式。业务知识可以分开维护，不必全部塞进初始提示词，也不必每增加一种能力就另开会话。
对于修 Bug、补交互、改接口、重构模块，我会先让一个主 Agent 完成闭环，遇到明确瓶颈再分工。微服务和领域建模的经验可以用在工具接口、数据归属和业务规则上，不用把每个模块都变成一个会思考的角色。
当然，Skill 承接的是做事方法。跨天任务的状态保存、失败恢复、审批和权限检查，仍然需要程序或平台来保证。Skill 里写了“发布前必须通过检查”，发布接口也得真去检查这个条件，否则只是一份措辞严格的说明书。
哪些活，值得分头干？
开发等设计，测试等开发，拆成三个 Agent 也不会改变依赖关系。而一个主 Agent 同样可以并行调用独立工具，读文件、查资料不一定要先组个团队。
值得拆的，是能独立走一段、再带回结果的工作。比如一个故障有几种可能原因，可以分别查日志、最近的变更和依赖服务；大仓库里互不相关的模块，也可以分头探索。
独立审查也有价值。让另一个 Agent 拿着需求和最终产物检查，有机会发现实现者沿着原有思路没注意到的问题。它不必接手每一步实现细节，检查范围和交付结果也比较明确。
这类协作，我会先用 Codex、Claude Code 内置的 subagent。分派、等待和收集结果已经有人做了，没必要为几次有边界的分工，再维护一套角色和消息系统。
不过内置也有开销。Claude Code 的 Agent Teams 文档明确提到，团队模式会使用更多 token；顺序任务、同文件修改和依赖较多的工作，更适合单会话或 subagent。几个终端同时刷日志，不能直接算效率提升。
我会看一件很实际的事：子任务交出去以后，主 Agent 能不能继续做有用的工作？如果它只能原地等报告，报告回来还得重读一遍代码，增加的分工很可能没省下多少时间。
平台的价值，也得分开算
像 Multica 这样的代表性产品，从官方介绍看，它驱动已有的 coding agent，提供任务分配、运行记录、审核和用量统计。团队需要知道任务谁在做、卡在哪里、花了多少钱，这些都有实际用途。
但管理一百个任务，和把一个任务拆成十个 Agent，是两件事。前者解决管理和可见性，后者是否提高执行效率，还得单独证明。不能因为我们需要一个看板，就顺带接受看板背后一整套角色流转。
保留看板、审批和运行记录，让单个任务由主 Agent 加 Skill 完成，必要时调用子 Agent，一样能构成完整的研发工作流。我不认同的是先安排好一套角色，再让每个小修改都走几轮需求复述、计划生成和阶段总结。
具体产品是不是更慢、更贵，也不能只凭一次使用感受下结论。模型选择、缓存、重试和平台排队都会影响结果。越是复杂的方案，越应该拿实际任务做对照。
可以拿同一批真实任务，对比原生 Agent 加 Skill、内置 subagent 和外部编排。模型、权限与验收标准尽量一致，比较通过率、总耗时、人工返工和实际费用，失败与重试也算进去。
Anthropic 的迁移工具包也是逐项替换、前后对照，并没预设单 Agent 一定赢。
我的倾向很明确：常规研发先把一个 Agent 用好。加人能解决问题就加，只是多几个框、多几份交接文档，我宁愿省下这笔钱。毕竟招人都知道先确认工作量，轮到按 token 付费的 Agent，反倒一下子大方起来了。