今天就以这篇文章的形式跟大家见面，聊聊
-
什么是Agent Skills？跟Prompt、Context之间的区别是什么？ -
为什么会火？解决了什么问题？ -
如何写好一个Skills？有哪些坑需要避免 -
实际案例Case以及国内应用
好了，接下来进入正文。1、从 Prompt 到 Context，再到 Skills大家其实会明显感觉到，圈子里的关键词换得越来越快。前几年大家讲 Prompt。后来大家讲 Context Engineering。再后来，MCP、Tool Use、Workflow、Agent Framework 一起上桌。到了最近，Skills 变成了高频词。
我观察到一个很有意思的变化：大家讨论 Skills 时，表面在聊“怎么写一个 Skill”，底层其实在聊“怎么把经验变成可复用的能力”。Prompt 时代，你在写一段话，让模型配合你。Context 时代，你在经营一个信息场，让模型更像你想要的那样工作。Skills 时代，我们在打包一个能力包，让通用 Agent 在特定任务上稳定发挥。好朋友一泽在Agent Skills 终极指南：入门、精通、预测上也提到了把 Skills 视作“通用 Agent 的扩展包”，并强调它的核心价值在于“人给指引，Agent 看着执行”，从而让垂直 Agent 的成本大幅降低。我认同这个方向。并且我觉得，这个方向才刚开始。一句话讲清三个词：Prompt、Context、Skills为了避免概念越聊越玄，我们先用三句话定住基本盘。
-
Prompt：你对 AI 说的话，是一次任务的显式指令。 -
Context：为了让 AI 更好完成任务，你提供的所有相关信息集合，包含系统设定、历史对话、工具说明、参考资料、约束条件、环境反馈等等。 -
Skills：把某个任务的 SOP、工具使用方式、模板材料、注意事项封装成一个“能力包”，需要时按需加载，让 Agent 稳定复用。
就这么简单。别把它神秘化。
“其实，私以为不管是
Context或是Skills，都是Prompt一部分，对于模型来说都是Token，只不是过我们之前提起prompt往往认为只有User Prompt而已，为的都是解决模型有限上下文窗口的实践。
关于Agent Skills的来龙去脉可以看一泽这篇，这里不再赘述。2、为什么 Skills 会突然爆火？通用 Agent 过去有两个“老毛病”。第一，上下文容易越堆越长。你写一个超级提示词，塞进去一堆背景、步骤、格式、示例。短期看很爽，长期看很痛。一来占 token，二来容易让模型变笨，三来难维护。第二，经验难以复用与共享。你在某个项目里写了很强的提示词。换一个同事，换一个项目，换一个对话窗口，基本要重来。团队层面就更难，大家各写各的“轮子”，很难形成标准作业。
Skills 的价值点，恰好对着这两个痛点打。它把“常驻的少量信息”和“需要时才加载的大段指令”拆开了。把“提示词”从一次性的对话文本，变成一个可版本化、可共享、可迭代的能力包。这里涉及到最主要的一个机制就是：「渐进式披露」，Agent 按需分阶段加载信息，而不是预先消耗上下文。翻译成大白话就是：平时只挂“目录”。需要时再翻“正文”。更深的资料，临时去取。我们来看一个标准的Skills的结构：pdf/
├── SKILL.md # 主要说明（触发时加载）
├── FORMS.md # 表单填充指南（根据需要加载）
├── references/ # API 参考（根据需要加载）
├──reference1.md
├── assets/ # 资产（根据需要加载）
├── examples.md # 使用示例（根据需要加载）
└── scripts/
├── analyze_form.py # 实用脚本（执行，不加载）
├── fill_form.py # 表单填充脚本
└── validate.py # 验证脚本
Skills 的结构：三层信息分级与按需加载我们把它讲得更工程一点，核心文件其实就是SKILL.md这个文件。Level 1：元数据（name + description）它很短，常驻。它决定“什么时候触发”。---
name: pdf-processing
description: 从 PDF 文件中提取文本和表格、填充表单、合并文档。在处理 PDF 文件或用户提及 PDF、表单或文档提取时使用。
---
这个 description 写不好，Skill 就会误触发、漏触发、乱触发。Level 2：指令正文（SKILL.md 的主体）它决定“触发后怎么做”。它应该像一份岗位 SOP，包含流程、步骤、输出格式、边界条件、最佳实践或者质量标准。# PDF 处理
## 快速入门
使用 pdfplumber 从 PDF 中提取文本：
``python
import pdfplumber
with pdfplumber.open("document.pdf") as pdf:
text = pdf.pages[0].extract_text()
``
有关高级表单填充，请参阅 [FORMS.md](FORMS.md)。
Level 3：资源（scripts / references / assets 等）它决定“怎么把事做稳”。脚本提升确定性。模板提升一致性。参考资料提升事实性。pdf-skill/
├── SKILL.md (主要指令)
├── FORMS.md (表单填充指南)
├── REFERENCE.md (详细 API 参考)
└── scripts/
└── fill_form.py (实用脚本)
这套结构，本质上是一种“上下文预算管理”。也可以理解成一种“把经验产品化”的方式。
这就是把复杂任务拆小、把可执行部分固化、把知识材料外置。
当然，最主要的是 Skills 在代码执行环境中运行，具有文件系统访问、bash 命令和代码执行功能。
把“容易出错的重复动作”固化成确定性动作，让 Agent 少一点临场发挥，多一点稳定交付。这就是能执行代码、命令的好处，这里暂且按下不提，等之后的文章再给大家分享~3、如何写好一个Skills？很多人写 Skill，会陷入一个误区：把它当成“更长的 Prompt”。我更推荐你把 Skill 当成一个小产品。用户输入是多变的。边界情况是必然的。交付要可验收。所以 SKILL.md 的写法，尽量贴近一个场景的“SOP”。
我自己的写法，视任务难易程度，通常会包含以下模块：
-
Overview：这个 Skill 解决什么问题，适用什么场景 -
Inputs：用户需要提供什么信息，允许哪些格式 -
Workflow：分步流程，尽量清晰可操作 -
Output Spec：输出结构、字段、格式、质量标准 -
Guardrails：禁止事项、风险提示、合规边界 -
Examples：触发示例与输出示例 -
Resources：什么时候读参考资料，什么时候跑脚本
你会发现，它跟你做 B 端方案写 PRD、写 SOP 很像。原因也很简单：Skill 其实就是把“经验流程化”。从0到1的部分，还可以直接由官方的skill-creator这个专门生成skill的skill来写。最佳实践可以参考Claude官网https://platform.claude.com/docs/zh-CN/agents-and-tools/agent-skills/best-practices写skill注意事项与常见坑我把坑总结成五类，你写 Skill 时逐个对照。
第一类：触发描述写得太虚description 写成“万能助手”，基本等于没写。写成“任何情况都可用”，就会冲突、误触发。第二类：指令过长，像百科全书Skill 的正文一旦过长，模型会疲劳。你自己也难维护。指南里建议 SKILL.md 正文尽量控制在 500行以下，大概 6000 tokens 左右，并把复杂内容拆成子文档按需加载。这是很实用的工程建议。第三类：步骤没有可验收标准你告诉模型“写得更好一点”，它会装作懂。你告诉模型“输出必须包含 A/B/C 三部分，每部分不超过 X 字，并给出 3 条可执行行动”，它才会收敛。第四类：缺少“边界条件”真实世界的问题永远不完整。用户输入经常缺字段。你需要在 Skill 里明确：缺信息时怎么追问，追问几个，追问顺序是什么。 否则它会一上来就输出一堆假设。第五类：脚本与指令脱节你在 scripts 里放了脚本。正文里却没告诉 Agent 什么时候调用。或者是名字跟脚本名匹配不上，导致后续步骤无法稳定衔接。4、实战案例：把“AI 私董会专家”封装成一个 Skill相信大家还记得我之前私董会的那篇文章把AI变成你的“最强军师团”！AI私董会实测，人人都能享受顶级咨询（附Prompt）过去那套私董会提示词，本身就具备 Skill 的雏形：它有角色设定，有流程，有模板，有输出格式，还有一问一答的交互规则。差的只是工程化包装与可复用结构。目标很明确：让通用 Agent 一旦遇到“复杂决策咨询”类问题，就能自动启用私董会流程。同时具备可定制幕僚阵容、可生成报告、可稳定推进节奏的能力。在这里，我把过去的私董会整体流程和可视化报告结合做了一个skill，先来看看效果：
Skill 结构设计：把提示词拆成三层（1）Level 1 元数据：只放名称与触发说明
name要使用指示内容的名称，动名词形式最好。其实 description 的触发场景也没必要写的这么细。这里方便大家理解（2）Level 2 指令正文：放完整流程与模板也就是我们要完成这个“确认问题 → 三轮提问 → 反馈建议 → 总结”场景的 SOP。
（3）Level 3 资源：把固定模板外置比如把默认幕僚档案、反馈模板、反思模板、报告模板拆到 references/。
这样正文更短，模板可独立迭代。
在这个基础上，还可以加上
-
quality-checklist.md（输出自检清单） -
red-flags.md（高风险场景提示，比如用户涉及医疗、法律、投资建议时如何提示边界）
如果能创建「评估模式」会更好，这样私董会 Skill 会更“稳”。案例演示：一次从触发到交付的完整流程我用一个典型案主场景演示一遍。
第一步，Agent 匹配元数据 看到“私董会”“纠结”“辞职”“项目验证”，命中 description，触发 peers-advisory-group。第二步，加载 SKILL.md 正文 进入固定开场，确认问题边界，然后我们可以补充背景信息，继续对话。
之后，按照整个流程走下来，每一轮幕僚都会提问两个问题，问题非常的犀利..关键在节奏：问完必须等用户回答。这是保证“案主参与感”和“信息完整度”的核心机制。
第四步，第二轮提问（黑帽子）在你的模板里，这一轮问“最坏情况”“盲点”“是不是自己的问题”。这轮非常值钱。它负责把案主从自我叙事里拽出来。
然后是，案主反问环节，Skill 里已经强调“不是求建议，而是补充信息”，这个定位很好。
第七步，幕僚反馈建议按模板输出：名言金句、感受、问题定性、经历分享、具体建议。
然后你说出你的收获和总结，最终可以选择出具报告。基于我们已经有的「杂志风格报告」输出模块。
打开就会得到一份完整的报告，如开头所示。
从这个简单的案例，希望大家能了解到Skill的用法，第一，Skill 最强的地方不在“文采”，在“流程控制”。一问一答、等待用户、分轮推进，这类规则要写死。第二，Skill 的价值在复用。不同案主、不同主题上重复跑同一套流程。第三，Skill 要能处理真实世界的不确定输入。 这就是为什么要写“信息缺口处理”“追问策略”“输出自检”。第四，Skill 适合和其他 Skill 联动你可以把“私董会 Skill”与“会议纪要 Skill”“报告排版 Skill”“PPTX Skill”等等联动。前者负责洞察与决策。后者负责交付与传播。官网也提到多 Skills 联用能带来不错的效果。关于脚本、代码执行后续再给大家分享~国内如何使用Skills？我们知道Anthropic在25年底把Agent Skills发布成了开放标准，Claude Code、Codex、OpenCode等等平台都支持并接入了。国内其实也有很多厂商陆续支持skills功能，比如字节的Trae就率先宣布接入「技能」模块。
还有字节的「扣子」平台，完成了2.0的新版本迭代，同样支持「技能」模块，主打职场办公。
并且可以在扣子中直接通过跟AI聊天创建skills，也支持直接上传现有的skill文件。
我把做好的「私董会专家」skill也上传到了Coze商店，审核后大家就可以直接使用了~
https://www.coze.cn/s/VOPGa_XQ37k/
结语Skills，从技巧变成资产。它让我们过去写在脑子里的经验，第一次有了像代码一样的封装方式。可复用。可分享。可迭代。可交易。它在生态里的位置，像软件时代的插件与扩展包。通用 Agent 是内核。Skill 是能力扩展。生态繁荣与否，很大程度取决于扩展包的数量、质量、分发与评价体系。又像组织里的 SOP 库。以前 SOP 写在飞书、钉钉、企微文档里，靠人执行。现在 SOP 写进 Skill 里，开始由 Agent 执行。组织的知识开始“可运行”。对行业的影响，我认为会体现在三点。接下来，各家模型厂商都会开始发力支持「技能」模块，毕竟，类似Coze、N8N这类Workflow Agentic平台对于大多数人而言，还是太难了，而Skills这种纯靠自然语言的形式更符合大众习惯，垂直 Agent 的门槛下降，会带来一波“领域专家做 Agent”的浪潮。
“会写 Prompt 的人，一定会写Skills，门槛不高，大家放心。
Skill 市场、Agent 市场、企业内部 Skill 商店。谁能把“发现好 Skill、评估好 Skill、组合好 Skill”做好，谁就抓住了下一波入口。今天先写这么多，给大家汇报下这段时间消失的原因…接下来我会继续围绕三个方向更新：一个是 AI圈观察、产品观点、思考。一个是 Agent Skills 的写法与工程实践，偏可直接抄走用。一个是结合真实业务场景的案例库，偏可落地复用。以上。
我是甲木，热衷于分享一些AI干活内容，同时也会分享AI在各行业的落地应用，我们下期再见👋🏻
© 版权声明
文章版权归作者所有，未经允许请勿转载。
