文章回顾了LLM扩展功能的发展历程，从最初的简单文本交互到如今能够操作代码库和浏览器的智能代理，探讨了如何让终端用户真正定制这些系统。作者特别提到ChatGPT插件的超前设计，展示了通过标准API实现通用工具使用的AGI思路。随着模型能力提升，用户定制方式也从简单提示演变为复杂的客户端-服务器协议。

标题：大语言模型扩展的苦涩教训

三年前，"使用大语言模型"意味着将大段文本粘贴到聊天框中，期待获得有用的回复。如今，我们可以让智能代理访问代码库、浏览器，并代表我们执行操作。在此期间，一个关键问题逐渐浮出水面：如何让终端用户真正定制这些系统？

随着模型能力的提升，终端用户定制模型的方式和机制也在不断扩展。我们从简单的系统提示发展到复杂的客户端-服务器协议，然后又回归简单。

让我们回顾过去三年大语言模型扩展的发展历程，并展望未来趋势。

ChatGPT插件（2023年3月）

OpenAI在发布仅四个月后就推出了ChatGPT插件。这个构想极具野心：给大语言模型一个OpenAPI规范的链接，让它自由调用REST端点。这是通向通用人工智能思维的直接路径：通过标准API实现通用工具使用。

但问题在于：模型尚未准备好。GPT-3.5（甚至早期的GPT-4）难以驾驭庞大的API规范，容易产生幻觉或迷失在上下文中。此外，用户体验也很笨拙——每次聊天都需要手动切换插件！

不过，这让我们窥见了未来："代码解释器"插件（后更名为高级数据分析）成为不可或缺的工具，预示了我们今天使用的强大沙盒执行环境。

自定义指令（2023年7月）

作为对插件复杂性的"简化"反应，自定义指令功能应运而生。它只是在每次聊天时附加用户定义的提示，简单明了却解决了重复设置上下文的大问题。这成为后来所有.cursorrules和CLAUDE.md文件的精神先驱。

自定义GPT（2023年11月）

OpenAI将指令和工具重新打包为"自定义GPT"，试图将提示工程"产品化"。用户可以将角色、文件和操作捆绑成可分享的链接，这标志着从插件的开放式承诺向精心策划的单一用途"应用"的退却。

ChatGPT记忆功能（2024年2月）

记忆功能代表了向自动个性化的转变。它能记录对话细节并悄悄插入未来上下文，就像自动编写的系统提示。虽然是个小功能，却标志着代理开始无需用户干预就能维护长期状态。

Cursor规则（2024年4月）

Cursor通过将自定义指令放在它们应有的位置——代码仓库中——改变了游戏规则。.cursorrules文件是个启示：不再需要将上下文粘贴到聊天窗口，而是将其提交到git中。它从一个文件发展为.cursor/rules文件夹，具有复杂的范围界定功能，首次让扩展感觉"原生"于代码。

模型上下文协议（2024年11月）

到2024年底，模型终于足够智能，可以可靠地处理真实工具。Anthropic的模型上下文协议（MCP）应运而生。这个重量级解决方案需要客户端与服务器保持持久连接，为代理提供工具定义、资源和提示。虽然功能强大，但对终端用户来说设置复杂，催生了Smithery等初创公司来简化使用。

Claude Code新代理（2025年2月）

2025年初推出的Claude Code几乎集成了所有扩展机制： - CLAUDE.md：仓库级指令标准 - MCP：重型工具集成 - 斜杠命令：可重用提示 - 钩子：拦截和修改代理循环的能力 - 子代理：处理子任务的专业工作者 - 输出样式（已弃用）

代理技能（2025年10月）

代理技能是ChatGPT插件的重生。与MCP的客户端-服务器协议不同，代理技能只是由markdown文件和脚本组成的文件夹。代理扫描skills/目录，读取每个SKILL.md的前言，建立轻量级索引，仅在任务适当时才读取完整内容。这解决了MCP的主要问题：必须将所有工具定义加载到上下文窗口导致的膨胀。

未来展望

技能实现了ChatGPT插件设定的梦想：只需给模型指令和一些通用工具，相信它能完成中间的粘合工作。现在可能真的可行，因为模型已经足够智能。

技能之所以有效，是因为它假设代理有能力（通过bash命令）编写自己的工具。你可以给它代码片段，要求代理为手头任务找出通用运行方式。这预示着对代理的新定义：代理不仅是循环中的大语言模型，而是配备了计算机的大语言模型。

展望2026年，预计会有越来越多的大语言模型应用以新颖有趣的方式"配备计算机"——无论我们是否意识到。如果可以，我会看空MCP，预计我们将回归用最易访问的编程语言——自然语言来扩展代理。

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

1. 关于LLM的进步与局限性

   • 正面观点：即使LLM存在幻觉问题，其信息处理能力的提升仍将改变世界（评论1："Even if all we get is to have an LLM be right more times than it is wrong, the world will change again."）
   • 质疑观点：模型改进与"苦涩教训"（bitter lesson）无关，依赖人工干预（如API或提示词）并非真正的进步（评论4："A 'bitter lesson' would be that the model can do better without any injection"）

2. 对MCP（可能指某种接口协议）的争议

   • 中立评价：MCP设计复杂但可能是必要的过渡方案（评论2："MCP seems to me to be right on the edge of what you'd define as a 'working simple system'"）
   • 批评观点：MCP存在惯性问题，人们忽视更优方案如"Skills"（评论3："people are in the MCP 'inertia' and having no time to shift to Skills"）

3. 关于Skills的讨论

   • 支持观点：Skills是ChatGPT插件的实际演进，模型已足够智能支持（评论3："Skills are the actualization of the dream that was set out by ChatGPT Plugins"）
   • 反对观点：OpenAI挪用学术术语"skill"造成语义混乱（评论10："Now OpenAI has usurped the term to refer to these inference-guiding .md files"）

4. 技术实现建议

   • 将提示词视为随机程序并开发专用shell（评论5："treating prompts as stochastic programs and using a special shell"）
   • Shell集成才是LLM最实用的扩展（评论11："An LLM with a shell integration can do anything you need it to"）

5. 批评与遗漏

   • 文章未讨论LLM采样等关键问题（评论6："Zero discussion around LLM sampling"）
   • 自然语言的模糊性使其难以替代精确编程（评论12："Natural language is so ambiguous... math has its own domain specific language"）

（注：部分术语如MCP/Skills因上下文有限，总结保留原始表述）