3 个 AI Agent 交付一个企业项目：4 人团队 2 个月，我 3 周做完
上个月，我给一家传统企业的老板讲方案。
讲到第 20 分钟，他打断我：「行，就你了。」
我报的是 12 万。他没还价，也没问我团队有几个人。
项目是一套 AI 客服系统。按传统外包的算法，这个价正常没人敢接。我接了，交付周期 3 周，我自己真正投进去的时间 10 天。
不是我突然变强了。是这套交付流程里，开发环节八成的代码是 3 个 AI Agent 写的。
这篇文章不讲「AI 让效率提升多少倍」这种话。我把拆解过程写出来：Agent 在哪些环节能上、哪些环节绝对不能碰、多 Agent 并行时最容易翻车的地方在哪。
整体流程：一个项目拆成四个环节
我把企业交付拆成四段，每段先划清「Agent 干什么、我干什么」：
| 环节 | AI Agent 负责 | 我负责 |
|---|---|---|
| 需求诊断 | 需求文档初稿、业务流程图、技术选型建议 | 审核、关键决策 |
| 方案设计 | 系统架构、库表设计、接口设计、排期、风险清单 | 技术评审、定关键难点 |
| 开发交付 | CRUD、接口对接、前端页面、测试用例 | 核心架构、code review |
| 运维迭代 | 客户日常答疑、小需求改代码跑测试 | 谈新需求、月度复盘 |
第二段贵在判断，第三段贵在量大，这两处的翻车点不一样，分开讲。
环节一：需求诊断，Agent 出初稿，我做终稿
跟客户开一次启动会，录屏录音，把核心需求聊透。
然后把录音丢给 Agent，让它整理成需求文档初稿，顺带输出业务流程图、架构图初稿、技术选型建议。最后我来审，该砍的砍掉、该补的补上，再发给客户确认。
这一步以前要 3 到 5 天，现在 1 天。
Agent 真正值钱的地方在这儿：客户随口提到、我当时没记下的点，它会全翻出来。会议开两小时，人的注意力会衰减，它不会。
环节二：方案设计，Agent 出方案，我做评审
需求确认后出技术方案。这一步以前最贵，也最考验人。
现在我把确认好的需求文档丢给 Agent，它输出系统架构、库表设计、接口设计、核心模块的代码框架，顺带生成排期、人力估算和风险清单。方案初稿当天出，我评审加改稿 1 天。
这里得说清楚：Agent 出的方案初稿，大概有三四成是需要我改的。 所以技术评审这一步，我一步没省。
但我还是把方案设计整段交给它了。初稿本身不值钱，值钱的是它不会累。你让它改十版，它就改十版，不会跟你摆脸色。带过团队的人都懂这意味着什么。
环节三：开发交付，我写两成，Agent 写八成
这是最多人质疑的地方：真敢让 AI 写代码吗？
我的做法是把项目拆成小模块，每个模块不超过 2 小时工作量，超过就继续切。每个模块我先写核心架构和关键逻辑，大概占两成；剩下的 CRUD、接口对接、前端页面、测试用例交给 Agent。
举个例子。那个 AI 客服项目里，大模型对接、RAG 检索、对话管理这三个模块是我自己写的，前后 5 天。剩下的代码，客服后台、数据统计、知识库管理，全是 Agent 写的，我只做 review（用户管理这块我只把 CRUD 交出去，权限判定还在我这边）。
多 Agent 并行的三个工程细节
第一个：用 worktree 做隔离。 一个项目我创建了 300 多个 worktree。
worktree 让每个 Agent 在独立目录和分支上干活，不会互相覆盖文件，也不会把没提交的改动带进别人的分支。哪个模块做废了，直接丢掉那个 worktree，不用回滚主干。
批量创建和分派大概长这样（示例，按你的任务清单改）：
TOP=$(git rev-parse --show-toplevel)
while IFS= read -r id; do
dir="$TOP/../wt/$id"
[ -d "$dir" ] && continue # 幂等：已存在就跳过
git worktree add -B "agent/$id" "$dir" origin/main
done < <(jq -r '.tasks[].id' tasks.json)
# 合并完立刻回收，不然磁盘和 git 状态很快被拖垮
git worktree remove "$TOP/../wt/svc-chat-014"
git worktree prune
这东西必须边用边回收。worktree 是完整的工作区检出，只建不删，两周就能把磁盘和 git status 拖慢。
第二个：任务状态必须落盘。 多 Agent 并行最容易翻车的地方，是同一个任务被两个 Agent 重复做，或者做完没人知道。
真正把 3 个 Agent 管起来的，不是上面那套脚本，是一张表。任务调度我没用什么高级工具，就是一张飞书多维表格，每个项目建一张：
{
"task_id": "svc-chat-014",
"module": "知识库管理",
"owner": "agent-2",
"worktree": "wt/svc-chat-014",
"status": "待评审",
"验收标准": "增删改查 + 分页，含单测",
"产出": "分支 agent/svc-chat-014"
}
（示例任务卡，字段按实际项目调整。）
Agent 定时去读任务、回写状态，我每天扫一眼就知道进度到哪了。工具越简单，越容易坚持。 为了 3 个 Agent 去养一套工作流引擎，维护成本比写业务还高。
这张表要真能跑，还有三件事必须补上，缺一个就等着重复劳动：
- 状态机闭合：
status只留五个值，待分派 → 进行中 → 待评审 → 已验收 / 已阻塞，不要用自由文本。 - 抢占加乐观锁：Agent 领任务时带上读到的
version，写回失败说明被别的 Agent 抢走了，重读即可。光靠「定时读、定时写」防不住重复做。 - 超时回收：超过 30 分钟没有心跳的任务自动打回「待分派」，否则 Agent 崩在中间，任务就永久卡死。轮询间隔放到 60 秒以上，别撞飞书的接口频次限制。
还有一条是合规：客户项目的模块名和验收标准属于交付物，进第三方表格前先脱敏成模块代号，业务细节不要落进去。
第三个：合并前必须过 CI。 这才是「敢不敢让 AI 写代码」的真正前提。
Agent 写完我做 code review，但 review 看不全。所以合并前一律过 CI：单测加类型检查，不绿就不合。Agent 写的代码和我的走同一套门禁，不给自己开后门。
哪些活不能交给 Agent
不是所有代码都能交出去。这四类我一条没让它们独立完成：
- 权限判定、事务边界、幂等设计。 Agent 可以写脚手架和调用封装，但判定逻辑必须我落地。这块出错就是线上事故。
- 架构决策。 拆几个服务、怎么分库、缓存放哪一层，这些是判断题不是编写题，Agent 给的是选项，不是答案。
- 对外接口契约。 接口一旦发出去就要兼容，改动成本极高，我先定契约，再让 Agent 按契约实现。
- 不可逆的操作。 改 schema、删数据、发生产环境，Agent 只负责出脚本和写回滚方案，敲回车的人必须是我。
环节四：运维迭代，日常交给 Agent，我谈新需求
交付不是结束。
以前最烦的是运维：客户今天提个需求，明天报个 bug，随时响应，精力被切得碎。
现在的做法是给客户搭一个 AI 运维助手，客户的小问题直接问它，大部分疑问当场就能解决。小的需求变更，Agent 改代码、跑测试、上线，我审一遍；大的变更，我去跟客户确认方案和报价，再交给 Agent 做。
每个月我亲自参加至少一次复盘会，聊下一阶段的规划。运维这块，我几乎不投入时间了。
算一笔账
| 对比项 | 传统外包 | 这套流程 |
|---|---|---|
| 人员 | 4 人（2 后端 + 1 前端 + 1 测试） | 1 人 + 3 个 Agent |
| 周期 | 2 个月 | 3 周 |
| 我的实际投入 | 全程盯人 | 10 天（需求 1 + 方案 1 + 核心代码 5 + review 测试 3） |
| 总成本 | 20 万上下 | 2 到 3 万 |
| 交付结果 | 净亏 8 万 | 利润率 75% 以上 |
（基准口径：按同类项目的常规外包配置与同行报价区间估算，含需求调研、上线和验收。）
我没说 AI 能替掉人。变的是我能承接的项目规模：原来必须靠招人来补的那部分产能，现在被这套流程接住了。
这套流程的适用边界
免得有人照搬翻车，把边界说清楚。
它适合业务逻辑清晰、CRUD 占比高的企业应用：管理系统、客服系统、数据看板、内容生产类工具。这类项目里真正难的只有一小块，剩下是确定性劳动。
但还有个前提：这段代码必须能被自动验证。 有测试、能本地跑、错了当天就能发现。没有测试覆盖的老代码，Agent 写得越快错得越远。
所以有两类活我不用这套：一是强实时、强一致性的底层系统，它们的正确性没法用测试快速验证，Agent 蒙对了也不知道对；二是需求自己都没想清楚的产品，Agent 会飞快地帮你把错误的方向做扎实。
这套东西的门槛不在技术栈，在你敢不敢把项目切得足够细。切不细，Agent 就只是个贵的自动补全。
你手上的项目，有哪几个模块是敢交给 Agent 独立完成的？评论区说说，我挑几个典型的展开写。
