假設我想讓 Codex 每次改 OpenAI API integration 前，都先查一次最新官方文件。
最直覺的做法，是每次都在 prompt 裡補一句：「先查 docs，不要靠記憶。」做兩三次沒什麼，做久了就會開始忘。更麻煩的是，真正需要固定下來的通常不只這一句，還包含怎麼查、查完要比對什麼、哪些相容性不能動，以及最後要跑哪些 verification。
這時 Skill 才開始有價值。
OpenAI 在 Agents SDK repositories 裡就是這樣用。implementation-strategy 處理 implementation 前的相容性判斷，code-change-verification 管 code、tests、examples 與 build behaviour 的驗證，openai-knowledge 則負責在碰到 OpenAI API 或 platform integration 時，把「先查 current docs」變成工作流程的一部分。[3]
但 openai-knowledge 自己沒有把整份官方文件塞進 Skill。它需要 current docs 時，會走官方 Docs MCP workflow 去拿。[3]
光這一個例子，其實就足夠把 Skill 和 MCP 分開了。
Skill 比較適合放「每次遇到這類工作，我都想這樣做」
Codex 的 Agent Skills 是 folder-based。最小單位是 SKILL.md，旁邊可以帶 scripts、references、assets。使用者可以直接指定 Skill，也可以讓 Codex 根據任務內容選用。[1]
my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/我會把 Skill 想成一套會重複出現的工作方法，而不是「比較長的 prompt」。
像這些就很適合：
- API change 前先確認 compatibility boundary
- code change 完成後固定跑哪一批 verification
- 文件和 source code 要怎麼一起檢查
- release 前有哪些條件不能漏
- PR handoff 最後要留下哪些資訊
OpenAI 自己的 repositories 也是沿著這個方向拆。Codex 一開始只需要知道有哪些 Skills；真的選到某個 Skill，才讀 SKILL.md，再依需要載入 references 或 scripts。[3]
這種 progressive disclosure 很實際。你不用把所有 SOP 一次塞進 context，只有這次工作真的會用到的那套 procedure 才進來。
但一次性的簡單要求不需要硬做成 Skill。沒有穩定 procedure、沒有會反覆使用的 reference 或 script，多做一個 Skill 只是多一個要維護的地方。OpenAI 在 2026 年 1 月 deprecated Custom Prompts 時，也把 reusable instructions and workflows 往 Skills 引導。[2]
MCP 解決的是「外面的東西要怎麼進來」
回到 openai-knowledge。
Skill 可以規定：
Before changing an OpenAI API integration,
check the latest official documentation.但這句話本身拿不到最新文件。真正把外部能力接進 workflow 的，是 MCP 那一層。[3]
這裡很容易偷懶講成「Skill 是 instruction，MCP 是 tool」，但 MCP 比這個大。2025-03-26 的 specification 裡，server 可以暴露 resources、prompts 和 tools。[6]
也就是說，一個 MCP server 不只可能讓 Codex 呼叫 action，也可能提供可讀 context，或提供可發現、可帶參數的 prompt template。
所以我會用一個很普通的判斷方式：如果缺的是「這類工作應該照什麼 procedure 做」，先想 Skill；如果缺的是「這個 workflow 要怎麼穩定接到外部 capability」，才看 MCP。
兩者可以一起用，也可以完全分開。
Tool Search 解決的是另一個痛點：工具多到不該全部塞進 prompt
MCP server 接得越多，下一個問題很快就會出現：工具很多時，模型到底要不要一開始就看到每一個完整 definition？
GPT-5.4 在 2026 年 3 月 5 日加入 Tool Search。OpenAI 對它的描述很具體：以前工具很多時，所有 tool definitions 可能一起進 prompt；Tool Search 改成先給模型一個較輕的可用工具清單，真的需要某個工具時，再去查它的完整 definition。[8]
這個設計處理的是 discovery cost，不是 MCP 連線本身。
一個 MCP server 可以已經連好，但模型還沒選到它要用的 tool；Tool Search 可以幫忙從大 catalog 裡找到比較相關的定義，但找到也不等於 action 已經獲得授權，更不等於執行成功。
在 4 月底這個時間點，我會把實際路徑看成：
Integration / MCP configuration
↓
Connection available
↓
Discover or search the relevant capability
↓
Select the action
↓
Approval if this action requires it
↓
Execute
↓
Check the returned result這不是 OpenAI 公布的一條固定產品 pipeline，而是拿來避免把幾種不同狀態混在一起。當時 Codex 已經有 custom MCP approval panels，所以「找得到 tool」和「這個 action 能直接跑」本來就不是同一件事。[7]
這也補上了我覺得最容易被忽略的一點：MCP 把能力接進來；Tool Search 幫忙在大量能力裡找；權限與 execution 則還有自己的邊界。
外部資料已經拿得到，就不需要為了漂亮再加一個 MCP
看到 external data 或 tool 就自動接 MCP，反而會讓系統變胖。
如果某份資料已經能從現有 tool path 取得，或 workflow 根本不需要另一個 MCP-compatible integration，那就不要為了讓架構圖看起來完整，多養一個 server、多一組 auth，再多一個故障點。
MCP 比較值得用的情況，是你真的需要一個標準化的 client/server interface，或目標服務本來就提供 MCP server，這條路本來就是它的正式 integration surface。
歷史順序也證明 MCP 不依賴 Plugin 才能存在。OpenAI 在 2025 年 12 月的 Codex for Linear 說明中，就已經提到 local Codex 可以透過 MCP 連 Linear。[7]
所以這種畫法會誤導：
Plugin → Skill → MCPSkill 不一定要走 MCP；MCP 也不必先包進 Plugin。
Plugin 是等到「這套東西要搬家」時才真的有感
我自己會把 Plugin 放得比較後面想。
一個 Skill 已經能跑，MCP 也接好了，而且只有自己或單一 repository 在用，這時不包 Plugin 完全沒問題。
2026 年 3 月 25 日的 Codex Plugins 可以把 Skills、app integrations 和 MCP server configuration 放進一個 installable bundle。[4]
my-plugin/
├── .codex-plugin/
│ └── plugin.json
├── skills/
├── .app.json
├── .mcp.json
└── assets/當真正的問題變成「另一個人怎麼裝到一樣的 setup」、「另一個 repo 怎麼重建同一組能力」，Plugin 才開始省事。
如果 setup 還每天在變，先包起來通常只會多一份同步工作。等它穩定，而且 distribution 已經真的成為問題，再做 package 比較自然。
裝好了，不代表這次真的用到了
這一段比名詞本身更重要。
Plugin 出現在介面裡，最多先證明 package 已安裝或可發現。如果它裡面依賴 app 或 MCP connection，後面還會碰到 connection、workspace control、approval 等條件。Enterprise / Edu 的 release notes 已經說明 Plugin access 會受到 workspace app controls 影響；Codex App 當時也已有 custom MCP approval panels。[5][7]
所以我不太會拿一個綠燈當完成證據。
如果這次工作的 claim 是「Codex 已經透過 MCP 查到最新文件」，至少要看到那次 lookup 的結果；如果 claim 是「某個 external action 已執行」，就要看 call 和回傳。Installed、connected、authorised、executed 是不同事情。
拿文章開頭那個 OpenAI API integration change 回來看，流程其實很普通：先因為任務類型選到 Skill；Skill 要求查 current docs 時，走 Docs MCP；工具很多時，Tool Search 可以減少把所有 definition 一次塞進 context 的成本；真正的 action 如果碰到 approval boundary，照既有規則處理；做完再回到 code、tests 和 handoff。
Plugin 則是在另一條軸上。等這整套 setup 要交給別人安裝時，再把相關能力包起來。
不用把四個名詞背成一張產品架構圖。下次遇到問題時，只要先問：我現在缺的是一套會重複使用的做法、一道外部 capability 的介面、在大量 tools 裡找到正確工具的方法，還是把整套 setup 搬給別人的方式？
問題落在哪裡，先處理那一層就好。
References
- OpenAI, ChatGPT & Codex changelog: Agent skills in Codex, 2025-12-19.
https://developers.openai.com/codex/changelog - OpenAI, ChatGPT & Codex changelog: Custom prompts deprecated / Team Config, 2026-01-22 to 2026-01-23.
https://developers.openai.com/codex/changelog - OpenAI Developers, Using skills to accelerate OSS maintenance, 2026-03-09.
https://developers.openai.com/blog/skills-agents-sdk - OpenAI, ChatGPT & Codex changelog: Build and install plugins in Codex, 2026-03-25.
https://developers.openai.com/codex/changelog - OpenAI Help Center, ChatGPT Enterprise & Edu Release Notes: Plugins in Codex, 2026-03-26.
https://help.openai.com/en/articles/10128477 - Model Context Protocol, Specification revision 2025-03-26: Overview / Resources / Prompts / Tools.
https://modelcontextprotocol.io/specification/2025-03-26/index
https://modelcontextprotocol.io/specification/2025-03-26/server/resources
https://modelcontextprotocol.io/specification/2025-03-26/server/prompts
https://modelcontextprotocol.io/specification/2025-03-26/server/tools - OpenAI, ChatGPT & Codex changelog: Codex for Linear / custom MCP approval panels, 2025-12-04 and 2026-04-01.
https://developers.openai.com/codex/changelog - OpenAI, Introducing GPT-5.4: Tool search, 2026-03-05.
https://openai.com/index/introducing-gpt-5-4/