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和branch：branch是同一个工作目录下切换分支，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的职责不是"看一眼代码觉得没问题"，而是跑一套固定的检查清单。我的清单包括：

这套检查清单跑在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 --config=auto --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依赖B，B依赖C"这类链路问题；Wiki是给人看的，结构松散，直接拿来做RAG效果很差，必须先做结构化处理。我这个项目里，代码层和历史层用RAG，模块依赖关系用了一个轻量的知识图谱，两者互补。

3.2 RAG的瓶颈：检索不准比不检索更可怕

RAG最大的坑不是"检索不到"，而是"检索到错误的片段，Agent还信了"。我遇到过好几次：Agent要修改一个支付相关的函数，RAG检索到了另一个同名但不同模块的函数，Agent基于错误上下文生成了代码，审查时才发现逻辑完全不对。

缓解这个问题的办法有三个：

1. 元数据过滤：检索时限定文件路径范围，比如只搜src/payment/目录下的内容。
2. 重排序：先用向量检索召回Top 20，再用一个交叉编码器重排，取Top 5。这一步能显著提升准确率，但会增加延迟。
3. 引用溯源：要求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 # 在编辑器里把不需要的提交标记为squash

6. 这套方案适合什么场景，不适合什么场景

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的"经验"能跨任务积累，实测下来重复错误的概率明显下降。