OpenClaw + Codex/ClaudeCode智能体集群：一人开发团队

OpenClaw + Codex/ClaudeCode智能体集群：一人开发团队 OpenClaw + Codex/ClaudeCode智能体集群：一人开发团队 Modified February 26 上周，Stripe介绍了他们名为“Minions”的后台Agent系统——由集中式编排层支持的并行编码Agent。我无意间构建了同样的东西，不过它是在我的Mac mini上本地运行的。 在我告诉你如何设置这个之前，你应该知道为什么你需要一个Agent编排器。 为什么一个AI无法兼顾两者 上下文窗口是零和的。你必须选择放入什么内容。 用代码填充它→没有业务背景的空间。用客户历史填充它→没有代码库的空间。这就是两层系统行之有效的原因：每个AI都被加载了它确切需要的内容。 OpenClaw和Codex的背景截然不同： 通过上下文实现专业化，而非通过不同的模型。 完整的八步工作流程 让我来介绍一个上周的真实例子。 步骤 1：客户请求 → 与Zoe进行范围界定 我与一家代理客户通了电话。他们希望复用团队中已经设置好的配置。 通话结束后，我和Zoe详细讨论了这个需求。由于我所有的会议记录都会自动同步到我的笔记库中，所以我这边无需做任何解释。我们一起确定了该功能的范围——最终确定采用一个模板系统，让他们能够保存和编辑现有的配置。 然后Zoe做了三件事： 1. 立即充值信用额度以解封客户 —— 她拥有管理 API 访问权限 2. 从生产数据库中提取客户配置 —— 她拥有只读的生产DB访问权限（我的CodexAgent永远不会有此权限），以检索他们现有的设置，这些设置会被包含在提示中 3. 生成一个CodexAgent——附带包含所有上下文的详细提示 步骤2：生成Agent 每个Agent都有自己的工作树（隔离分支）和 tmux 会话： bash Code block Bash Copy 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在tmux会话中运行，并通过脚本进行完整的终端日志记录。 以下是我们启动Agent的方式： bash Code block Bash Copy 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 Code block Bash Copy 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中被跟踪： json Code block JSON Copy { "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 中会详细介绍） json Code block JSON Copy { "status": "done", "pr": 341, "completedAt": 1740275400000, "checks": { "prCreated": true, "ciPassed": true, "claudeReviewPassed": true, "geminiReviewPassed": true }, "note": "All checks passed. Ready to merge." } 步骤3：循环监测 一个定时任务每10分钟运行一次，以监控所有Agent。这在很大程度上起到了改进版拉尔夫循环的作用，稍后会详细介绍。 但它并不直接轮询Agent——那样成本太高。相反，它运行一个脚本，读取 JSON 注册表并进行检查： bash Code block Bash Copy .clawdbot/check agents.sh 该脚本具有100%的确定性，且在token使用上极为高效： • 检查tmux会话是否处于活动状态 • 检查跟踪分支上的开放拉取请求 • 通过 gh 命令行工具检查 CI 状态 • 如果CI失败或收到关键审查反馈，自动重新启动失败的Agent（最多3次尝试） • 仅在需要人工关注时发出警报 我不盯着终端看。系统会告诉我何时查看。 步骤4：Agent创建PR Agent通过 进行提交、推送并打开一个 PR。此时我不会收到通知 —— 仅创建一个 PR 还不算完成。 完成定义（非常重要，你的Agent需要了解这一点）： • PR已创建 • 分支已同步到主分支（无合并冲突） • CI通过（代码检查、类型检查、单元测试、E2E） • Codex审查通过 • Claude代码审查已通过 • Gemini审核通过 • 包含屏幕截图（如果有 UI 更改） 步骤 5：自动代码审查 每个PR都会由三个AI模型进行审查。它们能发现不同的问题： • Codex审查员——在处理边缘情况方面表现出色。审查最为全面。能捕捉逻辑错误、遗漏的错误处理、竞态条件。误报率极低。 • Gemini代码辅助审查器——免费且极其有用。能捕捉到其他Agent遗漏的安全问题、可扩展性问题，并提出具体的修复建议。安装它不费吹灰之力。 • Claude代码审查器 — 大多时候没什么用，往往过于谨慎。有很多“考虑添加……”的建议，通常属于过度设计。除非标记为关键问题，否则我会忽略所有建议。它很少能自行发现关键问题，但会验证其他审查者标记的问题。 所有三条评论都直接针对PR发表。 步骤6：自动化测试 我们的CI管道运行大量自动化测试： • Lint和TypeScript检查 • 单元测试 • E2E测试 • 针对预览环境（与生产环境相同）的Playwright测试 我上周新增了一条规则：如果 PR 对任何 UI 进行了更改，那么它必须在 PR 描述中包含截图。否则 CI 会失败。这极大地缩短了审查时间——我无需点击预览就能确切看到发生了哪些更改。 步骤7：人工审核 现在我收到了 Telegram 通知：“PR 341 已准备好进行审核。” 到目前为止： • CI通过 • 三位AI评审员批准了代码 • 截图展示了UI的变化 • 所有边缘情况均记录在评审意见中 我的审核需要5到10分钟。很多PR我都不看代码就合并了——截图展示了我需要的所有信息。 步骤8：合并 PR合并。每日定时任务会清理孤立的工作树和任务注册表JSON。 拉尔夫循环V2 这本质上就是拉尔夫循环，但更胜一筹。 拉尔夫循环从内存中提取上下文、生成输出、评估结果并保存学习成果。但大多数实现方式在每个周期都运行相同的提示。提炼的学习成果能改进未来的检索，但提示本身保持不变。 我们的系统与众不同。当一个Agent失败时，Zoe不会只是用相同的提示重新生成它。她会结合完整的业务背景审视失败情况，并找出如何解决问题的方法： • Agent超出上下文范围了？“只专注于这三个文件。” • 座席方向错了？“停。客户要的是X，不是Y。这是他们在会议上说的。” • 座席需要进一步说明吗？“这是客户的电子邮件以及他们公司的业务范围。” Zoe全程指导座席直至任务完成。她掌握着座席所没有的背景信息——客户历史、会议记录、我们之前尝试过的方法以及失败原因。她利用这些背景信息在每次重试时编写更好的提示。 但她也不会等我分配任务。她会主动找工作： • 上午：扫描哨兵 → 发现4个新错误 → 生成4个Agent进行调查和修复 上周，Stripe介绍了他们名为“Minions”的后台Agent系统——由集中式编排层支持的并行编码Agent。我无意间构建了同样的东西，不过它是在我的Mac mini上本地运行的。 在我告诉你如何设置这个之前，你应该知道为什么你需要一个Agent编排器。 为什么一个AI无法兼顾两者 上下文窗口是零和的。你必须选择放入什么内容。 用代码填充它→没有业务背景的空间。用客户历史填充它→没有代码库的空间。这就是两层系统行之有效的原因：每个AI都被加载了它确切需要的内容。 OpenClaw和Codex的背景截然不同： 通过上下文实现专业化，而非通过不同的模型。 完整的八步工作流程 让我来介绍一个上周的真实例子。 步骤 1：客户请求 → 与Zoe进行范围界定 我与一家代理客户通了电话。他们希望复用团队中已经设置好的配置。 通话结束后，我和Zoe详细讨论了这个需求。由于我所有的会议记录都会自动同步到我的笔记库中，所以我这边无需做任何解释。我们一起确定了该功能的范围——最终确定采用一个模板系统，让他们能够保存和编辑现有的配置。 然后Zoe做了三件事： 1. 立即充值信用额度以解封客户 —— 她拥有管理 API 访问权限 2. 从生产数据库中提取客户配置 —— 她拥有只读的生产DB访问权限（我的CodexAgent永远不会有此权限），以检索他们现有的设置，这些设置会被包含在提示中 3. 生成一个CodexAgent——附带包含所有上下文的详细提示 步骤2：生成Agent 每个Agent都有自己的工作树（隔离分支）和 tmux 会话： bash Agent在tmux会话中运行，并通过脚本进行完整的终端日志记录。 以下是我们启动Agent的方式： bash 我过去常使用codex exec或claude p，但最近改用tmux了： tmux要好得多，因为任务中重定向功能强大。智能体走错方向了？别杀掉它： bash 该任务会在.clawdbot/active tasks.json中被跟踪： json 完成后，它会更新 PR 编号和检查信息。（步骤 5 中会详细介绍） json 步骤3：循环监测 一个定时任务每10分钟运行一次，以监控所有Agent。这在很大程度上起到了改进版拉尔夫循环的作用，稍后会详细介绍。 但它并不直接轮询Agent——那样成本太高。相反，它运行一个脚本，读取 JSON 注册表并进行检查： bash 该脚本具有100%的确定性，且在token使用上极为高效： • 检查tmux会话是否处于活动状态 • 检查跟踪分支上的开放拉取请求 • 通过 gh 命令行工具检查 CI 状态 • 如果CI失败或收到关键审查反馈，自动重新启动失败的Agent（最多3次尝试） • 仅在需要人工关注时发出警报 我不盯着终端看。系统会告诉我何时查看。 步骤4：Agent创建PR Agent通过 进行提交、推送并打开一个 PR。此时我不会收到通知 —— 仅创建一个 PR 还不算完成。 完成定义（非常重要，你的Agent需要了解这一点）： • PR已创建 • 分支已同步到主分支（无合并冲突） • CI通过（代码检查、类型检查、单元测试、E2E） • Codex审查通过 • Claude代码审查已通过 • Gemini审核通过 • 包含屏幕截图（如果有 UI 更改） 步骤 5：自动代码审查 每个PR都会由三个AI模型进行审查。它们能发现不同的问题： • Codex审查员——在处理边缘情况方面表现出色。审查最为全面。能捕捉逻辑错误、遗漏的错误处理、竞态条件。误报率极低。 • Gemini代码辅助审查器——免费且极其有用。能捕捉到其他Agent遗漏的安全问题、可扩展性问题，并提出具体的修复建议。安装它不费吹灰之力。 • Claude代码审查器 — 大多时候没什么用，往往过于谨慎。有很多“考虑添加……”的建议，通常属于过度设计。除非标记为关键问题，否则我会忽略所有建议。它很少能自行发现关键问题，但会验证其他审查者标记的问题。 所有三条评论都直接针对PR发表。 步骤6：自动化测试 我们的CI管道运行大量自动化测试： • Lint和TypeScript检查 • 单元测试 • E2E测试 • 针对预览环境（与生产环境相同）的Playwright测试 我上周新增了一条规则：如果 PR 对任何 UI 进行了更改，那么它必须在 PR 描述中包含截图。否则 CI 会失败。这极大地缩短了审查时间——我无需点击预览就能确切看到发生了哪些更改。 步骤7：人工审核 现在我收到了 Telegram 通知：“PR 341 已准备好进行审核。” 到目前为止： • CI通过 • 三位AI评审员批准了代码 • 截图展示了UI的变化 • 所有边缘情况均记录在评审意见中 我的审核需要5到10分钟。很多PR我都不看代码就合并了——截图展示了我需要的所有信息。 步骤8：合并 PR合并。每日定时任务会清理孤立的工作树和任务注册表JSON。 拉尔夫循环V2 这本质上就是拉尔夫循环，但更胜一筹。 拉尔夫循环从内存中提取上下文、生成输出、评估结果并保存学习成果。但大多数实现方式在每个周期都运行相同的提示。提炼的学习成果能改进未来的检索，但提示本身保持不变。 我们的系统与众不同。当一个Agent失败时，Zoe不会只是用相同的提示重新生成它。她会结合完整的业务背景审视失败情况，并找出如何解决问题的方法： • Agent超出上下文范围了？“只专注于这三个文件。” • 座席方向错了？“停。客户要的是X，不是Y。这是他们在会议上说的。” • 座席需要进一步说明吗？“这是客户的电子邮件以及他们公司的业务范围。” Zoe全程指导座席直至任务完成。她掌握着座席所没有的背景信息——客户历史、会议记录、我们之前尝试过的方法以及失败原因。她利用这些背景信息在每次重试时编写更好的提示。 但她也不会等我分配任务。她会主动找工作： • 上午：扫描哨兵 → 发现4个新错误 → 生成4个Agent进行调查和修复 • 会议结束后：扫描会议记录 → 标记客户提及的3个功能请求 → 生成3个CodexAgent • 晚上：扫描git日志 → 调用Claude Code更新变更日志和客户文档 客户电话结束后我出去散了会儿步。回到Telegram看到：“7个PR已准备好进行审查。3个功能，4个漏洞修复。” 当Agent成功时，模式会被记录下来。“这种提示结构适用于计费功能。”“Codex需要提前提供类型定义。”“始终包含测试文件路径。” 奖励信号包括：CI通过、三项代码审查均通过、人工合并。任何失败都会触发循环。随着时间的推移，Zoe会写出更好的提示，因为她记得哪些内容已发布。 选择合适的Agent 并非所有编码Agent都是相同的。快速参考： Codex是我的主力工具。后端逻辑、复杂的错误、多文件重构，任何需要在整个代码库中进行推理的任务都靠它。它速度较慢，但很全面。我90%的任务都用它来完成。 Claude Code在前端工作方面更快、更好。它的权限问题也更少，因此非常适合进行git操作。（我过去更多地使用它来处理日常工作，但现在Codex 5.3就是更快、更好） Gemini有一项独特的超能力——设计感。对于漂亮的用户界面，我会先让Gemini生成一个HTML/CSS规范，然后将其交给Claude Code在我们的组件系统中实现。Gemini负责设计，Claude负责构建。 Zoe会为每个任务挑选合适的智能体，并在它们之间路由输出。计费系统的漏洞会交给Codex处理。按钮样式的修复会交给Claude Code处理。新的仪表盘设计会从Gemini开始。 如何设置这个 将这整篇文章复制到OpenClaw中，并告诉它：“为我的代码库实现这个Agent群设置”。 它将读取架构、创建脚本、设置目录结构并配置定时任务监控。10分钟内完成。 没有课程向你推销。 无人预料到的瓶颈 这就是我目前遇到的瓶颈：RAM。 每个Agent都需要自己的工作树。每个工作树都需要自己的 node modules。每个Agent都会运行构建、类型检查和测试。五个Agent同时运行意味着有五个并行的 TypeScript 编译器、五个测试运行器，以及五组依赖项被加载到内存中。 我的16GB内存的Mac Mini在启动4 5个Agent后就会达到性能极限，开始进行内存交换——而且我还得祈祷它们不会同时尝试构建。 所以我买了一台配备128GB RAM的Mac Studio M4 Max（售价3500美元）来驱动这个系统。它将于3月底到货，我会分享它是否物有所值。 下一个：一人百万美元公司 我们将看到大量单人百万美元公司在2026年涌现。对于那些懂得如何构建递归式自我改进智能体的人来说，其影响力将是巨大的。 这就是它的样子：一个AI编排器作为你自身的延伸（就像Zoe对我而言那样），将工作委派给处理不同业务职能的专业智能体。工程、客户支持、运营、营销。每个智能体专注于自己擅长的领域。你保持高度专注并拥有完全控制权。 下一代创业者不会雇佣一个10人的团队去做一个拥有合适系统的人就能完成的事。他们会这样发展——保持小规模、行动迅速、每日交付。 现在有太多AI生成的垃圾内容了。围绕智能体和“任务控制中心”有太多炒作，却没有构建出任何真正有用的东西。华而不实的演示，没有任何实际效益。 我正试图反其道而行之：少些炒作，多些关于建立实际业务的记录。真实的客户、真实的收入、真正投入生产的提交，当然也有真实的亏损。 我在打造什么？自主型PR——一家单挑企业PR巨头的一人公司。我们的Agent帮助初创企业获得媒体报道，而无需每月支付1万美元的预付费。 如果你想知道我会把这件事做到什么程度，就继续关注吧。 原文链接：https://x.com/elvissun/status/2025920521871716562?s=46 原文链接：https://x.com/elvissun/status/2025920521871716562?s=46 我不再直接使用Codex或Claude Code了。 我使用OpenClaw作为我的编排层。我的编排器Zoe负责生成Agent、编写提示、为每个任务选择合适的模型、监控进度，并在拉取请求（PR）准备好合并时在Telegram上通知我。 过去4周的证明要点： 一天内提交了94次代码。这是我效率最高的一天——我打了3个客户电话，一次都没打开过编辑器。平均每天提交约50次代码。 30分钟内完成7个PR。从创意到产品的速度极快，因为编码和验证大多已实现自动化。 承诺 → MRR：我在自己正在打造的一个真正的B2B SaaS项目中使用这一方法——将其与创始人主导的销售相结合，以便在同一天内满足大多数功能需求。速度能将潜在客户转化为付费客户。 before Jan: CC/codex only | after Jan: Openclaw orchestrates CC/codex 我的git历史记录看起来就像我刚聘请了一个开发团队。实际上，这只是我从管理Claude代码，转变为管理一个OpenClawAgent，而这个Agent又管理着一群其他Claude代码和CodexAgent。 成功率：该系统几乎能一次性完成所有中小任务，无需任何干预。 费用：Claude约100美元/月，Codex为90美元/月，但你可以从20美元起开始使用。 以下是这种方法比直接使用Codex或Claude Code效果更好的原因： Codex和Claude Code对您的业务了解甚少。 他们只看到代码，却看不到你业务的全貌。 OpenClaw改变了局面。它充当你与所有智能体之间的编排层——它将我所有的业务上下文（客户数据、会议记录、过往决策、成功经验、失败教训）都存放在我的Obsidian库中，并将历史上下文转化为针对每个编码智能体的精准提示。智能体专注于代码，而编排器则着眼于高层战略层面。 以下是该系统的总体工作原理：