系列：Agent Skills 技术深潜 #1

一、越来越长的 Prompt

2025 年底，我开始做一个每日 AI 新闻简报系统。第一版是一个 prompt，三四百字，让模型从多个信源中筛出当天值得关注的内容，按重要性排序，输出一份简报。

效果不错。但很快我发现，模型对"重要性"的排序不是我想要的：它把人事变动排在了技术突破前面。于是我加了一段优先级规则。

过了几天，又出现不同来源的同一条新闻重复展现的问题，有时还把两条不同的新闻合并成一条。于是我又加了去重和合并规则。

接着是信源可信度分级、数字标注要求、中英文格式差异……

三个月后，这个 prompt 膨胀到 3000 字。每次一动规则，其他地方就开始漂移。

我开始怀疑：是我提示词工程做得不够好，还是这种形态本身就有天花板？

二、当"一段话"成为天花板

现在回头看，答案是后者。天花板不在某条规则，在形态本身。

那 3000 字，大概和你写过的长 prompt 差不多：开头交代角色和任务；中间是操作顺序，夹着各种判断标准——什么消息算重要、哪些信源更可靠；再往后是格式要求、输出示例；结尾还有一串"不要……"，每一条都是某次翻车后补的。这些内容性质各异：有的是流程，有的是领域知识，有的是格式约定。但扁平文本把它们压成一段话，全量塞进上下文，一次性执行。这就带来三个问题。

越精确，越难遵循。规则要可执行，就得写全定义、示例、边界情况；写得越全，上下文越长。而公开评测显示，上下文拉长后，模型对中间位置信息的利用率明显下降；指令数量增多时，单条指令的遵循率也随之走低。我的简报系统掉进了这个循环：中间规则被"稀释"，模型读了，但执行不严；加规则修补，prompt 更长，遵循更差。

出错无从排查。整个流程一步到底，没有中间产物。简报里冒出一条本该被去重的新闻，你分不清是提取多了、去重漏了，还是生成时编造的，也不能只重跑出错的那一段——能做的只有改 prompt、整体重跑、肉眼比对。

复用就是复制重来。这 3000 字是为"每日 AI 简报"一点点长出来的，但真正值得复用的部分——信源分级、去重逻辑、格式规范——和任务细节缠在一起，拆不出来。想改出一个周报版，只能整段复制再改，改完又是一个同样臃肿的新版本，同样的问题重演一遍。

把三个问题往下挖，会发现根子只有两个。

流程控制缺失。所有步骤塞在一段话里，对模型来说只是建议——它可以跳过、混合、在长上下文中遗忘；而你没有机制在步骤之间插入检查点、持久化中间产物，或按错误类型回退到特定阶段。出错无从排查，正是它的直接后果。

领域知识无法独立维护。领域知识和执行指令混在同一段文本中，无法独立版本化、独立更新、独立复用。规则一变，你得在几千字里找到那几行改掉，同时担心牵动别处。精确与遵循的矛盾、复用之难，都从这里来。

Anthropic 工程博客用 procedural knowledge（流程知识）和 organizational context（组织上下文）概括了同样的观察。

这不是提示词写得不够好，是形态本身的设计边界。Anthropic 给出了自己的解法，就是 Agent Skills。

三、Skill 是什么

2025 年 10 月，Anthropic 发布了 Agent Skills。同年 12 月，它将 Skill 的文件规范作为开放标准发布。此后主流开发工具陆续跟进：OpenAI（Codex CLI）、微软（VS Code）、Google（Gemini CLI）、JetBrains（Junie）、AWS（Kiro）等数十个工具已支持或声明兼容这一规范，不过各家的接入深度、触发方式和目录约定并不完全一致。

Skill 因此不绑定任何特定平台——下文讨论的是这个跨厂商开放规范层面的共性。

先看官方对 Skill 的定义。

官方定义

Anthropic 把 Agent Skills 定义为：

Agent Skills are modular capabilities that extend Claude's functionality. Each Skill packages instructions, metadata, and optional resources (scripts, templates) that Claude uses automatically when relevant.

Agent Skills 是扩展 Claude 功能的模块化能力。每个 Skill 打包指令、元数据和可选资源（脚本、模板），Claude 会在相关场景下自动调用。

官方还有一个更直观的类比：

Skills exist as directories containing instructions, executable code, and reference materials, organized like an onboarding guide you'd create for a new team member.

Skill 以目录形式存在，包含指令、可执行代码和参考材料，组织方式就像你为新团队成员创建的入职指南。

——Anthropic 官方文档《Agent Skills Overview》

一句话：Skill 把某类专业流程、领域规则和可复用工作模式封装成一个可维护的能力包。

这跟 prompt 有什么本质区别？基于官方文档和我自己的项目实践梳理如下：

表格概括了结构差异。落到工程实践，四个变化最值得展开。

领域知识独立维护。最直观的例子是领域规则：在 prompt 里你写"按重要性排序"，模型每次都要重新推断什么是"重要性"——同一条 prompt 跑两次，排序结果可能不同。

在 Skill 里，优先级框架是一个 reference 文件，明确定义哪类事件排前面，与执行指令分开存放。规则变了，改一个文件，执行指令不受影响。同理，格式规范、领域术语表、信源分级标准——凡是独立于执行流程、有自己更新节奏的知识，都适合拆入 reference 文件。

确定性任务交给代码。在 prompt 里你让模型"计算两条新闻的内容相似度，超过阈值就标记为疑似重复"。这是确定性计算，不该靠概率模型。

在 Skill 里，这类工作拆到 scripts/，由 Python 代码确定执行。模型只负责语义判断：两条新闻相似度高，但一条讲模型发布、一条讲融资，应该分开。

质量保障从人工到脚本。Prompt 模式下，模型输出后你只能逐条人眼检查。Skill 模式下，可以在关键步骤之间插入验证脚本，检查中间产物和最终输出。

这不是小众玩法：Anthropic 官方 pdf skill 的 scripts/ 里，create_validation_image.py 这类检查脚本就用于表单填写流程中的质量检查。在我的简报系统里，分析记录生成后、简报输出前也各有一道验证：通不过就回退到对应步骤，不是带着错误继续往下走。

上下文按需加载。Prompt 模式下，所有指令全量塞入上下文窗口。Skill 采用 progressive disclosure（渐进式加载）：启动时只加载元数据（约 100 tokens/Skill），触发时才读入指令主体（建议 <5k tokens），参考文件按需读取。这是加载策略层面。执行层面还有一道隔离：脚本通过 bash 执行，代码本身不进入上下文窗口。这意味着你可以安装几十个 Skill，大部分内容留在文件系统里，只在真正需要时才被读取。三层加载的具体机制和文件结构，后续文章会展开。

以上四个变化指向一个更大的收益：可独立迭代。Skill 的构建是一个长期的过程，它需要持续迭代。但和 prompt 不同，迭代的单元是结构化文件：你可以独立更新领域规则而不动执行指令，单独升级验证脚本而不影响参考资料。迭代是靶向的，不是"改一段文本然后祈祷其他部分不受影响"。

Skill 不会孤立存在——它在一个由 Agent、Tool 和 MCP 构成的体系中运行。划清边界，才能看清它的位置。

容易混淆的概念

围绕 Skill 有三个常被混用的概念。核心区分各一句话：

Agent：运行时决策 vs 设计时知识。 Agent 是运行时的决策主体——理解意图、选择工具、动态调整路径；Skill 封装的是设计时固化的决策：领域专家的经验被写成流程与规则，在运行时按需加载进 Agent 的上下文。Agent 执行 Skill 中的指令，但保留跳过或变通的权力——Skill 是指导而非硬约束。

Tool：原子能力 vs 领域规范。 Tool 是原子动作接口——搜索、读写文件、调用 API，每次调用完成一个单一操作；Skill 规定的是如何组合这些原子能力：调用顺序、约束条件、质量标准和异常处理策略；其中确定性强的环节，还可以下沉为 Skill 自带的脚本来执行。Tool 提供能力，Skill 规定如何使用这些能力以达到专业水准。

MCP：连接层 vs 知识层。 MCP 是连接层协议，负责把外部系统能力以标准化 Tool 的形式暴露给 Agent。Skill 不负责连接外部系统，也不直接调用 Tool——调用的主体始终是 Agent。Skill 规定的是 Agent 拿到这些能力之后怎么用：先查哪个源、何时去重、结果不达标时如何回退。

需要说明的是，这四者并非严格的架构堆栈——Skill 不是位于 Agent 和 Tool 之间的中间件，而是被 Agent 按需加载的知识资产。更准确的图景是三个面：MCP 和 Tool 构成能力面，Skill 构成知识面，Agent 构成决策面。

以新闻简报类系统为例：信源经 MCP 接入（连接），Tool 提供获取内容的原子动作（能力），Skill 编码筛选、去重、排序的规则与验证标准（知识），Agent 在运行时决定何时调用、是否变通（决策）。

四、该不该升级

Skill 把领域知识从执行指令中独立出来，把确定性任务交给脚本，用可选的验证机制守住质量底线。但这些收益有对应的成本——文件结构要设计，脚本要写和维护，reference 文件要持续更新。不是所有工作流都值得付出这些成本。

是否值得封装，可以从两个层面四个维度判断。

第一层：值不值得结构化。 这两个维度几乎对所有工作流都适用，优先看。

使用频率：这个流程每周跑几次？偶尔用一次的临时任务，prompt 复制粘贴就够了。每天或每周都在执行同类任务——生成行业简报、整理竞品动态、出合规报告——重复性本身就是结构化的理由。

出错代价：出错的后果是什么类型？格式不对、排序不准这类问题，自己用的话调一调就好。流向客户、投委会或合规部门的输出，错误的代价远不止返工——仅 2024 年，就有数十家 A 股上市公司因年报中数据前后不一致、正负号写反、错误版本上传这类低级错误收到交易所监管函或证监局警示函。后果越严重、且错误可以被规则检测，自动化验证的价值越大。

第二层：Skill 的架构优势能否发挥。 这两个维度视具体场景而定。

领域知识：工作流是否依赖专用领域规则或参考资料？优先级框架、信源可信度分级、合规检查清单、格式规范——这些知识和执行指令纠缠在同一段 prompt 里，每次更新都是整体手术。如果通用常识即可完成判断、规则很少改变，这一层不需要。

协作移交：流程只有你自己用，"只有作者能维护"就不是问题。团队成员需要复用、新人需要接手时文件结构的可读性与长文本相比优势开始凸显。

一个边界：这个框架针对的是有明确流程和可编码规则的重复性任务。探索性、创意性的工作——头脑风暴、开放式调研、概念验证——依赖发散思维和即兴判断，固化流程反而是约束，不在讨论范围内。结构化也不是越早越好：流程开始稳定、错误开始可分类、规则开始复用时，封装才有回报。

拿几个场景验证一下：

• • 法律合规审查：每月执行，有公司内部领域规则，结论进正式报告。使用频率、领域知识、协作移交三维命中，值得封装。
• • 竞品追踪与投研简报：每日执行，有私有评分模型，错误判断代价高。四维全中，强候选。
• • 安全事件响应：固定 runbook、公司特定阈值、审计合规严格。四维全中，属于强 Skill 化候选。

维度命中越多，封装的回报越高。如果你在上面认出了自己的工作流，从命中最多的那个开始。

五、案例复盘：从 3000 字 prompt 到 Skill

本文开头提到的那个 AI 新闻简报系统，最初是一个 prompt，三个月膨胀到 3000 字，后来我把它重构成了 Skill 版。一个文件夹，六步执行协议，三个脚本（一个预处理、两个验证），七个 reference 文件，一个迁移模板。

变化不是一步到位的：先拆出执行协议，明确每步的边界——Step 2 只做源内提取，不去重；Step 3 默认 separate，只有证据充分才 merge；再把确定性计算（相似度、实体提取）搬进预处理脚本；最后加上两道验证，分别在生成前检查分析记录、在生成后检查输出契约。

整个过程花了接近一周，大部分时间花在定义步骤边界和调试验证脚本上。收益不只在输出质量——稳定性和可追溯性的提升更明显：最终输出 → 分析记录 → 原始候选条目 → 源文件，每一层有据可查。代价是七个 reference 文件需要持续维护，但对每日执行的流程来说，这笔成本值得付。

这个项目给我的经验是：当工作流同时需要领域判断（优先级框架）、确定性计算（相似度计算）、质量校验（验证脚本）和多源输入（多个信源交叉验证）时，结构封装从"锦上添花"变成了可靠性的前提。

这套结构不是新闻简报专属——第四章的三个场景（法律合规、投研简报、安全事件响应）的工作流与它同构。这个简报系统只是本文用来观察这种结构的案例，不是唯一模板。

六、三个认识转变

复盘这次重构，输出质量和效率的提升只是表面。更持久的是三个思维方式的转变。

第一个：从"写指令"到"设计流程"。Prompt 模式下，思维是"告诉模型做什么"。Skill 模式下，思维变成"这个工作流分几步、每步的输入输出是什么、什么该由代码做、什么该由模型判断"。

在简报系统里，这意味着把"帮我从这些信源中整理一份简报"拆成六步协议——提取、去重、分析、排序、验证、生成——每步有明确的边界和交接物。

很像从口头交代任务到编写操作手册的转变：口头交代把所有要点一次说完就行，操作手册需要把流程步骤、领域规则、检查清单、参考资料分开放，各管各的。

第二个：从"看最终输出"到"中间产物更重要"。最终交付物——简报、报告——只是面向读者的呈现，执行过程中固化下来的中间产物（分析记录、候选清单）才承载着审计价值：输出错了，不再需要"改 prompt、重跑、肉眼判断"，而是沿着"最终输出 → 分析记录 → 原始候选 → 源文件"的路径定位到具体步骤。

拿第四章的投研简报场景说：进了投委会材料的一个错误数字，能不能在十分钟内回答出"它是在提取、去重还是生成阶段进来的"，很大程度上决定了这个流程能不能被信任。

第三个：从"个人手艺"到"工程资产"。前两个转变完成后，流程、中间产物、领域知识都变成了文件。文件可以版本管理、测试、审查、迁移到相邻场景、交给团队继续维护。

你可能是一个 prompt 高手，但你的经验很难复制给其他人。Skill 不能自动复制专家判断，但它把经验写进了文件结构——每份经验有名字、有位置、有边界，新人能看出哪些是执行指令、哪些是领域规则、哪些是验证脚本，以及哪些不能随意动。

这三个转变在个体场景下就已经效果显著；等到流程需要交给别人，红利才完全兑现——对方接手的不是你脑子里的手艺，而是一份可以直接上手维护的工程资产。

七、迈出第一小步

读到这里，如果你评估后认为自己的工作流值得封装，先别急着写脚本，也不必一步做出完整的能力包。从现在 ROI 最高的那个 prompt 开始，拆成两个文件：

• • SKILL.md：放 name 和 description（触发条件）、执行步骤、输入输出边界。
• • references/：放领域知识——需要时才查阅的规则、规范或参考资料。比如优先级定义、例外情况、格式要求。

它就变成了一个可被发现、可被触发的 Skill，而且执行指令和领域知识从第一天就分层存放。这一步成本很低，但你的流程已经从"一段复制粘贴的文本"变成了"有入口、有边界、规则可独立更新的结构"。后续再决定要不要加 scripts/、模板和其他资源文件。

如果你用 Claude Code，把这个文件夹放进 .claude/skills/ 即可；用其他支持 SKILL.md 的工具，目录位置和触发方式以对应工具的文档为准——本文讨论的是开放文件规范的共性，不是某一个平台的运行机制。

当你准备好进一步拆分领域规则和验证逻辑，下一篇会展开 Skill 的文件结构与每个文件的角色。

八、下一篇预告

Skill 到底由哪些文件组成？SKILL.md、scripts/、references/、assets/ 各自承担什么角色？下一篇打开这个结构，逐类讲清楚放什么、放哪里、为什么这样分。

——#2《Skill 的解剖学：包结构与文件角色》

本文简报系统案例来自作者自有项目实践，判断仅供参考。

参考资料

• • Anthropic 工程博客 — Equipping agents for the real world with Agent Skills：https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
• • Anthropic 开发者文档 — Agent Skills Overview：https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
• • Anthropic 官方 skills 仓库 — pdf skill：https://github.com/anthropics/skills/tree/main/skills/pdf

系列目录《Agent Skills 技术深潜》

1. 1. 从 Prompt 到 Skill：专业工作流的结构升级（本篇）
2. 2. Skill 的解剖学：包结构与文件角色
3. 3. 一个 Skill 是怎么跑起来的：发现、激活、执行与上下文管理