OpenClaw + Claude Code/Codex:打造个人开发Agent Swarm

louwill·March 4, 2026·1 min read·0 views

大家好,我是鲁工。

前段在X上刷到一条推文,瞬间就吸引了我。一个叫Elvis的独立开发者说,他现在已经不直接用Claude Code和Codex了,改用OpenClaw作为编排层,让一个叫Zoe的AI编排器去管理一整支Claude Code和Codex的Agent Swarm。

这条推文的数据也很炸裂,490万浏览,1.1万点赞,1800转发。

文章配图

我们号写Vibe Coding四个多月,Claude Code一直是主力工具。我之前也写过一些多Agent协作、VSCode多Agent架构等相关问文章:

VSCode Multi-Agent指南:适合IDE选手的AI开发团队搭建

终极效率方案:使用Claude Code + Opus 4.6与Codex + GPT-5.3-Codex组合开发

用Antigravity组建最强开发团队:Opus 4.5 + GPT-5.1-Codex-Max + Gemini 3 Pro

但看到Elvis的这套玩法,我只能直呼内行了。一个人,靠一套编排系统,日均50次代码提交,最猛的一天提交了94次,还接了3个客户电话,编辑器一次都没打开。

这不就是一个人当一支开发团队用吗?

今天这篇文章就来拆解一下,他到底是怎么做到的。

OpenClaw大家都不陌生了,这只小龙虾春节前到现在,一直火爆。简单来说就是一个开源的AI Agent框架,GitHub上目前已经超过24万Star,并在前两天正式超越React,成为GitHub历史上star增长最快的开源项目。

文章配图

创始人Peter Steinberger是奥地利开发者,之前创办过PSPDFKit(一个PDF框架的B2B公司),2021年拿了Insight Partners一亿欧元的投资。今年2月Peter宣布加入OpenAI,OpenClaw项目移交给开源基金会运营。

OpenClaw的定位不是聊天机器人,是一个跑在你本地设备上的AI Agent运行时。它有四个核心组件:Gateway(网关,连接50多个消息平台)、Agent(推理引擎)、Skills(5400多个插件)、Memory(记忆系统)。

但Elvis用OpenClaw的方式比较特别。他直接把它当成编排层,专门用来管理Claude Code和Codex这些编码Agent,没拿它当通用助手在使用。

这个思路确实很不一般。

为什么需要一个编排层呢?

Elvis在推文里提了一个很关键的观点:上下文窗口是零和博弈。

你往里面塞代码,就没空间放业务上下文了。你往里塞客户历史和会议记录,就没空间放代码库了。单个AI再强,它也没办法同时装下这两种完全不同类型的信息。

所以他把系统拆成了两层。

上层是OpenClaw的编排器Zoe,她掌握所有业务上下文,包括客户数据、会议记录、历史决策、哪些方案试过了、哪些失败了。这些信息全部存在Elvis的Obsidian笔记库里,Zoe可以直接读取。

下层是Claude Code和Codex这些编码Agent,它们只看代码,只管写代码。每个Agent启动的时候,Zoe会根据业务上下文给它写一份精准的prompt,告诉它该做什么、背景是什么、客户要的是什么。

简单来说了就是:编排器负责理解需求,编码Agent负责干活。各做各擅长的事。

这个架构和Stripe前段时间公开的内部系统Minions异曲同工。Stripe的Minions也是并行编码Agent加集中式编排层的设计,每周能合并1000多个完全由AI编写的PR。Elvis说他是无意中搭了个类似的架构,只不过跑在自己的Mac mini上。

Elvis在推文里用了一个真实案例来讲他的完整工作流,我把核心环节简单串一下。

他接了一个客户电话,客户想在团队内部复用已有的配置。通话结束后,他跟Zoe聊了一下这个需求。因为所有会议记录都会自动同步到Obsidian,Zoe已经知道客户说了什么,不需要Elvis额外解释。他们一起确定了功能范围,最终方案是做一个模板系统。

然后Zoe自动做了三件事:给客户充值解锁服务(她有管理员API权限),从生产数据库拉取客户现有配置(只读权限,编码Agent永远不会有这个权限),然后生成一个Codex Agent,带着包含完整业务上下文的详细prompt。

每个Agent都有自己独立的worktree(隔离分支)和tmux会话。启动命令大概是这样的:

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

Agent跑起来之后,有一个定时任务每10分钟巡检一次。但它不会直接去问Agent(那样太烧token了),而是跑一个确定性的Shell脚本,检查tmux会话是否还活着、有没有创建PR、CI是否通过。

如果CI失败了,自动重启Agent,最多重试3次。只有需要人工干预的时候才发通知。

Agent完成任务后会自动创建PR。但光创建PR还不算完,Elvis定义了一套完成标准:PR创建、分支同步到main(无合并冲突)、CI全部通过、三个AI模型的代码审查全部通过、如果有UI改动还必须附截图。

三个AI模型做代码审查看起来就很稳。聊一下他对这三个模型的评价,挺有意思的。

Codex Reviewer,他评价最高,说它在边界情况和逻辑错误方面的审查非常彻底,误报率很低。

Gemini Code Assist Reviewer,免费的,他说非常实用,能发现其他模型遗漏的安全隐患和可扩展性问题,还能给出具体修复方案。

Claude Code Reviewer,他的原话是"基本没用",说它过度谨慎,满屏都是"考虑添加..."之类的建议,大部分属于过度设计。除非标记为关键问题,否则他直接跳过。

我看到这段的时候有点惊讶。作为Claude Code的重度用户,我确实也遇到过它在代码审查时过于保守的情况,但基本没用这个评价还是有点过了。不过这也从侧面说明,多模型交叉审查确实有价值,不同模型的偏见刚好互补。

三个审查全部通过后,Elvis才会收到Telegram通知。到这一步,他看的主要是截图,确认UI改动是否正确,很多PR他不看代码就直接合并了。他说自己的人工审查只需要5到10分钟。

Zoe不只是执行者。比工作流本身更有意思的是Zoe的主动性。

Elvis说Zoe不会坐等它分配任务,它会主动找活干。早上扫描Sentry的错误日志,发现4个新错误,自动生成4个Agent去修。开完会扫描会议记录,标记出客户提到的3个功能需求,然后自动启动3个Codex Agent。晚上扫描Git日志,启动Claude Code更新changelog和客户文档。

Elvis出门遛个弯回来,Telegram上就躺着一条消息:7个PR准备好了,3个新功能,4个bug修复。这不就是我一直期望打造的OPC一人公司开发团队效果吗。

而且当Agent失败的时候,Zoe的处理方式也比简单重试高级很多。它会结合业务上下文分析失败原因。Agent上下文爆了?它会缩小范围,让Agent只关注三个文件。Agent方向跑偏了?它也会纠正,告诉Agent客户要的是X不是Y,并附上会议中的原话。

随着时间推移,Zoe还会积累经验,记住哪些prompt结构对哪类任务效果好,下次写出更精准的prompt。

这个思路其实就是Ralph Loop的升级版。Ralph Loop的核心逻辑是拉取上下文、生成输出、评估结果、保存经验这样的循环,但大多数实现每次循环的prompt是固定的。Elvis的系统不一样,每次重试Zoe都会根据失败原因动态调整prompt,而且有完整的业务上下文加持。

费用方面,Elvis公开的数据是Claude每月大约100美元,Codex每月大约90美元。他也说了,起步可以从20美元开始试试水。

这个费用跟雇一个开发者比当然是便宜到离谱。但如果考虑到你还需要自己做产品决策、客户沟通、代码审查,它更像是一个效率放大器,帮你省掉了编码和测试这些重复性最高的环节。

硬件方面,Elvis提到他目前最大的瓶颈是RAM。每个Agent需要独立的worktree,每个worktree有自己的node_modules,每个Agent都要跑构建、类型检查和测试。5个Agent同时跑就意味着5个并行的TypeScript编译器、5个测试运行器、5套依赖项。

他的Mac mini 16GB内存最多同时跑4到5个Agent,再多就开始内存交换了。所以他买了一台128GB内存的Mac Studio M4 Max(3500美元),打算用它来扛更多的Agent并发。

老实说,Elvis这套系统给我的冲击还是挺大的。我之前一直把OpenClaw当做玩具在玩,在打造生产力方面,我都是依赖独立的Claude Code。偶尔用worktree做并行,但远没有到这种系统化编排的程度。看完他的推文之后,我觉得AI编程这件事的天花板又被拉高了一截。

我最近在按照他的思路,准备用OpenClaw打造完全自动化的一人开发团队。所以,近期我们号会出多篇OpenClaw的实践文章。

有几个现实问题还得给大家提个醒。

这套系统的前提是你得有一个清晰的产品、明确的客户需求、完善的CI/CD流水线。Elvis是在做一个真实的B2B SaaS产品,有客户、有收入、有生产环境。如果你还在写Demo或者学习阶段,这套架构的ROI可能不太划算。

另外,OpenClaw目前的安全问题也得注意。根据公开信息,已经有多个高危CVE被披露,还有341个恶意的社区插件被发现存在数据窃取行为。部署OpenClaw的时候,隔离和权限控制一定要做好。这也是我一直没有把OpenClaw部署在本地主力机上的原因。

还有一点,Elvis在推文里对Claude Code的代码审查评价偏低,但最近Claude Code刚推出了Agent Teams功能(官方内置的多Agent协作),Anthropic也在往编排这个方向发力。

不过抛开这些细节,Elvis这套编排层加执行层的架构思路确实值得关注。上下文窗口的零和博弈是真实存在的约束,用分层架构来解决这个问题,让不同的AI各司其职,这个方向我个人觉得是对的。

对这个话题感兴趣的朋友,可以直接去看Elvis的原推文,信息密度很高:

https://x.com/elvissun/status/2025920521871716562


本文首发于微信公众号「AI编程实验室」,阅读原文

Loading comments...

Related Articles

Agent 工程
结合一周使用记录,分析 DeepSeek Harness 的插件架构、请求次数、上下文缓存与任务成本。
September 20, 2026
1min
Agent 工程
解释 Loop Engineering 的组成、适用条件与实现思路,讨论开发者如何从逐次提示转向设计可验证的任务循环。
June 12, 2026
1min
Agent 工程
梳理 Claude Code 动态工作流的设计动机与六种编排模式,解释复杂任务如何通过独立上下文和验证流程完成。
June 3, 2026
1min
View All Articles