看到 Open Responses 這個專案，覺得蠻興奮的。這是我一直在等的東西: 一個 vendor-neutral 的 LLM API 規範。

做過 LLM 應用開發的人都知道，各家 API 的 building blocks 其實很像 — messages、tool calls、streaming、multimodal inputs — 但每家的 JSON schema 都不一樣，整合多個 provider 的時候超痛苦。Open Responses 要解決的就是這個問題: 定義一套共用的 request/response 規範，寫一次就能跑在不同 provider 上。

為什麼值得關注

🔹 以 OpenAI Responses API 為基礎: 不是從零開始造輪子，而是基於 OpenAI 最新的 Responses API 來設計。Simon Willison 提到，雖然 Chat Completions API 已經被很多人 clone 了，但 Responses API 的設計本身就考慮了 reasoning traces 等新功能，拿來當標準的基礎更合理。

🔹 為 Agentic Workflow 設計: 規範的核心概念是「Items」— 把 model output 和 tool use 當作原子單位。定義了清楚的 agentic loop: model 可以發出 tool calls、接收結果、繼續執行。對於現在越來越複雜的 Agent 架構來說，這很重要。

🔹 Semantic Streaming Events: 不是給你 raw text deltas，而是語義層級的 streaming events，讓 client 端可以做到 provider-agnostic 的 streaming 處理。

🔹 Launch Partners 很強: OpenRouter、Hugging Face、LM Studio、vLLM、Ollama、Vercel 都是首批支援者。光 OpenRouter 一家就涵蓋了幾乎所有主流 model。這代表這個規範不是空談，而是有實際的生態系支撐。

Compliance Testing

比較有意思的是他們提供了 compliance test suite，可以驗證 server 端的實作是否符合規範。有 Web UI 也有 CLI，可以直接對著你的 API endpoint 跑測試。

不過 Simon 也指出一個目前的缺口: 測試只涵蓋 server 端，client 端的 conformance suite 還沒有。他計畫自己用 Python 寫一個 client library，希望也能有對應的測試來驗證 client 實作的正確性。

我的看法

LLM API 的「事實標準」一直都是 OpenAI 的 Chat Completions API — 大家都在 clone 它，但沒有人真正把它變成一個 open spec。Open Responses 走了正確的一步: 不只是文件化，還有 OpenAPI reference、compliance tests、open governance。

對於做 LLM 應用的開發者來說，如果這個規範真的被廣泛採用，意味著你不再需要為每個 provider 寫 adapter，切換 model 的成本會大幅降低。這對整個生態系的健康發展是好事。

以上，推薦關注 openresponses.org，也推薦看看 Simon Willison 的評論。