夜雨聆风
我错怪了 OpenClaw.但也没完全错.
errata · /wechat/openclaw · parallel execution
我错怪了 OpenClaw。但也没完全错。
事实勘误：OpenClaw 的子 Agent 和并行执行是真的，但可发现性和默认可靠性依然让体验像是坏的。
一个月前我发了篇《用惯了 OpenCode，OpenClaw 真降智》，说 OpenClaw 没有子 Agent、没有并行任务执行、永远只有一个对话。前两条我说错了。第三条我坚持。
01 · 我说错了什么
SECTION · 01 · ERRATA RECORD
原文里我写道：
✕ old claim · 1/2
「不是多 Agent 系统（没有子 Agent 编排，没有并行任务执行）」
对比表里：
✕ old claim · 2/2
「子 Agent：❌ 没有并行 Agent」
这是事实性错误。OpenClaw 至少从 v2026.2 就有子 Agent 了，并行执行系统设计得其实不错。下面这段一直在我的配置里：
CONFIG · ~/.config/openclaw.json
defaults.maxConcurrent
4主 Agent 并发槽位
subagents.maxConcurrent
8子 Agent 独立并发槽位
✓ correction
4 个并发主 Session。8 个并行子 Agent。就在那儿。我愣是没看到。
02 · 我漏掉的架构
SECTION · 02 · TWO LANES, NOT ONE CHAT
OpenClaw 的并发模型是一个分车道的 FIFO 队列：
LANE · A · MAIN
并发数：4 每个 Session 内串行；全局最多 4 个主 Agent 任务同时跑。
LANE · B · SUB-AGENT
并发数：8 子 Agent 走独立车道，槽位由 subagents.maxConcurrent 控制。
GATEWAY · LANES
MAIN LANE · MAX 4
主 Session 任务最多 4 个同时执行。
main runningwork runningproj runningnext queued
SUB-AGENT LANE · MAX 8
子 Agent 使用独立车道，最多 8 个并行。
uuid-1 runninguuid-2 runninguuid-3 runningup to 8
每个 Session 有自己的串行车道（同一时间只跑一个任务），但全局主车道允许最多 4 个 Session 并行运行。子 Agent 有独立车道，8 个槽位。
note
「主车道 = 4」限的是同时执行的主 Agent 任务数，不是你能开几个 Session。Session 数量没有上限，但同时在跑的最多 4 个。
核心工具是 sessions_spawn：
COMMAND · SUBAGENTS SPAWN
command
/subagents spawn default
task text
调研排名前 5 的 MCP 服务器
model flag
–model qwen3.5-plus
这会发射一个非阻塞的后台 Agent：
配合 maxSpawnDepth: 2，可以搭出真正的编排模式：
ORCHESTRATION · DEPTH ≤ 2
root主 Agent
depth=1编排子 Agent
depth=2工人层
工人 A工人 B工人 C
编排 Agent 能启动的工人数受车道剩余槽位限制，通常最多 7 个（编排器自己占 1）。它通过 sessions_list / sessions_history 管理工人，汇总后再向上汇报。这是货真价实的多 Agent 编排。
03 · 那我当初为什么没发现？
SECTION · 03 · DISCOVERABILITY FAILURE
三个原因。
1. TUI 把一切藏起来了
打开 OpenClaw 的 TUI（openclaw tui），看到的是一个聊天界面、一个输入框、一段对话。没有「启动子 Agent」按钮，没有「并行任务」面板，没有任何视觉提示告诉你这个系统存在。
对比 OpenCode，子 Agent 是系统 Prompt 里的一等公民，编排器像调 grep 一样自然地发射 explore 与 librarian。UI 显示任务 ID，后台完成自动通知。
note
OpenClaw 的子 Agent 是工具级功能，不是 UI 功能。需要模型自己决定调用 sessions_spawn。系统 Prompt 没突出提到，模型就不会用。
2. 文档太碎片化
初评时我读了 OpenClaw 文档。首页讲「个人 AI 助手」，入门指南教配 Telegram，概念部分讲消息、记忆、命令队列。子 Agent 藏在 Tools → Sub-Agents，要点好几层；队列并发模型在 Concepts → Command Queue；maxSpawnDepth 编排在更深的子章节里。你得先知道功能存在，才能找到文档。
3. 默认配置不做宣传
我的配置从第一天就有 maxConcurrent: 4 和 subagents.maxConcurrent: 8，安装向导默默写进去的。但向导从没说「嘿，你现在有最多 8 个并行子 Agent 了」。
⚠ root cause
功能存在。配置已设。文档有写。但在正常使用流程中，没有任何东西让你发现这些。
04 · 真凭实据：我亲自跑了一次
SECTION · 04 · RECEIPTS FROM A 5-AGENT TEST
读者完全可以追问：「你是只看了配置，还是真的验证过并行能跑？」合理质疑。下面是我实测的结果。
我让主 Agent 并行调研五款编程工具（OpenCode、Claude Code、Cursor、Aider、Continue.dev），明确要求每个工具派一个子 Agent，并禁止主 Agent 在子 Agent 全部返回前自己动手。Session 列表瞬间多出五个：
SESSION LIST · SNAPSHOT
active parent
parent session · 20260406-011348
five subagents
research-aiderresearch-opencoderesearch-claude-coderesearch-continueresearch-cursor · selected
other visible sessions
main sessionopenclaw-tui
✓ proof · 我实际跑了 5 个 subagent
五个子 Session，每个独立上下文，都能从下拉切进去。池子报告 5/8 槽位占用。编排是真的。
但是，这点很关键，五个里只有一个（research-cursor）在 timeout 内真正完成了。其他四个全部超时，主 Agent 用 web_fetch 兜底填上空缺。最终那份报告读起来像单 Agent 调研写的，因为它实际上就基本是单 Agent 写的。
⚠ field finding
OpenClaw 的并行执行确实是真的，但子 Agent 继承了一个受限的工具/超时配置，长任务调研不可靠。容量在那儿，完成率（至少在我环境里）不在。
所以修正后的故事不是「OpenClaw 有并行」，而是：
updated verdict
OpenClaw 有并行。子 Agent 真能 spawn。编排模式真能跑。
但默认子 Agent 运行时脆到，除非你调超时和工具权限，否则你感觉不到并行。普通用户照样不会发现。
原文说「没有并行执行」是错的。但抱怨的精神内核——我在正常使用里从来没感觉到并行——结果部分正确，只是原因和我当初以为的不一样。
05 · 我说对了什么
SECTION · 05 · NOT A FULL RETRACTION
澄清一下：我在纠正事实错误，不是撤回评测。
单 Session 的 UX 问题是真的。你可以用 openclaw tui --session work 创建多个 Session，我也设了别名：
~/.zshrc · shell aliases
cmain
打开 main Session，thinking high。
cwork
打开 work Session，thinking high。
cproj
打开 project Session，thinking high。
但默认体验仍是一个聊天线程。TUI 打开就是 agent:main:main，除非你自己用 shell 别名搭一套 Session 管理。没有 Session 选择器，没有侧边栏，没有像其他 AI 产品那样正常工作的「新对话」按钮。
自主性差距是真的。歌词测试结论不变。子 Agent 解决不了根本问题：OpenClaw 的 Agent 循环比 OpenCode 更谨慎、更依赖用户。8 个并行子 Agent 没用，如果父 Agent 还在问「你希望我怎么提供歌词？」而不是直接动手。
FOMO 批评是真的。发现子 Agent 不会改变炒作生态。22 万 Star 依然衡量的是营销，不是能力。
06 · 更大的教训
SECTION · 06 · UI SURFACE IS NOT SYSTEM TRUTH
我犯了一个技术评测中很常见的错误：测试了 UI 表面，然后以此为依据写了评测，而不是测试底层系统。
OpenClaw 的 UI 展示的是一个聊天机器人，配置和文档描述的是一个并发多 Agent 编排平台。两个穿同一个名字的不同产品，你只有从头读完文档或偶然撞上正确的配置项，才能遇到第二个。
✓ root cause
这是设计失败，不是能力失败。工程本身是扎实的——分车道队列、级联停止、深度限制编排、按深度配置的工具策略。但这些在正常使用中完全不可发现。
就像买了辆车，发现后备箱里藏了个配置文件能开涡轮模式。涡轮确实能用，但只能撑几秒就过热。功能确实存在。但你同时抱怨可发现性和可靠性，依然是对的。
07 · 更新后的对比
SECTION · 07 · OPENCLAW VS OPENCODE
多 Session
OpenClaw ⚠ 需 CLI 参数/别名 · OpenCode ✓ 内置 UI
子 Agent
OpenClaw ✓ sessions_spawn (≤8) · OpenCode ✓ explore/librarian
编排模式
OpenClaw ✓ maxSpawnDepth: 2 · OpenCode ✓ omo system prompt
子 Agent 可靠性
OpenClaw ⚠ 默认超时/工具太紧（5 个里 4 个超时） · OpenCode ✓ 继承父级 MCP/工具
可发现性
OpenClaw ✕ 藏在文档+配置里 · OpenCode ✓ UI + Prompt 一等公民
自主性
OpenClaw ⚠ 谨慎，行动前先问 · OpenCode ✓ 激进，先干后报告
OpenClaw 的并行能力技术上跟 omo 在 OpenCode 上做的事相当。区别在于 omo 让你没法不用并行，它写死在系统 Prompt 里。OpenClaw 让并行成为可能，但完全隐形。
08 · 勘误
SECTION · 08 · ERRATA RECORD
郑重记录，原文中以下说法是错误的：
ERRATA · 01
「没有子 Agent 编排，没有并行任务执行」
→ OpenClaw 有 sessions_spawn，也有专用子 Agent 队列车道和嵌套编排支持。
ERRATA · 02
「子 Agent：❌ 没有并行 Agent」
→ 应为 ✓，但附注：这是工具级能力，不是 UI 级能力。
HALF RIGHT
「我在正常使用里从来没感觉到并行」这句感受没错。容量是真的，5-subagent 实测也成立；但默认超时和工具配置会让长任务并行变得不可靠，所以你感觉不到它在工作。感觉是对的，归因是错的。
原文其他所有内容——单 Session 默认 UX、FOMO 批评、自主性对比、Token 效率分析——我依然坚持。
测试环境：macOS (Apple Silicon)，OpenClaw（沿用二月以来的同一份本地配置）。并行功能一直在那儿。是我没认真看；当我终于认真看，又在第一个问题背后发现了第二个问题。
关注 gamefatig · /wechat · 邵明鉴 · AI 工程化实践