考察点
这道题出自字节跳动大模型岗一面，考的是对 Agent Skills 这一新机制的理解（Anthropic 2025 年推出后迅速成为热点）。面试官想看三件事：你是否理解 Skill 解决的是「领域知识怎么模块化」的问题；能否讲清渐进式加载（progressive disclosure）的机制与量级；以及那个区分度最高的问题——Skill 和 prompt 模板到底是不是一回事。追问常往 description 设计、Skill 冲突、与 Few-shot 的区别走。
参考答案
Skill 的定位：可执行的知识包
Agent Skill 解决的是一个真实痛点：Agent 用到深处，system prompt 里塞满了各种领域的操作规范——怎么写 SQL、怎么按公司模板生成报表、怎么处理退款流程——越来越长、互相干扰、没法复用。Skill 的思路是把这些 know-how 从 system prompt 里剥离，打包成独立的能力包：一个目录，核心是一份带 front matter（name + description）的 SKILL.md 指令文档，旁边可以放参考文档、脚本、模板等资源。Agent 装上一组 Skill，就等于员工入职时发了一排操作手册，需要哪本翻哪本。
结构与渐进式加载
Skill 机制的灵魂是渐进式加载（progressive disclosure），分三级：
- 元数据级：所有 Skill 的 name 和 description 常驻上下文，每个几十 token。模型靠 description 判断当前任务和哪个 Skill 相关。
- 正文级：命中后，才把对应 SKILL.md 的正文（操作指令、流程规范，几百到几千 token）读进上下文。
- 资源级：正文里引用的参考文档、脚本，只在执行到那一步时才读取或运行，不进初始上下文。
省下的量级可以算笔账：假设装了 20 个 Skill，每个正文平均 2k token，全塞 system prompt 是 40k+ token 常驻——还没干活窗口先去了一截，注意力也被稀释。渐进式加载下，常驻只有 20 条约 50 token 的元数据（共 1k 左右），一次任务实际加载一两个相关 Skill 的正文，常驻上下文省掉 95% 以上。这个机制和 MCP 工具全量注入的上下文困境是同一个解法思路：让模型按描述检索能力，而不是把能力一次性铺满。
和 Prompt 模板的本质区别
这是最容易答浅的地方。「Skill 不就是写得好点的 prompt 吗」——不对，差在三点：
- 触发机制。prompt 模板是开发者写死在代码里的，什么时候用什么模板由程序逻辑决定；Skill 由模型根据 description 语义匹配自主决定何时加载，触发本身是模型能力的一部分。
- 携带资源。模板只是一段文本；Skill 可以带可执行脚本（比如一个跑数据校验的 Python 文件）和参考资料，模型可以调用脚本干活、按需翻阅文档——Skill 是「指令+工具+资料」的打包，文本只是入口。
- 生命周期。模板没有生命周期的概念；Skill 有发现、加载、使用、卸载的完整过程，可以像软件包一样安装、更新、共享，一个团队沉淀的 Skill 可以分发给所有 Agent 用。
一句话：prompt 模板是静态文本填充，Skill 是可被发现、被触发、携带资源的模块化能力单元。
写好 Skill 的实践要点
description 是命脉——它决定触发率。写「处理数据」这种宽泛描述，模型要么乱触发要么不触发；好的 description 说清「做什么+什么时候用」，比如「按公司财报模板生成季度 PPT，当用户要求生成汇报演示文稿时使用」。正文要克制，只写模型不知道的东西（它是操作手册不是教科书），长内容拆到资源文件里按需引用。多个 Skill 职责重叠会导致触发竞争，要定期合并治理。
可能的追问
- description 没写好会有什么后果？ 答：两类失败——该触发不触发（描述太窄或与用户表述不匹配），Agent 退化回裸模型瞎做；不该触发的触发了（描述太宽），加载一堆无关指令稀释注意力还浪费 token。
- Skill 和 Few-shot 有什么区别？ 答：Few-shot 是在上下文里放输入输出示例教模型「照猫画虎」，适合格式和风格约束；Skill 是完整的操作知识与资源包，适合多步骤、有外部依赖的流程性任务，两者可以共存于一个 Skill 里。
- 两个 Skill 指令冲突怎么办？ 答：加载时检测重叠并告警；运行时靠 SKILL.md 里写明优先级和边界；根本解法是治理——Skill 像代码库一样需要 review 和定期重构，不是写得越多越好。