OpenClaw AI 编码代理编排系统

发表于 2026-02-25 分类于 AI

AI 实践

背景

最近看到一位开发者在 X 上分享了他的 AI 编码工作流,看得我眼前一亮。他不再直接使用 Codex 或 Claude Code,而是用 OpenClaw 作为编排层,让一个叫 Zoe 的编排器来管理一群 AI 代理。

说实话,刚开始看的时候我还在想,直接用 Claude Code 不就够了吗?为什么还要搞个编排层?看完整个架构和工作流程后,我才明白这确实是个质的飞跃。

先看成果

这哥们儿过去4周的数据:

一天 94 次提交。他最高产的那天,开了 3 个客户会议,一次编辑器都没打开。平均每天 50 次提交左右
30 分钟 7 个 PR。从想法到生产环境的速度飞快,因为编码和验证基本都自动化了
提交次数直接转化为 MRR(Monthly Recurring Revenue):他用这个系统来做真实的 B2B SaaS 产品——和创始人主导的销售结合,大部分功能请求都能当天交付。速度就是转化率

Git 历史看起来像他刚招了一个开发团队,实际上就他一个人,从管理 Claude Code,变成管理一个 OpenClaw 代理,而 OpenClaw 又管理着一群其他的 Claude Code 和 Codex 代理。

为什么需要编排层?

上下文窗口的零和博弈

上下文窗口是零和游戏。你必须在里面选择放什么:

填满代码 → 没空间放业务上下文
填满客户历史 → 没空间放代码库

这就是为什么两层系统有效:每个 AI 只加载它需要的。

OpenClaw 和 Codex 有完全不同的上下文:

OpenClaw:

客户数据和会议记录(通过 Obsidian vault)
业务目标和策略
过去的决策和成败经验
产品路线图
市场信息

Codex:

当前代码库
具体文件和类型定义
单元测试
构建/测试流程

核心思想:通过上下文的专业化,而不是通过不同的模型来实现专业化

Codex 和 Claude Code 的局限

Codex 和 Claude Code 对你的业务几乎一无所知。它们看到的是代码,不是你业务的完整图景。

OpenClaw 改变了这个公式。它作为你与所有代理之间的编排层,在 Obsidian vault 中保存所有业务上下文(客户数据、会议记录、过去的决策、什么有效、什么失败),然后将历史上下文转化为每个编码代理的精确提示词。

代理专注于代码。编排器保持在高层策略层面。

系统工作流程

第1步:客户需求 → 与 Zoe 一起定范围

跟客户通完电话,他和 Zoe 讨论这个需求。因为所有会议记录都自动同步到他的 Obsidian vault,他这边完全不需要解释什么。

他们一起确定功能范围——最终确定了一个模板系统,让客户可以保存和编辑现有配置。

然后 Zoe 做三件事:

充值解除客户阻塞——她有管理员 API 访问权限
从生产数据库拉取客户配置——她有只读生产数据库访问权限(Codex 代理永远不会这个),获取他们现有设置,包含在提示词中
生成 Codex 代理——带有包含所有上下文的详细提示词

第2步:生成代理

每个代理都有自己的 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 "/Users/elvis/Documents/GitHub/medialyst-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 中跟踪:

{
  "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."
}

第3步:循环监控

一个 cron 任务每 10 分钟运行一次,照顾所有代理。这基本上就是一个改进版的 Ralph Loop。

但它不直接轮询代理——那样太贵了。而是运行一个脚本读取 JSON 注册表并检查:

tmux 会话是否存活
跟踪分支是否有打开的 PR
通过 gh cli 检查 CI 状态
如果 CI 失败或有关键审查反馈,自动重生失败的代理(最多 3 次)
只有需要人工关注时才提醒

他不是盯着终端看。系统告诉他什么时候该看。

第4步:代理创建 PR

代理提交、推送,并通过 gh pr create --fill 打开 PR。这时他不会收到通知——单有 PR 不算完成。

完成的标准(非常重要,你的代理必须知道这个):

PR 已创建
分支已同步到 main(无合并冲突)
CI 通过(lint,类型,单元测试,E2E)
Codex 审查通过
Claude Code 审查通过
Gemini 审查通过
包含截图(如果有 UI 变化)

第5步:自动化代码审查

每个 PR 都由三个 AI 模型审查。它们捕捉不同的东西:

Codex 审查者——边缘情况方面卓越。审查最彻底。捕捉逻辑错误、缺少错误处理、竞态条件。误报率很低
Gemini Code Assist 审查者——免费且极其有用。捕捉安全性问题、其他代理忽略的可扩展性问题。并建议具体修复方案。安装它是必然的
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 任务清理孤立的 worktree 和任务注册表 JSON。

这基本上就是 Ralph Loop,但更好。

Ralph Loop 从记忆中拉取上下文,生成输出,评估结果,保存学习。但大多数实现每个周期运行相同的提示词。蒸馏的学习改进未来的检索,但提示词本身保持静态。

他们的系统不同。当代理失败时,Zoe 不会用相同的提示词重新生成它。她用完整的业务上下文查看失败,并弄清楚如何解除阻塞:

代理上下文用完了?”只关注这三个文件。”
代理走错了方向?”停。客户想要 X,不是 Y。这是他们在会议中说的。”
代理需要澄清?”这是客户的邮件和他们公司的业务。”

Zoe 照顾代理直到完成。她有代理没有的上下文——客户历史、会议记录、他们之前尝试过什么、为什么失败。她使用那个上下文在每次重试时写更好的提示词。

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

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

跟客户通完电话去散个步。回到 Telegram:”7 个 PR 准备好审查。3 个功能,4 个 bug 修复。”

当代理成功时,模式被记录。”这个提示词结构对计费功能有效。””Codex 需要预先知道类型定义。””总是包含测试文件路径。”

奖励信号是:CI 通过,所有三个代码审查通过,人工合并。任何失败触发循环。随着时间推移,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 开始。

成本

每月大约 $100 给 Claude,$90 给 Codex,但你可以从 $20 开始。

当前遇到的瓶颈

他现在遇到的瓶颈是:RAM。

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

他的 16GB Mac Mini 在开始交换前最多跑 4-5 个代理——而且还得够幸运它们不要同时尝试构建。

所以他买了一个 128GB RAM 的 Mac Studio M4 Max($3,500) 来驱动这个系统。3 月底到货,他会分享是否值得。

启示

我们会在 2026 年看到大量一人百万美元公司开始。对那些理解如何构建递归自我改进代理的人来说,杠杆是巨大的。

它看起来是这样的:一个 AI 编排器作为你自己的延伸(就像 Zoe 对他),将工作委托给处理不同业务职能的专业代理。工程。客户支持。运营。市场。每个代理专注于它擅长的。你保持专注和完全控制。

下一代创业者不会招一个 10 人的团队来做拥有合适系统的人能做的事。他们会像这样构建——保持小规模,快速移动,每天交付。

个人思考

看完这个案例,我有几个感触:

这不是要取代人类。人类仍然需要设定目标、做战略决策、做最终审查。AI 代理只是放大了人类的产出能力。
编排层是关键。直接用 Claude Code 当然能提高效率,但要达到”一天94次提交”这种量级,需要一个更高层的系统来管理、协调、监控多个代理。
业务上下文不能丢。为什么需要编排层?因为只有编排器有完整的业务上下文。代理们只看到代码,看不到背后的业务逻辑、客户需求、历史决策。
自动化程度决定上限。从手动写提示词,到自动生成提示词;从手动审查,到三层 AI 自动审查+最终人工确认;每个环节的自动化都能大幅提升效率。
成本相对可控。一个月不到 $200 的成本,却能实现这么高的产出,ROI 还是挺高的。

当然,这个系统也有明显的局限——RAM。这也提示我们,基础设施要跟上。

但更重要的是,这种”人+AI编排器+AI代理集群”的模式,可能是未来的主流工作方式。

参考

原文: https://x.com/elvissun/status/2025920521871716562、https://x.com/huangyun_122/status/2026370426881060945