BoxAgnts运行时深度测评：MCP之外的核心竞争力

MCP的诞生，无疑是AI生态中一次关键的结构性突破。它首次让整个行业围绕工具交互的共享接口达成共识——模型如何发现工具、如何发起调用、如何交换上下文、如何与外部系统通信，都有了统一的规范。这值得肯定。

但坦诚地讲，MCP也暴露了一个更大的架构缺口：它解决了协议问题，却没有解决运行时问题。 而这个运行时问题正变得越来越关键，甚至可以说，它才是决定Agent系统能否在生产环境中落地的真正瓶颈。

协议不等于运行时

MCP标准化了通信——定义了工具发现、调用、资源管理等机制，这当然有价值。但协议只回答“系统如何通信”，不回答“系统如何安全执行”。这是两个截然不同的命题。

打个比方：HTTP标准化了Web通信，但它并未解决应用隔离、运行时治理、资源调度和执行安全。这些是操作系统和运行时的职责，不是协议该管的。同理，MCP只是通信层的标准，往下走，还得有东西兜底。

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) 
    -> anyhow::Result {
    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,
}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，每个框架都得自研一套协议，生态会极度碎片化。

协议简化集成，运行时强制执行。两层都重要，但不能混淆它们的职责边界。MCP负责“你能怎么连接”，运行时负责“你该怎么安全执行”。

结语

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

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

来源：互联网