Agent Skills 彻底改变了 AI 应用的构建范式

那是 2025 年底，我刚从一个为期三周的客户现场回到办公室。这期间我们团队被同一个问题反复折磨：明明用大模型写出了一个能跑通的客服 Agent，但每次交给业务方，他们总能找出各种“意外”——同样的投诉分类，周三还是 90% 准确率，周五就掉到 60%。我们把 Prompt 改了又改，最后 Prompt 文档膨胀到 6 页，团队成员甚至不敢再动它。

就在那个时间点，Anthropic 发布了 Agent Skills。接着，2026 年初，agentskills.io 上线了开放的技能规范，OpenAI Codex CLI 和更多工具链开始支持同一套格式。这不是一个渐进式升级，而是一次彻底的范式转换。

经验框
如果你还在把 Agent 当作“一个超级 Prompt + 几个工具函数”，那么你正在踩我们一年前踩过的坑。Skills 解决的不是模型性能问题，而是工程可靠性问题——它把“有时灵光一现，有时莫名翻车”的模型行为，转变成可测试、可版本化、可复用的软件组件。

三种构建范式的核心差异

要理解 Skills 为什么是一次范式革命，必须先看清楚它和前两种方式的根本区别。下面的表格给出了关键维度的对比。

这张表揭示了一个深刻的现实：Prompt Engineering 让 Agent 变得“更聪明”，但它并没有让 Agent 变得更像一个合格的软件模块。 一个被反复修补的 Promp t 文件，本质上是一个无法进行单元测试的黑箱。而 Skills 的做法是——把能力从“提示词技巧”升级为“软件工程学技法”。

核心洞察：被动响应 → 主动装配 → 独立执行

为了让这个范式跃迁变得直观，我把它拆成三个递进的层次，用你熟悉的日常场景作为类比。

第一层：被动响应 —— 螺丝刀和扳手

在“直接调用模型 API”时代，你把事情交给 AI 的唯一方式是：写下一段完整的需求描述，塞进消息窗口，然后期待模型给你一个合理的输出。这就像你拿起螺丝刀拧一颗螺丝，拿起扳手拧一颗螺母——每次操作都是一次独立的、手动的、无记忆的动作。模型扮演的是工具执行者，所有上下文都靠你自己管理。

第二层：主动装配 —— 标准件库

进入“Prompt Engineering + Tools”阶段，你开始把一系列工具函数和一段系统 Prompt 打包，期望模型自己能判断什么时候用哪个工具。这就像你把螺丝刀、扳手、卷尺放进一个工具箱，然后告诉工人：“这里有工具，你自己看着办。”工人（模型）大多数时候能用对，但偶尔会犯傻——用螺丝刀去撬油漆桶。原因是：模型只会“装配”工具，却不懂“工作流程”。

第三层：独立执行 —— 专家外脑

Agent Skills 做的事情完全不同。一个 Skill 包里封装的不只是工具，还有工作流程本身——执行步骤、判断标准、异常处理策略。这就像你不再给工人一堆工具，而是给他一个 SOP 文件夹：“客户投诉分三步处理，先看订单号，再查物流状态，物流超时走赔偿流程，其他情况转人工。”工人不再需要自己“猜”该怎么做，他只需要逐步执行经过验证的标准流程。这时，模型才从一个拿着工具的学徒，变成了持证上岗的专家。

而这套 SOP 的语言，不是晦涩的 Python 代码，而是任何人都能读写的 Markdown——配合可选的脚本以处理确定性逻辑。这意味着领域专家的隐性知识第一次可以被直接编码，而无需工程师转译。

从模型调用到能力封装：三要素的脱胎换骨

过去我们拆解一个 Agent 时，核心三要素是：工具（Tool）、记忆（Memory）、规划（Plan）。但那时候，这三样东西几乎全都绑定在模型调用的上下文窗口里。模型一旦忘掉前面的指令，整个 Agent 就退化到初始状态。

Agent Skills 重构了这三个要素的归属关系：

• 工具（Tool）不再是“暴露给模型的 API”，而是封装在 Skill 内部的可执行脚本。模型不需要知道脚本内部如何实现，它只知道“我可以调用这个能力”。一个发票识别 Skill 内部可能调用了 OCR 工具、调用了数据库查询、调用了格式校验，但对外只暴露一个明确的输入输出契约。

• 记忆（Memory）不再是“把所有历史消息塞进上下文”，而是 Skill Package 中预置的领域知识（Markdown 指令）和运行时产出的结构化状态。渐进式披露机制（Progressive Disclosure）让 Agent 只拉取当前步骤需要的信息，而不是一口气把所有 Skill 的完整文档都加载进来——这是 Anthropic 在 Skills 设计中解决上下文窗口污染的关键策略（源自 Claude 帮助中心的官方文档）。

• 规划（Plan）不再是“模型自己推理应该怎么做”，而是 Skill 内部的标准化工作流程。一个“会议纪要整理 Skill”会明确写明：第一步语音转文字，第二步提取议题和决议，第三步按模板生成纪要，第四步导出 Word 文档或同步飞书（来自博客园开发者实践的案例）。模型从一个需要“自己思考怎么做”的虚拟大脑，变成一个“知道该按什么流程执行”的执行引擎。

核心建议框
当你开始设计一个 Skill 时，第一件要做的事不是写 Prompt，而是画一张流程图。把专家处理这件事的真实步骤画出来——哪一步依赖外部数据，哪一步需要人工确认，哪一步是纯转换逻辑。这张图就是你的 SKILL.md 的骨架。Prompt 只是最后一步的润色。

下面这张关系图展示了在 Skills 范式下，五大核心概念如何协同工作：

flowchart TD
    Agent["Agent（智能体）"] -->|"加载技能清单"| SkillRegistry["Skill Registry（技能注册表）"]
    SkillRegistry -->|"渐进式披露"| SkillA["Skill：客户投诉分类"]
    SkillRegistry -->|"渐进式披露"| SkillB["Skill：会议纪要整理"]
    SkillRegistry -->|"渐进式披露"| SkillC["Skill：发票识别"]

    SkillA -->|"包含"| InstructionA["指令（Markdown SOP）"]
    SkillA -->|"包含"| ScriptA["脚本（Python/JS）"]
    SkillA -->|"包含"| ResourceA["资源（模板/知识库）"]
    SkillA -->|"调用"| Tool["Tool/ MCP（外部工具/数据源）"]

    Agent -->|"维护"| Memory["Memory（会话状态）"]
    Memory -->|"传递上下文"| SkillA

    Agent -->|"执行"| Plan["Plan（任务流）"]
    Plan -->|"Step 1"| SkillA
    Plan -->|"Step 2"| SkillB

这张图需要这样读：Agent 是整个系统的执行主体，它不再直接面对一堆原始的 Tool 和 Prompt，而是面对一个注册了多个 Skill 的技能注册表。当任务需要调用某个 Skill 时，Agent 通过渐进式披露机制只加载该 Skill 的简介；当确认需要深入执行时，才拉取详细的指令和脚本。途中产生的中间状态存入 Memory，多个 Skill 通过 Plan 编排成完整的任务流。每一个 Skill 内部是一个自包含的“能力黑箱”，外部只看到清晰的输入输出。

Skills 在市场中的定位与价值

截至当前调研资料（2025-2026 年），Agent Skills 的市场生态已经呈现清晰的梯队分层。

Google 在其 Agent 教育路径中，把 Skills 定位为“让 Agent 实现自主行动和推理以解决复杂问题的技术工具箱”，强调 Agent 需要借助 Skills 才能从“被动回答”升级为“主动解决问题”。Anthropic 则更激进，直接把 Skills 作为其 Agent 生态的核心开放标准——不仅 Claude Code 原生支持，还建立了 getclaudeskills.com 这样的第三方市场，让开发者可以发布、发现、安装其他人构建的技能包。

而且，Notion、Figma、Atlassian 等合作伙伴已经发布了官方 Skills，这些 Skills 能够在各自的 MCP 连接器上无缝运行，让 Agent 直接操作文档、设计和项目管理。这是一个关键信号：平台方不再只提供 API，而是提供封装了工作流的 Skills——这意味着 AI 与 SaaS 的集成从“开发者手工串接”，变成了“一键安装能力开关”。

从开发成本的角度看，Skills 带来的节省体现在两个层面：

1. 复用成本归零：过去要迁移一个“数据分析 Agent”的内部流程，需要另一个团队的工程师重新阅读 Promp t、理解工具调用逻辑、重新调试。现在，只需把对应的 Skill 文件夹复制过去，Agent 自动识别并动态加载。

2. 迭代效率质的飞跃：一个 SKILL.md 文件，用 Markdown 写成，产品经理和领域专家可以直接修改工作流程步骤，无需等待工程排期。工程师只负责维护底层的脚本和工具接口——业务逻辑和工程实现的边界第一次被清晰地切割开。

谁该拥抱 Skills？谁该暂时观望？

说到底，如果你开始觉得 Prompt 变成了你不敢动的“祖传代码”，你就正式具备了迁移到 Skills 的全部理由。

下一章，我们将深入 Claude Skills 的架构设计哲学。如果说本章解决的是“为什么要封装 Skills”，那么下一章将回答“Skills 内部应该按什么原则组织”——这是决定你能否设计出真正可维护的技能体系的基石。