WebAssembly AI 插件沙箱：插件能跑，更要能管

WebAssembly AI 插件沙箱：插件能跑，更要能管

一、插件系统的重点不是把代码加载起来

WebAssembly 很适合做插件沙箱。它可以把第三方逻辑编译成 wasm，在宿主程序里受控执行。对于 AI 工具来说，插件可能负责解析文件、调用本地命令、格式化结果或执行小型推理。能把插件跑起来只是第一步，更重要的是限制它能访问什么资源。

如果插件可以随便读文件、访问网络、执行命令，那它和直接运行脚本没有太大区别。AI Agent 场景尤其危险，因为模型可能选择调用插件。插件系统必须提供权限边界、资源限制和审计日志。沙箱不是装饰，是工具链的安全底座。

二、执行模型：宿主控制能力，插件提供逻辑

flowchart TD A[宿主程序] --> B[加载 Wasm 插件] B --> C[声明权限] C --> D[受控执行] D --> E[宿主 API] E --> F[文件或网络能力] D --> G[结果返回]

Wasm 插件不应该直接拿到系统资源，而是通过宿主提供的 API 访问。比如读取文件时，插件只传入逻辑路径，宿主检查是否在允许目录内；网络请求由宿主代理，并检查域名白名单；执行时间和内存由运行时限制。插件越小，能力越窄，越容易审计。

权限声明可以放在插件 manifest 中。宿主加载前先展示或校验权限，用户确认后再启用。不要等插件运行时才发现它想访问危险资源。插件市场或团队内部插件库，也应该把权限作为审核内容。

三、Manifest 示例：权限要显式写出来

下面是一份简化的插件声明。它不追求完整，只表达基本思路。

[plugin] name = "markdown-summary" version = "0.1.0" [permissions] read_paths = ["./docs"] network = [] max_memory_mb = 64 max_execution_ms = 2000

宿主程序加载后，可以根据 manifest 创建运行上下文。若插件尝试读取./secrets，宿主应拒绝，而不是让 wasm 自己决定。权限模型一定要默认拒绝，按需开放。这里的思路和浏览器权限有点像，只是场景更偏开发者工具。

资源限制也不能省。一个写坏的插件可能死循环，或者分配大量内存。运行时要限制执行时间和内存，必要时中断插件。插件错误要被隔离，不能让整个 AI 工具崩溃。

ABI 也要尽量稳定。插件和宿主之间传递的数据格式，一旦发布就会被多个插件依赖。可以在 manifest 里声明协议版本，宿主加载时检查兼容性。不兼容就拒绝加载，而不是运行到一半才发现字段缺失。插件系统越开放，版本管理越重要。

四、和 AI Agent 结合：模型只能请求，宿主决定执行

当 AI Agent 能调用 wasm 插件时，边界要更严格。模型可以提出“使用 markdown-summary 读取 docs 目录”的请求，但宿主必须检查权限、展示风险并记录审计。不能因为模型回答得很自信，就跳过用户确认。

插件返回结果也要结构化。比如返回摘要、文件列表、错误码和耗时，而不是一大段不可解析文本。这样 Agent 可以继续推理，用户也能看懂插件做了什么。工具链里每一步都应可追踪。

最后，插件版本要固定。一次任务记录中应包含插件名称、版本、权限和输入摘要。否则同一个 Agent 流程在下周可能因为插件升级得到不同结果。可复现不仅属于模型实验，也属于工具执行。

如果插件来自第三方，还应保存校验和。下载后的 wasm 文件可以计算 hash，执行前验证是否和记录一致。这样能避免文件被替换后仍然以旧版本名运行。安全设计看起来麻烦，但等工具真的开始执行用户文件时，这些麻烦会变成底气。

五、总结

WebAssembly 适合构建 AI 工具插件沙箱，但重点不是让插件能跑，而是让能力可控。权限声明、宿主代理、资源限制、审计日志和版本固定，是插件系统进入生产前必须补齐的部分。插件自由之前，先要有边界。