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本身不绑定任何特定平台。下文讨论的是跨厂商开放规范层面的共性。

官方定义很清晰：

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

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

一句话：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构成的体系中运行。划清边界，才能看清它的位置。

容易混淆的概念：Agent决定“做不做、何时做”；Skill规定“怎么做才专业”。Tool是原子操作；Skill编码组合这些操作的领域规范。MCP负责连接外部系统；Skill规定Agent拿到这些能力后的专业使用方式。

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

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

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