OpenClaw + Codex/ClaudeCode Agent Swarm：一人开发团队 [完整配置指南]

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

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

过去四周的成果证明：

• 一天 94 次提交。这是我效率最高的一天——当天我有 3 个客户电话，但一次都没打开过编辑器。平均每天大约 50 次提交。

• 30 分钟 7 个 PR。从想法到上线速度快得惊人，因为编码和验证基本都自动化了。

• 提交 → MRR：我在自己正在构建的一个真实 B2B SaaS 产品中使用了这套系统——将其与创始人主导的销售相结合，大部分功能请求都能当天交付。速度将潜在客户转化为付费客户。

我的 Git 历史看起来就像刚雇了一个开发团队。但实际上，只有我一个人，从管理 Claude Code 变成了管理一个 OpenClaw Agent，而这个 Agent 又管理着一群其他的 Claude Code 和 Codex Agent。

成功率：对于几乎所有中小型任务，系统无需任何干预就能一次性完成。

成本：Claude 每月约 100 美元，Codex 每月约 90 美元，但你也可以从 20 美元起步。

以下是为什么这比直接使用 Codex 或 Claude Code 效果更好的原因：

>Codex 和 Claude Code 对你的业务几乎没有任何上下文。

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

OpenClaw 改变了这个局面。它充当了你和所有 Agent 之间的编排层——它在我 Obsidian 笔记库中保存了我所有的业务上下文（客户数据、会议记录、过去的决策、什么有效、什么失败），并将历史上下文转化为每个编码 Agent 的精确提示词。Agent 专注于代码。编排器则专注于高层战略。

以下是系统在高层级上的工作方式：

上周，Stripe 写了一篇关于他们名为 "Minions" 的后台 Agent 系统的文章——这是一种由集中式编排层支持的并行编码 Agent。我无意中构建了同样的东西，但它是在我的 Mac mini 上本地运行的。

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

为什么一个 AI 无法兼顾两者

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

塞满代码 → 就没有空间放业务上下文。塞满客户历史 → 就没有空间放代码库。这就是为什么双层系统有效：每个 AI 只加载它确切需要的内容。

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

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

完整的 8 步工作流程

让我带你回顾上周的一个真实例子。

第 1 步：客户请求 → 与 Zoe 确定范围

我和一个代理机构客户通了电话。他们希望能够在团队中复用已经配置好的设置。

通话结束后，我和 Zoe 讨论了请求。因为我的所有会议记录都会自动同步到 Obsidian 笔记库，所以我这边几乎不需要解释。我们一起确定了功能范围——最终决定做一个模板系统，让他们可以保存和编辑现有的配置。

然后 Zoe 做了三件事：

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

第 2 步：生成 Agent

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

1# 创建工作树并生成 Agent
2git worktree add ../feat-custom-templates -b feat/custom-templates origin/main
3cd ../feat-custom-templates && pnpm install
4
5tmux new-session -d -s "codex-templates" \
6  -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \
7  "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"

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

以下是我们启动 Agent 的方式：

1# Codex
2codex --model gpt-5.3-codex \
3  -c "model_reasoning_effort=high" \
4  --dangerously-bypass-approvals-and-sandbox \
5  "你的提示词"
6
7# Claude Code
8claude --model claude-opus-4.5 \
9  --dangerously-skip-permissions \
10  -p "你的提示词"

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

tmux 好得多，因为 任务中途重定向 非常强大。Agent 走错方向了？不要杀死它：

1# 错误做法：
2tmux send-keys -t codex-templates "停止。先专注于 API 层，而不是 UI。" Enter
3
4# 需要更多上下文：
5tmux send-keys -t codex-templates "模式定义在 src/types/template.ts 中。使用那个。" Enter

任务会被跟踪在 .clawdbot/active-tasks.json 中：

1{
2  "id": "feat-custom-templates",
3  "tmuxSession": "codex-templates",
4  "agent": "codex",
5  "description": "为代理机构客户定制的电子邮件模板",
6  "repo": "medialyst",
7  "worktree": "feat-custom-templates",
8  "branch": "feat/custom-templates",
9  "startedAt": 1740268800000,
10  "status": "running",
11  "notifyOnComplete": true
12}

完成后，它会更新 PR 编号和检查状态。（更多内容见第 5 步）

1{
2  "status": "done",
3  "pr": 341,
4  "completedAt": 1740275400000,
5  "checks": {
6    "prCreated": true,
7    "ciPassed": true,
8    "claudeReviewPassed": true,
9    "geminiReviewPassed": true
10  },
11  "note": "所有检查通过。准备合并。"
12}

第 3 步：循环监控

一个 cron 任务每 10 分钟运行一次，负责监控所有 Agent。这基本上相当于一个改进版的 Ralph Loop，稍后会详细介绍。

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

1.clawdbot/check-agents.sh

该脚本是 100% 确定性的，并且极其节省 token：

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

我不需要盯着终端。系统会告诉我什么时候该看。

第 4 步：Agent 创建 PR

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

完成定义（你的 Agent 必须非常清楚这一点）：

• PR 已创建
• 分支已同步到 main（无合并冲突）
• CI 通过（lint、类型检查、单元测试、E2E 测试）
• Codex 审查通过
• Claude Code 审查通过
• Gemini 审查通过
• 包含截图（如果涉及 UI 变更）

第 5 步：自动化代码审查

每个 PR 都会由三个 AI 模型进行审查。它们能发现不同的问题：

• Codex 审查者——在边缘情况方面表现出色。审查最彻底。能发现逻辑错误、遗漏的错误处理、竞态条件。误报率非常低。
• Gemini Code Assist 审查者——免费且非常有用。能发现其他 Agent 遗漏的安全问题、可扩展性问题。并建议具体的修复方案。安装它是不用动脑筋的事。
• Claude Code 审查者——基本没什么用——往往过于谨慎。很多"考虑添加……"的建议通常都是过度设计。除非标记为关键，否则我会跳过所有内容。它很少能独立发现关键问题，但能验证其他审查者标记的内容。

三者都会直接在 PR 上发布评论。

第 6 步：自动化测试

我们的 CI 管道运行大量自动化测试：

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

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

第 7 步：人工审查

现在我收到 Telegram 通知："PR #341 准备审查。"

此时：

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

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

第 8 步：合并

PR 合并。一个每日 cron 任务会清理孤立的工作树和任务注册表 JSON。

Ralph Loop V2

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

Ralph Loop 从记忆中提取上下文、生成输出、评估结果、保存经验教训。但大多数实现每次循环都运行相同的提示词。提炼出的经验教训改进了未来的检索，但提示词本身保持不变。

我们的系统不同。当一个 Agent 失败时，Zoe 不会用相同的提示词简单地重启它。她会带着完整的业务上下文审视失败，并找出如何解除阻塞：

• Agent 上下文用完了？"只关注这三个文件。"
• Agent 走错了方向？"停止。客户想要的是 X，不是 Y。这是他们在会议上说的。"
• Agent 需要澄清？"这是客户的邮件以及他们公司的业务。"

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

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

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

我在客户电话后出去散步。回来时看到 Telegram 消息："7 个 PR 准备审查。3 个功能，4 个错误修复。"

当 Agent 成功时，模式会被记录下来。"这个提示词结构适用于计费功能。""Codex 需要预先提供类型定义。""始终包含测试文件路径。"

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

选择合适的 Agent

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

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

Claude Code 更快，在前端工作方面表现更好。它的权限问题也更少，因此非常适合 Git 操作。（我以前更多地用它来驱动日常工作，但 Codex 5.3 现在更优秀、更快）

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

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

如何设置

将整篇文章复制到 OpenClaw 中，并告诉它："为我的代码库实现这个 Agent 集群设置。"

它会读取架构、创建脚本、设置目录结构，并配置 cron 监控。10 分钟内完成。

没有课程要卖给你。

没人预料到的瓶颈

这是我目前遇到的瓶颈：RAM。

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

我那台 16GB 的 Mac Mini 在运行 4-5 个 Agent 时就开始使用交换内存了——而且我还得祈祷它们不会同时尝试构建。

所以我买了一台 Mac Studio M4 Max，配备 128GB 内存（3,500 美元）来驱动这个系统。它将在三月底到货，届时我会分享它是否值得。

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

从 2026 年开始，我们将看到大量一人百万美元公司。对于那些懂得如何构建递归自我改进 Agent 的人来说，杠杆效应是巨大的。

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

下一代创业者不会雇佣一个 10 人团队来做一个人用正确系统就能完成的事情。他们会像这样构建——保持小规模、快速行动、每日交付。

现在有太多 AI 生成的垃圾内容了。关于 Agent 和"任务控制中心"的炒作很多，但并没有构建任何真正有用的东西。花哨的演示，没有实际收益。

我试图做相反的事情：少一些炒作，多一些关于构建实际业务的记录。真实的客户、真实的收入、真实的上线提交，以及真实的损失。

我在构建什么？Agentic PR——一个挑战企业 PR 行业现有巨头的一人公司。帮助初创公司获得媒体报道的 Agent，无需每月 1 万美元的预付费。

如果你想看看我能走多远，请继续关注。