六個 MCP 工具，以及轉接器接下來將帶來什麼（現已達 17 個）

任何會說 MCP 的模型都能駕馭執行期——不需要為每家廠商做客製整合。RakuAI 的六工具契約，就是讓「確定性權威執行期」成真的那道邊界，也是它變成別人據以打造的基礎設施的轉折點。

執行期從三月下旬開始就會說 Model Context Protocol 了。出貨的 commit 是 138b538b：「feat(mcp): reframe MCP server from game-agent control to world model runtime orchestration」。那個 commit 訊息裡的框架轉換就是這篇文章的主體，而它的下一步棋是我想寫下來的東西。

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 現狀的誠實版本是：伺服器是真的、安全層強化過了、結構描述有型別、稽核日誌能運作，而轉接器是虛設的。

最後那個詞就是這個星期六的重量。六個工具接受一個 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 式邊界」有想法，這一週就是分享它的正確時機。契約還沒鎖定。現在提意見的成本，比一季之後低得多。

六個工具，已部署、已稽核、結構描述有型別、預設拒絕。接下來是轉接器。邊界是真的。在它之上運行的工作，是接下來的事。

星期六，進行中。