图解Skill读书笔记（二）：智能体组成与Skill触发机制

本文为原创学习笔记，记录本人阅读和实际操作后的理解。不同平台对智能体与 Skill 的实现方式可能不同，文中的界面和触发效果以本人使用的软件版本为准。

转载请注明作者及原文链接；未经许可，请勿用于商业转载。

学习目标

上一篇笔记通过“日总结”案例，对比了普通提示词与 Skill 的区别。这一篇继续学习三个问题：

1. 智能体由哪些部分组成；
2. 一个 Skill 通常包含哪些文件；
3. 智能体怎样判断何时调用某个 Skill。

为了便于理解，书中把智能体比作厨房，并用“做番茄炒蛋”说明各部分如何配合。这个比喻不是严格的技术定义，但很适合帮助初学者建立整体印象。

一、把智能体理解成一间厨房

普通 AI 聊天机器人收到“怎样做番茄炒蛋”的问题后，通常会整理出一份菜谱。具备工具调用能力的智能体则可以在权限允许的范围内继续执行任务，例如读取资料、运行程序或保存文件。

按照厨房的比喻，可以这样理解：

智能体组成	厨房中的角色	主要作用
大模型	厨师	理解需求、分析任务并决定下一步
上下文	操作台	放置当前对话、资料、工具结果和中间结论
工具	锅、刀、案板	执行搜索、读写文件、运行代码等具体操作
Skill	菜谱与操作规范	提供可重复使用的步骤、规则和配套资源
提示词	顾客的要求	说明这次需要完成什么任务
MCP	统一的连接方式	让支持该协议的客户端连接外部工具和数据源

实际平台不一定同时具备这些部分，也不一定使用相同名称。例如，有的平台把 Skill 称为技能、工具、插件或工作流。因此，这张表适合理解概念，不能代替具体平台的使用说明。

二、为什么复杂任务更需要Skill

简单任务使用普通提示词就能完成，但任务重复或步骤较多时，会出现几个问题：

• 每次都要重新输入相同规则；
• 提示词过长，占用更多上下文；
• 规则容易遗漏，输出结构不统一；
• 脚本、模板和说明分散，不方便维护；
• 多人使用时，很难保证大家采用同一套流程。

Skill 的作用，是把相对固定的任务规则整理成可重复使用的内容。执行新任务时，用户只需要提供本次数据，智能体再按 Skill 中的步骤处理。

可以简单概括为：

提示词：告诉智能体这一次要做什么
Skill：提供完成某类任务时可重复使用的规则和资源

不过，Skill 并不能消除输出波动，也不能保证 AI 不产生错误。它可以通过明确步骤、限制条件和校验方法降低出错概率，但最终效果仍受模型能力、上下文、工具状态和任务数据影响。

三、拆开一个Skill看看

只看概念时，我总觉得 Skill 有些抽象。打开一个 Skill 的目录后，事情就直观多了：里面最重要的是 SKILL.md，复杂一些的还会带着脚本、模板和示例文件。

我先打开 SKILL.md。文件开头通常有一小段 YAML Front Matter，很像 Skill 的名片：

---
name: daily-summary
description: 根据用户提供的当天事项生成日总结或工作日志
---

name 是名称，description 说明它会做什么、在什么情况下使用。后面研究触发机制时我才发现，description 不只是给人看的介绍，还可能影响智能体是否选择这个 Skill。至于还能填写哪些字段，要看具体平台的要求，不能想当然地添加。

名片下面是正文，也就是这项技能真正的操作说明。我创建日总结 Skill 时，把“先输出草稿，审核后再保存 Word”写在这里，同时说明内容结构和文件命名方式。这样再次使用时，就不用反复交代相同规则。

如果任务比较复杂，仅靠文字说明还不够，目录中还可以放配套文件。我把它整理成下面的样子：

daily-summary/
├── SKILL.md
├── templates/
│   └── 日总结模板.docx
├── scripts/
│   └── export_word.py
└── examples/
    └── 示例.md

看到这里，我对 Skill 的理解清楚了许多：SKILL.md 负责讲明白怎么做，模板负责统一样式，脚本负责完成保存文件等确定性操作，示例则展示希望得到的结果。

这些文件不能只放进目录就算完成，还要在 SKILL.md 中写清楚什么时候使用、怎样使用。否则文件再多，智能体也未必知道该选哪一个。这里采用的是支持 SKILL.md 的组织方式，其他平台的目录结构可能不同。

四、按需加载与上下文管理

上下文窗口可以理解为智能体当前能够处理的信息空间。对话、文件内容、工具返回结果和 Skill 说明都可能占用上下文。

一些 Skill 系统采用分层或按需加载方式：先读取名称和描述，确认任务可能需要某个 Skill 后，再加载详细说明和关联资源。这样可以避免一开始把所有内容都放入上下文。

书中建议 Skill 保持精简，并给出了篇幅和行数方面的经验值。这类数字适合作为写作提醒，但不是所有平台通用的硬性限制。更稳妥的原则是：

• 主说明只保留执行任务必需的规则；
• 很长的背景资料拆分成关联文件；
• 示例数量适当，避免重复；
• 复杂任务分阶段执行；
• 每个阶段保留明确的中间结论；
• 定期删除已经无用的上下文。

部分智能体提供上下文压缩功能，但压缩是对历史信息进行摘要，可能丢失细节。任务中存在精确参数、路径、密码策略或审核结论时，不能只依赖自动压缩，最好把关键内容单独记录下来。

开启新对话也不是必须执行的固定动作。如果当前上下文清楚且仍与任务相关，可以继续使用；当历史内容过多、不同任务互相干扰，或者模型开始混淆要求时，新建对话会更合适。

五、description怎样影响Skill触发

很多人会好奇：智能体怎样知道什么时候使用某个 Skill？

在支持自动发现 Skill 的系统中，名称和 description 往往会参与匹配。智能体根据用户请求、Skill 描述和当前上下文，判断是否需要加载某个 Skill。

这不是普通程序中完全固定的 if 判断。模型匹配可能出现两类问题：

• 误触发：描述范围太宽，与当前任务并不真正相关；
• 漏触发：描述不清楚，或者用户表达方式没有被正确匹配。

编写 description 时，可以参考下面的结构：

description = 功能定义 + 适用场景 + 典型表达

以日总结 Skill 为例：

description: 根据当天完成事项、问题和后续计划生成日总结；
  适用于“写日报”“写日总结”“整理工作日志”等请求。

如果只写“写报告”，范围太宽，周报、月报、项目报告都可能触发；如果只写某一天的固定句子，范围又太窄，换一种说法就可能无法匹配。

描述应简洁、明确，并尽量围绕任务本身，少用“你、我、他”等指向不清的人称代词。

六、用日报与周报测试触发冲突

为了观察多个 Skill 的触发情况，我分别创建了日报 Skill 和周报 Skill，并在两个描述中都加入了“工作总结”。

当我输入：

帮我写一个工作总结。

软件弹出了选择窗口，让我选择日总结还是周总结。这说明当前表达同时符合两个 Skill 的描述，系统无法直接确定应使用哪一个。

后来，我收紧了周报 Skill 的适用范围，明确说明只有请求中出现“周报”“周计划”或“周总结”等含义时才使用。再次输入“帮我写一个工作总结”后，软件没有再弹出相同的选择窗口。

这个实验说明，多个 Skill 的职责有重叠时，仅增加触发词不一定能解决问题，还要写清各自的适用边界。可以采用下面的方法：

1. 缩小每个 Skill 的职责范围；
2. 使用能够区分任务的典型表达；
3. 明确不适用的场景；
4. 对含糊请求先向用户确认；
5. 用多种说法反复测试误触发和漏触发。

我把“明确不适用场景”理解为反向限制。例如：

description: 生成周报、周总结或下周计划；
  仅用于按周汇总，不用于日报、日总结和单日工作日志。

这类描述能否被严格执行，仍取决于具体平台的实现，因此不能只写完就认为万无一失，还需要实际测试。

七、本篇小结

通过厨房的比喻，我对智能体各部分的分工有了更直观的认识：大模型负责理解和判断，工具负责执行具体操作，上下文承载当前信息，Skill 则整理可重复使用的流程与规则。

Skill 的核心价值不是把提示词写得更长，而是让规则能够按需使用、便于维护和反复测试。description 是 Skill 被发现和选择的重要信息之一，编写时既要说明能做什么，也要划清不该在什么情况下使用。

当多个 Skill 出现触发冲突时，应通过缩小职责、明确边界和补充测试逐步调整，而不是单纯堆积触发词。这也是我从日报与周报实验中得到的主要收获。