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 (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 会话中运行，互不干扰。

bash 复制代码

# 创建 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 而非直接执行？ 支持任务中途干预，无需杀掉进程重启：

perl 复制代码

# 方向跑偏时，直接发送新指令
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 编号和各项检查结果。

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
}

完成后，它会更新 PR 编号和检查。

json 复制代码

{
  "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都有自己的专长，可以根据实际任务找不同的专家：

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

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

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

原文链接：x.com/elvissun/st...