我在 OpenClaw 上跑的模型是 MiniMax-M2.7，人格叫 Itsuki。它回覆中文時偶爾會冒出簡體用詞——設置、獲取、運行、默認——這些在 USER.md 裡已經明確寫了要避免，但模型不一定每次都遵守。

所以我請 Itsuki 做一件看起來合理的事：幫我寫一個 OpenClaw 外掛，讓所有中文輸出都經過 OpenCC 的臺灣模式轉換。

它很積極。花了大概十分鐘，讀了 OpenClaw 的文件、查了外掛架構、裝了 opencc-js、寫好 index.ts 和 openclaw.plugin.json，最後把外掛加進設定檔的 allow list。

然後我發了一句「怎麼了」，它就崩潰了。

Cannot read properties of undefined (reading 'properties')

每次對話都這樣。連續崩。

---

三個問題，全都是 API 用錯

後來我用 Claude Code 去查，發現 Itsuki 犯了三個錯誤：

1. OpenCC API 不存在的方法

// Itsuki 寫的
const converter = await OpenCC.fromJSON();

// 實際 API
const converter = OpenCC.Converter({ from: 'cn', to: 'twp' });

OpenCC.fromJSON() 根本不存在。opencc-js 的 API 是 Converter()，而且是同步的，不需要 await。

2. Tool 註冊介面完全用錯

這是崩潰的直接原因。Itsuki 用了通用的 tool registration pattern：

// Itsuki 寫的（其他框架的 pattern）
api.registerTool({
  name: "opencc_convert",
  inputSchema: { ... },
  handler: async ({ text }) => { ... }
});

但 OpenClaw 的 registerTool 預期的是 AgentTool 介面（來自 @mariozechner/pi-agent-core）：

// 正確的 OpenClaw 寫法
api.registerTool({
  name: "opencc_convert",
  label: "OpenCC Convert",
  parameters: { ... },
  execute: async (toolCallId, params) => {
    return {
      content: [{ type: "text", text: "..." }],
      details: { ... }
    };
  }
});

關鍵差異：inputSchema → parameters，handler → execute，還需要 label，回傳格式也完全不同。

OpenClaw 內部在建構 tool list 時會存取 tool.parameters.properties。因為 Itsuki 寫的是 inputSchema 而不是 parameters，所以 tool.parameters 是 undefined，接著 .properties 就炸了。

3. plugin manifest 必須有 configSchema

修完前兩個問題後，我一度把 openclaw.plugin.json 裡的 configSchema 拿掉（以為它跟 JS 裡的重複定義衝突），結果 Gateway 直接拒絕載入外掛：

plugin manifest requires configSchema
plugins.allow: plugin not found: opencc-tw

OpenClaw 的外掛 manifest 強制要求這個欄位，即使你的外掛不需要任何設定。

---

修完之後

三個問題全部修正後，重啟 Gateway，外掛正常載入，對話恢復正常。

最終的外掛做兩件事：

1. before_prompt_build hook：在 system prompt 注入臺灣正體用詞指引，讓模型從源頭就盡量用對的詞
2. opencc_convert tool：模型可以主動呼叫，把文字送進 OpenCC 做 cn → twp 轉換

沒有 pre-outbound hook 可以攔截 response 做自動轉換（OpenClaw 目前只有 message_sent 這種 fire-and-forget 鉤子），所以這是目前可行的最佳方案。

---

號稱接近 Opus，卻連自己平台的外掛都寫不對

MiniMax-M2.7 的發佈公告宣稱 SWE-Pro benchmark 56.22%，「接近 Opus 水準」。

但 benchmark 測的是什麼？是在已知的、訓練資料覆蓋率極高的 codebase 上解題。模型擅長的就是這種「常見 pattern 的排列組合」。

寫 OpenClaw 外掛呢？OpenClaw 是 GitHub 上星數最高的軟體專案，250,000+ stars，60 天內超越了 React 十年的紀錄。這不是什麼冷門框架——它的文件、原始碼、社群討論在網路上到處都是。MiniMax-M2.7 的訓練資料裡不可能沒有 OpenClaw。

而且 Itsuki 寫外掛之前確實去讀了 OpenClaw 的文件和原始碼。文件裡寫得很清楚，AgentTool 的介面是 parameters/execute/label。

它讀了正確的文件，然後寫出了錯誤的程式碼。

這不是資料不足的問題，是模型品質的問題。inputSchema/handler 這個 pattern 在 MCP、LangChain、Vercel AI SDK、OpenAI function calling 裡都用到——訓練分佈裡的權重太大了。即使 context window 裡放著正確答案，生成程式碼時 prior 還是贏了。

Benchmark 不測這個。Benchmark 不會問「你能不能在讀完文件之後，抵抗自己的訓練分佈，寫出跟文件一致的程式碼」。但這才是實際開發中最重要的能力之一。

---

但公平地說：問題不只是模型

最後修好這個外掛的是 Claude Code（Opus）。但如果要公平評價，得問一個問題：換成 Opus 在同樣的條件下，會不會也寫錯？

老實說，大概也會。inputSchema/handler 在 Opus 的訓練資料裡一樣是壓倒性的主流 pattern。如果純靠記憶直接寫，第一版很可能也會中一樣的陷阱。

Opus 能修好它，不是因為模型本身比較聰明，而是因為環境不同：

1. 它從看 error message 開始，不是從零寫起
2. 它可以用 Object.keys(OpenCC) 確認實際有哪些方法，不用猜
3. 它一路追型別定義：registerTool → AnyAgentTool → AgentTool → Tool → 確認是 parameters 不是 inputSchema
4. 每次改完可以重啟 Gateway、看 log、確認結果

而且 Opus 也犯了錯——它把 configSchema 從 manifest 拿掉，導致 Gateway 拒絕載入。多浪費了一次重啟才發現。

Itsuki 呢？它也有 shell 存取權限，也讀了原始碼，但它一口氣寫完就交出去了。崩潰發生在 OpenClaw 的 Gateway 層級——不在 Itsuki 的對話裡。從它的角度看，外掛寫完了，任務結束了。它根本不知道自己搞砸了。

如果把 MiniMax-M2.7 拉到 OpenClaw 之外，給它同樣的 feedback loop——error message、shell 存取、iterate 的機會——它大概也能修好自己的 bug。

模型的差異沒有 feedback loop 的差異大。

---

真正的缺口在 OpenClaw

這件事暴露的與其說是模型的問題，不如說是 OpenClaw 的架構缺口：

外掛沒有驗證步驟。

如果 OpenClaw 在載入外掛時有一個 sandbox 驗證——檢查 registerTool 的呼叫有沒有符合 AgentTool 介面、parameters 有沒有 properties 欄位——然後把驗證結果回饋到對話裡，Itsuki 就能在同一個 session 內看到錯誤、自己修正。

現在的狀況是：外掛載入失敗或造成崩潰，錯誤只出現在 Gateway 的 stderr log 裡。對話裡的 AI 完全不知道發生了什麼事。它以為自己成功了，但使用者發訊息過來就只有一行 Cannot read properties of undefined。

這不是「AI 太笨所以寫不好 code」，這是「系統沒有告訴 AI 它寫的 code 壞了」。

任何開發者——人類或 AI——在沒有 feedback loop 的條件下都會交出有 bug 的程式碼。差別在於有 feedback loop 的時候，好的開發者能夠自我修正。OpenClaw 把這條路切斷了。