六个 MCP 工具，以及适配器接下来会解锁什么（现已增至 17 个）

任何会说 MCP 的模型都能驱动这个运行时——无需针对每个厂商做定制集成。RakuAI 的六工具契约正是让「确定性主导权运行时」成为现实的边界，也是它从我们自用的工具转变为他人赖以构建的基础设施的拐点。

自三月底以来，这个运行时就一直在使用 Model Context Protocol 进行通信。发布这项功能的提交是 138b538b，标题为「feat(mcp): reframe MCP server from game-agent control to world model runtime orchestration」。这条提交信息里框架的转变正是这篇文章的核心内容，而我想记录下来的是它的下一步动作。

MCP 在运行时中今天的样子

六个工具，位于 src/mcp/raku_mcp_server.py 中的一个 Python 服务器上，通过 stdio 传输，命名空间为 raku.*。按调用者、按工具强制执行默认拒绝的权限。每一次调用都记录在审计日志中。

这六个工具是：

1. load_world_model(adapter_name, config) 注册一个世界模型后端。目前的适配器名称都是占位符：VideoPredictor-v2、NeuralRadianceField、PhysicsFoundation。未来它们会是真正的适配器。
2. ingest_frame(adapter_name, frame_data, frame_index, timestamp) 把来自生成式模型的一帧数据交给运行时的场景图。
3. get_scene_state(include_physics, include_transforms) 是世界状态的只读快照。在任何模式下都是安全的。
4. set_render_target(target_type, config) 配置世界渲染的目标位置：WebGL、VR 头显、原生窗口、离屏渲染。
5. start_simulation(tick_rate, max_duration, realtime) 启动仿真循环。仅限沙盒和开发环境。生产环境的服务器会拒绝这一调用。
6. get_metrics() 返回一份性能快照。FPS、帧时间、节点数量、适配器负载、正常运行时间。在任何模式下都是安全的。

只读工具在任何环境中都可用。可变更工具（load、ingest、set、start）仅在沙盒和开发环境中可用。生产环境的姿态是「外部智能体可以询问，但不能下令」。这个姿态是在服务器端强制执行的，而不是靠调用方自觉。一个行为不当的合作伙伴无法意外地变更一个生产环境的世界模型。

为什么是这六个而不是别的

三月之前，MCP 服务器的早期版本暴露的是游戏智能体工具：move_npc、set_dialog、place_object、query_inventory。这些对于这个边界来说是错误的工具。它们关注的是应用层面的问题，而不是引擎层面的问题。它们让引擎变成智能体可以随意插手的东西。而引擎本应是智能体在其之上运行的东西。

PR #1311 中的这次重新构框替换了工具表面。新的工具作用于世界模型抽象之上：加载一个后端、推送一帧、查询状态、配置渲染、启动仿真、读取指标。想要移动一个 NPC 的智能体，做法是通过世界模型适配器推送一帧数据，而不是在引擎上调用 move_npc。引擎在物理、碰撞、计分、多人游戏状态方面依然保持主导权。世界模型是一个贡献者，而不是一个控制者。

正是这个区别，让引擎能够对另一端接入的是哪个世界模型保持中立。Genie、Runway、停运之前的 Sora、一个自研的内部模型、一个物理基础模型、一个实验性的神经辐射场渲染器——所有这些都使用同一套六工具表面进行通信。它们都无权凌驾于引擎对仿真中实际发生之事的主导权之上。

这就是「确定性主导权运行时」这个说法在实践中的含义。我们在和合作伙伴的对话中经常提到这个说法。而 MCP 表面正是让它成真的东西。

现状与下一步之间的差距

关于 MCP 现状的坦诚说法是：服务器是真实的，安全层已经加固，模式（schema）是类型化的，审计日志能正常工作，而适配器还只是桩代码。

最后那个词，正是这个星期六的分量所在。这六个工具接受一个 adapter_name 字符串。桩适配器（VideoPredictor-v2、NeuralRadianceField、PhysicsFoundation）只是证明调度路径可行的占位符。src/environment/ 目录下有 VeoEnvironmentAdapter 和 RunwayEnvironmentAdapter 的脚手架文件，但尚未接入真正的模型。

下一步是把一个适配器端到端地跑通，另一端接入一个真正的合作伙伴模型。在 GDC 的对话中反复被提到的候选方案，是一个视频预测模型（Runway，或是一个规模更小的开源模型）通过 ingest_frame 输入场景帧数据，同时引擎在底层处理物理和碰撞。这将是一个演示：画面来自生成式模型，玩法来自引擎，而双方除了通过 MCP 边界之外都不需要了解对方。

如果这个演示能跑通，其余每一个适配器都是已知的形状。难点不在于集成本身。难点在于契约。而契约就是这六个工具。

这对合作伙伴意味着什么

有两件具体的事，都值得说清楚。

任何会说 MCP 的智能体都能驱动这个运行时。 一家想要用真实引擎测试自己生成能力的模型实验室，不需要定制集成。他们只需编写一个 MCP 客户端，用自己的后端调用 load_world_model，用 ingest_frame 推送帧数据，用 get_scene_state 读取场景状态。剩下的都由引擎完成。合作伙伴得到了一个针对自己模型的真实评测平台。而我们得到了一个证明引擎与厂商无关的真实演示。

任何在这个运行时之上构建工具的开发者都能使用同一套表面。 MCP 服务器不是一个仅供合作伙伴使用的 API。它就是这个 API。一家构建创作工具的工作室，一位跑批量评测的研究者，一个集成新传感器的硬件合作伙伴，所有人拿到的都是同样的六个工具。这里没有一个隐藏在公开 API 背后的独立「内部」API。这里只有 MCP 表面，以及 SDK 所使用的 C API，而这就是这个运行时的全部公开面貌。

仍需加固的部分

有三项工作我想记录下来，好让它们真正被完成：

生产部署框架。 目前的 MCP 服务器是在测试中实例化的。它需要一个服务模板：用于模式、认证令牌和速率限制的环境变量配置、一个健康检查端点、优雅关闭、容器打包。标准的运维卫生工作。不光鲜，但正是这些工作让一个能跑起来的服务器变成一个可部署的服务器。

多厂商回退机制。 当主适配器缓慢或不可用时，服务器应该能够路由到一个备用适配器。策略文档已经讨论这个问题有一段时间了。实现还没有落地。方案本身很直接。真正的工作量在于测试。

适配器悬赏计划。 一旦某个适配器端到端跑通、契约得到验证，正确的做法就是发布适配器契约，邀请整个生态系统来编写更多适配器。让熟悉 Genie 的人来写一个 Genie 适配器。让熟悉 Marble 的人来写一个 Marble 适配器。让某个研究团队来写一个自定义模型适配器。我们的工作不再是「集成每一个模型」，而是变成「发布契约，评审实现」。

最后这一步是我最兴奋的一步。这正是 MCP 从一个我们自用的工具，转变为他人赖以构建的基础设施的拐点。

未来这一周

我这个星期六早上正在提交的队列里，已经有了第一个真正的适配器。范围明确、目标狭窄，如果进展顺利，月底前就能有一个可运行的演示。如果进展不顺利，我们就能趁改动成本还低的时候，弄清楚我们在契约上判断错了什么。

如果你在一家模型实验室工作，对于面向生成式模型对话的运行时应该采用怎样的 MCP 式边界有自己的看法，现在正是分享它的好时机。这个契约还没有锁定。现在提意见的成本，比一个季度之后要低得多。

六个工具，已部署、已审计、模式类型化、默认拒绝。适配器是下一步。这个边界是真实的。建立在它之上的工作，是接下来要发生的事。

星期六，仍在推进中。