编者按： 在当前 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
