新范式：代码就是一切｜Anthropic 为什么从“专用 Agent”转向 Skills

目录

1. 执行摘要
2. “代码就是一切”在工程上是什么意思
3. 缺的不是智商，而是经验：为什么通用 Agent 还是难干活
4. Skills 的本体：把 SOP 做成可版本化文件资产
5. 渐进式披露：让技能规模增长但上下文成本可控
6. 脚本即工具：把确定性工作交给代码
7. Skill、MCP、Subagents 怎么分工
8. 团队落地：从 1 个 Skill 到 20 个 Skill
9. 参考资料

执行摘要

Anthropic 在 2026-01-22 发布了一篇很“硬”的文章：《Building Agents with Skills: Equipping agents for specialized work》。里面最打动我的，不是某个新功能，而是一句把路线说死的话：

The new paradigm: code is all you need。

它背后的意思大致是：

• 代码正在变成 Agent 做数字工作的统一接口。有了代码执行环境与文件系统，一个“通用 Agent”就能做很多过去需要定制 Agent 才能做的事。
• 但“能做”不等于“能稳定交付”。Agent 真正缺的不是推理能力，而是领域经验：流程、模板、检查清单、风险边界、验收口径。
• Skills 的核心价值，是把这些经验从对话里拿出来，沉淀为可版本化、可复用、可审计的文件资产，并通过渐进式披露把上下文成本做成可控账本。

如果你在做 Agent 产品或团队落地，这篇文章值得读的地方在于：它把“Agent 能力栈”分得更清楚，也把工程化的抓手说得更具体。

“代码就是一切”在工程上是什么意思

我们习惯把“代码”当成一种用例：编程、写脚本、修 bug。

Anthropic 的说法更激进：在 Agent 的世界里，代码更像“操作系统层”的接口。

想象一个现实任务，比如“生成一份财务报告”。传统路线很容易走成：

• 写一堆工具说明
• 给模型塞一堆上下文
• 祈祷它每次都按同样的方式组织输出

而“code is all you need”的路线，是把任务拆成更确定的执行面：

• 调 API 拉数据，落盘到文件系统
• 用脚本清洗与统计
• 用模板生成报告骨架
• 最后让模型做综合判断与叙事表达

结果是：脚手架收敛为 Bash + 文件系统 + 一组可复用脚本。Agent 不必被“按领域重造”，能力更多来自“会不会用代码把事做完”。

缺的不是智商，而是经验：为什么通用 Agent 还是难干活

文章里有个比喻很准确：报税这件事，你更愿意交给数学天才，还是交给一个做过上千次报税的会计？

多数人会选后者。原因很简单：会计的优势不在智商，而在经验。

今天的通用 Agent 也一样：它很聪明，但经常在真实工作里卡住，通常是三类问题：

1. 背景缺失：组织里的约定、历史决策、合规红线，模型默认不知道。
2. 复用困难：同类任务反复做，输出漂移，质量靠人盯。
3. 不会自我固化：这次踩过的坑，下次还会踩，因为“经验”没有被沉淀成资产。

Skills 要补的，就是这块“职业训练”。

Skills 的本体：把 SOP 做成可版本化文件资产

Anthropic 对 Skills 的定义非常工程化：Skills 是一组文件的组织方式，用来打包领域专业知识与程序化流程。

典型结构像这样：

my-skill/
├── SKILL.md          # 入口：流程、边界、验收
├── references/       # 资料：规范、模板、清单、示例（按需加载）
└── scripts/          # 工具：可执行脚本（按需运行）

这里最关键的不是“目录长什么样”，而是它带来的工程属性：

• 版本化：能用 Git 做 review，能回滚，能追责。
• 可共享：能放在仓库、共享盘、团队目录里。
• 可审计：流程与边界写在文件里，而不是散在对话里。

换句话说，Skills 更像把“教新人怎么做事”的材料，做成了一套可组合的资产包。

渐进式披露：让技能规模增长但上下文成本可控

目录结构只是表象，真正让 Skills 变成“平台能力”的，是渐进式披露（Progressive Disclosure）：按需加载，而不是一次性全塞进上下文。

Anthropic 把它做成三层账本：

1. 元信息（metadata）：只暴露 name/description，成本大概 ~50 tokens，用于匹配与发现。
2. 入口（SKILL.md）：命中后才加载，成本大概 ~500 tokens，写清流程、边界、验收。
3. 附录（references/）：需要细节再按需读，单文件可能 2000+ tokens，但不常驻。

一张图就够理解：

    flowchart TB
  U[用户请求] --> D[发现：只加载 name/description]
  D -->|命中| A[激活：加载 SKILL.md]
  A --> Q{需要更多细节？}
  Q -->|是| R[按需读取 references/]
  Q -->|是| S[按需运行 scripts/]
  R --> O[输出]
  S --> O[输出]
  

description 不是简介，更像路由规则

很多团队第一次写 Skill，最容易写废的地方是 description。

它更像一条路由规则，告诉模型两件事：

• 什么时候该用它
• 用了之后会产出什么

一个能用的写法通常很朴素：

• 用“真实触发词”写进去：团队成员会怎么说，就把关键词放进 description。
• 把产出说具体：报告、表格、代码改动、检查清单，别写成抽象能力。

脚本即工具：把确定性工作交给代码

文章里举了一个很现实的例子：他们反复看到 Claude 写同一段脚本，用来把演示文稿套上 Anthropic 的模板。

与其每次都让模型“现场重写”，不如把脚本保存下来，让 Agent 直接调用。

这件事的工程收益非常明确：

• 确定性更强：关键逻辑走可测试脚本，失败模式更可分类。
• 更容易演进：脚本能迭代，能 review，能补边界条件。
• 上下文更干净：脚本本体不必进入上下文，只把结果（stdout/生成文件）带回来。

如果你把模型定位为“编排者”，把脚本定位为“操作工”，很多看似玄学的稳定性问题，会变成工程问题。

Skill、MCP、Subagents 怎么分工

很多团队会把这些概念揉成一团，最后变成“一个超级 Prompt + 一堆工具”。这也是系统失控的常见起点。

我更建议按下面的分工理解：

• Skills：怎么做（流程、模板、检查点、验收方式）。
• MCP：连到哪里（外部工具与数据源的连接层）。
• Subagents：怎么分工（并行探索、审计、排障、隔离上下文）。

你可以把它们看成三种不同的“工程杠杆”：方法、连接、组织。

一张图：Loop / Runtime / MCP / Skills

Anthropic 在这篇文章里给出了一种更清晰的分层方式：推理负责决定，运行时负责执行，MCP 负责连接，Skills 负责经验与流程。

    flowchart TB
  subgraph L1[Agent Loop]
    P[Plan / Reason]
  end
  subgraph L2[Agent Runtime]
    X[Code + Filesystem]
  end
  subgraph L3[MCP Servers]
    T[External Tools + Data]
  end
  subgraph L4[Skills Library]
    K[SKILL.md + references/ + scripts/]
  end

  P --> X
  X <--> T
  P <--> K
  

一张表：别把“该放哪”放错

为什么他们要把 Agent Skills 做成开放标准

Anthropic 在文中提到推进 Skills 标准化。动机我理解主要是两点：

• 可移植：同一个 Skill，不应该被锁死在某个平台或某个工具栈里。
• 可共享：社区沉淀出来的好技能，能在不同团队之间迁移复用，让后来的 Agent 天生就更“职业”。

如果这件事跑通，影响会比“又多了一套配置格式”大：它会把经验从“人脑”搬到“文件资产”，再从“单团队资产”搬到“生态资产”。

团队落地：从 1 个 Skill 到 20 个 Skill

如果你准备在团队里用起来，我建议从“最小可用”开始：先做 1 个能反复用、能验收的 Skill，再扩张到 5 个、20 个。

第一步：选题只看两个信号

• 高频：每周都在做，或者每个项目都要做。
• 可验收：输出能被检查，不靠“感觉对”。

典型的试点题目包括：PR review、故障排障、状态周报、竞品分析、投标材料套版等。

第二步：入口文件只写三件事

SKILL.md 不要写成长文档站，入口建议只放：

1. 流程：按顺序做什么
2. 边界：缺什么先问、什么情况不要做
3. 验收：怎样算完成（尽量可验证）

细节、示例、口径表，拆进 references/，需要时再读。

第三步：把确定性部分脚本化

只要能脚本化，就别让模型“即兴发挥”：

• 结构校验（Markdown 结构、JSON schema、字段完整性）
• 批量抽取信息、生成固定表格
• 报告/PPT 的固定套版

模型更擅长的部分，是处理“不确定”：拆解、取舍、组织叙事、给出判断。

第四步：从第 20 个 Skill 开始做治理

技能少的时候，靠习惯就能维护；技能多了以后，治理是硬需求。

最小治理方式也很简单：

• 每个 Skill 标注 owner
• description 写清触发场景，避免重叠
• 固定节奏做盘点：合并重复、删掉不用、补齐验收

一个更工程的建议：给落地设“可量化验收”

你不需要一开始就上 KPI，但至少要能回答一个问题：Skill 是否真的让系统更可控？

可量化的信号通常包括：

• 一致性：同类任务输出的结构/格式/口径漂移是否明显下降
• 返工率：需要人肉补齐的项（字段缺失、格式不对、步骤漏掉）是否减少
• 首轮命中率：第一次产出就可交付/可审核的比例是否提升
• 执行确定性：脚本化步骤的失败是否可分类、可重试、可回归

参考资料

• Anthropic Blog（2026-01-22）：Building Agents with Skills: Equipping agents for specialized work
  https://claude.com/blog/building-agents-with-skills-equipping-agents-for-specialized-work