实战案例 | OpenClaw + Codex/Claude Code 智能体集群：一人开发团队的完整搭建方案

最近了看到了一个独立开发者分享了一个很酷的案例，他使用 OpenClaw + Codex/Claude code搭建了一个AI Agent，然后他完全没打开编辑器就把功能实现了，并完成了交付。

以下是他过去四周的实际数据：

• 单日最高 94 次提交（当天有 3 个客户电话，全程未打开编辑器），日均约 50 次提交
• 30 分钟内完成 7 个 PR
• 这套系统服务于作者正在构建的真实 B2B SaaS 产品，能做到同天交付客户功能请求，显著提升销售转化率

看着是不是很吓人？

从git 历史看起来像是刚雇一整个开发团队所作出的贡献。实际上，他只是从管理 Claude 代码，转变为管理一个 Openclaw 代理，该代理管理着一支其他 claude code 和 codex 代理的超级团队。

看了文章之后我觉得还是挺有启发的，所以就整理了这篇文章。

如果你也在学习怎么用openclaw来搭建一人超级团队，希望你可以从这里得到帮助。

为什么需要两层架构？

原文中，作者说他不再直接使用 Codex 或 Claude Code，而是以 OpenClaw 作为编排层。

他弄的编排智能体叫 Zoe，主要负责：派生子智能体、编写提示词、为每个任务选择合适的模型、监控进度，并在 PR 准备好合并时通过 Telegram 通知作者。

在这个时候，你可以会问：为什么不直接使用Claude code或者Codex，还需要加一个编排？

作者给的答案很清楚：Codex 和 Claude Code 对你的业务几乎一无所知。他们只看代码，没有你业务完整的上下文信息。

这其中的核心矛盾就是：上下文窗口是零和博弈。

• 填满代码 → 没有空间容纳业务背景
• 填满客户历史 → 没有空间容纳代码库

因此两层分工如下：

Openclaw就相当于管家，根据自己的业务知识分配任务；Codex / Claude Code就是员工，收到命令只要负责执行即可。

专业化来自上下文分配，而非依赖不同模型。

完整的 8 步工作流

Step 1：需求接收 → 与 Zoe 共同拆解

客户提出需求后，作者与 Zoe 对话拆解功能范围。由于会议记录自动同步至 Obsidian 知识库，作者无需额外解释背景。

作者最终和Zoe确定了一个模板系统，让他们能够保存和编辑现有的配置。

Zoe 随即完成三件事：

1. 补充 API 额度，立即解除客户阻塞（Zoe 有管理员 API 权限）
2. 从生产数据库拉取客户配置（Zoe 有只读权限，编码智能体永远没有）
3. 携带完整上下文提示词，派生一个 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
• 通过 gh CLI 检查 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 全部通过、截图直观展示变更且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都有自己的专长，可以根据实际任务找不同的专家：

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 的价值远不止派发任务。更值得关注的是它的自我改进机制。每次成功合并在强化某种行为模式，每次失败在触发更好的提示词重构。这已经非常接近一个会自我进化的组织，只不过整个组织只是一个人而已。

一人公司的天花板，正在被重新定义。

如果你也在探索 AI Agent 的搭建，希望这个案例对你有用。