最近看到一个挺有意思的案例：有位独立开发者，靠一套AI Agent系统，愣是把自己活成了一个开发团队。真的，连编辑器都没打开，就把功能实现了，还完成了交付。
先看几组实际数据，感受一下冲击力：
- 单日最高94次提交（那天接了3个客户电话，全程没碰编辑器），日均大约50次提交
- 30分钟内完成7个PR
- 这套系统服务于作者正在构建的真实B2B SaaS产品，能做到同天交付客户功能请求，销售转化率明显提升
从git历史来看，这简直像一个完整开发团队干出来的活。实际上呢？他做的事情，只是从直接管理Claude Code，转变为管理一个OpenClaw编排层——而这个编排层，又在管理着一群Claude Code和Codex的执行智能体。
挺有启发，所以整理成一篇文章。如果你也在琢磨怎么用OpenClaw搭建一人超级团队，希望能派上用场。
为什么需要两层架构？
作者分享的核心思路是：他不再直接使用Codex或Claude Code，而是用OpenClaw作为编排层。这个编排智能体叫做Zoe，主要职责包括：派生子智能体、编写提示词、为每个任务选择合适的模型、监控进度，并在PR准备好合并时通过Telegram通知。
那你可能会问：为什么不直接上Codex或Claude Code，非要中间加一层？
答案很明确：Codex和Claude Code对你的业务几乎一无所知。它们只看得见代码，没有你业务完整的上下文信息。核心矛盾在于——上下文窗口是零和博弈。
- 填满代码 → 没有空间容纳业务背景
- 填满客户历史 → 没有空间容纳代码库
于是，两层架构的分工就清晰了：
| 层级 | 角色 | 上下文内容 |
|---|---|---|
| OpenClaw (Zoe) | 编排层 | 客户数据、会议记录、历史决策、业务战略 |
| Codex / Claude Code | 执行层 | 代码库、类型定义、测试文件 |
OpenClaw就像个总管，掌握业务全局来分配任务；Codex / Claude Code则是精干的执行员工，接到指令只管干活。
专业化的关键在于上下文的合理分配，而不是依赖不同模型本身。
完整的8步工作流
Step 1：需求接收 → 与Zoe共同拆解
客户提需求后，作者与Zoe对话，拆解功能范围。因为会议记录会自动同步到Obsidian知识库，作者不用额外解释背景。最终和Zoe敲定了一个模板系统，让团队能保存和编辑现有配置。
Zoe随即完成三件事：
- 补充API额度，立刻解除客户阻塞（Zoe有管理员API权限）
- 从生产数据库拉取客户配置（Zoe只有只读权限，编码智能体永远没有）
- 携带完整上下文提示词，派生一个Codex智能体
Step 2：派生智能体
每个智能体都在独立的git worktree和tmux会话中运行，互不干扰。
# 创建worktree + 派生智能体
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" -c "/path/to/worktrees/feat-custom-templates" "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"为什么用tmux而不是直接执行？ 支持任务中途干预，不用杀掉进程重启：
# 方向跑偏时，直接发送新指令
tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter
# 需要补充上下文时
tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter每个任务的状态记录在 .clawdbot/active-tasks.json，包含tmux会话名、分支名、启动时间、当前状态等字段。完成后自动更新PR编号和各项检查结果。
{
"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
}完成后，它会自动更新PR编号和检查状态。
{
"status": "done",
"pr": 341,
"completedAt": 1740275400000,
"checks": {
"prCreated": true,
"ciPassed": true,
"claudeReviewPassed": true,
"geminiReviewPassed": true
},
"note": "All checks passed. Ready to merge."
}Step 3：循环监控
每10分钟运行一次cron任务，读取JSON注册表（不直接问智能体，避免浪费token），执行以下检查：
- tmux会话是否存活
- 追踪分支上是否有待处理PR
- 通过
ghCLI检查CI状态 - CI失败或代码审查反馈严重问题时，自动重新派生（最多3次）
- 只在需要人工介入时才发送通知
作者并不盯着终端，只有真正需要确认的时候，Agent才会通知他。
Step 4：智能体创建PR
Agent完成后提交代码、推送分支，并通过gh pr create --fill创建PR。此时不会通知作者——光有一个PR，还不算完成。完成的定义是智能体必须满足所有条件：
- PR已创建
- 分支已同步main（无合并冲突）
- CI全部通过（lint、类型检查、单元测试、E2E）
- Codex代码审查通过
- Claude Code代码审查通过
- Gemini代码审查通过
- 如有UI变更，PR描述中必须包含截图
Step 5：自动化代码审查
每个PR由三个模型分别审查，各有侧重：
- Codex审查员：最擅长边界情况，能发现逻辑错误、缺失的错误处理、竞态条件，误报率极低
- Gemini Code Assist：免费且实用，擅长安全问题和可扩展性分析，直接给出具体修改建议
- Claude Code审查员：倾向过度谨慎，常给出"可以考虑添加..."之类的建议。作者只关注标记为critical的问题，主要用于交叉验证其他审查员的发现
Step 6：自动化测试
CI流水线涵盖：
- Lint检查
- TypeScript类型检查
- 单元测试
- E2E测试
- 针对预发布环境（与生产完全一致）的Playwright测试
上周新增了一条规则：如果PR涉及UI变更，必须在描述中附上截图，否则CI直接失败。这大幅缩短了审查时间。
Step 7：人工审查
到了这一步，作者会收到Telegram的通知："PR #341 ready for review"。此时的PR已经过三轮AI审查、CI全部通过、截图直观展示变更。作者只需5到10分钟就能完成审查，很多PR甚至不用读代码，看截图就能决定是否合并。
Step 8：合并与清理
PR合并。每日cron任务自动清理孤立的worktree和任务注册表。
进化版Ralph Loop：Zoe的自我改进机制
传统的Ralph Loop核心是：提取记忆 → 生成输出 → 评估结果 → 保存学习。但大多数实现每次循环都用相同的提示词，改进仅来自历史记忆的提炼，提示词本身是静态的。
作者系统的不同之处在于：当智能体失败时，Zoe不是简单用相同提示词重试，而是结合完整的业务上下文分析失败原因，重新构建提示词：
- 智能体上下文耗尽？→ "只关注这三个文件"
- 方向跑偏？→ "停下。客户想要的是X，不是Y。这是他们在会议中说的原话"
- 需要澄清？→ "这是客户的邮件以及他们公司的业务描述"
Zoe还会主动发现工作，而不只是等待分配：
- 早上：扫描Sentry错误日志 → 发现4个新错误 → 派生4个智能体排查修复
- 会议结束后：扫描会议记录 → 识别客户提到的3个功能请求 → 派生3个Codex智能体
- 晚间：扫描git log → 派生Claude Code更新changelog和客户文档
成功的模式会被记录下来，比如"这种提示词结构适用于计费功能"、"Codex需要在开头提供类型定义"、"始终包含测试文件路径"。奖励信号来自：CI通过、三方代码审查通过、人工合并。任何失败都会触发循环。随着时间推移，Zoe的提示词质量持续提升。
Agent选型指南——根据任务选择合适的Agent
每个Agent都有自己的专长，要根据实际任务找不同的专家：
| Agent | 适用场景 | 特点 |
|---|---|---|
| Codex | 后端逻辑、复杂bug、多文件重构、需要跨代码库推理的任务 | 速度较慢但更彻底，占作者90%的任务量 |
| Claude Code | 前端工作、git操作 | 速度更快，权限问题更少 |
| Gemini | UI设计稿生成 | 设计感强，先由Gemini生成HTML/CSS规格稿，再交由Claude Code在组件系统中实现 |
Zoe负责为每个任务路由到最合适的智能体：计费系统bug → Codex，按钮样式调整 → Claude Code，新仪表盘设计 → 先Gemini后Claude Code。
如何快速搭建？
想快速复现这个系统？最直接的办法就是：把这篇文章的全部内容复制到OpenClaw中，然后告诉它："为我实现这个编排层设置。" OpenClaw会自动读取架构、创建脚本、设置目录结构，并配置cron监控。最快10分钟就能完成搭建。
成本与瓶颈
当前成本：Claude大约100美元/月，Codex大约90美元/月，最低可以从20美元起步。
当前瓶颈：内存。每个智能体需要独立的worktree，每个worktree又需要独立的node_modules。并行运行的智能体意味着多个TypeScript编译器、测试运行器同时抢占内存。作者的Mac Mini（16GB）在4到5个智能体并发时就开始内存交换。为此，他已经订购了Mac Studio M4 Max（128GB内存，3500美元），后续会分享实际效果。
核心价值总结
这套系统的本质是：作者不再直接管理Claude Code，而是管理一个控制着Claude Code/Codex智能体集群的OpenClaw编排层。git历史看起来像雇了一个开发团队，实际上只有一个人。
传统的一人公司，瓶颈在于人的精力和时间有限。你能做的事情越多，注意力就越分散，质量就越难保证。这套系统真正解决的问题不是"怎么写更多代码"，而是如何把人的注意力从执行层彻底解放出来，专注在判断层。
Zoe的价值远不止派发任务。更值得关注的是它的自我改进机制：每次成功合并在强化某种行为模式，每次失败则触发更好的提示词重构。这已经非常接近一个会自我进化的组织——只不过这个组织，只有一个人。
一人公司的天花板，正在被重新定义。
