【转载】OpenClaw + Codex/ClaudeCode Agent Swarm: 一个人的开发团队（完整设置指南）

AI Agent OpenClaw Codex Claude Code 转载

💡 Elvis 这篇 X Article 在 24 小时内获得了 230 万次浏览和 2 万+ 收藏，完整记录了他如何用 OpenClaw 编排 AI Agent 集群来构建 SaaS 产品。以下是原文翻译。

cover

OpenClaw + Codex/ClaudeCode Agent Swarm: 一个人的开发团队（完整设置指南）

我已经不再直接使用 Codex 或 Claude Code 了。

我用 OpenClaw 作为编排层。我的编排器 Zoe 负责生成 Agent、编写 prompt、为每个任务选择合适的模型、监控进度，并在 PR 准备好合并时通过 Telegram 通知我。

过去 4 周的成果：

  • 一天 94 次 commit。我最高产的一天——当天有 3 个客户电话，但一次都没打开编辑器。日均大约 50 次 commit。
  • 30 分钟内 7 个 PR。从想法到生产的速度极快，因为编码和验证基本都是自动化的。
  • Commit → MRR：我用这套系统构建一个真实的 B2B SaaS——结合创始人主导的销售，大多数功能需求当天就能交付。速度将潜在客户转化为付费客户。

commit chart
Jan 之前：仅用 CC/Codex | Jan 之后：OpenClaw 编排 CC/Codex

我的 git 历史看起来像是刚招了一个开发团队。实际上只是我从「管理 Claude Code」变成了「管理一个编排 Claude Code 和 Codex 集群的 OpenClaw Agent」。

成功率：系统对几乎所有中小型任务都能一次完成，无需人工干预。

成本：Claude 大约 $100/月，Codex $90/月，但你可以从 $20 开始。

这套系统为什么比直接使用 Codex 或 Claude Code 更好：

Codex 和 Claude Code 对你的业务了解非常有限。

它们看到的是代码，看不到你业务的全貌。

OpenClaw 改变了这个等式。它充当你和所有 Agent 之间的编排层——它持有我所有的业务上下文（客户数据、会议笔记、过往决策、什么有效、什么失败了），这些都在我的 Obsidian vault 中，并将历史上下文转化为每个编码 Agent 的精确 prompt。Agent 专注于代码，编排器则保持在高层战略水平。

系统工作原理概览：

architecture

上周 Stripe 发表了关于他们的后台 Agent 系统 “Minions” 的文章——并行编码 Agent 加上集中式编排层。我无意中构建了相同的东西，但它运行在我的 Mac mini 上。

在我告诉你如何设置之前，你应该先了解为什么需要一个 Agent 编排器。

为什么一个 AI 做不了两件事

上下文窗口是零和博弈。你必须选择放什么进去。

填满代码 → 没有空间放业务上下文。填满客户历史 → 没有空间放代码库。这就是两层系统有效的原因：每个 AI 只加载它需要的内容。

OpenClaw 和 Codex 有截然不同的上下文：

context comparison

通过上下文实现专业化，而不是通过不同的模型。

完整的 8 步工作流

让我带你看一个上周的真实案例。

Step 1: 客户需求 → 与 Zoe 确定范围

我和一个代理商客户通了电话。他们想复用已经设置好的配置。

通话后，我和 Zoe 讨论了需求。因为我所有的会议笔记会自动同步到 Obsidian vault，我这边完全不需要解释。我们一起确定了功能范围——最终落在一个模板系统上，让他们可以保存和编辑现有配置。

然后 Zoe 做了三件事：

  1. 充值额度以立即解除客户限制——她有管理员 API 权限
  2. 从生产数据库拉取客户配置——她有只读生产数据库权限（我的 Codex Agent 永远不会有这个），检索客户现有设置并包含在 prompt 中
  3. 生成一个 Codex Agent——附带包含所有上下文的详细 prompt

Step 2: 生成 Agent

每个 Agent 都有自己的 worktree（隔离分支）和 tmux 会话：

# Create worktree + spawn 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" \
  -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \
  "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"

Agent 在 tmux 会话中运行，通过脚本记录完整终端日志。

启动 Agent 的方式：

# 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"

我以前用 codex exec 或 claude -p，但最近切换到了 tmux：

tmux 更好是因为任务中重定向非常强大。Agent 方向走偏了？不要杀掉它：

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

# Needs more context:
tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter

任务在 .clawdbot/active-tasks.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 编号和检查状态：

{
  "status": "done",
  "pr": 341,
  "completedAt": 1740275400000,
  "checks": {
    "prCreated": true,
    "ciPassed": true,
    "claudeReviewPassed": true,
    "geminiReviewPassed": true
  },
  "note": "All checks passed. Ready to merge."
}

Step 3: 循环监控

一个 cron job 每 10 分钟运行一次来监护所有 Agent。这基本上是改进版的 Ralph Loop，后面会详细说。

但它不直接轮询 Agent——那太贵了。相反，它运行一个脚本读取 JSON 注册表并检查：

.clawdbot/check-agents.sh

这个脚本是 100% 确定性的，极其节省 token：

  • 检查 tmux 会话是否存活
  • 检查跟踪分支上是否有打开的 PR
  • 通过 gh cli 检查 CI 状态
  • 如果 CI 失败或有关键审查反馈，自动重新生成失败的 Agent（最多 3 次）
  • 只在需要人工关注时发出警报

我不看终端。系统告诉我什么时候该看。

Step 4: Agent 创建 PR

Agent 提交、推送，并通过 gh pr create --fill 打开 PR。此时我不会收到通知——仅有 PR 并不算完成。

完成的定义（让你的 Agent 知道这一点非常重要）：

  • PR 已创建
  • 分支与 main 同步（无合并冲突）
  • CI 通过（lint, types, 单元测试, E2E）
  • Codex 审查通过
  • Claude Code 审查通过
  • Gemini 审查通过
  • 包含截图（如果有 UI 变更）

Step 5: 自动化代码审查

每个 PR 都经过三个 AI 模型审查。它们捕获不同的问题：

  1. Codex Reviewer — 在边界情况方面表现出色。做最彻底的审查。捕获逻辑错误、缺失的错误处理、竞态条件。误报率非常低。
  2. Gemini Code Assist Reviewer — 免费且极其有用。捕获其他 Agent 遗漏的安全问题和可扩展性问题，并建议具体修复。安装它毫无疑问。
  3. Claude Code Reviewer — 大多数情况下没什么用——倾向于过度谨慎。大量 “consider adding…” 的建议通常是过度工程化。除非标记为关键问题否则我都跳过。它很少自己发现关键问题，但能验证其他审查者标记的内容。

三个模型都直接在 PR 上发表评论。

Step 6: 自动化测试

我们的 CI 流水线运行大量自动化测试：

  • Lint 和 TypeScript 检查
  • 单元测试
  • E2E 测试
  • 针对预览环境（与生产环境相同）的 Playwright 测试

上周我加了一条新规则：如果 PR 修改了任何 UI，必须在 PR 描述中包含截图，否则 CI 失败。这大幅缩短了审查时间——我可以直接看到什么变了，不用点击预览。

Step 7: 人工审查

现在我收到 Telegram 通知：“PR #341 ready for review。”

到这个时候：

  • CI 通过
  • 三个 AI 审查者批准了代码
  • 截图展示了 UI 变化
  • 所有边界情况都在审查评论中记录

我的审查只需 5-10 分钟。很多 PR 我不读代码就直接合并——截图告诉了我需要知道的一切。

Step 8: 合并

PR 合并。每日 cron job 清理孤立的 worktree 和任务注册表 JSON。

Ralph Loop V2

这本质上是 Ralph Loop，但更好。

Ralph Loop 从记忆中拉取上下文，生成输出，评估结果，保存学习成果。但大多数实现每个循环运行相同的 prompt。蒸馏出的学习成果改善了未来的检索，但 prompt 本身保持不变。

我们的系统不同。当 Agent 失败时，Zoe 不是简单地用相同的 prompt 重新生成它。她带着完整的业务上下文审视失败，并找出如何解除阻塞：

  • Agent 上下文用完了？“只关注这三个文件。”
  • Agent 方向走偏了？“停下。客户要的是 X 不是 Y。这是他们在会议上说的。”
  • Agent 需要澄清？“这是客户的邮件和他们公司的情况。”

Zoe 全程监护 Agent 直到完成。她拥有 Agent 没有的上下文——客户历史、会议笔记、我们之前尝试过什么、为什么失败。她用这些上下文在每次重试时写出更好的 prompt。

但她也不等我分配任务。她主动寻找工作：

  • 早上：扫描 Sentry → 发现 4 个新错误 → 生成 4 个 Agent 调查和修复
  • 会议后：扫描会议笔记 → 标记客户提到的 3 个功能请求 → 生成 3 个 Codex Agent
  • 晚上：扫描 git log → 生成 Claude Code 更新 changelog 和客户文档

我在客户电话后出去散步。回来看 Telegram：“7 个 PR 准备审查。3 个功能，4 个 bug 修复。”

当 Agent 成功时，模式会被记录下来。“这种 prompt 结构适合计费功能。““Codex 需要预先提供类型定义。““总是包含测试文件路径。”

奖励信号是：CI 通过、三个代码审查通过、人工合并。任何失败都会触发循环。随着时间推移，Zoe 写出更好的 prompt，因为她记住了什么成功发布了。

选择合适的 Agent

并非所有编码 Agent 都是平等的。快速参考：

Codex 是我的主力。后端逻辑、复杂 bug、跨文件重构，任何需要在代码库中进行推理的任务。它更慢但更彻底。我 90% 的任务都用它。

Claude Code 更快，前端工作更出色。它的权限问题也更少，所以非常适合 git 操作。（我以前更多用它来驱动日常工作，但 Codex 5.3 现在确实更好更快）

Gemini 有不同的超能力——设计感。对于漂亮的 UI，我会让 Gemini 先生成 HTML/CSS 规范，然后交给 Claude Code 在我们的组件系统中实现。Gemini 设计，Claude 构建。

Zoe 为每个任务选择合适的 Agent 并在它们之间路由输出。计费系统 bug 交给 Codex。按钮样式修复交给 Claude Code。新的 dashboard 设计从 Gemini 开始。

如何搭建

把这整篇文章复制到 OpenClaw 里，告诉它：“为我的代码库实现这个 Agent 集群设置。”

它会读取架构、创建脚本、设置目录结构、配置 cron 监控。10 分钟搞定。

没有课程要卖给你。

没人预料到的瓶颈

我现在遇到的天花板是：RAM。

每个 Agent 需要自己的 worktree。每个 worktree 需要自己的 node_modules。每个 Agent 运行构建、类型检查、测试。五个 Agent 同时运行意味着五个并行的 TypeScript 编译器、五个测试运行器、五套依赖加载到内存。

我的 Mac Mini 16GB 在 4-5 个 Agent 时就开始 swap 了——而且还得运气好它们不同时构建。

所以我买了一台 128GB RAM 的 Mac Studio M4 Max（$3,500）来驱动这套系统。3 月底到货，届时会分享是否值得。

下一步：一个人的百万美元公司

2026 年我们将看到大量一人百万美元公司出现。对于理解如何构建递归自我改进 Agent 的人来说，杠杆效应是巨大的。

这就是它的样子：一个 AI 编排器作为你自身的延伸（就像 Zoe 之于我），将工作委派给专注不同业务功能的专业 Agent。工程。客户支持。运营。营销。每个 Agent 专注于它擅长的事情。你保持激光般的专注和完全的控制。

下一代创业者不会雇佣 10 人团队来做一个拥有正确系统的人就能做的事。他们会这样构建——保持小团队，快速行动，每天发布。

现在有太多 AI 生成的垃圾内容。围绕 Agent 和"任务控制台"的炒作太多了，却没有构建任何真正有用的东西。华丽的演示没有真实世界的收益。

我在尝试做相反的事：少一些炒作，多一些构建真实业务的记录。真实的客户，真实的收入，真实的提交到生产的 commit，也有真实的损失。

我在构建什么？Agentic PR——一个一人公司挑战企业级 PR 巨头。帮助初创公司获得媒体报道的 Agent，不需要每月 $10k 的顾问费。

如果你想看我能走多远，跟着看吧。

原文作者：Elvis (@elvissun) | 原文链接：X Article | 原文发布于 2026-02-23

☕ 如果这篇文章对你有帮助，欢迎请我喝杯咖啡，支持我继续创作更多内容。

Buy me a coffee