OpenClaw：先驱准备成先烈

本文是 OpenClaw 架构在应用层的风险 的延伸。Anthropic 发布了 Managed Agents 架构，验证我们的一些判断判断，我们继续扩展讨论一下。

我们的判断被验证了

上一篇文章的核心论点是：OpenClaw 的 Runtime（Gateway、Agent Runtime、Tool Use、Sandbox）会成为标准化的基础设施，而 State（Memory、Skill、Knowledge Base、Profile）才是不可替代的核心资产。

当时我们指出了 OpenClaw 架构的一个结构性风险：Gateway 同时承担了编排（Harness）和状态管理（Session）的职责，是一个"三位一体"的单体设计。 这在个人助手场景下没有问题，但一旦进入企业级生产环境，就会暴露致命缺陷——

想象这样一个场景：你的 AI Agent 正在执行一个长达数小时的复杂任务——分析代码库、重构模块、运行测试。一切顺利，直到运行 Agent 的 Gateway 容器突然崩溃。因为状态只活在内存里，Agent 的推理状态、会话数据、工具调用的中间结果——全部丢失。

崩溃即失忆。

现在，Anthropic 的 Managed Agents 发布了。它的架构严格遵循了**"状态完全外部化"和"计算环境用完即抛"**的原则——恰恰就是我们在上一篇文章中预言的方向，而且走得更远：它不仅把 Runtime 和 State 解耦了，还把 Runtime 本身拆成了三层虚拟化组件。

更令人兴奋的是，我们在上一篇文章中提到的"静态部分"（CLAUDE.md、MEMORY.md、Skill 文件），在这个新架构中找到了清晰的位置——文件系统。文件系统不是 Agent 的"器官"，而是它交互的对象和规则的来源。作为用户，你只需要管理文件系统这个静态层，所有动态配置的工作，完全由企业服务提供。

下面，我们来深入拆解这个新架构。

病根：什么是"状态"？为什么它让架构变复杂？

大语言模型（LLM）本身是无状态的（Stateless）——它把每一次请求都当作全新的独立事件来处理，既不记得上一轮对话，也不知道当前任务进行到哪一步。

所以，要让 Agent 具备连续性、记忆和上下文感知能力，就必须有外部机制来维护状态。在现代 AI Agent 架构中，"状态"主要包含四个核心维度：

1. 对话与会话记忆（Session & Conversation Memory）

这是最基础的状态，包含用户输入、模型的推理过程（思维链）以及工具调用的返回结果。在现代架构中，这种状态通常被处理为一个只能追加的事件日志（Append-only Event Log），作为系统单一的真相来源。

2. 执行与工作流进度（Execution & Workflow State）

当 Agent 执行一个多步骤任务时，系统必须记录它当前处于哪个阶段。这包括：

• 状态机（State Machines）：记录 Agent 是处于"就绪"、"忙碌"还是"等待人类审批"。
• 状态追踪变量（State Tracking Variables）：记录哪些子任务已完成、哪些正在排队、以及工具调用的中间结果。

如果没有这些状态，Agent 在遇到报错或被中断后就无法从断点恢复，只能从头开始。

3. 上下文与持久化知识（Contextual & Persistent Knowledge）

• 短期工作状态：当前上下文窗口中正在活跃使用的文件内容和对话。
• 长期记忆：跨越多个会话持久存在的偏好设置、历史决策、项目规则（如 CLAUDE.md 或 MEMORY.md 索引文件），以及存在向量数据库中的上下文。

4. 环境与物理工作区状态（Environment & Workspace State）

Agent 在本地或沙盒中维护的独立工作区（Workspaces）和状态目录（State directories），以及文件系统的快照（Checkpoints）——在 Agent 修改文件前保存当前状态，以便出错时可以回滚。

旧架构：OpenClaw 的"三位一体"单体设计

理解了状态的含义，再来看 OpenClaw 的架构，问题就一目了然了。

如果将 OpenClaw 的设计映射到现代解耦架构中，它的 Gateway 其实是 Harness（编排层）与 Session（状态/记忆）高度耦合的混合体：

作为 Harness 的职责： Gateway 充当"操作胶水"（Operational Glue），负责管理多智能体路由、连接各种外部聊天应用（通道）、触发代理循环以及调度插件和工具。

作为 Session 的职责： Gateway 是一个 "Always-on（始终在线）"的常驻服务，负责在本地维护独立的工作区、状态目录和会话的持久性。

这种"一个常驻进程同时持有状态和编排逻辑"的设计，非常适合 OpenClaw 所定位的个人助手信任边界（Personal Assistant Trust Boundary）——即单用户在本地控制网关和工具。但在企业级生产环境中，它有三个致命缺陷：

• 崩溃即失忆： 如果 Gateway 容器崩溃，代理的推理状态和会话数据就会丢失——因为状态只活在内存里。
• 无法横向扩展： 因为状态被锁定在常驻进程内部，系统无法通过增加服务器来处理高并发请求。
• 安全边界模糊： 编排逻辑、状态存储和工具执行混在同一进程中，缺乏明确的信任边界。

这就是为什么架构演进的核心方向是——把状态从进程中剥离出来。

新架构：三层解耦

现代生产级 Agent 架构（以 Anthropic 的 Managed Agents 为代表）用一个简洁的三层解耦，彻底解决了上述问题：

三层之间的协作方式是：

1. Session 是唯一的真相来源。所有对话内容、执行进度、工具调用和中间结果，都会被写入 Session。它完全独立于大模型的上下文窗口——无状态的 Harness 会根据当前需要，动态决定从 Session 中抽取哪些信息喂给模型。

2. Harness 不持有任何状态。即使正在执行任务的 Harness 实例突然崩溃，也无所谓——新的实例可以随时读取 Session 日志，准确知道任务卡在了哪一步，并无缝接管工作。这让系统实现了轻松的横向扩展。

3. Sandbox 是临时的。只有当 Agent 实际需要执行代码或调用工具时，沙盒才会被启动；空闲时不消耗任何资源。执行完毕后即被销毁。

深入 Session：不可变的外部记忆

在三层解耦架构中，Session 模块被定义为系统的持久化记忆（Durable Memory），它是整个系统唯一的单一事实来源（Single source of truth）。

Session 的本质是一个只能追加的事件日志（Append-only Event Log），它完整记录了 Agent 发生的所有事情——用户的输入、模型的思考过程、工具的调用指令以及工具返回的中间结果。在 Claude Code 的本地实现中，这些日志通常被写入纯文本的 JSONL 文件中。

Session 通过以下几个核心机制，彻底颠覆了传统的"进程内状态管理"：

1. 作为"外部上下文"（External Context），解除大模型窗口限制

传统的 Agent 将状态直接堆砌在 LLM 的上下文窗口中，导致长周期任务很快就会让上下文溢出崩溃。Session 将状态存放在大模型上下文窗口之外——无状态的 Harness 充当过滤器，动态决定从 Session 日志中提取哪些相关事件，经过转换后喂给模型。这干净利落地将"可恢复的存储"与"上下文工程"分离开来。

2. 赋予 Harness"无状态"特性与完美的崩溃恢复

因为所有的进度和状态都实时写入了外部的 Session 日志，Harness 本身变成了完全无状态的。如果执行任务的容器突然崩溃，任何一个新的 Harness 实例都可以随时接管这个 Session，读取事件日志并准确无误地从断点继续工作。这使得横向扩展变得轻而易举。

3. 支持高级状态操作：时间旅行与并行分支

因为 Session 是一个不可变的事件日志流，它支持极其复杂的系统级状态操作：

• 回滚/撤销（Rewinding）： Agent 可以像时间旅行一样，回退到日志中的特定事件节点。例如结合文件快照（Checkpoints），可以随时撤销 Agent 产生的错误代码修改。
• 分支/切片（Slicing/Forking）： 可以对 Session 日志进行切片以支持并行处理，或者使用类似 --fork-session 的指令从当前对话进度"分叉"出一个全新的 Session，让 Agent 在不影响原会话的情况下尝试另一种解决思路。

4. 带来极致的性能提升

将状态管理从执行和编排中抽离出来，不仅提高了稳定性，还带来了巨大的性能收益。根据 Anthropic 的数据，这种架构解耦使模型生成首个 Token 的时间（TTFT）中位数（p50）降低了约 60%，而代表极端延迟的尾部延迟（p95）更是下降了 90% 以上。

5. 完整的审计与调试轨迹

传统的单体 Agent 一旦出错，由于内部状态不透明，几乎无法调试。而 Session 作为一个详尽的事件日志，自然形成了一条完美的审计轨迹（Audit Trail）。开发者可以确切知道在任务的哪一秒、Agent 调用了哪个工具、得到了什么报错，从而让不可预测的 AI 行为变得可追踪、可诊断。

Session 用**"不可变的外部事件日志"替代了传统的"内存变量与常驻进程"**——它不仅是 Agent 的记忆硬盘，更是让 Agent 能够实现高可用、高并发和企业级安全隔离的基石。

深入 Harness：无状态编排器内部有什么？

现代的 Harness 被定义为**"无状态的控制引擎"**（Stateless Orchestrator）。它本身不包含 UI、不包含底层数据库、也不包含代码的运行环境。它的核心是调度、决策和护栏。

根据 Claude Code 泄露的 52 万行源码，Harness 内部主要由以下核心模块构成：

1. 查询与编排引擎（Query Engine）

这是 Harness 真正的大脑——源码中高达 4.6 万行。它负责处理所有的大语言模型 API 调用、Token 流式传输、速率限制处理，以及核心的**"代理循环"**（Agentic Loop）。它决定了 Agent 在执行任务时的"思考→行动→观察"决策流。

2. 多级上下文压缩系统（Context Management）

Harness 负责在上下文窗口即将耗尽时进行动态压缩，确保长期任务不会崩溃。它包含三个层级：

• 微压缩（MicroCompact）：零 API 成本清理旧输出。
• 自动压缩（AutoCompact）：保留 Token 缓冲并生成结构化摘要。
• 全局压缩（Full Compact）：压缩整个对话并重新注入核心文件。

3. 工具框架与权限网关（Tool Framework & Permission Gates）

源码约 2.9 万行。所有工具在这里被严格定义。需要注意的是：Harness 并不执行工具，而是验证工具的 Schema 和权限。它负责实施权限拦截（例如区分单纯的文件读取和高风险的 Bash 写入），并在工具执行失败时提供结构化的错误恢复机制，而不是让系统直接崩溃。

深入 Sandbox：零信任的执行环境

执行环境（通常被称为沙盒 Sandbox 或"手" Hands）是纯粹的、一次性的代码和命令执行场所。

1. 一次性计算资源（Disposable Execution）

这是一个极其轻量级的容器或微虚拟机。它仅在 Agent 真正需要执行代码或工具时才启动（延迟初始化），空闲时不消耗资源。企业只需要为实际处于活跃计算状态的时间买单。

2. 物理隔离的工具执行面

它包含底层操作系统环境（如 Linux/WSL 环境）、文件系统读写能力、网络访问能力，以及实际执行 Python、Bash 等脚本的运行时（Runtime）。

3. 极端的"零凭证"安全架构

这是整个架构中最值得强调的设计：执行环境中绝对没有任何核心凭证（Credentials）。

由于架构的分离，Git 令牌被安全地接线在初始化阶段，OAuth 令牌被保存在 Harness 层的安全金库（Vault）中，只能通过作用域代理访问。即使沙盒中的代码执行被恶意破坏——例如安装了带有木马的 npm 包——攻击者也无法窃取 Agent 的核心凭证。而且沙盒随后就会被彻底销毁，攻击面被自动清除。

4. 补充说明：Sandbox之外也有“工具”

Anthropic 的公式中明确指出："双手（Hands）= Sandbox + Tools"。这里的 Tools 并不局限于本地文件系统的读写，它包括了 Agent 与整个外部世界的连接。

**MCP（Model Context Protocol，模型上下文协议）**是现代 Agent 架构中不可或缺的基础设施：

• AI 的"USB-C 接口"：MCP 是一个开源的通用协议，专门用于将 Agent 与外部数据源、企业内部系统（数据库、Slack、CRM）以及远程 API 连接起来。

• 与 Sandbox 并列的"手"：如果说 Sandbox 是 Agent 在本地干活的手，那么 MCP 服务器就是 Agent 在云端和企业内网干活的手。Harness 并不关心底层是本地 Bash 脚本还是远端 MCP 服务器，它只需要通过统一的接口下发指令（如 execute(name, input) -> string）。

• 安全与能力的解耦：通过 MCP，Agent 可以查询结构化数据库或企业知识库，而无需将这些外部系统放入 Sandbox 中。这使得 Agent 的触角可以无限延伸，而不增加本地系统的风险。

收尾：三层解耦 + 文件系统 = 最终形态

回到开篇的判断：Runtime 标准化之后，真正的差异化价值在 State。

现在，Anthropic 的 Managed Agents 把这个判断变成了现实——而且比我们预想的更彻底。Runtime 不是一个模块，而是被拆成了 Harness（大脑）、Session（记忆）、Sandbox（双手）三层，每层各归其位。

但还有一个关键问题：作为用户，你到底需要管理什么？

答案是：文件系统。

文件系统不属于 Agent 自身的"器官"，而是它交互的对象和规则的来源。它与三大模块的关系是：

• 文件系统是 Harness 的"规则读取源"。 当 Agent 启动时，Harness 会扫描项目文件系统中的 .claude/ 目录，读取 CLAUDE.md（项目级指令）、MEMORY.md（持久化索引）、各类 SKILL.md 文件，将它们作为静态规则动态组装到大模型的系统提示词中。
• 文件系统是 Sandbox 的"操作对象"。 Agent 的主要工作是修改代码、读取日志、生成文件。Harness 向 Sandbox 下发指令，Sandbox 直接在文件系统中执行读写操作。修改前，系统甚至会在本地文件系统打快照（Checkpoints），以便随时回滚。
• 文件系统是 Session 的"物理存储介质"（在本地架构中）。 在云端托管架构中，Session 存在于云端数据库。但在本地运行的 CLI 工具中，Session 状态就是以 JSONL 文件的形式存储在文件系统里（如 ~/.claude/projects/ 目录下）。Agent 的长期记忆同样基于文件存储。

这就是最终形态：系统被严格解耦为三大虚拟化组件（Harness、Session、Sandbox），而用户通过文件系统来管理 Skill 和项目规则——因为文件系统是开发者最熟悉、最易于进行版本控制（Git）的工作区。

作为用户，你只需要管理文件系统这个静态层。"动态"配置的工作——编排、调度、安全隔离、崩溃恢复、横向扩展——完全由企业服务提供。

这正是我们在上一篇文章中预言的未来："龙虾身子"被基础设施化了，用户只需要带着自己的"龙虾脑子"——以文件的形式——随时迁移，随时使用。 预期一致，非常好。