MCP（Model Context Protocol）的出现代表了 AI 生态系统的重大进步。行业首次围绕工具交互的共享接口汇聚——标准化了模型如何发现工具、调用能力、交换上下文和与外部系统通信。

但 MCP 也揭示了一个更大的架构缺口：它解决了协议问题，没有解决运行时问题。  而运行时问题正变得越来越关键。

协议不是运行时

MCP 标准化了通信——定义工具发现、调用、资源管理——这是有价值的。但协议只定义"系统如何通信"，不定义"系统如何安全执行"。

类比一下：HTTP 标准化了 Web 通信，但它没有解决应用隔离、运行时治理、资源调度和执行安全。这些是操作系统和运行时的职责。

BoxAgnts 的 MCP 实现体现了这个分层的本质。boxagnts/mcp/src/lib.rs 负责所有协议级别的逻辑——JSON-RPC 2.0 消息格式、initialize/initialized 握手、tools/list 工具发现、tools/call 工具执行、stdio 和 HTTP/SSE 传输层：

// MCP 客户端连接
pub async fn connect_stdio(config: &McpServerConfig) -> anyhow::Result<Self> {
    let backend = RmcpClientBackend::connect_stdio(config).await?;
    Ok(Self::from_backend(Arc::new(backend)))
}

// 工具调用
pub async fn call_tool(&self, name: &str, arguments: Option<Value>) 
    -> anyhow::Result<CallToolResult> {
    self.backend()?.call_tool(name, arguments).await
}

但请注意——MCP 客户端只负责"调用工具并获取结果"，它不负责"这个工具是否应该被调用"或"调用应该在什么约束下执行"。那个职责属于运行时层。

当前 Agent 技术栈的不完整性

大多数 AI 系统的架构是：

LLM → 提示词框架 → 工具调用协议 → 主机执行

中间缺少了一层：运行时基础设施。  这层负责执行隔离、能力边界、资源约束、状态持久化和执行可观察性。

BoxAgnts 的完整技术栈清晰地展示了这个分层：

LLM (api/ 层)
  ↓
Gateway / Query (gateway/ + query/)
  ↓
Tool Interface (tools/ + wasm-tools/)
  ↓
WASM Sandbox (wasm-sandbox/ 层)  ← 这里是真正的运行时
  ↓
Host Resources

MCP 位于 Tool Interface 层旁边——它负责将外部工具引入 Agent 的工具集，但不改变底层的执行隔离。BoxAgnts 中 MCP 工具通过 McpToolWrapper 注册：

// boxagnts/gateway/src/api/mcp.rs
pub struct McpToolWrapper {
    pub tool_def: ToolDefinition,
    pub server_name: String,
    pub manager: Arc<boxagnts_mcp::McpManager>,
}

impl Tool for McpToolWrapper {
    fn permission_level(&self) -> PermissionLevel {
        PermissionLevel::Execute  // MCP 工具默认被视为 Execute 级别
    }
    // execute 方法将调用委托给远程 MCP 服务器
}

MCP 工具接入后，和其他原生工具一样走相同的 Tool trait 接口——但它们的执行发生在远程 MCP 服务器上，不受 BoxAgnts 的 WASM 沙箱保护。这是一个需要清醒认识的安全边界差异。

工具调用 ≠ 工具执行

MCP 标准化了工具调用——模型选择工具名、结构化参数、执行请求。但更难的问题在调用之后：工具接收什么权限？可以访问哪些文件？允许哪些网络端点？如何约束资源？如何隔离执行？如何审计行为？

这些是运行时关切，MCP 无法回答。BoxAgnts 的做法是把 MCP 工具与原生 WASM 工具放在同一层接口下，但在执行路径上做区分：

  • WASM 工具：在 Wasmtime 沙箱内，受 RunOption 全量约束
  • MCP 工具：通过 McpToolWrapper 委托，信任边界在 MCP 服务器自身

这意味着 MCP 工具的安全性取决于 MCP 服务器提供者的实现质量。如果 MCP 服务器不做沙箱——那它的工具调用就等同于主机直接执行。

为什么 AI Agent 需要运行时隔离

传统软件早假设应用可能失败、依赖可能被攻破、进程可能行为异常。这就是容器、虚拟机、进程边界存在的理由。AI Agent 面临更严重的问题：LLM 驱动的系统暴露在提示注入、对抗性文档和被操控上下文中。

BoxAgnts 的 Connection Manager（boxagnts/mcp/src/connection_manager.rs）展示了即使是 MCP 连接也需要治理：

pub async fn connect_all(&self) -> anyhow::Result<()> {
    for name in names {
        if let Err(e) = self.connect(&name).await {
            error!(server = %name, error = %e, 
                   "MCP server failed to connect during startup");
        }
    }
    Ok(())
}

连接失败是隔离处理的——一个 MCP 服务器宕机不影响其他服务器。这看起来理所当然，但很多 Agent 框架连这一层都没有。

行业先标准化了错误的层

当前生态系统投入大量精力标准化模型接口、工具协议、提示词格式、编排框架。这些有用，但历史表明基础设施最终被执行约束，而不是接口。

Web 不只因为 HTTP 扩展——它扩展因为操作系统、进程隔离、容器编排、运行时环境和调度系统。AI 基础设施同理：工具协议是必要条件，但不是充分条件。  最终的关键区分因素是运行时可靠性，而不是工具调用语法。

BoxAgnts 的架构预见了这一点：协议层（MCP）在上面，运行时层（WASM Sandbox）在下面。新工具可以通过协议发现，但执行约束由运行时统一控制。

运行时工程：新兴的基础设施学科

可靠的 AI 系统需要确定性执行、显式权限、沙箱化工具、受治理的编排、有界副作用、资源核算、执行可观察性——这些远远超出提示词工程的范围。

BoxAgnts 在几个关键模块中体现了这个方向：

  • boxagnts/wasm-sandbox/：执行隔离和能力约束
  • boxagnts/tools/：工具接口和权限模型
  • boxagnts/gateway/cron/：定时任务执行治理
  • boxagnts/workspace/：状态持久化和管理

未来的 AI 技术栈应该是：

LLM
  ↓
协议层（MCP）
  ↓
运行时层 ← 这一层需要大量工程投入
  ↓
能力沙箱（WASM）
  ↓
执行基础设施

MCP 仍然极其重要

以上分析不是削弱 MCP 的价值。恰好相反——标准化的协议让运行时创新更容易。共享工具接口使可移植运行时、可互换编排系统、标准化能力注入成为可能。

协议简化集成，运行时强制执行。两层都重要，但不能混淆它们的职责边界。

结语

MCP 标准化了模型如何与外部系统通信——这是重要的里程碑。但通信只是问题的一半。更难的挑战是执行安全。随着 Agent 获得操作权限，生产系统需要运行时隔离、能力治理、确定性执行和沙箱化工具。

最终的关键问题不再是"模型能调用工具吗？"——而是"系统能安全执行吗？"

相关资源