从提示词到工作方法：我理解的 Agent Skill

“Skill 不就是一大段 Prompt 吗？”

我觉得这句话抓住了一部分事实。很多 Skill 的核心确实是 Markdown 指令，Agent 读取之后，这些文字会成为上下文的一部分。如果一个 Skill 只有“你是一位资深专家，请认真分析”，把它理解为保存下来的提示词并不冤枉。

但用文件里有没有自然语言，来判断它有没有工程价值，我觉得还不够。我更关心的是：这份东西有没有把一次性的交代，变成下一次还能可靠使用的工作方法。

所以我想反驳的，是那个“就”字，而不是否认 Skill 和 Prompt 的关系。

先承认：Skill 没有让模型凭空学会新能力

把一段说明写进 SKILL.md，不会因此修改模型权重，也不会自动获得新的权限、工具或专业资格。

如果模型读不懂任务、环境里没有所需工具，或者资料本身有问题，Skill 仍然可能失败。它不是给能力不足的系统贴上一个名字，就能保证完成工作的机制。

Agent Skills 的开放格式，把 Skill 定义为一个以 SKILL.md 为入口的目录：入口包含元数据和任务指令，也可以带上脚本、参考资料和模板等资源。代码和这些额外资源都是可选的。Agent Skills 概览

这意味着两个容易误解的说法都需要收紧：Skill 并不一定只是单个文本文件，但一个纯文本 Skill 也不一定没有价值。

我理解的差别，在于经验怎样被组织

一次性 Prompt 往往围绕当前请求：帮我检查这个仓库，分析这场比赛，把这份材料整理好。很多背景、顺序和判断标准，需要使用者现场补充。

一个有用的 Skill 会把反复出现的部分保存下来：什么场景适用，先看哪些证据，如何处理常见缺失，交付什么结果，什么算完成。下一次换了输入，这套方法仍然能帮助 Agent 开始工作。

这并不是一条严格的形式边界。精心设计的 Prompt 一样可以写出完整流程；反过来，一个挂着 Skill 名字的文件也可能只有空泛要求。

我的判断是：Prompt 是表达指令的材料，Skill 是组织和交付一类任务经验的方式。两者可以重叠，价值需要看内容和使用效果。

用一个比赛分析的例子说清楚

假设需求是：“比较两支队伍最近的状态，给我一份比赛前瞻。”

很常见的提示词是：你是一位电竞分析师，请综合选手、地图池和近期表现，给出专业判断。它告诉模型要扮演什么角色，却没有交代判断的证据怎样取得。

如果把这类任务沉淀成 Skill，我更希望里面有这些具体方法：先确认比赛对象、赛制和日期；明确近期样本的时间范围；区分线上和线下比赛、不同赛事级别；记录阵容变化；比较地图池时展示样本量；证据不足时说明限制，不把少量比赛变成确定性结论。

最后的输出也可以有固定要求：事实、推断和未知分别写清，关键数据给出来源，预测说明依赖哪些假设。

这里没有神奇的新算法。价值来自过去容易漏掉的检查，被写成可以重复使用的流程。之前我在 OpenCLI 的 HLTV 贡献之外，也沉淀了 hltv-analyst。仓库把 CLI 的事实提取和 Skill 的分析流程分成两层：工具提供数据，方法帮助 Agent 解释数据。上面的例子说明了我对这类分析方法的设计期待。

按需加载，改变的是经验进入上下文的方式

如果把所有领域知识都拼进一份总提示词，哪怕每一段都不错，也会让无关内容占据上下文。

Skills 的设计提供了一种渐进加载方式：先通过名称和描述发现相关能力，任务需要时读取完整指令，再按需读取引用资源。具体触发和加载行为取决于宿主实现。Agent Skills 规范

这让我觉得，一个 Skill 的入口应该像一张清楚的索引：说明它能解决什么问题，以及什么时候值得读取。详细资料放在哪里、哪些步骤需要脚本、什么条件下查哪份参考，都应该有明确指引。

但“按需”不能只是一句口号。入口里已经塞了几万字，或者要求所有任务把所有附件读完，上下文成本仍然很大。整理目录不会自动带来效率，信息怎样拆分和被选择才会。

脚本和模板，让一部分经验变成稳定执行

有些步骤需要模型判断，有些步骤更适合程序。

例如，对一个报告生成任务，模型可以理解问题和组织解释；字段校验、单位换算、文件命名和固定格式检查，则可以交给已有脚本。模板帮助输出保持一致，参考资料帮助判断符合团队或领域约定。

Anthropic 关于 Agent Skills 的工程介绍，也讨论了把指令、资源和可执行代码放在一起的做法。工程文章

不过，脚本数量不是成熟度指标。有的工作只需要一份准确的审核清单，有的工作确实需要验证程序。我的原则是：把稳定、重复的计算交给代码，把需要理解和判断的部分留给模型，并让两者的输入输出衔接清楚。

真正拉开差距的，是能否检查和改进

我会用一个很朴素的方法评价 Skill：让它面对几类真实输入，看结果有没有更稳定。

正常输入能不能完成？缺少数据时是否会编造？输入有歧义时能不能识别？结果中有没有保留关键证据？工具失败之后是否还会假装成功？这些问题，比“这份 Prompt 看起来很专业”更容易验证。

如果一份 Skill 帮我避免了某类反复发生的错误，我会记录这个案例，把对应检查加入方法，再用相同案例复验。它因此可以像代码和文档一样做版本管理：知道改了什么，为什么改，以及有没有改善结果。

这不会使输出变成确定性的。模型、工具版本和数据源变化，都会影响表现。但可观察的案例和验收标准，至少让改进有了依据。

这也是我眼中“经验沉淀”的具体含义：失败不只留在聊天记录里，而是变成下一次执行时能用上的规则。

哪些时候，“只是 Prompt”这个批评成立

如果一份 Skill 的主要内容是角色设定、形容词和万能要求，没有适用范围、具体流程或验收依据，我会接受这个批评。

如果它把网上资料原样拼接成巨型文件，又没有帮助 Agent 找到当前需要的部分，它甚至可能增加负担。

如果它承诺某种效果，却没有案例能说明效果如何验证，那么“专家”“高级”“自动化”这些名字也没有太多意义。

同样，Skill 里的“必须执行”也不是权限来源。指令可以约定步骤，真正的访问能力和操作权限由宿主、工具与服务决定。让 Agent 读一份工作说明，不等于允许它对外发布、删除数据或付款。

我在关于 Harness 的随笔里写过，人需要给出目标、边界和验收。Skill 可以保存其中反复适用的部分，但仍然需要人判断它是否适合当前任务。

我会怎样回应那句话

我不会回答“Skill 完全不是 Prompt”。那样把一个有用的工程形式讲得太神秘。

我更愿意说：Skill 的指令部分确实是 Prompt；它是否值得使用，要看它有没有把方法、资源与验收组织起来，让下一次工作少依赖临场补充和重复试错。

如果它没有做到这些，叫它 Skill 也不会增加价值。如果它做到了，文件依然可以很简单，里面甚至没有一行代码，但保存下来的可能是相当有用的专业经验。

我关心的，是这份经验能不能被复用、被检查、被持续改进。文本长度和文件后缀，只是表面。

本文讨论的是 Agent Skills 这一类开放格式及其工程使用方式。相关格式资料于 2026 年 10 月 4 日核实，文中的评价标准和示例属于我的实践判断。另见关于 MCP 与 CLI 的笔记。