1. 先把这个项目的底牌摊开讲“3 个 AI Agent 交付一个企业项目4 人团队 2 个月我 3 周做完”——这句话我第一次看到的时候第一反应不是兴奋而是警惕。因为但凡在企业里真正交付过项目的人都知道工期压缩一半靠工具另一半靠的是把不确定性提前掐死。AI Agent 能帮你写代码、查资料、跑测试但它不会替你背锅也不会在需求评审会上帮你跟业务方扯皮。所以这个标题真正值得拆的不是“3 周做完”这个结果而是为什么 3 个 Agent 能顶住一个 4 人团队 2 个月的活以及这套东西到底怎么搭、怎么用、哪里会翻车。我先把结论放在前面这套方案的核心不是“让 AI 写代码”而是把交付流程拆成可并行、可验证、可回滚的单元然后让 Agent 去填那些重复度高、上下文明确、验收标准清晰的环节。人负责的是判断、取舍和兜底Agent 负责的是执行、检索和初筛。这个分工一旦错位比如让 Agent 去做需求决策或者让人去干重复的 CRUD效率立刻崩盘。这篇文章适合三类人看一是手里有企业项目、想试试 AI Agent 但不知道从哪下手的开发者二是团队小、工期紧、想用工具把人力杠杆撬起来的 Tech Lead三是已经在用 RAG、CI、code review 这些工具但还没把它们串成一条流水线的人。我会把整个项目的设计思路、Agent 分工、worktree 并行策略、CI 卡点、RAG 知识库搭建、以及我踩过的坑全部摊开讲。你看完不一定能 3 周做完但至少知道哪些地方能省、哪些地方不能省。2. 整体设计与思路拆解为什么是 3 个 Agent而不是 1 个或 5 个2.1 从“4 人 2 个月”倒推工作量结构一个典型的企业项目4 人 2 个月按每人每天有效产出 5 小时算大约是 4 × 40 天 × 5 小时 800 人时。这 800 小时里真正写核心业务逻辑的可能只占 30%剩下 70% 是需求理解与澄清、接口联调、数据迁移脚本、测试用例、code review、文档、环境配置、修 bug、以及各种“等别人回复”的阻塞时间。AI Agent 最擅长吃掉的恰恰是那 70% 里上下文明确、验收标准可量化的部分。比如根据 OpenAPI 文档生成接口调用代码和 mock 数据根据数据库 schema 生成 CRUD 和迁移脚本根据历史 code review 记录对 diff 做第一轮静态检查根据 RAG 知识库回答“这个字段的业务含义是什么”根据 CI 失败日志定位是依赖问题还是逻辑问题这些活人做不是不行而是切换成本高、重复度高、容易漏。Agent 做这些速度是人的 5 到 10 倍而且不会因为下午开了个会就忘了上午的上下文。2.2 为什么是 3 个 Agent而不是 1 个全能 Agent我试过用一个“全能 Agent”包打天下结果很惨。它一会儿要查业务文档一会儿要写代码一会儿要跑测试上下文窗口被塞得乱七八糟最后连“当前在改哪个模块”都搞混了。Agent 的数量不是越多越好而是按职责边界切分每个 Agent 的输入输出尽量正交。我最终定下来的 3 个 Agent 是Agent 代号职责核心输入核心输出对应热词ArchAgent需求解析与任务拆解需求文档、会议纪要、RAG 知识库任务卡片、接口契约、验收标准RAG、ontology ragCodeAgent代码生成与本地验证任务卡片、代码库、worktree可运行代码、单测、diffworktree、code reviewGateAgentCI 卡点与质量门禁diff、CI 日志、历史 review 记录审查意见、失败归因、回滚建议CI、github ci、gitlab ci这三个 Agent 的边界很清楚ArchAgent 不写代码CodeAgent 不做需求决策GateAgent 不直接改代码只给意见。这样每个 Agent 的 prompt 可以写得很窄准确率反而高。你如果非要用一个 Agent 干三件事那就得接受它每件事都干到 70 分而企业项目里 70 分往往等于返工。2.3 人在这套体系里到底干什么很多人以为上了 Agent 人就可以躺了恰恰相反。人的角色变成了定义验收标准、处理 Agent 之间的冲突、以及兜底那些 Agent 不敢碰的模糊地带。具体来说需求评审时人要把“用户能快速看到数据”翻译成“列表接口 P95 小于 200ms首屏渲染小于 1s”Agent 才能据此生成可验证的任务。CodeAgent 和 GateAgent 意见冲突时人要做最终裁决并把裁决结果写回 RAG 知识库让下次不再吵。涉及权限、资金、合规的逻辑人必须逐行 review不能交给 Agent 初筛就过。我个人的体会是Agent 把人的时间从“做”转移到了“判”。判比做累但判的杠杆率高得多。你判一次Agent 能执行一百次。3. 核心细节解析与实操要点worktree、CI、RAG 怎么串起来3.1 git worktree 与 git branch 的区别以及为什么并行开发必须用 worktree这是整个项目里最容易被忽略、但收益最大的一个点。很多人分不清git worktree和git branch我用人话解释一下git branch是逻辑上的分支指针你切换分支时工作区文件会被替换。同一时间你只能在一个分支上干活。git worktree是把同一个仓库的不同分支检出到不同的物理目录。你可以同时开着三个终端一个目录在改 feature A一个目录在改 feature B互不干扰。为什么这对 AI Agent 至关重要因为 CodeAgent 并行跑多个任务时如果共用一个工作区就会出现“Agent A 改了文件Agent B 读到的却是改了一半的版本”这种脏读会导致生成的代码完全错乱。用 worktree 之后每个 Agent 任务分配一个独立目录物理隔离谁也别碰谁。实操命令大概是这样# 主仓库在 /repo/main cd /repo/main git worktree add ../wt-task-101 -b task-101 git worktree add ../wt-task-102 -b task-102 git worktree add ../wt-task-103 -b task-103 # 每个 Agent 在自己的目录里干活 cd ../wt-task-101 codeagent run --task task-101注意worktree 不是免费的。每个 worktree 都会占一份磁盘空间而且 node_modules、venv 这类依赖目录不会自动共享。我的做法是把依赖目录做成软链接或者用 pnpm 的全局 store 来省空间。3.2 CI 卡点怎么设计才能让 GateAgent 真正拦住问题CI 不是“跑个测试就完事”。在这个项目里CI 承担的是GateAgent 的物理执行层。GateAgent 的审查意见再漂亮如果 CI 不执行等于没有。我把 CI 分成四道门静态检查门lint、类型检查、格式检查。这一层最快30 秒内出结果不过直接打回。单测门CodeAgent 生成的单测必须跑过覆盖率低于阈值直接失败。集成门起一个轻量环境跑接口契约测试确认 ArchAgent 定义的契约没被破坏。安全门依赖漏洞扫描、敏感信息扫描。这一层最慢但必须卡。GitHub CI 和 GitLab CI 我都用过核心逻辑一样区别在配置语法。GitHub 用.github/workflows/*.ymlGitLab 用.gitlab-ci.yml。我的建议是把 CI 配置也纳入 RAG 知识库这样 GateAgent 在给审查意见时能引用“根据 CI 第 3 条规则你这个改动会导致集成门失败”而不是干巴巴地说“我觉得有问题”。3.3 RAG 知识库到底存什么不存什么RAG 是这套体系里最容易做成“玩具”的部分。我见过太多人搭了个 RAG往里塞了一堆 PDF然后问它“我们项目的登录逻辑在哪”它给你编一段。问题不在 RAG在于你塞进去的东西本身就没有结构。我的 RAG 知识库只存四类内容接口契约OpenAPI 文档、字段业务含义、错误码表。这类内容结构化程度高检索准确率最高。历史 code review 记录把“这个写法为什么被拒”沉淀下来GateAgent 直接复用。CI 失败归因每次 CI 挂了人工写一句归因比如“依赖版本冲突需锁版本”。下次同类失败Agent 直接给建议。架构决策记录ADR为什么选 A 不选 B这类内容对 ArchAgent 拆任务极其重要。至于图片RAG 知识库能不能存图片技术上可以用多模态 embedding但我的经验是企业项目里图片检索的准确率远低于文本除非你有大量架构图需要按图搜图否则别折腾。把图里的关键信息用文字描述一遍存进去效果更好。3.4 ontology rag 和普通 RAG 的区别什么时候值得上普通 RAG 是“文本块 向量检索”ontology rag 是“实体 关系 向量检索”。区别在于普通 RAG 检索出来的是“相似的段落”ontology rag 检索出来的是“相关的实体及其关系”。举个例子你问“订单模块依赖哪些服务”。普通 RAG 可能返回一段提到订单和支付的文档但未必完整。ontology rag 里订单是一个实体它和支付、库存、用户之间有明确的依赖关系边检索时能沿着边把整条链路拉出来。什么时候值得上 ontology rag我的判断标准是如果你的项目里实体关系复杂、且跨模块查询频繁就值得。比如微服务架构、有几十个表和上百个接口的项目。如果只是个单体应用普通 RAG 加好的元数据过滤就够了。上 ontology 的成本不低要建本体、要维护关系别为了时髦硬上。4. 实操过程与核心环节实现从需求到交付的完整流水线4.1 第一步ArchAgent 把需求拆成可执行任务卡需求文档进来ArchAgent 的第一件事不是写代码而是输出任务卡。一张合格的任务卡包含任务 ID 和标题输入依赖哪些接口、哪些数据表、哪些配置输出改哪些文件、新增哪些文件、对外暴露什么验收标准可量化的测试点比如“输入 X 返回 Y”“并发 100 时无超时”风险标记是否涉及权限、资金、外部依赖我让 ArchAgent 用固定模板输出模板本身存在 RAG 里。这样每张任务卡格式一致CodeAgent 消费起来不需要额外解析。实测下来任务卡拆得越细CodeAgent 的首次通过率越高。一张卡如果超过 200 行代码量就该拆。4.2 第二步CodeAgent 在 worktree 里并行执行CodeAgent 拿到任务卡后流程是这样的从主仓库拉一个 worktree创建独立分支。读任务卡读相关代码文件读 RAG 里的接口契约。生成代码和单测。本地跑单测和 lint。通过后提交 diff交给 GateAgent。这里有个关键参数并行度。我一开始开了 6 个 worktree 并行跑结果机器 CPU 打满单测跑得比串行还慢。后来压到 3 个并行配合 16 核 32G 的机器吞吐最高。你可以用这个公式估算并行度 ≈ CPU 核数 / 每个任务平均核数占用。一般编译型语言每个任务吃 2 到 4 核解释型语言吃 1 到 2 核。4.3 第三步GateAgent 做第一轮 code reviewGateAgent 的审查不是“看一眼说不错”而是按规则逐条过。规则来自三处CI 配置、历史 review 记录、以及团队约定的编码规范。它的输出是一份结构化报告检查项结果依据建议命名规范通过规范第 3 条无空指针风险警告历史 review #221第 45 行加判空接口契约失败OpenAPI v2.3返回字段少了 createTime单测覆盖通过覆盖率 82%无人只需要看“失败”和“警告”这两栏通过的不用管。这一下就把 review 时间从每人 30 分钟压到 5 分钟。4.4 第四步CI 跑门禁失败自动归因CI 挂了不可怕可怕的是不知道为啥挂。我在 CI 脚本里加了一段逻辑失败时把日志尾部 200 行喂给 GateAgent让它输出归因。归因分三类环境问题依赖下载失败、端口占用。这类直接重试。代码问题编译错误、测试断言失败。这类打回 CodeAgent。契约问题接口不匹配、字段缺失。这类打回 ArchAgent 重新对齐。实测下来80% 的 CI 失败是环境问题重试就好。剩下 20% 里代码问题和契约问题各占一半。这个归因机制让平均修复时间从 40 分钟降到 12 分钟。4.5 第五步人做最终验收与知识沉淀Agent 跑完人做三件事抽查随机抽 20% 的 diff 逐行看重点看权限和资金相关。验收按任务卡的验收标准跑一遍确认达标。沉淀把这次的新决策、新坑、新规范写回 RAG。第三步最容易被跳过但它是让下一周比这一周快的关键。我坚持每次迭代结束花 30 分钟做沉淀三周下来RAG 里的有效条目从 40 条涨到 180 条CodeAgent 的首次通过率从 55% 涨到 78%。5. 常见问题与排查技巧实录5.1 Agent 之间上下文不一致怎么办这是最常见的问题。ArchAgent 说接口返回userIdCodeAgent 写成了user_idGateAgent 又按userId检查三方打架。根因是契约没有单一事实来源。我的解法是所有接口契约统一存在 RAG 的一个命名空间下任何 Agent 引用契约必须带版本号。契约变更必须走一次人工确认确认后版本号加一旧版本标记废弃。这样谁引用旧版本GateAgent 直接报错。5.2 RAG 检索不准Agent 答非所问先别怪模型先查三件事分块是否合理把 50 页的文档切成 500 字一块检索时经常切在句子中间。我的做法是按标题层级切每块带上级标题作为上下文。元数据是否齐全每块内容要带来源、版本、生效日期。检索时先按元数据过滤再按向量排序。是否有重复内容同一份文档存了三个版本检索出来互相矛盾。定期去重只留最新版。5.3 CI 太慢拖垮整体节奏CI 慢通常慢在依赖安装和全量测试。我的优化顺序是依赖缓存命中缓存后安装时间从 3 分钟降到 20 秒。测试分片把单测按模块拆成 4 片并行跑。增量测试只跑受影响的模块用 git diff 算出影响范围。这三招下来CI 从 12 分钟压到 3 分半。别小看这几分钟一天跑 20 次就是 3 小时的差距。5.4 Agent 生成的代码能直接上生产吗不能。我的底线是Agent 生成的代码必须经过人 review 才能合并到主分支。GateAgent 只是初筛它拦得住语法错误和契约问题拦不住业务逻辑错误。尤其是涉及金额计算、权限判断、状态机流转的地方人必须逐行看。我踩过一次坑CodeAgent 把“退款金额不能超过订单金额”写成了“不能超过订单金额的 1.1 倍”GateAgent 没查出来因为这条规则不在 RAG 里。后来我把所有业务规则都补进 RAG这类问题才绝迹。5.5 常见问题速查表现象可能原因排查动作解决方式Agent 输出格式错乱prompt 模板被污染检查模板文件回滚模板加格式校验worktree 切换报错分支已被占用git worktree list清理无用 worktreeCI 缓存不生效缓存 key 含随机值检查 cache key用依赖文件 hash 做 keyRAG 返回旧版本元数据未更新查生效日期字段重建索引标记废弃GateAgent 漏报规则未覆盖对比历史 review补规则进 RAG6. 这套方案能复制到什么程度我把这套东西跑通之后最大的感受是AI Agent 不是魔法它是一面镜子照出你流程里本来就不清晰的地方。你需求拆得越细它干得越好你契约定得越死它错得越少你 CI 卡得越严它越不敢乱来。反过来如果你自己都不知道要做什么Agent 只会把混乱放大十倍。至于“3 周做完 4 人 2 个月的活”我的真实数据是核心功能 3 周交付但后续的联调、压测、上线准备又花了 1 周半。所以严格说是 4 周半不是 3 周。标题嘛总要有点冲击力。但即便 4 周半相比 2 个月也是实打实的压缩。最后分享一个我一直在用的小技巧每次 Agent 犯错不要只修代码要把错误原因写成一条 RAG 规则。比如“CodeAgent 把分页参数默认值写成 10但业务要求是 20”就把“分页默认值 20”写进契约。这样下次它就不会再错。三周下来我的 RAG 规则库从 40 条涨到 180 条Agent 的首次通过率从 55% 涨到 78%。这个数字还会涨因为规则在积累而人的时间被省下来了。