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类型和DTO定义，避免前后端各写各的。
• 配置管理Agent：环境变量、依赖注入、第三方服务配置。

质量保障类（8个）

• 单测生成Agent：针对新增函数生成单元测试。
• 集成测试Agent：跑本地环境，验证模块间调用链路。
• 静态审查Agent：代码规范、命名、复杂度检查。
• 安全审查Agent：SQL注入、路径穿越、越权风险。
• 性能分析Agent：慢查询、接口耗时预估。
• 边界条件Agent：专门想“空数组、超大数值、网络超时”这类极端情况。
• 回归影响Agent：判断改动会影响哪些已有功能。
• 代码规范Agent：最后统一格式和风格，不等同于静态审查。

文档与协作类（5个）

• README生成Agent。
• API文档Agent：更新OpenAPI定义。
• 变更日志Agent：生成CHANGELOG条目。
• 代码评审摘要Agent：生成PR描述，给人类Reviewer看。
• 周报Agent：汇总本周各Agent产出。

运维交付类（3个）

• 部署脚本Agent：生成Dockerfile和CI/CD配置。
• 监控巡检Agent：检查日志错误率和接口健康度。
• 线上问题初诊Agent：收到报警后拉日志、定位可疑代码片段，输出初步结论。

加起来正好30个。你会发现一个大原则：职责只按交付物切，不按技术栈切。后端实现Agent不负责测试，测试类Agent不负责改代码，这样出了问题能迅速定位到是哪一环没干好。

2.2 “岗位说明书”：每个Agent的提示词都要有边界

每个Agent的提示词我称之为“岗位说明书”。一份好的岗位说明书必须包含四块：角色限定、职责清单、输入输出格式、禁止事项。举一个后端实现Agent的例子。

你是订单模块的后端实现工程师。你的产出必须是可以直接运行的Python代码。你只负责订单模块，不要修改任何其他模块的文件。如果发现需要改动其他模块，在输出中标记需要协调。所有输入输出必须遵循任务卡JSON格式，禁止输出分析过程和内心想法，只输出最终结果。遇到不确定的业务规则，在risks中标明，不要自行假设。

这四块缺一不可。很多人的Agent提示词只有“你是一个资深Python工程师”这种空话，结果Agent行为不稳定，就是因为缺了“禁止事项”和“输出格式”。比如“不要修改其他模块文件”这条，如果没有显式声明，模型真的会把无关文件一并改掉。边界不是靠自觉，是靠写进说明书里。

2.3 输出格式统一是协作的前提

多Agent协作时，输出格式就是协议。我规定所有Agent的输出必须是一个结构化JSON，至少包含四个字段：summary、changes、risks、next。这样下游Agent不用从一段充满语气词的自然语言里猜上游想干什么，直接解析JSON就行。没统一格式之前，Agent A输出的结论是“我已经修好了这个问题，看起来没什么大碍”，Agent B根本不知道该拿这句话怎么办。统一之后，一切变得可程序化。

3. Agent协作的地基：编排模式、任务交接与记忆共享

有了一群角色，接下来最关键的问题是：它们之间怎么合作？这个环节我踩了很多坑，最后沉淀下来三件事：编排模式选DAG、任务交接走结构化任务卡、记忆要分层。

3.1 为什么选DAG而不是自由对话

第一版我让Agent之间可以自由调用，A可以叫B，B也可以叫A。结果就是群聊失控，Agent们聊了40多轮还在互相确认需求，任务发散得厉害。后来我改成有向无环图（DAG）编排——每个Agent只要知道上游是谁、下游是谁，从需求节点开始，一直流到最终交付节点，不回头、不跳级。

你可以用LangGraph、Temporal这类现成的编排工具，也可以像我后期一样自己写一个基于Redis队列的简化调度器。现成框架的好处是上手快、有可视化界面，但抽象层级高，想改执行策略会受限；自研调度器逻辑透明，每一步都在自己掌控内，但需要维护成本。我的建议是：30个Agent以内，先用现成框架跑通流程再说，等规模大了再考虑自研。

3.2 任务交接：统一JSON格式是避免混乱的底线

每个Agent完成任务后，会生成一张“任务卡”，格式如下：

json复制{
  "task_id": "TASK-001",
  "from_agent": "backend_impl_order",
  "to_agent": "static_reviewer",
  "input_files": ["app/api/order.py"],
  "output_files": ["app/api/order.py", "tests/test_order.py"],
  "constraints": ["不修改数据库schema", "不引入新依赖"],
  "verification_criteria": ["所有单元测试通过", "行数变化不超过500行"],
  "status": "pending"
}

这张卡就是Agent之间的唯一沟通载体。上游Agent只把任务卡传给下游Agent，下游Agent只能基于卡里的input_files和constraints工作，不能擅自扩大范围。这样任务边界清晰，出了事也能回溯到底是谁传了错误信息。

3.3 记忆分层：不该让所有Agent共享同一份记忆

多Agent之间绝对不能共享同一段对话历史，否则一个Agent的推理过程会被另一个Agent拿去做“依据”，最终导致上下文污染（后面详细说）。我的做法是把记忆分成三层：

• 项目级记忆：存在向量数据库里，存历史决策记录、踩坑记录、技术选型原因。每个Agent通过RAG按需检索，只有和当前任务相关的才拿得到。
• 任务级记忆：就是任务卡本身。卡里的字段是当前任务的全部上下文，不附带任何多余信息。
• 全局配置：比如代码风格、框架版本、第三方服务凭证，统一放共享配置，所有Agent只读。

3.4 人工审核节点必须放在这几处

30个Agent的流水线并非无人值守，我保留了三个人工审核节点：第一，需求澄清Agent产出验收标准后，人工看一眼确认没有理解偏差；第二，技术方案Agent输出改动清单后，人工评估影响面；第三，合并PR之前，人工过一遍最终代码。其余环节全部自动。为什么选这三处？它们都是“代价极高、返工极贵”的节点。需求理解错了，整个流水线做出来的东西全废；改动清单错了，下游所有实现都会跑偏；合并PR前的审核是最后的把关机会。其他环节出了问题都能自动重跑，但这三个节点一旦错了，成本会指数级放大。

4. 真实的一天：30个Agent如何端到端跑完一个需求

文字描述再多，不如走一遍真实流程。拿一个具体的例子：用户提交了一条Issue——“后台订单列表增加导出CSV功能”。这条Issue进入流水线之后是这样的。

4.1 从Issue到发版的全链路

第一步，需求澄清Agent收到Issue，生成验收标准：格式支持CSV、编码兼容UTF-8与GBK、导出的列顺序和当前列表一致、单次导出上限10万行。我确认后，技术方案Agent开始读项目结构，输出改动清单：新增app/services/order_export.py、新增app/api/order_export.py、前端订单列表页增加导出按钮、不需要新增数据库表。

数据库设计Agent评估后确认复用orders表即可。接着后端实现Agent（订单模块专属）生成导出服务代码，单测生成Agent同步产出测试用例。静态审查Agent跑完提出两个问题：一个是导出的CSV文件流没有关闭，一个是函数命名不符合规范。触发实现Agent自动修复一次，再送审通过。安全审查Agent检查了路径穿越风险和SQL拼接，确认没有问题。

前端实现Agent新增导出按钮和下载逻辑，集成测试Agent启动本地环境，模拟点击导出、验证文件内容、确认10万行数据能正常下载。最后API文档Agent更新OpenAPI定义，README生成Agent补充使用说明，变更日志Agent追加一条记录。代码评审摘要Agent生成PR描述，附上测试结果。我审核后合并，部署脚本Agent自动触发CI流水线。

整个流程，我只做了两次确认：需求验收标准和技术方案。其他环节Agent自己跑完。

4.2 实测收益：我做了个时间对比

这个需求如果我自己来做，大约要5.5小时。Agent流水线跑完只要1小时左右，其中还有20多分钟是我在审核。具体的时间分配可以看这个表：

单看数字很爽，但我要补一句：这个收益在中等复杂度的功能上表现最好。改动越简单，Agent的性价比越高；改动涉及大量历史遗留逻辑时，收益会明显打折，因为Agent需要反复读取上下文，流程会变长。

4.3 哪些环节仍然要我亲自上手

Agent流水线跑通之后，真正需要我亲自动手的有三类场景。第一种是跨模块的大重构，比如把单体应用拆成微服务，这种改动影响全链路，Agent的局部视角hold不住。第二种是新基建的引入，比如引入一个团队没人用过的新中间件，需要人来定技术标准。第三种是线上故障的真实排查，Agent能定位可疑代码，但真正做灰度回滚、和运维沟通、确定最终修复方案的还是我。换句话说，Agent擅长处理“流程明确的已知问题”，人处理“边界模糊的未知问题”。

5. 多Agent流水线踩过的坑：上下文污染、死循环和幻觉放大

这部分才是从“Demo能跑”到“生产可稳定跑”的关键。30个Agent串起来之后，问题复杂度不是加法，是乘法。我踩过的坑里，有四个最值得说。

5.1 坑一：上下文污染，Agent之间的推理过程互相干扰

最初我给下游Agent传上下文时，图省事会把上游Agent的“完整思考过程”一并传过去。结果很快就出问题了：静态审查Agent本来只看代码规范，结果引用了一条上游技术方案Agent的推理，说“这个方案里提到的技术栈选择我觉得不合适”，它开始评产品决策了。

问题根源是推理过程泄漏。下游拿到了不该它关心的东西，就会忍不住去管闲事。解决办法是“结果传递、过程隔离”——下游Agent只能拿到任务卡里的结构化结论，不能看到上游的思维链和中间分析。这也是为什么我前面强调统一JSON格式，因为只有结构化才能做到最小化信息传递。

5.2 坑二：死循环，质量门禁变成了无限重试

有一个阶段，我的流水线里只要测试Agent发现失败，实现Agent就要重试，重试完再测试，再失败再重试。有一次我醒来发现日志已经循环了14次，改了一个本不该动的函数，原因是测试Agent对“代码风格”和“功能正确性”的反馈没有分级，实现Agent每次修复都会顺手调整一些不相关代码，引入新问题，又触发新一轮修复。

解决方法是给反馈定级。任务卡里加了一个severity字段：只有error级别才触发重新执行；warning级别只记录到归档，不打断流程。同时设了max_retries: 3，超过三次直接转人工，不准无限循环。无限重试的本质，是AI不知道什么时候该停下来。既然它不知道，人就要替它定好规则。

5.3 坑三：幻觉在流水线里被放大

单个Agent的幻觉可以靠人来把关，流水线里幻觉会传染。我有一次真实经历：需求澄清Agent在验收标准里编了一条“导出文件需要包含汇总行”，需求源头根本没提过。技术方案Agent基于这条不存在的标准，设计了汇总行的计算逻辑。后端实现Agent更有执行力，直接把汇总逻辑写了出来，还写了测试。

这事的可怕之处在于，每个Agent自己看着都没问题，它是忠实执行了上游的指令，但指令本身是假的。现在我要求每个Agent在传递上游信息前必须做一个事实核查动作：凡是上游传来的结论，必须能在代码库中找到依据，找不到就标记status: "uncertain"，不能直接沿用。这个动作让链路里多了一层校验，虽然慢一点，但能把幻觉拦截在早期。

5.4 坑四：权限边界，给Agent的工具越多事故越大

有次部署脚本Agent在测试环境执行时，判断需要清理数据库，直接把她负责的预览库一张业务表给drop了。还好是预览环境，不是生产，但那次之后我重新设计了Agent的权限体系。核心原则是：**Agent默认只有只读权限，写操作一律过审批节点。**代码生成可以随意，但执行数据库变更、执行部署命令、修改生产配置这类操作，全部走“危险操作审批”节点，等人工确认。破坏性命令的审批，即使只有一键确认，也比完全没有要好。后来我还发现，给Agent的工具接口越宽，它的计划能力就越不稳定——因为可能性太多，它反而会纠结。把工具限制在任务必需的最小集合里，行为会稳定很多。

6. “干掉自己的工作”背后的真实逻辑：从执行者到验收者

聊到这里，回来回答标题那个问题。我并没有失业，只是工作重心彻底变了。以前我每天写代码、写测试、写文档、处理部署、回复用户问题，时间被大量重复劳动吃掉了。现在这些事流水线上的Agent在做，而我聚焦在四件事上：定义流程、拆任务、写Agent提示词、审核输出、处理异常。

6.1 哪些工作我永远不会交给Agent

虽然Agent已经很强，但我列了一份“永不外包”清单。第一类，产品方向的最终决策，比如放弃某个功能、调整优先级，这是价值判断，不是信息处理。第二类，架构路线的取舍，比如要不要引入微服务、要不要换数据库。这种决策的影响以年为单位，Agent没有承担后果的能力。第三类，涉及资金、用户隐私、法律合规的操作。这不是技术风险，而是责任归属问题。第四类，需要共情沟通的场景。用户已经炸毛了，你去让AI回应，大概率火上浇油。AI处理事实，人处理情绪。

6.2 给想入局Agent开发的同行的建议

别一上来就想搭30个Agent。我一开始也是边搭边拆，中间推翻重来过好几次。最务实的起步是三个：需求澄清Agent、实现Agent、审查Agent。先把这三个跑通，感受一下它们之间的沟通成本，再逐步扩到六、七个。扩的时候遵循一个原则：只要现有Agent在某个环节的产出不稳定，才考虑拆一个新的Agent出来专职负责这个环节。Agent不是越多越好，一个冗余的Agent只是增加了编排成本和上下文的噪声。

6.3 一个判断标准

最后分享我自己的判断标准：如果一个任务，写清楚流程之后让任何一个Agent来做，结果都差不多，那应该自动化；如果一个任务需要大量隐性知识、需要背锅、需要为最终结果负责，那还是留在自己手里。我干掉的是“可以被流程化的自己”，不是“需要做判断的自己”。这30个Agent没有让我失业，反而让我从靠工时换产出的开发者，变成了靠定义质量换产出的开发者。这个转变，才是这串数字背后真正值得思考的东西。