一、 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，框架会自动生成对应的工具描述（通常是大模型厂商要求的 JSON Schema），然后自动解析大模型返回的调用指令，将其转换成实际的函数调用。
如果没有这个能力，每个开发者都要手写 Prompt 来"教"大模型如何输出 JSON，然后手写解析器来解析输出------不仅繁琐，而且极易出错。
问题二：多轮对话中的状态管理
Agent 不是一问一答的。一个复杂的任务可能需要多轮推理，每一轮 Agent 都可能调用多个工具，每个工具调用都会产生新的上下文。OpenClaw 提供了内置的消息历史管理和状态持久化机制，开发者不需要自己维护对话状态。
问题三：工具调用的编排和执行
一个 Agent 可能在一次推理中决定调用多个工具，这些工具可能串行执行，也可能并行执行。OpenClaw 提供了工具调度的基础设施：它负责按顺序或并发执行工具，收集结果，然后将结果返回给 Agent 进行下一轮推理。
问题四：与不同大模型厂商的适配
OpenAI、Anthropic、Google、Azure......每个大模型厂商的 API 格式、工具调用规范、流式响应格式都不完全相同。OpenClaw 提供了统一的抽象层，开发者可以切换底层模型而无需重写 Agent 逻辑。
问题五：流式响应和用户体验
大模型生成文本需要时间。流式响应可以让用户逐字看到生成内容，而不是等待完整响应。OpenClaw 封装了流式处理的复杂性，开发者只需要调用几个简单的 API。
小结： OpenClaw 解决的是 " 执行层 " 的问题
以上所有问题的本质是：如何让大模型作为一个**"** 推理引擎 " ，驱动一个可编程的执行环境。 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，你有99.9% 的信心它不会乱调接口，但 0.1% 的概率乘以每天百万次调用，结果是灾难性的。
OpenClaw 本身不提供任何机制来限制 Agent 能调用哪些 Tool、在什么条件下能调用、是否需要人工审批。它把这些问题完全留给了开发者。
问题二：没有细粒度的权限模型
即使你想限制 Agent 的能力，OpenClaw 能给你的粒度也只是"这个 Agent 能用这些 Tool"。你不能说"这个Agent 只能以只读方式调用数据库查询工具，不能执行更新或删除"。
这是因为 OpenClaw 的 Tool 抽象没有内建"操作类型"的概念。一个 Tool 可能是查询，也可能是更新，也可能是删除------框架层面无法区分。权限控制只能靠开发者自己在 Tool 内部实现，但这样每个 Tool 都要重复实现一遍，而且无法在运行时动态调整。
问题三：没有统一的凭证管理
Agent 调用外部 API 时，通常需要 API Key、Token 等凭证。在 OpenClaw 的典型实现中，这些凭证以明文形式存储在配置文件或环境变量中，Agent 运行时直接读取并使用。
这带来几个问题：凭证泄露风险（Agent 的输入输出可能被记录到日志中），凭证轮换困难（改一个 Key 要重新部署所有 Agent），无法实现最小权限原则（一个 Agent 拿到 Key 后可以做 Key 允许的任何事情）。
问题四：没有审计日志
当一个 OpenClaw Agent 系统出现问题时------比如意外删除了数据，或者执行了不该执行的操作------你无法回答以下问题：哪个 Agent 发起了这个调用？什么时候发生的？传入了什么参数？是谁批准的这个操作？
OpenClaw 本身不记录这些信息。开发者可以自己加日志，但这不是框架提供的标准化能力，而且很容易遗漏。
问题五：没有标准化的人工审批流程
某些高风险操作------比如发送邮件给大量用户、执行数据库写操作、调用计费接口------需要人工确认后才能执行。OpenClaw 没有内建这种"人在回路"的能力。开发者可以自己实现一个"先挂起，等审批，再继续"的机制，但这需要大量的额外代码，而且很难做得通用。
问题六：多 Agent 协作失控
OpenClaw 支持多个 Agent 协作，一个 Agent 可以调用另一个 Agent。但当多个 Agent 开始互相调用时，调用链变得复杂到无法追踪。Agent A 调用 Agent B，Agent B 调用 Agent C，Agent C 又调用了 Agent A------循环调用可能导致无限循环。没有全局的调用追踪和熔断机制，这种失控几乎是必然的。
小结： OpenClaw 解决的是 " 执行 " ， MCP 解决的是 " 治理 "
用一个类比来理解 OpenClaw 和 MCP 的关系：
- OpenClaw 像一个汽车的发动机和传动系统。它让汽车能跑起来，能加速、能刹车、能转向。没有它，汽车根本动不了。
- MCP 和 Peta 这样的控制平面像交通规则、驾照、行车记录仪和保险。它们不直接让车跑起来，但它们让车在路上跑的时候不会撞到人，出了事故能追溯责任，不同车辆之间能协调。
OpenClaw 解决的是"能不能跑"，MCP 解决的是"能不能在路上安全地跑"。
四、 OpenClaw + MCP ：执行层与协议层的协同
OpenClaw 和 MCP 不是竞争关系，而是互补关系。实际上，两者可以完美地协同工作。
架构上的整合方式
在整合了 MCP 的 OpenClaw 系统中，Agent 不再直接调用 Tool，而是通过 MCP 协议调用被封装成 MCP Server 的 Skill。
具体来说：
- 开发者用 OpenClaw 定义 Agent 的推理逻辑、Prompt、工作流编排
- Agent 需要调用某个能力时，不直接调用本地函数，而是通过 MCP Client 向 MCP 网关发送请求
- MCP 网关（如 Peta）负责：验证 Agent 身份、检查权限策略、注入凭证、记录审计日志、执行人工审批流程
- MCP 网关将请求转发给对应的 MCP Server（封装了实际的 Skill/Tool 执行逻辑）
- 执行结果通过 MCP 协议返回给 Agent，Agent 继续推理
这种架构的好处
第一，安全治理与业务逻辑分离。OpenClaw 专注于让 Agent 更聪明、更高效地完成任务；MCP 控制平面专注于让 Agent 的行为安全可控。两者各司其职。
第二，能力可插拔。任何被 MCP 封装的 Skill 都可以被 OpenClaw Agent 调用，无论 Skill 是用什么语言写的、运行在哪里。新增 Skill 不需要修改 Agent 代码。
第三，统一的治理。权限策略、审计日志、凭证管理、人工审批------这些治理能力在 MCP 层统一实现，所有Agent 自动受益，不需要每个 Agent 单独实现。
第四，可观测性。MCP 网关记录了每一次 Agent 调用的完整信息，包括调用者、调用时间、传入参数、执行结果、耗时。这些数据可以用于调试、审计、成本分析、异常检测。
五、 OpenClaw 没解决问题，不等于 OpenClaw 不好
在批评 OpenClaw 这类框架"没解决什么问题"之前，我们需要保持公正：这些问题本来就不是****OpenClaw 要解决的。
OpenClaw 的设计目标是解决 Agent 的"执行"问题------如何让大模型驱动一个可编程的执行环境。在这个目标上，它做得非常好。安全、治理、审计、权限------这些是"平台层"或"基础设施层"的问题，不应该由执行框架来承担。
把安全治理的责任强加给 OpenClaw，就像要求汽车发动机自带交通法规一样荒谬。发动机负责提供动力，交通法规由驾驶员和交通系统来执行。
因此，正确的态度不是"OpenClaw 不行，我们要换掉它"，而是"OpenClaw 负责执行，我们需要在它外面包一层 MCP 控制平面来负责治理"。
六、从 OpenClaw 到生产级系统的演进路径
理解了 OpenClaw 和 MCP 各自解决什么问题，就能画出一条清晰的演进路径：
第一阶段：纯 OpenClaw 原型
用 OpenClaw 快速搭建 Agent 原型，验证业务可行性。这个阶段只有几个 Tool，用户很少，不需要考虑安全治理。目标：证明"能跑"。
第二阶段：发现治理问题
当系统规模扩大，开始出现安全事件、审计需求、权限失控等问题。开发者意识到"能跑"不等于"能上线"。
第三阶段：引入 MCP 协议层
将 Tool 封装成 MCP Skill，在 Agent 和 Skill 之间引入 MCP 协议。Agent 不再直接调用 Tool，而是通过 MCP Client 发送请求。
第四阶段：引入 MCP 控制平面
部署 Peta 这样的 MCP 控制平面，提供凭证 Vault、策略引擎、审计日志、人工审批等能力。系统从"能跑"升级为"能上线"。
第五阶段：持续优化
基于审计日志分析 Agent 行为，优化权限策略，发现异常调用模式，持续改进系统的安全性和可治理性。
七、小结
本章的核心观点可以总结为以下几点：
- OpenClaw 是执行框架的代表，它解决了"让 Agent 能跑起来"的问题------工具调用、状态管理、多轮对话、模型适配等。没有它，Agent 开发会极其繁琐。
- OpenClaw 没有解决治理问题------安全边界、权限模型、凭证管理、审计日志、人工审批、多 Agent 协作失控。这些是生产环境必须面对的问题。
- OpenClaw 和 MCP 不是竞争关系，而是互补关系。OpenClaw 负责执行层，MCP 负责协议层。两者可以完美协同。
- 正确的架构模式是 "OpenClaw + MCP 控制平面 "。OpenClaw 让 Agent 变聪明，MCP 让 Agent 变可控。两者结合，才能从"能跑"走向"能上线"。
在下一章，我们将用一个"反例"来进一步强化这个认知：一个没有****MCP 的 Agent 系统，是如何一步步失控的。 通过具体的故障场景，你会更深刻地理解为什么协议层和控制平面不是"锦上添花"，而是"必需品"。