Skill 是我重新学习 AI 时，特别想弄清楚的一个概念。
有人说要安装技能，有人说要调用技能。我最困惑的地方是：它看起来只是一份文字，为什么放进某个地方，就能让 AI 按它工作？
我们仍然使用旅行助手的例子。
假设这个助手已经能理解要求、查询酒店，并在遇到满房后继续寻找方案。现在，我还想让它采用一套比较稳定的做法。
比如，带老人和孩子的家庭旅行，要考虑体力，尽量少换酒店，每天留出休息时间。交付之前，还要检查交通距离、费用依据和未确认的信息。
如果每次都在对话里重新输入这些要求，会有不少重复。我们可以把常用的方法保存下来，在适合的任务里再次采用。
Skill 可以先理解为：供 Agent 使用的一套可复用工作说明，以及必要的配套材料。
按 Agent Skills 的格式，一项技能通常是一个文件夹，入口文件叫 SKILL.md。这个文件写明技能名称、用途和具体说明；文件夹还可以放参考资料、模板或脚本。脚本就是能交给相应运行环境执行的一段程序。Skill 的组成
.md 是 Markdown 文件常见的后缀。Markdown 是组织文字的一种格式，例如用编号列步骤，用标题区分内容。先把它当作容易阅读和编辑的文字文件就够了。
我们可以设想一份“家庭旅行规划”Skill，其中写着：
安排景点前，先考虑同行人的体力和活动偏好。
优先选择相邻景点，减少来回赶路。
给老人和孩子留出休息时间。
核对酒店日期、价格依据和预算。
交付前标出仍未确认的事项。
这是用来解释概念的教学示例，没有宣称实际安装了这项旅行技能。
现在问题来了：这些文字怎样发挥作用？
它和我们直接对 AI 说“请考虑老人和孩子的体力”，在基本原理上是相通的。模型能够处理这样的要求，并据此组织回答或选择行动。
Skill 把这类要求保存成可复用的材料。需要时，系统读取相关内容，把它提供给模型。
这里要认识一个词：上下文。
上下文，可以先理解为模型在当前这一步实际拿到的信息，包括你的要求、相关对话、已经读到的文件内容，以及工具返回的结果。
我喜欢把它想成工作桌上的材料。家里可能有很多书，但这次摊在桌面上、正在参考的，只是其中一部分。
同样，文件存在、系统可以访问、这一次实际读取了内容，是三个不同的状态。
把 Skill 文件放进一个文件夹，并不自动等于它已经进入本次工作。模型需要实际得到相关说明，才有依据采用其中的方法。
接下来，比较两份 Skill。
同一个旅行 Agent，使用同一个大模型和相同的查询工具。如果采用家庭旅行的方法，它会更重视体力和休息；如果采用摄影旅行的方法，它可能更重视拍摄地点、光线，以及日出日落的时间。
面对“早上五点出发”这个安排，两套方法会提供不同的考虑重点。
但用户的实际要求仍然要放在前面。明确说了不能早起，就不能为了执行摄影方法，擅自安排凌晨出发。
学习时，AI 问过我：
采用家庭旅行 Skill 后，助手开始安排每天中午休息。这是不是说明，大模型已经被训练成了一个更懂家庭旅行的新模型？
我的回答是：没有。模型参数没有因此改变。变化发生在运行过程中，系统读取了方法说明，把其中的要求作为本次工作的依据。
这一次，我比较清楚地解释出了其中的区别。
模型的参数，是训练形成、参与计算的大量数值。上下文，是它这一次处理任务拿到的信息。普通的 Skill 读取过程，改变的是后者。
这可以类比同一位旅行顾问拿到两份不同的工作要求。顾问原有的能力没有被重新培养一遍，但他会根据眼前的要求采用不同安排。
这个比喻只帮助理解。模型并不是一个藏在电脑里的人，具体的信息读取和执行仍由软件完成。
“安装”和“使用”也因此能分开了。
安装，通常是把技能说明和配套文件放进某个环境能够发现、读取的位置，或者通过产品的技能管理功能登记好。
使用，是这一次任务实际取得相关说明，并采用其中的方法。
有些环境会先提供技能的名称和用途，等任务需要时再读取完整说明，不必一开始把所有技能全文都交给模型。具体入口和加载方式，取决于你使用的产品。
所以，下载了文件、安装成功、本次读取了说明、实际按说明执行，这些状态要分别确认。
同样，安装在一台电脑里的技能，也不能据此推断另一个网页会话已经能够使用。方法可以复用，文件是否可访问、工具是否具备，仍要看那个环境。
如果换到一个没有取得这些说明的新会话，就不能指望它自动沿用所有要求。有些产品会通过保存记录或重新读取来接续工作，那也是具体的软件机制。
还有一个经常被误会的地方：Skill 可以写得很严格，也可以主要提供判断原则。
“每天中午安排休息”是一项明确要求。“考虑同行人的体力，安排必要休息”则给具体判断留了空间。
因此，Skill 不等于固定工作流。是否读取方法说明，和下一步行动由谁决定，是两个不同的问题。
Agent 也不是每项任务都必须使用专门的 Skill。它可以依据用户要求和模型已有能力开展工作。Skill 的价值，在于把值得重复采用的方法保留下来，让要求更清楚，后续也更容易检查。
不过，说明写得专业，不代表执行一定可靠。方法可能不适合当前任务，必要材料可能缺失，模型也可能遗漏其中的要求。
我现在更愿意把 Skill 看成能够积累、修改和检验的做事方法。以后读到高手的技能，我需要理解它为什么这样安排，也要看看它是否适合我的任务。
最后还有一个边界没有越过去：即使 Skill 写明“必须查询实时房态”，系统就一定查得到吗？
方法准备好了，还得有真正执行它的条件。下一篇，把这几个概念放进一个完整任务里看。