一个人写代码，五个人在旁边递砖头，什么感觉？最近我把一套完整的Agent协作流程跑通，五个大模型在同一套代码库里分工干活，有写业务逻辑的，有补测试的，有查Review的，有看依赖的，还有一个专门盯着性能和安全。实测下来，效率确实不是1+1=2，但要说完全不用管，那也是想多了。
这玩意儿不是什么未来概念，就是现在能落地的工作方式。AI编程发展到今天，早就过了“一个人对着对话框问一句答一句”的阶段。这个标题里的“第四纪元”，我自己的理解是：第一纪元是补全代码，第二纪元是对话生成，第三纪元是单Agent跑通一个闭环任务，到第四纪元，就是多个Agent在同一个项目里并行干活，像一支小团队一样协作。很多人还停在前两个阶段，用AI写个函数、改个bug就觉得到头了，实际上这套多Agent协作的方式，才是真正改变开发节奏的东西。
这篇文章没有厂商通稿，没有PPT愿景，只有我实际跑过的流程、踩过的坑和调出来的参数，供想往这个方向试试的人参考。
1. 第四纪元到底“新”在哪：从工具人到队友
先回顾一下前几个纪元，不然说不清楚为什么多Agent会带来质变。
第一纪元，就是各种IDE插件做行级补全。你写个函数名，它帮你补参数，补循环。这玩意儿解决的是打字速度，是“手跟不上脑”的问题。当时的体验就是“AI真聪明，连我接下来要写什么都猜到了”，但骨子里，它是一个高级输入法。
第二纪元，是对话式编程。你直接跟模型说“帮我写一个时间序列异常检测的类”，它给你生成一坨代码，你往项目里一粘，改改就能跑。这个阶段解决了“从零到有”的问题，但本质上还是人在主导，上下文全靠人来喂，代码错了要人去查，Bug定位全靠人肉。用过的都懂，在大型项目里，这种方式的上下文窗口根本不够用，聊到一半前面的内容早忘了。
第三纪元，代码托管平台开始有Agent能力，你扔一个Issue进去，Agent自动生成一个Pull Request。这个阶段厉害在它能做任务闭环，你自己不用写细节了，但一次只能跑一个任务，一个Agent从拿到Issue到改完代码，中间串行执行，效率还行，但不够。
到了第四纪元，也就是现在我自己跑的这套架构，核心变化在于：多个Agent之间有了分工和协作，它们共用一个代码仓库、一套上下文体系、一个任务队列，同时处理多个相互关联的开发任务。这像什么？就像你以前有个实习生，现在给了你五个实习生，而且这五个实习生干活的时候还能互相吼一嗓子“你那边接口改了我这边调用要跟着动”。
实际效果是，以前一个改动要串行经历“写代码”“写测试”“跑静态检查”“改问题”这四个步骤，现在四个Agent并行推进，写业务代码和补测试同时进行，Review Agent提前盯在上面，出了问题第一时间能反馈到业务代码Agent那边去修正。整体时间是实打实省下来的，不是账面上那种“指标好看但活没少干”。
2. 五个Agent谁是谁：分工不是堆数量
很多人一听“5个Agent”，第一反应是“那我一次开五个对话框，让它们各写各的不就行了”。思路对了一半，但只开对话框不叫协作，叫轮班，上下文不互通，代码库不共享，五个模型各写各的，最后合并的时候绝对让你头疼到怀疑人生。
我跑下来的流程，是五个Agent在同一套代码库、同一个任务列表下协作，每个Agent有明确角色和职责范围。
第一个是业务Agent，也就是主开发。它负责核心业务逻辑的实现。比如项目里需要一个订单状态机的流转逻辑，这个Agent就专注做这个，它的职责边界非常清晰：只写业务逻辑，不碰基础设施，不碰部署脚本。原因在于，如果让它什么都干，上下文会被撑爆，任务会变得模糊，产出质量必然下降。
第二个是测试Agent。它和业务Agent共享同一份代码变更信息，业务Agent改完一个核心模块，测试Agent马上就能拿到变更内容，开始补单元测试和集成测试。这里最关键的一点是，测试Agent不是看到完整代码才动手，而是基于业务Agent提交的接口约定和变更摘要，提前开始写测试骨架和边界条件的用例。这个并行度是整个架构效率的核心之一。
第三个是Review Agent，相当于团队里的Code Reviewer，不看业务逻辑对不对，专门看架构一致性、编码规范、接口兼容性和潜在Bug。它跑的是最高频的角色，业务Agent每提交一版代码，它都要做一轮增量Review，把反馈直接丢回业务Agent那边。这里有个细节：Review Agent的Prompt必须特别强调“只提必须改的问题”，不然它会吹毛求疵，什么命名风格不一致也给你提一遍，导致业务Agent被无效反馈淹没。
第四个是依赖Agent。这个是我后面加的，因为一开始四个Agent跑起来之后，发现大量冲突不是来自业务逻辑，而是来自依赖库和全局配置。比如业务A要用新版本的某个库，业务B还在用旧接口。依赖Agent专门负责看全项目的依赖声明、版本冲突、配置项变更，确保所有Agent推入的改动在依赖层面不自相矛盾。
第五个是性能安全Agent，负责非功能需求的兜底。它盯着改动里的常见性能坑，比如循环里查数据库、N+1查询、敏感信息进日志等。虽然它不会做事后审计级别的深入分析，但在开发阶段把明显的坑挡住，比事后优化要省钱得多。
每个Agent的角色描述在Prompt里写得极其细致，不能只给一句话“你是代码审查员”，得给定输入格式、输出格式、必须检查的项目清单、改动文件范围、上下文获取方式。
3. 让5个Agent协作的核心：一个共享大脑
角色分好了，接下来是更关键的问题——怎么让它们成为一个团队，而不是五个各自为战的个体。
这里面最核心的组件是共享上下文。我自己的做法是维护一个项目状态库，本质上是一个结构化的文本文件和代码索引的集合，里面记录着当前任务的进度、每个Agent正在处理的内容、已完成模块的摘要、关键技术决策和约定。
具体落地方式，是用一套基于文件的任务状态机制。每个任务在开始前会生成一份任务说明文件，包含问题描述、涉及到的已有代码区域、依赖关系、验收标准。Agent开工前，先读任务说明和项目状态库中相关的部分，再开始动手。完成之后，它要更新状态库里对应模块的描述，写清楚“我改了什么”“为什么这么改”“当前留下什么风险”。
这个看起来简单的机制，解决了多Agent协作里最大的问题——记忆断层。大模型没有记忆，即便有上下文窗口，在不同Agent之间也不会天然共享。如果不做这个共享状态库，业务Agent和测试Agent对同一段代码的理解可能完全是两套逻辑，接口都对齐不上。
另一个核心机制是消息总线，或者叫任务事件流更贴切。每个Agent的动作都会产生事件，比如“业务Agent提交了一版变更”，这个事件会被推送给相关的Agent，Review Agent收到后开始做增量检查，测试Agent收到后开始补相关用例。说起来像软件工程里的事件驱动架构，实际本质也确实是这个。写业务代码，本质上是在设计一套并行系统，不是简单写Prompt。
然后就是锁机制，这词一听像是数据库的东西，但在多Agent协作里同样存在。如果两个Agent同时改同一个文件，大概率产生不可自动合并的冲突。我在实际设计里用文件级的锁来规避，一个Agent拿了一个文件的写权限，其他Agent对这个文件的写入就会被挂起。不能让两个Agent同时改同一个文件，这是用血泪换来的教训，有几次两个Agent同时在一个工具类文件里加方法，互相覆盖到对方心态爆炸。
4. 一套能跑通的工作流设计：从任务拆解到代码合并
这套架构不是拍脑袋搭出来的，我跑通的那套工作流，大致分成了六个步骤。写下来供参考，完全能直接抄去用。
首先是任务拆解。项目启动时，把需求拆成可以并行推进的任务块。这里需要点功力，拆得好不好直接决定后面Agent协作的流畅度。关键原则是任务块之间要尽量减少代码文件层面的交集。比如“订单服务模块的API开发”和“支付回调硬件的签名校验”这两个任务，就可以并行，它们碰到的文件不重叠。但如果拆成“用户模块的API开发”和“用户模块的持久层优化”，这俩大概率会碰同一个目录，冲突就来了。
第二步是任务说明书生成。每个任务都有一份说明书，记录背景、需求、验收标准、约束条件。这相当于给Agent里的“产品经理”角色，核心目的是让Agent拿到任务时不需要自己瞎猜需求边界。
第三步是Agent认领与并行执行。任务池里的任务被Agent拉取，拿到锁之后开工。这个过程里，业务Agent是绝对的主力，测试Agent和依赖Agent是伴飞的，干什么节奏都在推进业务Agent的任务进度。
第四步是增量Review与修复。业务Agent每完成一个文件或一个功能点，Review Agent立刻启动增量Review，发现问题直接派回业务Agent。注意这个增量Review的设计，等所有代码写完再一次性Review，反馈效率低，而且会让修复的上下文断掉。增量Review的节奏感特别重要，我们要的是“小步快跑”的感觉，代码写完一个函数，Review那边就接上了。
第五步是自动化验证串起来。等任务片的业务代码和测试代码都完成，自动跑单元测试、静态检查、依赖验证。这里面有一个特别实用的做法——测试Agent和业务Agent共用一套模拟数据的定义，不然容易出现在测试里Mock的数据结构和实际业务代码用出入的问题。
第六步是人工合并与总体审查。最后一道关卡必须由人来做，原因不是Agent能力不足，而是跨模块的全局一致性、产品语义的最终判断，目前仍需要人来兜底。流程上，我会把多Agent产生的代码改动放在一起做一次整体的Code Review，重点看接口契约、模块间的一致性，以及是否存在Agent各自为政导致的风格割裂。
跑完这六步，一次多Agent协同开发基本闭环。实测下来，一个中等复杂度的功能模块，从拆解任务到代码合并落地，整个周期比单Agent串行方式至少省掉一半时间——前提是任务拆解得当、Prompt配置准确的情况下。
5. 实操配置指北：角色Prompt、上下文与输出规约
光说架构不落地等于白说，要跑起来，几个关键配置细节必须说透。
每个Agent的System Prompt必须包含四个部分：角色定义、输入接口、输出格式、约束与禁忌。角色定义不能是“你是Java工程师”这种废话，要精确到“你是负责XX系统的核心业务逻辑开发的工程师，负责模块包括：订单状态流转、支付结果处理、库存扣减模板。你的代码风格遵循项目现有风格，优先使用项目已有的工具类”。
输入接口要写明Agent可以读取哪些目录、哪些文件、哪些配置文件，以及任务说明书存放在哪里。这能极大减少Agent的“迷茫感”——它不需要自己猜该从哪里获取信息。
输出格式的约束是保命条款。比如业务Agent的输出必须包含：变更文件列表、变更说明、涉及到的依赖项、遗留风险。这个标准化的输出是后续通信的基础。没有固定格式，Agent输出的东西就无法被其他Agent和自动化工具正确解析。
约束与禁忌要写得非常细。比如“不允许修改任何测试文件”“不允许改动打包配置”“不允许重构非你任务范围内的代码”。写完之后你会发现，Agent比人类好管的地方就在于，它真能严格听指令，但你给的指令不完整，它一定会给你闯祸。
还有一个值得大家注意的配置细节，是上下文压缩与摘要。单个Agent的上下文窗口再大，一个长任务跑下来也一定会爆。我在状态库中设计了“任务阶段摘要”机制，业务Agent每完成一个阶段，就要把已完成的细节压缩成摘要存下来，后续它自己再次读取时，不读原始的长对话，只读摘要和必要代码。这个机制也是后来才加的，不加的话，任务跑到后期，Agent的表现会肉眼可见地崩——前面的对话细节因为超过上下文窗口被丢弃，又没落到持久化里。
6. 踩坑实录：这五个坑值得单独立传
这套玩法看着美好，跑起来实际也是处处埋雷。我踩了几个值得单独写出来的坑，每一个背后都是小时级别的排查。
第一个坑，就是上下文污染。多个Agent共享同一个代码库，A Agent在公共配置里改了一个参数，B Agent在对代码做分析时读到了新值，但B它内部的缓存状态还是旧值，于是产生了一种玄学的逻辑错位。排查到最后，发现是并发读写的时序问题。解决的方案是用版本控制系统的变更通知来驱动Agent的上下文更新，而且要在大改之后强制所有Agent重启会话并重新读取状态库。
第二个坑，反馈风暴。这个在前面多少提过，把Review Agent的Prompt写得过于宽松，导致它每轮改动能给出十几条审阅意见，其中一半是因为它没引用当前最新代码，用的还是旧快照。结果业务Agent被无效意见反复打断，效率不升反降。
解决这个问题的办法有两个：一是Review Agent的检查项要像需求文档一样精确，钩子到具体模块的具体规则和具体风格约定；二是给Review Agent也加上输出格式限制，意见必须标注优先级和严重等级，低级意见每周合并。这套做法实测下来很稳，Review的噪音量至少下降了七成。
第三个坑，边缘模块没人管。任务拆解如果只追求“并行度最大化”，很容易出现各任务覆盖的模块中间隔出一片“三不管地带”，经典的Case是工具类函数、公共DTO定义、常量池。后来为了解决这个问题，我额外设立了“公共区域守护”规则，任何Agent要动公共目录的文件，都必须先更新任务说明，确保改动有迹可查。
第四个坑，测试Agent过度输出。它会为了“测试覆盖率高”硬凑测试，写出一堆无意义的低价值用例，比如断言函数返回类型、断言HTTP状态码这种夹具级测试。这种测试不是没意义，但优先级极低，还多花了大量时间。后来在Prompt里加了一条硬约束：新测试用例必须证明业务逻辑的核心分支，不满足就禁止提交。
第五个坑，模型能力不均衡导致的下限拖累。五个Agent背后不一定是同一个模型，实际搭配下来也不建议同一个模型。像性能安全Agent可以选一个代码分析能力特别强的模型，而业务Agent需要一个指令跟随强、长上下文执行稳定的模型。但如果某个Agent用的是能力明显偏弱的模型，它的错误会通过事件流传染给其他Agent。所以建议对Agent用的模型做一次盘点和能力隔离，别让一个弱模型成为整个流水线的短板。
7. 聊几句管理体验和这个模式的天花板
多Agent编程真正难的地方，不在于把System Prompt写好，也不在于任务拆解，而在于背后那套基于状态和事件的管理框架要足够稳。代码能力强的Agent满地都是，但能稳定协作起来的Agent团队，还是需要一整套机制来托底。
我自己的体会是，这模式很像项目管理，只是把管理的对象从人换成了Agent。任务怎么拆、上下文怎么同步、冲突怎么提前规避、输出怎么约束，这些东西跟传统团队管理没有本质差别，差别只在于Agent服从度更高，但推理深度有时不够。
再说说天花板，这个模式目前能解决方法论层面和流程层面的问题，但它不能帮你想清楚产品逻辑。业务Agent能帮你把订单状态机写得干净利落，但它不会替你思考“这个订单流程和优惠券系统的联动是不是存在设计上的漏洞”。人力在这个过程里唯一不可替代的，是对系统的整体理解和边界判断。
从实际项目复盘看，多Agent协作不等于招聘五个AI你就能撒手不管。它是一种强力的推进器，但方向还得由人来控制。一个合理的动作可能也就几条线：项目里哪些模块适合并行开发，哪些Agent适合负责哪些角色，哪些流程节点必须人审。想清楚这些，再把这套模式放进去，产出效率确实能上一个台阶，但前提是一直有人盯着方向盘。
最后说个特别实在的经验：第一次试这套模式，别真放五个Agent上生产项目，太容易乱。先在某个内部小项目里跑通，把任务状态库的规范、锁机制、上下文更新节奏都调顺了，再逐步加大规模。每一步都走稳了，这套模式才真正为你所用。
