Anthropic Skills. 新模型和架构的全景
Source: Dev.to
引言
Skills 是模块化、按需加载的数据，能够把通用 LLM 转变为专用代理。这并不是关于 MCP 或花哨的协议——而是关于 上下文工程：在恰当的时机加载恰当的信息。
Skill 是一种记忆、指令、事实或代码片段，按需加载到你的 LLM 的上下文窗口中。
Skill 也是 RAG + System Instructions + Domain Expertise 的组合。
你可以用技能实现的所有功能，技术上也可以不使用技能而实现：把大量 token（工具、指令、示例）加载进上下文，使用一个思考时间足够长的大推理模型，就能得到尚可的结果。然而，基于技能的新方法更简单、更快、更便宜，也更具可扩展性。
这并不是关于 MCP
我写代码已有 14 年，密切关注 AI 动向，自认是个 vibe‑coder。大约一年前，我分享了我从 开发者视角 对 MCP 的看法：关于 MCP 的开发者思考。
我的核心论点： MCP 作为一种方法和编程模式未必是最佳解决方案。
- 我不使用 MCP 服务器，因为它们在我的使用场景下表现不佳。
- 编码代理已经足够：终端命令、文件系统、网页搜索能够处理大多数情形。
- 当代理必须调用外部工具（例如创建 Google Calendar 事件）时，我需要更稳健的自定义代码，而不是 MCP 包装器。
- 我的调试工作流：手动添加 3‑4 个文件 + 1‑2 个文档链接。这比任何自动化上下文检索都更有效。
这些文件和链接本可以自动发现——这正是技能所承诺的：让代理更聪明。
上下文工程
我感觉架构正在发生转变：
- 之前： 大型通用预训练模型 或 微调模型。
- 之后： 小型推理模型搭配新架构进行学习 + Skills 解决任务特定问题。
“上下文工程是用恰当的信息填充上下文窗口，以完成下一步的精细艺术与科学。” — Andrej Karpathy
关键洞见：这不是拥有最大的模型，而是拥有 在正确时刻的正确上下文。
前进的路径
这仍然是研发阶段——是主流 LLM 开发的一个分支，而非替代品。Anthropic 已经在这上面工作了 6 个月以上，我们是早期采用者，在主流到来之前探索更好的方向。我的预测是：六个月后，所有人都会涌向基于技能的代理架构。
我们需要：
- 自动化技能发现。
- 可组合的技能库——将技能组合用于复杂的多步骤工作流（例如 n8n）。
- 行业特定的技能包——为常见开发者任务预构建的专业知识，如 Angular 技能或 GitHub Runner 技能。
结论
Skills 体现了一种模块化、可复用、按需提供的专业知识哲学，能够把任何 LLM 转变为特定工作流的专用代理。我相信这是一条正确的道路，并计划密切关注其进展，最终编写利用或扩展 Skills 的新项目。