I Was Wrong About OpenClaw. But Not Completely.

A month ago I published "After OpenCode, OpenClaw Feels Brain-Dead" and said OpenClaw had no sub-agents, no parallel task execution, and was stuck with one session forever. I was wrong about the first two. I stand by the third.

What I Got Wrong

In my original review, I wrote:

"It is NOT a multi-agent system (no sub-agent orchestration, no parallel task execution)"

And in the comparison table:

Sub-agents: ❌ No parallel agents

This was factually incorrect. OpenClaw has had sub-agents since at least v2026.2, and the parallel execution system is actually well-designed. Here's what's been sitting in my config this entire time:

Json

{
  "agents": {
    "defaults": {
      "maxConcurrent": 4,
      "subagents": {
        "maxConcurrent": 8
      }
    }
  }
}

Four concurrent main sessions. Eight parallel sub-agents. It's right there. I just didn't see it.

The Architecture I Missed

OpenClaw's concurrency model is a lane-aware FIFO queue:

Text

┌─────────────────────────────────────────────────┐
│                 Gateway Process                   │
│                                                   │
│  ┌──────────────────┐  ┌──────────────────────┐  │
│  │   Main Lane       │  │   Sub-agent Lane      │  │
│  │  concurrency: 4   │  │  concurrency: 8       │  │
│  │                    │  │                        │  │
│  │  session:main ─►   │  │  subagent:uuid-1 ─►   │  │
│  │  session:work ─►   │  │  subagent:uuid-2 ─►   │  │
│  │  session:proj ─►   │  │  subagent:uuid-3 ─►   │  │
│  │  (queued...)       │  │  ...up to 8 parallel   │  │
│  └──────────────────┘  └──────────────────────────┘  │
└─────────────────────────────────────────────────┘

Each session gets its own lane for serial execution (one run at a time per session), but the global main lane allows up to 4 sessions running in parallel. Sub-agents get a separate lane with 8 slots.

Quick clarification: "main lane = 4" caps concurrently executing main-agent tasks, not the number of sessions you can have. You can keep dozens of sessions sitting around; only 4 actively run at once.

The sessions_spawn tool is the key:

Text

/subagents spawn default "Research the top 5 MCP servers" --model qwen3.5-plus

This fires a non-blocking background agent that:

Runs in its own isolated session
Gets its own context and token budget
Announces results back to the parent when done
Can be killed, inspected, or steered mid-flight

And with maxSpawnDepth: 2, you get an orchestrator pattern:

Text

Main Agent
  └─► Orchestrator Sub-agent (depth 1)
        ├─► Worker A (depth 2)
        ├─► Worker B (depth 2)
        └─► Worker C (depth 2)

The orchestrator can spawn workers up to the lane's available slots — typically up to 7 if the orchestrator itself occupies 1 of the 8. It manages them via sessions_list and sessions_history, then synthesizes their results before announcing back to main. That's genuine multi-agent orchestration.

So Why Didn't I Find It?

Three reasons.

1. The TUI Hides Everything

When you open OpenClaw's TUI (openclaw tui), you get a chat interface. One input box. One conversation. There's no "spawn sub-agent" button. No "parallel tasks" panel. No visual indication that this system exists.Compare that to OpenCode, where sub-agents are a first-class concept in the system prompt — the orchestrator fires explore and librarian agents in the background as naturally as calling grep. The UI shows task IDs, background completions arrive as system notifications.OpenClaw's sub-agents are a tool-level feature, not a UI feature. The model has to decide to use sessions_spawn. And if the model doesn't know it exists (because the system prompt doesn't mention it prominently), it won't use it.

2. The Docs Are Fragmented

I read the OpenClaw docs during my initial review. The homepage talks about "personal AI assistant." The getting-started guide walks you through Telegram setup. The concepts section covers messages, memory, and the command queue.Sub-agents? They're documented under Tools → Sub-Agents, several clicks deep. The queue concurrency model is under Concepts → Command Queue. The orchestrator pattern with maxSpawnDepth is buried in a subsection. You'd have to already know these features exist to find the documentation for them.

3. The Default Config Doesn't Advertise

My config had maxConcurrent: 4 and subagents.maxConcurrent: 8 from day one — the setup wizard put them there. But the wizard never said "hey, you now have parallel execution for up to 8 sub-agents." It just wrote the values and moved on.The feature exists. The config is set. The docs explain it. But nothing in the normal user journey surfaces any of this.

Receipts: I Actually Ran It

A reader could reasonably ask: "Did you just read the config, or did you actually verify the parallel execution works?" Fair question. Here's what I ran tonight.I asked the main agent to research five different coding tools (OpenCode, Claude Code, Cursor, Aider, Continue.dev) in parallel, with explicit instructions to dispatch one sub-agent per tool and refuse to do any research itself before all sub-agents returned.The session list immediately showed five new entries:

Review note: Screenshot pending before final publish. Expected final asset: /images/blog/openclaw-parallel-retraction/openclaw-subagents-2026-04-26.png.

Text

✓ webchat:g-agent-main-c-20260406-011348
  Subagent: research-aider
  Subagent: research-opencode
  Subagent: research-claude-code
  Subagent: research-continue
> Subagent: research-cursor          ← clickable, switchable
  webchat:g-agent-main-main
  openclaw-tui

Five sub-sessions, each with its own context, each switchable from the session dropdown. The pool reported 5/8 slots used. The orchestration is real.But — and this matters — only one of the five (research-cursor) actually completed within timeout. The other four timed out, and the main agent fell back to using web_fetch to fill in the gaps itself. The final report read like a single-agent investigation, because in practice it mostly was.This taught me something my docs-reading didn't: OpenClaw's parallel execution is real, but the sub-agents inherit a constrained tool/timeout profile that makes long-running research unreliable. The capacity is there. The completion rate, in my setup at least, is not.So the corrected story isn't "OpenClaw has parallelism" — it's:

OpenClaw has parallelism. It really spawns. The orchestrator pattern works. But the default sub-agent runtime is brittle enough that you won't feel the parallelism unless you tune timeouts and tool permissions. Which, again, no normal user will discover.

The original review said "no parallel execution." That was wrong. But the spirit of the complaint — I never felt parallelism in normal use — turns out to be partially correct, for a different reason than I originally thought.

What I Still Got Right

Let me be clear: I'm correcting a factual error, not retracting the review.The one-session UX problem is real. Yes, you can have multiple sessions via openclaw tui --session work, and I actually set up aliases for this:

Bash

alias cmain='openclaw tui --session main --thinking high'
alias cwork='openclaw tui --session work --thinking high'
alias cproj='openclaw tui --session project --thinking high'

But the default experience is still one chat thread. The TUI opens agent:main:main and that's your life unless you create your own session management system via shell aliases. There's no session picker, no sidebar, no "New Chat" button that works the way every other AI product does.The autonomy gap is real. My lyrics test stands. Sub-agents don't fix the fundamental issue: OpenClaw's agent loop is more cautious and hand-holdy than OpenCode's. Having 8 parallel sub-agents doesn't help when the parent agent asks "how would you like me to provide the lyrics?" instead of just solving the problem.The FOMO critique is real. Nothing about discovering sub-agents changes the hype ecosystem. 229k stars still measures marketing, not capability. Most articles still sell the dream without mentioning the work required.

The Broader Lesson

I made a mistake that's common in tech reviews: I tested the UI surface and reviewed that, not the underlying system.OpenClaw's UI presents a chat bot. Its config and docs describe a concurrent multi-agent orchestration platform. These are two different products wearing the same name, and you'll only meet the second one if you read the docs cover-to-cover or stumble into the right config keys.This is a design failure, not a capabilities failure. The engineering is solid — lane-aware queues, cascade stops, depth-limited orchestration, configurable tool policies per depth level. The problem is that none of this is discoverable through normal usage.It's like buying a car with a turbo button hidden in the trunk's config file. Turns out the turbo works — but only for a few seconds before it overheats (more on this below). The feature exists. You're still right to complain about both the discoverability and the reliability.

Updated Comparison

In fairness, here's the corrected table:

	OpenClaw	OpenCode
Multi-session	⚠️ Via CLI flags/aliases	✅ Built-in UI
Sub-agents	✅ sessions_spawn (up to 8)	✅ Parallel explore/librarian
Orchestrator pattern	✅ maxSpawnDepth: 2	✅ Via OMOC system prompt
Sub-agent reliability	⚠️ Default timeout/tools too tight (4/5 timed out in my test)	✅ Inherits parent's MCP/tools, completion stable
Discoverability	❌ Hidden in docs + config	✅ First-class in UI + prompt
Autonomy	⚠️ Cautious, asks before acting	✅ Aggressive, acts then reports

OpenClaw's parallel execution is technically comparable to what OMOC does with OpenCode. The difference is that OMOC makes it impossible to not use parallelism — it's baked into the system prompt, the agent fires background tasks automatically. OpenClaw makes it possible but invisible.

Errata

For the record, these claims from my original review were wrong:

~~"no sub-agent orchestration, no parallel task execution"~~ → OpenClaw has sessions_spawn, a dedicated sub-agent queue lane with configurable concurrency, and nested orchestrator support.
~~"Sub-agents: ❌ No parallel agents"~~ → Should be ✅ with the caveat that it's tool-level, not UI-level.
Half-correct: "I never felt parallelism in normal use" → The capacity is real (verified with the 5-subagent test above), but default sub-agent timeouts/tools make long-running parallel tasks unreliable enough that you won't notice them working. The feeling was right; the diagnosis was wrong.

Everything else in the original review — the one-session default UX, the FOMO critique, the autonomy comparison, the token efficiency analysis — I stand by.Tested on: macOS (Apple Silicon), OpenClaw [VERSION TBD — verify before publish], with the same config I've had since February. The parallel features were there the whole time. I just didn't look hard enough — and when I finally did look hard, I found a second problem hiding behind the first.

一个月前我发了篇《用惯了 OpenCode，OpenClaw 真降智》，说 OpenClaw 没有子 Agent、没有并行任务执行、永远只有一个对话。前两条我说错了。第三条我坚持。

我说错了什么

原文里我写道：

"不是多 Agent 系统（没有子 Agent 编排，没有并行任务执行）"

对比表里：

子 Agent：❌ 没有并行 Agent

这是事实性错误。OpenClaw 至少从 v2026.2 就有子 Agent 了，而且并行执行系统设计得其实不错。下面这段一直在我的配置文件里：

Json

{
  "agents": {
    "defaults": {
      "maxConcurrent": 4,
      "subagents": {
        "maxConcurrent": 8
      }
    }
  }
}

4 个并发主 Session。8 个并行子 Agent。就在那儿。我愣是没看到。

我漏掉的架构

OpenClaw 的并发模型是一个分车道的 FIFO 队列：

Text

┌─────────────────────────────────────────────────┐
│                 Gateway 进程                      │
│                                                   │
│  ┌──────────────────┐  ┌──────────────────────┐  │
│  │   主车道          │  │   子 Agent 车道        │  │
│  │  并发数: 4        │  │  并发数: 8             │  │
│  │                    │  │                        │  │
│  │  session:main ─►   │  │  subagent:uuid-1 ─►   │  │
│  │  session:work ─►   │  │  subagent:uuid-2 ─►   │  │
│  │  session:proj ─►   │  │  subagent:uuid-3 ─►   │  │
│  │  (排队中...)       │  │  ...最多 8 个并行      │  │
│  └──────────────────┘  └──────────────────────────┘  │
└─────────────────────────────────────────────────┘

每个 Session 有自己的串行车道（同一时间只跑一个任务），但全局主车道允许最多 4 个 Session 并行运行。子 Agent 有独立车道，8 个槽位。

顺手澄清一下："主车道 = 4" 限的是同时执行的主 Agent 任务数，不是你能开几个 Session。Session 数量没有上限，但同时在跑的最多 4 个。

核心工具是 sessions_spawn：

Text

/subagents spawn default "调研排名前 5 的 MCP 服务器" --model qwen3.5-plus

这会发射一个非阻塞的后台 Agent：

在自己的隔离 Session 里运行
有独立的上下文和 Token 预算
完成后向父级汇报结果
运行中可以被终止、查看或引导

配合 maxSpawnDepth: 2，你可以搭编排模式：

Text

主 Agent
  └─► 编排子 Agent（深度 1）
        ├─► 工人 A（深度 2）
        ├─► 工人 B（深度 2）
        └─► 工人 C（深度 2）

编排 Agent 可以启动的工人数受限于车道剩余槽位——通常最多 7 个（编排器自己占 1 个）。它通过 sessions_list 和 sessions_history 管理工人，汇总结果后再向主 Agent 汇报。这是货真价实的多 Agent 编排。

那我当初为什么没发现？

三个原因。

1. TUI 把一切藏起来了

打开 OpenClaw 的 TUI（openclaw tui），你看到的是一个聊天界面。一个输入框。一段对话。没有"启动子 Agent"按钮。没有"并行任务"面板。没有任何视觉提示告诉你这个系统存在。对比 OpenCode——子 Agent 是系统 Prompt 里的一等公民，编排器像调 grep 一样自然地发射 explore 和 librarian Agent。UI 显示任务 ID，后台完成通知自动弹出。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 了。"它就默默写了值，然后结束了。功能存在。配置已设。文档有写。但在正常使用流程中，没有任何东西让你发现这些。

真凭实据：我亲自跑了一次

读者完全可以追问：「你是只看了配置，还是真的验证过并行能跑？」合理质疑。下面是今晚我实测的结果。我让主 Agent 并行调研五款编程工具（OpenCode、Claude Code、Cursor、Aider、Continue.dev），明确要求每个工具派一个子 Agent，并禁止主 Agent 在子 Agent 全部返回前自己动手。Session 列表瞬间多出了五个：

Review note: 截图待补后再正式发布。最终资产应放在 /images/blog/openclaw-parallel-retraction/openclaw-subagents-2026-04-26.png。

Text

✓ webchat:g-agent-main-c-20260406-011348
  Subagent: research-aider
  Subagent: research-opencode
  Subagent: research-claude-code
  Subagent: research-continue
> Subagent: research-cursor          ← 可点击切换
  webchat:g-agent-main-main
  openclaw-tui

五个子 Session，每个独立上下文，都能从 Session 下拉里切进去。池子报告 5/8 槽位占用。编排是真的。但是——这点很关键——五个里只有一个（research-cursor）在 timeout 内真正完成了。其他四个全部超时，主 Agent 用 web_fetch 兜底填上了空缺。最终那份报告读起来像是单 Agent 调研写的，因为实际上它就基本是单 Agent 写的。这件事教会了我读文档时学不到的事：OpenClaw 的并行执行确实是真的，但子 Agent 继承了一个受限的工具/超时配置，导致长任务调研不可靠。容量在那儿，完成率（至少在我的环境里）不在。所以修正后的故事不是「OpenClaw 有并行」——而是：

OpenClaw 有并行。子 Agent 真的能 spawn。编排模式真能跑。但默认子 Agent 运行时脆到，除非你调超时和工具权限，否则你感觉不到并行。而这个，普通用户照样不会发现。

原文说「没有并行执行」是错的。但抱怨的精神内核——我在正常使用里从来没感觉到并行——结果部分正确，只是原因和我当初以为的不一样。

我说对了什么

澄清一下：我在纠正事实错误，不是撤回评测。单 Session 的 UX 问题是真的。 没错，你可以通过 openclaw tui --session work 创建多个 Session，我确实也设了快捷别名：

Bash

alias cmain='openclaw tui --session main --thinking high'
alias cwork='openclaw tui --session work --thinking high'
alias cproj='openclaw tui --session project --thinking high'

但默认体验还是一个聊天线程。TUI 打开就是 agent:main:main，除非你自己用 shell 别名搭一套 Session 管理系统。没有 Session 选择器，没有侧边栏，没有像其他 AI 产品那样正常工作的"新对话"按钮。自主性差距是真的。 歌词测试结论不变。子 Agent 解决不了根本问题：OpenClaw 的 Agent 循环比 OpenCode 更谨慎、更依赖用户。有 8 个并行子 Agent 没用，如果父 Agent 还是在问"你希望我怎么提供歌词？"而不是直接去解决问题。FOMO 批评是真的。 发现子 Agent 不会改变炒作生态。22 万 Star 依然衡量的是营销，不是能力。大多数文章还是在卖梦，不提需要付出的工作量。

更大的教训

我犯了一个技术评测中很常见的错误：我测试了 UI 表面，然后以此为依据写了评测，而不是测试底层系统。OpenClaw 的 UI 展示的是一个聊天机器人。它的配置和文档描述的是一个并发多 Agent 编排平台。这是两个穿着同一个名字的不同产品，你只有从头到尾读完文档或者偶然发现正确的配置项，才能遇到第二个。这是设计失败，不是能力失败。工程本身是扎实的——分车道队列、级联停止、深度限制编排、按深度配置的工具策略。问题在于，这些在正常使用中完全不可发现。就像买了辆车，发现后备箱里藏了个配置文件能开涡轮模式。涡轮确实能用——但只能撑几秒就过热（这点下面细说）。功能确实存在。但你同时抱怨可发现性和可靠性，依然是对的。

更新后的对比

公平起见，这是修正后的表格：

	OpenClaw	OpenCode
多 Session	⚠️ 需要 CLI 参数/别名	✅ 内置 UI
子 Agent	✅ sessions_spawn（最多 8）	✅ 并行 explore/librarian
编排模式	✅ maxSpawnDepth: 2	✅ 通过 OMOC 系统 Prompt
子 Agent 可靠性	⚠️ 默认超时/工具太紧（实测 5 个里 4 个超时）	✅ 继承父级 MCP/工具，完成率稳定
可发现性	❌ 藏在文档+配置里	✅ UI + Prompt 一等公民
自主性	⚠️ 谨慎，行动前先问	✅ 激进，先干后报告

OpenClaw 的并行执行能力在技术上跟 OMOC 在 OpenCode 上做的事相当。区别在于 OMOC 让你没法不用并行——它写死在系统 Prompt 里，Agent 自动发射后台任务。OpenClaw 让并行成为可能，但完全隐形。

勘误

郑重记录，我原文中以下说法是错误的：

~~"没有子 Agent 编排，没有并行任务执行"~~ → OpenClaw 有 sessions_spawn，有专用子 Agent 队列车道（可配置并发数），有嵌套编排支持。
~~"子 Agent：❌ 没有并行 Agent"~~ → 应该是 ✅，但附注：是工具级的，不是 UI 级的。
半对："我在正常使用里从来没感觉到并行" → 容量是真的（前面 5 子 Agent 实测验证过），但默认超时/工具配置让长任务并行不可靠到——你感觉不到它在工作。我的感觉是对的，归因是错的。

原文其他所有内容——单 Session 默认 UX、FOMO 批评、自主性对比、Token 效率分析——我依然坚持。测试环境：macOS (Apple Silicon)，OpenClaw [VERSION TBD — 发文前确认]，用的还是二月以来的同一份配置。并行功能一直在那儿。是我没认真看——而当我终于认真看的时候，又在第一个问题背后发现了第二个问题。

I Was Wrong About OpenClaw. But Not Completely.

我错怪了 OpenClaw。但也没完全错。

What I Got Wrong

The Architecture I Missed

So Why Didn't I Find It?

1. The TUI Hides Everything

2. The Docs Are Fragmented

3. The Default Config Doesn't Advertise

Receipts: I Actually Ran It

What I Still Got Right

The Broader Lesson

Updated Comparison

Errata

我说错了什么

我漏掉的架构

那我当初为什么没发现？

1. TUI 把一切藏起来了

2. 文档太碎片化

3. 默认配置不做宣传

真凭实据：我亲自跑了一次

我说对了什么

更大的教训

更新后的对比

勘误

For AI Agents

Recent posts