扇贝听力
126.68M · 2026-02-26
一个独立开发者，不开编辑器，一天提交 94 个 commit，30 分钟合并 7 个 PR。不是吹牛，是有 git 记录的。他的秘密武器不是某个超强模型，而是一套让 AI 管理 AI 的编排系统。
这两天 X 上有条推文火了。开发者 Elvis（@elvissun）写了一篇长文，详细拆解了他怎么用 OpenClaw 搭建了一个 AI agent 集群，让自己一个人干出了一个开发团队的活。Karpathy 看完直接评论：
翻译一下：分不清这是天才还是重度 AI 精神病，挺好的。
这条推文在 X 上引发了大量讨论。不是因为又一个人在吹 AI 多厉害，而是他把完整的工作流、代码、成本全摊开了讲。
Elvis 的做法说白了就一句话：他不再直接用 Codex 或 Claude Code 写代码了，而是让一个叫 Zoe 的 AI 编排器来管理这些 coding agent。
有人在评论区给了一个精准的类比：
这个比喻抓住了关键——你从「写代码的人」变成了「提需求的人」，中间多了一层 AI 帮你翻译需求、分配任务、坚控进度。
那为什么不直接跟 Codex 聊？
因为上下文窗口是零和博弈。塞满代码就没空间放业务信息，塞满客户历史就没空间看代码。Elvis 的解法是分两层：编排层掌握全局业务上下文，执行层只管写代码。
Zoe 连接着 Elvis 的 Obsidian 知识库，里面有客户数据、会议记录、过去的决策和踩过的坑。当客户提了一个需求，Zoe 知道这个客户之前用过什么配置、遇到过什么问题，然后把这些上下文翻译成精准的 prompt 喂给 coding agent。
agent 不需要知道客户是谁，只需要知道「在这三个文件里加一个模板系统，类型定义在 src/types/template.ts」。
Elvis 把整个流程拆成了 8 步。核心架构长这样：
简单说就是：开发者只跟编排器对话，编排器把任务拆解后分配给不同的 coding agent，每个 agent 在独立分支上干活。
几个关键细节值得展开讲。
Agent 隔离运行
每个任务都在独立的 git worktree 和 tmux session 里跑。这意味着 5 个 agent 可以同时在 5 个不同的功能分支上干活，互不干扰。
启动一个 agent 大概长这样：
agent 在 tmux session 里跑，具体的启动命令是这样的：
Codex：
Claude Code：
中途纠偏，不用杀掉重来
这是 tmux 方案比 codex exec 或 claude -p 好的地方。agent 跑偏了？直接往 tmux session 里发消息：
不用杀进程重启，不用丢失已有的上下文。就像你在 Slack 里跟同事说「方向不对，先做后端」一样。
任务追踪：JSON 注册表
每个 agent 任务都记录在 .clawdbot/active-tasks.json 里：
{
"id": "feat-custom-templates",
"tmuxSession": "codex-templates",
"agent": "codex",
"description": "Custom email templates for agency customer",
"repo": "medialyst",
"worktree": "feat-custom-templates",
"branch": "feat/custom-templates",
"startedAt": 1740268800000,
"status": "running",
"notifyOnComplete": true
}
任务完成后，自动更新状态和检查结果：
{
"status": "done",
"pr": 341,
"completedAt": 1740275400000,
"checks": {
"prCreated": true,
"ciPassed": true,
"claudeReviewPassed": true,
"geminiReviewPassed": true
},
"note": "All checks passed. Ready to merge."
}
自动坚控：每 10 分钟巡检
一个 cron job 每 10 分钟跑一次 .clawdbot/check-agents.sh，这个脚本是纯确定性的，不调用任何 AI，极省 token：
gh CLI 检查 CI 状态Elvis 不盯终端，系统会告诉他什么时候该看。
PR 完成的定义（很重要）
agent 提了 PR 不算完。Elvis 定义的 "done" 标准是：
最后一条是 Elvis 最近加的规则——强制 UI 截图。这大幅缩短了人工 review 时间，看一眼截图就知道改了什么，不用点进预览环境。
三个 AI 交叉审核
每个 PR 都要过三道 AI review，Elvis 的评价很直接：
| 审核者 | 擅长 | 评价 |
|---|---|---|
| Codex | 边界情况、竞态条件、逻辑错误 | 最靠谱，误报率低 |
| Gemini Code Assist | 安全问题、可扩展性 | 免费且好用 |
| Claude Code | 过度谨慎的建议 | "基本没用"，除非标记 critical |
说实话，Claude Code 在 review 环节被评为"基本没用"这个结论挺有意思的。它的问题不是能力不够，而是太保守——大量"consider adding..."的建议其实是过度工程化。
人工 Review 压缩到 5-10 分钟
等 Elvis 收到 T@elegrimm 通知的时候，CI 已经跑完、三个 AI 都审过了、UI 截图也附在 PR 里了。很多 PR 他看一眼截图就直接合并，都不用读代码。
这套系统最聪明的地方不是自动化本身，而是失败处理。
传统的 agent loop 失败了就用同样的 prompt 重跑。Elvis 的系统不一样——Zoe 会分析失败原因，结合业务上下文重写 prompt：
成功的模式也会沉淀下来。"这种 prompt 结构适合计费功能"、"Codex 需要先给类型定义"、"测试文件路径一定要写进 prompt"。
时间长了，Zoe 写 prompt 越来越准，因为她记得什么 prompt 最终成功 ship 了。
更狠的是，Zoe 不等 Elvis 分配任务，她会主动找活干：
Elvis 散步回来，T@elegrimm 上等着他的是："7 个 PR 等你 review，3 个新功能，4 个 bug 修复。"
Elvis 不迷信单一模型，而是按任务类型分配：
| 模型 | 定位 | 使用场景 |
|---|---|---|
| Codex (GPT-5.3) | 主力，占 90% | 后端逻辑、复杂 bug、跨文件重构 |
| Claude Code | 速度快 | 前端、git 操作 |
| Gemini | 设计感好 | 先出 HTML/CSS 设计稿，再交给 Claude 实现 |
Gemini 的用法比较有意思——不是直接让它写组件代码，而是让它先出设计稿，然后把设计稿交给 Claude Code 去实现。设计归设计，实现归实现。
Zoe 根据任务类型自动路由：计费系统的 bug 给 Codex，按钮样式调整给 Claude Code，新的 dashboard 设计先给 Gemini。
成本出乎意料地低：
但瓶颈不在钱，在硬件。每个 agent 需要独立的 worktree，每个 worktree 有自己的 node_modules，每个 agent 要跑构建、类型检查、测试。5 个 agent 同时跑意味着 5 个 TypeScript 编译器、5 个测试运行器同时吃内存。
Elvis 的 16GB Mac Mini 跑到 4-5 个 agent 就开始 swap 了。所以他花 $3500 买了台 128GB 的 Mac Studio M4 Max，3 月底到货。
这个瓶颈其实很有代表性——2026 年限制 AI 生产力的不是模型能力，而是本地算力。
Elvis 用这套系统在做什么？一个叫 Medialyst 的 B2B SaaS，帮初创公司用 AI agent 做 PR，不用花每月 $10k 请公关公司。
他的商业逻辑很简单：用 agent 集群实现当天交付客户需求。客户上午提需求，下午就能看到功能上线。这种速度在传统开发团队里不可能，但一个人 + agent 集群可以。
2026 年的分水岭不是谁的模型更强，而是谁能把 agent 编排成一个真正的生产系统。不是 demo，不是 POC，是每天跑在生产环境里、处理真实客户需求的系统。
评论区有人说得好：真正的不平等不在于谁买得起 token，而在于谁会用 agent。
