这段时间确实停更了几天。
原因很简单，家里新增了一位小成员，新手奶爸上路。
这几天的生活节奏，一直都是左手照顾宝妈，右手照顾宝宝。
中间还夹着一些工作上躲不开的沟通。
睡眠变得很碎，注意力也变得更贵。 很多想写的内容，我在备忘录里打了标题。 然后就没有然后了..
之后尽量恢复正常的节奏！
今天来跟大家聊聊 「Agent Skills」，
最近两周 AI 圈内讨论的非常热闹，
前段时间AIGC开发者大会上，就跟几位好友就着skills的话题在台上唠了很久，从“为什么火”聊到“怎么落地”。
今天就以这篇文章的形式跟大家见面，聊聊
什么是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商店，审核后大家就可以直接使用了~
结语
Skills，从技巧变成资产。
它让我们过去写在脑子里的经验，第一次有了像代码一样的封装方式。
可复用。可分享。可迭代。可交易。
它在生态里的位置，
像软件时代的插件与扩展包。
通用 Agent 是内核。Skill 是能力扩展。
生态繁荣与否，很大程度取决于扩展包的数量、质量、分发与评价体系。
又像组织里的 SOP 库。
以前 SOP 写在飞书、钉钉、企微文档里，靠人执行。
现在 SOP 写进 Skill 里，开始由 Agent 执行。
组织的知识开始“可运行”。
对行业的影响，我认为会体现在三点。
接下来，各家模型厂商都会开始发力支持「技能」模块，
毕竟，类似Coze、N8N这类Workflow Agentic平台对于大多数人而言，还是太难了，
而Skills这种纯靠自然语言的形式更符合大众习惯，垂直 Agent 的门槛下降，会带来一波“领域专家做 Agent”的浪潮。
“会写 Prompt 的人，一定会写Skills，门槛不高，大家放心。
Skill 市场、Agent 市场、企业内部 Skill 商店。
谁能把“发现好 Skill、评估好 Skill、组合好 Skill”做好，谁就抓住了下一波入口。
