Go 后端转 AI：3 个 Agent 并行开发，我用 300 个 worktree 管住它们

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

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

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

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

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

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

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

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

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

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

装配模板有三套：

工具链就是中间那一列，四样东西：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 里塞一份任务说明再启动（示例，按你的项目改）：

# 给实例准备独立工作区：建 worktree → 注入上下文 → 合并后回收TOP=$(gitrev-parse --show-toplevel)task_id="svc-chat-014"attempt=${ATTEMPT:-1}# 同一任务重跑时递增，避免撞上旧目录dir="$TOP/../wt/${task_id}-${attempt}"branch="agent/${task_id}-${attempt}"gitworktreeadd-b"$branch""$dir"origin/maincat>"$dir/AGENT_CONTEXT.md"<<EOF # 本次任务 模块：知识库管理 验收标准：增删改查 + 分页，含单测 # 硬约束 1. 只改动本目录下的文件 2. 接口契约见 docs/api-contract.yaml，不得自行修改 3. 不得改动权限判定与事务边界相关代码 4. 完成后把状态写回任务表，禁止自己点合并 EOF# review 合并之后立刻回收，只建不删会把磁盘拖垮# 注意：AGENT_CONTEXT.md 是未跟踪文件，不带 --force 会被 git 拒绝gitworktree remove--force"$dir"gitworktree prune

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

{"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 带宽走，不跟着机器走。你要是打算照这套搭，先问自己一天能看多少代码，再决定开几个。

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

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

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

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

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

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

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

八、一张表收尾

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

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

九、边界

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

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

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

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

你手上现在跑的项目，如果只挑一个模块交给 Agent 独立完成，你会挑哪个？评论区聊聊。

评论区留言「工程化」，我把 300 个 worktree 的批量脚本和任务卡模板整理成一份清单发你。

更多后端转 AI 的工程化实践，我写在官网：https://wangzhongyang.com