夜雨聆风你见过一个人一天提交 94 次代码吗？
不是加班到凌晨，不是疯狂复制粘贴，而是在有 3 个客户电话的情况下，连编辑器都没打开。
这不是科幻，这是一位开发者 Elvis 用 AI Agent 编排系统实现的真实生产力。他的 Git 历史看起来像刚雇了一个开发团队，但实际上只有他一个人——和一群被精心编排的 AI 助手。
平均每天 50 次提交，30 分钟完成 7 个 PR，从想法到上线的速度快到惊人。
这篇文章不是理论，是他完整公开的实战架构。
从“使用工具”到“管理系统”
大多数人用 AI 编程工具的方式是：打开 Claude Code 或 Codex，开始对话，写代码。
Elvis 不再这样做。
他用 OpenClaw 作为编排层，创建了一个叫 Zoe 的 AI 编排者。Zoe 负责生成其他 AI 助手、编写它们的提示词、为每个任务选择合适的模型、监控进度，最后在 PR 准备好时通过 Telegram 通知他。
这是一个根本性的范式转变：从直接使用 AI 工具，到管理一个管理 AI 工具的系统。
就像从自己做饭，到管理一个厨师团队。你不再关心每道菜的具体做法，而是关注整体菜单、出菜顺序、质量标准。
上下文零和博弈的解法
这个架构为什么有效？因为它解决了 AI 协作的核心问题：上下文窗口是零和博弈。
AI 的“记忆空间”是有限的。你必须选择装什么进去：
装满代码 → 没空间放业务背景
装满客户历史 → 没空间放代码库
Codex 和 Claude Code 看到的是代码，但它们看不到你业务的全貌。
OpenClaw 改变了这个等式。它作为编排层，持有所有业务上下文：
客户数据
会议笔记
过往决策
什么有效、什么失败了
这些信息存储在 Obsidian 知识库中，Zoe 可以访问全部内容。当需要执行具体任务时，Zoe 把历史背景转化为精确的提示词，发给专注于代码的 AI 助手。
编排层保持在高战略层级，执行层专注于代码实现。
这和 Stripe 最近公开的“Minions”系统（并行编程 Agent+中心化编排层）是同一个架构思路——只不过 Elvis 的版本运行在他的 Mac mini 上。
8 步完整自动化工作流
让我们看一个真实案例，从客户需求到代码上线的完整流程。
Step 1: 客户需求 → Zoe 范围界定
Elvis 和一个代理客户通话，客户想要在团队间复用已有的配置。
通话后，他和 Zoe 讨论这个需求。因为所有会议笔记自动同步到 Obsidian 知识库，Zoe 完全理解背景，零解释成本。他们一起确定方案：一个模板系统，让客户保存和编辑现有配置。
然后 Zoe 做三件事：
充值客户积分立即解除阻塞（她有管理员 API 访问权限）
从生产数据库拉取客户配置（她有只读生产 DB 访问权限，但 Codex agent 永远不会有）
生成一个 Codex agent，提示词包含所有上下文
Step 2: 生成 Agent
每个 agent 获得自己的 worktree（隔离分支）和 tmux 会话：
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 "/path/to/worktree" \
"$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"
Agent 在 tmux 会话中运行，完整终端日志被记录。
任务被追踪在。clawdbot/active-tasks.json 中，包含 ID、tmux 会话、agent 类型、描述、仓库、分支、开始时间、状态。
Step 3: 监控循环
一个 cron 任务每 10 分钟检查所有 agent。它不直接轮询 agent（那会很贵），而是运行一个脚本读取 JSON 注册表并检查：
tmux 会话是否存活
追踪的分支上是否有打开的 PR
通过 gh cli 检查 CI 状态
如果 CI 失败或有严重审查反馈，自动重新生成失败的 agent（最多 3 次）
只在需要人类注意时发出警报
Elvis 不需要盯着终端。系统会告诉他什么时候需要看。
Step 4: Agent 创建 PR
Agent 提交、推送，并通过 gh pr create --fill 打开 PR。
此时 Elvis 不会收到通知——一个 PR 本身不算完成。
完成的定义（非常重要，你的 agent 必须知道这个）：
PR 已创建
分支与 main 同步（无合并冲突）
CI 通过（lint、类型检查、单元测试、E2E）
Codex 审查通过
Claude Code 审查通过
Gemini 审查通过
包含截图（如果有 UI 变更）
Step 5: 自动化代码审查
每个 PR 被三个 AI 模型审查。它们捕获不同的问题：
Codex 审查员：在边界情况方面表现出色。做最彻底的审查。捕获逻辑错误、缺失的错误处理、竞态条件。误报率非常低。
Gemini Code Assist 审查员：免费且极其有用。捕获其他 agent 遗漏的安全问题、可扩展性问题。并提供具体修复建议。
Claude Code 审查员：大部分时候没什么用——倾向于过度谨慎。很多“考虑添加……”的建议通常是过度工程。Elvis 跳过所有内容除非标记为关键。它很少独自发现关键问题，但会验证其他审查员标记的内容。
所有三个都直接在 PR 上发布评论。
Step 6: 自动化测试
CI 管道运行大量自动化测试：
Lint 和 TypeScript 检查
单元测试
E2E 测试
针对预览环境的 Playwright 测试（与生产环境相同）
上周新增规则：如果 PR 改变任何 UI，必须在 PR 描述中包含截图，否则 CI 失败。这大幅缩短了审查时间——Elvis 可以准确看到变化了什么，无需点击预览。
Step 7: 人工审核
现在 Elvis 收到 Telegram 通知：“PR #341 准备审查。”
此时：
CI 通过
三个 AI 审查员批准了代码
截图显示 UI 变更
所有边界情况在审查评论中记录
他的审查只需 5-10 分钟。很多 PR 他不读代码就合并——截图告诉他需要知道的一切。
Step 8: 合并
PR 合并。每日 cron 任务清理孤立的 worktree 和任务注册表 json。
改进版 Ralph Loop：失败后变聪明
这本质上是 Ralph Loop，但更好。
Ralph Loop 的逻辑是：从记忆中拉取上下文 → 生成输出 → 评估结果 → 保存学习。但大多数实现每次循环运行相同的提示词。提炼的学习改进未来的检索，但提示词本身保持静态。
Elvis 的系统不同。当 agent 失败时，Zoe 不只是用相同提示词重新生成它。她用完整的业务上下文查看失败，并找出如何解除阻塞：
Agent 上下文用完了？“只关注这三个文件。”
Agent 走错方向了？“停。客户想要 X，不是 Y。这是他们在会议中说的。”
Agent 需要澄清？“这是客户的邮件和他们公司做什么。”
Zoe 保姆式地照顾 agent 直到完成。她有 agent 没有的上下文——客户历史、会议笔记、我们之前尝试过什么、为什么失败了。她用那个上下文在每次重试时写更好的提示词。
但她也不等 Elvis 分配任务。她主动找工作：
早上：扫描 Sentry → 发现 4 个新错误 → 生成 4 个 agent 调查和修复
会议后：扫描会议笔记 → 标记客户提到的 3 个功能请求 → 生成 3 个 Codex agent
晚上：扫描 git 日志 → 生成 Claude Code 更新变更日志和客户文档
Elvis 散步回来后，Telegram 显示：“7 个 PR 准备审查。3 个功能，4 个 bug 修复。”
当 agent 成功时，模式被记录。“这个提示词结构对计费功能有效。”“Codex 需要预先提供类型定义。”“总是包含测试文件路径。”
奖励信号是：CI 通过、所有三个代码审查通过、人工合并。任何失败都触发循环。随着时间推移，Zoe 写出更好的提示词，因为她记得什么能发布。
AI 模型的专业化分工
不是所有编程 agent 都一样。快速参考：
Codex 是主力后端逻辑、复杂 bug、多文件重构、任何需要跨代码库推理的东西。它更慢但彻底。Elvis 用它处理 90% 的任务。
Claude Code 更快，更擅长前端工作它的权限问题也更少，所以很适合 git 操作。（Elvis 以前更多地用它驱动日常工作，但 Codex 5.3 现在就是更好更快）
Gemini 有不同的超能力——设计感对于漂亮的 UI，Elvis 会让 Gemini 先生成 HTML/CSS 规范，然后把它交给 Claude Code 在他们的组件系统中实现。Gemini 设计，Claude 构建。
Zoe 为每个任务选择合适的 agent，并在它们之间路由输出。计费系统 bug 去 Codex。按钮样式修复去 Claude Code。新仪表板设计从 Gemini 开始。
硬件成为新瓶颈
Elvis 现在遇到的天花板是：RAM。
每个 agent 需要自己的 worktree。每个 worktree 需要自己的 node_modules。每个 agent 运行构建、类型检查、测试。五个 agent 同时运行意味着五个并行的 TypeScript 编译器、五个测试运行器、五组加载到内存中的依赖。
他的 16GB Mac Mini 在 4-5 个 agent 时就开始内存交换——而且他需要运气好它们不同时尝试构建。
所以他买了一台 128GB RAM 的 Mac Studio M4 max（3500 美元）来驱动这个系统。它 3 月底到货，他会分享是否值得。
这个细节非常关键：当 AI 能力不再是瓶颈，本地计算资源成为新的限制因素。
三个深层洞察
洞察 1：AI 协作的本质是“认知负荷的空间分配”
上下文窗口是零和博弈。这和人类团队的认知分工惊人相似——你不会让一个工程师既要深入理解业务战略、客户历史、市场定位，又要精通底层代码实现。
双层架构本质上是将“战略思维”和“执行细节”物理隔离，让每个 AI 在其最擅长的认知层级工作。
这个原则可以推广到所有 AI 系统设计：不要试图用一个超大上下文的模型解决所有问题，而是用专业化分工+精准的信息路由。
洞察 2：从“工具使用者”到“系统架构师”
Elvis 的 Git 历史“看起来像刚雇了一个开发团队”，但实际上是“从管理 Claude Code，到管理一个管理 Claude Code 舰队的 OpenClaw agent”。
这揭示了 AI 时代个人生产力的新模式：核心竞争力不再是“会用 AI 工具”，而是“会设计 AI 协作系统”。
就像工业革命时代，价值不在于会操作单台机器，而在于会设计整条生产线。未来的“一人公司”创始人，本质上是系统架构师——设计 AI 之间的协作协议、信息流动、失败恢复机制。
洞察 3：硬件瓶颈预示着“本地 AI 基础设施”的新赛道
Elvis 花 3500 美元买 128GB RAM 的 Mac Studio 来运行 Agent 系统，这个细节非常关键。
当 AI 能力不再是瓶颈，本地计算资源成为新的限制因素。这预示着几个趋势：
“AI 工作站”可能成为新品类（类似当年的“游戏 PC”）
云端 Agent 编排服务会兴起（把并行计算 offload 到云端）
针对 Agent 并行的操作系统优化会出现
这和早期互联网时代服务器需求爆发的逻辑类似——当应用场景成熟，基础设施需求会爆发式增长。
如何开始？
Elvis 的建议简单粗暴：
“把这整篇文章复制到 OpenClaw 中，告诉它：‘为我的代码库实现这个 agent 群系统。’”
“它会读取架构，创建脚本，设置目录结构，配置 cron 监控。10 分钟完成。”
成本：每月约 100 美元用于 Claude，90 美元用于 Codex，但你可以从 20 美元开始。
这不是课程推销。这是完整的架构公开。
写在最后
Elvis 说：“我们将在 2026 年开始看到大量一人百万美元公司。对于那些理解如何构建递归自我改进 agent 的人来说，杠杆是巨大的。”
这就是它的样子：一个 AI 编排者作为你自己的延伸（就像 Zoe 对 Elvis），将工作委派给处理不同业务功能的专业化 agent。工程。客户支持。运营。营销。每个 agent 专注于它擅长的事情。你保持激光聚焦和完全控制。
下一代创业者不会雇佣 10 人团队来做一个人用正确系统能做的事。他们会像这样构建——保持小规模，快速移动，每天发布。
现在有太多 AI 生成的垃圾内容。太多关于 agent 和“任务控制”的炒作，却没有构建任何真正有用的东西。花哨的演示，没有实际好处。
Elvis 试图做相反的事：少炒作，多记录构建实际业务。真实客户，真实收入，真实提交发布到生产环境，还有真实的损失。
他正在构建什么？Agentic PR——一个一人公司挑战企业 PR 巨头。帮助初创公司获得新闻报道的 agent，不需要每月 1 万美元的代理费。
这是 AI 时代个人生产力的新前沿。不是用 AI 替代人，而是用 AI 编排系统放大一个人的能力。
从工具使用者，到系统架构师。这是跨越。
Elvis 的《OpenClaw + Codex/ClaudeCode Agent Swarm: The One-Person Dev Team》原文链接：https://x.com/elvissun/status/2025920521871716562
如果您正在学习AI Agent，想利用Coze/dify/n8n做一些RPA方面的工作流搭建，欢迎在评论区留言或入群交流！
喜欢本篇内容请给我们点个在看
欢迎【关注】&【星标】&【转发】
