去中心化、可信的 MCP 运行时：架构设计与实现

一句话：把工具当成可寻址的产物、放进沙箱执行、用身份兜底，MCP 才配得上「可信」两个字。这是架构；后半篇是它的实现。

一、问题：Agent 的工具，是黑盒

Agent 的能力边界不是模型，而是它能调到的工具。可今天的工具是黑盒：第三方代码、一工具一容器、集中托管。

后果	现场表现	代价
来源不可验证	不知道跑的是哪一段字节，也不知道有没有被改过	不敢把敏感数据交给它
架构不可移植	x86 / ARM / RISC-V 各编一份二进制	工具到不了边缘
负载不可扩展	一容器一工具，冷启动 527–1119 ms、常驻 69–94 MB	小设备挂不起几个

这不是运维问题，是信任问题：你既不能核对它，也不能搬动它，还不能按需放它出去。

二、行业研究走到哪一步了

近两年围绕「MCP + WebAssembly」的研究，把这件事拆得比较清楚了。归纳成三个缺口和一组对策（数据与设计主张来自公开论文，实测环境为 Intel NUC）：

缺口一：协议只有功能元数据。 MCP 的 tool schema 描述「叫什么、要什么参数、返回什么」，但没有「跑多久、吃不吃 CPU、数据在哪、能不能出设备」。调度器看不见执行需求，只能猜。

缺口二：冷启动与指令集把边缘挡在门外。 容器化 MCP server 冷启动 527–1119 ms、常驻 69–94 MB；原生二进制要为每种 ISA 单独构建。数据集里 22.3% 的 server 只支持本地 stdio、77.7% 只支持远程 HTTP、0% 两者都支持——传输方式在编译期就被写死。

缺口三：现有 SDK 绑死系统原语。 它们建在 thread / signal / socket 上，而 WASI 里这些都没有；于是 WASM 侧缺一个原生传输层，只能靠 sidecar 代理，反而把 WASM 省下的开销还了回去。

研究给出的对策可以分成三组：

层次	主张	对架构的含义
控制面	代理 → 注册表 + 画像 → 约束过滤 → 可插拔调度	「调什么」与「在哪跑」分离，候选从 N×M 收到 N
运行时	双传输一份源码、编译期 schema、精简初始化路径	53 ms 启动；无 sidecar；跨架构可移植
部署面	无状态 HTTP、scale-to-zero、wasmtime 运行时类、卷挂载映射成 preopen	WASM 模块能进集群、能读存储

调度的代价函数（论文实现的是贪心版）：

1Score = α·Pexec + β·Pnet + (1−α)·Pcomm

Pexec 是归一化执行延迟，Pcomm 是与节点的通信开销；网络类工具用 β 把外部网络延迟 Pnet 加上去，α 按工具类型在执行与传输之间调权重。

三、架构设计

行业研究给了零件，但零件不等于架构。这里给出我认可的一份设计，它由四个要件和两条原则组成。

要件	解决什么	反面（缺了会怎样）
内容寻址的分发	产物不可变、可核对	只能相信某个服务自报版本
沙箱里的执行	不可信代码跑不出边界	第三方工具拿到宿主权限
可追溯的身份	谁发布、谁调用能追到	无中心网络里没人对结果负责
标准的 MCP 协议	任何 agent 框架都能接	每接一个框架写一层适配

两条原则：去中心化（分发不依赖中心注册表）与可信（不可变 + 沙箱 + 身份，三者必须同时成立）。

落到系统上是三层 + 两个横向能力：

由此得到五条设计不变量，后面所有实现都受它们约束：

逻辑工具唯一：上层只看到一个工具名，不看到节点。
控制面可插拔：调度算法可换，约束可加，不改编排逻辑。
执行面可替换：同一份工具语义，可以跑 WASM，也可以跑容器。
产物不可变：工具二进制一旦发布，地址即校验。
身份可追溯：每次发布与调用都能落到一个地址上。

四、实现对照：五层落地

下面这份实现是开源的（Apache-2.0 / MIT）。五层与架构要件一一对应，右边是可以直接翻的代码位置。

4.1 清单层：工具是目录项，不是部署单元

1modules:
2  - name: hello
3    wasm_path: IPFS://QmeDsaLTc8dAfPrQ5duC4j5KqPdGbcinEo5htDqSgU8u8Z
4    tools:
5      - name: say_hello
6        description: Greet someone by name
7        inputs: [{ name: name, type: string, required: true }]

加一个工具只改这一个文件；工具是目录项，运行时不需要重新构建。

4.2 运行时层：不可信代码必须进沙箱

1// core/mcp/wasm.go（节选）
2if strings.HasPrefix(path, "IPFS://") {
3    data, _ := ipfs.ExtractWASMFromCID(client, strings.TrimPrefix(path, "IPFS://"))
4    for _, d := range data { manifest.Wasm = append(manifest.Wasm, extism.WasmData{Data: d}) }
5}
6cfg := extism.PluginConfig{ModuleConfig: wazero.NewModuleConfig().WithSysWalltime(), EnableWasi: true}

沙箱带来两件事：第三方代码跑不出去；同一份字节码在 x86 与 ARM 上都能跑。

4.3 分发层：地址就是哈希

内容改一个字节，CID 就变。所以「发布一个工具」等于「发布一个内容地址」，任何人拿到都能自己核对，不需要中心注册表。这一层是去中心化真正硬的部分。

4.4 身份层：无中心网络里的身份位

启动时用口令解出 keystore（scrypt），服务拥有一个可追溯的地址。目前只做身份，没有计量与计费——先把「谁发布、谁调用」立住，再谈授权与结算。

4.5 协议层：接住所有 agent，才敢进集群

MCP 走 Streamable HTTP，注册表暴露在 GET /tools。无状态请求意味着可以横向扩、可以缩到零；这也是它和「常驻 SSE」最本质的区别。

五、四个取舍，以及它们的代价

架构是一串取舍。每一条都写清代价，否则下一版会踩回来。

决策	备选	选它的理由	代价
清单驱动	动态注册（运行时写注册表）	配置即契约，审计面小；工具不进代码	热更新要重新加载清单
IPFS 分发	中心 registry	不可变、可核对、全球可取	首次取回要付一次网络成本（官网 p99 50 ms）
钱包身份	API Key / OAuth	无中心网络里可自我验证，不依赖某个服务	目前只有身份，没有权限模型
无状态 HTTP	常驻 SSE	能 scale-to-zero、能横向扩	丢掉了长连接的推送语义

还有一条不是取舍，是欠账：目前一个模块一个实例一把锁，同一工具并发进来要排队。这保证了模块状态安全，但压住了吞吐——下一步是实例池。

六、与论文设计的差距

差距很清楚：有运行时、有分发、有身份，缺的是控制面。也就是说，现在「能跑」，但还不「聪明」——工具落在哪一层，还得人来定。

这也解释了为什么架构图里控制面是灰的：它是设计的一部分，但还没实现。

七、数据（分清来源）

指标	值	来源
模块启动	53 ms	实测（Intel NUC）
容器启动	527–1119 ms	实测（同上）
冷启动差距	10–21×	实测
内存	31 MB vs 82 MB（−59~72%）	实测
分发体积	0.3–1.4 MB vs 80–167 MB 镜像	实测
约束违规（45 次调用）	0 vs 41 / 42 / 42	实测
端到端	比全云快 2.3×	实测
执行吞吐 / 平均响应 / IPFS p99	25,000+/s、5 ms、50 ms	官网公布，未独立复测

注意最后一行：它不是我们测的。凡是官网口径的数字，在图表里都必须与实测分开，否则整篇的可信度会被一个数字拖垮。

八、可信是三个条件的乘积

给读者一个可操作的验证路径：拿到 CID，自己去网关取一次，算一遍哈希，与发布时给的地址比对。对不上，说明你拿到的东西被改过。能自己核对，才谈得上可信——这句话不依赖任何一家公司的承诺。

九、路线图与开放问题

控制面：画像（profiler）→ 约束过滤 → 放置调度。目标是「工具落在哪一层」从人的决定变成系统的决定。
并发：一模块一锁 → 实例池，先把吞吐打上去。
冷路径：首次取回的缓存与预热。
未解的问题：调度要不要暴露给工具作者？约束由谁定义（平台、数据所有者，还是调用方）？这两个问题决定了这套架构最终是「一个运行时」还是「一个市场」。

参考

公开论文：Orchestrating WASM-based MCP Tool Runtimes for AI Agents across Edge-Cloud Continuum（CCGrid 2026）——三个缺口、控制面、WASI 原生运行时与实测数据
实现仓库：DANP-LABS/DANP-Engine（Apache-2.0 / MIT）
项目站点：danp.icefirelabs.xyz