NOTE // 28

OpenClaw + Codex/ClaudeCode 代理蜂群：一人开发团队【完整设置】

OpenClaw + Codex/ClaudeCode Agent Swarm: The One-Person Dev Team [Full Setup]

I don't use Codex or Claude Code directly anymore.

我现在不再直接用 Codex 或 Claude Code 了。

I use OpenClaw as my orchestration layer. My orchestrator, Stan, spawns the agents, writes their prompts, picks the right model for each task, monitors progress, and pings me on Telegram when PRs are ready to merge.

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

Proof points from the last 4 weeks:

过去四周的证据：

- 94 commits in one day. My most productive day - I had 3 client calls and didn't open my editor once. The average is around 50 commits a day.
- 一天内提交 94 个。我最有效率的一天——我接了 3 个客户电话，一次都没打开编辑器。平均每天大约 50 次提交。

- 7 PRs in 30 minutes. Idea to production are blazing fast because coding and validations are mostly automated.
- 30 分钟内刷新 7 个人最好成绩。从创意到生产环境的快速推进，因为编码和验证大多自动化。

- Commits → MRR: I use this for a real B2B SaaS I'm building — bundling it with founder-led sales to deliver most feature requests same-day. Speed converts leads into paying customers.
- 提交→MRR：我用它来构建一个真正的 B2B SaaS——与创始人主导的销售捆绑销售，当天交付大部分功能请求。速度将潜在客户转化为付费客户。

before Jan: CC/codex only | after Jan: Openclaw orchestrates CC/codex

1 月之前：仅限 CC/法典 |1 月后：Openclaw 协调 CC/codex

My git history looks like I just hired a dev team. In reality it's just me going from managing claude code, to managing an openclaw agent that manages a fleet of other claude code and codex agents.

我的 git 历史看起来像是我刚雇了一个开发团队。实际上，我只是从管理 Claude 代码，转变为管理一个管理一群其他 Claude 代码和 Codex 代理的 Openclaw 代理。

Success rate: The system one-shots almost all small to medium tasks without any intervention.

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

Cost: ~$100/month for Claude and $90/month for Codex, but you can start with $20.

费用：克劳德每月~100 美元，Codex 每月 90 美元，但你可以从 20 美元开始。

Here's why this works better than using Codex or Claude Code directly:

以下是为什么这比直接使用 Codex 或 Claude 代码更有效的原因：

>Codex and Claude Code have very little context about your business.
>Codex 和 Claude Code 对你的业务几乎没有背景信息。

They see code. They don't see the full picture of your business.

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

OpenClaw changes the equation. It acts as the orchestration layer between you and all agents — it holds all my business context (customer data, meeting notes, past decisions, what worked, what failed) inside my Obsidian vault, and translates historical context into precise prompts for each coding agent. The agents stay focused on code. The orchestrator stays at the high strategy level.

OpenClaw 改变了这一局面。它作为你和所有代理之间的编排层——它将我所有的业务上下文（客户数据、会议记录、过去决策、哪些有效、哪些失败）存储在我的 Obsidian 保险库中，并将历史上下文转化为每个编码代理的精确提示。特工们专注于代码。策划者保持在高策略层面。

Here's how the system works at a high level:

系统大致如下：

Last week Stripe wrote about their background agent system called "Minions" — parallel coding agents backed by a centralized orchestration layer. I accidentally built the same thing but it runs locally on my Mac mini.

上周，Stripe 介绍了他们的后台代理系统“Minions”——由集中编排层支持的并行编码代理。我不小心组装了同样的东西，但它能在我的 Mac mini 上本地运行。

Before I tell you how to set this up, you should know WHY you need an agent orchestrator.

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

Why One AI Can't Do Both

为什么一个 AI 不能两者兼顾

Context windows are zero-sum. You have to choose what goes in.
上下文窗口是零和的。你得自己选择要放进去的东西。

Fill it with code → no room for business context. Fill it with customer history → no room for the codebase. This is why the two-tier system works: each AI is loaded with exactly what it needs.

用代码填满→没有商业背景的空间。填满客户历史→没有代码库空间。这就是为什么双层系统能奏效：每个 AI 都配备了它所需的精准内容。

OpenClaw and Codex have drastically different context:

OpenClaw 和 Codex 的背景有着截然不同的背景：

Specialization through context, not through different models.

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

The Full 8-step Workflow

完整的八步工作流程

Let me walk through a real example from last week.

让我来讲讲上周的一个真实例子。

Step 1: Customer Request → Scoping with Stan
步骤 1：客户请求→与 Stan 进行范围调查

I had a call with an agency customer. They wanted to reuse configurations they've already set up across the team.

我和一位代理客户通了电话。他们想重复使用团队中已经设置好的配置。

After the call, I talked through the request with Zoe. Because all my meeting notes sync automatically to my obsidian vault, zero explanation was needed on my end. We scoped out the feature together — and landed on a template system that lets them save and edit their existing configurations.

通话结束后，我和 Zoe 讨论了请求。因为我所有的会议记录都会自动同步到我的 Obsidian Vault，所以我这边根本不需要任何解释。我们一起考察了这个功能——最终确定了一个模板系统，允许用户保存和编辑现有配置。

Then Stan does three things:

然后佐伊做了三件事：

Tops up credits to unblock customer immediately — he has admin API access
他会立即为客户解锁信用点——她有管理员 API 访问权限
Pulls customer config from prod database — he has read-only prod DB access (my codex agents will never have this) to retrieve their existing setup, which gets included in the prompt
从生产数据库拉取客户配置 ——他有只读生产数据库访问权限（我的 Codex 代理永远没有这个权限），可以获取他们现有的配置，这些设置会包含在提示中
Spawns a Codex agent — with a detailed prompt containing all the context
生成一名 Codex 特工——并附有包含所有上下文的详细提示

Step 2: Spawn the Agent
第二步：召唤代理

Each agent gets its own worktree (isolated branch) and tmux session:

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

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"

The agent runs in a tmux session with full terminal logging via a script.

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

Here's how we launch agents:

以下是我们推出代理的方式：

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"

I used to use codex exec or claude -p, but switch to tmux recently:

我以前用过 Codex exec 或 claude -p，但最近换成了 tmux：

tmux is far better because mid-task redirection is powerful. Agent going the wrong direction? Don't kill it:
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

The task gets tracked in .clawdbot/active-tasks.json:

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

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
}

When complete, it updates with PR number and checks. (More on this in step 5)

完成后，会更新 PR 编号并进行检查。（关于这点，详见第 5 步）

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: Monitoring in a loop
步骤3：循环监控

A cron job runs every 10 minutes to babysit all agents. This pretty much functions as an improved Ralph Loop, more on it later.

每 10 分钟会有一个 cron 任务来照看所有特工。这基本上就是改进版的拉尔夫循环，后面会详细说。

But it doesn't poll the agents directly — that would be expensive. Instead, it runs a script that reads the JSON registry and checks:

但它不会直接对代理人进行调查——那会很昂贵。相反，它运行一个脚本读取 JSON 注册表并检查：

bash

砰

.clawdbot/check-agents.sh

The script is 100% deterministic and extremely token-efficient:

该脚本是100%确定性的，且极高的代币效率：

Checks if tmux sessions are alive
Checks for open PRs on tracked branches
Checks CI status via gh cli
Auto-respawns failed agents (max 3 attempts) if CI fails or critical review feedback
Only alerts if something needs human attention
检查 tmux 会话是否存活
在轨道支线上检查未开 PR
通过 gh cli 检查 CI 状态
如果 CI 失败或关键审查反馈，自动重生失败的代理（最多 3 次尝试）
仅在需要人工关注时发出警报

I'm not watching terminals. The system tells me when to look.

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

Step 4: Agent Creates PR
第四步：经纪人创建 PR

The agent commits, pushes, and opens a PR via gh pr create --fill. At this point I do NOT get notified — a PR alone isn't done.
代理通过“gh pr create --fill”提交、推送并打开 PR。此时我还没有收到通知——仅仅 PR 是不完成的。

Definition of done (very important your agent knows this):
“完成”的定义（非常重要的是你的经纪人知道这一点）：

PR created
Branch synced to main (no merge conflicts)
CI passing (lint, types, unit tests, E2E)
Codex review passed
Claude Code review passed
Gemini review passed
Screenshots included (if UI changes)
创建公共关系
分支与主节点同步（无合并冲突）
CI 通过（lint、类型、单元测试、端对端）
《军规》审查通过
Claude Code 审核通过
Gemini 审核通过
包含截图（如果界面发生变化）

Step 5: Automated Code Review
步骤5：自动代码审查

Every PR gets reviewed by three AI models. They catch different things:

每个公关都会由三个 AI 模型审核。它们捕捉到的不同内容：

Codex Reviewer — Exceptional at edge cases. Does the most thorough review. Catches logic errors, missing error handling, race conditions. False positive rate is very low.
军规书评审 —— 在极端情况下表现出色。评测最为详尽。能发现逻辑错误、缺失的错误处理、竞态条件。假阳性率非常低。
Gemini Code Assist Reviewer — Free and incredibly useful. Catches security issues, scalability problems other agents miss. And suggests specific fixes. No brainer to install.
Gemini 代码协助审核员 ——免费且极其实用。能发现安全问题、其他代理忽略的可扩展性问题。并提出了具体的修复建议。安装毫无疑问。
Claude Code Reviewer — Mostly useless - tends to be overly cautious. Lots of "consider adding..." suggestions that are usually overengineering. I skip everything unless it's marked critical. It rarely finds critical issues on its own but validates what the other reviewers flag.
Claude 代码审核员 ——大多没用——往往过于谨慎。很多“考虑加......”这些建议通常都算是过度设计了。除非标记为关键，否则我跳过所有内容。它很少单独发现关键问题，但会验证其他评审指出的观点。

All three post comments directly on the PR.

这三位球员都直接在 PR 上发表评论。

Step 6: Automated Testing
第六步：自动化测试

Our CI pipeline runs a heavy amount of automated tests:

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

Lint and TypeScript checks
Unit tests
E2E tests
Playwright tests against a preview environment (identical to prod)
lint 和 TypeScript 检查
单元测试
端对端测试
Playwright 在预览环境下进行测试（与生产环境相同）

I added a new rule last week: if the PR changes any UI, it must include a screenshot in the PR description. Otherwise CI fails. This dramatically shortens review time — I can see exactly what changed without clicking through the preview.

我上周新增了一条规则：如果 PR 更改了任何界面，必须在 PR 描述中包含截图。否则人工耳蜗就失败了。这大大缩短了审阅时间——我不用点预览也能准确看到哪里变了。

Step 7: Human Review
第7步：人类审核

Now I get the Telegram notification: "PR #341 ready for review."

现在我收到了 Telegram 通知：“PR #341 准备审核。”

By this point:

到这个时候：

CI passed
Three AI reviewers approved the code
Screenshots show the UI changes
All edge cases are documented in review comments
CI 通过
三位 AI 审核员批准了代码
截图展示了界面的变化
所有边缘情况均在评审评论中记录

My review takes 5-10 minutes. Many PRs I merge without reading the code — the screenshot shows me everything I need.

我的评测大约需要 5 到 10 分钟。很多 PR 我合并时不看代码——截图里显示了我需要的所有内容。

Step 8: Merge
第八步：合并

PR merges. A daily cron job cleans up orphaned worktrees and task registry json.

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

The Ralph Loop V2

拉尔夫环 V2

This is essentially the Ralph Loop, but better.

这本质上是拉尔夫环路，但更好。

The Ralph Loop pulls context from memory, generate output, evaluate results, save learnings. But most implementations run the same prompt each cycle. The distilled learnings improve future retrievals, but the prompt itself stays static.

拉尔夫循环从记忆中提取上下文，生成输出，评估结果，保存学习内容。但大多数实现每个周期运行的提示词都相同。这些精炼的学习内容提升了未来的检索，但提示本身保持静态。

Our system is different. When an agent fails, Zoe doesn't just respawn it with the same prompt. She looks at the failure with full business context and figures out how to unblock it:

我们的系统不同。当一个特工失败时，佐伊不会用同样的提示重新生成它。她从完整的商业背景来看待失败，并想出如何解封它：

Agent ran out of context? "Focus only on these three files."
特工脱离了上下文？“只专注于这三个文件。”
Agent went the wrong direction? "Stop. The customer wanted X, not Y. Here's what they said in the meeting."
特工走错方向了？“停下。客户想要的是 X，而不是 Y。会议上他们说了这些。”
Agent need clarification? "Here's customer's email and what their company does."
代理人需要澄清吗？“这是客户的邮箱和他们公司的业务。”

Stan babysits agents through to completion. She has context the agents don't — customer history, meeting notes, what we tried before, why it failed. She uses that context to write better prompts on each retry.

Stan一直照看特工直到完成。她掌握了客服没有的背景信息——客户历史、会议记录、我们之前尝试过的事、失败的原因。她利用这些语境，在每次重试时写出更好的提示。

But she also doesn't wait for me to assign tasks. She finds work proactively:

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

Morning: Scans Sentry → finds 4 new errors → spawns 4 agents to investigate and fix
早晨： 扫描哨兵→发现 4 个新错误→生成 4 名特工进行调查和修复
After meetings: Scans meeting notes → flags 3 feature requests customers mentioned → spawns 3 Codex agents
会议结束后： 扫描会议记录→标记 3 个客户提到的功能请求→生成 3 个 Codex 特工
Evening: Scans git log → spawns Claude Code to update changelog and customer docs
晚上： 扫描 git 日志→生成 Claude 代码更新变更日志和客户文档

I take a walk after a customer call. Come back to Telegram: "7 PRs ready for review. 3 features, 4 bug fixes."

客户接完电话后我去散步。回到 Telegram：“7 个 PR 准备审核。3 个功能，4 个漏洞修复。”

When agents succeed, the pattern gets logged. "This prompt structure works for billing features." "Codex needs the type definitions upfront." "Always include the test file paths."

当代理成功时，模式会被记录下来。“这种提示结构适用于计费功能。”“Codex 需要提前提供类型的定义。”“一定要包含测试文件路径。”

The reward signals are: CI passing, all three code reviews passing, human merge. Any failure triggers the loop. Over time, Zoe writes better prompts because she remembers what shipped.

奖励信号是：CI 通过，三个代码审查均通过，人类合并。任何故障都会触发循环。随着时间推移，Stan 写出的提示写得更好，因为她记得什么已经发货了。

Choosing the Right Agent

选择合适的代理人

Not all coding agents are equal. Quick reference:

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

Codex is my workhorse. Backend logic, complex bugs, multi-file refactors, anything that requires reasoning across the codebase. It's slower but thorough. I use it for 90% of tasks.
Codex 是我的主力。后端逻辑、复杂的漏洞、多文件重构，任何需要跨代码库推理的事情。虽然节奏较慢，但非常细致。我用它完成 90%的任务。

Claude Code is faster and better at frontend work. It also has fewer permission issues, so it's great for git operations. (I used to use this more to drive day to day, but Codex 5.3 is simply better and faster now)
Claude Code 在前端工作上更快更好。它的权限问题也更少，非常适合 git 作。（我以前更多用它来日常驾驶，但现在 Codex 5.3 更好更快）

Gemini has a different superpower — design sensibility. For beautiful UIs, I'll have Gemini generate an HTML/CSS spec first, then hand that to Claude Code to implement in our component system. Gemini designs, Claude builds.
双子座有一种不同的超能力——设计感知。对于漂亮的用户界面，我会先让 Gemini 生成 HTML/CSS 规范，然后交给 Claude Code 在我们的组件系统中实现。双子座设计，克劳德建造。

Zoe picks the right agent for each task and routes outputs between them. A billing system bug goes to Codex. A button style fix goes to Claude Code. A new dashboard design starts with Gemini.

Zoe 为每个任务选择合适的代理，并在它们之间路由输出。计费系统的一个漏洞归到了 Codex。按钮样式的修复归功于 Claude Code。新的仪表盘设计始于 Gemini。

How to Set This Up

如何设置

Copy this entire article into OpenClaw and tell it: "Implement this agent swarm setup for my codebase."

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

It'll read the architecture, create the scripts, set up the directory structure, and configure cron monitoring. Done in 10 minutes.

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

No course to sell you.

没有课程可以推销给你。

The Bottleneck Nobody Expects

没人预料到的瓶颈

Here's the ceiling I'm hitting right now: RAM.

我现在遇到的最大瓶颈是：内存。

Each agent needs its own worktree. Each worktree needs its own node_modules. Each agent runs builds, type checks, tests. Five agents running simultaneously means five parallel TypeScript compilers, five test runners, five sets of dependencies loaded into memory.

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

My Mac Mini with 16GB tops out at 4-5 agents before it starts swapping — and I need to be lucky they don't try to build at the same time.

我的 Mac Mini 16GB 内存最多 4-5 个代理，之后才开始切换——我得庆幸他们不会同时构建。

So I bought a Mac Studio M4 max with 128GB RAM ($3,500) to power this system. It arrives end of March and I'll share if it's worth it.

所以我买了一台带 128GB 内存的 Mac Studio M4 Max（3500 美元）来为这台系统供电。它将在三月底到货，我会告诉你值不值得买。

Up Next: The One-Person Million-Dollar Company

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

We're going to see a ton of one-person million-dollar companies starting in 2026. The leverage is massive for those who understand how to build recursively self-improving agents.

从2026年开始，我们将看到大量一人的百万美元公司。对于那些懂得如何构建递归自我改进代理的人来说，这种优势极为巨大。

This is what it looks like: an AI orchestrator as an extension of yourself (like what Zoe is to me), delegating work to specialized agents that handle different business functions. Engineering. Customer support. Ops. Marketing. Each agent focused on what it's good at. You maintain laser focus and full control.

这就是它的样子：一个 AI 编排器，作为你的延伸（就像我对 Zoe 的理解），将工作委派给处理不同业务功能的专业代理。工程学。客服。作。市场营销。每个特工都专注于自己的强项。你保持高度专注和完全的控制。

The next generation of entrepreneurs won't hire a team of 10 to do what one person with the right system can do. They'll build like this — staying small, moving fast, shipping daily.

下一代创业者不会雇佣10人团队去完成一个拥有正确系统的人能做到的事。他们会这样建造——保持小规模，快速移动，每天发货。

There's so much AI-generated slop right now. So much hype around agents and "mission controls" without building anything actually useful. Fancy demos with no real-world benefits.

现在 AI 生成的烂东西太多了。关于特工和“任务控制”的炒作太多，却没有真正建成什么有用的东西。花哨的演示，但没有实际效果。