編者按： 在當前 LLM 能力日益增強、擴展方式不斷演進的背景下，我們是否正在走向一種“越複雜越強大”的技術路徑？抑或，真正的突破恰恰源於迴歸簡單與通用？

今天我們為大家帶來的文章指出，儘管過去三年間出現了從插件、上下文協議、記憶功能等多種擴展機制，但最終的趨勢很可能是：賦予智能體通用的計算能力，並相信它能自主完成複雜任務，而非依賴過度設計的專用工具。

文章系統梳理了過去三年 LLM 擴展方式的演進脈絡 —— 從 ChatGPT 插件的超前嘗試，到自定義指令的簡化回潮。從 MCP 協議的重量級架構，到 Agent Skills 以 Markdown 和腳本實現的輕量級“重生”。作者指出，早期因模型能力不足而失敗的“通用工具+自然語言指令”願景，如今正因模型真正變“聰明”而成為可能。

作者 | Sawyer Hood

編譯 | 嶽揚

三年前，“使用大語言模型”還意味着把一大段文字粘貼到聊天框裏，然後期待能收到些有用的東西。如今，我們讓智能體對接代碼庫、操控瀏覽器，允許它們自主運行並代表我們執行具體任務。在此期間，有一個關鍵的問題一直在醖釀：我們如何能讓終端用户真正地按照自己的意願、為滿足自己的具體需求，來調整和塑造這些 AI 系統的工作方式？

隨着模型能力的增強，終端用户可用的定製方式和機制也在不斷擴展。我們從簡單的系統提示詞起步，演進到複雜的客户端-服務器協議，而後又再次迴歸簡化的模式。

我想借此機會回顧一下過去三年大語言模型擴展方式的演變，並談談我對未來趨勢的看法。

01 ChatGPT 插件（2023 年 3 月）[1]

在 ChatGPT 發佈僅四個月後，OpenAI 就推出了 ChatGPT 插件。如今回過頭看，這項設計在當時可謂極度超前。

這一構想雄心勃勃：給大語言模型一個符合 OpenAPI 規範的鏈接，讓它“自由發揮”，調用各類 REST 接口。這直接體現了 AGI 式的思維模式：通過標準化 API 實現通用工具的調用。

{
"schema_version":"v1",
"name_for_human":"TODO Manager",
"name_for_model":"todo_manager",
"description_for_human":"Manages your TODOs!",
"description_for_model":"An app for managing a user's TODOs",
"api":{"url":"/openapi.json"},
"auth":{"type":"none"},
"logo_url":"https://example.com/logo.png",
"legal_info_url":"http://example.com",
"contact_email":"hello@example.com"
}

那麼問題出在哪裏呢？當時的模型尚未準備就緒。GPT-3.5（甚至早期的 GPT-4）在處理龐大的 API 規範文檔時存在困難，很容易“產生幻覺”（譯者注：即編造不存在的信息或調用不存在的接口）或在上下文信息中“迷失方向”（譯者注：即無法準確理解或跟蹤當前任務所需的上下文，導致錯誤操作或理解偏差）。此外，用起來也很麻煩，每開始一個新的對話，即使想使用和上一次相同的插件，也必須重新手動在列表中找到並點擊啓用它。

儘管當時存在種種不足，但 ChatGPT 插件仍讓我們窺見了未來：其中的 Code Interpreter 插件（後更名為 Advanced Data Analysis）變得不可或缺，它預示了我們今天正在使用的強大代碼執行沙箱。

02 自定義指令（2023 年 7 月）[2]

自定義指令是對插件過於繁雜的一種“化繁為簡”的迴應。寫到這裏時我甚至愣了一下，因為我一度認為這項功能是在插件之前推出的。

它只是在每次對話中自動追加一段用户自定義的提示詞（prompt）。簡單、直觀，卻解決了一個大麻煩：重複設置上下文。

它可被視為後來所有 .cursorrules 和 CLAUDE.md 文件的理念原型。

03 Custom GPT（2023 年 11 月）[3]

OpenAI 將指令和工具重新打包，推出了“Custom GPT”。這是將提示詞工程“產品化”的一次嘗試：你可以將一個角色設定、若干文件和幾個操作打包成一個可分享的鏈接。

相比插件最初所承諾的那種開放、靈活、可自由擴展的能力，Custom GPT 的做法實際上是一種戰略上的退讓 —— 它轉向了經過精心設計、功能單一的“應用”（apps）模式。

04 ChatGPT 的記憶功能（2024 年 2 月）[4]

之前的擴展方式（如自定義指令、插件、Custom GPT 等）都依賴用户主動提供上下文或相關配置。而“記憶”功能則由系統自動記錄並利用用户的歷史對話信息，在用户無需干預的情況下動態調整模型行為，實現更自然、持續的個性化體驗。

ChatGPT 記憶會記錄你對話中的細節，並在後續對話的上下文中悄悄插入這些信息。這就像一個能自我編寫的系統提示詞。比如你提到自己是素食者，幾周後它依然記得。這個功能雖小，卻標誌着智能體開始能自主積累和利用上下文信息，像一個有“記憶”的助手一樣持續與用户互動，而不是每次對話都從零開始。

05 Cursor Rules（2024 年 4 月）[5]

以前，用户得在聊天界面裏反覆輸入或設置上下文（比如代碼風格、項目規範等），既麻煩又難以複用。而 Cursor 的做法是把這些指令直接寫進項目代碼倉庫，從而徹底改變了這一遊戲規則。

.cursorrules 文件的出現令人耳目一新。它不再需要你把項目上下文手動粘貼到聊天窗口裏，而是讓你直接將這些規則提交到 Git 倉庫中：

• "We use tabs, not spaces."
• "No semicolons."
• "Always use TypeScript."

它最初只是一個單獨的文件，後來演變為一個 .cursor/rules 文件夾，支持更精細的作用域控制。你可以組織多個規則文件，甚至指定它們的適用條件，比如僅對特定文件類型或子目錄生效。這是人們第一次覺得對大語言模型的擴展真正“原生地融入”了代碼本身。

後來，Cursor 還引入了讓大語言模型自行決定何時應用某條規則的功能 —— 這種模式我們之後還會再次見到。

06 模型上下文協議（2024 年 11 月）[6]

到了 2024 年底，大語言模型終於變得足夠智能，能夠穩定、可靠地操作真正的工具了。Anthropic 推出的模型上下文協議（Model Context Protocol, MCP）正是對這一能力需求的正式迴應。

MCP 是一個重量級的解決方案。使用 MCP 時，客户端必須與 MCP 服務器保持一個持久的連接。服務器負責向客户端（通常是智能體）提供工具的定義、資源（如文件、日誌等）以及提示詞。當客户端決定調用某個工具時，它會向服務器發送一條消息説明“我調用了這個工具”。隨後，服務器執行該工具（或協調執行），並將結果返回給客户端。

與“自定義指令”（僅附加上下文）不同，MCP 賦予模型真正的執行能力 —— 它可以讀取你的代碼倉庫、查詢你的 Postgres 數據庫，甚至部署到 Vercel。除了提供工具，MCP 還允許服務器直接向智能體提供資源（如文檔、日誌）和提示詞。

這套機制雖然功能非常強大，但可能有點“用牛刀殺雞”了。雖然複雜，但對構建智能體的開發者而言，多花點功夫也值得。但若要求普通用户自行搭建並連接 MCP 服務，門檻就太高了。正因如此，圍繞降低 MCP 使用難度的初創生態迅速興起，比如 Smithery[7] 這類公司。

值得注意的是，2025 年 10 月發佈[8]的 ChatGPT Apps 實際上正是以 MCP 作為底層基礎構建的。這是 OpenAI 試圖讓終端用户在無需感知 MCP 存在的前提下，也能享受其能力的一次嘗試。

07 Claude Code：新智能體，新擴展機制（2025 年 2 月）

2025 年初，Anthropic 發佈了 Claude Code，幾乎將當時所有的 LLM 擴展機制集於一身：

• CLAUDE.md：為整個項目倉庫設置操作規範的標準化方式。
• MCP：用來對接那些功能強、結構複雜的外部工具。
• 斜槓命令（Slash Commands） ：類似於 Cursor 提供的 Notebooks 功能，用於保存和複用提示詞。
• 鈎子（Hooks） ：能在智能體運行過程中介入並調整其執行流程（例如：“如果測試失敗，就立即停止”）。
• 子智能體（Sub-agents） ：動態創建專門的“子智能體”（或工作單元）來處理特定的子任務。
• 輸出風格（Output Styles） ：（已棄用）用於配置回答語氣和響應格式。

這些功能中哪些能長期留存，仍有待時間檢驗。事實上，Anthropic 已經嘗試棄用“輸出風格”這一特性[9]。

08 Agent Skills（2025 年 10 月）

Claude Code 新增的這一擴展機制意義重大，值得深入探討。Agent Skills 可視為 ChatGPT 插件理念的“重生”。

MCP 依賴一整套客户端-服務器通信協議，而 Agent Skills 則簡單得多 —— 它們只不過是包含 Markdown 文件和腳本（可用任意語言編寫）的普通文件夾。

智能體會簡單地掃描 skills/ 目錄，讀取每個 SKILL.md 文件的 frontmatter（前置元數據），並據此構建一個輕量級索引。只有當某項技能與當前任務相關時，它才會加載該技能的完整內容。這解決了 MCP 的一個主要痛點：所有工具的定義都必須一次性塞進模型的上下文窗口，導致上下文膨脹（context bloat）

以下是從 Anthropic 的 Skills 示例倉庫[10]中摘錄的一個用 Playwright 做端到端測試的技能結構片段：

webapp-testing/
├── examples/
│   ├── console_logging.py
│   ├── element_discovery.py
│   └── static_html_automation.py
├── scripts/
│   └── with_server.py
└── SKILL.md

Skill 目錄中可以包含腳本、示例和純文本説明等多種內容，形式靈活。但其中唯一必需的文件只有 SKILL.md。接下來，我們來看看這個文件長什麼樣：

---
name: webapp-testing
description: Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
license: Complete terms in LICENSE.txt
---

# Web Application Testing

To test local web applications, write native Python Playwright scripts.

 **HelperScripts Available**:

- `scripts/with_server.py` - Manages server lifecycle (supports multiple servers)

 **Always run scripts with `--help` first **  to see usage. DO NOT read the source until you try running the script first and find that a customized solution is absolutely necessary. These scripts can be very large and thus pollute your context window. They exist to be called directly as black-box scripts rather than ingested into your context window.

這只是一個包含一些元數據和技能描述的普通 Markdown 文件。智能體讀取該文件，並可以自由引用其中提到的其他文件（智能體也能讀取這些文件）。相比之下，一個 Playwright MCP 服務器需要定義幾十個工具來控制瀏覽器，而這個 Skill 只需説一句：“你擁有 bash 環境，這是編寫 Playwright 腳本的方法。”

誠然，要使用“Skill”，智能體必須具備對計算機的通用訪問能力 —— 但這恰恰體現了“苦澀的教訓”（the bitter lesson）[11]：與其為每個任務都定製一套專用工具，不如給智能體提供通用工具，並相信它有能力自主運用這些工具來完成任務 —— 這很可能才是制勝之道。

09 未來展望

Agent Skills 真正實現了 ChatGPT 插件最初所描繪的那個願景：只需給模型提供一些説明（instructions）和通用工具（generic tools），然後相信它能自己完成中間所需的“膠水”工作。而我有一個假設：如今這種模式之所以可能奏效，是因為模型真的足夠聰明瞭。

Agent Skills 之所以有效，是因為它默認智能體具備“自己編寫工具”的能力（比如通過 bash 命令等）。你不需要提供一個封裝好的專用工具，而只需給它一段代碼片段，它就能自行推斷如何通用地運行這段代碼，來應對當前任務。

更重要的是，我認為“Agent Skills”正在重新定義“智能體”的本質。智能體不再僅僅是一個在 while 循環裏不斷運行的大語言模型（LLM），而是一個綁着一台計算機的、在 while 循環裏跑的大語言模型。

Claude Code 是第一個讓我真正意識到這一點的軟件，但它過於面向開發者，遠非面向大眾的終極形態。其他應用（如 Zo Computer[12]）試圖將大語言模型與計算機能力打包成一個整體應用，但我認為，它們仍未充分向終端用户隱藏底層計算機的複雜性。畢竟，當我請同事幫忙做一件事時，我不需要知道他電腦裏所有的文件結構或操作細節。我只需要知道他有一台能用的電腦，並且相信他能自己搞定就行了。

展望 2026 年，我相信我們使用的 LLM 應用將越來越多地以新穎而巧妙的方式“綁上一台計算機” —— 而作為用户，我們可能根本察覺不到。

如果我能“做空” MCP，我一定會“做空”它。我預計，我們最終會迴歸到用最易用、最普適的“編程語言”來擴展智能體 —— 那就是自然語言。

END

本期互動內容 🍻

❓作者認為未來的方向是“給模型通用工具，讓它自己寫膠水代碼”，而不是依賴複雜協議。你認同這個“苦澀的教訓”嗎？為什麼？

文中鏈接

[1]https://openai.com/index/chatgpt-plugins/

[2]https://openai.com/index/custom-instructions-for-chatgpt/?utm_source=chatgpt.com

[3]https://openai.com/index/introducing-gpts/

[4]https://openai.com/index/memory-and-new-controls-for-chatgpt/

[5]https://cursor.com/changelog/0-32-x

[6]https://en.wikipedia.org/wiki/Model_Context_Protocol

[7]https://smithery.ai/

[8]https://openai.com/index/introducing-apps-in-chatgpt/

[9]https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md#2030

[10]https://github.com/anthropics/skills/blob/main/webapp-testing/SKILL.md

[11]https://en.wikipedia.org/wiki/Bitter_lesson

[12]https://www.zo.computer/

本文經原作者授權，由 Baihai IDP 編譯。如需轉載譯文，請聯繫獲取授權。

原文鏈接：

https://www.sawyerhood.com/blog/llm-extension