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