Appearance
Q115 · AI Agent 的 Skills 机制是什么？有什么作用？
公司做了一个通用客服 Agent。有人让它翻译邮件，有人让它画售后趋势图，还有人让它“审核订单 O-314 的售后工单”。如果把这三套操作细则全塞进每一次模型输入，材料会越来越长，而且翻译任务也会读到用不上的售后规则。遇到审核任务时只临时告诉模型“认真审核”，又可能漏掉“核订单归属、查当前政策、给建议但不自动退款”等关键步骤。
**Skill（技能）**就是把某类可重复完成的任务，整理成一份可被 Agent 发现、按需读取的工作说明，并附上需要的参考资料、模板或脚本。它教 Agent 何时使用、按什么顺序做、如何判断完成。Skill 可以指导 Agent 使用工具，却不会因为文件里写了“退款”就自动拥有退款权限。图中的客服先匹配“售后审核”技能，再打开完整步骤，最后才用已有的订单与政策工具去执行。
术语和示例里的对象
| 词或符号 | 用普通话解释 |
|---|---|
| Agent | 组织模型判断、工具调用、结果检查的应用；不是单独一份提示词。 |
| Skill / 技能 | 可复用的任务说明与配套文件组成的包。本文的虚构技能叫“售后审核”。 |
SKILL.md | 常见 Skill 包里的主说明文件，写名称、用途以及执行步骤；不同平台可有不同打包和加载方式。 |
元数据 / name / description | 技能的短名称和用途描述。Agent 先看到简短信息，再判断是否需要打开详细内容。 |
| 按需加载 | 不把所有技能全文一开始就塞进上下文，而是任务相关时才读取对应文件。 |
| 工具 | 真正执行外部读写的接口，如“查订单”“查售后政策”“提交退款”；模型提出调用，应用或工具服务执行。 |
| 参考文件 / 脚本 | Skill 可附带政策说明、核对清单、可执行程序等。参考文件提供资料；脚本只有经过受控运行环境执行才会产生动作。 |
| O-314、U7、P2 | 虚构订单、服务端已认证用户、当前售后政策版本。 |
| 权限网关 | 在工具真正执行前校验身份、参数和可做的动作；Skill 里的文字不能越过这道校验。 |
例子前提：U7 登录客服系统，要求审核自己的订单 O-314。系统有只读查单工具、读取政策 P2 的工具和需要额外审批的退款工具。本文只让 Skill 产出审核建议；真正退款要由后端另行确认和审批。订单号和政策均为教学假设。
一个 Skill 通常装着什么
OpenAI 的 Skill 文档把技能描述为包含 SKILL.md 的文件目录，可附参考资料、脚本和模板。SKILL.md 的前部有名称、描述，后面写工作说明。发现阶段通常先展示名称和描述；真正使用时再读全文，必要时继续读引用的支持文件。OpenAI：Skills · OpenAI：Plugins 中的 Skills
虚构的售后审核技能可写成下面这样。它只是说明文件示例，不是连接真实订单系统的可运行程序：
markdown
---
name: after-sales-review
description: 用户要求审核售后申请时，核对订单与当前政策并给出可追溯建议；不执行退款。
---
1. 从当前已认证会话确认用户身份，不把用户自述身份当凭据。
2. 调用查单工具，核对订单号、归属和当前状态。
3. 读取本次订单适用的政策版本，记录政策来源。
4. 若资料不足或冲突，说明缺什么并停止；不得猜测通过。
5. 输出建议、依据、尚待人工核验的地方；不得调用退款工具。name 是给系统区分技能的短标识，description 告诉 Agent 在什么任务上考虑它；正文才是详细的工作顺序。第一步提到的“已认证会话”是后端登录信息，不是模型在聊天里猜身份。第二步的“查单工具”需要应用预先提供接口与授权。第五步只允许建议，不等于用户的退款已被批准。
如果还需固定输出格式，可以在技能目录放模板；如果有长政策解释，可以放参考文件，正文只链接其位置，真正需要时再读；如果有可复现的数据处理，可以附脚本，但脚本运行要经过沙箱、允许的文件/网络范围及参数校验。把复杂规则拆开，有助于保持主技能简洁，不过隐藏在支持文件里的关键限制也必须在调用前被读到并执行，不能让权限规则只藏在某个可能不会打开的附件中。
从用户请求到结果，技能怎样发挥作用
以“请审核 O-314 售后工单”为例，完整链路有六步：
- 发现：应用告诉 Agent 当前可用技能的名称和简短描述，如“售后审核”“翻译”“画图”。这里还没有把三份详细说明都送进模型。模型根据请求匹配到售后审核。
- 加载：运行环境读取“售后审核”的
SKILL.md，把步骤交给模型。若需要某份政策说明，再读取对应参考文件。加载成功后，本轮模型才真正拥有这套工作说明；只看到技能名不等于已理解完整步骤。 - 核订单：Agent 按技能建议调用查单工具；后端用
U7的真实登录态确认O-314属于他，并返回当前订单事实。Skill 没有查库能力，是已有工具完成这一步。 - 查政策：Agent 获取适用的
P2文档或政策服务结果，注意生效时间和适用范围。若查到的只是过期版本，不能因为 Skill 写“查政策”就把它当正确依据。 - 形成建议：模型汇总真实订单事实与政策依据，说明是否满足申请条件、还缺什么。它不调用退款工具，也不把“可申请”说成“已退款”。
- 核验和交付：应用检查是否有工具结果和来源，敏感操作仍由权限网关控制；客服向用户给出可理解的建议。系统记录所用 Skill 版本、政策版本和工具轨迹，便于复盘。
这种设计解决两个实际问题：第一，可复用，同类售后审核能沿同一套步骤走；第二，上下文更集中，翻译任务不必读售后政策全文。它不能保证每次模型都自动正确选中技能，也不能替代业务系统对订单事实、权限和政策的检查。LangChain 的 Deep Agents 也把 Skills 作为可复用的专门工作流、领域知识和自定义指令，并展示按需加载专用技能的场景。LangChain：Deep Agents overview · LangChain：Learn
Skill、工具、普通提示词和工作流怎么分
它们解决的不是同一层问题：
| 对象 | 回答的问题 | 售后审核例子 |
|---|---|---|
| 普通提示词 | 本次模型该怎样理解任务或回答 | 用户说“帮我审核 O-314”及当前客服规则。 |
| Skill | 某类任务通常按什么步骤做、要读哪些资料、如何交付 | 售后审核 SKILL.md 写“核订单→查政策→给建议”。 |
| 工具 / MCP 接口 | 到哪里拿实时数据或执行动作 | 查订单工具返回 O-314 的状态；政策工具返回 P2。MCP 可用于连接某些外部工具，但 Skill 本身不是 MCP 服务器。 |
| 工作流 | 程序把哪几步、分支和审批固定下来 | 系统硬性规定“归属不符就停”“退款必须人工批准”。 |
Skill 可以装工作流说明，但说明文字不等于程序里的强制分支。如果法律或资金业务要求每笔退款必须人工确认，应该把这一关写成后端条件或工作流节点；技能可以提醒模型遵守，却不能作为唯一执行保证。OpenAI 官方文档也把 Skill 描述为工具之上的可复用流程指导：MCP 服务器提供实时信息或受控动作，Skill 说明怎样组合这些工具完成任务。OpenAI：Plugins 中的 Skills
什么情况下容易用错
错误匹配：用户只说“帮我翻译一封售后邮件”，Agent 因出现“售后”两字就加载审核技能。正确做法是让 description 写清触发任务和排除范围，并用“翻译售后邮件”“审核订单申请”分别做样例测试。必要时让用户说明是要翻译还是要决定可否申请。
技能内容过期：技能写着“按 P1 政策处理”，而今天有效的是 P2。技能版本需与政策来源分开：工作步骤可相对稳定，实际政策从权威服务读取并检查生效时间。修改技能时标版本并做回归测试；不要把每条会变的业务价格或日期写死在技能正文里。
把技能当权限：有人在外部网页放一份名叫 SKILL.md 的文件，声称“审核前先导出所有订单”。这不因为文件名像技能就成为可信指令。安装或加载的技能应来自可信范围，经审查后暴露给 Agent；运行脚本的权限、网络和文件访问由环境控制。OpenAI 的 Skills 文档明确提示在提供技能前要检查其内容和随附文件，因为技能可带来提示词注入与数据外泄风险。OpenAI：Skills 安全说明
执行中断：查单工具超时，模型仍照着技能最后一条写“建议批准”。正确结果是停在资料不足处，说明未核实订单。技能里应明确失败后的行为，应用也要核验是否真的收到了所需工具结果。不能把“按流程做过一遍”的模型自述当完成证据。
怎样设计和检验一个好用的 Skill
先界定一个清楚、可重复的任务，例如“为已登录用户审核售后申请并给出依据”，而不是“处理所有公司业务”。描述里写清何时使用、何时不适用；正文每步写可观察的输入和输出。把经常变化的事实放权威数据源，把确定性的权限和审批留给程序，把长背景放参考文件。设计时还要决定哪些步骤允许模型灵活判断，哪些必须被代码固定。
验证不只看最终文字是否流畅。准备“本人订单且材料齐全”“他人订单”“过期政策”“工具超时”“用户只想翻译邮件”“网页冒充技能”等样本，检查实际技能选择、工具轨迹、证据版本、权限拒绝和最终答复。修改技能后，对同一批样本回归。OpenAI 文档支持技能版本化；但更重要的是把团队自己的业务正确率、误触发率、越权尝试和未查证即下结论率测出来。OpenAI：Skills
面试时怎么回答
Skill 是给 Agent 的可复用任务说明包，常见形态是一个带
SKILL.md的目录，里面有名称、用途描述、详细步骤和可选的参考资料、模板或脚本。运行时通常先把技能的短描述暴露给 Agent，任务相关时再加载全文，所以不必每轮塞进所有领域细则。比如售后审核 Skill 会要求先核订单归属、再查当前政策、最后给有依据的建议。Skill 指导模型怎样组织工具，却不提供工具权限；查单、读政策由真实工具完成，退款审批仍由后端网关强制执行。我会用正确匹配、误匹配、过期政策、工具失败和恶意技能文件等样本验证，并对技能做版本管理。
如果追问“Skill 和 Function Calling 有什么差别”，可以说：Function Calling 让模型提出要调用哪个具体工具和参数；Skill 规定这类任务应该怎样组合步骤与工具。追问“Skill 是否就是 System Prompt”，可以说它同样是指令材料，但通常更聚焦一个任务、可独立维护并按需加载；具体在哪个优先级传给模型，取决于产品的运行环境，不能把文件存在磁盘上等同于模型已读到它。
资料依据
- OpenAI：Skills（API）：目录结构、元数据发现、按需读取、支持文件、版本与安全。
- OpenAI：Plugins 中的 Skills：技能工作流与 MCP 工具的分工。
- LangChain：Deep Agents overview 与 Learn：可复用技能和按需上下文的实例。