一人开发团队OpenClaw与Codex及Claude Code智能体集群完整搭建方案

最近看到一个挺有意思的案例：有位独立开发者，靠一套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就像个总管，掌握业务全局来分配任务；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全部通过、截图直观展示变更。作者只需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的价值远不止派发任务。更值得关注的是它的自我改进机制：每次成功合并在强化某种行为模式，每次失败则触发更好的提示词重构。这已经非常接近一个会自我进化的组织——只不过这个组织，只有一个人。

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