30个Agent的研发流水线：从分工设计到防坑实践

上个月，我把自己的开发流程彻底重构了一遍。不是什么新语言、新框架，而是把30个Agent接进了日常的研发链路——现在从需求澄清、技术方案、写代码、写测试到改文档，大部分重复劳动都变成了Agent流水线里的一个节点。说“干掉自己的工作”其实是标题党，我的工作并没有消失，只是从“亲手写每一行代码”变成了“定义流程、拆任务、验收结果”。这篇文章不聊那种“点击几下自动生成整个应用”的演示效果，而是讲多Agent协作真正落地时遇到的分工、交接、防污染问题，以及30个Agent这个数字背后到底意味着什么。如果你正在项目里试Agent开发，又不知道从哪下手，这篇文章应该能给你一条可落地的路径。

1. 为什么是30个Agent，而不是一个“超级Agent”

先说结论：不是因为单个大模型能力不行，而是把一个大任务全塞给一个Agent，在真实项目里根本跑不稳。

我最早也试过“一个Agent干所有事”——需求、方案、编码、测试、文档、部署建议全放同一段对话里。单个任务测试时效果确实惊艳，比如“帮我写一个导出CSV的功能”，它真能一口气给出完整代码。但放到真实项目里，问题立刻暴露。真实项目有几十个文件、一堆历史决策、各种约定俗成的写法，把这些全部塞进一个上下文根本塞不下，只能裁剪，一裁剪就会漏信息。更麻烦的是角色冲突：同一个对话里，它刚以架构师的口吻讨论完目录结构，马上又要切换到测试工程师视角挑自己刚写的代码的刺，模型很容易把这两种角色搅在一起，说话一会儿像架构师一会儿像QA，输出的东西前后矛盾。

上下文超长和角色混杂这两个问题叠加，还会带来第三个问题——不可审计。流水线质量下降时，你不知道是需求理解错了、方案设计跑偏了，还是代码生成阶段出了问题，因为你手里只有一个大黑盒。

所以我把“一个大Agent”拆成了“一组小Agent”。每个Agent只负责一个非常窄的岗位，比如“只检查Python类型错误”或“只评审前端组件变更”。拆小之后有很明显的收益：

• 角色纯净。每个Agent的提示词只有几百字，它只需要记住自己那一小摊事，行为稳定得多。
• 故障隔离。某个Agent抽风了，只影响局部环节，把它的结果丢掉重跑就行，不会一崩全崩。
• 可以单独替换。某个Agent效果不好，我可以换个思路重写它的提示词，甚至换一个模型来跑，完全不影响其他环节。

至于为什么是30个而不是10个或50个，我的理由很简单：按一条完整交付链路去数岗位，需求设计、编码实现、质量保障、文档协作、运维交付这五个环节拆下来，自然就落在30这个量级。这是从分工粒度推出来的数，不是拍脑袋凑的。

2. 30个Agent都是谁：按交付链路拆出来的完整角色清单

拆Agent的依据是“这个环节的输出会不会影响下游”，而不是“能不能让AI干”。我按这个思路把30个Agent分成了五类，下面是我现在在用的实际分工。

2.1 从需求到上线的五类Agent分工

需求与设计类（4个）

• 需求澄清Agent：把一句模糊的需求拆成可校验的验收标准，比如“支持中文导出”会被拆成“标题编码使用UTF-8，内容编码兼容GBK”。
• 技术方案Agent：读项目结构，把需求翻译成具体改动清单，精确到文件路径。
• 数据库设计Agent：评估是否需要新增表、索引、迁移脚本，输出ER变更说明。
• API设计Agent：负责接口契约、请求响应结构、错误码规范。

编码实现类（10个）

• 脚手架Agent：负责初始化项目结构，只在新建模块时触发。
• 后端实现Agent x 5：按业务模块划分，比如用户、订单、支付、库存、报表各一个。不混用。
• 前端实现Agent x 2：一个负责页面UI，一个负责状态管理和接口联调。
• 类型定义Agent：统一维护TypeScript类