Codex + Claude Code + 一个编排器：独立开发者的「一人军团」实战手册

一个独立开发者，不开编辑器，一天提交 94 个 commit，30 分钟合并 7 个 PR。不是吹牛，是有 git 记录的。他的秘密武器不是某个超强模型，而是一套让 AI 管理 AI 的编排系统。

这两天 X 上有条推文火了。开发者 Elvis（@elvissun）写了一篇长文，详细拆解了他怎么用 OpenClaw 搭建了一个 AI agent 集群，让自己一个人干出了一个开发团队的活。Karpathy 看完直接评论：

"Can't tell if brilliant or severe AI psychosis nice"

翻译一下：分不清这是天才还是重度 AI 精神病，挺好的。

这条推文在 X 上引发了大量讨论。不是因为又一个人在吹 AI 多厉害，而是他把完整的工作流、代码、成本全摊开了讲。

核心思路：让 AI 管 AI，而不是你管 AI

Elvis 的做法说白了就一句话：他不再直接用 Codex 或 Claude Code 写代码了，而是让一个叫 Zoe 的 AI 编排器来管理这些 coding agent。

有人在评论区给了一个精准的类比：

用 Codex/Claude Code，你是建筑师在跟总包说话。用 OpenClaw，你是甲方在跟建筑师说话。

这个比喻抓住了关键------你从「写代码的人」变成了「提需求的人」，中间多了一层 AI 帮你翻译需求、分配任务、监控进度。

那为什么不直接跟 Codex 聊？

因为上下文窗口是零和博弈。塞满代码就没空间放业务信息，塞满客户历史就没空间看代码。Elvis 的解法是分两层：编排层掌握全局业务上下文，执行层只管写代码。

Zoe 连接着 Elvis 的 Obsidian 知识库，里面有客户数据、会议记录、过去的决策和踩过的坑。当客户提了一个需求，Zoe 知道这个客户之前用过什么配置、遇到过什么问题，然后把这些上下文翻译成精准的 prompt 喂给 coding agent。

agent 不需要知道客户是谁，只需要知道「在这三个文件里加一个模板系统，类型定义在 src/types/template.ts」。

8 步工作流：从客户电话到代码合并

Elvis 把整个流程拆成了 8 步。核心架构长这样：

简单说就是：开发者只跟编排器对话，编排器把任务拆解后分配给不同的 coding agent，每个 agent 在独立分支上干活。

几个关键细节值得展开讲。

Agent 隔离运行

每个任务都在独立的 git worktree 和 tmux session 里跑。这意味着 5 个 agent 可以同时在 5 个不同的功能分支上干活，互不干扰。

启动一个 agent 大概长这样：

git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install tmux new-session -d -s "codex-templates" "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"

agent 在 tmux session 里跑，具体的启动命令是这样的：

Codex：

codex --model gpt-5.3-codex -c "model_reasoning_effort=high" --dangerously-bypass-approvals-and-sandbox "Your prompt here"

Claude Code：

claude --model claude-opus-4.5 --dangerously-skip-permissions -p "Your prompt here"

中途纠偏，不用杀掉重来

这是 tmux 方案比 codex exec 或 claude -p 好的地方。agent 跑偏了？直接往 tmux session 里发消息：

tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter

不用杀进程重启，不用丢失已有的上下文。就像你在 Slack 里跟同事说「方向不对，先做后端」一样。

任务追踪：JSON 注册表

每个 agent 任务都记录在 .clawdbot/active-tasks.json 里：

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
}

任务完成后，自动更新状态和检查结果：

json 复制代码

{
  "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：

检查 tmux session 是否还活着
检查对应分支是否有 open PR
通过 gh CLI 检查 CI 状态
CI 失败或收到严重 review 反馈时，自动重启 agent（最多 3 次）
只有需要人工介入时才发通知

Elvis 不盯终端，系统会告诉他什么时候该看。

PR 完成的定义（很重要）

agent 提了 PR 不算完。Elvis 定义的 "done" 标准是：

PR 已创建
分支已同步到 main（无合并冲突）
CI 全部通过（lint、类型检查、单测、E2E）
Codex review 通过
Claude Code review 通过
Gemini review 通过
如果涉及 UI 变更，PR 描述中必须包含截图（否则 CI 直接失败）

最后一条是 Elvis 最近加的规则------强制 UI 截图。这大幅缩短了人工 review 时间，看一眼截图就知道改了什么，不用点进预览环境。

三个 AI 交叉审核

每个 PR 都要过三道 AI review，Elvis 的评价很直接：

审核者	擅长	评价
Codex	边界情况、竞态条件、逻辑错误	最靠谱，误报率低
Gemini Code Assist	安全问题、可扩展性	免费且好用
Claude Code	过度谨慎的建议	"基本没用"，除非标记 critical

说实话，Claude Code 在 review 环节被评为"基本没用"这个结论挺有意思的。它的问题不是能力不够，而是太保守------大量"consider adding..."的建议其实是过度工程化。

人工 Review 压缩到 5-10 分钟

等 Elvis 收到 Telegram 通知的时候，CI 已经跑完、三个 AI 都审过了、UI 截图也附在 PR 里了。很多 PR 他看一眼截图就直接合并，都不用读代码。

Ralph Loop V2：失败了不是简单重试

这套系统最聪明的地方不是自动化本身，而是失败处理。

传统的 agent loop 失败了就用同样的 prompt 重跑。Elvis 的系统不一样------Zoe 会分析失败原因，结合业务上下文重写 prompt：

Agent 上下文爆了？"只关注这三个文件。"
Agent 方向跑偏？"客户要的是 X 不是 Y，这是他们会议上说的原话。"
Agent 需要更多信息？"这是客户的邮件和他们公司的业务。"

成功的模式也会沉淀下来。"这种 prompt 结构适合计费功能"、"Codex 需要先给类型定义"、"测试文件路径一定要写进 prompt"。

时间长了，Zoe 写 prompt 越来越准，因为她记得什么 prompt 最终成功 ship 了。

更狠的是，Zoe 不等 Elvis 分配任务，她会主动找活干：

早上扫 Sentry 错误日志 → 发现 4 个新 bug → 自动生成 4 个 agent 去修
会议结束后扫会议记录 → 找到 3 个客户提到的功能需求 → 生成 3 个 agent 去做
晚上扫 git log → 生成 agent 更新 changelog 和客户文档

Elvis 散步回来，Telegram 上等着他的是："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。

成本和瓶颈

成本出乎意料地低：

Claude：约 $100/月
Codex：$90/月
起步价：$20 就能跑起来

但瓶颈不在钱，在硬件。每个 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。

要点回顾

核心架构：编排层（Zoe）管业务上下文 + 执行层（Codex/Claude Code）管代码，上下文分离是关键
实战数据：日均 50 commit，30 分钟 7 个 PR，中小任务几乎零干预
成本： <math xmlns="http://www.w3.org/1998/Math/MathML"> 190 / 月（ C l a u d e 190/月（Claude </math>190/月（Claude100 + Codex <math xmlns="http://www.w3.org/1998/Math/MathML"> 90 ）， 90）， </math>90），20 可起步
失败处理：不是简单重试，而是结合业务上下文重写 prompt
瓶颈：不是模型能力，是本地 RAM（16GB 只能跑 4-5 个 agent）
趋势：2026 年将出现大量「一人百万美元公司」，agent 编排能力是核心竞争力

参考链接

Elvis 原文推文：x.com/elvissun/st...
OpenClaw 官方文档：docs.openclaw.ai
OpenClaw GitHub：github.com/openclaw/op...