1. 三周干完两个月的活到底省在哪儿了先把这个项目的底牌摊开说一个标准的企业级内部系统按常规配置——4 人团队、2 个月工期——大概需要 320 人天左右。我实际投入的是 3 周核心执行单元是 3 个 AI Agent 加上我自己。这不是AI 帮我写了几段代码那种程度而是从需求拆解、接口设计、代码生成、测试覆盖到 CI 流水线搭建整条链路都由 Agent 承担了主要工作量。先说清楚这个项目是什么类型的活因为不是所有项目都适合这么干。它是一个典型的企业内部工具前端管理后台 后端 REST API 数据库 定时任务 权限体系。技术栈是 Spring Boot Vue3 MySQL Redis部署在 GitLab CI 上。这类项目的特点是——模式化程度高、业务逻辑清晰、没有太多需要灵光一现的架构决策。这正是 AI Agent 最能发挥的场景。为什么是 3 个 Agent 而不是 1 个这是整个项目里最关键的一个决策。单个 Agent 处理复杂项目时上下文窗口会被迅速撑爆而且它容易在写代码和改 bug之间反复横跳效率极低。我把职责拆成了三条线架构 Agent负责需求拆解、接口定义、数据库设计编码 Agent负责按接口契约生成具体实现审查 Agent负责 code review、测试用例生成和 CI 配置。三个 Agent 之间通过结构化的文档和代码仓库交互而不是靠对话上下文传递信息。这里有个反直觉的点Agent 之间的沟通成本必须用文件系统来承载而不是对话。我一开始试过让架构 Agent 把设计直接告诉编码 Agent结果就是编码 Agent 经常记错字段名、漏掉边界条件。后来改成架构 Agent 输出 OpenAPI 规范文件和数据库 DDL 文件编码 Agent 直接读文件错误率立刻降下来了。这个经验后面会展开讲。三周的时间分配大概是这样的第一周做需求拆解和架构设计同时把 CI 流水线和 Git worktree 的工作流搭好第二周是编码 Agent 的主力输出期我主要在做 review 和纠偏第三周做集成测试、修 bug、补文档、上线。真正写代码的时间其实只占了一半另一半全花在给 Agent 搭脚手架和验收上。所以如果你问我3 周做完 2 个月的活省在哪儿了答案不是AI 写得快而是省掉了人类团队里大量的沟通对齐、等待、返工和上下文切换。4 人团队里两个人对接口理解不一致可能要开半小时会才能对齐Agent 之间不存在这个问题只要契约文件写死了它们就严格按契约执行。这才是效率差异的真正来源。2. 三个 Agent 的职责边界怎么划才不打架2.1 为什么按交付物而不是按功能模块来分工很多人搭多 Agent 系统时第一反应是按功能模块分——你负责用户模块我负责订单模块。我试过这个方案很快就崩了。原因是模块之间是有依赖的用户模块的 Agent 改了数据结构订单模块的 Agent 不知道集成的时候一堆冲突。正确的切法是按交付物类型分。架构 Agent 的交付物是设计文档和契约文件编码 Agent 的交付物是可运行的代码审查 Agent 的交付物是 review 意见、测试用例和 CI 配置。每个 Agent 的输入和输出都是明确的文件不依赖对话记忆。Agent 角色输入输出核心工具架构 Agent需求文档、业务规则OpenAPI 规范、DDL、模块划分图长上下文模型 结构化输出编码 AgentOpenAPI 规范、DDL、编码规范后端代码、前端代码、单元测试代码专用模型 仓库读写审查 Agent代码 diff、测试报告Review 意见、补充测试、CI 配置代码模型 CI 配置文件生成这个表看着简单但每一行的输入都是上一行的输出形成了一条流水线。流水线的好处是可中断、可重跑。编码 Agent 某次输出质量差我不用重跑整个流程只要把架构 Agent 的契约文件重新喂给它就行。2.2 契约文件是整个流水线的宪法OpenAPI 规范文件在这个项目里的地位怎么强调都不过分。它不只是给前端看的接口文档而是编码 Agent 的唯一真相来源。我在架构 Agent 的 prompt 里写死了一条规则任何接口的字段名、类型、必填性、错误码都必须在 OpenAPI 文件里定义清楚不允许有待定字段。为什么这么严格因为编码 Agent 在生成 Controller 和 Service 时会严格按 OpenAPI 文件来。如果文件里有个字段叫userName但数据库 DDL 里叫user_name编码 Agent 生成的代码就会在映射层出错。我踩过这个坑——第一版契约文件里字段命名不统一结果编码 Agent 生成了 30 多个文件其中一半的字段映射是错的光修这个就花了大半天。后来我加了一道校验架构 Agent 输出契约文件后先跑一个脚本检查 OpenAPI 里的字段名和 DDL 里的列名是否一一对应驼峰转下划线不通过就打回重做。这个脚本本身也是审查 Agent 生成的大概 50 行 Python但省了我至少两天的返工时间。提示契约文件一定要用机器可校验的格式OpenAPI、JSON Schema、DDL不要用 Markdown 表格或自然语言描述。自然语言描述给 Agent 读它每次理解都可能不一样。2.3 审查 Agent 不是找茬而是补位审查 Agent 的定位很容易被误解成挑代码毛病。实际上它最大的价值是补编码 Agent 漏掉的横切关注点。编码 Agent 在生成业务代码时注意力全在业务逻辑上很容易漏掉日志、异常处理、参数校验、权限注解这些东西。审查 Agent 的职责就是系统性地检查这些每个接口都应该有但容易被忽略的部分。我让审查 Agent 按一个固定的 checklist 来 review这个 checklist 包括每个 Controller 方法是否有PreAuthorize权限注解、每个 Service 方法是否有入参校验、每个数据库操作是否在事务里、每个外部调用是否有超时和降级、每个接口是否有对应的单元测试。这个 checklist 是固定的审查 Agent 每次 review 都按这个来不会漏。实测下来审查 Agent 平均每个 PR 能找出 5 到 8 个问题其中大部分是编码 Agent 漏掉的横切关注点。如果靠人工 review这些问题可能要等到测试阶段才暴露那时候修的成本就高多了。3. Git worktree 撑起的多 Agent 并行工作流3.1 worktree 和 branch 的区别以及为什么这个项目非它不可先说清楚 git worktree 和 git branch 的区别因为这是整个并行工作流的基础。branch 是同一个工作目录下的不同分支你切换分支时工作目录里的文件会跟着变。worktree 则是同一个仓库的多个工作目录每个 worktree 可以 checkout 不同的分支互不干扰。这个区别在多 Agent 场景下是决定性的。如果三个 Agent 共用一个工作目录它们会互相踩脚——编码 Agent 正在写文件审查 Agent 去 checkout 另一个分支文件全变了。用 worktree每个 Agent 有自己的目录各自 checkout 自己的分支物理隔离。# 主仓库 git worktree add ../agent-arch feat/architecture git worktree add ../agent-code feat/implementation git worktree add ../agent-review feat/review # 每个目录独立工作互不影响 cd ../agent-code git checkout -b feat/user-module我实际用的结构是主仓库放架构 Agent 的产出契约文件、DDL三个 worktree 分别给三个 Agent 用。编码 Agent 在agent-code目录里写代码审查 Agent 在agent-review目录里跑测试和 review架构 Agent 在主仓库里更新契约。3.2 分支策略短分支 频繁合并多 Agent 并行最大的风险是合并冲突。三个 Agent 同时改代码如果分支活得太久合并时就是灾难。我的策略是短分支 频繁合并每个功能点一个分支编码 Agent 写完一个模块就立刻合并到集成分支审查 Agent 在集成分支上 review。具体节奏是编码 Agent 每完成一个 Controller Service Mapper 的组合就提交一次分支存活时间不超过半天。审查 Agent 在集成分支上持续 review发现问题就开一个 fix 分支修完立刻合回。这样任何时刻集成分支上的代码都是接近可运行的状态。这个策略的代价是提交次数多、分支多但好处是永远不会出现合并地狱。我见过太多项目feature 分支开了两周合并时几百个冲突光解决冲突就花掉好几天。短分支策略把这个成本摊平到了每一天。3.3 用 CI 做 Agent 产出的自动验收CI 在这个项目里不只是跑测试而是Agent 产出的自动验收关卡。我配了 GitLab CI每次 push 触发以下流水线stages: - lint - build - test - contract-check lint: script: - mvn checkstyle:check - npm run lint build: script: - mvn clean package -DskipTests - npm run build test: script: - mvn test - npm run test:unit contract-check: script: - python scripts/check_contract.py其中contract-check是我自己加的专门检查 OpenAPI 契约文件和实际代码是否一致。这个关卡拦住过好几次编码 Agent 的自由发挥——它有时候会自作主张加个字段或改个类型CI 一跑就暴露了。CI 的另一个作用是给审查 Agent 提供客观依据。审查 Agent 的 review 意见里凡是 CI 已经报出来的问题它就不用重复说了专注在 CI 覆盖不到的层面比如业务逻辑正确性、边界条件。这样审查 Agent 的 token 花在刀刃上。4. RAG 知识库让 Agent 记住项目的潜规则4.1 为什么通用模型搞不定企业项目的隐性知识通用大模型懂 Spring Boot、懂 Vue但它不懂你这个项目的约定。比如这个项目的所有金额字段都用BigDecimal且保留两位小数所有时间字段都用LocalDateTime且时区固定所有对外接口都要加Log注解记录审计日志。这些潜规则如果不在 prompt 里说清楚Agent 生成的代码就是能跑但不符合规范。把这些规则全塞进 prompt 是不现实的——太长而且每次都要重复。我的做法是建一个 RAG 知识库把这些项目约定、编码规范、历史踩坑记录都存进去Agent 在生成代码前先检索相关规则。4.2 知识库的切分策略按规则而不是按文档切RAG 效果好不好切分策略占一半。我一开始按文档切一个规范文档切成若干段结果检索出来的内容经常是半截话Agent 理解不了。后来改成按规则切一条规则一个 chunk每个 chunk 包含规则描述 正例 反例。比如一条 chunk 是这样的规则所有金额字段必须使用 BigDecimal禁止使用 double 或 float。 正例private BigDecimal amount; 反例private double amount; 适用场景实体类、DTO、VO 中的金额字段。这样切的好处是检索粒度精准。Agent 在写实体类时检索金额字段直接命中这条规则不会检索到无关的文档段落。实测下来按规则切分后Agent 生成代码的规范符合率从大概 70% 提升到了 95% 以上。4.3 RAG 的瓶颈和绕行方案RAG 不是银弹这个项目里我遇到两个明显的瓶颈。第一个瓶颈是检索不准。有些规则的关键词和代码里的术语对不上比如规则里说审计日志代码里叫Log注解纯向量检索可能匹配不上。我的绕行方案是混合检索向量检索 关键词检索两路结果合并后重排。关键词检索用 BM25能兜住那些术语对不上的情况。第二个瓶颈是知识库更新滞后。项目进行中会产生新的约定比如这个模块的错误码统一用 5xxxx 段如果知识库没更新Agent 就不知道。我的做法是把知识库更新纳入 CI每次合并到主分支如果 diff 里包含新的约定通过 commit message 里的特定标签识别就自动触发知识库更新流程。注意RAG 知识库不是越大越好。我一开始把整个项目的历史文档全塞进去了结果检索噪音很大。后来精简到只保留当前有效的规则检索质量立刻上来了。知识库要定期清理过期的规则比没有规则更危险。5. 三周里我踩过的坑和对应的解法5.1 编码 Agent 的过度设计倾向编码 Agent 有个很讨厌的习惯喜欢加抽象层。你让它写一个用户查询接口它会给你搞出UserQueryService、UserQueryStrategy、UserQueryFactory三层实际上业务逻辑就是一句SELECT * FROM user WHERE id ?。这种过度设计在人类开发者里也常见但 Agent 干这事更隐蔽因为它生成的代码看起来很专业。我的解法是在编码 Agent 的 prompt 里加一条硬规则除非明确要求否则不允许创建接口 实现类的组合不允许使用设计模式。所有 Service 直接写成Service标注的类不抽接口。这条规则加上去之后代码量直接少了三分之一可读性反而更好了。5.2 审查 Agent 的老好人问题审查 Agent 一开始特别客气review 意见都是建议考虑...、或许可以...这种。这种意见编码 Agent 根本不当回事因为它没有必须改的强制力。后来我把审查 Agent 的输出格式改成分级BLOCKER必须改否则不合并、MAJOR应该改、MINOR可选。只有BLOCKER和MAJOR会进入修复流程MINOR记录但不强制。分级之后审查 Agent 的意见有了牙齿。BLOCKER级别的问题编码 Agent 必须修完才能合并。实测下来每个模块平均有 2 到 3 个BLOCKER主要是权限注解缺失和事务边界错误这些都是上线后会出大问题的点。5.3 上下文窗口的遗忘问题编码 Agent 在处理大模块时写到后面会忘记前面的约定。比如它前面写的 Controller 用了PreAuthorize(hasRole(ADMIN))写到第五个 Controller 时忘了加。这不是模型能力问题是上下文窗口的物理限制。我的解法是分块 检查点。每个模块拆成不超过 5 个文件的小块每块写完立刻跑一次 CI 的 lint 和 contract-check通过后再写下一块。这样即使 Agent 忘了CI 也会立刻发现。另外我在每个块的 prompt 开头都重复一遍核心约定权限注解、事务、日志用重复来对抗遗忘。5.4 合并冲突的预防式处理多 Agent 并行合并冲突是必然的。我的处理原则是预防为主解决为辅。预防的手段有三个一是文件级隔离不同 Agent 尽量不碰同一个文件二是短分支分支存活时间短冲突窗口就小三是约定文件修改权OpenAPI 契约文件只有架构 Agent 能改编码 Agent 只能读审查 Agent 只能提意见。即使这样还是会有冲突主要是pom.xml和package.json这种共享文件。我的做法是指定一个 Agent 负责共享文件其他 Agent 需要加依赖时不直接改文件而是提交一个依赖申请就是一个简单的 JSON 文件由负责共享文件的 Agent 统一合并。这个流程听着麻烦但比解决pom.xml的冲突简单多了。6. 这套打法适合什么项目不适合什么项目6.1 适合的场景模式化、契约清晰、横切关注点明确这套三 Agent 流水线最适合的项目类型是企业级 CRUD 系统。这类项目的特征是业务逻辑以增删改查为主接口契约清晰横切关注点权限、日志、事务、校验明确且统一。我做的这个项目就是典型所以效果特别好。另一个适合的场景是有现成规范和历史代码库的项目。因为 RAG 知识库需要喂规范如果项目本身就有完善的编码规范和历史代码知识库建起来很快Agent 的产出质量也高。反过来如果是一个全新的、没有任何规范的项目你得先花时间定规范这部分工作 Agent 帮不上太多忙。6.2 不适合的场景强创新、强交互、强领域知识有三类项目我建议不要用这套打法。第一类是强创新项目比如需要设计新算法、新架构的项目Agent 的过度设计倾向和按套路出牌的习惯会拖后腿。第二类是强交互项目比如需要频繁和用户确认需求的探索型项目Agent 没法替你做需求判断。第三类是强领域知识项目比如医疗、金融的核心业务逻辑Agent 缺乏领域知识生成的代码可能语法正确但业务错误这种错误比语法错误更危险。判断标准很简单如果这个项目的需求文档能写到任何合格开发者看了都能实现的程度那它就适合 Agent 流水线。如果需求本身还在模糊状态需要人来反复澄清那 Agent 帮不上忙反而会增加沟通成本。6.3 团队规模的影响小团队收益最大这套打法对团队规模很敏感。4 人团队 2 个月的活我一个人 3 周做完效率提升大概 4 倍。但如果是一个 20 人的团队提升可能就没这么明显了因为大团队里 Agent 产出的协调成本会上升而且大团队本身就有分工Agent 替代的是执行而不是协调。我的观察是1 到 5 人的小团队用这套打法收益最大。因为小团队里每个人都是多面手要同时做架构、编码、测试、运维Agent 正好能补上这些角色的空缺。大团队里角色已经细分了Agent 的边际收益反而低。7. 如果重来一次我会怎么调整7.1 把契约校验提前到架构阶段这次项目里契约校验是在编码阶段才做的导致架构 Agent 的一些命名不一致问题到编码时才暴露。如果重来我会在架构 Agent 输出契约文件后立刻跑校验不通过就打回。这样能把问题拦在源头省掉编码阶段的返工。7.2 给审查 Agent 加业务逻辑检查这次的审查 Agent 主要检查横切关注点对业务逻辑的检查比较弱。结果是有些业务逻辑错误比如状态流转不对到集成测试才发现。如果重来我会给审查 Agent 加一个业务规则知识库让它能对照业务规则检查代码逻辑。7.3 知识库的维护要更早启动这次知识库是项目进行到一半才建的前半段的 Agent 产出规范符合率明显低于后半段。如果重来我会在项目启动第一天就把知识库建起来哪怕只有几条核心规则也比没有强。7.4 保留人工的最终验收环节这次项目里我虽然做了 review但主要是抽查。如果重来我会对核心模块做 100% 的人工 review非核心模块才用抽查。因为 Agent 的错误有时候很隐蔽CI 和审查 Agent 都可能漏掉人工的最终验收是最后一道防线不能省。最后分享一个我在实际操作中的体会这套打法的核心不是AI 多强而是流程多顺。三个 Agent 的能力其实都差不多真正决定效率的是它们之间的协作流程——契约文件、worktree 隔离、CI 关卡、知识库检索。这些脚手架搭好了Agent 就是高效的执行者搭不好Agent 就是制造混乱的源头。我花在搭脚手架上的时间大概占整个项目的三分之一但这部分投入是值得的因为它让后面的三分之二变得可控。