Agent Skills 是什么？和把说明全写进 system prompt 有什么区别？渐进式披露解决什么？
谁在问：头部 AI 公司 2026 新题；用来看你有没有理解「手册」这一层的定位，以及它和代码约束的边界
口语化问法
- Agent Skills 你了解吗？跟直接写在系统提示里有什么不一样？
- 渐进式披露到底解决了什么问题？
- 我们有几十份操作规范，是不是都做成 skill 就行了？
考察意图
第三个问法是陷阱——全都做成 skill 会引出新问题（触发不准、规则互相冲突）。面试官在验三层：
- 能不能说清定位。 一句话：**Skills 是操作手册，MCP/工具是手。**手册讲怎么把事做对，工具提供做事的能力。分不清这层的人，会把 skill 当成"另一种插件"。
- 知不知道渐进式披露解决的是常驻 token 与遵循度的矛盾。 只答"按需加载更省"是及格，能说出长系统提示会稀释指令遵循才是理解。
- 知不知道手册的边界在哪。 这是分水岭：手册是建议，代码是保证——安全和合规约束不能靠 skill。
参考答案
60 分答案（及格线）
Agent Skills 是把"怎么把某件事做对"的知识打包成模型可按需取用的手册，而不是常驻在系统提示里。截至 2026-08，它的核心机制是四级渐进式披露：
- 广告层：每个 skill 只用大约 100 token 说明"我是干什么的、什么时候该用我"，这部分常驻；
- 正文层：模型判断相关后才加载 SKILL.md，控制在 5000 token 以内（约 500 行）；
- 引用层：更细的资料放 references，需要时再读；
- 脚本层：确定性的操作直接写成 scripts，让模型去执行而不是自己推理。
和全写进系统提示的区别：系统提示是每一轮都要重发的，十几份规范塞进去，每次对话都在为用不到的内容付费；而 skill 平时只占广告那点位置。
90 分答案（有生产经验的回答）
补三层。
1. 差别不只是省钱，有四条。
| 维度 | 全写进 system prompt | Skills |
|---|---|---|
| 成本 | 常驻、每轮重发，规范越多越贵 | 广告常驻（约 100 token/个），正文按需 |
| 遵循度 | 提示词越长，关键指令越容易被稀释（长上下文的注意力衰减） | 只加载当前相关的一份，指令密度高 |
| 可维护 | 巨型提示词最后没人敢改 | 是文件，可版本化、可 review、可分发复用 |
| 可组合 | 多套规则塞在一起会互相打架 | 按场景加载，天然隔离 |
第二和第四条比省钱更重要。我见过把七八份流程规范堆进系统提示的系统，结果是每一份都执行得半吊子——不是模型不听话，是它同时被七八套指令拉扯。
2. 脚本层是最被低估的一层。 手册里凡是确定性、可重复、模型容易做错的步骤（格式转换、字段校验、批量处理、按固定规则计算），都该写成脚本让模型调用，而不是写成文字让它每次重新推理。这既省 token 又消除随机性。判断标准很简单：如果这一步的正确答案是唯一的，就不该让模型即兴发挥。
3. 边界是这题的分水岭：手册是建议，代码是保证。 Skill 能提升"做对的概率"，但它不提供保证——模型可能不去加载、加载了也可能不完全照做。所以：
- 必须 100% 生效的约束（权限、金额上限、审批流、合规红线）→ 写进代码（策略引擎、执行层校验）；
- 能力（能查什么、能改什么）→ 工具 / MCP；
- 怎么做对的知识与流程 → Skills；
- 少量始终生效的核心指令（角色、语气、全局禁令）→ system prompt。
四者的边界清楚了，系统提示自然就瘦下来了。
4. 三段式看渐进式披露。 解决规范膨胀与遵循度、复用与分发的问题；代价是多一跳读取延迟、模型可能判断失误（该加载没加载，或加载了不照做）、手册本身要维护、广告写不好就永远不被触发；不该用在流程只有一两个且很短的场景（直接写进系统提示更省事）、对单轮延迟极敏感的链路、以及必须强制执行的规则（那是代码的活）。
追问链
为什么不把所有规范都写进 system prompt？给量化理由。
期望两笔账。成本账：系统提示每轮重发，十份规范共几万 token，一次十轮任务要付十次，而其中九份这次根本用不上；改广告制常驻只剩约100 token× 份数。质量账更关键：超长系统提示稀释指令遵循，靠后的次要规则最容易被忽略，而且这种失效是静默的信号同时给成本账和质量账、并指出遵循失效是静默的 → 理解到位；只答「省 token」→ 及格但不够skill 写好了但模型不去用，怎么排查？
期望两类：没触发——问题都在广告描述：场景没写清、skill 边界糊、名字抽象；修法：写清「何时用」与「何时不要用」。触发了不照做：正文太长太抽象、堆背景无可操作步骤，或与系统提示冲突；改成步骤化指令、背景挪 references、确定步骤下沉脚本。改描述必须用标注 query 回归信号先分「没触发」与「没照做」两类 → 调过 skill；只答「把描述写详细点」→ 没有排查框架Skills、MCP、system prompt、代码，这四层边界怎么划？
期望必须保证的 → 代码；能做什么 → 工具/MCP；怎么做对 → Skills；少量常驻指令 → system prompt。两问定归属：必须 100% 生效吗 → 代码；每次都要用吗 → 提示，否则 Skills。MCP Prompts 由用户触发，Skills 由模型自取信号给出「是否必须生效 + 是否每次都用」两个判断维度 → 想清楚了；把 Skills 说成「MCP 的替代品」或「另一种插件」→ 层次混了脚本层的意义是什么？什么该写成脚本？
期望意义是把确定性从模型手里拿走——同样输入必须同样输出的步骤，让模型每次重推既贵又不稳；脚本化后可被单测覆盖，从概率正确变确定正确。该写：格式转换、字段校验、批量操作、按规则计算、模板填充；不该写：要判断权衡的，那正是模型的价值。代价：脚本要维护、跟上游变更、执行要沙箱，攻击面扩大信号说出「确定性步骤脚本化后可被单测覆盖」和「执行脚本扩大攻击面」→ 落地过；只答「脚本更快」→ 没看到本质40 个 skill 模型常加载错的，一次三四个还互相冲突，怎么救？
期望先冲突审计，别急调描述：两两过范围标矛盾（「退款流程」撞「大客户特殊处理」），改描述改不掉 → 建层级：全局原则上提，手册头写「与 X 冲突以本文为准」→ 减量合并：40 个 skill 并到十几个，判据是会犹豫就该合并 → 按角色分组装载、描述补「什么时候不用」→ 金额、权限、合规提到代码，放手册就是设计错误 → 标注 query 测触发准确率作基线信号先做冲突审计、给出「会犹豫就该合并」的判据、把强制规则提出手册 → 治理过规模化知识资产；只答「优化每个 skill 的描述」→ 治不好结构性冲突
评分要点
- 一句话定位：Skills 是操作手册，工具/MCP 是能力
- 说得出四级渐进式披露及各级的量级（约 100 token 广告 → 5000 token 正文 → references → scripts）
- 与全写进 system prompt 的差别不止成本，还有遵循度、可维护、可组合
- 知道长系统提示会稀释指令遵循，且失效是静默的
- 脚本层的意义：确定性步骤不该让模型重新推理
- 分水岭：手册是建议、代码是保证，强制约束不能放 skill
- 能划清 Skills / MCP / system prompt / 代码四层边界
- 加分：触发失败要分"没触发"与"没照做"，各有修法
- 加分：知道 skill 规模化后会有冲突，需要层级与优先级治理