一、OpenClaw 是什么？一个执行框架的典型样本

在深入讨论之前，我们需要先明确一个前提：OpenClaw 不是某个单一产品的名称，而是一类 Agent 执行框架的代表。在这个领域，有 LangChain、LangGraph、CrewAI、AutoGen、Semantic Kernel、Spring AI 等数十个框架，它们虽然在 API 设计和编程范式上各有差异，但解决的核心问题是相同的：让 Agent 能跑起来。

为了方便讨论，我们用 OpenClaw 作为这类执行框架的统称和代表。如果你已经接触过任何一个 Agent 开发框架，你应该对以下模式非常熟悉。

第一步，定义一个或多个 Agent，每个 Agent 有一个系统 Prompt 和一组可用的 Tool 或 Skill。第二步，Agent 接收用户输入，调用大模型进行推理。第三步，大模型返回一个决策：调用某个 Tool，或者直接回复用户。第四步，框架执行 Tool 调用，将结果返回给 Agent。第五步，Agent 继续推理，直到任务完成或达到终止条件。

这个循环看起来简单，但实际上包含了大量的工程细节：流式响应、工具调用解析、多轮对话管理、状态持久化、错误处理、重试逻辑、并行执行。OpenClaw 这类框架的价值，就在于把这些通用问题封装起来，让开发者不需要从零开始实现一个 Agent 运行时。

OpenClaw 解决了什么问题？简单说：它让 Agent 从理论上可行变成了实际能运行。

但能运行不等于能上线。当我们把目光从跑起来转向跑得稳、跑得安全、跑得可控时，OpenClaw 这类框架的局限性就开始浮现了。这正是本章要讨论的核心：OpenClaw 解决的是执行层的问题，而 MCP 解决的是协议层的问题。两者不是替代关系，而是不同层次的互补关系。

二、OpenClaw 解决的核心问题：让 Agent 能跑起来

我们先充分肯定 OpenClaw 这类框架的价值。没有它们，今天绝大多数 Agent 应用根本不可能存在。

问题一：大模型不知道怎么调用工具

大模型本质上是文本生成模型。你给它一个 Prompt，它生成一段文本。要让大模型调用工具，你需要教会它用一种结构化的方式表达调用意图，通常是用 JSON 或类似的格式。

OpenClaw 封装了这种工具调用格式的定义和解析。你只需要用框架提供的 API 注册 Tool，框架会自动生成对应的工具描述，然后自动解析大模型返回的调用指令，将其转换成实际的函数调用。如果没有这个能力，每个开发者都要手写 Prompt 来教大模型如何输出 JSON，然后手写解析器来解析输出，不仅繁琐，而且极易出错。

问题二：多轮对话中的状态管理

Agent 不是一问一答的。一个复杂的任务可能需要多轮推理，每一轮 Agent 都可能调用多个工具，每个工具调用都会产生新的上下文。OpenClaw 提供了内置的消息历史管理和状态持久化机制，开发者不需要自己维护对话状态。

问题三：工具调用的编排和执行

一个 Agent 可能在一次推理中决定调用多个工具，这些工具可能串行执行，也可能并行执行。OpenClaw 提供了工具调度的基础设施：它负责按顺序或并发执行工具，收集结果，然后将结果返回给 Agent 进行下一轮推理。

问题四：与不同大模型厂商的适配

OpenAI、Anthropic、Google、Azure，每个大模型厂商的 API 格式、工具调用规范、流式响应格式都不完全相同。OpenClaw 提供了统一的抽象层，开发者可以切换底层模型而无需重写 Agent 逻辑。

问题五：流式响应和用户体验

大模型生成文本需要时间。流式响应可以让用户逐字看到生成内容，而不是等待完整响应。OpenClaw 封装了流式处理的复杂性，开发者只需要调用几个简单的 API。

小结

以上所有问题的本质是：如何让大模型作为一个推理引擎，驱动一个可编程的执行环境。OpenClaw 把大模型变成了 Agent 的大脑，把 Tool 和 Skill 变成了 Agent 的手脚，并提供了让大脑和手脚协同工作的神经系统。这是一个了不起的成就。但问题是，这个神经系统只管能不能动，不管该不该动。这就引出了 OpenClaw 没有解决的问题。

三、OpenClaw 没解决什么问题：从能跑到能上线的断层

OpenClaw 这类框架的设计目标非常明确：让 Agent 能跑起来。它们不是为生产环境的大规模治理而设计的。因此，当你想把一个 OpenClaw Agent 系统真正部署到生产环境时，会撞上一堵看不见的墙。

问题一：安全边界缺失

在 OpenClaw 的典型架构中，Agent 拥有对所有已注册 Tool 的调用能力。代码里可能写了一个delete_production_database 的 Tool，Agent 在理论上是可以调用它的。

你说我会在 Prompt 里告诉 Agent 不要调用危险的 Tool。但 Prompt 不是安全边界。Prompt 可以被绕过，这就是越狱攻击。可以因为上下文太长而被遗忘。可以因为模型的概率性而偶尔出错。一个金融交易 Agent，你有百分之九十九点九的信心它不会乱调接口，但百分之零点一的概率乘以每天百万次调用，结果是灾难性的。

OpenClaw 本身不提供任何机制来限制 Agent 能调用哪些 Tool、在什么条件下能调用、是否需要人工审批。它把这些问题完全留给了开发者。

问题二：没有细粒度的权限模型

即使你想限制 Agent 的能力，OpenClaw 能给你的粒度也只是这个 Agent 能用这些 Tool。你不能说这个 Agent 只能以只读方式调用数据库查询工具，不能执行更新或删除。

这是因为 OpenClaw 的 Tool 抽象没有内建操作类型的概念。一个 Tool 可能是查询，也可能是更新，也可能是删除，框架层面无法区分。权限控制只能靠开发者自己在 Tool 内部实现，但这样每个 Tool 都要重复实现一遍，而且无法在运行时动态调整。

问题三：没有统一的凭证管理

Agent 调用外部 API 时，通常需要 API Key 或令牌等凭证。在 OpenClaw 的典型实现中，这些凭证以明文形式存储在配置文件或环境变量中，Agent 运行时直接读取并使用。

这带来几个问题。凭证泄露风险，Agent 的输入输出可能被记录到日志中。凭证轮换困难，改一个密钥要重新部署所有 Agent。无法实现最小权限原则，一个 Agent 拿到密钥后可以做密钥允许的任何事情。

问题四：没有审计日志

当一个 OpenClaw Agent 系统出现问题时，比如意外删除了数据，或者执行了不该执行的操作，你无法回答以下问题：哪个 Agent 发起了这个调用？什么时候发生的？传入了什么参数？是谁批准的这个操作？

OpenClaw 本身不记录这些信息。开发者可以自己加日志，但这不是框架提供的标准化能力，而且很容易遗漏。

问题五：没有标准化的人工审批流程

某些高风险操作，比如发送邮件给大量用户、执行数据库写操作、调用计费接口，需要人工确认后才能执行。OpenClaw 没有内建这种人在回路的能力。开发者可以自己实现一个先挂起、等审批、再继续的机制，但这需要大量的额外代码，而且很难做得通用。

问题六：多 Agent 协作失控

OpenClaw 支持多个 Agent 协作，一个 Agent 可以调用另一个 Agent。但当多个 Agent 开始互相调用时，调用链变得复杂到无法追踪。Agent A 调用 Agent B，Agent B 调用 Agent C，Agent C 又调用了 Agent A，循环调用可能导致无限循环。没有全局的调用追踪和熔断机制，这种失控几乎是必然的。

四、Peta 如何填补 OpenClaw 的治理空白？

OpenClaw 没有解决的这些问题，正是 Peta 这样的 MCP 控制平面要解决的问题。Peta 不是要替代OpenClaw，而是在 OpenClaw 的外围提供一个治理层。

Peta 解决安全边界问题

Peta 通过零信任网关实现了强制性的安全边界。Agent 不能直接调用任何 Skill，所有的调用都必须经过 Peta 网关。网关在执行调用之前，会验证 Agent 的身份、检查权限策略、记录审计日志。无论 Agent 的 Prompt 里写了什么，无论模型输出了什么，网关都会在最后一刻拦截违规调用。这不是劝说，而是强制。

Peta 解决细粒度权限问题

Peta 的策略引擎支持精细的权限定义。你可以配置：客服 Agent 可以调用 query_order，但只能查询状态为completed 的订单。你可以配置：delete_order 只能由管理员角色的 Agent 调用，并且需要人工审批。你可以配置：同一个 Skill 在开发环境和生产环境有不同的权限策略。这些策略在 Peta Console 中集中配置，不需要修改任何代码。

Peta 解决凭证管理问题

Peta 的核心组件之一是加密存储。所有的 API 密钥、数据库密码、服务令牌都存储在 Vault 中，Agent 永远看不到原始凭证。Agent 通过短期令牌与 Peta 网关通信，网关在运行时动态注入凭证。即使 Agent 被攻破或日志泄露，真实密钥也不会暴露。密钥轮换也变得简单：你只需要在 Vault 中更新密钥，不需要重新部署任何 Agent 或 Skill。

Peta 解决审计日志问题

Peta 自动记录每一次调用的完整信息：哪个 Agent、什么时间、调用了哪个 Skill、传入了什么参数、结果是什么、耗时多久。这些日志是结构化的、可查询的、不可篡改的。你可以将日志导出到 SIEM 系统，满足合规要求。当问题发生时，你可以快速追溯完整的事件链条。

Peta 解决人工审批问题

Peta Desk 提供了完整的人工审批工作流。你可以在策略中将高风险 Skill 标记为需要审批。当 Agent 发起调用时，Peta 网关自动挂起请求，发送审批通知到审批人的桌面应用。审批人可以看到调用的详细信息，一键批准或拒绝。审批通过后，网关自动继续执行。整个过程中，Agent 不需要知道审批的存在，它只是正常发起调用然后等待响应。

Peta 解决多 Agent 协作失控问题

Peta 通过调用链追踪解决了多 Agent 协作的失控问题。每个 Action 都有父 Action 标识符，可以还原完整的调用树。无论调用链多长，无论涉及多少个 Agent，你都可以在审计日志中看到完整的调用关系。当出现循环调用时，Peta 的限流和熔断机制可以自动切断异常调用链。

五、OpenClaw 与 Peta 的协同架构

OpenClaw 和 Peta 不是竞争关系，而是互补关系。正确的架构模式是 OpenClaw 加 Peta。

在这个架构中，OpenClaw 负责 Agent 的推理和决策。它接收用户输入，调用大模型，决定要做什么。Peta 负责治理。它管理凭证、执行权限策略、记录审计日志、处理人工审批。两者的接口是 MCP 协议。

具体的工作流程是这样的。OpenClaw Agent 决定需要调用某个 Skill。Agent 通过 MCP 客户端向 Peta 网关发送请求。Peta 网关验证 Agent 身份，检查权限策略，记录审计日志。如果需要审批，网关挂起请求并通知审批人。审批通过后，网关将请求转发给对应的 MCP 服务器。MCP 服务器执行 Skill 逻辑，返回结果。网关将结果返回给 Agent。

在这个架构中，OpenClaw Agent 不需要知道 Peta 的存在。它只需要遵循 MCP 协议。Peta 也不需要知道OpenClaw 的内部实现。它只需要处理符合 MCP 协议的请求。这种松耦合的设计使得两者可以独立演进。

六、小结：执行与治理的分工

本章的核心结论可以总结为以下几点。

第一，OpenClaw 是执行框架的代表，它解决了让 Agent 能跑起来的问题，包括工具调用、状态管理、多轮对话、模型适配等。没有它，Agent 开发会极其繁琐。

第二，OpenClaw 没有解决治理问题，包括安全边界、权限模型、凭证管理、审计日志、人工审批、多 Agent 协作失控。这些是生产环境必须面对的问题。

第三，Peta 作为 MCP 控制平面，专门解决这些治理问题。它提供零信任网关、加密存储、策略引擎、审计日志、审批工作流、调用链追踪。

第四，OpenClaw 和 Peta 不是竞争关系，而是互补关系。OpenClaw 负责执行层，Peta 负责治理层。两者通过MCP 协议连接。

第五，正确的架构模式是 OpenClaw 加 Peta。OpenClaw 让 Agent 变聪明，Peta 让 Agent 变可控。两者结合，才能从能跑走向能上线。

在下一章，我们将用一个反例来进一步强化这个认知：一个没有 MCP 的 Agent 系统，是如何一步步失控的。通过具体的故障场景，你会更深刻地理解为什么协议层和控制平面不是锦上添花，而是必需品。