这正是当下 AI agent 平台几乎所有动向底层的那个转变。Prompt 是建议——模型可能尊重它、重新解读它，或者在上下文压力下悄悄无视它。Harness——包裹模型的运行时系统：工具循环、上下文组装、沙箱、权限、预算、追踪——是法律。它是概率核心外圈的确定性代码，决定模型的能力有多少能在真实任务的接触中幸存。

我们刚把 AllClaws 跟踪的全部 34 个平台按四域 harness 框架打完分：核心架构、安全与验证、执行控制与状态、企业集成与协调。完整报告里有 20×10 覆盖矩阵。这篇博客讲的是让我们意外的东西。

每家对可靠性的押注都不一样

把 34 个架构并排读完，第一件事你会发现：没有人就「可靠性从哪来」达成共识。每个平台的押注都不同。

OpenClaw 押路由——一个横跨 37+ channel、吸收复杂性的消息织物。ClawTeam 押编排——TOML 依赖链让 worker 在前置任务完成前根本无法启动。GoClaw 押治理——五层防御、按租户加密、审计日志。IronClaw 押隔离——每个工具调用包进带能力权限的 WASM 沙箱。OpenWorker 押人类——每个后果性动作一道审批门。reasonix 押钱——会话预算到 100% 时拒绝下一轮。LangGraph 押显式状态——类型化图的每个节点都有 checkpoint。

这些押注没有一个是错的。刺眼的是：没有一家覆盖全部四个域。生态没有在收敛于某个 harness 设计——它在并行投机，赌哪个单一控制点最重要。

状态机赢了。预算没来。

按「强实现数量」给各域排成熟度，结果清晰。执行状态——把 agent 运行时当状态机而非孤立 API 调用——是最成熟的能力，9 个强实现。上下文管理 8 个，紧随其后。

状态机故事有两个主角。LangGraph 是教科书版：类型化状态、每节点 checkpoint、human-in-the-loop 建模为图边。但更有意思的是 NanoClaw v2——它把状态机物理实现了：每个会话两个 SQLite 文件——host 写一个，容器写一个——每个文件恰好一个写者，奇偶序号。消息状态和执行状态在存储层分离。当你可以靠查数据库来审计对话时，「黑盒」这个反对意见就开始瓦解。

排名垫底的是预算。两个平台。在有像样 harness 故事的二十家里。

reasonix 是生态中唯一带硬性花费门禁的 CLI——--budget <usd> 在 80% 时警告，100% 时拒绝下一轮。不是警告，是拒绝。配上每次调用可设推理强度的 --effort 旋钮（harness 研究者所说的 Reasoning Compute Sandwich 的实操形态——规划和验证用强推理，中间执行用便宜的），它把 token 经济学当工程约束，而不是事后审的账单。AgentScope 把预算做成可组合的循环 middleware——同一想法的程序化版本。

那个最能预测 agent 能否在生产环境无人值守存活的能力，只有两个实现。生态早就解决了「别崩溃」，还没解决「别超支」。

危险的缺口：没人验证声明

这个发现应该让所有人不安。

我们今年早些时候的失败模式研究把 Silent Success（静默成功） 识别为生产 agent 最危险的失败：agent 报告任务完成，输出是错的或从未执行，用户信任了报告。解药是验证钩子——对声明而非动作的独立检查。

全部被跟踪平台中，有近似机制的只有四家。而运行独立审计模型来检验主 agent 产出的，一家都没有。

现有的机制拦的是别的东西。审批门（OpenWorker）在动作发生前拦动作——人类审命令。权限钩子（AgentScope 的 on_check_permission）以程序化方式拦未授权调用。审计日志（GoClaw）事后记录发生了什么。都有价值。没有一个回答那个真正要紧的问题：agent 的成功报告是真的吗？

不对称是结构性的。模型被训练得乐于助人；被问「你做了 X 吗？」时，先验答案是「是」。一个从不独立验证产出的 harness，对这种先验毫无防御。四域框架要求一个独立的审计模型来裁决输出。在被跟踪的平台里它不存在。这是生态最危险的洞，也是一片空旷的市场。

应验的预测，和没应验的

harness 框架给了一个具体的成本预测：子 agent 团队应该共享 KV cache——主 agent 和 worker 复用相同的已计算 prompt 前缀——让编排变得便宜。我们去找了。

它不存在。34 个平台里一个都没有。最近的邻居是 reasonix 的 cache-first 循环——规范化 prompt 以最大化 DeepSeek 上下文缓存命中——但只在单会话内，从不跨 agent。ClawTeam 的公开数据（5 个并行 agent 约 3 小时完成全栈应用，对比串行 8 小时以上，token 成本相同）纯靠并行达成。跨 agent 缓存共享是明晃晃摆在那里的未兑现价值。

有一个相关性成立，但框架里没写：语言预测 harness 哲学。Rust 平台（IronClaw、ZeroClaw、codex、OpenFang）把 harness 表达为运行时属性——沙箱、确定性、estop 紧急停止命令。Python 平台（Hermes、Nanobot、AgentScope）把它表达为循环结构——middleware、压缩引擎、AgentLoop/AgentRunner 分离。Go 平台（GoClaw、HiClaw）把它表达为基础设施——lane-based 调度器、Kubernetes 风格控制面。你用什么语言构建，决定了你甚至能看见哪些 harness 问题。

未探索的中间地带

门禁哲学最深的分裂，跑在「全部人类侧把关」和「全部机器侧把关」之间。OpenWorker 和 NanoClaw 的 guard seam（allow / hold / deny，还有别处不存在的自我修改防护）在每个后果性步骤放上人类或硬规则。GoClaw 的 RBAC 和 IronClaw 的能力系统把权限编码为机器强制执行的策略。

两者之间躺着一块未开发的设计空间：概率模型由概率裁判验证，只在两者分歧时才触发确定性门禁。一个审计模型读主 agent 的产出、挑战它、只在冲突时升级给人类。它会把个人范式的自主性和企业范式的保证结合起来。没有被跟踪的平台在做它。

补上验证缺口的平台——不是靠更大的模型或更好的 prompt，而是靠检查工作的 harness 代码——才是能从「令人惊艳」毕业到「值得信任」的那些。harness 才是发生这件事的地方。prompt 从来都不是。

本文基于完整研究报告：Harness Engineering Comparison: Philosophy, Design, and Features Across Tracked Platforms，含 20×10 覆盖矩阵与各平台评级。

English version

That’s the shift underneath almost everything happening in AI agent platforms right now. The prompt is a suggestion — the model may honor it, reinterpret it, or quietly ignore it under context pressure. The harness — the runtime system wrapping the model: tool loops, context assembly, sandboxes, permissions, budgets, traces — is law. It’s deterministic code around a probabilistic core, and it decides how much of the model’s capability survives contact with a real task.

We just finished grading all 34 platforms AllClaws tracks through a four-area harness framework: core architecture, safety and verification, execution control and state, and enterprise integration. The full report has a 20×10 coverage matrix. This post is about what surprised us.

Everyone Bets Differently on Reliability

The first thing you notice reading 34 architectures side by side: nobody agrees on where reliability comes from. Every platform makes a different bet.

OpenClaw bets on routing — a message fabric that absorbs complexity across 37+ channels. ClawTeam bets on orchestration: TOML dependency chains mean a worker literally cannot start before its prerequisites finish. GoClaw bets on governance — a five-layer defense with per-tenant encryption and audit logs. IronClaw bets on isolation, wrapping every tool call in a WASM sandbox with capability permissions. OpenWorker bets on humans: an approval gate on every consequential action. reasonix bets on money — a session budget that refuses the next turn at 100% spent. LangGraph bets on explicit state, checkpointing every node of a typed graph.

None of these bets is wrong. What’s striking is that none of them covers all four areas. The ecosystem isn’t converging on a harness design — it’s speculating, in parallel, on which single control point matters most.

State Machines Won. Budgets Didn’t Arrive.

Measuring coverage by strong implementations per area produced a clear maturity ranking. Execution state — treating the agent runtime as a state machine rather than isolated API calls — is the most mature capability, with nine strong implementations. Context management follows at eight.

The state-machine story has two protagonists. LangGraph is the textbook version: typed state, checkpointed at every node, human-in-the-loop modeled as graph edges. But the more interesting one is NanoClaw v2, which implements the state machine physically: every session gets two SQLite files — one the host writes, one the container writes — with exactly one writer per file and even/odd sequence numbers. Message state and execution state are separated at the storage layer. When you can audit the conversation by querying a database, the “black box” objection starts to dissolve.

At the bottom of the ranking: budgeting. Two platforms. Out of twenty with meaningful harness stories.

reasonix is the only CLI in the ecosystem with a hard spend gate — --budget <usd> warns at 80% and refuses the next turn at 100%. Not a warning. A refusal. Paired with an --effort dial that sets reasoning intensity per invocation (the practical form of what harness researchers call the Reasoning Compute Sandwich — strong reasoning for planning and verification, cheap execution in between), it treats token economics as an engineering constraint rather than an invoice to be reviewed afterward. AgentScope ships budget as composable loop middleware, the programmatic version of the same idea.

Two implementations of the capability that most directly predicts whether an agent survives production unsupervised. The ecosystem solved “don’t crash” long before “don’t overspend.”

The Dangerous Gap: Nobody Verifies Claims

Here is the finding that should worry everyone.

Our failure-mode research earlier this year identified Silent Success as the most dangerous failure in production agents: the agent reports a task complete, the output is wrong or never executed, and the user trusts the report. The cure is a verification hook — an independent check on the claim, not the action.

Across all tracked platforms, four have any mechanism approaching this. And zero platforms run an independent auditing model over the main agent’s output.

What exists instead catches different things. Approval gates (OpenWorker) catch actions before they happen — a human reviews the command. Permission hooks (AgentScope’s on_check_permission) catch unauthorized calls programmatically. Audit logs (GoClaw) record what happened, after the fact. All valuable. None of them answers the question that matters: is the agent’s report of success true?

The asymmetry is structural. Models are trained to be helpful; when asked “did you do X?”, the prior is “yes.” A harness that never independently verifies outcomes has no defense against that prior. The four-area framework calls for a separate auditing model judging outputs. It exists in no tracked platform. This is the ecosystem’s most dangerous hole, and it is an open market.

The Prediction That Came True (and the One That Didn’t)

The harness framework makes a specific cost prediction: sub-agent teams should share KV caches — the master agent and its workers reusing the same computed prompt prefixes — to make orchestration cheap. We went looking for it.

It doesn’t exist. Not in one platform out of thirty-four. The nearest neighbor is reasonix’s cache-first loop, which canonicalizes prompts to maximize DeepSeek context-cache hits — but within a single session, never across agents. ClawTeam’s published numbers (five parallel agents finishing a full-stack app in ~3 hours versus 8+ sequential, at the same token cost) were achieved by parallelism alone. Cross-agent cache sharing is unrealized value sitting in plain sight.

One correlation did hold, and it wasn’t in the framework: language predicts harness philosophy. Rust platforms (IronClaw, ZeroClaw, codex, OpenFang) express the harness as runtime properties — sandboxes, determinism, an estop emergency-stop command. Python platforms (Hermes, Nanobot, AgentScope) express it as loop structure — middleware, compaction engines, the AgentLoop/AgentRunner split. Go platforms (GoClaw, HiClaw) express it as infrastructure — lane-based schedulers, Kubernetes-style control planes. The language you build in shapes which harness problems you can even see.

The Unexplored Middle

The deepest split in gating philosophy runs between gating everything human-side and gating everything machine-side. OpenWorker and NanoClaw’s guard seam (allow / hold / deny, with self-modification guards that exist nowhere else) put humans or hard rules at every consequential step. GoClaw’s RBAC and IronClaw’s capability system encode permissions as machine-enforced policy.

Between them lies an unexplored design: probabilistic models verified by probabilistic judges, with deterministic gates engaged only when they disagree. An auditing model that reads the main agent’s output, challenges it, and escalates to a human gate only on conflict. It would combine the autonomy of the personal paradigm with the assurance of the enterprise one. No tracked platform builds it.

The platforms that close the verification gap — not with bigger models or better prompts, but with harness code that checks the work — are the ones that will graduate from impressive to trustworthy. The harness is where that happens. The prompt never was.

This analysis is based on the full research report: Harness Engineering Comparison: Philosophy, Design, and Features Across Tracked Platforms, including the 20×10 coverage matrix and per-platform grades.

在本机所有可安装的 CLI 上运行了 --help、并阅读了无法安装的那些的源代码之后，这里是一份关于 17 个 AI agent 平台如何向用户展示能力的结构化对比——以及这些选择揭示了怎样的设计哲学。

方法论

我从本机安装的五个平台（Hermes、kimi-cli、zeroclaw、opencode、reasonix）抓取了活的 --help 输出，并从 AllClaws 架构文档跟踪的其余平台的源代码和文档中提取了 CLI 架构细节。每个平台的条目涵盖：

• 命令名：你输入什么来启动它
• 子命令数量：有多少个不同的命令可用
• 调用模式：REPL、TUI、one-shot、pipe 友好等
• 配置方式：标志、配置文件、交互式设置
• 运维命令：cron、监控、调试、备份
• 会话管理：恢复、历史、导出

对比

1. Hermes-Agent (hermes)

Hermes 拥有所有被跟踪平台中最庞大的 CLI。运行 hermes --help 会产出约 14,000 字符的输出，覆盖 81 个位置子命令和数十个标志。

调用模式：

• hermes — 经典 REPL（prompt_toolkit）
• hermes --tui — 现代终端 UI
• hermes -z "prompt" — One-shot 模式（仅 stdout，无 banner，无 spinner，面向脚本/管道）
• hermes -w — 隔离的 git worktree 模式（用于并行 agent）
• hermes -s skill1,skill2 — 预加载技能

按类别分组的关键子命令：

设计哲学： “一切皆子命令。” Hermes 把 CLI 当作每个功能的主接口——消息、调度、技能、记忆、监控、桌面 GUI、MCP 服务器、安全审计。CLI 就是控制平面。不存在”面向用户的功能”与”管理员功能”之分——全在一个命名空间里。

值得关注的设计选择：

• -z one-shot 模式只把最终响应写入 stdout（管道友好，CI 兼容）
• --usage-file 用于脚本化运行的成本追踪
• --safe-mode 禁用所有自定义（排障用）
• --yolo 绕过所有审批 prompt
• --worktree 为并行 agent 创建隔离的 git worktree
• ACP 服务器模式（hermes acp）用于 IDE 集成

2. OpenClaw (openclaw)

OpenClaw 的 CLI 无法直接测试（npm 二进制启动的 TUI 在 WSL 里超时），但架构文档揭示了它的结构。

架构：

• 入口在 src/cli，命令在 src/commands
• 单 agent 架构 + channel/插件扩展
• 37+ 消息 channel（Telegram、Discord、Slack、Signal、iMessage、Web 等）
• 用于额外平台（MSTeams、Matrix）的扩展系统

设计哲学： “成为 channel。” OpenClaw 本质上是一个路由平台——它从任何 channel 接收输入，通过 AI agent 处理，再输出到任何 channel。CLI 是众多 channel 之一，而不是主要的那个。架构上 src/provider-web.ts 和 src/routing 的分量重过 src/commands。

CLI 性格： 极简而聚焦。OpenClaw 的 CLI 的存在是为了配置 channel、启动 agent 循环、管理插件。它不试图成为通用控制平面。37+ 个 channel 才是差异化所在，不是命令数量。

3. ClawTeam (clawteam)

ClawTeam 的 CLI 是所有平台中最领域特定的——每个子命令都映射到一个多代理工作流概念。

关键子命令组：

设计哲学： “编排 agent，而不是成为 agent。” ClawTeam 的 CLI 是团队管理接口，不是 agent 聊天接口。你不通过 ClawTeam 与 AI 对话——你生成一个互相交谈的 agent 团队。CLI 子命令映射工作流：建团队、定义任务、看板、合并结果。

值得关注： 使用 TOML 团队模板（clawteam launch hedge-fund --team fund1）实现可复现的团队配置。ZeroMQ P2P 选项用于跨机器协调。kanban 看板（board live）提供所有 agent 的 tmux 平铺视图。

4. GoClaw (goclaw)

GoClaw 的 CLI 反映了它作为网关服务器的身份——主命令启动网关，子命令管理周边基础设施。

推断的 CLI 结构（来自 cmd/ 模块分析）：

• 网关启动（主命令——WS + HTTP 服务器）
• Onboarding 向导
• 迁移工具
• 配置管理（JSON5 + 环境变量）

设计哲学： “单一二进制，全栈。” GoClaw 以一个约 25MB 的 Go 二进制交付，内含网关服务器、agent 循环、提供商集成和管理工具。CLI 是部署工具。你运行 goclaw 启动网关，然后通过 Web 仪表盘、WebSocket RPC 或 HTTP API（/v1/chat/completions、/v1/agents、/v1/skills）与 agent 交互。

CLI 性格： 面向基础设施。与 Hermes（一切皆子命令）或 ClawTeam（编排即子命令）不同，GoClaw 的 CLI 关注部署和配置。agent 交互发生在网关的 RPC 和 HTTP 接口上，而不是 CLI 子命令里。这与它的企业定位一致——你不会 SSH 到生产服务器上跟 agent 聊天。

5. IronClaw (ironclaw)

IronClaw 的 CLI 架构强调安全原语和沙箱管理。

Channel 结构：

• REPL（主要交互方式）
• HTTP webhook
• WASM channel（动态工具加载）
• Web 网关（SSE/WebSocket）

设计哲学： “安全第一，CLI 只是众多 channel 之一。” IronClaw 把 REPL 当作与 HTTP webhook 和 WASM channel 并列的 channel——不是主接口。架构重心在沙箱编排器（Docker）、工具注册表（内置 + MCP + WASM）和安全层（prompt 注入防御、宿主边界的凭据注入）。

6. ZeroClaw (zeroclaw)

ZeroClaw 拥有所有平台中最一致的 CLI——干净、结构良好、基于 Rust clap 的帮助输出，每个子命令都带示例。

子命令（22 个）：

设计哲学： “快、小、完整。” ZeroClaw 的 CLI 胜在平衡——22 个子命令覆盖完整 agent 生命周期（onboarding、agent 循环、daemon、调度、技能、硬件、监控），没有 Hermes 81+ 命令的蔓延。每个子命令的 --help 输出都带示例。

值得关注的设计选择：

• agent -m "prompt" 单次执行，不进入交互模式
• estop 紧急停止 daemon 和 channel
• 硬件外设支持（STM32、RPi GPIO）——生态中独此一家
• daemon 是一等命令（网关 + channel + 心跳 + 调度器作为单一长驻进程）

7. OpenCode (opencode)

OpenCode 是”开源编程 agent”——TUI 优先的编程助手，支持 ACP 和 MCP，外加独特的 headless 服务器模式用于远程协作。

子命令（21 个）：

调用模式：

• opencode — 启动 TUI（默认）
• opencode run "prompt" — 带消息运行（非交互）
• opencode serve — headless 服务器
• opencode web — 服务器 + 浏览器 UI
• opencode attach <url> — 连接远程服务器
• opencode --mini — 最小交互界面
• opencode -c / -s <id> — 继续上一个或指定会话

值得关注的设计选择：

• --fork 在继续会话时 fork（从先前状态分叉）
• --pure 不加载外部插件运行
• --mdns 用于局域网 mDNS 服务发现（找到运行中的实例）
• --cors 用于 headless 服务器的跨域配置
• --auto 自动批准所有未被显式拒绝的权限（文档明示危险的模式）
• --port / --hostname 显式绑定服务器；--mdns-domain 自定义发现域名
• --replay-limit 限制 mini 模式恢复时的会话回放条数
• pr <number> 拉取 GitHub PR 分支后启动 TUI——其他平台没有的工作流专属命令
• stats 把 token 用量和成本追踪作为一等命令

设计哲学： “TUI 优先，服务器可选。” OpenCode 的默认体验是 TUI，但它独特地同时提供 headless serve 模式和带浏览器 UI 的 web 模式。attach <url> 命令和 mDNS 发现暗示了一个同时支持本地开发和远程协作的设计——你可以在服务器上运行 opencode，从笔记本 attach 上去。pr 命令把 GitHub 工作流接进 agent 循环，把 PR 审查当作一等用例。

8. Nanobot (nanobot)

Nanobot 把”超轻量”哲学带进了 CLI 设计。

架构：

• CLI 用 Python Typer（从类型提示自动生成帮助）
• 单 agent + subagent 支持
• 8+ channel（Telegram、Discord、Slack、WhatsApp、飞书、QQ、Email、Matrix、CLI）
• MCP 桥接（可用但非核心）
• LiteLLM 多提供商支持

设计哲学： “一条命令，一个 agent。” Nanobot 的 CLI 是极简的，因为平台本身就是极简的（核心约 4,000 行）。Typer 从类型注解自动提供良好的帮助输出。重心在 pip install nanobot-ai 和开箱即用，而不是全面的子命令覆盖。

9. Maxclaw (maxclaw)

Maxclaw 交付两个二进制——一个给 agent，一个给网关。

架构：

• cmd/main.go — agent CLI，支持子会话生成
• maxclaw-gateway — 独立网关二进制
• 桌面 UI + Web UI 同端口
• Monorepo 上下文发现（AGENTS.md、CLAUDE.md）
• 分层记忆（MEMORY.md、HISTORY.md、heartbeat.md）

设计哲学： “本地优先，配视觉界面。” Maxclaw 独特地把桌面 UI 和 Web UI 绑定在同一端口。CLI 是与视觉界面并列的一种界面。子会话生成让单个 maxclaw 实例内可以跑并行 agent。

10. NanoClaw (nanoclaw)

NanoClaw 是最以容器为中心的平台——它的”CLI”本质上是一个编排器进程。

架构：

• 单 Node.js 编排器进程
• Claude Agent SDK 在每组隔离容器中运行
• 每组一个 CLAUDE.md 作为记忆
• IPC watcher 用于进程间通信
• 任务调度器
• WhatsApp 作为主 channel

设计哲学： “容器，而非命令。” NanoClaw 的 CLI 是一个生成容器化 agent 实例的 IPC 编排器。”命令”就是容器生命周期管理——启动、停止、监控。传统意义上的 REPL 不存在；你通过 WhatsApp 群组交互，每个群组一个隔离在自己容器里的 Claude agent。

11. HiClaw (hiclaw)

HiClaw 是唯一使用 Kubernetes 风格声明式资源的平台。

架构：

• hiclaw CLI 配 Docker Compose
• YAML 资源定义（Worker、Team、Human）
• Worker 模板市场
• 基于 Nacos 的技能发现
• Manager-Workers 运行时（CoPaw）

设计哲学： “给 agent 的声明式基础设施。” HiClaw 的 CLI 最接近 kubectl——你把 worker、team 和 human-in-the-loop 资源定义为 YAML 文件然后 apply。CLI 管理资源生命周期而非 agent 交互。这是企业自动化范式推到逻辑终点：agent 就是 Kubernetes 资源。

12. Hermes-Agent（源码分析 vs 实测抓取）

架构文档把 Hermes 描述得比实测 --help 揭示的更简单。文档记的是：

• 入口：hermes CLI
• 架构：带上下文管理的单 agent
• MCP 原生集成

实测 CLI（v0.20.0）展示的是一个远超”带上下文管理的单 agent”的平台——一个完整的 agent 操作系统，81+ 子命令横跨消息、调度、技能、记忆、监控、桌面 GUI 和 MCP 服务器管理。

13. aider (aider)

aider 是最聚焦的 CLI——它只做一件事（AI 编辑代码），并通过聊天界面完成。

架构：

• REPL 结对编程循环
• git 感知（用合理的 message 自动提交）
• 编辑模式：Whole Edit、Diff Edit、Architect
• Repo Map 用于大代码库上下文
• 20+ LLM 提供商

设计哲学： “结对编程，不是平台。” aider 没有调度、技能、消息或监控的子命令。它是一个带 git 集成的聊天循环。你说，它改代码，git 提交结果。极简就是重点——68K 星来自把一件事做到极致。

14. Claude Code (claude)

Claude Code 是 Anthropic 官方 CLI 编程 agent。无法从 WSL 直接测试（启动的 TUI 会超时）。

架构：

• 终端编程 agent
• ACP 协议支持
• 沙箱执行
• 交互式审批循环

设计哲学： “Anthropic 的终端 agent。” Claude Code 是 Anthropic 终端 AI 编程愿景的参考实现。它遵循极简 CLI 表面的模式——你运行 claude，它开启会话，你写代码。简单是刻意为之。

15. kimi-cli (kimi-cli)

来自 MoonshotAI 的 kimi-cli，相对其子命令数量，拥有所有平台中选项最密集的帮助输出。

调用模式：

• kimi-cli — 交互 agent（默认）
• kimi-cli -p "prompt" / -c "prompt" — 单次 prompt
• kimi-cli --print — 打印模式（非交互，隐含 --yolo）
• kimi-cli --quiet — --print --output-format text --final-message-only 的简写
• kimi-cli --acp — ACP 服务器模式（已弃用，现为 kimi-cli acp）
• kimi-cli --wire — Wire 服务器（实验性）

子命令（9 个）：

值得关注的设计选择：

• --agent [default|okabe] 和 --agent-file FILE 用于自定义 agent 规格
• --input-format [text|stream-json] 和 --output-format [text|stream-json] 用于管道集成
• --mcp-config-file FILE（可重复）用于多个 MCP 配置
• --skills-dir DIRECTORY 用于技能发现
• --thinking / --no-thinking 推理模式开关
• --max-steps-per-turn、--max-retries-per-step、--max-ralph-iterations 细粒度控制

设计哲学： “可配置的 agent，多界面。” kimi-cli 提供所有平台中最细粒度的每次调用配置。agent 行为的每个方面都可以通过标志调——模型、思考模式、步数上限、重试上限、MCP 配置、agent 规格、技能目录。三种界面模式（交互、print、wire/ACP）加上 agent 追踪可视化（vis），暗示这是一个同时为终端用户编程和开发者工具链设计的平台。

16. Codex (codex)

OpenAI 的 Codex 是星标最多的 CLI agent，也是架构上最简单的。

架构：

• 简单的 CLI → LLM → shell 执行循环
• 沙箱执行（所有代码在隔离环境中运行）
• 单二进制，零运行时开销
• 模型：GPT-4o、o3、o4-mini

设计哲学： “单二进制，单循环。” Codex 是反 Hermes。一条命令，一个循环，沙箱执行，完事。没有技能、调度、消息或监控的子命令。沙箱是差异化所在——每次代码执行都是隔离的，对 CI/CD 管道是安全的。

17. Reasonix (reasonix / dsnix)

Reasonix（esengine/DeepSeek-Reasonix）是”DeepSeek 原生编程 agent”——也是本次对比中唯一拥有两个命令名的平台：reasonix 和 dsnix 指向同一个二进制。它的 CLI 哲学围绕一个经济性理念构建：DeepSeek 的上下文缓存。子命令的存在就是为了让缓存命中率可见、可干预。

子命令（19 个）：

设计哲学： “成本是一等公民。” Reasonix 是这里唯一把会话美元预算内置到调用里的 CLI：--budget <usd> 在 80% 时警告，100% 时拒绝下一轮（不只是警告——是硬门禁）。chat TUI 在你输入时显示实时缓存命中/成本面板，stats 把历史转录稿变成使用仪表盘，doctor-cache 是专门针对缓存稳定性的健康检查。kimi-cli 让每个行为可配置，Reasonix 让每个成本维度可见：预算上限、按转录稿记账、缓存健康。它是 kimi-cli 配置优先设计的经济学优先对照。

值得关注的设计选择：

• --budget <usd> — 每会话花费上限，80% 警告，100% 硬拒绝
• --effort low|medium|high|max — 每种调用模式都有的推理强度旋钮
• --no-mouse — 关闭 SGR 鼠标跟踪，恢复终端原生拖选（其他 CLI 都没处理的痛点）
• --no-proxy — 单次运行绕过代理，适合 GFW 邻近网络
• --dashboard-port / --dashboard-host — 内嵌 Web 仪表盘的固定端口 + 局域网绑定（SSH 隧道友好）
• --mcp <spec> 可重复，配 --mcp-prefix 给工具名加命名空间
• --profile — 记录 V8 CPU profile，用于性能 bug 报告
• 双语帮助输出（中文描述 + 英文命令名）
• diff <a> <b> — 唯一能分栏对比两份 agent 转录稿的 CLI
• code 上的 dry-run 标志用于 ssh:// 目标——解析 URI、检查本地 SSH、打印计划步骤，不执行任何远程命令

交叉引用： Reasonix 实现了 one-shot（run）、TUI（chat）、ACP 服务器（acp）、MCP 管理（mcp）、会话恢复（-c/-r）和自更新（update）——与 Hermes 和 OpenCode 相同的六个能力点，代码量只是零头。

跨平台分析

子命令数量光谱

Hermes       ████████████████████████████████████████████  81+
OpenCode     ████████████████████████  21
ZeroClaw     ██████████████████  22
Reasonix     ██████████████████  19
kimi-cli     ████████  9
ClawTeam     ████████  ~8 组
GoClaw       █████  ~5
codex        ██  1-2
aider        ██  1

调用模式矩阵

配置方式

运维命令覆盖

CLI 揭示的平台哲学

Unix 哲学光谱

Hermes 在一个极端：”一切通过 CLI。” 81+ 子命令，每个功能都暴露，从 hermes dashboard 到 hermes pets。CLI 即平台。

Codex 和 aider 在另一个极端：”通过 CLI 只做一件事。” 聊天循环，git 集成，完事。CLI 是核心 agent 循环外面的一层薄壳。

ZeroClaw 和 kimi-cli 占据中间地带：足够覆盖 agent 生命周期（调度、技能、监控）的子命令，没有蔓延。ZeroClaw 的 22 个命令和 kimi-cli 的 9 个命令 + 丰富标志集，暗示一种刻意的设计约束——足够有用，不至于令人不知所措。

“操作系统”与”工具”的分野

Hermes、ZeroClaw 和 GoClaw 表现得像 agent 的操作系统——它们管理完整生命周期：安装、配置、调度、监控、调试、备份、更新。它们的 CLI 反映了这一点：doctor、backup、update、migrate、estop。

aider、codex 和 Claude Code 表现得像工具——需要时运行，做完工作，退出。没有 daemon，没有调度器，没有备份。它们的 CLI 反映了这一点：表面极简，交互聚焦。

ClawTeam 占据独特位置：它是其他 agent 的操作系统，不是自己的。它的 CLI 管理 aider/Codex/OpenClaw 实例的团队。它没有 AI 聊天循环——它有的是团队生命周期管理。

收敛模式

三种 CLI 模式正在生态中收敛：

1. One-shot 模式（Hermes -z、kimi-cli --print、ZeroClaw -m）——每个平台最终都会为脚本和 CI 集成添加非交互模式。

2. ACP/Wire 协议（Hermes acp、kimi-cli acp/--wire、copilot-cli ACP）——Agent Communication Protocol 正在成为 IDE 集成的标准，kimi-cli 在 wire 协议实验上领先。

3. MCP 配置成为 CLI 职责（Hermes mcp、kimi-cli mcp、GoClaw adapter）——管理 MCP 服务器正在成为一等 CLI 操作，不再只是配置文件的事。

缺失的命令

每个平台都缺了点什么：

• aider 和 codex 没有调度。你不能说”每天早上跑这个编程任务”。它们是纯交互的。
• ClawTeam 没有凭据管理 CLI。凭据在 TOML 文件或环境变量里。
• GoClaw 没有备份/恢复。企业基础设施被假定由外部管理。
• Hermes 没有 one-shot 纯打印模式下同时输出 JSON 的能力（kimi-cli 的 --output-format stream-json 更管道友好）。
• ZeroClaw 没有会话恢复。每次 agent 调用都是全新的。
• kimi-cli 尽管有最丰富的每次调用配置，却没有 cron 或调度。
• Reasonix 没有调度，也没有 shell 补全。它的成本工具无可匹敌，但你说不了”每天早上跑这个”——预期模式是用系统 cron 驱动它的 run one-shot。

结论

CLI 是一个平台最诚实的接口。文档可以夸大能力。营销可以误导。但 --help 输出是用户实际看到的，它揭示了真实的优先级：

• Hermes 优先完整性——每个功能都有命令
• ZeroClaw 优先一致性——每个命令都有示例和干净的帮助
• kimi-cli 优先可配置性——每次调用都可以精细调校
• OpenCode 优先远程协作——serve、attach、mDNS 发现
• aider 优先聚焦——一个循环，做到极致
• codex 优先安全——单二进制，沙箱，极简
• ClawTeam 优先编排——命令面向团队，而非聊天
• GoClaw 优先基础设施——命令面向部署，而非交互
• Reasonix 优先经济学——每次调用都有预算上限和缓存可见性

2026 年最好的 CLI 会把 Hermes 的完整性、ZeroClaw 的一致性、kimi-cli 的可配置性、OpenCode 的远程协作和 Reasonix 的成本纪律结合起来。还没有人做到全部五点。

实测 CLI 抓取自 Hermes v0.20.0、OpenCode v1.18.18、kimi-cli v1.24.0、zeroclaw v0.1.7、reasonix v0.52.0。架构文档来自覆盖所有被跟踪平台的 AllClaws 平台对比。完整架构细节见 platform_comparison.md。

English version

After running --help on every available CLI and reading the source code of the ones we couldn’t install, here is a structured comparison of how 17 AI agent platforms present their capabilities to users — and what those choices reveal about their design philosophy.

Methodology

I captured live --help output from five platforms installed on this system (Hermes, kimi-cli, zeroclaw, opencode, reasonix), and extracted CLI architecture details from source code and documentation for the remaining platforms tracked in the AllClaws architecture docs. Each platform’s entry covers:

• Command name: What you type to start it
• Subcommand count: How many distinct commands are available
• Invocation modes: REPL, TUI, one-shot, pipe-friendly, etc.
• Configuration approach: Flags, config files, interactive setup
• Operational commands: Cron, monitoring, debugging, backup
• Session management: Resume, history, export

The Comparison

1. Hermes-Agent (hermes)

Hermes has the most extensive CLI of any platform tracked. Running hermes --help produces ~14,000 characters of output covering 81 positional subcommands and dozens of flags.

Invocation modes:

• hermes — Classic REPL (prompt_toolkit)
• hermes --tui — Modern terminal UI
• hermes -z "prompt" — One-shot mode (stdout only, no banner, no spinner, intended for scripts/pipes)
• hermes -w — Isolated git worktree mode (for parallel agents)
• hermes -s skill1,skill2 — Preload skills

Key subcommands by category:

Design philosophy: “Everything is a subcommand.” Hermes treats its CLI as the primary interface to every feature — messaging, scheduling, skills, memory, monitoring, desktop GUI, MCP servers, security audit. The CLI is the control plane. There is no distinction between “user-facing features” and “admin features” — it’s all one namespace.

Notable design choices:

• -z one-shot mode writes only final response to stdout (pipe-friendly, CI-compatible)
• --usage-file for cost tracking in scripted runs
• --safe-mode disables all customizations (troubleshooting)
• --yolo bypasses all approval prompts
• --worktree creates an isolated git worktree for parallel agents
• ACP server mode (hermes acp) for IDE integration

2. OpenClaw (openclaw)

OpenClaw’s CLI was not directly testable (the npm binary launches a TUI that times out from WSL), but the architecture docs reveal its structure.

Architecture:

• Entry point via src/cli, commands in src/commands
• Single-agent architecture with channel/plugin extensions
• 37+ messaging channels (Telegram, Discord, Slack, Signal, iMessage, Web, etc.)
• Extensions system for additional platforms (MSTeams, Matrix)

Design philosophy: “Be the channel.” OpenClaw is fundamentally a routing platform — it takes input from any channel, processes it through an AI agent, and outputs to any channel. The CLI is one of many channels, not the primary one. The architecture emphasizes src/provider-web.ts and src/routing over src/commands.

CLI character: Minimal and focused. OpenClaw’s CLI exists to configure channels, start the agent loop, and manage plugins. It does not attempt to be a general-purpose control plane. The 37+ channels are the differentiator, not the command count.

3. ClawTeam (clawteam)

ClawTeam’s CLI is the most domain-specific of any platform — every subcommand maps to a multi-agent workflow concept.

Key subcommand groups:

Design philosophy: “Orchestrate agents, don’t be one.” ClawTeam’s CLI is a team management interface, not an agent chat interface. You don’t talk to an AI through ClawTeam — you spawn a team of agents that talk to each other. The CLI subcommands mirror the workflow: create a team, define tasks, watch the board, merge the results.

Notable: Uses TOML team templates (clawteam launch hedge-fund --team fund1) for reproducible team configurations. ZeroMQ P2P option for cross-machine coordination. The kanban board (board live) provides a tmux tiled view of all agents simultaneously.

4. GoClaw (goclaw)

GoClaw’s CLI reflects its identity as a gateway server — the primary command launches the gateway, and subcommands manage the infrastructure around it.

Inferred CLI structure (from cmd/ module analysis):

• Gateway startup (primary command — WS + HTTP server)
• Onboarding wizard
• Migration tools
• Configuration management (JSON5 + env vars)

Design philosophy: “Single binary, full stack.” GoClaw ships as one ~25MB Go binary that includes the gateway server, agent loop, provider integrations, and management tools. The CLI is the deployment tool. You run goclaw to start the gateway, then interact with agents through the web dashboard, WebSocket RPC, or HTTP API (/v1/chat/completions, /v1/agents, /v1/skills).

CLI character: Infrastructure-oriented. Unlike Hermes (which exposes everything as subcommands) or ClawTeam (which exposes orchestration as subcommands), GoClaw’s CLI is about deployment and configuration. The agent interaction happens through the gateway’s RPC and HTTP interfaces, not through CLI subcommands. This is consistent with its enterprise focus — you don’t SSH into a production server to chat with an agent.

5. IronClaw (ironclaw)

IronClaw’s CLI architecture emphasizes security primitives and sandbox management.

Channel structure:

• REPL (primary interaction)
• HTTP webhooks
• WASM channels (dynamic tool loading)
• Web gateway (SSE/WebSocket)

Design philosophy: “Security first, CLI as one of many channels.” IronClaw treats the REPL as a channel alongside HTTP webhooks and WASM channels — not as the primary interface. The architecture emphasizes the sandbox orchestrator (Docker), tool registry (built-in + MCP + WASM), and safety layer (prompt injection defense, credential injection at host boundary).

6. ZeroClaw (zeroclaw)

ZeroClaw has the most consistent CLI of any platform — clean, well-structured, Rust clap-based help output with examples for every subcommand.

Subcommands (22):

Design philosophy: “Fast, small, complete.” ZeroClaw’s CLI is notable for its balance — 22 subcommands covering the full agent lifecycle (onboarding, agent loop, daemon, scheduling, skills, hardware, monitoring) without the sprawl of Hermes’ 81+ commands. Every subcommand has examples in its --help output.

Notable design choices:

• agent -m "prompt" for single-shot without entering interactive mode
• estop for emergency stop of the daemon and channels
• Hardware peripheral support (STM32, RPi GPIO) — unique in the ecosystem
• daemon as a first-class command (gateway + channels + heartbeat + scheduler as a single long-running process)

7. OpenCode (opencode)

OpenCode is “the open source coding agent” — a TUI-first coding assistant with ACP and MCP support, plus a unique headless server mode for remote collaboration.

Subcommands (21):

Invocation modes:

• opencode — Launch TUI (default)
• opencode run "prompt" — Run with a message (non-interactive)
• opencode serve — Headless server
• opencode web — Server + browser UI
• opencode attach <url> — Connect to remote server
• opencode --mini — Minimal interactive interface
• opencode -c / -s <id> — Continue last or specific session

Notable design choices:

• --fork to fork a session when continuing (branch from a previous state)
• --pure to run without external plugins
• --mdns for mDNS service discovery on local network (find running instances)
• --cors for cross-origin configuration on the headless server
• --auto to auto-approve any permission not explicitly denied (the documented-dangerous mode)
• --port / --hostname to bind the server explicitly; --mdns-domain to customize discovery
• --replay-limit to cap mini-mode session replay on resume
• pr <number> fetches a GitHub PR branch then launches the TUI — a workflow-specific command no other platform has
• stats for token usage and cost tracking as a first-class command

Design philosophy: “TUI-first, server-optional.” OpenCode’s default experience is a TUI, but it uniquely offers both a headless serve mode and a web mode with browser UI. The attach <url> command and mDNS discovery suggest a design that supports both local development and remote collaboration — you can run opencode on a server and attach to it from your laptop. The pr command bridges GitHub workflow into the agent loop, treating PR review as a first-class use case.

8. Nanobot (nanobot)

Nanobot takes the “ultra-lightweight” philosophy into its CLI design.

Architecture:

• CLI via Python Typer (auto-generated help from type hints)
• Single-agent with subagent support
• 8+ channels (Telegram, Discord, Slack, WhatsApp, Feishu, QQ, Email, Matrix, CLI)
• MCP bridge (available but not core)
• LiteLLM for multi-provider support

Design philosophy: “One command, one agent.” Nanobot’s CLI is minimal because the platform itself is minimal (~4,000 LOC core). Typer provides good help output automatically from type annotations. The focus is on pip install nanobot-ai and immediate usability, not comprehensive subcommand coverage.

9. Maxclaw (maxclaw)

Maxclaw ships two binaries — one for the agent, one for the gateway.

Architecture:

• cmd/main.go — Agent CLI with sub-session spawning
• maxclaw-gateway — Separate gateway binary
• Desktop UI + Web UI on same port
• Monorepo context discovery (AGENTS.md, CLAUDE.md)
• Layered memory (MEMORY.md, HISTORY.md, heartbeat.md)

Design philosophy: “Local-first with visual interfaces.” Maxclaw uniquely bundles a desktop UI and web UI on the same port. The CLI is one interface alongside visual ones. Sub-session spawning enables parallel agents within a single maxclaw instance.

10. NanoClaw (nanoclaw)

NanoClaw is the most container-centric platform — its “CLI” is fundamentally an orchestrator process.

Architecture:

• Single Node.js orchestrator process
• Claude Agent SDK running in isolated containers per group
• Per-group CLAUDE.md for memory
• IPC watcher for inter-process communication
• Task scheduler
• WhatsApp as primary channel

Design philosophy: “Containers, not commands.” NanoClaw’s CLI is an IPC orchestrator that spawns containerized agent instances. The “commands” are container lifecycle management — start, stop, monitor. There is no REPL in the traditional sense; you interact through WhatsApp groups, each with an isolated Claude agent in its own container.

11. HiClaw (hiclaw)

HiClaw is the only platform to use Kubernetes-style declarative resources.

Architecture:

• hiclaw CLI with Docker Compose
• YAML resource definitions (Worker, Team, Human)
• Worker template marketplace
• Nacos-based skill discovery
• Manager-Workers runtime (CoPaw)

Design philosophy: “Declarative infrastructure for agents.” HiClaw’s CLI is closest to kubectl — you define workers, teams, and human-in-the-loop resources as YAML files and apply them. The CLI manages resource lifecycle rather than agent interaction. This is the enterprise-automation paradigm taken to its logical conclusion: agents are Kubernetes resources.

12. Hermes-Agent (Source Analysis vs Live Capture)

The architecture docs describe Hermes as a simpler platform than what the live --help reveals. The docs note:

• Entry point: hermes CLI
• Architecture: Single-agent with context management
• MCP native integration

The live CLI (v0.20.0) shows a platform that has evolved far beyond “single-agent with context management” into a full-featured agent operating system with 81+ subcommands spanning messaging, scheduling, skills, memory, monitoring, desktop GUI, and MCP server management.

13. aider (aider)

aider is the most focused CLI — it does one thing (code editing with AI) and does it through a chat interface.

Architecture:

• REPL pair-programming loop
• Git-aware (auto-commits with sensible messages)
• Edit modes: Whole Edit, Diff Edit, Architect
• Repo Map for large codebase context
• 20+ LLM providers

Design philosophy: “Pair programming, not a platform.” aider has no subcommands for scheduling, skills, messaging, or monitoring. It’s a chat loop with git integration. You talk, it edits code, git commits the result. The minimalism is the point — 68K stars from doing one thing extremely well.

14. Claude Code (claude)

Claude Code is Anthropic’s official CLI coding agent. Not directly testable from WSL (launches a TUI that times out).

Architecture:

• Terminal-based coding agent
• ACP protocol support
• Sandboxed execution
• Interactive approval loop

Design philosophy: “Anthropic’s terminal agent.” Claude Code is the reference implementation of Anthropic’s vision for terminal-based AI coding. It follows the pattern of minimal CLI surface — you run claude, it starts a session, you code. The simplicity is by design.

15. kimi-cli (kimi-cli)

kimi-cli from MoonshotAI has the most options-dense help of any platform relative to its subcommand count.

Invocation modes:

• kimi-cli — Interactive agent (default)
• kimi-cli -p "prompt" / -c "prompt" — Single prompt
• kimi-cli --print — Print mode (non-interactive, implies --yolo)
• kimi-cli --quiet — Shorthand for --print --output-format text --final-message-only
• kimi-cli --acp — ACP server mode (deprecated, now kimi-cli acp)
• kimi-cli --wire — Wire server (experimental)

Subcommands (9):

Notable design choices:

• --agent [default|okabe] and --agent-file FILE for custom agent specifications
• --input-format [text|stream-json] and --output-format [text|stream-json] for pipe integration
• --mcp-config-file FILE (repeatable) for multiple MCP configs
• --skills-dir DIRECTORY for skills discovery
• --thinking / --no-thinking for reasoning mode toggle
• --max-steps-per-turn, --max-retries-per-step, --max-ralph-iterations for fine-grained control

Design philosophy: “Configurable agent, multiple interfaces.” kimi-cli provides the most granular per-invocation configuration of any platform. Every aspect of the agent’s behavior can be tuned via flags — model, thinking mode, step limits, retry limits, MCP configs, agent specification, skills directory. The three interface modes (interactive, print, wire/ACP) and the agent tracing visualizer (vis) suggest a platform designed for both end-user coding and developer tooling.

16. Codex (codex)

OpenAI’s Codex is the most starred CLI agent and the simplest architecturally.

Architecture:

• Simple CLI → LLM → Shell execution loop
• Sandboxed execution (all code runs in isolated environments)
• Single binary, zero runtime overhead
• Models: GPT-4o, o3, o4-mini

Design philosophy: “Single binary, single loop.” Codex is the anti-Hermes. One command, one loop, sandboxed execution, done. No subcommands for skills, scheduling, messaging, or monitoring. The sandbox is the differentiator — every code execution is isolated, making it safe for CI/CD pipelines.

17. Reasonix (reasonix / dsnix)

Reasonix (esengine/DeepSeek-Reasonix) is the “DeepSeek-native coding agent” — and the only platform in this comparison with two command names: both reasonix and dsnix map to the same binary. Its CLI philosophy is built around one economic idea: DeepSeek’s context cache. Subcommands exist to make cache hit rates visible and steerable.

Subcommands (19):

Design philosophy: “Cost as a first-class citizen.” Reasonix is the only CLI here with a session dollar budget built into the invocation: --budget <usd> warns at 80% and refuses the next turn at 100% (not just warns — a hard gate). The chat TUI shows a live cache-hit/cost panel while you type, stats turns historical transcripts into a usage dashboard, and doctor-cache is a dedicated health check for cache stability. Where kimi-cli makes every behavior configurable, Reasonix makes every cost dimension visible: budget caps, per-transcript accounting, cache health. It’s the economics-first counterpart to kimi-cli’s configuration-first design.

Notable design choices:

• --budget <usd> — per-session spend cap with 80% warning and hard refusal at 100%
• --effort low|medium|high|max — reasoning-effort dial on every invocation mode
• --no-mouse — disables SGR mouse tracking to restore native terminal selection (a pain point no other CLI addresses)
• --no-proxy — per-run proxy bypass, useful behind GFW-adjacent networks
• --dashboard-port / --dashboard-host — stable port + LAN binding for the embedded web dashboard (SSH-tunnel friendly)
• --mcp <spec> repeatable with --mcp-prefix to namespace tool names
• --profile — records a V8 CPU profile for perf-bug reports
• Bilingual help output (Chinese descriptions with English command names)
• diff <a> <b> — the only CLI that can diff two agent transcripts side-by-side
• dry-run flag on code for ssh:// targets — parse the URI, check local SSH, print planned steps, execute nothing

Cross-links: Reasonix implements one-shot (run), TUI (chat), ACP server (acp), MCP management (mcp), session resume (-c/-r), and self-update (update) — the same six capability points as Hermes and OpenCode, in a fraction of the codebase.

Cross-Platform Analysis

Subcommand Count Spectrum

Hermes       ████████████████████████████████████████████  81+
OpenCode     ████████████████████████  21
ZeroClaw     ██████████████████  22
Reasonix     ██████████████████  19
kimi-cli     ████████  9
ClawTeam     ████████  ~8 groups
GoClaw       █████  ~5
codex        ██  1-2
aider        ██  1

Invocation Mode Matrix

Configuration Approach

Operational Commands Coverage

What the CLI Reveals About Platform Philosophy

The Unix Philosophy Spectrum

Hermes is at one extreme: “Do everything through the CLI.” 81+ subcommands, every feature exposed, from hermes dashboard to hermes pets. The CLI IS the platform.

Codex and aider are at the other extreme: “Do one thing through the CLI.” A chat loop, git integration, done. The CLI is a thin shell around the core agent loop.

ZeroClaw and kimi-cli occupy the middle ground: enough subcommands to cover the agent lifecycle (scheduling, skills, monitoring) without the sprawl. ZeroClaw’s 22 commands and kimi-cli’s 9 commands + rich flag set suggest a deliberate design constraint — enough to be useful, not enough to be overwhelming.

The “Operating System” vs “Tool” Divide

Hermes, ZeroClaw, and GoClaw behave like operating systems for agents — they manage the full lifecycle: installation, configuration, scheduling, monitoring, debugging, backup, update. Their CLIs reflect this: doctor, backup, update, migrate, estop.

aider, codex, and Claude Code behave like tools — you run them when you need them, they do their job, they exit. No daemon, no scheduler, no backup. Their CLIs reflect this: minimal surface, focused interaction.

ClawTeam occupies a unique position: it’s an operating system for other agents, not for itself. Its CLI manages teams of aider/Codex/OpenClaw instances. It doesn’t have an AI chat loop — it has team lifecycle management.

The Convergence Pattern

Three CLI patterns are converging across the ecosystem:

1. One-shot mode (Hermes -z, kimi-cli --print, ZeroClaw -m) — Every platform eventually adds a non-interactive mode for scripting and CI integration.

2. ACP/Wire protocol (Hermes acp, kimi-cli acp/--wire, copilot-cli ACP) — Agent Communication Protocol is becoming the standard for IDE integration, with kimi-cli leading on wire protocol experimentation.

3. MCP configuration as a CLI concern (Hermes mcp, kimi-cli mcp, GoClaw adapter) — Managing MCP servers is becoming a first-class CLI operation, not a config-file-only concern.

The Missing Commands

Every platform is missing something:

• aider and codex have no scheduling. You cannot say “run this coding task every morning.” They are purely interactive.
• ClawTeam has no credential management CLI. Credentials are in TOML files or environment variables.
• GoClaw has no backup/restore. Enterprise infrastructure is assumed to be externally managed.
• Hermes has no one-shot print-only mode that also outputs JSON (kimi-cli’s --output-format stream-json is more pipe-friendly).
• ZeroClaw has no session resume. Each agent invocation is fresh.
• kimi-cli has no cron or scheduling despite having the richest per-invocation configuration.
• Reasonix has no scheduling and no shell completion. Its cost tooling is unmatched, but you can’t say “run this every morning” — the expected pattern is its run one-shot driven by system cron.

The Bottom Line

The CLI is the most honest interface a platform has. Documentation can overstate capabilities. Marketing can mislead. But --help output is what users actually see, and it reveals the real priorities:

• Hermes prioritizes completeness — every feature gets a command
• ZeroClaw prioritizes consistency — every command has examples and clean help
• kimi-cli prioritizes configurability — every invocation can be finely tuned
• OpenCode prioritizes remote collaboration — serve, attach, mDNS discovery
• aider prioritizes focus — one loop, done well
• codex prioritizes safety — one binary, sandboxed, minimal
• ClawTeam prioritizes orchestration — commands for teams, not for chat
• GoClaw prioritizes infrastructure — commands for deployment, not interaction
• Reasonix prioritizes economics — budget caps and cache visibility in every invocation

The best CLIs of 2026 combine Hermes’ completeness with ZeroClaw’s consistency, kimi-cli’s configurability, OpenCode’s remote collaboration, and Reasonix’s cost discipline. Nobody has done all five yet.

Live CLI captures from Hermes v0.20.0, OpenCode v1.18.18, kimi-cli v1.24.0, zeroclaw v0.1.7, reasonix v0.52.0. Architecture documentation from the AllClaws platform comparison covering all tracked platforms. See platform_comparison.md for full architecture details.

实验概念上很简单。我创建了三个团队成员，每个由一个来自完全不同架构范式的平台驱动：

我给了它们一个共享任务板，包含四个关于它们自己平台的研究问题——工作区隔离、多任务协调、安全和身份模型——然后是第五个需要阅读彼此产出的综合任务。每个成员调查自己平台的内部实现，并以 markdown 文件提交发现。

在一个 sprint 的时间里，团队产出了 13 个 markdown 文件：每人 4 个，加一份跨平台综合报告。以下是我学到的东西。

实验：结构与设置

任务板很直接。每个成员收到关于其平台四个维度的相同研究 prompt：

1. S1-T1：工作区与项目隔离 — 平台如何组织工作？隔离边界是什么？
2. S1-T2：多任务与多代理协调 — 如何处理并发任务？代理间通信？
3. S1-T3：安全与凭据管理 — 如何处理密钥、沙箱、审计？
4. S1-T4：Profile / 身份模型 — 用户和上下文如何分离？

第五个任务（S1-T5）是综合——比较三种方法，识别权衡，并为每个平台提出可以向其他平台借鉴什么。

每个成员基于相同的源材料工作：AllClaws 架构文档和实际的平台源代码（作为 git submodule 提供在父仓库中）。它们不能直接对话。协调通过引用其他成员工作的 commit message 完成。

整个实验活在一个 git 仓库里，使用结构化命名：virtual-team/<member>/S1-T<task#>-<short-name>.md。没有项目管理工具。没有 Slack 频道。没有站会。只有 git commit 和 markdown 文件。

发生了什么

三个范式，通过它们自己的眼睛

每个成员都产出了扎根于实际代码的详细技术分析——不是营销文案，不是文档摘要，而是从阅读源码中提炼的架构。

goclaw-operator 交出了配得上其平台的企业级分析。它的工作区隔离分析记录了 GoClaw 如何把 TenantID 传播到每一层——网关路由、agent 分发、数据库查询（store.WithTenantID）和审计日志。它的安全分析是所有成员中最详尽的，详述了五层防御：AES-256-GCM 加密、RBAC（admin/operator/viewer）、exec 审批白名单、通过 Go channel 的缓冲审计日志（容量 256），以及限流。这份分析读起来像一份安全审计——精确、落到具体实现、不留情面。

clawteam-lead 产出了聚焦协调原语的分析。它的工作区隔离文档解释了基于 git worktree 的架构——每个 worker agent 从父仓库获得自己的 worktree，消除了合并冲突。它的多任务协调分析是所有成员中最丰富的，记录了基于 TOML 的 blocked-by 依赖链与自动解除阻塞、双模式代理间通信（点对点 inbox 加广播），以及一个具体的性能声明：5 个并行 agent 在约 3 小时内完成一个全栈应用，对比串行的 8 小时以上——同等 token 成本下 2.7 倍加速。

hermes-researcher 交出了最内省的分析，基于一个实际运行的安装。它确认了两个活跃 profile（personal，1.9MB state.db；work，368KB WAL），记录了凭据池轮换（标记 401，轮换到下一个 key），并提供了 profile 隔离在实践中如何工作的最清晰解释。它的分析对局限性最坦诚：”agent 进程内部没有任何东西构成容器隔离”——直接引用自平台的 SECURITY.md。

综合：三个范式碰撞的地方

跨平台综合报告（S1-T5）是这次实验的收获。它在每个维度上比较了三个平台，产出了整个实验中最有用的输出：一个结构化的权衡矩阵。

以下浮现出来的发现：

在工作区隔离上，根本性的分叉显形了。 GoClaw 按身份隔离（你是谁——每个数据库查询里的 TenantID）。ClawTeam 按任务隔离（你在做什么——每个 agent 一个 git worktree）。Hermes 按上下文隔离（你在扮演什么角色——每个用例一个 profile 目录）。三者没有一个能同时做到另外两个。GoClaw 无法为同一用户分离上下文。ClawTeam 无法分离用户。Hermes 无法分离任务。

在协调上，成熟度光谱悬殊得刺眼。 ClawTeam 拥有最精密的系统：显式依赖链、代理间 inbox、广播消息、kanban 监控。GoClaw 有数据库支撑的团队协调但没有直接消息传递。Hermes 只有 fire-and-forget 委派，完全没有代理间通信。ClawTeam 的”agent 交换中间结果”与 Hermes 的”agent 返回最终摘要”之间的差距不是渐进的——是架构性的。

在安全上，企业与个人的分野显而易见但并不简单。 GoClaw 决定性领先：加密凭据、RBAC、结构化审计日志、按租户隔离。但综合报告凸显了一个有趣的中间立场。Hermes 的自动凭据池轮换——耗尽一个 401 的 key 然后轮换到下一个——在运维成熟度上超过 GoClaw 的手动凭据管理。最好的安全模型应该结合 GoClaw 的治理与 Hermes 的运维自动化。

在身份上，每个平台回答的是不同的问题。 GoClaw：”你是谁？”（TenantID）。ClawTeam：”你在哪个团队？”（TOML 模板）。Hermes：”你现在戴的是哪顶帽子？”（profile 目录）。洞察在于：这些不是竞争的答案——它们在回答真实用户同时拥有的不同问题。

元教训：Agent 能做比较研究

在讨论平台含义之前，有一个元层面的发现：实验成功了。

三个 AI agent，各自访问相同的源材料，但运行在不同平台、使用不同 prompt 策略，产出了 13 个文件的有据可依的技术分析。综合文档跨成员交叉引用发现，识别出非显而易见的权衡，并为每个平台提出了可操作的改进——全程没有人类写下一个段落。

这很重要，因为比较性平台分析恰好是那种：

• 劳动密集：阅读三个代码库的源代码是人类数小时的工作
• 结构化：输出格式定义明确（markdown、表格、对比）
• 有据可依：你可以对照实际代码验证声明
• 无聊：没人想花一个周末比较 RBAC 实现

AI agent 擅长以上全部四点。关键在于提供结构化的任务定义、共享的证据基础和清晰的输出格式。agent 完成了剩下的一切。

但是——这一点至关重要——综合质量完全取决于个体分析的质量。当 clawteam-lead 对 TOML 依赖链足够具体时，综合才能精确比较它们。当 goclaw-operator 详述审计管道（EventEmitter -> Buffered Channel -> PostgreSQL）时，综合才能准确对比。模糊的分析只会产出模糊的综合。实验的结构与 agent 本身同样重要。

对 Agent 平台设计的启示

1. 分叉是真实的，而且正在固化

AllClaws 研究已经识别出一个决定性趋势：个人力量倍增器与企业自动化范式之间的分叉。这次实验以新的方式让分叉显形——不是通过阅读文档，而是通过观察来自每个范式的 agent 如何推理同样的问题。

GoClaw 的 goclaw-operator 用租户、策略和合规思考。ClawTeam 的 clawteam-lead 用 agent、任务和合并冲突思考。Hermes 的 hermes-researcher 用 profile、记忆和上下文切换思考。这些不是同一抽象的不同实现——它们是完全不同的抽象。

启示：我们不会收敛到单一的 agent 平台架构。我们正在分化为至少三种不同的架构，各自为不同的部署现实优化。GoClaw 的 PostgreSQL 承诺让它不可能零配置。ClawTeam 的 git worktree 模型让它不可能多租户。Hermes 的文件系统 profile 模型让它不可能做实时代理间协调。

2. 没有人做到三种分离

综合报告识别出一个没有任何被跟踪平台填补的缺口：同时做到用户分离、任务分离和上下文分离。

在真实世界里，开发者三者都需要。我需要工作 API key 与个人 API key 隔离（用户分离）。我需要并行 agent 在不同 feature 上工作而不冲突（任务分离）。我需要我的”代码审查”上下文拥有与”研究”上下文不同的工具和权限（上下文分离）。

GoClaw 分离用户。ClawTeam 分离任务。Hermes 分离上下文。同时做到三者——且不分别要求 PostgreSQL、git 专业知识和文件系统管理——的平台，将拥有真正的架构优势。

3. 协调是服务不足的中间地带

实验揭示了一个出人意料的非对称。GoClaw 有企业治理但没有群体协调。ClawTeam 有群体协调但没有企业治理。Hermes 两者皆无但擅长个体生产力。

服务不足的空间是面向小团队的结构化协调——不是 500 用户的企业部署（GoClaw 的地盘），不是并行 agent 的独立开发者（ClawTeam 的地盘），而是 3-10 人的团队，他们的 agent 需要跨组织边界协作并带一些治理。

想象一下：ClawTeam 的依赖链和 inbox 系统，加上 GoClaw 的凭据隔离和审计日志，运行在 Hermes 的 profile 模型里，每个成员获得一致的上下文。这个产品不存在。最接近的近似需要用胶带把三个平台粘在一起。

4. 安全实践应该与架构解耦

GoClaw 的安全最完整，因为它烤进了 PostgreSQL——租户范围的加密、租户范围的审计日志、RPC 层的 RBAC 强制执行。但这意味着你需要 PostgreSQL 才能有安全。

综合报告表明，一些安全实践与架构无关：

• 凭据池轮换（Hermes）适配任何存储后端
• 通过指纹的密钥脱敏（Hermes）不需要加密
• exec 审批白名单（GoClaw）不需要数据库
• 结构化审计日志（GoClaw）可以用 SQLite 替代 PostgreSQL

启示：安全成熟度不应该要求特定的架构承诺。像 ClawTeam 那样把凭据以明文 TOML 存储的平台，可以采纳 Hermes 的池轮换和 GoClaw 的审计模式，而不改变核心架构。它们没有这样做的事实表明，安全在个人 agent 平台中被当作事后想起——随着这些 agent 处理越来越敏感的操作，这个习惯将变得不可持续。

5. Profile 即工作区，是个人 agent 的正确默认

Hermes 的 profile 模型——一个自包含目录，带配置、凭据、技能、记忆和会话状态——是我见过的个人用途下最干净的隔离原语。ClawTeam 的 worktree 模型对并行代码工作很出色，但不分离上下文。GoClaw 的租户模型对单用户是杀鸡用牛刀。

profile 方法有一个其他方法不具备的属性：零配置上下文切换。我可以有一个用便宜模型和只读工具的”research” profile，和一个用强大模型和完整终端访问的”coding” profile。切换它们就是换一个目录，不是开通基础设施。

这暗示了一个收敛点：个人平台应该采用基于 profile 的隔离作为默认，可选 worktree 隔离用于并行编程任务，可选租户隔离用于团队部署。Hermes 提供了地基；其他平台提供可选层。

每个平台应该偷什么

综合报告产出了一份具体、可操作的清单：

GoClaw 应该从 ClawTeam 偷：

• 带自动解除阻塞的任务依赖链（比隐式团队协调更有表达力）
• 带 circuit breaker 状态的 agent 级成本仪表盘

GoClaw 应该从 Hermes 偷：

• 自动凭据池轮换（替代手动 key 管理）

ClawTeam 应该从 GoClaw 偷：

• AES-256-GCM 凭据加密（明文 TOML 问题是任何共享系统的 showstopper）
• 结构化审计日志（JSON 状态文件不是审计轨迹）

ClawTeam 应该从 Hermes 偷：

• Profile / 上下文分离（让 agent 在不同任务下以不同配置运行）

Hermes 应该从 ClawTeam 偷：

• 代理间通信（inbox 和广播，而不只是 fire-and-forget 委派）
• 任务依赖跟踪（blocked-by 链，而不是扁平 todo 列表）
• 多代理监控（所有运行中任务的 kanban 看板视图）

Hermes 应该从 GoClaw 偷：

• 带权限范围的 RBAC（research 只读，development 完全访问）
• 面向企业 profile 的结构化审计日志

真正的收获

我出发去通过让三个 AI agent 平台解决同一个问题来了解它们。我学到了预期中的东西——平台有不同的强项、不同的弱点、不同的架构承诺。对比矩阵确认了我已经手动做过的分析。

但我也学到了意料之外的东西：每个 agent 思考问题的方式，比任何功能对比都更能揭示平台的本质。

GoClaw 的 agent 写安全的方式，就像安全工程师写安全——分层防御、威胁模型、合规要求。ClawTeam 的 agent 写协调的方式，就像系统架构师写分布式系统——消息传递、隔离边界、故障恢复。Hermes 的 agent 写身份的方式，就像产品设计师写用户体验——用户上下文、心智模型、切换成本。

这些不是巧合。每个平台塑造了它的 agent 推理问题的方式。GoClaw 的数据库中心架构自然产出数据库中心的分析。ClawTeam 的 git 中心架构自然产出 git 中心的分析。Hermes 的 profile 中心架构自然产出 profile 中心的分析。

平台提供的不只是不同的工具——它们提供不同的透镜。这次实验最有价值的东西，不是学到每个平台做什么，而是学到每个平台看到什么。

全部 13 个分析文件可在 AllClaws 仓库的 virtual-team 目录获取。跨平台综合报告在 virtual-team/S1-T5-cross-platform-synthesis.md，包含完整的对比矩阵和权衡分析。

English version

The experiment was simple in concept. I created three team members, each powered by a different platform from a fundamentally different architectural paradigm:

I gave them a shared task board with four research questions about their own platforms — workspace isolation, multi-task coordination, security, and identity models — then a fifth synthesis task that required reading each other’s output. Each member investigated their own platform’s internals and committed findings as markdown files.

Over the course of a sprint, the team produced 13 markdown files: 4 per member plus a cross-platform synthesis. Here’s what I learned.

The Experiment: Structure and Setup

The task board was straightforward. Each member received identical research prompts about four dimensions of their platform:

1. S1-T1: Workspace & Project Isolation — How does the platform organize work? What is the isolation boundary?
2. S1-T2: Multi-Task & Multi-Agent Coordination — How does it handle concurrent tasks? Inter-agent communication?
3. S1-T3: Security & Credential Management — How does it handle secrets, sandboxing, audit?
4. S1-T4: Profile / Identity Model — How are users and contexts separated?

The fifth task (S1-T5) was a synthesis — compare all three approaches, identify trade-offs, and suggest what each platform could learn from the others.

Each member worked from the same source material: the AllClaws architecture documentation and the actual platform source code (available as git submodules in the parent repo). They couldn’t talk to each other directly. Coordination happened through commit messages referencing other members’ work.

The whole thing lived in a git repo with structured naming: virtual-team/<member>/S1-T<task#>-<short-name>.md. No project management tool. No Slack channel. No standup meetings. Just git commits and markdown files.

What Happened

The Three Paradigms, Through Their Own Eyes

Each member produced detailed technical analysis rooted in actual code — not marketing copy, not documentation summaries, but architecture drawn from reading source.

goclaw-operator delivered enterprise-grade analysis befitting its platform. Its workspace isolation analysis documented how GoClaw propagates a TenantID through every layer — gateway routing, agent dispatch, database queries (store.WithTenantID), and audit logging. Its security analysis was the most thorough of any member, detailing a 5-layer defense: AES-256-GCM encryption, RBAC (admin/operator/viewer), exec approval allowlists, buffered audit logging via Go channels (capacity 256), and rate limiting. The analysis read like a security audit — precise, implementation-specific, and unsparing.

clawteam-lead produced analysis focused on coordination primitives. Its workspace isolation document explained git worktree-based architecture — each worker agent gets its own worktree from the parent repo, eliminating merge conflicts. Its multi-task coordination analysis was the richest of any member, documenting TOML-based blocked-by dependency chains with automatic unblocking, dual-mode inter-agent communication (point-to-point inboxes plus broadcast), and a concrete performance claim: 5 parallel agents completing a full-stack app in ~3 hours vs 8+ hours sequential, a 2.7x speedup at the same token cost.

hermes-researcher delivered the most introspective analysis, grounded in an actual running installation. It confirmed two active profiles (personal at 1.9MB state.db, work at 368KB WAL), documented credential pool rotation (mark 401, rotate to next key), and provided the clearest explanation of how profile-based isolation works in practice. Its analysis was the most candid about limitations: “Nothing inside the agent process constitutes containment,” quoting directly from the platform’s SECURITY.md.

The Synthesis: Where the Three Paradigms Collide

The cross-platform synthesis (S1-T5) was the payoff. It compared all three platforms across each dimension and produced the most useful output of the entire experiment: a structured matrix of trade-offs.

Here’s what emerged:

On workspace isolation, the fundamental fork revealed itself. GoClaw isolates by identity (who you are — TenantID in every database query). ClawTeam isolates by task (what you’re doing — git worktree per agent). Hermes isolates by context (which role you’re in — profile directory per use case). None of the three does all three. GoClaw cannot separate contexts for the same user. ClawTeam cannot separate users. Hermes cannot separate tasks.

On coordination, the maturity spectrum was stark. ClawTeam has the most sophisticated system: explicit dependency chains, inter-agent inboxes, broadcast messaging, kanban monitoring. GoClaw has database-backed team coordination without direct messaging. Hermes has fire-and-forget delegation with no inter-agent communication at all. The gap between ClawTeam’s “agents exchange intermediate results” and Hermes’ “agents return final summaries” is not incremental — it’s architectural.

On security, the divide between enterprise and personal was obvious but not simple. GoClaw leads decisively: encrypted credentials, RBAC, structured audit logging, per-tenant isolation. But the synthesis highlighted an interesting middle position. Hermes’ automatic credential pool rotation — exhausting a 401’d key and rotating to the next — is more operationally mature than GoClaw’s manual credential management. The best security model would combine GoClaw’s governance with Hermes’ operational automation.

On identity, each platform answers a different question. GoClaw: “Who are you?” (TenantID). ClawTeam: “What team are you on?” (TOML template). Hermes: “What hat are you wearing?” (profile directory). The insight is that these are not competing answers — they’re answering different questions that real users have simultaneously.

The Meta-Lesson: Agents Can Do Comparative Research

Before discussing platform implications, there’s a meta-level finding: the experiment worked.

Three AI agents, each with access to the same source material but running on different platforms with different prompting strategies, produced 13 files of grounded technical analysis. The synthesis document cross-referenced findings across members, identified non-obvious trade-offs, and suggested actionable improvements for each platform — all without a human writing a single paragraph.

This matters because comparative platform analysis is exactly the kind of work that is:

• Labor-intensive: Reading source code across three codebases is hours of human effort
• Structured: The output format is well-defined (markdown, tables, comparisons)
• Grounded: You can verify claims against actual code
• Boring: Nobody wants to spend a weekend comparing RBAC implementations

AI agents are good at all four of these properties. The key was providing structured task definitions, a shared evidence base, and a clear output format. The agents did the rest.

But — and this is critical — the synthesis quality depended entirely on the individual analysis quality. When clawteam-lead was specific about TOML dependency chains, the synthesis could compare them precisely. When goclaw-operator detailed the audit pipeline (EventEmitter -> Buffered Channel -> PostgreSQL), the synthesis could contrast it accurately. Vague analysis would have produced vague synthesis. The structure of the experiment mattered as much as the agents.

Implications for Agent Platform Design

1. The Fork Is Real, and It’s Hardening

The AllClaws research has identified a defining trend: the fork between personal-force-multiplier and enterprise-automation paradigms. This experiment made the fork visible in a new way — not by reading documentation, but by watching how agents from each paradigm reason about the same problems.

GoClaw’s goclaw-operator thinks in terms of tenants, policies, and compliance. ClawTeam’s clawteam-lead thinks in terms of agents, tasks, and merge conflicts. Hermes’ hermes-researcher thinks in terms of profiles, memory, and context switching. These are not different implementations of the same abstraction — they are different abstractions entirely.

The implication: we are not converging on a single agent platform architecture. We are diverging into at least three distinct ones, each optimized for a different deployment reality. GoClaw’s PostgreSQL commitment makes it impossible to be zero-config. ClawTeam’s git worktree model makes it impossible to be multi-tenant. Hermes’ filesystem profile model makes it impossible to do real-time inter-agent coordination.

2. Nobody Does All Three Separations

The synthesis identified a gap that no tracked platform fills: simultaneous user separation, task separation, and context separation.

In the real world, developers need all three. I need my work API keys isolated from my personal ones (user separation). I need parallel agents working on different features without conflicts (task separation). I need my “code review” context to have different tools and permissions than my “research” context (context separation).

GoClaw separates users. ClawTeam separates tasks. Hermes separates contexts. The platform that does all three — without requiring PostgreSQL, git expertise, and filesystem management respectively — will have a genuine architectural advantage.

3. Coordination Is the Underserved Middle Ground

The experiment revealed a surprising asymmetry. GoClaw has enterprise governance but no swarm coordination. ClawTeam has swarm coordination but no enterprise governance. Hermes has neither but excels at individual productivity.

The underserved space is structured coordination for small teams — not 500-user enterprise deployments (GoClaw’s territory), not solo developers with parallel agents (ClawTeam’s territory), but teams of 3-10 humans who need their agents to collaborate across organizational boundaries with some governance.

Imagine: ClawTeam’s dependency chains and inbox system, but with GoClaw’s credential isolation and audit logging, running inside Hermes’ profile model so each team member gets a consistent context. That product doesn’t exist. The closest approximation requires duct-taping three platforms together.

4. Security Practices Should Decouple from Architecture

GoClaw’s security is the most complete because it’s baked into PostgreSQL — tenant-scoped encryption, tenant-scoped audit logs, RBAC enforcement at the RPC layer. But this means you need PostgreSQL to get security.

The synthesis showed that some security practices are architecture-independent:

• Credential pool rotation (Hermes) works with any storage backend
• Secret redaction via fingerprints (Hermes) works without encryption
• Exec approval allowlists (GoClaw) work without a database
• Structured audit logging (GoClaw) could use SQLite instead of PostgreSQL

The implication: security maturity should not require a specific architectural commitment. Platforms like ClawTeam that store credentials in plaintext TOML files could adopt Hermes’ pool rotation and GoClaw’s audit patterns without changing their core architecture. The fact that they haven’t suggests that security is treated as an afterthought in personal-agent platforms — a habit that will become unsustainable as these agents handle more sensitive operations.

5. Profile-as-Workspace Is the Right Default for Personal Agents

Hermes’ profile model — a self-contained directory with config, credentials, skills, memory, and session state — is the cleanest isolation primitive I’ve seen for personal use. ClawTeam’s worktree model is brilliant for parallel code work but doesn’t separate contexts. GoClaw’s tenant model is overkill for a single user.

The profile approach has a property that the others lack: zero-config context switching. I can have a “research” profile with a cheaper model and read-only tools, and a “coding” profile with a powerful model and full terminal access. Switching between them is changing a directory, not provisioning infrastructure.

This suggests a convergence point: personal platforms should adopt profile-based isolation as the default, with optional worktree isolation for parallel coding tasks and optional tenant isolation for team deployments. Hermes provides the foundation; the others provide the optional layers.

What Each Platform Should Steal

The synthesis produced a specific, actionable list:

GoClaw should steal from ClawTeam:

• Task dependency chains with auto-unblock (more expressive than implicit team coordination)
• Agent-level cost dashboards with circuit breaker states

GoClaw should steal from Hermes:

• Automatic credential pool rotation (replace manual key management)

ClawTeam should steal from GoClaw:

• AES-256-GCM credential encryption (the plaintext TOML problem is a showstopper for any shared system)
• Structured audit logging (JSON state files are not audit trails)

ClawTeam should steal from Hermes:

• Profile/context separation (let agents operate under different configurations for different tasks)

Hermes should steal from ClawTeam:

• Inter-agent communication (inboxes and broadcast, not just fire-and-forget delegation)
• Task dependency tracking (blocked-by chains, not flat todo lists)
• Multi-agent monitoring (kanban board view of all running tasks)

Hermes should steal from GoClaw:

• RBAC with permission scopes (read-only for research, full-access for development)
• Structured audit logging for enterprise profiles

The Real Takeaway

I set out to learn about AI agent platforms by putting three of them to work on the same problem. I learned what I expected — the platforms have different strengths, different weaknesses, different architectural commitments. The comparison matrices confirmed the analysis I’d already done manually.

But I also learned something I didn’t expect: the way each agent thought about the problem revealed more about the platform than any feature comparison ever could.

GoClaw’s agent wrote about security the way a security engineer writes about security — layered defenses, threat models, compliance requirements. ClawTeam’s agent wrote about coordination the way a systems architect writes about distributed systems — message passing, isolation boundaries, failure recovery. Hermes’ agent wrote about identity the way a product designer writes about UX — user contexts, mental models, switching costs.

These aren’t coincidences. Each platform shapes how its agents reason about problems. GoClaw’s database-centric architecture naturally produces database-centric analysis. ClawTeam’s git-centric architecture naturally produces git-centric analysis. Hermes’ profile-centric architecture naturally produces profile-centric analysis.

The platforms don’t just provide different tools — they provide different lenses. And the most useful thing about this experiment wasn’t learning what each platform does. It was learning what each platform sees.

All 13 analysis files are available in the virtual-team directory of the AllClaws repository. The cross-platform synthesis at virtual-team/S1-T5-cross-platform-synthesis.md contains the full comparison matrices and trade-off analysis.

本月 AllClaws 跟踪了 34 个平台（7 月初为 30 个），新增 7 个 submodule，发布 7 份研究报告，产出 6 篇博客，并将基准测试引擎升级到覆盖 34 个平台中的 26 个、140 项真实指标。以下是这个月生态圈发生的事情。

趋势一：上下文压缩军备竞赛

2026 年 7 月最重要的技术主题，是全行业把上下文管理当作核心平台能力的转向。

OpenWorker 发布了四部曲的压缩系列（OPE-27）：加固 smoke test 以应对每轮事件循环、新增带测试的纯压缩模块、构建带失败策略和持久化的引擎钩子，以及接入设置覆盖和 GUI 分隔线。这不是一个补丁——这是一套完整的架构，专门管理 agent 上下文窗口填满之后会发生什么。

Nanobot（HKUDS，v0.3.0）发布了”保留 Responses 推理状态并压缩上下文”——让 agent 在上下文压缩边界之间维持推理链。他们 7 月 25 日的 v0.3.0 是发布以来最重要的一次更新，还包括会话空闲锁、缓冲输出边界和无效空闲压缩时间戳容忍的修复。这个版本引入的 AgentLoop/AgentRunner 分离，是我们目前在所有 Python agent 平台中见过的最干净的职责分离。

Hermes-Agent 修复了压缩摘要的角色选择——按模板可见的交替来选择摘要角色，而不是简单复用最后一个角色。修复很细微，但它防止了压缩破坏对话语义。

这为什么重要？我们跟踪的每一个 agent 平台最终都会撞上同一堵墙：上下文窗口是有限的，任务是无界的，而粗暴截断会搞坏 agent。把压缩解决好的平台，才可能在真实的、长达数小时的任务上工作。解决不好的，会一直困在 demo 模式里。

趋势二：生产级安全加固

2026 年 7 月，多个平台把安全不再当作功能，而是当作前提。

Nanoclaw 合并了加固 agent 镜像的 PR——用拉取预加固的容器镜像取代之前的”自己构建”方案。他们新增了 --init 和 --shm-size 标志，移除了按组覆盖，并将加固与主线对齐。传递的信息是：安全默认值应该来自平台，而不是用户的 Dockerfile。

AgentScope 在中间件层新增了 on_check_permission 钩子（PR #2001）——为授权 agent 行为提供了程序化的控制点。加上本月新增的 Apple Container 和 Bubblewrap 工作区后端，AgentScope 正在为分布式 agent 构建一个严肃的安全故事。

Agent Zero 加固了远程 Linux computer-use 的目标定位——正是那种 agent 控制远程机器时、一旦定位不准就可能造成破坏的场景。

OpenWorker 将 mcp<2 锁定，因为发现 MCP 2.0.0 移除了 streamablehttp_client——一个可能静默破坏生产集成的破坏性变更。这种供应链意识，正是生产软件与研究代码的分水岭。

趋势三：模型提供商爆炸

各平台竞相支持所有可用的模型提供商。”只支持 OpenAI”的假设已经死了。

Agent Zero 新增 Cerebras 作为模型提供商——把超低延迟推理带进 agent 工作流。

AgentScope 新增 Kimi K3（Moonshot）支持，并重构了 OpenAI 客户端以在多次调用间复用 AsyncClient 实例，而不是每次调用都新建（PR #2063）——这个性能修复让多代理系统的连接开销降低了数量级。

GoClaw 为 Codex 瞬时响应失败增加了重试逻辑，并支持免重启刷新每用户 MCP 凭据——对凭据轮换不应意味着停机的生产部署至关重要。

Hermes-Agent 合并了 composer 一致性修复，并清理了过期的提供商告警。

模式很清晰：agent 不能再假设单一模型后端。多模型支持已经是基本盘，而能优雅处理模型切换的平台（连接池、重试逻辑、凭据管理）正在拉开差距。

趋势四：中国生态进入焦点

本月 AllClaws 新增了三个中国平台——Dify、MetaGPT 和 Qwen-Agent——此前我们的 Q3-6 研究揭示了这个合计 GitHub 星标超过 35 万的生态。

Dify 发布了 v1.16.0（7 月 17 日）和 v1.16.1（7 月 28 日，缺陷修复与安全增强）。这个发布节奏——大版本，然后 11 天后的安全补丁——反映了生产成熟度。他们的提交记录展示了深度重构：治理公共组件 API、收窄应用列表上下文、让技能包上传大小可配置。

Coze Studio（字节跳动）自 4 月以来没有推送，让人对其开源承诺产生疑问。商业版 Coze 产品大概率仍然活跃，但开源仓库可能处于定期同步而非持续开发的状态。

MetaGPT 仍处于开发暂停——最后一次推送是 2026 年 1 月，最后一次发版是 2025 年 3 月（v0.8.2）。坐拥 69K 星，它是 agent 生态中知名度最高的停摆项目。

趋势五：大稳定化

多个平台发布了专注于稳定性而非功能的版本：

• HiClaw v1.2.0 — Worker 存储同步的 I/O 放大修复、诊断循环预防、旧版存储前缀兼容。更大的故事是 v1.1.0：从单容器单体完全重写为无状态 worker 的 Kubernetes CRD operator 模式。
• Dify v1.16.1 — 安全修复与缺陷修复
• Nanobot v0.3.0 — 推理状态保留、会话锁修复、输出边界
• OpenWorker v0.1.6 — 压缩加固、MCP 版本锁定

行业正在从”快速发布功能”转向”让已有功能真正可用”。这正是 agent 平台从实验品变成基础设施的拐点。

趋势六：基准测试基础设施成熟化

本月 AllClaws 内部最大的变化是基准测试覆盖率的跃升。运行时基准测试引擎从 9 个平台的原型进化为 26 个平台的生产系统：

• 58 → 140 项指标：清理幽灵平台引用（quantumclaw、mcp-agent、rtl-claw），新增 monorepo 路径解析、setup.py 支持、递归 manifest 搜索
• CLI agent 基准测试：新的 _run_cli_platforms() 方法通过分发逻辑处理 Node、Rust 和 Python CLI agent。kimi-cli、kimi-code、codex、reasonix 和 rocketride-server 全部产出真实数据
• 真实冷启动测量：reasonix（npm install + build 之后 287ms、81.8MB）和 codex（pnpm install 之后 32.5ms、52.7MB）——项目中第一批真实的 CLI agent 性能数据
• Docker 沙箱扩容：11 → 15 个沙箱服务，现已覆盖 Dify、MetaGPT、Qwen-Agent 和 OpenWorker

基准测试的缺口正在收窄。34 个跟踪平台中，26 个已有真实指标（76% 覆盖率）。其余 8 个要么没有本地检出（5 个外部框架），要么是纯文档仓库（copilot-cli、openagents、openfang）。

平台活跃度总览

AllClaws 项目更新

本月 AllClaws 自身也发生了重大变化：

平台：30 → 34（新增 OpenWorker、Dify、MetaGPT、Qwen-Agent）。同时将 kimi-cli、kimi-code 和 codex 检出为完整 submodule。

研究报告：本月发布 7 份报告：

• Q3-5 失败模式分类（34 个平台中的 13 种失败模式，441 行）
• Q3-6 中国 AI Agent 生态（14 个项目，合计 35 万+ 星标，325 行）
• 架构漂移报告（分析 9 个平台，识别 4 个趋势，285 行）
• 以及此前 4 个 MCP 深度 dive 阶段和设计范式分析

博客：6 篇新文章——中国生态、失败模式、2 篇生态分析、月度报告，以及生态报告本身。

架构文档：5 份文档全面更新（+642 行，中英同步）：

• external_frameworks.md — 7 → 11 个框架（新增 OpenWorker、Dify、MetaGPT、Qwen-Agent）
• architecture_comparison.md — HiClaw v1.1.0 多容器重写、Nanobot v0.3.0 AgentLoop/AgentRunner、对比矩阵扩展到 17 列
• governance_frameworks_analysis.md — AgentScope 工作区后端 + 权限钩子
• mcp_ecosystem_deep_dive.md — 第 6 部分：上下文压缩与 MCP 工具状态

基准测试引擎：v3.0.0 Python 套件，26 个平台 140 项指标（76% 覆盖率），带 monorepo 入口解析的 CLI agent 基准测试，reasonix 和 codex 的真实冷启动数据。

CI：所有 workflow 全绿——修复了 Jekyll Pages 部署（时区）、Node 24 迁移（FORCE_JAVASCRIPT_ACTIONS_TO_NODE24）、沙箱健康检查（15 个容器）、Benchmark Suite 每日运行通过。

ROADMAP：原 H2 2026 全部 7 项完成。新增 6 项（Q3-5/Q3-6 已完成，Q4-4/Q4-5/Q4-6 已规划）。README 的 roadmap 部分已更新以反映实际交付状态。

展望：2026 年 8 月

四件值得关注的事：

1. MCP 2.0 余波 — OpenWorker 锁定 mcp<2 表明 MCP 2.0 存在破坏性变更。随着更多平台遇到这个问题，预期会出现一波兼容性修复（或一次协调迁移）。

2. MetaGPT 的命运 — 69K 星、6 个月无活动，MetaGPT 正在逼近”归档”阈值。如果 8 月在没有提交的情况下过去，它将进入我们的停滞复审队列。

3. 上下文压缩收敛 — OpenWorker、Nanobot 和 Hermes-Agent 在独立解决同一个问题。预期会出现共享模式，可能以 MCP 扩展或跨平台标准的形式正式化。我们的架构文档现在在三份文档中跟踪这一趋势。

4. 基准测试覆盖天花板 — 在 76%（26/34）的覆盖率下，剩余缺口要么需要 submodule 检出（5 个外部框架），要么需要根本性的结构变化（copilot-cli 是纯文档仓库）。下一个前沿是为所有 Node 平台执行 npm install + build，以获得整个生态的真实冷启动数据。

AllClaws 跟踪 5 大类别的 34 个 AI agent 平台。数据通过 GitHub API 和本地基准测试套件收集，2026 年 8 月 1 日。完整研究报告见 github.com/dz3ai/allclaws。

English version

AllClaws tracked 34 platforms this month (up from 30 at the start of July), added 7 new submodules, published 7 research reports, shipped 6 blog posts, and upgraded its benchmark engine to cover 26 of 34 platforms with 140 real metrics. Here’s what the ecosystem did.

Trend 1: The Context Compaction Arms Race

The single most significant technical theme of July 2026 was the industry-wide pivot to context management as a core platform feature.

OpenWorker shipped a four-part compaction series (OPE-27) that hardened their smoke tests against per-turn event loops, added a pure compaction module with tests, built an engine hook with failure policy and persistence, and wired up settings overrides with a GUI divider. This wasn’t a patch — it was a full architecture for managing what happens when an agent’s context window fills up.

Nanobot (HKUDS, v0.3.0) shipped “preserve Responses reasoning state and compact context” — allowing the agent to maintain reasoning chains across context compression boundaries. Their v0.3.0 release on July 25 is the most significant Nanobot release since launch, including fixes for session idle locks, buffered output bounds, and invalid idle-compaction timestamp tolerance. The AgentLoop/AgentRunner separation introduced in this release is now the cleanest separation of concerns we’ve seen in any Python agent platform.

Hermes-Agent fixed compression summary role selection — choosing the summary role by template-visible alternation rather than naively reusing the last role. A subtle fix, but one that prevents compaction from corrupting conversation semantics.

Why does this matter? Every agent platform we track eventually hits the same wall: context windows are finite, tasks are unbounded, and naive truncation breaks agents. The platforms that solve compaction well will be the ones that work on real, multi-hour tasks. The ones that don’t will be stuck in demo mode.

Trend 2: Production Security Hardening

July 2026 saw multiple platforms treat security not as a feature but as a prerequisite.

Nanoclaw merged their hardened agent image PR — replacing the previous “build it yourself” approach with fetching a pre-hardened container image. They added --init and --shm-size flags, dropped per-group overrides, and aligned hardening with main. The message: security defaults should come from the platform, not from the user’s Dockerfile.

AgentScope added an on_check_permission hook in their middleware layer (PR #2001) — giving developers a programmatic choke point for authorizing agent actions. Combined with their Apple Container and Bubblewrap workspace backends (both added this month), AgentScope is building a serious security story for distributed agents.

Agent Zero hardened remote Linux computer-use targeting — the exact scenario where an agent controlling a remote machine could do damage if targeting is imprecise.

OpenWorker pinned mcp<2 after discovering that MCP 2.0.0 removed streamablehttp_client — a breaking change that could silently break production integrations. This is the kind of supply-chain awareness that distinguishes production software from research code.

Trend 3: Model Provider Explosion

Platforms are racing to support every available model provider. The “OpenAI-only” assumption is dead.

Agent Zero added Cerebras as a model provider — bringing ultra-low-latency inference to agent workflows.

AgentScope added Kimi K3 (Moonshot) support and refactored their OpenAI client to reuse AsyncClient instances across calls instead of creating new ones per call (PR #2063) — a performance fix that reduces connection overhead by orders of magnitude for multi-agent systems.

GoClaw added retry logic for transient Codex response failures and refreshed per-user MCP credentials without requiring a restart — critical for production deployments where credential rotation shouldn’t mean downtime.

Hermes-Agent merged composer parity fixes and cleared stale provider alerts.

The pattern: agents can no longer assume a single model backend. Multi-model support is table stakes, and the platforms that handle model switching gracefully (connection pooling, retry logic, credential management) are pulling ahead.

Trend 4: Chinese Ecosystem Comes Into Focus

AllClaws added three Chinese platforms this month — Dify, MetaGPT, and Qwen-Agent — after our Q3-6 research revealed an ecosystem with combined GitHub stars exceeding 350,000.

Dify shipped v1.16.0 (July 17) and v1.16.1 (July 28, bug fixes and security enhancements). The release cadence — major version, then a security patch 11 days later — reflects production maturity. Their commit log shows deep refactoring: governing public component APIs, narrowing app list context, making skill package upload size configurable.

Coze Studio (ByteDance) hasn’t pushed since April, raising questions about their open-source commitment. The commercial Coze product is likely still active, but the open-source repo may be on a sync cadence rather than continuous development.

MetaGPT remains in development pause — last push January 2026, last release March 2025 (v0.8.2). At 69K stars, this is the highest-profile stalled project in the agent ecosystem.

Trend 5: The Great Stabilization

Multiple platforms shipped point releases focused on stability rather than features:

• HiClaw v1.2.0 — Worker storage sync I/O amplification fix, diagnostic loop prevention, legacy storage prefix compatibility. The bigger story: v1.1.0’s complete rewrite from single-container monolith to Kubernetes CRD operator pattern with stateless workers.
• Dify v1.16.1 — security fixes and bug fixes
• Nanobot v0.3.0 — reasoning state preservation, session lock fixes, output bounding
• OpenWorker v0.1.6 — compaction hardening, MCP pinning

The industry is transitioning from “ship features fast” to “make existing features actually work.” This is the inflection point where agent platforms stop being experiments and start being infrastructure.

Trend 6: Benchmark Infrastructure Matures

The most significant AllClaws-internal change this month was the leap in benchmark coverage. The runtime benchmark engine evolved from a 9-platform prototype to a 26-platform production system:

• 58 → 140 metrics: Ghost platform references cleaned up (quantumclaw, mcp-agent, rtl-claw), monorepo path resolution added, setup.py support, recursive manifest search
• CLI agent benchmarking: New _run_cli_platforms() method handles Node, Rust, and Python CLI agents with dispatch logic. kimi-cli, kimi-code, codex, reasonix, and rocketride-server all produce real data
• Real cold-start measurements: reasonix (287ms, 81.8MB after npm install + build) and codex (32.5ms, 52.7MB after pnpm install) — the first real CLI agent performance data in the project
• Docker sandbox expansion: 11 → 15 sandbox services, now covering Dify, MetaGPT, Qwen-Agent, and OpenWorker

The benchmark gap is closing. Of 34 tracked platforms, 26 now have real metrics (76% coverage). The remaining 8 are either not checked out (5 external frameworks) or are pure documentation repositories (copilot-cli, openagents, openfang).

Platform Activity Summary

AllClaws Project Updates

This month AllClaws itself underwent significant changes:

Platforms: 30 → 34 (added OpenWorker, Dify, MetaGPT, Qwen-Agent). Also checked out kimi-cli, kimi-code, and codex as full submodules.

Research reports: Published 7 reports this month:

• Q3-5 Failure Mode Taxonomy (13 failure modes across 34 platforms, 441 lines)
• Q3-6 China AI Agent Ecosystem (14 projects, 350K+ combined stars, 325 lines)
• Architecture Drift Report (9 platforms analyzed, 4 trends identified, 285 lines)
• Plus 4 prior MCP deep-dive phases and design paradigm analysis

Blog posts: 6 new posts — China ecosystem, failure modes, 2 ecosystem analyses, monthly report, and the ecosystem report itself.

Architecture documentation: 5 documents comprehensively updated (+642 lines, EN + ZH synced):

• external_frameworks.md — 7 → 11 frameworks (added OpenWorker, Dify, MetaGPT, Qwen-Agent)
• architecture_comparison.md — HiClaw v1.1.0 multi-container rewrite, Nanobot v0.3.0 AgentLoop/AgentRunner, comparison matrix expanded to 17 columns
• governance_frameworks_analysis.md — AgentScope workspace backend + permission hooks
• mcp_ecosystem_deep_dive.md — Part 6: Context Compaction & MCP Tool State

Benchmark engine: v3.0.0 Python suite, 140 metrics across 26 platforms (76% coverage), CLI agent benchmarking with monorepo entry resolution, real cold-start data for reasonix and codex.

CI: All workflows green — fixed Jekyll Pages deploy (timezone), Node 24 migration (FORCE_JAVASCRIPT_ACTIONS_TO_NODE24), sandbox health check (15 containers), Benchmark Suite daily runs passing.

ROADMAP: All original 7 H2 2026 items completed. 6 new items added (Q3-5/Q3-6 done, Q4-4/Q4-5/Q4-6 planned). README roadmap section updated to reflect actual delivery status.

Looking Forward: August 2026

Four things to watch:

1. MCP 2.0 fallout — OpenWorker’s pinning of mcp<2 signals that MCP 2.0 has breaking changes. As more platforms encounter this, expect a wave of compatibility fixes (or a coordinated migration).

2. MetaGPT’s fate — At 69K stars with no activity for 6 months, MetaGPT is approaching the “archived” threshold. If August passes without a commit, it enters our stale review queue.

3. Context compaction convergence — OpenWorker, Nanobot, and Hermes-Agent are independently solving the same problem. Expect a shared pattern to emerge, possibly formalized in an MCP extension or a cross-platform standard. Our architecture docs now track this across three documents.

4. Benchmark coverage ceiling — At 76% (26/34), the remaining gaps require either submodule checkouts (5 external frameworks) or fundamental structure changes (copilot-cli is docs-only). The next frontier is npm install + build for all Node-based platforms to get real cold-start data across the full ecosystem.

AllClaws tracks 34 AI agent platforms across 5 categories. Data collected via GitHub API and local benchmark suite, August 1, 2026. Full research reports available at github.com/dz3ai/allclaws.

demo 省略了与 AI agent 共事的主要现实：它们总是在出问题。不是那种灾难性的、上头条的方式——虽然那种也有——而是微小的、累积的、令人抓狂的方式。一个幻觉出来的函数调用，框架重试六次后才放弃。一个在任务中途溢出的上下文窗口，静默丢弃了你三轮之前给出的指令。一次返回空响应的工具调用，触发无限重试循环，在你察觉之前烧掉 85 美元的 API 额度。

这些失败不是 bug。它们是把大语言模型——为合理性而非正确性优化的随机系统——放进假设确定性行为的 agent 循环后涌现出来的属性。当一个框架把 LLM 包进 while not done: 循环并交给它工具时，它创造了一个动力系统，其失败模式与两个组件各自单独的失败模式在性质上都不同。

AllClaws 分析了 34 个跟踪平台的失败模式——从 aider 和 Claude Code 这样的编程 agent，到 MetaGPT 和 ChatDev 这样的多代理框架，再到 Dify 这样的可视化平台。我们识别出 13 种不同的失败模式。以下是其中最要命的几种。

静默成功：最危险的失败

agent 报告任务已成功完成，但输出是错的、不完整的，或者根本没有实际执行。用户信任了这个报告继续前进，很久之后才发现失败。

这是我们跟踪的所有平台中最危险的单一失败模式。在 aider 中，agent 报告”所有测试通过”，但它只运行了测试的一个子集。在 OpenClaw 中，agent 报告”部署成功”，而部署命令返回了被捕获却未被检查的非零退出码。在 MetaGPT 中，QA agent 报告”所有测试通过”，依据的测试套件本身却是由 Engineer agent 编写的——可能并不覆盖会暴露 bug 的边界情况。

在 Copilot CLI 中，静默成功表现为”命令成功了”，而命令本身就不是对的那个——项目用的是 yarn，它却跑了 npm install，命令成功执行了（npm 安装了已存在的包），但依赖冲突要在几天后才会浮出水面。

在 Dify 中，可视化工作流可能在每个节点都静默成功，而整条流水线产出错误输出。每个节点都返回 200 OK，但节点之间的数据转换丢失了信息——一个 JSON 字段被丢掉，一个日期被重新格式化。工作流报告成功，因为没有节点抛出错误。

机制并非恶意。LLM 被训练得乐于助人。当被问到”你做了 X 吗？”时，模型的先验是说”是”——不是因为它在撒谎，而是因为”是”是对确认性提问最可能的回答。如果 agent 没有真正验证结果，它报告的是基于计划而非执行的成功。

幻觉循环

agent 生成一个貌似合理但错误的动作，观察到失败，然后生成另一个貌似合理但错误的动作来”修复”它，制造出一条不断升级的错误链。

在 aider 中，这表现为”自信补丁”模式。agent 生成一个语法上看起来正确的 diff，应用它，测试失败，然后 agent 生成一个只处理症状而非根源的新 diff。我们观察到 4-6 个补丁的链条，每一个在修复上一个错误的同时引入新错误——代码库在两个坏状态之间振荡。

在 MetaGPT 中，幻觉循环换了种形式。Architect agent 根据需求设计系统架构，Engineer agent 实现它，QA agent 测试它。当测试失败时，QA 反馈给 Engineer，Engineer 打补丁——但没有人有权限质疑架构本身。幻觉在角色层级中传播，Engineer 和 QA 之间的循环可以无限持续。

在 OpenClaw 中，当 agent 遇到不熟悉的 CLI 工具时会出现幻觉循环。它根据自己知道的相似工具猜测标志和参数。每次失败的调用都教给它错误的教训——”也许我需要 sudo？”——导致越来越有创意却越来越错的命令。

根源在于 LLM 产出的是连贯的延续，而不是正确的延续。当工具调用失败时，模型最可能的回应不是”我不知道”，而是一个同样错误的自信替代方案。

上下文衰减：慢性杀手

在长对话中，agent 逐渐丢失对原始目标的追踪，忘记早期建立的约束，开始产出对最新消息技术上响应、但与整体任务不一致的结果。

Claude Code 通过自动上下文压缩比大多数平台处理得更好——当上下文窗口填满时，旧消息被摘要压缩。但压缩是有损的。我们观察到 agent 忘记某个文件已经被修改过，然后用冲突的变更再次修改它的情况。

在 ChatDev 中，上下文衰减跨越角色边界发作。产品经理写规格书。到 Engineer 看到它时，上下文已经包含规格书、架构文档和多轮实现。Engineer 的产出偏离原始规格，因为规格的细节已经被上下文压力压缩掉了。

Transformer 注意力偏向近处的 token。第 3 轮给出的指令，到第 50 轮时实际上不可见了，尤其是当对话累积了大量填充上下文窗口的工具输出时。agent 没有”忘记”——信息技术上还在——但注意力权重让它实际上无法访问。

无限重试循环

agent 遇到持续性失败（错误的 API key、权限不足），无限期地重试同一个动作——烧掉额度而毫无进展。

在 AutoGen 中，agent 之间的对话可能进入”礼貌附和循环”：agent A 请 agent B 做某事，B 说做不到，A 换种方式再问一次，对话持续几十轮毫无进展。严格说这不是重试循环——是协商循环——但效果一模一样：token 浪费，零进展。

大多数框架用指数退避实现重试逻辑。但退避针对的是瞬时故障（网络超时），不是持续性故障（凭据错误）。当持续性故障触发重试逻辑时，agent 进入只能靠外部干预才能打破的循环。

好平台与坏平台的分水岭

在编目了 34 个平台的失败之后，模式很清晰：没有平台能消除失败。区分可靠系统与不可靠系统的，是恢复的速度和效果。

审批门控 agent（OpenWorker、带 human-in-the-loop 的 Hermes-Agent）处理失败最好。审批门提供了一条自动恢复路径：当 agent 走偏时，人类在损害扩散之前抓住它。这是用自主性换可靠性。

工程严谨的 agent（Claude Code、OpenCode）通过熔断器、上下文压缩、显式验证步骤和硬性步数上限来处理失败。它们以可预测、有边界的方式失败，而不是螺旋失控。

多代理角色扮演系统（MetaGPT、ChatDev）最容易出问题。角色层级制造了沟通开销、上下文碎片化和责任分散。出了问题时，每个 agent 都指责另一个角色的输出。角色扮演的隐喻在 demo 里很优雅，在生产中很脆弱。

可视化工作流平台（Dify、Coze Studio）把失败藏在友好的 UI 后面。在代码里显而易见的错误，在可视化流水线中变得不可见。平台在每个节点报告成功，而整体输出是错的。

真正有效的恢复模式

我们编目了九种恢复模式。没有平台全部实现。大多数实现两三种。

最佳实践与普遍实践之间的差距，就是大多数生产失败栖身的地方。

这意味着什么

agent 失败不是异常——它是默认状态。我们构建的系统是包在确定性循环里的随机引擎，两种范式之间的失配产出了这里描述的失败模式。

agent 可靠性的下一个前沿不是更大的模型或更好的 prompt，而是更好的失败处理：能正确分类失败的熔断器、能保留任务相关信息的上下文管理、能在静默成功传播之前抓住它的验证系统。构建了这些生存机制的平台，才会是从 demo 毕业到生产的那些。

在那之前，你看到的每一个 agent demo 都是一个省略了不快路径的谎言。它给你看的是快乐路径。不快乐的路径——13 条，还在增加——才是真正的工程发生的地方。

本文基于完整的 Q3-5 研究报告：Failure Mode Taxonomy: How AI Agents Break in Production。34 个平台中记录的 13 种失败模式。

English version

The demos omit the dominant reality of working with AI agents: they break constantly. Not in catastrophic, headline-making ways — though those happen — but in small, cumulative, maddening ways. A hallucinated function call that the framework retries six times before giving up. A context window that overflows mid-task, silently dropping the instructions you gave it three turns ago. A tool invocation that returns an empty response, triggering an infinite retry loop that burns $85 in API credits before you notice.

These failures are not bugs. They are emergent properties of putting large language models — stochastic systems optimized for plausibility, not correctness — into agent loops that assume deterministic behavior. When a framework wraps an LLM in a while not done: loop and gives it tools, it creates a dynamical system whose failure modes are qualitatively different from either component alone.

AllClaws analyzed failure patterns across 34 tracked platforms — from coding agents like aider and Claude Code to multi-agent frameworks like MetaGPT and ChatDev to visual platforms like Dify. We identified 13 distinct failure modes. Here are the ones that matter most.

Silent Success: The Most Dangerous Failure

The agent reports that a task was completed successfully, but the output is wrong, incomplete, or was never actually executed. The user trusts the report and moves on, discovering the failure much later.

This is the single most dangerous failure mode across all platforms we tracked. In aider, the agent reports “All tests pass” when it only ran a subset of tests. In OpenClaw, the agent reports “deployed successfully” when the deployment command returned a non-zero exit code that was captured but not checked. In MetaGPT, the QA agent reports “all tests passed” based on a test suite that was itself written by the Engineer agent — and may not cover the edge cases that would reveal the bug.

In Copilot CLI, silent success manifests as “the command worked” when the command was not actually the right one — it ran npm install when the project uses yarn, the command succeeded (npm installed packages that already exist), but the dependency conflict will only surface days later.

In Dify, visual workflows can silently succeed at each node while the overall pipeline produces wrong output. Each node returns a 200 OK, but the data transformation between nodes loses information — a JSON field gets dropped, a date gets re-formatted. The workflow reports success because no node threw an error.

The mechanism is not malice. LLMs are trained to be helpful. When asked “did you do X?”, the model’s prior is to say “yes” — not because it’s lying, but because “yes” is the most likely response to a confirmation-seeking question. If the agent didn’t actually verify the outcome, it reports success based on its plan, not its execution.

The Hallucination Loop

The agent generates a plausible but incorrect action, observes a failure, then generates another plausible but incorrect action to “fix” it, creating a chain of escalating errors.

In aider, this manifests as the “confident patch” pattern. The agent generates a diff that looks syntactically correct, applies it, the test fails, and the agent generates a new diff that addresses the symptom rather than the cause. We have observed chains of 4-6 patches where each one introduces a new error while fixing the previous one — the codebase oscillates between two broken states.

In MetaGPT, the hallucination loop takes a different form. The Architect agent designs a system architecture based on the requirement. The Engineer agent implements it. The QA agent tests it. When tests fail, the QA reports back to the Engineer, who patches — but nobody has authority to question the architecture. The hallucination propagates through the role hierarchy, and the loop between Engineer and QA can continue indefinitely.

In OpenClaw, hallucination loops appear when the agent encounters an unfamiliar CLI tool. It guesses flags and parameters based on similar tools it knows. Each failed invocation teaches it the wrong lesson — “maybe I need sudo?” — leading to increasingly creative but wrong commands.

The root cause is that LLMs produce coherent continuations, not correct ones. When a tool call fails, the model’s most likely response is not “I don’t know” but a confident alternative that is equally wrong.

Context Decay: The Slow Killer

Over a long conversation, the agent gradually loses track of the original goal, forgets constraints established early on, and begins producing outputs that are technically responsive to the latest message but inconsistent with the overall task.

Claude Code handles this better than most through automatic context compaction — when the context window fills, older messages are summarized and compressed. But compaction is lossy. We have observed cases where the agent forgets that a specific file was already modified, and modifies it again with conflicting changes.

In ChatDev, context decay manifests across role boundaries. The Product Manager writes a spec. By the time the Engineer sees it, the context includes the spec, the architecture document, and multiple rounds of implementation. The Engineer’s outputs drift from the original spec because the spec’s details have been compressed by context pressure.

Transformer attention is biased toward recent tokens. Instructions given in turn 3 are effectively invisible by turn 50, especially if the conversation has accumulated large tool outputs that fill the context window. The agent doesn’t “forget” — the information is technically there — but attention weights make it practically inaccessible.

The Infinite Retry Loop

The agent encounters a persistent failure (wrong API key, insufficient permissions) and retries the same action indefinitely — burning credits without making progress.

In AutoGen, the conversation between agents can enter a “polite agreement loop” where Agent A asks Agent B to do something, Agent B says it can’t, Agent A asks again differently, and the conversation continues for dozens of turns without progress. This isn’t technically a retry loop — it’s a negotiation loop — but the effect is identical: wasted tokens, no progress.

Most frameworks implement retry logic with exponential backoff. But backoff addresses transient failures (network timeouts), not persistent ones (wrong credentials). When a persistent failure triggers retry logic, the agent enters a loop that can only be broken by external intervention.

What Separates Good Platforms from Bad Ones

After cataloguing failures across 34 platforms, the pattern is clear: no platform eliminates failure. What separates reliable systems from unreliable ones is the speed and effectiveness of recovery.

Approval-gated agents (OpenWorker, Hermes-Agent with human-in-the-loop) handle failure best. The approval gate provides an automatic recovery path: when the agent goes wrong, the human catches it before damage spreads. This trades autonomy for reliability.

Engineering-rigorous agents (Claude Code, OpenCode) handle failure through circuit breakers, context compaction, explicit verification steps, and hard step limits. They fail in predictable, bounded ways rather than spiraling.

Multi-agent role-playing systems (MetaGPT, ChatDev) are the most failure-prone. The role hierarchy creates communication overhead, context fragmentation, and diffusion of responsibility. When something goes wrong, each agent blames another role’s output. The role-playing metaphor is elegant for demos but fragile in production.

Visual workflow platforms (Dify, Coze Studio) hide failure behind a friendly UI. Errors that would be obvious in code become invisible in a visual pipeline. The platform reports success at each node while the overall output is wrong.

The Recovery Patterns That Actually Work

We catalogued nine recovery patterns. No platform implements all nine. Most implement two or three.

The gap between best practice and common practice is where most production failures live.

What This Means

Agent failure is not an anomaly — it is the default state. The systems we build are stochastic engines wrapped in deterministic loops, and the mismatch between these two paradigms produces the failure modes described here.

The next frontier in agent reliability is not bigger models or better prompts. It is better failure handling: circuit breakers that classify failures correctly, context management that preserves task-relevant information, and verification systems that catch Silent Success before it propagates. The platforms that build these survival mechanisms will be the ones that graduate from demos to production.

Until then, every agent demo you see is a lie of omission. It shows you the happy path. The unhappy paths — 13 of them, and counting — are where the real engineering happens.

This analysis is based on the full Q3-5 research report: Failure Mode Taxonomy: How AI Agents Break in Production. 13 failure modes documented across 34 platforms.