一、执行框架与协议层的分工
在前面的章节中，我们分别讨论了 OpenClaw 这类执行框架的作用和 MCP 协议层的价值。OpenClaw 解决了"让 Agent 能跑起来"的问题------工具调用、状态管理、多轮对话、模型适配。MCP 解决了"让 Agent 安全可控地跑"的问题------凭证管理、权限控制、审计日志、人工审批。
但这两个世界是分离的。在实际的 Agent 系统中，执行框架和协议层需要协同工作。OpenClaw 不能取代MCP，MCP 也不能取代 OpenClaw。它们之间的关系不是"替代"，而是"约束"。
本章将探讨：如何将 OpenClaw 这样的执行框架纳入 MCP 体系，使其从"能跑"的执行引擎，转变为"受约束的"系统组件。这不是简单的集成，而是架构层面的重新设计。
二、没有 MCP 的 OpenClaw ：强大的执行引擎
在纯 OpenClaw 架构中，系统的工作方式如下：
第一步，开发者定义若干个 Tool，每个 Tool 是一个函数。第二步，开发者将这些 Tool 注册到 Agent 的可用工具列表中。第三步，Agent 接收用户输入，调用大模型进行推理。第四步，大模型返回一个决策，决定调用某个Tool。第五步，OpenClaw 执行这个 Tool，将结果返回给模型。第六步，循环往复，直到任务完成。
这个模式在简单场景下工作得很好。Agent 可以调用 Tool，Tool 可以访问数据库、调用应用程序编程接口、发送邮件。一切看起来都很顺畅。
但问题在哪里？问题在于，OpenClaw 对 Tool 的调用没有任何约束。一旦 Tool 被注册，Agent 就可以在任何时候、以任何参数调用它。没有权限检查，没有审计日志，没有人工审批，没有调用追踪。
你可以通过 Prompt 来"劝说"Agent 不要做某些事，但正如我们在第八章中讨论的，Prompt 不是有效的约束机制。模型可能忽略、遗忘、或被绕过。这意味着，一个纯 OpenClaw 系统，在规模化和安全敏感的场景下，是不可控的。
三、引入 MCP 协议层：从直接调用到协议化调用
为了解决这个问题，我们需要在 OpenClaw 和 Tool 之间插入一个 MCP 协议层。核心的变化是：Agent 不再直接调用 Tool，而是通过 MCP 协议调用 Skill。
在集成 MCP 之后，架构发生了根本性的变化。开发者首先将原有的 Tool 封装为 MCP Skill。每个 Skill 被部署为一个 MCP 服务器，暴露 MCP 协议接口。OpenClaw Agent 不再直接调用 Tool，而是通过 MCP 客户端向MCP 网关发送请求。MCP 网关负责认证、授权、审计、限流、审批。网关将请求转发给对应的 MCP 服务器。MCP 服务器执行实际的业务逻辑，返回结果。
这个架构变化的关键在于，OpenClaw 失去了直接调用 Tool 的能力，取而代之的是通过协议调用 Skill。这个失去的能力，正是获得可控性的代价和回报。
OpenClaw 的角色也发生了深刻的变化。在纯 OpenClaw 架构中，OpenClaw 既是执行引擎又是调用通道，它负责推理、决策、工具调用、结果处理。在 MCP 集成架构中，OpenClaw 的角色被精简了。OpenClaw 仍然负责推理和决策，它决定"要做什么"。但 OpenClaw 不再负责"如何调用"，调用细节由 MCP 协议处理。OpenClaw 不再负责"能否调用"，权限决策由 MCP 网关处理。OpenClaw 不再负责"调用记录"，审计日志由 MCP 网关处理。
这种角色变化的核心是，OpenClaw 从全能的执行引擎变成了专注的决策引擎。它只关心"做什么"，不关心"怎么做"和"能否做"。
四、 MCP 如何约束 OpenClaw ？
MCP 对 OpenClaw 的约束体现在以下几个层面。
第一个层面是调用路径的统一收口。在没有 MCP 的情况下，OpenClaw 可以直接调用任意 Tool，调用路径是分散的、不可控的。在 MCP 集成后，所有的调用都必须经过 MCP 网关。网关成为唯一的调用入口。这意味着，没有能够绕过网关的调用路径，所有调用都在网关的监控之下，任何违规调用都可以在网关层被拦截。
第二个层面是权限策略的外部化。在没有 MCP 的情况下，权限逻辑要么不存在，要么硬编码在 Tool 内部。OpenClaw 本身不参与权限决策。在 MCP 集成后，权限策略从 Tool 内部抽离出来，配置在 MCP 控制平面中。OpenClaw Agent 发起调用时，网关会检查策略。Agent 不需要知道策略的存在，也不需要实现任何权限逻辑。策略对 Agent 是透明的，但又是强制执行的。
第三个层面是审计日志的自动化。在没有 MCP 的情况下，审计日志需要开发者自己实现。每个 Tool 都要单独加日志，格式不统一，容易遗漏。在 MCP 集成后，MCP 网关自动记录每一次调用的完整信息。OpenClaw Agent 不需要做任何额外工作。审计日志的格式是统一的，存储是集中的，查询是标准化的。
第四个层面是人工审批的强制执行。在没有 MCP 的情况下，人工审批需要开发者自己实现一个复杂的流程：挂起执行、等待审批、恢复执行。这很难做到通用和可靠。在 MCP 集成后，MCP 控制平面内置了审批工作流。开发者只需要在策略中标记某个 Skill 为"需要审批"，MCP 网关会自动处理挂起、通知、等待、恢复的整个流程。OpenClaw Agent 只需要正常发起调用，网关会在需要时自动等待审批结果。
五、集成的工程实现
下面，我们来看一个具体的集成示例。假设我们有一个使用 OpenClaw 框架构建的客服 Agent，它需要调用一个"发送退款"的 Tool。
第一步，将 Tool 封装为 MCP Skill。原有的 Tool 是一个 Python 函数，它首先验证调用者是否有退款权限，然后执行退款业务逻辑。在 MCP 封装后，Skill 不再包含权限验证逻辑，只包含退款业务逻辑。权限验证被移到了MCP 控制平面的策略中。
第二步，配置 MCP 策略。在 Peta 这样的控制平面中，配置一条策略：只有角色为 customer_service 的 Agent 可以调用 send_refund Skill，且订单状态不能为已发货，同时这个调用需要人工审批。
第三步，配置 OpenClaw Agent。在 OpenClaw 中，Agent 不再直接注册 Tool，而是注册一个 MCP 客户端，连接到 MCP 网关。Agent 在配置时声明它可以调用的 Skill 列表，包括 query_order、send_refund、query_user 等。
第四步，运行时流程。当 Agent 决定需要调用 send_refund 时，它通过 MCP 客户端向网关发送 Action 请求。网关收到请求后，查询策略配置，发现 send_refund 需要审批。于是网关挂起这个 Action，发送审批请求到Peta Desk。审批人在 Peta Desk 中看到请求的详细信息，点击批准。网关收到批准信号后，将 Action 转发给对应的 MCP 服务器。MCP 服务器执行 send_refund 的业务逻辑，返回结果。网关将结果返回给 Agent。
整个过程中，Agent 不知道审批的存在，它只是正常发起调用然后等待响应。网关在后台处理了所有的审批流程。
六、集成前后的能力对比
集成 MCP 前后，OpenClaw 系统的能力发生了显著变化。
在工具调用方面，纯 OpenClaw 是直接调用函数，而集成 MCP 后是通过 MCP 协议调用 Skill。
在权限控制方面，纯 OpenClaw 要么没有权限控制，要么权限逻辑硬编码在 Tool 内部，而集成 MCP 后由策略引擎统一控制。
在审计日志方面，纯 OpenClaw 需要开发者手动实现，而集成 MCP 后由网关自动记录。
在人工审批方面，纯 OpenClaw 需要开发者手动实现复杂的审批流程，而集成 MCP 后内置了审批工作流。
在调用追踪方面，纯 OpenClaw 没有调用追踪能力，而集成 MCP 后有完整的调用链追踪。
在凭证管理方面，纯 OpenClaw 的凭证以明文形式写在配置文件中，而集成 MCP 后采用加密存储加动态注入的方式。
在限流熔断方面，纯 OpenClaw 需要开发者手动实现，而集成 MCP 后由网关统一配置。
七、小结：从执行引擎到约束系统
本章的核心结论可以总结为以下几点。
第一，OpenClaw 解决的是执行问题，它让 Agent 能够调用工具、管理状态、完成多轮对话。但它不解决治理问题。
第二，MCP 通过协议层约束 OpenClaw 的调用行为。所有的调用都必须经过 MCP 网关，在网关层实现认证、授权、审计、审批、限流。
第三，集成 MCP 后，OpenClaw 的角色从全能的执行引擎转变为专注的决策引擎。它只关心"做什么"，不关心"怎么做"和"能否做"。
第四，MCP 对 OpenClaw 的约束体现在四个层面：调用路径的统一收口、权限策略的外部化、审计日志的自动化、人工审批的强制执行。
第五，OpenClaw 加 MCP 的组合，是从"能跑"到"能上线"的必经之路。OpenClaw 让 Agent 变聪明，MCP 让Agent 变可控。
在下一章，我们将继续工程视角的讨论，深入 MCP 的核心机制，探讨 Action、Context、Permission 是如何协同工作的。