读者问"你用的什么 Agent"：3 个 AI 员工的分工表和工具链

上一篇《3 个 AI Agent 交付一个企业项目》发出去之后，底下只有一条评论。

一位读者问：「请问一下用的什么agent?」

就这一条。但它是那篇文章里唯一的互动。

我盯着这句话想了一会儿。大家真正想问的不是「你赚了多少」，是「你拿什么干的」。上一个问题我答完了，这个问题我还没答。

那就摊开。三个 AI 员工怎么装配、谁在哪一环、验收标准怎么定、哪几件事我到现在也没交给它们。

一、先纠正一个误解：问「什么 Agent」，问的不是模型

我一开始也答不上来，因为这个问题默认了一个前提：Agent 等于某个模型或者某个产品。

真跑起来之后我发现不是。一个能干活的 AI 员工是三样东西叠起来的：上下文、工具、模型。

模型是最薄的那一层。换模型，效果会变；但不给它上下文和工具，它连自己该改哪个文件都不知道。

先把「3 个员工」这个词定义清楚，不然后面全是歧义：它们是 3 个并行跑的实例，不是 3 个固定岗位。 谁领到哪类任务，就按那类任务装配上下文。同一时刻最多 3 个在跑。

装配模板有三套：

上下文模板	装进去的东西	挂的工具	模型档位	我的角色
需求与方案	会议录音转写、历史需求文档	文档生成、流程图、排期表	长文本、逻辑推理强的那档	终稿与决策
写代码	代码仓库、任务卡、接口契约	git worktree、CI、测试框架	按模块难度分两档	核心架构 + review
运维	线上日志、工单历史、知识库	RAG 检索、改码跑测、发布脚本	中文语义理解好的那档	常规变更过一遍 diff，不可逆动作我亲自执行

工具链就是中间那一列，四样东西：git worktree 做隔离、一张多维表格当任务队列、CI 当门禁、RAG 知识库给运维段喂上下文。没有别的了。

具体用哪个模型我故意不点名。不是藏着，是这一层换得最快，几个月就变一次，也是整套里最不稳的一层。你把它当成最后才调的旋钮就行。

三个模板里，真正吃工时的是中间那个。下面挨个说。

二、需求与方案：它吃的是会议，产出的是文档

跟客户开一次启动会，录屏录音，把核心需求聊透。

录音丢给它，出来的东西有四类：需求文档初稿、业务流程图、架构图初稿、技术选型建议。我来审，该砍的砍掉、该补的补上，再发给客户确认。

这一步以前要 3 到 5 天，现在 1 天。

它真正值钱的地方不是写得快。是会开到两小时，人的注意力往下掉，它不掉。客户随口提了一句、我当时没记下的点，它会全翻出来。 这种事发生过不止一次，翻出来的还经常是后面最麻烦的那个约束条件。

方案设计是同一套逻辑，只是输入换成确认好的需求文档，输出换成系统架构、库表设计、接口设计、排期和风险清单。

这里得说实话：它出的方案初稿，大概有三四成是要我改的。 评审这步我一步没省。

但我还是整段交给它了。初稿本身不值钱，值钱的是它不会累。你让它改十版它就改十版，不会跟你摆脸色。带过团队的人都懂这意味着什么。

三、写代码：它吃的是任务卡和契约，不是一句话

这是最多人质疑的地方。我说说我怎么管住它。

第一件事：模块必须切到 2 小时以内。 这里的 2 小时是我估的人工工作量，用来控制切分粒度。如果这个模块我自己写得超过 2 小时，就继续切。Agent 实际跑完通常只要几十分钟。

切细还带来一个额外好处：单个 worktree 的存活时间从按天算变成按小时算，回收才跟得上。 模块切得粗的时候，一个分支要挂一两天，几十个堆在那儿磁盘就吃紧。

第二件事：每个实例只能在自己的 worktree 里干活。 一个项目下来累计创建了 300 多个 worktree。这个数字是累计创建数，包含重跑和被我丢掉的废弃分支；同一时刻并行的上限就是实例数，3 个。这三个实例不是全天候挂着，只有我投进去的那 10 天里在跑，每天在线 6 到 10 小时。扣掉重跑和废弃，最终合进主分支的大概 180 个模块，占累计数的六成左右。

只建不删的话，两周就能把磁盘和 git worktree list 拖成一屏屏的垃圾。worktree 是完整的工作区检出，必须边用边回收。

上下文注入这一步我是这么做的，每个 worktree 里塞一份任务说明再启动（示例，按你的项目改）：

bash 复制代码

# 给实例准备独立工作区：建 worktree → 注入上下文 → 合并后回收
TOP=$(git rev-parse --show-toplevel)
task_id="svc-chat-014"
attempt=${ATTEMPT:-1}                 # 同一任务重跑时递增，避免撞上旧目录
dir="$TOP/../wt/${task_id}-${attempt}"
branch="agent/${task_id}-${attempt}"

git worktree add -b "$branch" "$dir" origin/main

cat > "$dir/AGENT_CONTEXT.md" <<EOF
# 本次任务
模块：知识库管理
验收标准：增删改查 + 分页，含单测
# 硬约束
1. 只改动本目录下的文件
2. 接口契约见 docs/api-contract.yaml，不得自行修改
3. 不得改动权限判定与事务边界相关代码
4. 完成后把状态写回任务表，禁止自己点合并
EOF

# review 合并之后立刻回收，只建不删会把磁盘拖垮
# 注意：AGENT_CONTEXT.md 是未跟踪文件，不带 --force 会被 git 拒绝
git worktree remove --force "$dir"
git worktree prune

任务本身我落在一张多维表格里，每个项目一张：

json 复制代码

{
  "task_id": "svc-chat-014",
  "module": "知识库管理",
  "status": "进行中",
  "claimed_by": "agent-2",
  "claimed_at": "2026-09-12T10:04:00+08:00",
  "last_heartbeat": "2026-09-12T10:31:00+08:00",
  "version": 17,
  "attempt": 1,
  "worktree": "wt/svc-chat-014-1",
  "验收标准": "增删改查 + 分页，含单测",
  "产出": "分支 agent/svc-chat-014-1"
}

（示例任务卡，字段按实际项目调整。）

这里有三件事，别混为一谈。

第一，抢占是状态约束。 status 只留五个取值：待分派 → 进行中 → 待评审 → 已验收 / 已阻塞，只有「待分派」能跃迁到「进行中」。它挡住绝大多数重复领，但它自己是 read-then-write，两个实例同一瞬间读时会同时看到「待分派」。

第二，version 是唯一的原子执行手段。 真正让第二个写失败的不是那条状态约束，是 version：写回时带上读到的 version，与表里一致才写成功，不一致就重读重来。它防的是并发写覆盖，不保证不白跑。

第三，回收脚本和我自己也要走同一条 versioned write。 超时打回是把 status 写回「待分派」，我的评审回填也是在写。这两个写者不走 version，就可能在实例刚写完结果的瞬间把状态盖掉，那它自己就是最大的竞态源。

超时阈值是 30 分钟没有 last_heartbeat，心跳每 5 分钟写一次，阈值是间隔的 6 倍，任务跑慢一点不会被误杀。心跳写的是单独一个不抬 version 的字段，写结论前再重读一次 version，否则任务跑上几十分钟，开局读到的那个版本号早过期了，每次写回都会失败。

没有超时打回也不行：某个实例崩在中间，任务就永久卡死，而我在表上看到的还一直是「进行中」。

先把工作量说清楚，免得被当成自研调度框架：这个回收逻辑就是个几十行的轮询脚本，只做一件事，扫表、超时打回，不承担编排职责。任务怎么拆、谁能做什么，全在任务卡里由我提前写好。为了 3 个 Agent 去养一套工作流引擎，维护成本比写业务还高。轮询间隔我放到 60 秒以上，原因是表格没有 webhook，只能定时拉。

第三件事：模型不是越贵越好，是按模块难度分两档。 逻辑分支多、并发路径复杂的模块用强的一档，不过锁和并行的判定部分仍然是我写；CRUD、管理后台页面、测试用例用便宜的一档。我一开始全用最强的那档，跑了几天发现八成的任务根本用不上那个能力，纯烧钱。

第四件事：合并前一律过 CI。 单测加类型检查，不绿就不合。它写的代码和我写的走同一套门禁，不给自己开后门。这才是「敢不敢让 AI 写代码」的真正前提。

四、运维：它吃的是工单和日志

交付之后才是漫长的部分。客户今天提个需求，明天报个 bug，精力被切得碎。

现在给客户搭一个运维助手，接的是线上日志、工单历史和产品知识库。客户的小问题直接问它，大部分当场解决。小的需求变更，它改代码、跑测试、提交发布单（回滚脚本一起出），我审一遍之后由流水线发布。

这里有个例外必须交代：日常小变更走流水线，但改 schema、删数据、首次上生产这类不可逆动作，敲回车的人是我。 下面四条红线里的「不可逆操作」，说的就是这一类。

我每个月亲自参加至少一次复盘会。运维这块，我几乎不投时间了。

五、为什么停在 3 个，不继续加

有人问我为什么不多开几个。

加实例不等于加产能，这是我试到第四个才认的。瓶颈不在机器，在我。

每个实例的产出都要我 review，我一天能认真看多少，就决定了上限。加到第四个之后，它的产出不是变快了，是变成排队等我看。任务表里「待评审」那一列越堆越长，等于把瓶颈从写代码挪到了我这边，总交付时间一点没少。

并发上限跟着 review 带宽走，不跟着机器走。 你要是打算照这套搭，先问自己一天能看多少代码，再决定开几个。

六、验收：每个实例交活之前必须能回答三个问题

我不看它「做得怎么样」，只看三件事有没有答案：

改动范围：动了哪些文件，有没有碰到契约之外的东西。
怎么证明它对：跑没跑测试，测试是它自己写的还是复用了库里的。
错了怎么退：这个改动有没有对应的回滚路径。

第三个最容易被跳过。它改得快，出错也快，没有回滚路径就等于把风险留到线上。

七、这四类活我一条都没交出去

不是所有代码都能放手。以下四类，我到现在也是自己落地：

权限判定、事务边界、幂等设计。 它可以写脚手架和调用封装，判定逻辑必须我来。这块出错就是线上事故。
架构决策。 拆几个服务、怎么分库、缓存放哪一层，这是判断题不是编写题，它给的是选项不是答案。
对外接口契约。 接口一旦发出去就要兼容，我先定契约，它按契约实现。
不可逆的操作。 改 schema、删数据、首次上生产，它只出脚本和回滚方案，敲回车的人是我。

八、一张表收尾

环节	Agent 干什么	我干什么	验收口
需求诊断	需求文档初稿、流程图、选型建议	终稿、砍需求	客户签字确认
方案设计	架构、库表、接口、排期、风险	评审、定关键难点	评审通过
开发交付	CRUD、接口对接、页面、测试	核心架构、review	CI 绿 + review
运维迭代	日常答疑、小需求改码跑测	小变更过一遍 diff，大变更确认与报价，不可逆动作亲自执行	回滚路径齐备

那笔账我在上一篇算过，这里把关键数字补齐，免得本篇变成孤证：单项目报价 12 万，交付周期 3 周，其中我自己真正投入 10 天，成本 2 到 3 万（含 token 开销），利润率 75% 以上。对照的 20 万是传统外包 4 人 2 个月的常规配置和同行报价区间，含需求调研、上线和验收。

我没说 AI 能替掉人。变的是我能承接的项目规模。

九、边界

它适合业务逻辑清晰、CRUD 占比高的企业应用：管理系统、客服系统、数据看板、内容生产类工具。

前提是这段代码能被自动验证。有测试、能本地跑、错了当天能发现。没有测试覆盖的老代码，它写得越快错得越远。

有两类活我不用这套：强实时、强一致性的底层系统；需求自己都没想清楚的产品，它会飞快地帮你把错误的方向做扎实。

门槛不在技术栈，在你敢不敢把项目切得足够细。

你手上现在跑的项目，如果只挑一个模块交给 Agent 独立完成，你会挑哪个？评论区说说，我挑几个典型的展开写。