Chapter 03 · Agent Skill

Skill 机制

02 章解决的是 agent「如何行动」的流程问题；本章回答「如何把流程知识装进 agent」——Skill 把操作规程从散落的 prompt 沉淀为可加载、可分发的文件资产。

本章覆盖原题

  • Q7 — Skill 是什么？Auto-coder Skill 的工作流程是怎样的？
  • Q8 — Skill 的核心价值是什么？为什么会出现这个概念？

Q7Skill 是什么？Auto-coder Skill 的工作流程是怎样的？

面试官在考什么

考察候选人是否理解 Skill 的文件结构与渐进式披露（progressive disclosure）加载机制，而非停留在「Skill = 一段提示词」的表层认识。

参考答案

Agent Skill 是一个文件夹：核心文件 SKILL.md 承载操作规程，旁边按需附带脚本、模板与参考文件。Anthropic 于 2025-10-16 发布该机制。

文件结构分两部分：

  • SKILL.md = YAML frontmatter（元数据头，必填 name 与 description）+ Markdown 正文，正文写操作规程（SOP）。
  • 附属资源：脚本、模板、参考文件——正文按需引用，脚本在执行环境运行。
SKILL.md markdown 
---
name: pdf-form-filler
description: 填写 PDF 表单。当用户要求处理 PDF 表单、提取或回填字段时使用。
---

# 操作规程
1. 运行 scripts/inspect.py 列出表单字段（脚本结果回传，代码不进上下文）
2. 按 references/field-mapping.md 的映射规则填写字段
3. 生成后用 scripts/validate.py 校验产出

L2-L3frontmatter 的 name + description 是渐进式披露第一阶段唯一进入上下文的内容，description 同时承担触发匹配的职责。

工作机制：渐进式披露三阶段。设计目标是让上下文只承载当前需要的内容：

  1. Discovery（发现）：会话启动时，系统只把所有 skill 的 name + description 装入上下文——每个 skill 仅占几十 token，相当于一份目录索引。
  2. Activation（激活）：当前任务与某个 description 匹配时，完整 SKILL.md 正文才被读入上下文，数百 token 量级。
  3. Execution（执行）：按正文引用，按需加载参考文件；捆绑脚本在代码执行环境中运行——脚本代码本身不进上下文，只回传执行结果。
上下文窗口 skill 索引 ≈几十 token/个 SKILL.md 正文 （命中的那个） 数百 token 剩余空间 留给任务本身 ① Discovery · 发现 启动时仅装入全部 skill 的 name + description ② Activation · 激活 任务匹配 description 后，读入完整 SKILL.md ③ Execution · 执行 按需加载引用文件；捆绑脚本在执行环境运行 脚本代码不进上下文 只回传结果
图 1渐进式披露：三个阶段逐层把 skill 内容装入上下文，脚本代码始终留在执行环境，仅结果回传。

coding 类 skill 的典型工作流程：

  1. 用户发出请求；
  2. 请求与某个 skill 的 description 匹配触发，或通过 /skill-name 显式调用；
  3. 完整 SKILL.md 正文指令载入上下文；
  4. 按正文 SOP 调用工具、运行捆绑脚本（脚本代码不进上下文，仅回传结果）；
  5. 按规程对产出做校验后交付。
事实核查 · 「Auto-coder Skill」的指代

开源项目 allwefantasy/auto-coder 本身没有名为 Skill 的机制——它提供 chat / coding / agentic 模式与 RAG 索引，没有 SKILL.md 类设计。面试题中的「Auto-coder Skill」更接近泛指「AI 编码 agent 的 Skill 机制」（Claude Code 式）。

面试应对：按通用 Skill 三阶段机制作答，并主动向面试官确认所指——例如「如果指的是 Claude Code 式的 Skill 机制，可以按该机制展开」。这种澄清本身是加分行为。

60 秒口头版本

Skill 是给 agent 的技能包：一个文件夹，核心是 SKILL.md——frontmatter 写 name 和 description，正文写操作规程，旁边放脚本和模板。关键设计是渐进式披露：启动时上下文里只有每个 skill 几十 token 的索引；任务匹配 description 时才读入完整正文；执行阶段按需加载引用文件、在代码环境跑捆绑脚本，脚本本身不占上下文，只回传结果。对编码类 skill，流程就是请求匹配触发→加载规程→按 SOP 调工具→按规程校验产出。

加分点

Insight
  • 可组合、可移植：同一个 skill 文件夹在 Claude app、Claude Code、API（/v1/skills）之间通用；多个 skill 在同一任务中组合生效。
  • 安全面：附带脚本等于授予代码执行权——引入 skill 前需要信任来源并做审计。

追问预判

追问 1 · skill 数量增多后，索引本身会不会占满上下文？

每个 skill 的索引只有 name + description 几十 token，百级数量的索引开销仍远低于预载完整内容。真正的约束在 description 的区分度：描述写得含混会导致误触发或漏触发，因此 description 的写作质量直接决定触发准确率。

追问 2 · Skill 与直接写一段长 system prompt 的区别？

system prompt 常驻每一轮对话，全部内容持续占用上下文并计费；Skill 只在匹配时加载，且作为文件可版本化、可跨项目分发。两者的关系类似「常驻配置」与「按需加载的模块」。

追问 3 · 捆绑脚本的执行安全如何控制？

脚本在代码执行环境中运行，权限边界由该环境决定。工程上的控制点有三个：来源信任（只装可信仓库的 skill）、装载前审计脚本内容、用沙箱限制文件与网络访问范围。

Q8Skill 的核心价值是什么？为什么会出现这个概念？

面试官在考什么

考察候选人能否从上下文经济与知识资产化的角度解释 Skill 的出现动机，并与 MCP、RAG、fine-tuning 划清边界。

参考答案

Skill 的价值分三层：上下文经济、知识资产化、与替代方案的明确分工。

第一层：上下文窗口是稀缺资源。MCP（模型上下文协议）把全部工具定义在会话开始时预载进上下文，多个 server 叠加后占比相当高——Milvus 博客实测 3 个 MCP server 约占上下文窗口的 72%。Skill 反其道而行：常驻的只有索引（name + description），完整内容按需展开，上下文成本与 skill 数量近似解耦。

第二层：组织知识沉淀为可分发资产。团队的 know-how 与 SOP 原本散落在各人的 prompt 里，Skill 把它们变成版本化、可复用、可共享的文件——类比给新员工的 onboarding 手册：写一次，所有 agent 实例按需取用，更新只改一处。

第三层：与替代方案的边界。每种方案给 agent 的东西不同：

把知识交给 agent 的四种方案
方案提供什么局限
fine-tuning把知识写进模型权重成本高、更新慢、不可逐条审计
RAG检索式注入事实（回答「是什么」）给事实，不给流程
MCP标准化的连接与工具（hands）工具定义预载，占用上下文
Agent Skill程序性知识 know-how（回答「怎么做」）依赖 description 质量与执行环境信任

三者互补而非互斥：Skill 定流程 → MCP 连数据 → tool 执行动作。

Agent Skill 知识 / 流程 承载 SOP 与程序性知识 回答「怎么做」 MCP 连接 / 数据 标准化接入外部系统 回答「连什么」 function calling 动作执行 发起一次具体工具调用 回答「做动作」 协作链 Skill 定流程 MCP 连数据 tool 执行动作
图 2三种机制的边界与协作链：Skill 提供 know-how，MCP 提供连接与数据，function calling（工具调用）执行具体动作。

与 01 章记忆系统的程序性记忆呼应：Skill 本质是把程序性记忆做成文件资产——「怎么做」的知识不再依赖权重或对话历史，而是落成可审计、可分发的文件。

60 秒口头版本

Skill 解决两个问题：上下文经济和知识资产化。MCP 把全部工具定义预载进上下文，Milvus 实测 3 个 server 约占 72% 的窗口；Skill 只载索引、按需展开。同时它把团队 know-how 从散落的 prompt 变成版本化、可分发的文件，相当于给 agent 的 onboarding 手册。和替代方案相比：fine-tuning 贵且更新慢，RAG 给事实不给流程，MCP 给连接，Skill 给程序性知识——三者互补：Skill 定流程、MCP 连数据、tool 执行动作。

加分点

Insight
  • 本质是 prompt engineering 的工程化与模块化：复用文件系统而非发明新协议，上手成本极低。
  • 前沿动态：2025-12-18 Skills 开放为开放标准（agentskills.io，含规范与 SDK）；2026 上半年 Cursor、VS Code / Copilot、OpenAI Codex、Gemini CLI 等数十个客户端跟进，Cursor 直接兼容读取 .claude/skills/ 目录。

追问预判

追问 1 · Skill 会取代 MCP 吗？

不会。两者解决正交问题：MCP 解决「agent 如何连到外部系统」——传输、鉴权、工具发现；Skill 解决「agent 按什么规程做事」。72% 的实测数据指向的是 MCP 工具定义预载的上下文成本，对应的改进方向是索引化与按需加载，而不是去掉连接层。

追问 2 · 同样是按需取内容，Skill 与 RAG 的差别？

取的内容类型与触发方式都不同：RAG 用语义检索取事实片段，服务于「回答问题」；Skill 用 description 匹配取操作规程，服务于「规范行为」。一个补充「是什么」，一个补充「怎么做」。

追问 3 · 在团队里推动 Skill 落地，第一步做什么？

挑最高频、最依赖口口相传的 SOP（发布流程、代码评审清单）写成第一个 skill，用两个指标验证效果：description 触发准确率、产出按规程校验的通过率。验证通过后再扩展到其他流程。

本章自测

  1. 渐进式披露的三个阶段分别把什么装进上下文？各自的 token 量级？
    查看答案

    Discovery：全部 skill 的 name + description，每个几十 token；Activation：命中 skill 的完整 SKILL.md 正文，数百 token 量级；Execution：按需加载的引用文件——捆绑脚本在执行环境运行，代码不进上下文，只回传结果。

  2. SKILL.md 的 YAML frontmatter 必填字段是哪两个？分别决定什么？
    查看答案

    name 与 description。name 是标识，也用于 /skill-name 显式调用；description 决定任务匹配时是否触发，是 Discovery 阶段唯一进入上下文的描述信息。

  3. 各用一句话说明 Skill、MCP、function calling 解决的问题。
    查看答案

    Skill 提供程序性知识——按什么规程做（know-how）；MCP 提供标准化的连接与数据接入——连什么；function calling（工具调用）让模型发起一次具体的工具调用——做动作。协作链：Skill 定流程 → MCP 连数据 → tool 执行动作。

  4. 面试题里出现指代不明的限定词（如「Auto-coder Skill」），标准应对是什么？
    查看答案

    按通用机制作答（Skill 的渐进式披露三阶段），同时主动向面试官确认所指。澄清行为本身体现严谨，是加分项；allwefantasy/auto-coder 项目实际并无名为 Skill 的机制。

延伸阅读