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 会话:
1
2
3
4
5
6
|
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 会话中运行,通过脚本进行完整的终端日志记录。
如果代理走错了方向?不需要杀掉它:
1
2
3
4
5
|
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 中跟踪:
1
2
3
4
5
6
7
8
9
10
11
12
| {
"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 号和检查:
1
2
3
4
5
6
7
8
9
10
11
12
| {
"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
