尧图网站建设 
1. 一个人三周干完四人两个月的活到底省在哪了先把结论摆在前面这个项目能压缩到三周靠的不是让 AI Agent 替我写代码那么简单而是把整个交付流程里最耗人的几个环节——需求拆解、并行开发、代码审查、知识检索——全部重新编排了一遍。四人团队两个月的工作量折算下来大约是 320 人时。我一个人三周按每天有效投入 6 小时算也就 90 人时左右。中间那 230 人时的差额就是这篇文章要拆的东西。先说清楚这个项目的背景。这是一个企业内部管理系统包含权限模块、审批流、数据看板、报表导出四块核心功能技术栈是 Spring Boot 后端加 Vue 前端数据库用 MySQL部署走 GitLab CI。团队原本的排期是四个人并行开发两个月其中后端两人、前端一人、测试一人。我接手之后用三个 AI Agent 分别承担后端接口生成、前端组件生成、测试用例生成自己只做架构决策、关键逻辑审核和集成联调。这里有个很多人会误解的点AI Agent 不是帮你写代码的工具它更像是一个能独立完成子任务的虚拟同事。区别在于你得给它足够清晰的边界和上下文否则它产出的东西你改起来比自己写还慢。我见过太多人把 Agent 当成高级代码补全来用结果就是生成一堆看起来能跑、实际上到处是坑的代码最后返工的时间比省下来的还多。所以这篇文章不讲AI 多厉害讲的是怎么把一个企业项目拆成 Agent 能接住的粒度怎么让三个 Agent 并行不打架怎么在 CI 和 code review 环节把住质量关以及 RAG 知识库在整个流程里扮演什么角色。适合有一定工程经验、想真正把 AI Agent 用进实际交付的开发者也适合正在评估AI 能不能替代部分人力的技术负责人。我踩过的坑不少有些是工具本身的限制有些是我自己编排流程时的失误。下面按实际推进的顺序一块一块拆开讲。2. 三个 Agent 的分工边界为什么不是越多越好2.1 从一个全能 Agent到三个专精 Agent的取舍最开始我试过用一个 Agent 干所有事。给它一个完整的模块需求让它同时生成后端接口、前端页面和测试用例。结果非常糟糕生成的代码风格前后不一致后端返回的数据结构和前端期望的对不上测试用例覆盖的路径和实际接口逻辑有偏差。原因很简单——一个 Agent 在一次对话里要同时维护三套上下文它的注意力被稀释了。后来我改成三个 Agent每个只负责一个层面后端 Agent输入是接口文档和数据库表结构输出是 Controller、Service、Mapper 三层代码以及对应的单元测试。前端 Agent输入是页面原型和接口契约输出是 Vue 组件、API 调用层和表单校验逻辑。测试 Agent输入是接口契约和业务规则输出是集成测试用例和边界条件测试。这三个 Agent 之间不直接通信它们通过接口契约这个中间产物来对齐。接口契约是我手写的用 OpenAPI 格式定义包含每个接口的路径、方法、请求体、响应体、错误码。这份契约是整个项目的宪法三个 Agent 都基于它工作谁也不能偏离。提示接口契约一定要自己写不要让 Agent 生成。契约是三个 Agent 协作的唯一对齐点一旦契约本身有歧义后面所有产出都会跟着歪。2.2 为什么是三个而不是五个或两个有人会问既然专精更好为什么不拆成五个 Agent比如把数据库操作单独拆出来我的实测结论是Agent 数量要和上下文隔离的必要性匹配而不是越多越好。拆成五个的问题是Agent 之间的接口变多了。三个 Agent 有 3 对协作关系五个 Agent 就有 10 对。每多一对协作关系就多一个对齐成本和出错点。数据库操作和后端逻辑耦合太紧拆开之后后端 Agent 生成 Service 时还得等数据库 Agent 先产出 Mapper串行化了反而慢。两个 Agent 也不够。后端和前端必须分开因为它们的上下文差异太大——后端关心事务、并发、数据一致性前端关心渲染、交互、状态管理。硬塞进一个 Agent它会在两种思维模式之间反复切换产出质量明显下降。三个是刚好能覆盖后端逻辑、前端交互、质量验证这三个正交维度的最小数量。测试 Agent 单独拆出来是因为测试的思维方式和开发完全不同——开发想的是怎么让功能跑通测试想的是怎么让它跑不通。这两种思维放在一个 Agent 里会互相干扰。2.3 Agent 之间的交接棒怎么设计三个 Agent 并行工作最大的风险是各干各的最后合不上。我的做法是设置三个同步点同步点触发时机检查内容不通过的后果契约冻结开发开始前接口路径、字段类型、错误码是否完整不允许开工契约变更任一 Agent 需要改契约变更是否影响其他两方三方重新对齐集成验证各自产出完成后前后端联调、测试用例执行打回对应 Agent 重做契约冻结这一步特别关键。我在第一个模块上偷懒契约只写了个大概就开工了结果后端 Agent 把某个字段定义成Integer前端 Agent 理解成String联调的时候报了一堆类型错误。后来我强制要求契约必须精确到字段类型和是否可空这类问题就再没出现过。契约变更的处理也有讲究。开发过程中需求微调是常事但不能让某个 Agent 自己改了契约就继续干。我的规则是任何契约变更都要先停下来评估影响范围然后三个 Agent 一起更新。听起来很重但实际上变更频率很低而且每次变更如果不同步后面返工的代价远大于停下来对齐的成本。3. git worktree 撑起并行开发和 branch 到底差在哪3.1 为什么 branch 不够用非要上 worktree三个 Agent 并行工作意味着同一时间有三份代码在被修改。如果用传统的git branch你只能在一个工作目录里来回切换分支。Agent A 在写后端的时候工作目录里是后端分支的代码Agent B 要写前端就得先git checkout到前端分支。这个切换过程会打断 Agent 的工作流而且切换时如果有未提交的改动还得先 stash非常麻烦。git worktree解决的就是这个问题。它允许你把同一个仓库的多个分支同时检出到不同的目录。也就是说后端 Agent 在/work/backend目录里改后端分支前端 Agent 在/work/frontend目录里改前端分支测试 Agent 在/work/test目录里改测试分支三个目录互不干扰共享同一个.git仓库。# 在主仓库里创建三个 worktree git worktree add ../work-backend feature/backend git worktree add ../work-frontend feature/frontend git worktree add ../work-test feature/test # 查看当前所有 worktree git worktree list这样每个 Agent 在自己的目录里独立工作提交、切换、回滚都不影响别人。等各自完成后再通过 merge 或 rebase 合并到主分支。3.2 worktree 和 branch 的本质区别很多人搞不清 worktree 和 branch 的关系我用一句话说清楚branch 是提交历史的分叉worktree 是工作目录的分身。一个 branch 可以对应零个、一个或多个 worktree。默认情况下你 clone 一个仓库主分支对应一个 worktree就是你的工作目录。当你git worktree add的时候你是在为某个分支再创建一个工作目录。同一个分支不能同时被两个 worktree 检出这是 Git 的限制也是合理的——否则两个目录同时改同一个分支冲突无法处理。维度git branchgit worktree作用对象提交历史工作目录能否同时检出同一分支只能在一个目录不同分支可在不同目录切换成本需要 checkout可能 stash无需切换直接进对应目录适用场景单人开发、串行任务多人/多 Agent 并行磁盘占用共享仓库每个 worktree 有独立工作文件对 AI Agent 场景来说worktree 的价值在于消除了上下文切换的成本。Agent 不需要知道现在该切到哪个分支它只需要在自己的目录里持续工作。我实测下来用 worktree 之后三个 Agent 的并行效率比用 branch 切换高了大概 40%主要省在不用反复 stash 和 checkout 上。3.3 worktree 使用中的几个坑第一个坑是目录规划。worktree 的目录最好放在主仓库的同级或专门的worktrees/目录下不要放在仓库内部否则 Git 会把 worktree 目录当成未跟踪文件git status会很难看。第二个坑是清理。Agent 完成任务后对应的 worktree 要记得删掉否则会残留一堆目录。删除命令是git worktree remove ../work-backend如果目录里有未提交的改动需要加--force。第三个坑是分支冲突。如果两个 Agent 不小心检出了同一个分支Git 会直接报错。这个反而是好事能提前发现问题。我在流程里规定每个 Agent 的分支名必须带前缀feature/backend-、feature/frontend-从命名上就避免撞车。注意worktree 不是万能的。如果两个 Agent 需要修改同一批文件worktree 也救不了你该冲突还是冲突。所以拆分任务时要尽量让不同 Agent 负责不同的文件集合。4. CI 流水线怎么接住 Agent 的产出4.1 Agent 生成的代码CI 要检查什么Agent 生成的代码有个特点表面看起来都很规范但细节上容易出问题。比如命名风格统一但不符合项目规范异常处理写了但吞掉了关键错误日志打了但泄露了敏感信息。所以 CI 不能只跑单元测试要加几道针对性的检查。我的 GitLab CI 流水线分四个阶段stages: - lint - test - security - build lint: stage: lint script: - mvn checkstyle:check - mvn spotbugs:check - npm run lint test: stage: test script: - mvn test - npm run test:unit security: stage: security script: - mvn dependency-check:check - grep -rn password\|secret\|token src/ || true build: stage: build script: - mvn package -DskipTests - npm run buildlint 阶段用 Checkstyle 和 SpotBugs 检查代码规范前端用 ESLint。这一步能拦住大部分 Agent 生成的风格漂移问题。test 阶段跑单元测试覆盖率低于 70% 直接失败。security 阶段做依赖漏洞扫描和敏感信息扫描后者是我专门加的因为 Agent 有时候会把示例里的假密码写进代码。4.2 为什么 CI 反馈要快而准Agent 的工作模式是生成-验证-修正的循环。如果 CI 反馈太慢Agent 就得干等着并行效率大打折扣。我的做法是把 CI 拆成快速检查和完整检查两层快速检查只跑 lint 和单元测试控制在 3 分钟内。Agent 每次提交都触发。完整检查跑安全扫描和构建控制在 10 分钟内。合并到主分支前触发。快速检查的 3 分钟是硬指标。我试过把安全扫描也放进快速检查结果每次要等 8 分钟Agent 的并行度直接掉了一半。后来拆开之后Agent 的迭代速度明显上来了。还有一个细节CI 的失败信息要结构化。默认的 CI 日志是一大坨文本Agent 读起来很费劲。我在流水线里加了一步把失败信息解析成 JSON 格式包含文件路径、行号、错误类型、错误描述。Agent 拿到这个 JSON能直接定位到问题不用在日志里大海捞针。4.3 code review 环节人要看什么CI 能拦住机器能判断的问题但有些东西必须人来看。我在 code review 环节重点关注三类第一类是业务逻辑的正确性。Agent 能写出语法正确的代码但它不理解业务。比如审批流里的会签和或签Agent 可能都实现成一样的逻辑但实际业务里这两个完全不同。这类问题 CI 测不出来必须人看。第二类是边界条件的处理。Agent 生成的代码往往只处理正常路径对空值、超长输入、并发冲突这些边界情况考虑不足。我会专门检查每个接口的参数校验和异常分支。第三类是架构一致性。Agent 可能用了一种新的设计模式虽然能跑但和项目现有架构不一致。比如项目里统一用ResponseEntity包装响应Agent 却直接返回了对象。这类问题不影响功能但会破坏代码的一致性。提示code review 不要试图看完所有代码。我的做法是让 Agent 自己生成一份变更摘要列出每个文件的改动点和理由我只审查摘要里标记为高风险的部分。这样能把 review 时间压缩到原来的三分之一。5. RAG 知识库让 Agent 记住项目规范5.1 为什么 Agent 需要 RAGAgent 的上下文窗口是有限的。一个企业项目的代码规范、接口约定、历史决策加起来可能几十万字不可能全部塞进 prompt。而且每次对话都塞一遍token 成本高得离谱。RAG检索增强生成解决的就是这个问题。它把项目知识存进向量数据库Agent 需要的时候根据当前任务检索相关片段只把最相关的部分塞进 prompt。这样既保证了 Agent 能拿到需要的上下文又控制了 token 消耗。我搭的 RAG 知识库包含四类内容代码规范命名约定、分层规则、异常处理规范、日志规范。接口契约所有接口的 OpenAPI 定义按模块分片存储。历史决策项目过程中做过的技术选型和理由比如为什么用 MyBatis 而不是 JPA。常见问题踩过的坑和解决方案比如分页查询的 count 语句要单独优化。5.2 RAG 知识库能存图片吗这是热词里被问得很多的一个问题。答案是能存但检索效果取决于你的方案。纯文本的 RAG 是把文本切片、向量化、存进向量库。图片不能直接向量化需要先转成文本描述。有两种做法第一种是用多模态模型给图片生成描述把描述文本存进向量库。比如一张架构图生成描述这是三层架构图上层是 Controller中层是 Service下层是 Mapper检索时匹配的是这段描述。缺点是描述可能丢失图片里的细节。第二种是把图片和文本一起存进支持多模态的向量库检索时同时匹配文本和图片特征。这种方式效果更好但对向量库的要求更高成本也更大。我的项目里图片不多用的是第一种方案。架构图和流程图用多模态模型生成描述后存入检索时能命中。但如果你的项目里有大量设计稿、UI 图建议用第二种方案或者干脆把图片单独管理RAG 只负责文本部分。5.3 RAG 的瓶颈在哪用了几个月我总结出 RAG 的三个主要瓶颈第一个瓶颈是切片策略。切片太粗检索出来的内容包含大量无关信息浪费 token切片太细又可能丢失上下文检索出来的片段不完整。我的经验是代码类知识按函数或类切片文档类知识按段落切片切片之间保留 20% 的重叠。第二个瓶颈是检索精度。向量检索是基于语义相似度的但语义相似不等于真正相关。比如你搜分页查询优化可能检索出一堆查询优化的通用建议但真正需要的是项目里那条具体的分页规范。解决办法是混合检索——向量检索加关键词检索两者结果加权排序。第三个瓶颈是知识更新。项目在推进规范在变化RAG 知识库如果不同步更新Agent 就会拿到过时的信息。我的做法是把知识库的更新也纳入 CI 流程每次代码合并时自动检查是否有规范文档变更有的话触发知识库重建。瓶颈表现我的应对方案切片策略检索结果太长或太碎按内容类型分片保留重叠检索精度语义相似但不相关向量关键词混合检索知识更新Agent 用过时信息知识库更新纳入 CI6. 三周交付的完整时间线复盘6.1 第一周契约冻结和基础设施搭建第一周基本没写业务代码全在搭架子。周一和周二梳理需求把四个模块的功能点拆成 47 个接口写成 OpenAPI 契约。周三搭 worktree 环境配好三个 Agent 的工作目录和分支。周四搭 RAG 知识库把代码规范和接口契约灌进去。周五配 CI 流水线跑通 lint 和 test 两个阶段。这一周看起来没产出但恰恰是最关键的。我见过太多项目一上来就写代码写到一半发现接口对不上返工的时间远超前期规划的时间。契约冻结这一步把后面可能出现的对齐问题提前消灭了。6.2 第二周三个 Agent 并行冲刺第二周是产出最密集的一周。三个 Agent 同时开工后端 Agent 生成接口和 Service前端 Agent 生成页面和组件测试 Agent 生成用例。我每天做三件事早上检查前一天的 CI 结果中午做 code review晚上处理 Agent 之间的契约变更。这一周遇到的最大问题是测试 Agent 的用例覆盖不全。它生成的用例大多覆盖正常路径对异常路径覆盖不足。我的解决办法是给它一份异常场景清单明确列出每个接口需要测试的异常情况比如参数为空、参数超长、并发冲突、权限不足。有了这份清单测试覆盖率从 62% 提到了 85%。6.3 第三周集成联调和收尾第三周主要是联调和修 bug。前后端对接的时候发现了一些契约里没定义清楚的细节比如时间字段的格式、枚举值的映射。这些问题在契约里补上之后让对应的 Agent 重新生成相关代码。联调阶段我还做了一件事让测试 Agent 生成端到端的集成测试。这些测试模拟真实用户操作从登录开始走完整个审批流程验证数据看板的数字是否正确。这类测试跑起来慢但能发现单元测试发现不了的问题。三周下来最终交付的代码量大约是 18000 行其中 Agent 生成的部分占 75%我手写的部分占 25%主要是契约、关键业务逻辑和集成代码。bug 数量比预期少上线后第一周只收到 3 个问题反馈都是边界情况当天就修完了。7. 几个让我少走弯路的关键决策7.1 契约先行宁可慢一天也不省这一步前面反复提契约这里再强调一次。契约不是文档是三个 Agent 之间的通信协议。协议不清楚通信就会出错。我在第一个模块上省了这一步结果返工了两天。后面三个模块老老实实先写契约每个模块省下的返工时间至少一天。写契约的时候有个技巧把错误码也定义清楚。Agent 生成异常处理代码时如果不知道有哪些错误码就会自己编一套导致前后端对不上。我在契约里定义了统一的错误码规范比如 40001 表示参数错误40003 表示权限不足50001 表示系统异常。Agent 照着这个规范生成前后端的错误处理就对齐了。7.2 Agent 的产出必须过 CI不能靠看起来对Agent 生成的代码有个迷惑性它看起来很规范命名整齐注释齐全容易让人放松警惕。但看起来对和实际对是两回事。我坚持所有 Agent 产出必须过 CIlint 不过、测试不过一律打回重做。这个原则救了我好几次。有一次后端 Agent 生成了一个查询接口逻辑看起来没问题但 CI 的 SpotBugs 检查报了一个可能的空指针警告。我一看果然在某个分支下会返回 null前端没做判空处理。如果靠人眼看这种问题很容易漏掉。7.3 人的价值在决策不在敲代码三周做完这个项目我最大的体会是AI Agent 替代的是执行不是决策。契约怎么定、架构怎么分层、异常怎么处理、哪些边界要考虑这些决策还是得人来做。Agent 能把你从重复的编码劳动里解放出来但前提是你得知道要它做什么。我见过一些人用 Agent 的方式是给个需求等它生成然后改改就用。这种方式在简单任务上可行但在企业项目里会出大问题。企业项目的复杂度不在于代码本身而在于业务规则、历史包袱、团队约定这些隐性知识。这些知识 Agent 不知道得你来告诉它或者通过 RAG 喂给它。所以我的建议是把 Agent 当成一个执行力很强但需要明确指令的初级工程师。你给它的指令越清晰它的产出越好。你偷懒省掉的思考最后都会变成返工的时间还回来。最后分享一个我在实操中总结的小技巧给每个 Agent 建一个工作日志。每次它完成任务后让它自己记录这次做了什么、遇到什么问题、怎么解决的。这些日志积累起来一方面能帮你复盘另一方面可以喂回 RAG 知识库让后续的任务检索到这些经验。我用这个方法让 Agent 在第三个模块上的产出质量明显高于第一个模块因为它记住了前面踩过的坑。 AI Agent 三周交付企业项目：契约先行、worktree 并行与 RAG 知识库实战
1. 一个人三周干完四人两个月的活到底省在哪了先把结论摆在前面这个项目能压缩到三周靠的不是让 AI Agent 替我写代码那么简单而是把整个交付流程里最耗人的几个环节——需求拆解、并行开发、代码审查、知识检索——全部重新编排了一遍。四人团队两个月的工作量折算下来大约是 320 人时。我一个人三周按每天有效投入 6 小时算也就 90 人时左右。中间那 230 人时的差额就是这篇文章要拆的东西。先说清楚这个项目的背景。这是一个企业内部管理系统包含权限模块、审批流、数据看板、报表导出四块核心功能技术栈是 Spring Boot 后端加 Vue 前端数据库用 MySQL部署走 GitLab CI。团队原本的排期是四个人并行开发两个月其中后端两人、前端一人、测试一人。我接手之后用三个 AI Agent 分别承担后端接口生成、前端组件生成、测试用例生成自己只做架构决策、关键逻辑审核和集成联调。这里有个很多人会误解的点AI Agent 不是帮你写代码的工具它更像是一个能独立完成子任务的虚拟同事。区别在于你得给它足够清晰的边界和上下文否则它产出的东西你改起来比自己写还慢。我见过太多人把 Agent 当成高级代码补全来用结果就是生成一堆看起来能跑、实际上到处是坑的代码最后返工的时间比省下来的还多。所以这篇文章不讲AI 多厉害讲的是怎么把一个企业项目拆成 Agent 能接住的粒度怎么让三个 Agent 并行不打架怎么在 CI 和 code review 环节把住质量关以及 RAG 知识库在整个流程里扮演什么角色。适合有一定工程经验、想真正把 AI Agent 用进实际交付的开发者也适合正在评估AI 能不能替代部分人力的技术负责人。我踩过的坑不少有些是工具本身的限制有些是我自己编排流程时的失误。下面按实际推进的顺序一块一块拆开讲。2. 三个 Agent 的分工边界为什么不是越多越好2.1 从一个全能 Agent到三个专精 Agent的取舍最开始我试过用一个 Agent 干所有事。给它一个完整的模块需求让它同时生成后端接口、前端页面和测试用例。结果非常糟糕生成的代码风格前后不一致后端返回的数据结构和前端期望的对不上测试用例覆盖的路径和实际接口逻辑有偏差。原因很简单——一个 Agent 在一次对话里要同时维护三套上下文它的注意力被稀释了。后来我改成三个 Agent每个只负责一个层面后端 Agent输入是接口文档和数据库表结构输出是 Controller、Service、Mapper 三层代码以及对应的单元测试。前端 Agent输入是页面原型和接口契约输出是 Vue 组件、API 调用层和表单校验逻辑。测试 Agent输入是接口契约和业务规则输出是集成测试用例和边界条件测试。这三个 Agent 之间不直接通信它们通过接口契约这个中间产物来对齐。接口契约是我手写的用 OpenAPI 格式定义包含每个接口的路径、方法、请求体、响应体、错误码。这份契约是整个项目的宪法三个 Agent 都基于它工作谁也不能偏离。提示接口契约一定要自己写不要让 Agent 生成。契约是三个 Agent 协作的唯一对齐点一旦契约本身有歧义后面所有产出都会跟着歪。2.2 为什么是三个而不是五个或两个有人会问既然专精更好为什么不拆成五个 Agent比如把数据库操作单独拆出来我的实测结论是Agent 数量要和上下文隔离的必要性匹配而不是越多越好。拆成五个的问题是Agent 之间的接口变多了。三个 Agent 有 3 对协作关系五个 Agent 就有 10 对。每多一对协作关系就多一个对齐成本和出错点。数据库操作和后端逻辑耦合太紧拆开之后后端 Agent 生成 Service 时还得等数据库 Agent 先产出 Mapper串行化了反而慢。两个 Agent 也不够。后端和前端必须分开因为它们的上下文差异太大——后端关心事务、并发、数据一致性前端关心渲染、交互、状态管理。硬塞进一个 Agent它会在两种思维模式之间反复切换产出质量明显下降。三个是刚好能覆盖后端逻辑、前端交互、质量验证这三个正交维度的最小数量。测试 Agent 单独拆出来是因为测试的思维方式和开发完全不同——开发想的是怎么让功能跑通测试想的是怎么让它跑不通。这两种思维放在一个 Agent 里会互相干扰。2.3 Agent 之间的交接棒怎么设计三个 Agent 并行工作最大的风险是各干各的最后合不上。我的做法是设置三个同步点同步点触发时机检查内容不通过的后果契约冻结开发开始前接口路径、字段类型、错误码是否完整不允许开工契约变更任一 Agent 需要改契约变更是否影响其他两方三方重新对齐集成验证各自产出完成后前后端联调、测试用例执行打回对应 Agent 重做契约冻结这一步特别关键。我在第一个模块上偷懒契约只写了个大概就开工了结果后端 Agent 把某个字段定义成Integer前端 Agent 理解成String联调的时候报了一堆类型错误。后来我强制要求契约必须精确到字段类型和是否可空这类问题就再没出现过。契约变更的处理也有讲究。开发过程中需求微调是常事但不能让某个 Agent 自己改了契约就继续干。我的规则是任何契约变更都要先停下来评估影响范围然后三个 Agent 一起更新。听起来很重但实际上变更频率很低而且每次变更如果不同步后面返工的代价远大于停下来对齐的成本。3. git worktree 撑起并行开发和 branch 到底差在哪3.1 为什么 branch 不够用非要上 worktree三个 Agent 并行工作意味着同一时间有三份代码在被修改。如果用传统的git branch你只能在一个工作目录里来回切换分支。Agent A 在写后端的时候工作目录里是后端分支的代码Agent B 要写前端就得先git checkout到前端分支。这个切换过程会打断 Agent 的工作流而且切换时如果有未提交的改动还得先 stash非常麻烦。git worktree解决的就是这个问题。它允许你把同一个仓库的多个分支同时检出到不同的目录。也就是说后端 Agent 在/work/backend目录里改后端分支前端 Agent 在/work/frontend目录里改前端分支测试 Agent 在/work/test目录里改测试分支三个目录互不干扰共享同一个.git仓库。# 在主仓库里创建三个 worktree git worktree add ../work-backend feature/backend git worktree add ../work-frontend feature/frontend git worktree add ../work-test feature/test # 查看当前所有 worktree git worktree list这样每个 Agent 在自己的目录里独立工作提交、切换、回滚都不影响别人。等各自完成后再通过 merge 或 rebase 合并到主分支。3.2 worktree 和 branch 的本质区别很多人搞不清 worktree 和 branch 的关系我用一句话说清楚branch 是提交历史的分叉worktree 是工作目录的分身。一个 branch 可以对应零个、一个或多个 worktree。默认情况下你 clone 一个仓库主分支对应一个 worktree就是你的工作目录。当你git worktree add的时候你是在为某个分支再创建一个工作目录。同一个分支不能同时被两个 worktree 检出这是 Git 的限制也是合理的——否则两个目录同时改同一个分支冲突无法处理。维度git branchgit worktree作用对象提交历史工作目录能否同时检出同一分支只能在一个目录不同分支可在不同目录切换成本需要 checkout可能 stash无需切换直接进对应目录适用场景单人开发、串行任务多人/多 Agent 并行磁盘占用共享仓库每个 worktree 有独立工作文件对 AI Agent 场景来说worktree 的价值在于消除了上下文切换的成本。Agent 不需要知道现在该切到哪个分支它只需要在自己的目录里持续工作。我实测下来用 worktree 之后三个 Agent 的并行效率比用 branch 切换高了大概 40%主要省在不用反复 stash 和 checkout 上。3.3 worktree 使用中的几个坑第一个坑是目录规划。worktree 的目录最好放在主仓库的同级或专门的worktrees/目录下不要放在仓库内部否则 Git 会把 worktree 目录当成未跟踪文件git status会很难看。第二个坑是清理。Agent 完成任务后对应的 worktree 要记得删掉否则会残留一堆目录。删除命令是git worktree remove ../work-backend如果目录里有未提交的改动需要加--force。第三个坑是分支冲突。如果两个 Agent 不小心检出了同一个分支Git 会直接报错。这个反而是好事能提前发现问题。我在流程里规定每个 Agent 的分支名必须带前缀feature/backend-、feature/frontend-从命名上就避免撞车。注意worktree 不是万能的。如果两个 Agent 需要修改同一批文件worktree 也救不了你该冲突还是冲突。所以拆分任务时要尽量让不同 Agent 负责不同的文件集合。4. CI 流水线怎么接住 Agent 的产出4.1 Agent 生成的代码CI 要检查什么Agent 生成的代码有个特点表面看起来都很规范但细节上容易出问题。比如命名风格统一但不符合项目规范异常处理写了但吞掉了关键错误日志打了但泄露了敏感信息。所以 CI 不能只跑单元测试要加几道针对性的检查。我的 GitLab CI 流水线分四个阶段stages: - lint - test - security - build lint: stage: lint script: - mvn checkstyle:check - mvn spotbugs:check - npm run lint test: stage: test script: - mvn test - npm run test:unit security: stage: security script: - mvn dependency-check:check - grep -rn password\|secret\|token src/ || true build: stage: build script: - mvn package -DskipTests - npm run buildlint 阶段用 Checkstyle 和 SpotBugs 检查代码规范前端用 ESLint。这一步能拦住大部分 Agent 生成的风格漂移问题。test 阶段跑单元测试覆盖率低于 70% 直接失败。security 阶段做依赖漏洞扫描和敏感信息扫描后者是我专门加的因为 Agent 有时候会把示例里的假密码写进代码。4.2 为什么 CI 反馈要快而准Agent 的工作模式是生成-验证-修正的循环。如果 CI 反馈太慢Agent 就得干等着并行效率大打折扣。我的做法是把 CI 拆成快速检查和完整检查两层快速检查只跑 lint 和单元测试控制在 3 分钟内。Agent 每次提交都触发。完整检查跑安全扫描和构建控制在 10 分钟内。合并到主分支前触发。快速检查的 3 分钟是硬指标。我试过把安全扫描也放进快速检查结果每次要等 8 分钟Agent 的并行度直接掉了一半。后来拆开之后Agent 的迭代速度明显上来了。还有一个细节CI 的失败信息要结构化。默认的 CI 日志是一大坨文本Agent 读起来很费劲。我在流水线里加了一步把失败信息解析成 JSON 格式包含文件路径、行号、错误类型、错误描述。Agent 拿到这个 JSON能直接定位到问题不用在日志里大海捞针。4.3 code review 环节人要看什么CI 能拦住机器能判断的问题但有些东西必须人来看。我在 code review 环节重点关注三类第一类是业务逻辑的正确性。Agent 能写出语法正确的代码但它不理解业务。比如审批流里的会签和或签Agent 可能都实现成一样的逻辑但实际业务里这两个完全不同。这类问题 CI 测不出来必须人看。第二类是边界条件的处理。Agent 生成的代码往往只处理正常路径对空值、超长输入、并发冲突这些边界情况考虑不足。我会专门检查每个接口的参数校验和异常分支。第三类是架构一致性。Agent 可能用了一种新的设计模式虽然能跑但和项目现有架构不一致。比如项目里统一用ResponseEntity包装响应Agent 却直接返回了对象。这类问题不影响功能但会破坏代码的一致性。提示code review 不要试图看完所有代码。我的做法是让 Agent 自己生成一份变更摘要列出每个文件的改动点和理由我只审查摘要里标记为高风险的部分。这样能把 review 时间压缩到原来的三分之一。5. RAG 知识库让 Agent 记住项目规范5.1 为什么 Agent 需要 RAGAgent 的上下文窗口是有限的。一个企业项目的代码规范、接口约定、历史决策加起来可能几十万字不可能全部塞进 prompt。而且每次对话都塞一遍token 成本高得离谱。RAG检索增强生成解决的就是这个问题。它把项目知识存进向量数据库Agent 需要的时候根据当前任务检索相关片段只把最相关的部分塞进 prompt。这样既保证了 Agent 能拿到需要的上下文又控制了 token 消耗。我搭的 RAG 知识库包含四类内容代码规范命名约定、分层规则、异常处理规范、日志规范。接口契约所有接口的 OpenAPI 定义按模块分片存储。历史决策项目过程中做过的技术选型和理由比如为什么用 MyBatis 而不是 JPA。常见问题踩过的坑和解决方案比如分页查询的 count 语句要单独优化。5.2 RAG 知识库能存图片吗这是热词里被问得很多的一个问题。答案是能存但检索效果取决于你的方案。纯文本的 RAG 是把文本切片、向量化、存进向量库。图片不能直接向量化需要先转成文本描述。有两种做法第一种是用多模态模型给图片生成描述把描述文本存进向量库。比如一张架构图生成描述这是三层架构图上层是 Controller中层是 Service下层是 Mapper检索时匹配的是这段描述。缺点是描述可能丢失图片里的细节。第二种是把图片和文本一起存进支持多模态的向量库检索时同时匹配文本和图片特征。这种方式效果更好但对向量库的要求更高成本也更大。我的项目里图片不多用的是第一种方案。架构图和流程图用多模态模型生成描述后存入检索时能命中。但如果你的项目里有大量设计稿、UI 图建议用第二种方案或者干脆把图片单独管理RAG 只负责文本部分。5.3 RAG 的瓶颈在哪用了几个月我总结出 RAG 的三个主要瓶颈第一个瓶颈是切片策略。切片太粗检索出来的内容包含大量无关信息浪费 token切片太细又可能丢失上下文检索出来的片段不完整。我的经验是代码类知识按函数或类切片文档类知识按段落切片切片之间保留 20% 的重叠。第二个瓶颈是检索精度。向量检索是基于语义相似度的但语义相似不等于真正相关。比如你搜分页查询优化可能检索出一堆查询优化的通用建议但真正需要的是项目里那条具体的分页规范。解决办法是混合检索——向量检索加关键词检索两者结果加权排序。第三个瓶颈是知识更新。项目在推进规范在变化RAG 知识库如果不同步更新Agent 就会拿到过时的信息。我的做法是把知识库的更新也纳入 CI 流程每次代码合并时自动检查是否有规范文档变更有的话触发知识库重建。瓶颈表现我的应对方案切片策略检索结果太长或太碎按内容类型分片保留重叠检索精度语义相似但不相关向量关键词混合检索知识更新Agent 用过时信息知识库更新纳入 CI6. 三周交付的完整时间线复盘6.1 第一周契约冻结和基础设施搭建第一周基本没写业务代码全在搭架子。周一和周二梳理需求把四个模块的功能点拆成 47 个接口写成 OpenAPI 契约。周三搭 worktree 环境配好三个 Agent 的工作目录和分支。周四搭 RAG 知识库把代码规范和接口契约灌进去。周五配 CI 流水线跑通 lint 和 test 两个阶段。这一周看起来没产出但恰恰是最关键的。我见过太多项目一上来就写代码写到一半发现接口对不上返工的时间远超前期规划的时间。契约冻结这一步把后面可能出现的对齐问题提前消灭了。6.2 第二周三个 Agent 并行冲刺第二周是产出最密集的一周。三个 Agent 同时开工后端 Agent 生成接口和 Service前端 Agent 生成页面和组件测试 Agent 生成用例。我每天做三件事早上检查前一天的 CI 结果中午做 code review晚上处理 Agent 之间的契约变更。这一周遇到的最大问题是测试 Agent 的用例覆盖不全。它生成的用例大多覆盖正常路径对异常路径覆盖不足。我的解决办法是给它一份异常场景清单明确列出每个接口需要测试的异常情况比如参数为空、参数超长、并发冲突、权限不足。有了这份清单测试覆盖率从 62% 提到了 85%。6.3 第三周集成联调和收尾第三周主要是联调和修 bug。前后端对接的时候发现了一些契约里没定义清楚的细节比如时间字段的格式、枚举值的映射。这些问题在契约里补上之后让对应的 Agent 重新生成相关代码。联调阶段我还做了一件事让测试 Agent 生成端到端的集成测试。这些测试模拟真实用户操作从登录开始走完整个审批流程验证数据看板的数字是否正确。这类测试跑起来慢但能发现单元测试发现不了的问题。三周下来最终交付的代码量大约是 18000 行其中 Agent 生成的部分占 75%我手写的部分占 25%主要是契约、关键业务逻辑和集成代码。bug 数量比预期少上线后第一周只收到 3 个问题反馈都是边界情况当天就修完了。7. 几个让我少走弯路的关键决策7.1 契约先行宁可慢一天也不省这一步前面反复提契约这里再强调一次。契约不是文档是三个 Agent 之间的通信协议。协议不清楚通信就会出错。我在第一个模块上省了这一步结果返工了两天。后面三个模块老老实实先写契约每个模块省下的返工时间至少一天。写契约的时候有个技巧把错误码也定义清楚。Agent 生成异常处理代码时如果不知道有哪些错误码就会自己编一套导致前后端对不上。我在契约里定义了统一的错误码规范比如 40001 表示参数错误40003 表示权限不足50001 表示系统异常。Agent 照着这个规范生成前后端的错误处理就对齐了。7.2 Agent 的产出必须过 CI不能靠看起来对Agent 生成的代码有个迷惑性它看起来很规范命名整齐注释齐全容易让人放松警惕。但看起来对和实际对是两回事。我坚持所有 Agent 产出必须过 CIlint 不过、测试不过一律打回重做。这个原则救了我好几次。有一次后端 Agent 生成了一个查询接口逻辑看起来没问题但 CI 的 SpotBugs 检查报了一个可能的空指针警告。我一看果然在某个分支下会返回 null前端没做判空处理。如果靠人眼看这种问题很容易漏掉。7.3 人的价值在决策不在敲代码三周做完这个项目我最大的体会是AI Agent 替代的是执行不是决策。契约怎么定、架构怎么分层、异常怎么处理、哪些边界要考虑这些决策还是得人来做。Agent 能把你从重复的编码劳动里解放出来但前提是你得知道要它做什么。我见过一些人用 Agent 的方式是给个需求等它生成然后改改就用。这种方式在简单任务上可行但在企业项目里会出大问题。企业项目的复杂度不在于代码本身而在于业务规则、历史包袱、团队约定这些隐性知识。这些知识 Agent 不知道得你来告诉它或者通过 RAG 喂给它。所以我的建议是把 Agent 当成一个执行力很强但需要明确指令的初级工程师。你给它的指令越清晰它的产出越好。你偷懒省掉的思考最后都会变成返工的时间还回来。最后分享一个我在实操中总结的小技巧给每个 Agent 建一个工作日志。每次它完成任务后让它自己记录这次做了什么、遇到什么问题、怎么解决的。这些日志积累起来一方面能帮你复盘另一方面可以喂回 RAG 知识库让后续的任务检索到这些经验。我用这个方法让 Agent 在第三个模块上的产出质量明显高于第一个模块因为它记住了前面踩过的坑。