---

为什么 Prompt 和 Agent 都无法 Scale？深度解析 Anthropic Skills 背后的设计范式

在大模型工程进入 2025 年之后，一个共识正在逐渐形成：

Prompt 工程无法 scale，Agent 工程也无法真正 scale。

Anthropic 在《Skills explained》这篇文章里，给出了他们的答案：
不是通过更复杂的 Agent，不是通过更强的 Prompt，而是通过一种新的抽象——Skills。

但如果只把 Skills 理解成“更高级的 prompt”或“隐式 agent”，那几乎必然会误解它真正的价值，也会误判它的适用边界。

本文试图从工程控制、模型训练、系统演化三个层面，完整拆解 Anthropic 的 Skills 体系，并与 LangChain 的白盒流程范式进行对照。

---

一、Anthropic 在解决什么问题？

先明确一个前提：
Anthropic 不是在为复杂业务系统设计框架，而是在为“模型如何使用能力”设计接口。

这与 LangChain 的出发点根本不同。

LangChain 的核心问题是：

如何让工程师明确、可控地把模型嵌入到一个业务流程中？

因此它强调：

• 显式流程（Chain / Graph）
• 显式状态
• 显式分支
• 人类决定 if / else

Anthropic 的核心问题则是：

如何让模型本身，学会在合适的时候使用合适的能力？

因此它关心的不是流程，而是：

• 能力是否可被模型理解
• 能力是否可被模型内化
• 能力调度是否能成为模型能力的一部分

Skills 正是在这个目标下诞生的。

---

二、Skills 是什么？以及它刻意不是什么

1. Skills 不是 Prompt

Prompt 的本质是：

• 一次性
• 会话级
• 强依赖人工调优
• 不具备长期语义稳定性

Anthropic 在文中非常明确地传达了一个判断：

如果你在反复复制一个 prompt，它就已经失效了。

Skills 则恰恰相反：

• 目标是长期复用
• 语义稳定
• 可被多次、跨会话调用
• 并且不需要用户显式触发

这意味着：
Skill 的第一使用者不是人，而是模型。

---

2. Skills 也不是 Agent

一个非常容易混淆的点是：
Skills 看起来“会在合适的时候被用”，是否等价于 agent？

答案是否定的。

• Agent 是执行主体
• Skill 是能力模块

Anthropic 非常克制地把两者拆开：

• Subagent：负责“谁来做”
• Skill：负责“怎么做”

这在工程上是一个极其重要的判断，因为它避免了一个常见陷阱：

把“专业能力”塞进 agent 人设里，导致能力不可复用、不可组合、不可评测。

---

三、Skills 的三个关键设计（也是最“黑盒”的地方）

Anthropic 的 Skills 设计中，有三个决定性特征，也是争议最大的地方。

1. Implicit Invocation（隐式触发）

Skill 不通过显式调用触发：

// 不存在 if task == X then use Skill_A

而是：

Claude 会根据任务语义，判断是否需要某个 Skill。

这是一个刻意放弃工程控制权的设计。

---

2. Progressive Disclosure（渐进加载）

Skill 的内容并不会一次性注入上下文：

• 先加载 metadata
• 判断相关性
• 再加载详细指令与资源

从工程角度看，这是黑盒；
但从模型角度看，这是context budgeting 的学习问题。

Anthropic 的隐含假设是：

模型不仅要学会“用什么能力”，还要学会“用到什么程度”。

---

3. 能力调度不暴露给开发者

你无法：

• 插桩 Skill 的选择逻辑
• 强制指定 Skill 优先级
• 回放一次失败的 Skill 触发路径

这在强流程系统里几乎是不可接受的。
但这正是 Anthropic 的立场：

能力调度应该是模型能力的一部分，而不是工程规则的一部分。

---

四、为什么这种设计“反工程直觉”，却对 Anthropic 成立？

这是理解 Skills 成败的关键。

1. 因为 Anthropic 同时控制“模型”和“接口”

对于大多数框架或应用开发者来说：

• 黑盒一旦出现，就永远是黑盒

但对 Anthropic 而言：

• Skill 的触发、效果、失败，本身就是训练信号

换句话说：

Skill 的黑盒不是终态，而是训练闭环的一部分。

这是 LangChain 等框架无法复制的优势。

---

2. Skill 是为“模型学习”设计的，不是为“工程组合”设计的

LangChain 的抽象来自 Python 世界：

• function
• class
• pipeline
• DAG

Anthropic 的抽象来自 Transformer 世界：

• context
• attention
• relevance
• policy

Skill 的设计目标不是：

“让工程师更好写代码”

而是：

“让模型更好理解什么是一种能力”

---

3. 时机刚刚好：模型已经足够聪明

如果放在 2022 年，这套设计一定失败。

但在 2024–2026 年：

• 模型已经具备较强的任务分解与能力匹配能力
• 超长上下文使“渐进加载”有现实意义
• 用户对“少工程、多智能”的接受度显著提升

这使得：

把一部分控制权交给模型，不再是赌博，而是统计优势。

---

五、与 LangChain 的根本差异：黑盒的位置不同

这也是我们对话中反复确认的一个关键结论。

Anthropic 的黑盒在：

• 系统级
• 能力调度级
• 模型决定用什么、怎么用

LangChain 的黑盒在：

• 任务级
• 节点级
• 人类决定流程，但节点内部复杂

这不是“谁更黑”，而是：

控制权被放在了完全不同的位置。

---

六、Skills 是否可以被“工程化复刻”？

一个重要但必须冷静的判断是：

Skills 的设计思想可以学习，但它的运行方式不能照搬。

在强流程、强合规、强审计场景中：

• 隐式能力调度
• 不可回放的失败路径
• 无法插桩的决策

都是不可接受的。

但 Skills 提供了一个非常重要的启发：

能力应该是“一等公民”，而不是 prompt 的副产物

这意味着，即便在 LangChain / LangGraph 体系下，也可以：

• 把能力封装为标准化模块
• 明确定义输入 / 输出 schema
• 独立评测、版本化、回归测试
• 但由流程显式决定是否使用

换句话说：

借鉴 Skill 的“能力建模思想”，
保留 LangChain 的“流程白盒控制”。

---

七、一个更长远的判断

Anthropic 的 Skills，并不是为当前所有行业准备的。

它更像是在回答一个未来问题：

当模型足够强时，工程应该退到哪里？

LangChain 回答的是现在：

“在模型还不可靠时，人类必须写清流程。”

Anthropic 回答的是未来：

“当模型可靠到一定程度，流程本身可以被学习。”

这两者并不矛盾，而是处在不同时间尺度上的最优解。

---

结语

Skills 的真正价值，不在于它是否“好用”，
而在于它重新定义了什么才是可以 scale 的能力表达。

Prompt 是临时的，
Agent 是脆弱的，
只有能力模块，才值得被长期维护。

Anthropic 用一种极端、甚至反工程直觉的方式，把这件事推到了极致。

而工程系统真正成熟的标志，或许正是：
知道哪些地方可以交给模型，哪些地方必须由人控制。

这，才是 Skills 留下的最大启发。

---