LangChain 在 2026 年 5 月 29 日介紹 interpreter skills。這個概念很適合正在做企業 agent 的團隊，因為它解決一個常見問題：有些流程不該只寫在 prompt 裡，應該變成可審查、可測試、可重用的 code。
傳統 skill 通常包含 SKILL.md，告訴 agent 什麼時候使用、怎麼做、有哪些限制和範例。Interpreter skill 則進一步加入 module，例如 index.ts，讓 agent 可以在 interpreter 裡 import 並執行固定流程。
Interpreter skill 是什麼？
它可以理解成兩層：
SKILL.md：讓 agent 發現這個能力，知道何時使用。index.ts：讓 interpreter 執行已審查的流程程式碼。
模型仍然負責判斷 skill 是否適用、要傳什麼參數、如何使用結果。但流程中比較確定的部分，可以放進 module 裡。
這就把「請 agent 乖乖照流程做」變成「讓 agent 呼叫一個已經寫好的流程」。
為什麼 prompt-only procedure 容易脆弱？
如果流程只寫成文字指令，agent 可能：
- 跳過步驟。
- 改變步驟順序。
- 把不相關要求混進流程。
- 中途被新要求打斷。
- 最後輸出看起來合理，但其實沒有完整執行。
對低風險任務，這可能還能接受。但對 invoice、repo triage、customer escalation、資料清理、合規檢查來說，流程是否完整執行本身就是品質的一部分。
Interpreter skill 的好處
| 好處 | 說明 |
|---|---|
| 可審查 | 固定流程在 code 裡，可以 code review |
| 可測試 | 可以對 module 寫 unit tests 或 integration tests |
| 可重用 | 多個 agent 可使用同一個 skill package |
| 可評估 | 可以檢查是否呼叫指定函式和正確 input |
| 可控 | 工具和 subagent access 仍透過 host runtime allowlist |
它不是要把 agent 變回死板 workflow，而是把「需要穩定」的部分固定下來，把「需要判斷」的部分留給模型。
適合的例子：Repo triage
LangChain 的例子是 GitHub repo triage。
使用者要求 agent 分析 repository 的 issues、pull requests 和 discussions。若只靠 prompt，agent 可能每次都用不同方法處理，長任務中還可能失去一致性。
Interpreter skill 可以把 triage procedure 寫成函式：
- 抓取開放項目。
- 對每個項目啟動 subagent 做 condensed description。
- 把結果放進 queue。
- 逐項分群。
- 產生 structured result。
- 最後轉成 markdown 報告。
模型不用把 300 個中間狀態都放在 context 裡，只要呼叫流程、查看結果，再做後續判斷。
和一般 script 有什麼不同？
Script 通常透過 command args、files、stdout、stderr 或 serialized state 和外部環境互動。
Interpreter skill 則能參與 agent harness loop，例如：
- spawn subagents。
- 呼叫 allowlisted tools。
- 管理 task graph。
- 處理 partial failures。
- 回傳 structured object。
- 讓 agent 繼續檢查結果或呼叫下一步。
因此它比較適合 agent workflow，而不只是一次性資料處理。
哪些工作適合做成 interpreter skill？
可以優先考慮：
- CSV 清理與驗證。
- Invoice submission。
- GitHub issue triage。
- Customer ticket clustering。
- Research source scoring。
- Document batch extraction。
- Compliance checklist。
- Report generation pipeline。
- Multi-subagent review workflow。
判斷標準很簡單：如果流程必須重複、步驟可定義、結果需要被測試，就值得從 prompt 移到 skill code。
對 eval 的影響
Interpreter skills 讓評估更具體。
Prompt-only 時，問題常常是：
- Agent 有沒有大致遵守？
- 最後結果看起來對不對？
- 是否偏離流程？
Interpreter skill 可以改問：
- 是否呼叫指定 function？
- input shape 是否正確？
- module output 是否符合 schema？
- partial failure 是否被處理？
- 是否有在禁止情境下呼叫？
這讓 agent eval 更接近工程測試，而不是只靠人工感覺。
官方來源
結論
Interpreter skills 的價值，是把 agent workflow 裡「固定、可測、可重用」的部分抽成 code，同時保留模型判斷何時使用的彈性。
企業做 agent 時，不應把所有流程都塞進 prompt。比較成熟的做法，是把關鍵流程包成 skill：用 SKILL.md 做 progressive disclosure，用 module 承載確定性邏輯，用 trace 和 eval 監控是否真的被正確使用。