面试题库

7 天 Agent Skills：把经验做成可复用能力

D6 组织与分发：插件与市场、版本与团队共享，以及函数调用、MCP、Skills 三者的分工

• skill 包要不要做版本管理？升级时最容易出什么问题？Should a skill package be versioned, and what goes wrong most often on upgrade?

  国内高频海外高频深入#agent-skills#versioning#distribution

  分析过程 · 先想清楚再作答

  1. 这题看着像流程题，实际考的是「skill 的接口到底是什么」。想清楚这一点，答案自然出来。
  2. 先答要不要：对内可以宽松，**对外发布必须写死版本**。写了版本，用户只在这个值变化时才收到更新，这是可控的；不写的话 Git 来源会拿提交哈希当版本，你每推一次内容用户就更一次，团队内部尚可，对外就是失控。
  3. 补一条容易忽略的细节：版本不要在包清单和市场清单两处都写，包自己的清单优先级更高，两边不一致会得到一个你自己都解释不清的状态。
  4. 接着答判据。什么改动要升版本？不是「改没改文件」，而是「**用户的行为会不会因此变化**」。描述改了、正文步骤改了、脚本参数改了都要升；修错别字、补注释不用。这跟给库发版一个道理，只不过这里的接口不是函数签名。
  5. 本题的拿分点在这里：**skill 的接口是描述与正文**。大家都记得改脚本要升版本，却常觉得「我就是把描述改得更准了一点」不算变更。但描述是唯一的触发面，改宽了会开始抢别的任务，改窄了会突然不触发。**描述的每一次改动都是行为变更**，都要在升级说明里单独写一行。
  6. 再给两个升级期的具体坑。一是改包名：包名是命名空间，改名等于把包里所有技能的调用名全改了，用户那边所有写死调用名的地方一起断。二是拆包与合包：一个 skill 从 A 包挪到 B 包，对用户来说是「装了 A 的人突然少了一个能力」，必须在升级说明里显式写迁移步骤。
  7. 可预期的追问是「怎么知道升级没升坏」。答案是把第三天那套触发测试当回归跑：改描述前后各跑一次同一组正负例，比触发率而不是凭感觉。

  How to reason about it · think before answering

  1. It looks procedural but really asks what a skill's interface is. Answer that and the rest follows.
  2. Should you version? Internally you can be loose; for public distribution you must pin a version. With a version, users update only when it changes. Without one, git sources use the resolved commit, so every push updates everyone, which is tolerable inside a team and out of control outside it.
  3. Add an easily missed detail: do not set the version in both the plugin manifest and the marketplace catalog. The plugin manifest wins, and a mismatch leaves a state you cannot explain.
  4. Then the criterion. What requires a bump is not whether a file changed but whether user-visible behavior changes. A changed description, changed body steps, or changed script flags all require a bump; typos and comments do not. It is the same as releasing a library, except the interface is not a function signature.
  5. The scoring point: a skill's interface is its description and body. Everyone remembers to bump for script changes but treats a slightly sharper description as cosmetic. The description is the only trigger surface: widen it and the skill starts stealing tasks, narrow it and it silently stops firing. Every description change is a behavior change and belongs in the upgrade notes.
  6. Give two concrete upgrade traps. Renaming the package changes the namespace, so every skill's invocation name changes and any hard-coded reference breaks. Moving a skill between packages looks to users like a capability disappearing, so the upgrade notes must spell out the migration.
  7. Expected follow-up: how do you know an upgrade did not break things? Run the day-three trigger tests as a regression, comparing hit rates on the same labeled queries before and after.

  答题要点

  • 对内可宽松，对外发布必须写死版本；不写版本时 Git 来源按提交更新，等于失控。
  • 版本不要在包清单与市场清单两处都写，包清单优先。
  • 升不升版本看用户行为会不会变，不看改没改文件。
  • skill 的接口是描述与正文，描述的每一次改动都是行为变更，最容易被漏掉。
  • 改包名会改掉全部调用名，跨包挪动 skill 要写迁移步骤；用触发测试做升级回归。

  Key points

  • Loose internally, pinned for public release; without a version, git sources update on every commit.
  • Never set the version in both the plugin manifest and the marketplace catalog; the plugin manifest wins.
  • Bump when user-visible behavior changes, not when a file changes.
  • A skill's interface is its description and body, and every description change is a behavior change.
  • Renaming the package rewrites every invocation name, moving a skill across packages needs migration notes, and trigger tests serve as upgrade regression.