一个人的 DevOps 团队：OpenClaw 如何协调 5-20 个 Claude Code 实例

一天 94 次 commit，三个客户电话，一整天没打开编辑器。我的 Git 历史看起来像刚招了一支开发团队。但事实上，团队里只有我一个人。

写在前面：我为什么要把这件事记下来

2026 年初，AI 社区发生了一场静默的革命。

不是又一个新模型发布，而是有人证明了一个人可以拥有一支虚拟开发团队。

一天 94 次 commit——这是我最高产的一天。尽管那天有三个客户电话，而且从未打开过代码编辑器，但系统仍然保持着每天约 50 次 commit 的平均产出。1

七个 Pull Request 在 30 分钟内完成。2

从想法到生产几乎是闪电速度——因为编码和验证大部分已经自动化。这套系统被用于真实的 B2B SaaS 产品开发，与创始人一起主导销售，大部分功能需求可以当天交付。速度直接转化为了付费客户。2

这不是技术 Demo，不是 Twitter 上的概念截图。这是一个独立开发者（Elvis）真实运行了四周、有付费客户验证的生产系统。

这篇文章是我研究、复现并深度拆解这套系统后的完整复盘。我会从第一性原理出发，告诉你为什么需要编排层、怎么搭建、踩了什么坑、花了多少钱。

第一章 核心矛盾：为什么一个 Claude Code 不够用

上下文窗口是零和博弈

这是理解整篇文章的钥匙。

上下文窗口是零和的。填满代码 → 就没有空间放业务上下文。填满客户历史信息 → 就没有空间放代码库。这就是为什么两层系统有效：每个 AI 只加载它需要的特定内容。2

让我画张图：

text

┌────────────────────────────────────────┐
│         单一 Agent 的上下文窗口          │
│                                        │
│  ┌──────────┐ ┌──────────┐ ┌────────┐ │
│  │ 代码库    │ │ 客户历史  │ │ 会议纪要│ │
│  │ (40%)    │ │ (20%)    │ │ (15%) │  │
│  └──────────┘ └──────────┘ └────────┘ │
│  ┌──────────┐ ┌──────────────────────┐ │
│  │ 当前任务  │ │  系统提示 + 工具定义   │ │
│  │ (10%)    │ │  (15%)               │ │
│  └──────────┘ └──────────────────────┘ │
│                                        │
│  ⚠️ 什么都有一点，什么都不够深            │
└────────────────────────────────────────┘

vs

text

┌──────────────────────────────────┐
│  编排器 Agent 的上下文窗口         │
│  ┌────────────────────────────┐  │
│  │ 完整业务上下文               │  │
│  │ 客户数据 + 历史决策 + 战略   │  │
│  │ (80%)                      │  │
│  └────────────────────────────┘  │
│  ┌────────────────────────────┐  │
│  │ 当前任务 + Agent 调度逻辑   │  │
│  │ (20%)                      │  │
│  └────────────────────────────┘  │
└──────────────────────────────────┘
          │  精确提示  │
    ┌─────▼──┐  ┌─────▼──┐
    │编码 Ag1│  │编码 Ag2│
    │100%代码│  │100%代码│
    └────────┘  └────────┘

区别一目了然：编排器拥有全部业务上下文，编码 Agent 拥有全部代码上下文。各司其职，零浪费。

一个 Claude Code 的天花板

Claude Code 不只是代码补全器。它可以规划多步实现方案，导航大型代码库，端到端地管理真实开发工作流。这使它成为当今最强的 AI 开发工具之一。3

但问题是——它是一个专家，不是一个团队。

你能让一个专家同时做前端、后端、测试、部署、写文档吗？技术上可以，但效率会急剧下降，因为每切换一次任务，模型就要重新加载一遍上下文。

你需要的不是一个更强的 Claude Code——你需要五个 Claude Code，各自专注一件事，由一个懂你业务的编排器来调度。

第二章 认识编排层：OpenClaw 在这里扮演什么角色

OpenClaw ≠ 又一个编码工具

OpenClaw 是一个连接你消息应用和 AI 模型的通用型生活助手。Claude Code 是一个住在你终端里、理解整个代码库的专用编码 Agent。比较它们就像比较瑞士军刀和手术刀。4

这正是为什么它们组合在一起如此强大——

OpenClaw 编排 Claude Code，这是真正意义上的 AI Agent 在使用 Claude 来构建软件——最字面意义上的 Claude 驱动的机器人。5

OpenClaw 可以程序化地触发 Claude Code 工作流。Claude Code 的结果可以反馈到 OpenClaw 的监控管线中。6

更妙的是这种闭环设计——一个失败的部署可以将错误日志发送到 OpenClaw，OpenClaw 将其路由到 Claude Code 进行诊断，Claude Code 推送修复，然后 OpenClaw 验证并报告结果。这一切都不需要你在看着。6

Elvis 的 Zoe 系统

让我们回到那个一天 94 commit 的人。他的架构是这样的：

他使用 OpenClaw 作为编排层。他的编排器 Zoe 负责生成子 Agent、编写它们的提示、为不同任务选择最合适的模型、监控进度，并在 PR 可合并时通过 Telegram 通知。2

OpenClaw 作为你和所有 Agent 之间的编排层——在 Obsidian Vault 中保存所有业务上下文（客户数据、会议纪要、历史决策、成功与失败），并将这些历史上下文翻译为每个编码 Agent 的精确提示。编码 Agent 专注于代码。编排器专注于战略。1

text

┌───────────────────────────────────────────────────────────────┐
│                    你（人类决策者）                               │
│              通过 Telegram / Discord 发送指令                    │
└───────────────────────┬───────────────────────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────────────────────┐
│              🦞 OpenClaw 编排器 (Zoe)                          │
│                                                                │
│  ┌────────────┐  ┌────────────┐  ┌──────────────────┐        │
│  │ SOUL.md    │  │ MEMORY.md  │  │ Obsidian Vault   │        │
│  │ 人格+原则   │  │ 长期记忆    │  │ 业务全景上下文     │        │
│  └────────────┘  └────────────┘  └──────────────────┘        │
│                                                                │
│  职责：理解需求 → 拆解任务 → 选择模型 → 分配Agent → 监控合并    │
│  模型：Claude Opus（需要最强推理来做任务拆解和质量把控）          │
└──────┬────────┬────────┬────────┬────────┬───────────────────┘
       │        │        │        │        │
  ┌────▼───┐┌───▼──┐┌───▼──┐┌───▼──┐┌───▼──┐
  │ Codex  ││Claude││Claude││Codex ││Gemini│
  │ Agent1 ││Code 2││Code 3││Agent4││CLI 5 │
  │ 前端   ││ 后端  ││ 测试  ││ DevOps││ 文档  │
  │ React  ││ Go   ││ QA   ││ CI/CD││ Docs │
  └────────┘└──────┘└──────┘└──────┘└──────┘

Stripe 上周写了他们的后台 Agent 系统 "Minions"——并行编码 Agent 加中心化编排层。Elvis 意外地构建了同样的东西，只不过它在本地 Mac mini 上运行。1

第三章 Gateway 架构：一个进程，多个大脑

OpenClaw Gateway 的本质

OpenClaw 中的一切都流经一个叫做 Gateway 的单一进程。官方文档将其描述为 Session、路由和频道连接的"唯一事实来源"。可以把它想象成整个系统的神经系统。Gateway 通常作为长期运行的后台进程运行（在 Linux 上通过 systemd，或 macOS 上通过 LaunchAgent）。客户端通过 WebSocket 连接到它，默认绑定地址是 ws://127.0.0.1:18789。7

Gateway 处理路由、连接、认证和会话管理。Agent 运行时处理推理和执行。这种关注点分离是有意为之且至关重要的。这是第一个值得内化的架构概念：一个真正的 AI Agent 部署，总是在模型前面有一个编排层。7

多 Agent 隔离

OpenClaw 可以在一个 Gateway 进程内运行多个完全隔离的 Agent。这里的"隔离"不是营销用语。每个 Agent 可以拥有自己的工作区目录和本地文件（如 SOUL.md 和 AGENTS.md）。它们仍然共享同一个服务器进程和同一份主配置文件，所以你不需要运行十个 Gateway——你运行一个 Gateway，里面装着多个"大脑"。8

那什么时候应该从单 Agent 升级到多 Agent？

多 Agent 在你需要真正的隔离、不同的工具策略或永远不该混合的独立记忆时变得有用。8

具体来说——

不同的安全上下文：当某些对话需要访问敏感系统而其他对话应保持沙箱化时，使用不同认证配置的独立 Agent 可以提供清晰的安全边界。专业化能力：运行一个具有网页浏览功能的研究 Agent 和一个具有仓库访问权限的编码 Agent，让每个都能针对各自的领域优化。频道特定行为：不同频道上根本不同的人格或能力。资源管理：不同的 Agent 可以使用不同的模型。你的编排 Agent 可以使用 Claude Opus 做复杂推理，而工作 Agent 使用更快、更便宜的模型处理日常任务。9

第四章 ACP——Agent 之间的通信协议

这是整套系统的技术心脏。

为什么需要 ACP

传统方式——让 OpenClaw 通过 PTY（伪终端）去"驱动" Claude Code 的 TUI——非常脆弱。

acpx 是 Agent Client Protocol (ACP) 的无头 CLI 客户端，让 AI Agent 和编排器能通过结构化协议与编码 Agent 通信，而不是 PTY 抓取。一个命令界面就能操控 Codex、Claude、Gemini、OpenCode、Pi 或自定义 ACP 服务器。专为 Agent 到 Agent 的命令行通信而构建。10

编排器通常在原始终端中生成编码 Agent 并解析 ANSI 文本。这会丢失结构：工具调用、权限请求、计划、Diff 和会话状态。ACP 适配器已经存在于主要 Agent 中，但之前没有专注于脚本化使用的无头 CLI 客户端。acpx 填补了这个空白。11

架构图如下：

text

┌─────────────┐ stdio/ndjson ┌──────────────┐ wraps  ┌─────────┐
│  acpx CLI   │ ◄──────────► │  ACP adapter │ ◄─────► │  Agent  │
│  (client)   │ ACP protocol │  (codex-acp) │internal │ (Codex) │
└─────────────┘              └──────────────┘        └─────────┘

ACP 的核心能力

持久会话：跨调用存活的多轮对话，按仓库范围。命名会话：在同一仓库中运行并行工作流（-s backend, -s frontend）。提示队列：在一个提示运行时提交另一个，它们按顺序执行。协作取消命令：cancel 通过队列 IPC 发送 ACP session/cancel，不会拆毁会话状态。软关闭生命周期：关闭会话但不删除磁盘上的历史。Fire-and-forget：--no-wait 将提示入队并立即返回。10

OpenClaw 如何使用 ACP

Agent Client Protocol (ACP) 会话让 OpenClaw 可以通过 ACP 后端插件运行外部编码工具（例如 Pi、Claude Code、Codex、OpenCode 和 Gemini CLI）。如果你用自然语言要求 OpenClaw "在 Codex 中运行这个"……12

使用 runtime: "acp" 可以从 Agent 回合或工具调用中启动一个 ACP 会话。12

实际调用长这样：

JSON

{
  "task": "打开仓库并总结失败的测试",
  "runtime": "acp",
  "agentId": "codex",
  "thread": true,
  "mode": "session"
}

完整的 ACP 配置支持多个 Agent 后端——allowedAgents: ["pi", "claude", "codex", "opencode", "gemini", "kimi"]，最大并发会话数为 8。12

Thread 绑定——Discord 频道变身 Agent 终端

当线程绑定在频道适配器上启用时，ACP 会话可以绑定到线程：OpenClaw 将一个线程绑定到目标 ACP 会话。该线程中的后续消息会被路由到绑定的 ACP 会话。ACP 输出会被传回同一个线程。取消焦点/关闭/归档/空闲超时或最大有效期到期时移除绑定。12

这意味着——你在 Discord 里开一个线程，这个线程就变成了一个 Claude Code 会话的实时终端。你可以同时开 5 个线程，每个线程对应一个 Agent 在处理不同的任务。在 Discord 上看，就像有 5 个程序员在同时干活。

第五章 Sub-Agent 系统：编排器的手和脚

sessions_spawn：核心编排原语

Sub-Agent 的首要目标：并行化"研究/长任务/慢工具"的工作，不阻塞主运行。13

具体场景——

你让 OpenClaw 研究五个竞品并分别总结。没有子 Agent，它会一个接一个地研究。有了子 Agent，它可以同时研究所有五个。14

你需要一份晨间简报，包含天气、日历、邮件摘要和新闻。没有子 Agent，它逐个收集信息。有了子 Agent，它并行收集所有内容，等所有部分就绪后再组装简报。14

成本控制的杀手锏：模型分层

每个子 Agent 有自己的上下文和 token 消耗。对于繁重或重复的任务，为子 Agent 设置更便宜的模型，将主 Agent 保持在更高质量的模型上。你可以通过 agents.defaults.subagents.model 或按 Agent 覆盖来配置。13

这是一个重要的成本优化策略。你的协调器 Agent 用昂贵的模型思考。你的工作 Agent 用便宜的模型执行。14

用人类团队来类比——

text

┌─────────────────────────────────────────────────────────┐
│                  CTO（你 + 编排器 Opus）                   │
│              做决策、拆任务、质量把控                         │
│              年薪 $300K 的脑力，最贵但只需要一个              │
├──────────┬──────────┬──────────┬──────────┬──────────────┤
│  前端 Dev │  后端 Dev │  QA      │  DevOps  │  Tech Writer │
│  (Sonnet) │  (Codex) │  (Haiku) │  (Codex) │  (Haiku)    │
│  快速执行  │  快速执行  │  快便宜   │  快速执行  │  最便宜    │
└──────────┘──────────┘──────────┘──────────┘──────────────┘

防止失控：并发限制

每个 Agent 会话（任何深度）同时最多可以有 maxChildrenPerAgent（默认：5）个活跃子节点。这防止了单个编排器的失控扇出。13

停止一个 depth-1 的编排器会自动停止它所有的 depth-2 子节点：在主聊天中使用 /stop 会停止所有 depth-1 Agent 并级联到它们的 depth-2 子节点。/subagents kill <id> 停止特定子 Agent 并级联到其子节点。/subagents kill all 停止所有子 Agent 并级联。13

第六章 实战：五个 Agent 并行处理一次大型重构

让我用一个真实场景来展示完整的工作流。

场景：客户要求重构认证系统

客户 Slack 消息：「下周一之前能把认证从 JWT 迁移到 Session-based 吗？」

传统做法：一个人干 3-5 天。Agent Swarm 做法：

Step 1：编排器 Zoe 接收需求（5 分钟）

我在 Telegram 上给 Zoe 发消息：

text

@zoe 客户 A 要求把认证从 JWT 迁移到 session-based。
代码在 github.com/client-a/api 仓库。
下周一截止。请制定方案并分配工作。

Zoe 读取 Obsidian Vault 中的客户 A 上下文（包括架构文档、之前的技术决策、团队偏好），然后输出：

Markdown

## 认证迁移方案 v1
### 任务拆解
1. [架构] 设计 session store schema + 迁移策略 → Opus (深度思考)
2. [后端] 实现 session 中间件 + API 适配 → Claude Code Agent
3. [前端] 更新 token 存储逻辑 → Codex Agent
4. [测试] 编写认证集成测试 → Claude Code Agent (Haiku)
5. [文档] 更新 API 文档 + 迁移指南 → Codex Agent (Haiku)
### 依赖关系
1 → 2,3 (并行) → 4 → 5
### 预估
- 并行编码阶段：2-3 小时
- 测试 + 修复：1-2 小时
- 总计：4-6 小时（vs 传统 3-5 天）
等你确认我就开始分配。

Step 2：Zoe 通过 ACP 分配工作（30 秒）

我回复「Go」，Zoe 开始并行生成 Agent：

Bash

# Zoe 内部执行的 ACP 调用（简化展示）
# Agent 1: 架构设计（串行优先，因为后续依赖它）
acpx claude sessions new --name auth-arch
acpx claude -s auth-arch "设计 session store schema，
参考客户 A 的现有 PostgreSQL schema..."
# 等待 Agent 1 完成后，并行启动 2 和 3：
# Agent 2: 后端实现
acpx codex sessions new --name auth-backend
acpx codex --no-wait -s auth-backend "实现 session 中间件，
schema 如下：[Agent 1 的输出]..."
# Agent 3: 前端适配
acpx codex sessions new --name auth-frontend
acpx codex --no-wait -s auth-frontend "更新前端 token 存储逻辑..."
# Agent 4: 测试（等 2 和 3 完成后）
acpx claude sessions new --name auth-tests
acpx claude -s auth-tests "为新认证系统编写集成测试..."
# Agent 5: 文档
acpx codex sessions new --name auth-docs
acpx codex --no-wait -s auth-docs "更新 API 文档..."

Step 3：监控与合并（我在开客户电话）

在 Discord 的 #dev-ops 频道里，每个 Agent 的线程都在实时更新进度。我的手机上，Telegram 每完成一个 PR 就推送通知：

text

🟢 [auth-backend] PR #47: Session middleware - 全部测试通过
🟢 [auth-frontend] PR #48: Token storage migration - 全部测试通过
🟡 [auth-tests] 运行中... 3/8 测试完成
🟢 [auth-docs] PR #49: API docs update - Ready for review
🟡 [auth-tests] PR #50: Integration tests - 1 个测试失败
🔄 [auth-tests] 自动修复中...
🟢 [auth-tests] PR #50 (v2): 全部测试通过

总耗时：4 小时 23 分钟。我的人工介入：发了两条 Telegram 消息。

第七章 Agent Teams——下一代协调方式

当前 Sub-Agent 的局限

使用 sessions_spawn 时，子 Agent 只能与父级通信。如果子 Agent A 发现了与子 Agent B 相关的内容：当前方式是 A → 父级 → B（间接的，需要父级中继）；有了 Teams 后：A → B（直接的，即时的）。每个生成的会话都有隔离的上下文。没有共享的任务列表，没有办法查看其他子 Agent 在做什么，没有依赖追踪。子 Agent 在生成时接收任务，无法接手新工作。如果任务提前完成，子 Agent 就闲置了。结论：sessions_spawn 非常适合独立的、聚焦的任务。15

Teams RFC：正在到来的革命

社区已经提出了 Agent Teams 的 RFC 提案——

RFC 大量依赖共享文件系统（~/.openclaw/teams/）来进行协调和状态管理（任务、邮箱）。虽然持久化很重要，但社区 PR 实现将这些作为内置上下文特性而非纯粹依赖文件解析。任务账本（TaskCreate、TaskList、TaskUpdate）和通信协议（SendMessage 用于消息、广播和关闭/计划请求）由编排器直接处理。这减少了多个 Agent 活跃时解析 JSON/JSONL 文件的摩擦，使编排更加健壮。15

这意味着将来 Agent 之间可以：

• 直接通信（不需要经过父级中继）
• 共享任务看板（看到彼此在做什么）
• 动态分配工作（提前完成的 Agent 自动领取新任务）
• 进行代码审查（Agent A 写的代码让 Agent B 审查）

第八章 Mission Control——你的 AI 团队仪表板

当你的 Agent 舰队扩展到 5 个、10 个甚至 20 个时，你需要一个可视化的控制中心。

社区百花齐放

Mission Control 已经成为 OpenClaw 社区最活跃的赛道之一。

OpenClaw Mission Control 是跨团队和组织运行 OpenClaw 的集中化运营和治理平台，提供统一的可见性、审批控制和 Gateway 感知的编排。它为运营者提供一个工作编排、Agent 和 Gateway 管理、审批驱动治理和 API 支持自动化的统一界面。16

实时活动流、会话检查器和日志查看器（带过滤）。WebSocket 连接到 OpenClaw Gateway 实现即时事件传递。Token 使用仪表板，按模型细分、趋势图表和成本分析。定时任务用于数据库备份、过期记录清理和 Agent 心跳监控。可通过 UI 或 API 配置。直连 Claude Code、Codex 或任何 CLI 工具到 Mission Control，无需 Gateway。注册连接、发送带内联 token 报告的心跳，并自动注册 Agent。自动发现并追踪本地 Claude Code 会话，通过扫描 ~/.claude/projects/。从 JSONL 记录中提取 token 使用量、模型信息、消息数、成本估算和活跃状态。每 60 秒通过后台调度器扫描一次。17

Jonathan Tsai 的真实案例

他管理 5 个 AI 主实例、10 个卫星 Agent 和 20 多个定时任务——从混乱到清晰。18

他的核心洞察是什么？

人类已经在 Slack 里了。他在员工数十人、数百人甚至数千人的公司工作过，有成百上千个 Slack 频道。那里是工作发生的地方。那里是上下文所在的地方。那里是人们沟通的地方。所以他没有构建另一个强迫上下文切换的工具，而是问：如果我把可见性带到我已经在的地方呢？Agent 就生活在 Slack 线程中——那是它们的原生栖息地。18

他甚至在健身房里通过 Slack 在手机上编程……在卧推 315 磅之间。可能性是无限的。18

他还应用了操作系统级的工程思维——

在具有 Spark、Airflow、Dagster、Celery 和 Beanstalk 的多年生产经验之后——每一个都有各自的优势和痛苦的局限——他对 AI 原生调度器应该是什么样子有很强的观点。他直接从 CS162（操作系统）中提取了概念：多线程原语、信号量、互斥锁、进程调度算法。这些不是学术练习——当几十个 AI Agent 竞争有限资源时，这正是你需要的东西。18

第九章 真实工作流模式：从简单到复杂

模式一：直接 PTY 方式（入门级）

OpenClaw 可以正常使用 Claude Code/Codex，只要你把它们当作交互式 CLI 并通过 PTY exec 运行。关键的错误是试图"驱动 TUI"像操控 GUI 应用；正确的模式是：启动 CLI → 让它在工作目录中进行编辑 → 流式传回日志 → 如果它询问就回答提示。19

Bash

# 一次性任务
bash pty:true workdir:~/your-project \
  command:"claude 'Implement X. Run tests. Summarize changes.'"
# 后台长时间运行（推荐）
bash pty:true workdir:~/your-project background:true \
  command:"claude 'Refactor Y. Keep behavior. Run tests.'"

模式二：ACP 会话方式（推荐）

Bash

# 创建命名会话
acpx codex sessions new --name api
acpx codex sessions new --name docs
# 并行工作
acpx codex -s api 'implement cursor pagination'
acpx codex -s docs 'rewrite API docs'
# Fire-and-forget（入队不等待）
acpx codex --no-wait 'draft test migration plan'
# 检查状态
acpx codex sessions list
acpx codex status

模式三：Fan-out / Fan-in 模式（高级编排）

多个子 Agent 扇出收集信息，然后主 Agent 扇入综合。例如："为 AI 笔记应用创建市场分析"——子 Agent 1 收集 10 个产品的定价数据，子 Agent 2 收集用户评论和情绪，子 Agent 3 研究功能对比，子 Agent 4 查找市场规模和增长数据——主 Agent 将四个数据流综合为一份完整的市场分析文档。14

模式四：确定性管线模式（最健壮）

来自社区开发者 ggondim 的贡献——

他需要一个代码→审查→测试的管线，由自主 AI Agent 驱动，编排是确定性的（不让 LLM 决定流程）。在经过两个月探索 Copilot Agent 会话、构建自己的封装器（Protoagent）、评估 Ralph Orchestrator 并深入 OpenClaw 内部后，他发现 Lobster（OpenClaw 的工作流引擎）是正确的基础——只是缺少循环。所以他贡献了带循环支持的子工作流步骤，实现了完全确定性的多 Agent 管线，LLM 做创意工作，YAML 工作流处理管道。20

这个思路和我在第一篇文章中强调的一致——不要用 LLM 做编排。让 LLM 做 LLM 擅长的事（写代码、分析、创作），让确定性引擎做确定性引擎擅长的事（排序、路由、重试）。

第十章 多机器人 Slack 协作——Agent 像真人同事一样工作

如果你希望 Agent 像真正的团队成员一样出现在 Slack 中——各有各的名字、头像，可以互相 @mention、在线程中接力——这是具体做法：

目标：将多个 AI Agent 作为真正的 Slack 队友运行——每个都有自己的身份，能独立发 DM 或参与共享频道——同时通过一个主 Agent 集中编排。每个 Slack App 对应一个 accountId，绑定将每个 account 路由到对应的 OpenClaw Agent。这给每个 Agent 真正的独立 DM 加上共享频道中的群聊存在感。无论是 2 个还是 10 个 Agent，模式都一样。21

关键配置——防止 Bot 死循环：

allowBots: true 让每个 Agent 可以消费其他 Bot 的消息作为上下文。requireMention: true 防止 Bot 循环（每个 Bot 只在被明确 @ 时才响应）。21

第十一章 成本真相

月度账单拆解

Jonathan 使用 $200/月的 Claude Code Max 计划。如果不做优化，他的每周额度到周三就会用完，之后就要支付超额费用。18

Claude Code Pro 起价约 100-$200/月），获得 5x-20x 使用量和 Opus 访问，以避免密集会话中的速率限制。22

我的推荐分层方案：

对比雇佣一个初级开发者的月薪（$4,000-6,000），这个 ROI 是不是清楚了？

省钱秘籍

你的协调器需要最好的推理模型。你的工作 Agent 通常需要又快又便宜的。将模型匹配到任务复杂度。14

具体策略：

• 编排器：Opus（最贵但值得——它决定任务拆解的质量）
• 编码主力：Sonnet（性价比最佳）
• 测试/文档/格式化：Haiku（够用就好）
• 本地模型：通过 Ollama 跑 Kimi 2.5 做低优先级任务，零 API 成本

第十二章 权限与安全：不能忽视的另一面

ACP 的权限控制

ACP 会话以非交互方式运行——没有 TTY 来批准或拒绝文件写入和 Shell 执行的权限提示。acpx 插件提供两个配置键来控制权限的处理方式：一个控制工具 Agent 可以无需提示执行哪些操作；另一个控制当权限提示需要显示但没有可用的交互式 TTY 时（ACP 会话永远是这种情况）会发生什么。12

重要提示：OpenClaw 当前默认 permissionMode=approve-reads 和 nonInteractivePermissions=fail。在非交互式 ACP 会话中，任何触发权限提示的写入或执行都可能失败。12

安全防线建议

如果你决定多频道编排对你的工作流确实必要，请睁大眼睛进去。知道你在连接什么。知道一个被入侵的频道意味着什么。安装之前先阅读每一个 Skill。在专用机器上运行，不是你的个人笔记本。23

我的安全实践清单：

Markdown

✅ 编排器 Agent：只有 Obsidian 读取权限 + ACP 调度权限
✅ 编码 Agent：只有项目目录的读写权限，无互联网访问
✅ 测试 Agent：只读 + 测试执行权限
✅ 文档 Agent：只有文档目录写入权限
✅ 每个 Agent 独立的 API Key
✅ Gateway 运行在 Docker 容器内
✅ 通过 Tailscale 私有网络访问
✅ 每个 Skill 安装前人工审阅源码
✅ 每日 Obsidian Vault 自动备份到私有 Git 仓库

多 Agent 使隔离更容易，但也增加了攻击面。你有更多的 Bot Token、更多的 Skill、更多的认证配置。通常的"审查第三方 Skill"建议仍然适用，而且在这里更重要，因为你可能不小心将一个 Skill 安装到共享目录中，使其对每个 Agent 都可用。8

第十三章 从 0 到 1 的行动路线图

Week 1：最小可行编排（投入 1 天）

如果你目前在几个频道上运行单个助手，你可能不需要多 Agent。一个配置良好的单 Agent 可以处理 Slack、Telegram 和 Discord 并保持良好的上下文。8

所以第一周：

Bash

# 1. 安装 OpenClaw + acpx
npm install -g openclaw@latest
npm install -g acpx@latest
# 2. 配置 Gateway + Discord
openclaw onboard --install-daemon
# 3. 验证 ACP 连接
acpx codex 'echo hello world'
# 4. 尝试第一个手动编排
# 在 Discord 中发消息：
# "请用 Codex 帮我修复 ~/project 中失败的测试"

Week 2：两层架构（投入 2 天）

创建你的编排器 Agent：

Markdown

# SOUL.md - 编排器 Agent
## 你是谁
你是一位资深技术总监，名叫 Zoe。
你的工作是理解业务需求、拆解技术任务、
分配给合适的编码 Agent、监控质量。
## 核心原则
1. 永远不要自己写代码——你的工作是思考和分配
2. 每个任务都要明确：输入、预期输出、验收标准
3. 为每个子 Agent 选择最合适的模型和工具
4. 完成后通过 Telegram 通知人类
## 可用 Agent
- codex: 擅长快速编码和重构
- claude: 擅长深度推理和架构设计
- gemini: 擅长文档和知识工作

Week 3-4：完整 Agent 舰队（持续迭代）

text

Day 1:  编排器 + 1 个编码 Agent → 验证任务分配流
Day 3:  + 测试 Agent → 验证 code→test 管线
Day 5:  + 文档 Agent → 完整 SDLC 覆盖
Day 7:  + Mission Control → 可视化监控
Day 14: 并行编码 Agent 扩展到 3-5 个
Day 21: 接入 Obsidian Vault → 长期业务上下文
Day 30: 全面优化：成本、速度、质量的平衡

第十四章 诚实反思：这套系统的真实边界

它真正改变了什么

• 时间杠杆：同样 8 小时可以完成之前 3-5 天的编码量
• 质量一致性：Agent 不会因为周五下午而偷懒
• 上下文无损：编排器记住了每一个历史决策，不会重复犯错
• 异步解放：开会时代码在跑，睡觉时测试在跑

它做不到什么

• 不能替代架构直觉：Agent 写不出你还没想明白的架构
• 不能处理模糊需求：你的任务描述越模糊，Agent 的输出越差
• 不能做产品决策：Agent 不知道哪个功能更重要，你知道
• 不能在没有监督下长期运行：每 2-3 小时需要检查一次，否则容易走偏

最大的坑

1. 过度编排：不是所有任务都需要 5 个 Agent。简单 Bug 修复用一个 Agent 就够了。
2. 上下文传递损耗：编排器到子 Agent 的上下文传递永远有信息损耗，你需要不断优化提示模板。
3. 模型一致性：不同模型的代码风格不一样。前端用 Codex、后端用 Claude，合并时可能风格冲突。在 AGENTS.md 中统一代码规范可以缓解但无法根除。
4. Debug 复杂度：当 5 个 Agent 同时运行时，出了问题追踪根因比单 Agent 困难得多。Mission Control 和详尽的日志是必须的。

写在最后：一人公司的新定义

我们会在 2026 年看到大量一个人的百万美元公司。对于那些理解如何构建递归自我改进 Agent 的人来说，杠杆是巨大的。这就是它的样子：一个 AI 编排器作为你自己的延伸，将工作委派给处理不同业务职能的专业 Agent。1

工程。客户支持。运营。营销。每个 Agent 专注于它擅长的事情。你保持极度聚焦和完全控制。1

下一代创业者不会雇佣 10 个人的团队去做一个拥有正确系统的人就能做的事。他们会这样构建：保持精简、快速迭代、每天发布。1

但我也想补充 Elvis 的另一段清醒的话——

现在有太多 AI 生成的垃圾。围绕 Agent 和"Mission Control"的大量炒作，却没有构建任何真正有用的东西。花哨的演示，却没有真实世界的收益。1

真正的区别在于：你是在做 Demo，还是在做生意？

这套系统不是为了在 Twitter 上发炫酷截图。它是为了让一个人能交付五个人的代码量，同时保持高质量，并且把省下来的时间花在真正只有人类能做的事情上——理解客户、做产品决策、建立信任。

94 次 commit 不是目的。

让客户在截止日期前收到高质量的产品，才是目的。

Agent 帮你做了 95% 的键盘敲击。

但决定敲什么、为谁敲、为什么敲——这永远是你的工作。

📌 下期预告： 《Last 30 Days Skill：30 秒摸清一个领域的真实痛点》——如何用 OpenClaw 挖掘 Reddit、X、HN 上的真实用户痛点，30 秒内验证你的产品创意值不值得做。

关注不迷路。🦞

声明：本文基于 OpenClaw 开源社区公开资料、Elvis（@elvissun）的公开分享、Jonathan Tsai 的博客、Dan Malone 的教程及多位社区贡献者的实践经验撰写。所有架构图和代码配置均为学习示例，请根据实际项目需求调整。安全风险部分引用了多方独立机构的公开报告。技术细节截至 2026 年 3 月初，OpenClaw 生态迭代极快，请以官方文档为准。本文不构成任何投资或技术决策建议。_