用 AI 管理 AI，才是正确的打开方式

本文基于 @elvissun 在 X 上发布的原帖，结合 Reddit r/AskClaw 社区的完整整理，加入我自己作为 JS 全栈独立开发者的理解与拆解。所有架构设计归原作者所有，本文仅为学习笔记性质的二次创作。

开头：一个让我眼红的 git 记录#

有人在某天的 git 记录里留下了 94 次 commits。

那天，他没有打开过编辑器。

7 个 PR，在 30 分钟内全部完成。每月成本：约 190 美元。

这不是在说未来，这是 2025 年某个普通工作日发生的事。

我第一次看到这个数字的时候，脑子里浮出来的第一个念头不是”好厉害”，而是——

他是怎么做到的？

这篇文章，是我读完原帖之后，用自己的话把它拆开、重新理解一遍的过程。

一、为什么不直接用 Claude Code？#

这是整篇文章最核心的问题，也是大多数人没想清楚的地方。

我们现在用 AI 写代码的方式，大概是这样的：

打开 Claude Code / Cursor，把需求贴进去，让它写，改，再改，合并。

这个方式有用，但有一个根本性的瓶颈——

上下文窗口是零和的。

原文里有一句话，我觉得是全文最精准的表达：

Context windows are zero-sum — fill it with code, no room for business context. Fill it with customer history, no room for the codebase.

翻译过来就是：

你往上下文里塞代码，就没有空间放业务背景。你往上下文里塞客户历史，就没有空间放代码库。

这不是模型的问题，是物理限制。

AI 编码工具（Claude Code、Codex）天然只看得到代码，看不到客户、看不到会议记录、看不到上周那个 bug 为什么会出现。

它们是很好的执行者，但不是决策者。

二、两层架构：上下文分层是核心#

原作者的解法，是一个两层架构：

层级	角色	持有什么	做什么
编排层	Zoe（运行在 OpenClaw 上）	业务上下文、客户数据、会议记录、历史决策	理解需求、拆解任务、写 Prompt、分配 Agent
执行层	Codex / Claude Code Agent	代码上下文	专注写代码、提 PR

这个设计的精髓在于：

专业化不是通过”不同的模型”实现的，而是通过”不同的上下文”实现的。

Zoe 不是一个更聪明的模型，她只是一个持有更多业务信息的角色。执行层的 Agent 也不是更笨，他们只是被保护在一个干净的代码上下文里。

两层各司其职，互不干扰。

用易经的话说，这有点像乾坤分立—— 乾在上，持大局，运筹帷幄；坤在下，承执行，落地成形。两者不是对立，是分工之后的协同。

三、完整的 8 步工作流#

Step 1：需求进来，和 Zoe 对话#

客户需求进来，不是直接扔给 Agent—— 而是先和 Zoe 聊，一起 scope 功能。

会议记录自动同步到 Obsidian，Zoe 直接读取，不需要重复解释背景。

关键设计：权限分层

Zoe 有生产数据库的只读权限，可以查客户数据、理解业务背景。但执行层的 Codex Agent 永远没有生产数据库权限。

这是”最小权限原则”在 AI 系统里的具体应用—— 你信任 Zoe 的判断，但你不让 Agent 碰不该碰的东西。

Step 2：Zoe 生成 Agent，分配任务#

Zoe 为每个任务：

创建独立的 git worktree（隔离代码环境）
开一个独立的 tmux session（持久化进程）
写好完整的 Prompt（含业务上下文）
在 JSON registry 里记录这个 Agent 的状态

为什么用 tmux 而不是直接 CLI？

tmux 的核心优势是：可以中途介入，而不需要杀掉进程重来。

Agent 跑偏了？直接 send-keys 告诉它停下来重新聚焦，不用重新启动，不浪费已有的上下文。

Step 3：Cron 监控脚本，每 10 分钟跑一次#

这是整个系统里我觉得最”工程师思维”的一步。

监控脚本做三件事：

检查 tmux session 是否还活着
检查 PR 状态
检查 CI 状态（通过 gh cli）

如果 Agent 挂了，自动重启，最多 3 次。

原文里有一句话值得单独拎出来：

100% deterministic, no token cost.

监控脚本是纯脚本逻辑，不调用任何 AI 接口。这是一个很重要的设计原则：能用确定性代码解决的问题，不要用 AI 解决。

Step 4：Agent 提 PR，但 PR ≠ 完成#

这一步很多人会忽略，但原作者专门强调了：

A PR alone isn’t “done.”

他定义了一套完成定义（Definition of Done，DoD），PR 必须满足以下条件才算真正完成：

✅ CI 通过（lint、types、unit tests、E2E、Playwright）
✅ 三个 AI Reviewer 全部通过
✅ UI 变更必须包含截图（否则 CI 直接失败）

这个 DoD 的意义在于：把”AI 说好了”变成”系统验证好了”。

Step 5：三模型代码 Review#

这是原文里最有意思的部分，也是原作者踩坑之后的真实评价：

Reviewer	擅长	原作者评价
Codex	边界情况、逻辑错误、竞态条件	最彻底，是主力
Gemini Code Assist	安全问题、可扩展性	免费，抓安全问题准
Claude Code	验证其他 Reviewer 的结论	”mostly useless”，过度谨慎，只看 critical

三个模型互补，不是因为哪个更聪明，而是因为它们的偏差方向不同。

Step 6 & 7：CI 门控 + Telegram 通知#

CI 跑完，三个 Reviewer 通过，截图包含—— 这时候，Telegram 才会 ping 他。

他收到通知之后，Review 只需要 5-10 分钟。很多 PR，他直接合并，没有读过代码。

这不是偷懒，这是系统设计的结果—— 前面的每一步，都是在为这一步的”放心合并”做铺垫。

Step 8：合并，清理#

每日 Cron 自动清理孤立的 worktree。成功的 Prompt 模式被记录下来，Zoe 下次写 Prompt 会更好。

系统在自我迭代。

四、Zoe 主动找工作#

这是整个系统里让我觉得最有意思的部分：

早上：扫描 Sentry → 发现错误 → 自动生成修复任务
开完会：扫描会议记录 → 标记 feature request → 生成开发任务
晚上：扫描 git log → 自动更新 changelog 和文档

这已经不是”AI 帮你写代码”了，这是AI 在帮你管理一个开发团队。

五、8 个可复用的设计原则#

#	原则	一句话说清楚为什么
1	上下文分层	编排层持业务，执行层持代码，各司其职
2	最小权限	Agent 只能碰它该碰的，Zoe 才有更高权限
3	明确 DoD	”AI 说好了”不算好，系统验证通过才算好
4	确定性监控	监控脚本不用 AI，100% 可预测，零 token 成本
5	多模型互补	用偏差方向不同的模型互相验证，不是用”更好”的模型
6	人工介入最小化	系统设计的目标是让人只在最后 5-10 分钟出现
7	截图 CI 门控	UI 变更没有截图，CI 直接失败，强制可视化验证
8	tmux 持久化	进程不死，上下文不丢，可以中途介入而不重来

六、和 Stripe “Minions” 的对比#

Stripe 在 2025 年发布了他们的内部 AI 编排系统，叫 “Minions”—— 用工程团队，花了大量资源，做了一套企业级的 Agent 编排架构。

原作者在 Mac Mini 上，用 OpenClaw，复现了同等的架构模式。

这个对比的意义不是”个人开发者比 Stripe 厉害”，而是：

这套架构模式已经被大公司验证了，同时，进入门槛正在快速降低。

今天需要 Mac Studio M4 Max 128GB（3500 美元）才能跑 5 个并行 Agent，明年可能只需要一台普通笔记本。

结尾：对我的启发#

作为一个 JS 全栈独立开发者，读完这篇，我在想的不是”我要搭一套一模一样的”——

我在想的是：这套架构里，哪些原则是现在就能用的？

现在就能用的：

多模型 Review（Codex + Gemini + Claude Code 三重验证）
截图 CI 门控（UI 变更必须有截图才能合并）
明确 DoD（在 PR 模板里写清楚”完成”的定义）
确定性监控脚本（用 gh cli 检查 CI 状态，不用 AI）

需要积累才值得投入的：

完整的编排层（需要有足够多的并行任务才值得）
Obsidian 自动同步会议记录（需要先养成记录习惯）
成功 Prompt 模式的自动归档（需要有一定量的历史数据）

有一句话，我最近一直在想——

风无形，但草知道它来过。

这套系统里，Zoe 就是那个风。她不写代码，但每一行代码，都知道她在场。

这大概就是巽的方式：不强迫，不控制，以信息渗透，以上下文引导，让执行者自然地走向正确的方向。

原帖来源：@elvissun on X Reddit 整理版：r/AskClaw 本文为个人学习笔记，基于原作者内容二次创作，观点为个人理解。

音乐

音乐