1. 项目缘起与整体交付思路1.1 一个真实到有点扎心的背景去年年底我接了一个企业级内部管理系统的项目。客户那边原本的规划是4 人团队2 个月工期预算按人天算得清清楚楚。结果我这边实际投入的只有我一个人外加 3 个 AI Agent 组成的“虚拟小组”3 周交付上线。这不是标题党也不是为了炫技。我之所以敢接这个活是因为在接之前我已经用类似的方式跑通过两个小项目心里有底。但即便如此3 周做完一个原本 4 人 2 个月的项目中间踩的坑、熬的夜、推翻重来的次数一点都不少。这篇文章不打算跟你聊“AI 会不会取代程序员”这种大而空的话题。我想把整个项目的交付过程拆开讲清楚三件事AI Agent 到底在哪些环节真正提效了、哪些环节它反而拖了后腿、以及一个人带着 3 个 Agent 干活工程上要怎么组织才不至于把自己搞崩。如果你是一个独立开发者、小团队技术负责人或者正在评估要不要把 AI Agent 引入日常交付流程这篇内容应该能帮你省下不少试错成本。1.2 为什么是“3 个 Agent”而不是“1 个全能 Agent”很多人一上来就想搞一个“什么都能干”的超级 Agent我试过结论是单 Agent 做企业项目越到后面越失控。原因很简单。企业项目不是写一个算法题它涉及需求理解、架构设计、编码实现、测试验证、部署运维等多个阶段每个阶段对上下文的要求完全不同。你让一个 Agent 同时记住需求文档、代码规范、数据库 schema、接口约定、部署脚本它的上下文窗口会被迅速撑爆然后开始“胡言乱语”——生成看似合理但完全跑不通的代码。所以我把它拆成了 3 个角色各管一段Agent 角色主要职责核心依赖需求与架构 Agent拆解需求、生成数据模型、输出接口契约RAG 知识库、历史项目文档编码 Agent按契约生成业务代码、单元测试代码规范库、worktree 隔离环境审查与集成 Agentcode review、CI 流水线校验、集成测试CI 配置、静态分析规则这三个 Agent 不是各自为战它们之间通过结构化的中间产物通信——接口契约、数据模型、测试用例而不是靠自然语言互相“聊天”。这一点非常关键后面会详细讲。1.3 3 周时间是怎么分配的先给你一个整体节奏心里有个数第 1 周需求梳理 RAG 知识库搭建 架构设计 接口契约冻结第 2 周核心业务模块编码 单元测试 每日 code review第 3 周集成测试 CI 流水线打通 部署 修 bug 交付文档看起来挺顺但实际执行中第 1 周我花了整整 5 天在“让 Agent 理解这个项目”上第 2 周有 2 天在跟 Agent 生成的“幻觉代码”搏斗第 3 周有 1 天因为 CI 配置问题差点通宵。所以真实的时间账比表面看起来紧得多。2. 核心工具链选型与背后的取舍逻辑2.1 为什么用 git worktree 而不是 git branch这是整个项目里我最想先讲的一个点因为它直接决定了多 Agent 并行编码能不能跑通。一开始我用的是传统的git branch。每个 Agent 在自己的分支上干活干完再 merge。听起来没问题但实际操作中你会发现切换分支要 stash、要 checkout工作目录是共享的。当编码 Agent 在写业务代码、审查 Agent 同时想跑测试的时候两边会互相干扰。你切过去它的编译缓存就废了它跑测试你的未提交改动就被搅乱了。后来我换成了git worktree。简单说worktree 允许你把同一个仓库的不同分支同时检出到不同的目录每个目录有自己独立的工作区、独立的编译缓存、独立的运行环境。# 为主仓库创建两个额外的工作树 git worktree add ../project-agent-code feature/agent-code git worktree add ../project-agent-review feature/agent-review # 查看当前所有工作树 git worktree list这样编码 Agent 在../project-agent-code目录里写代码审查 Agent 在../project-agent-review目录里跑测试互不干扰。实测下来这个改动让并行效率提升了至少 40%。注意worktree 不是银弹。它会让你的磁盘占用翻倍而且每个 worktree 的依赖需要单独安装。如果你的项目依赖特别重要提前评估磁盘和内存。2.2 RAG 知识库企业项目的“记忆外挂”企业项目最大的特点是什么上下文极其庞杂。客户有历史系统、有内部规范、有行业术语、有各种没写进文档但老员工都知道的“潜规则”。这些东西你不可能全部塞进 Agent 的 prompt 里。我用 RAG检索增强生成来解决这个问题。具体做法是把客户提供的需求文档、历史接口文档、数据库设计文档全部切块、向量化存进知识库把团队内部的代码规范、命名约定、常用工具类也存进去Agent 在生成代码前先检索相关知识片段再基于检索结果生成这里有个坑我必须提醒你RAG 的瓶颈往往不在检索而在切块。我一开始按固定 500 字切块结果一个完整的接口定义被切成两半Agent 检索到半截信息生成的代码自然对不上。后来改成按语义结构切块——一个接口定义、一个数据表、一个业务规则各成一块效果立刻好转。关于“RAG 知识库能不能存图片”我的实践是可以存但意义有限。图片里的信息如果没被 OCR 转成文字检索时基本命中不了。企业项目里真正有用的还是结构化的文本知识。2.3 CI 流水线让 Agent 的产出“有据可查”AI Agent 生成代码最大的风险是什么它看起来很对但可能根本跑不起来。所以我从第 2 周开始就把 CI 流水线接入了。每次编码 Agent 提交代码CI 自动触发静态代码检查lint单元测试接口契约校验构建打包只有全部通过代码才允许合并。这一步看似增加了流程实际上是把审查 Agent 从“人肉检查”中解放出来让它专注于逻辑层面的 review而不是纠结语法错误。我用的是 GitLab CI配置不复杂核心就是几个 stagestages: - lint - test - build lint: stage: lint script: - npm run lint test: stage: test script: - npm run test:unit build: stage: build script: - npm run build这套配置跑通之后我每天早上的第一件事就是看 CI 报告而不是逐行读 Agent 生成的代码。效率差别巨大。3. 核心环节的实操细节与避坑经验3.1 需求拆解别让 Agent 直接读原始需求这是我踩过的第一个大坑。一开始我把客户给的 30 页需求文档直接丢给架构 Agent让它输出数据模型和接口设计。结果它生成的东西大方向没错但细节全是想当然——字段类型拍脑袋定、业务规则自己编、边界条件完全忽略。后来我改成了“人工预处理 Agent 细化”的模式我先花半天时间把需求文档里的核心业务实体和关键业务流程手动梳理出来把梳理结果作为“骨架”喂给 Agent让它在此基础上补充字段、生成接口我再逐条 review把不合理的打回去重生成这样做的好处是Agent 的发挥空间被限制在“细化”而不是“创造”上幻觉大幅减少。实测下来需求拆解阶段的时间从 3 天压缩到 1.5 天而且返工率明显下降。实操心得给 Agent 的输入越结构化它的输出越可靠。自然语言需求文档是“非结构化”的你必须先把它变成表格、列表、流程图再交给 Agent。3.2 接口契约冻结多 Agent 协作的“宪法”3 个 Agent 要协作最怕的是什么各干各的最后对不上。编码 Agent 以为用户 ID 是字符串审查 Agent 以为是整数集成的时候直接崩。所以我在第 1 周结束前强制做了一件事接口契约冻结。具体来说就是把所有对外接口的请求参数、响应结构、错误码全部定义清楚写成一份机器可读的契约文件我用的是 OpenAPI 规范。这份契约一旦冻结就成为 3 个 Agent 共同的“宪法”编码 Agent 按契约生成实现审查 Agent 按契约校验代码CI 流水线按契约做接口测试任何一方想改契约必须走变更流程重新生成受影响的代码。这个约束看起来死板但它避免了后期大量的“接口对不上”问题。3.3 编码阶段worktree 小步提交编码阶段是整个项目最耗时的部分也是 Agent 提效最明显的部分。我的做法是把每个业务模块拆成独立的 worktree 任务编码 Agent 在对应 worktree 里生成代码每完成一个小功能就提交一次触发 CICI 通过后审查 Agent 介入做逻辑 review这里的关键是小步提交。我试过让 Agent 一次性生成一个大模块结果 CI 报了几十个错排查起来极其痛苦。改成小步提交后每次只关注几个文件的改动问题定位快得多。还有一个细节Agent 生成的代码必须带注释。不是为了好看而是为了审查 Agent 能理解代码意图。我在 prompt 里明确要求“每个函数必须有说明其业务目的的注释”这样审查 Agent 在 review 时能快速判断逻辑是否正确。3.4 审查阶段人机分工的边界在哪审查 Agent 能干什么、不能干什么我摸索了整整一周才搞清楚。它能干的检查代码是否符合规范检查接口实现是否与契约一致检查是否有明显的空指针、越界等低级错误检查单元测试覆盖率是否达标它干不好的判断业务逻辑是否符合客户真实意图判断架构设计是否合理判断性能瓶颈在哪里所以我的分工是Agent 负责“形式正确”我负责“实质正确”。Agent 审查通过的代码我会再快速过一遍核心逻辑确认没有理解偏差。这个分工让我的 review 时间从每天 4 小时降到 1.5 小时左右。4. 常见问题与排查技巧实录4.1 Agent 生成“幻觉代码”怎么办这是最高频的问题。表现是代码语法正确、逻辑自洽但调用的方法不存在、引用的字段没定义、依赖的库没安装。我的排查思路是分三步看 CI 报错大部分幻觉代码会在编译或测试阶段暴露看契约校验接口对不上的契约校验会直接标红看依赖清单Agent 有时会“发明”不存在的依赖检查 package.json 或 pom.xml 能快速发现解决方法是在 prompt 里明确约束可用依赖。我维护了一份“允许使用的依赖清单”每次生成代码前都把它塞进上下文Agent 就不会乱引用了。4.2 CI 流水线跑得太慢怎么优化项目中期CI 一次要跑 8 分钟严重拖慢节奏。我做了三件事并行化lint、test、build 三个 stage 并行跑而不是串行缓存依赖把 node_modules 缓存起来避免每次重新安装增量测试只跑受影响的模块的测试而不是全量测试优化后 CI 时间降到 2 分半基本可以接受。4.3 多 Agent 上下文冲突怎么解当 3 个 Agent 同时工作时它们可能会对同一个文件产生不同的理解。我的解法是用文件锁 任务队列每个 worktree 同一时间只允许一个 Agent 操作任务按优先级排队避免并发冲突关键文件如契约文件设为只读只有我能改这套机制不复杂但能避免 90% 以上的并发问题。4.4 常见问题速查表问题现象可能原因排查方向解决手段代码编译不过幻觉依赖/方法看 CI 报错约束依赖清单接口对不上契约未同步看契约校验重新生成受影响代码测试覆盖率低Agent 偷懒看覆盖率报告prompt 强制要求CI 频繁失败提交粒度过大看提交记录改小步提交Agent 理解偏差上下文不足看检索结果优化 RAG 切块5. 交付后的复盘与个人体会项目最终按时上线客户验收通过。但复盘下来有几个点我觉得值得所有想用 AI Agent 做企业项目的人注意。第一AI Agent 不是用来替代人的是用来放大人的。我之所以能 3 周做完不是因为我什么都不干而是因为我把大量重复性、机械性的工作交给了 Agent自己专注于架构决策、业务理解和关键 review。如果我自己对业务一窍不通Agent 生成的东西我根本判断不了对错。第二工程规范比 Agent 本身更重要。worktree、CI、契约冻结、小步提交这些都不是 AI 时代的新东西但正是这些“老掉牙”的工程实践让 Agent 的产出变得可控。你如果连基本的版本管理和 CI 都没有直接上 Agent只会把混乱放大。第三RAG 知识库的质量决定 Agent 的上限。我花在整理知识库上的时间占了整个项目前期的一半。但这是值得的因为知识库越干净、越结构化Agent 的检索命中率越高生成的代码越靠谱。最后分享一个小技巧给每个 Agent 起个名字并且在 prompt 里明确它的角色边界。我管架构 Agent 叫“老架”编码 Agent 叫“小码”审查 Agent 叫“严审”。听起来有点中二但实测下来明确角色后Agent 的“越界行为”明显减少——它知道自己该干什么、不该干什么。这个项目之后我又用类似的方式接了 2 个活节奏越来越顺。但我也很清楚这套方法有它的适用边界需求相对明确、技术栈相对标准、团队有一定工程基础的项目效果最好。如果是那种需求天天变、技术栈极其冷门的项目AI Agent 的提效会大打折扣甚至可能帮倒忙。所以别盲目跟风先拿一个小项目试试水把 worktree、CI、RAG 这套基础设施跑通再考虑上大项目。这是我用 3 周时间换来的最实在的经验。