OpenClaw + Codex/ClaudeCode Agent Swarm：单人开发团队

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

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

过去 4 周的成果：

一天提交了 94 次代码。这是我效率最高的一天------我接了 3 个客户电话，一次编辑器都没打开。平均每天提交约 50 次代码。
30 分钟内提交了 7 个 PR。从构思到生产的速度非常快，因为编码和验证大部分都是自动化的。
提交次数 → 月度经常性收入 (MRR)：我将其用于我正在构建的真正的 B2B SaaS 产品------将其与创始人主导的销售相结合，以便当天交付大多数功能请求。速度是将潜在客户转化为付费客户的关键。

我的 Git 历史记录看起来就像我刚招了个开发团队。实际上，我只是从管理 Claude 代码，转而管理一个 OpenClaw 代理，这个代理又管理着一大批其他的 Claude 代码和 Codex 代理。

成功率：该系统几乎可以一次性完成所有中小型任务，无需任何人工干预。

费用：Claude 每月约 100 美元，Codex 每月约 90 美元，但您可以从 20 美元起步。

这就是为什么它比直接使用 Codex 或 Claude Code 更有效的原因：

Codex 和 Claude Code 对您的业务了解甚少。

它们只能看到代码，而无法了解您业务的全貌。

OpenClaw 改变了这种局面。它充当您和所有代理之间的协调层------它将我所有的业务背景信息（客户数据、会议记录、过往决策、成功经验和失败教训）保存在我的 Obsidian 存储库中，并将历史背景信息转化为每个编码代理的精准提示。代理可以专注于代码编写，而协调层则可以专注于高层战略。

以下是该系统的工作原理概述：

上周 Stripe 介绍了他们的后台代理系统"Minions"------由集中式编排层支持的并行编码代理。我不小心也搭建了一个类似的系统，不过它运行在我的 Mac mini 本地。

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

为什么一个人工智能无法同时处理所有事情

上下文窗口是零和博弈。你必须选择放入哪些内容。

如果填充代码 → 就没有空间容纳业务上下文。如果填充客户历史记录 → 就没有空间容纳代码库。这就是双层系统有效的原因：每个人工智能都加载了它所需的全部内容。

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

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

完整的八步工作流程

让我举一个上周的实际例子。

步骤 1：客户需求 → 与 Zoe 进行范围界定

我与一家代理机构的客户进行了通话。他们希望在团队中复用已设置的配置。

通话结束后，我与 Zoe 讨论了他们的需求。由于我的所有会议记录都会自动同步到我的 Obsidian Vault，因此我无需进行任何解释。我们一起确定了功能范围，最终确定了一个模板系统，允许他们保存和编辑现有配置。

然后 Zoe 执行三项操作：

充值以立即解锁客户------她拥有管理员 API 权限
从生产数据库拉取客户配置------她拥有只读的生产数据库权限（我的 Codex 代理永远不会拥有此权限），以检索其现有设置，并将其包含在提示信息中
生成一个 Codex 代理------并显示包含所有上下文的详细提示信息

步骤 2：生成代理

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

bash 复制代码

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

该代理程序在 tmux 会话中运行，并通过脚本进行完整的终端日志记录。

以下是启动代理程序的方法：

bash 复制代码

# 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 好得多，因为它支持任务中途重定向。代理程序运行方向错误？别终止它：

bash 复制代码

# 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 文件中：

bash 复制代码

{
  "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 编号并进行检查。（更多内容请参见步骤 5）

bash 复制代码

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

步骤 3：循环监控

一个 cron 任务每 10 分钟运行一次，监控所有代理。这基本上是一个改进版的 Ralph Loop，稍后会详细介绍。

但它不会直接轮询代理------那样开销太大。相反，它会运行一个脚本来读取 JSON 注册表并检查：

bash 复制代码

.clawdbot/check-agents.sh

该脚本完全确定性，且令牌效率极高：

检查 tmux 会话是否处于活动状态
检查跟踪分支上是否存在未完成的 PR
通过 gh cli 检查 CI 状态
如果 CI 失败或收到关键审查反馈，则自动重启失败的代理（最多尝试 3 次）
仅在需要人工干预时发出警报

我不会监控终端。系统会告知我何时需要查看。

步骤 4：代理创建 PR

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

完成的定义（代理必须了解这一点，非常重要）：

PR 已创建
分支已同步到主分支（无合并冲突）
CI 通过（lint、types、单元测试、端到端测试）
Codex 审查通过
Claude Code 审查通过
Gemini 审查通过
包含屏幕截图（如果 UI 发生更改）

步骤 5：自动化代码审查

每个 PR 都会由三个 AI 模型进行审查。它们各自负责不同的问题：

Codex Reviewer --- 擅长处理各种极端情况。审查最为彻底，能够发现逻辑错误、缺失的错误处理和竞态条件。误报率极低。

Gemini Code Assist Reviewer --- 免费且非常实用。能够发现其他工具遗漏的安全问题和可扩展性问题，并提出具体的修复建议。安装它绝对没错。

Claude Code Reviewer --- 基本没什么用，往往过于谨慎。它会给出很多"考虑添加......"之类的建议，而这些建议通常都是过度设计。除非被标记为"严重"，否则我一般会跳过它的所有建议。它很少能独立发现严重问题，但会验证其他审查员标记的问题。

这三个工具都会直接在 PR 上发布评论。

步骤 6：自动化测试

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

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

我上周添加了一条新规则：如果 PR 更改了任何 UI，则必须在 PR 描述中包含屏幕截图。否则 CI 测试将失败。这大大缩短了审核时间------我无需点击预览即可准确了解更改内容。

步骤 7：人工审核

现在我收到了 Telegram 通知："PR #341 已准备好进行审核。"

此时：

CI 测试通过
三位 AI 审核员已批准代码
屏幕截图显示了 UI 更改
所有边界情况均已记录在审核评论中

我的审核耗时 5-10 分钟。许多 PR 我甚至无需阅读代码即可合并------屏幕截图显示了我需要的所有信息。

步骤 8：合并

PR 合并。每日定时任务会清理孤立的工作树和任务注册表 JSON 文件。

Ralph Loop V2

这本质上是 Ralph Loop 的升级版。

Ralph Loop 从内存中提取上下文信息，生成输出，评估结果，并保存学习成果。但大多数实现方式在每个循环中都运行相同的提示。虽然提炼出的学习成果可以改进未来的检索，但提示本身却保持不变。

我们的系统则不同。当代理失败时，Zoe 不会简单地用相同的提示重新启动它。她会结合完整的业务上下文来分析失败原因，并找出解决方法：

代理上下文信息不足？"只关注这三个文件。"
代理方向错误？"停。客户想要的是 X，而不是 Y。这是他们在会议上说的。"
代理需要澄清？"这是客户的邮箱地址以及他们公司的业务。"

Zoe 会全程指导代理完成任务。她掌握着代理所不了解的上下文信息------客户历史记录、会议记录、我们之前的尝试以及失败的原因。她利用这些上下文信息，在每次重试时编写更完善的提示。

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

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

我打完客户电话后出去散步。回到 Telegram 后看到："7 个 PR 已准备好审核。3 个功能，4 个 bug 修复。"

代理成功后，会记录模式。"这种提示结构适用于计费功能。""Codex 需要预先提供类型定义。""始终包含测试文件路径。"

奖励信号包括：持续集成通过、所有三个代码审查均通过、人工合并。任何失败都会触发循环。随着时间的推移，Zoe 编写的提示越来越完善，因为她记住了哪些内容已发布。

选择合适的代码处理工具

并非所有代码处理工具都一样。快速参考：

Codex 是我的主力工具。后端逻辑、复杂的 bug、多文件重构，以及任何需要跨代码库推理的任务，它都能胜任。虽然速度较慢，但处理得非常彻底。我 90% 的任务都用它完成。

Claude Code 速度更快，前端工作也更出色。它的权限问题也更少，因此非常适合 Git 操作。（我以前更多地用它来管理日常工作，但现在 Codex 5.3 的速度更快、性能更优。）

Gemini 拥有另一种超能力------设计感。为了创建美观的 UI，我会先让 Gemini 生成 HTML/CSS 规范，然后交给 Claude Code 在我们的组件系统中实现。Gemini 负责设计，Claude 负责构建。

Zoe 会为每个任务选择合适的工具，并在它们之间路由输出。例如，计费系统 bug 交给 Codex 处理。按钮样式修复交给 Claude Code。新的仪表盘设计则由 Gemini 发起。

如何设置

将本文全部复制到 OpenClaw 中，并告诉它："为我的代码库实现此代理集群设置。"

它将读取架构、创建脚本、设置目录结构并配置 cron 监控。只需 10 分钟即可完成。

无需购买任何课程。

意想不到的瓶颈

我目前遇到的瓶颈是：内存。

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

我的 16GB 内存的 Mac Mini 最多只能运行 4-5 个代理，之后就会开始使用交换空间------而且我还要祈祷它们不会同时尝试构建。

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

接下来：一人百万美元公司

我们将在2026年看到大量由一人打造的百万美元公司涌现。对于那些懂得如何构建递归式自我改进智能体的人来说，杠杆效应是巨大的。

它的样子是这样的：一个作为你自身延伸的AI编排器（就像Zoe之于我一样），将工作委派给负责不同业务职能的专业智能体。工程、客户支持、运营、市场营销。每个智能体都专注于自己擅长的领域。你可以保持高度专注和完全掌控。

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

现在充斥着太多AI生成的垃圾产品。围绕智能体和"任务控制"的炒作铺天盖地，却没有真正创造出任何有用的东西。花哨的演示，却没有实际意义。

我的目标是反其道而行之：减少炒作，更多地记录构建实际业务的过程。真实的客户，真实的收入，真正上线的产品，以及真实的亏损。

我正在打造什么？Agentic PR------一家挑战传统企业公关公司的单人公司。我们帮助初创公司获得媒体曝光，而无需每月支付1万美元的顾问费。

如果你想看看我最终能做到什么程度，请继续关注。