1. 先算一笔账3周交付企业项目到底省在哪儿先把标题里的数字拆开看。一个企业级项目常规配置是4人团队、2个月工期粗算下来大约160人天。我用3周做完按单人投入算约15人天即便算上我调度AI Agent的隐性时间成本整体投入也很难超过30人天。这个差距不是靠加班或者压缩测试换来的而是把项目里那些重复性高、模式固定、但必须有人盯着的环节整体外包给了AI Agent。具体是哪些环节我把它分成三类信息搬运类需求文档转任务清单、接口定义转类型声明、数据库表结构转ORM模型、日志报错转修复建议。这类工作的特点是输入输出格式高度确定人做起来枯燥且容易出错。模式匹配类代码风格统一、命名规范检查、单元测试骨架生成、CI配置模板套用。这类工作有明确的正确样例可以参照AI Agent的命中率很高。检索汇总类在大型代码库里定位某个功能的实现位置、梳理某个模块的调用链路、从历史提交里找出类似问题的修复方式。这类工作靠人翻代码效率极低但RAG检索增强生成配合代码索引能大幅提速。我用的3个AI Agent分工大致对应这三类。第一个负责需求拆解和任务编排第二个负责代码生成与重构第三个负责代码审查和CI流水线维护。它们不是各自为战而是通过一个共享的上下文层串起来——这个上下文层就是整个方案的核心后面会详细讲。注意这里说的3个Agent不是指3个独立的模型实例而是3套不同的提示词策略加工具链组合。底层可以共用同一个模型关键是角色边界要清晰否则Agent之间会互相污染上下文输出质量断崖式下跌。为什么是3个而不是1个或5个我试过1个Agent包打天下结果是它在同一个对话里既要理解需求又要写代码还要做审查上下文窗口很快被塞满后期输出开始幻觉把前面已经确认的接口定义改得面目全非。也试过拆成5个结果协调成本急剧上升Agent之间的交接损耗比省下来的时间还多。3个是我实测下来的平衡点需求侧一个、实现侧一个、质量侧一个每个Agent的职责边界用一句话能说清交接物是结构化的JSON或Markdown表格不依赖自然语言的模糊传递。2. 三个Agent的职责边界与交接协议2.1 需求拆解Agent把模糊需求变成可执行任务企业项目最耗时的往往不是写代码而是搞清楚到底要做什么。产品经理给的需求文档通常夹杂着业务术语、历史遗留逻辑和未明说的假设。我的做法是让需求拆解Agent先做一轮需求澄清输出一份结构化的任务清单格式如下{ epic: 用户权限管理模块, tasks: [ { id: T001, title: 实现基于角色的访问控制, inputs: [用户表结构, 角色定义文档], outputs: [权限校验中间件, 角色配置接口], acceptance: [未授权请求返回403, 角色变更实时生效], dependencies: [] } ] }这份清单的关键在于acceptance字段——它必须是可验证的。如果写系统运行正常这种话后面的代码生成Agent和审查Agent就没法判断做没做对。我通常要求acceptance里至少有一条是可以用自动化测试覆盖的。这个Agent的提示词里我加了一条硬规则遇到需求文档里没写清楚的地方不许猜直接列成待确认问题。早期我没加这条结果Agent自作主张补了一堆假设代码写完才发现跟业务方预期完全不符返工成本极高。现在它会把模糊点单独列出来我花10分钟跟业务方确认比事后返工省几天。2.2 代码实现Agent在worktree里干活不污染主分支代码实现Agent的工作环境很关键。我给它配的是git worktree而不是直接在主分支上改。这里要区分一下worktree和branchbranch是同一个工作目录下切换分支worktree是给同一个仓库开多个独立的工作目录每个目录可以检出不同分支。对AI Agent来说worktree的好处是隔离性——Agent在独立目录里折腾改坏了不影响我本地的开发环境也不影响主分支。具体操作# 为主仓库创建一个worktree检出feature分支 git worktree add ../project-agent-workspace feature/agent-task-001 # Agent在这个目录里工作 cd ../project-agent-workspace # ... Agent进行代码生成和修改 ... # 完成后提交回到主仓库合并 git add -A git commit -m feat: implement RBAC middleware为什么不用branch因为branch切换时未提交的改动会跟着走Agent如果在改代码的同时我本地也在改容易冲突。worktree物理隔离各干各的合并时再处理冲突心智负担小很多。代码实现Agent的提示词里我强调三点遵循现有代码风格、优先复用已有工具函数、每个函数必须有对应的单元测试。第三点尤其重要因为审查Agent后面要靠测试来判断实现是否正确。如果Agent偷懒不写测试审查环节就失去了客观依据。2.3 审查与CI Agent把code review变成自动化关卡审查Agent的职责不是看一眼代码觉得没问题而是跑一套固定的检查清单。我的清单包括检查项判断标准不通过的处理单元测试覆盖率新增代码覆盖率≥80%要求实现Agent补测试接口契约一致性与需求拆解Agent输出的接口定义一致标记冲突人工裁决命名规范符合项目现有命名约定自动重命名并提交安全扫描无硬编码密钥、无SQL拼接直接拒绝合并CI流水线所有stage通过修复后重新触发这套检查清单跑在CI里每次Agent提交代码自动触发。我用的是GitLab CI配置大概长这样stages: - test - review - security unit_test: stage: test script: - npm run test:coverage coverage: /Lines\s*:\s*(\d\.\d)%/ rules: - if: $CI_PIPELINE_SOURCE merge_request_event ai_review: stage: review script: - python scripts/ai_review.py --diff $CI_MERGE_REQUEST_DIFF_BASE_SHA allow_failure: false security_scan: stage: security script: - semgrep --configauto --error审查Agent的输出不是简单的通过/不通过而是一份带行号的评论列表直接贴到Merge Request里。我实测下来这套机制能拦住大约70%的低级问题剩下30%需要人工判断的通常是业务逻辑层面的取舍这部分AI确实替代不了。3. RAG在项目里的真实作用与瓶颈3.1 为什么企业项目离不开RAG这个项目涉及一个已有5年历史的代码库大概20万行代码文档散落在Confluence、README、代码注释里。如果让AI Agent直接读全部代码上下文窗口根本装不下。RAG的作用就是按需检索——Agent需要了解某个模块时先去检索相关代码片段和文档再基于检索结果生成代码。我的RAG知识库分三层代码层按函数和类切分每个片段附带文件路径、行号、依赖关系。检索时用代码语义相似度而不是纯文本相似度。文档层需求文档、设计文档、API文档按章节切分保留标题层级作为元数据。历史层过去的Issue、Merge Request、提交信息按问题类型打标签方便Agent找到类似问题的修复方式。这里要区分几个概念RAG知识库是面向检索的存储的是切分后的文本片段加向量结构化知识库比如知识图谱存储的是实体和关系适合回答A依赖BB依赖C这类链路问题Wiki是给人看的结构松散直接拿来做RAG效果很差必须先做结构化处理。我这个项目里代码层和历史层用RAG模块依赖关系用了一个轻量的知识图谱两者互补。3.2 RAG的瓶颈检索不准比不检索更可怕RAG最大的坑不是检索不到而是检索到错误的片段Agent还信了。我遇到过好几次Agent要修改一个支付相关的函数RAG检索到了另一个同名但不同模块的函数Agent基于错误上下文生成了代码审查时才发现逻辑完全不对。缓解这个问题的办法有三个元数据过滤检索时限定文件路径范围比如只搜src/payment/目录下的内容。重排序先用向量检索召回Top 20再用一个交叉编码器重排取Top 5。这一步能显著提升准确率但会增加延迟。引用溯源要求Agent在生成代码时标注参考了哪些片段审查Agent核对引用是否合理。关于RAG知识库能不能存图片我的经验是可以存但检索效果取决于图片有没有配套的文字描述。纯图片比如架构图如果不做OCR或人工标注向量检索基本搜不到。我的做法是架构图旁边必须有一段文字说明RAG检索文字图片作为附件链接。3.3 本地RAG搭建的实操要点我用的是Ollama加一个轻量向量库的方案适合个人和小团队。核心步骤# 拉取嵌入模型 ollama pull nomic-embed-text # 拉取生成模型 ollama pull qwen2.5-coder:7b文本切分我用的是按语义切分而不是固定长度切分。具体做法是先用Markdown标题切大块再在块内按段落切每段控制在500到800字。切太碎会丢失上下文切太大检索精度下降。检索时我设了两个阈值相似度低于0.7的片段直接丢弃相似度在0.7到0.8之间的标记为低置信度Agent使用这些片段时必须额外说明理由。这个机制拦住过好几次潜在的幻觉。提示本地RAG的瓶颈通常在嵌入模型的质量而不是生成模型。如果检索结果总是不相关先换嵌入模型试试比调生成模型的提示词有效得多。4. 并发压力下Agent的稳定性处理4.1 多Agent并发时的资源竞争3个Agent同时跑的时候会出现资源竞争。最典型的是同时读写同一个文件实现Agent在改user_service.py审查Agent同时在读这个文件做检查读到的可能是改了一半的中间状态。我的解决办法是加锁加队列。每个文件在被Agent修改前先申请一个锁锁的粒度是文件级。审查Agent只读已提交的版本不读工作区里的未提交改动。这样虽然牺牲了一点实时性但避免了脏读。具体实现上我用了一个简单的文件锁服务import fcntl def acquire_lock(filepath): lockfile open(f{filepath}.lock, w) fcntl.flock(lockfile, fcntl.LOCK_EX) return lockfile def release_lock(lockfile): fcntl.flock(lockfile, fcntl.LOCK_UN) lockfile.close()这个方案在单机多进程下够用。如果Agent部署在不同机器上需要换成基于Redis的分布式锁。4.2 CI流水线的并发控制CI流水线在多个Agent同时提交时会触发多次构建浪费资源且容易互相干扰。我在GitLab CI里加了resource_group保证同一时间只有一个流水线在跑ai_review: stage: review resource_group: agent_pipeline script: - python scripts/ai_review.py另外我把CI的触发条件从每次提交改成Merge Request创建或更新时减少无效构建。Agent在worktree里可以随便提交只有准备合并时才触发CI。4.3 Agent超时与重试策略Agent调用模型API时偶尔会超时尤其是上下文很长的时候。我的策略是单次调用超时60秒超时后重试2次每次重试前把上下文精简20%。如果3次都失败降级到人工处理并记录日志。这个策略的关键是精简上下文而不是原样重试。原样重试大概率还是超时精简上下文能提高成功率。精简的优先级是先删历史对话再删低相关度的RAG片段最后删代码注释。5. 实测中踩过的坑与应对5.1 Agent生成的代码看起来对跑起来错这是最常见的问题。Agent生成的代码语法正确、命名规范、注释齐全但逻辑有微妙错误。比如一个边界条件判断用了而不是单元测试如果没覆盖到边界就发现不了。我的应对是强制要求边界测试。在需求拆解Agent的acceptance字段里必须包含至少一条边界条件测试。审查Agent会检查测试用例里有没有边界值如0、-1、最大值、空字符串。这条规则加上之后边界相关的bug减少了大约六成。5.2 RAG检索到的代码片段版本过旧代码库在演进但RAG索引不是实时更新的。Agent可能检索到三个月前的函数实现而那个函数已经重构过了。我的做法是每次合并到主分支后自动重建索引并且在检索结果的元数据里带上最后更新时间超过30天的片段标记为可能过时Agent使用时需要额外验证。5.3 多Agent之间的责任推诿早期我的3个Agent没有明确的交接协议结果实现Agent说需求没写清楚需求Agent说我写清楚了是你没理解审查Agent说你们俩都有问题。后来我强制规定所有交接必须通过结构化文档需求Agent输出的JSON里每个任务必须有明确的inputs和outputs实现Agent如果觉得inputs不够必须列出具体缺什么而不是笼统地说不清楚。这个改变看起来只是格式问题实际上大幅减少了扯皮。因为缺什么一旦具体化要么是需求Agent补上要么是我人工确认没有模糊空间。5.4 CI流水线被Agent的频繁提交刷屏Agent干活快提交频繁CI流水线被触发几十次通知栏全是构建结果。我的处理是合并提交Agent在worktree里可以多次提交但推送到远程前用git rebase -i合并成逻辑相关的几个提交。这样CI触发次数从几十次降到三到五次通知清爽很多。# 在worktree里合并最近5个提交 git rebase -i HEAD~5 # 在编辑器里把不需要的提交标记为squash6. 这套方案适合什么场景不适合什么场景6.1 适合的场景这套3Agent方案最适合中等规模、需求相对明确、代码库有一定历史的企业项目。具体来说项目周期在1到3个月团队规模2到5人。需求文档基本齐全但存在模糊点需要澄清。代码库有既有规范新代码需要遵循。有CI基础设施能跑自动化测试和检查。我实测下来这类项目里信息搬运和模式匹配类工作能省掉60%到70%的时间检索汇总类工作能省掉50%左右。整体工期压缩到原来的三分之一到二分之一是合理的。6.2 不适合的场景反过来以下场景这套方案效果有限需求极度模糊、需要大量探索性设计的项目。Agent擅长执行明确任务不擅长从零定义问题。代码库没有测试、没有规范的项目。Agent生成的代码没有参照质量无法保证。强实时性、强一致性的系统。Agent的异步工作模式和重试机制不适合这类场景。涉及敏感数据处理的项目。Agent调用外部模型API时数据会离开本地环境需要额外评估合规性。6.3 关于个人用AI Agent做交易的提醒热词里有人问个人使用AI Agent可以做期货交易吗。我的看法是技术上可以搭但风险极高。Agent的决策基于历史数据和模式匹配而市场存在大量非理性因素和突发事件Agent的反应速度和判断力在极端行情下不可靠。如果一定要尝试务必用模拟盘跑至少半年且仓位控制在可承受损失范围内。这不是技术问题是风险管理问题。7. 从3周交付里提炼的可复用经验7.1 先建上下文层再谈Agent分工很多人一上来就纠结用几个Agent用什么框架但真正决定成败的是上下文层——也就是Agent之间共享的信息结构。我的做法是先定义好任务清单的JSON schema、代码片段的元数据格式、审查评论的结构然后再去配Agent。上下文层清晰了Agent用1个还是5个只是调度问题。7.2 把可验证作为所有输出的硬标准无论是需求拆解、代码生成还是审查意见我都要求输出里包含可验证的断言。需求要有acceptance代码要有测试审查要有具体的行号和判断依据。这条原则执行得越彻底Agent之间的协作越顺畅人工介入越少。7.3 隔离环境比提示词优化更重要我花在worktree隔离、文件锁、CI并发控制上的时间回报远高于反复调提示词。Agent在干净、隔离的环境里工作输出质量天然更稳定。提示词优化有上限环境隔离没有。7.4 保留人工裁决的入口整套流程里我保留了三个必须人工确认的节点需求模糊点确认、接口契约冲突裁决、安全扫描告警处理。这三个节点AI做不了最终决定但可以把问题整理好、给出建议我只需要做选择题而不是问答题。这个设计让我的实际介入时间控制在每天1小时以内。最后分享一个我一直在用的小技巧每次Agent完成一个任务我会让它用一句话总结这次做了什么、遇到什么问题、下次类似任务要注意什么存到一个lessons.md文件里。下次启动新任务时把这个文件作为上下文的一部分喂给Agent。这个习惯让Agent的经验能跨任务积累实测下来重复错误的概率明显下降。
