面试题库

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

D1 Skills 是什么：SKILL.md 规范、目录结构与三阶段渐进式加载

• Agent Skills 解决的是什么问题？它和把所有规范写进一个大的提示词文件有什么区别？What problem do Agent Skills solve, and how are they different from putting every convention into one big instruction file?

  国内高频海外高频基础#agent-skills#context-engineering

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

  1. 这题的区分度在你有没有说出「按需」两个字。只答「skill 是可复用的提示词」的人，等于没答，因为那句话对提示词模板同样成立。
  2. 先给分工：工具补的是能力缺口，模型本来做不到的事；技能补的是经验缺口，模型做得到但不知道你们这儿怎么做。这一刀切下去，后面的论证才站得住。
  3. 再给机制差异：常驻指令文件每次会话全量进上下文，skill 平时只露 name 与 description，命中才展开正文。前者的成本是固定的，后者的成本是按需的。
  4. 接着算代价：二十条规范写满六千 token 的系统提示，五十轮会话要重复计费三十万 token；更贵的是注意力被不相干的规则稀释，做第三件事时被第十七条干扰。
  5. 最后给判据，这是面试官真正想听的一句：这条经验是不是每次都用得上？是就写进常驻指令文件，不是就做成 skill。
  6. 可预期的追问是「那提示词模板呢」。答案是谁来挑：模板是你手动选的，skill 是模型读着 description 自己选的，触发权在模型手里。

  How to reason about it · think before answering

  1. The discriminator is whether you say on demand. Answering skills are reusable prompts says nothing, because that is equally true of a prompt template.
  2. Start with the split: tools fill a capability gap the model cannot cross on its own; skills fill an experience gap where the model can do the task but not the way your team does it.
  3. Then the mechanism: a persistent instruction file enters context in full every session, while a skill exposes only name and description until something matches and its body is loaded.
  4. Quantify the cost: twenty conventions at six thousand tokens of system prompt bill three hundred thousand tokens over a fifty-turn session, and the attention dilution costs more than the money.
  5. Close with the rule of thumb interviewers want: if the guidance applies every single time, it belongs in the persistent instruction file; otherwise make it a skill.
  6. Expected follow-up: what about prompt templates? The difference is who chooses. You pick a template; the model picks a skill by reading descriptions.

  答题要点

  • 工具补能力缺口，技能补经验缺口，这是两件事，不要混着答。
  • 常驻指令文件成本固定且每轮重发，skill 的正文只在命中时才进上下文。
  • 把不相干的规范全塞进系统提示，除了花钱还会稀释注意力，让模型被无关规则干扰。
  • 判据是「是不是每次都用得上」：是就常驻，不是就做成 skill。
  • 和提示词模板的关键差别是触发权在模型手里，靠的是 description。

  Key points

  • Tools close capability gaps, skills close experience gaps. Do not blur the two.
  • A persistent instruction file costs the same tokens every turn; a skill body only enters context when it matches.
  • Dumping unrelated conventions into the system prompt both costs money and dilutes attention.
  • The test is whether the guidance applies every time: if yes it stays resident, if no it becomes a skill.
  • Unlike a prompt template, a skill is selected by the model itself from its description.
• 渐进式加载的三个阶段分别加载什么？为什么不能一次性把所有 skill 全加载进去？What does each of the three progressive disclosure stages load, and why not just load every skill up front?

  国内高频海外高频进阶#agent-skills#progressive-disclosure

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

  1. 这题在考你对机制的记忆精度，同时也在考工程感。只背出三个阶段的名字拿不到分，要说出每一阶段加载的**是哪些字段、哪些文件**。
  2. 拆法很简单，按加载的粒度从粗到细数：阶段一只加载 name 与 description，量级是每个 skill 五十到一百个 token；阶段二加载整份 SKILL.md 正文，建议不超过五千 token 与五百行；阶段三按文件粒度加载脚本、引用与资源。
  3. 回答「为什么不全加载」时给一个具体的数：二十个 skill 各三千 token 的正文加上引用文件，全量是十几万 token，超过很多模型的窗口，而且每一轮都要重发。渐进式加载后总量落在一万上下。
  4. 补一条更本质的理由：省下来的不只是钱，是窗口位置。腾出来的空间要留给真正在做的这件事的代码和数据，这就是上下文工程的核心取舍。
  5. 可预期的追问是「阶段三怎么触发」。答案是正文里必须写明读取条件——写「细节见 references 目录」等于没写，写「接口返回非 200 时读 references 里的错误码文件」才真正把时机交给了模型。

  How to reason about it · think before answering

  1. This tests both recall precision and engineering sense. Naming the three stages is not enough; say which fields and which files each stage pulls in.
  2. Order them by granularity: stage one loads only name and description, roughly fifty to a hundred tokens per skill; stage two loads the full SKILL.md body, recommended under five thousand tokens and five hundred lines; stage three loads individual scripts, references and assets.
  3. Answer the why with a number: twenty skills at three thousand tokens of body plus reference files is well over a hundred thousand tokens, past many context windows, and resent every turn. Progressive loading lands around ten thousand.
  4. Add the deeper reason: what you save is window space, not just money, and that space belongs to the actual task.
  5. Expected follow-up: how does stage three fire? The body must state the loading condition. See the references folder is useless; read the error-code reference when the API returns a non-200 hands the timing to the model.

  答题要点

  • 阶段一发现：只加载 name 与 description，每个 skill 约五十到一百 token。
  • 阶段二激活：读入完整 SKILL.md 正文，建议不超过五千 token 与五百行。
  • 阶段三执行：按需读取 scripts、references、assets 里的单个文件，不是整目录倒进来。
  • 全量加载会撑爆窗口且每轮重发，渐进式加载能把量级压到十分之一左右。
  • 阶段三能不能被触发，取决于正文有没有写清「什么条件下读哪个文件」。

  Key points

  • Discovery: only name and description, about fifty to a hundred tokens per skill.
  • Activation: the full SKILL.md body, ideally under five thousand tokens and five hundred lines.
  • Execution: individual files from scripts, references or assets, loaded one at a time on demand.
  • Loading everything up front blows the window and is resent every turn; progressive loading cuts it to roughly a tenth.
  • Stage three only fires if the body spells out which file to read under which condition.
• SKILL.md 的 name 与 description 有哪些硬性约束？规范为什么要把 name 卡得这么死？What hard constraints does the spec put on the name and description fields, and why is name so tightly constrained?

  国内高频海外高频进阶#agent-skills#spec

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

  1. 这题看着像背规范，其实题眼在后半句「为什么」。能把约束背全只算及格，能说出这些约束是为了解决什么工程问题才是加分项。
  2. 先把 name 的五条约束数完：长度一到六十四个字符、只能用小写字母数字和连字符、不能以连字符开头或结尾、不能有连续两个连字符、必须与父目录名一致。
  3. 再给 description 的两条：长度一到一千零二十四个字符；内容上要同时说清做什么和什么时候用，而不是只说做什么。
  4. 解释「为什么卡这么死」：name 是这个 skill 在整个生态里的唯一标识，要拼进目录名、命名空间、斜杠命令，还要在两个 skill 撞名时用来判优先级。任何一处大小写或分隔符不一致，都会变成一个很难查的「装了却调不到」。
  5. 补一个真实的坑：很多客户端在实现时故意放宽了「name 等于目录名」这条，不一致只打警告仍然加载。于是你本地一切正常，换个严格实现就整个消失。
  6. 可预期的追问是「description 写到一千个字符会怎样」。答案是它每次会话都要付一遍，二十个 skill 都写满上限，光目录就要八千 token，这时候该做的是把描述写短而不是删 skill。

  How to reason about it · think before answering

  1. It looks like spec recall, but the real question is the why. Listing the constraints is a pass; explaining which engineering problem they prevent is the differentiator.
  2. Name has five constraints: one to sixty-four characters, lowercase letters digits and hyphens only, no leading or trailing hyphen, no consecutive hyphens, and it must match the parent directory name.
  3. Description has two: one to one thousand twenty-four characters, and it must convey both what the skill does and when to use it.
  4. The reason name is strict: it is the skill's identity across the ecosystem, feeding directory lookup, namespacing, slash-command invocation and collision precedence. One casing mismatch becomes an installed but uncallable skill.
  5. Mention the real-world wrinkle: many clients deliberately relax the name-matches-directory rule and only warn, so a skill can work locally and vanish under a stricter implementation.
  6. Expected follow-up: what if the description runs to a thousand characters? You pay for it every session. Twenty maxed-out descriptions cost eight thousand tokens of catalog, so shorten the text rather than dropping skills.

  答题要点

  • name：一到六十四字符、小写字母数字与连字符、首尾不能是连字符、不能有连续连字符、必须等于父目录名。
  • description：一到一千零二十四字符，必须同时说清做什么与什么时候用。
  • name 卡死是因为它是唯一标识，要参与目录查找、命名空间、命令调用与撞名优先级。
  • 很多客户端对 name 做宽松校验，本地能跑不代表换个客户端也能跑。
  • description 是每次会话都要付的固定开销，能短则短。

  Key points

  • Name: one to sixty-four characters, lowercase alphanumerics and hyphens, no leading or trailing hyphen, no double hyphens, must equal the directory name.
  • Description: one to one thousand twenty-four characters, stating both what it does and when to use it.
  • Name is strict because it is the skill's identity for lookup, namespacing, invocation and collision precedence.
  • Many clients validate name leniently, so working locally does not guarantee working elsewhere.
  • The description is a fixed per-session cost, so keep it as short as it can be while still triggering.

D2 写第一个 skill：description 的触发词怎么写、结构怎么分层、怎么装进客户端

• skill 的 description 写得太泛会怎样？太窄又会怎样？你怎么找到中间那个点？What goes wrong when a skill description is too broad, and what goes wrong when it is too narrow? How do you find the middle?

  国内高频海外高频进阶#agent-skills#skill-description

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

  1. 这题的题眼在「代价」两个字。只说「太泛会误触发、太窄会不触发」是把题目复述了一遍，面试官等的是后面那句：误触发到底损失了什么。
  2. 先说太泛的代价，而且要说满三层：这个 skill 的正文白占了上下文位置；它的指令会干扰当前任务；更麻烦的是模型一旦选定了一个 skill，就更不容易再去选真正对的那个。**一个太泛的 skill 会拖累整个技能库**，这一句是拿分点。
  3. 再说太窄的代价：它只在用户按你预想的说法提问时才触发，而真实用户几乎不会那样说话。太窄的 skill 通常不是不好用，是根本没被用过，所以你连它不好用都不知道。
  4. 找中间点的方法要给成一套动作而不是感觉：写覆盖多种说法而不是多个关键词，末尾补一句边界排除相邻能力，然后用一组正例加近似负例把触发率量出来，按结果改描述。
  5. 补一个容易被忽略的事实：有些任务简单到模型觉得自己就能干，这时候描述写得再匹配也不会触发。判断描述好不好之前，先确认这个任务值不值得一个 skill。
  6. 可预期的追问是「改描述时怎么避免过拟合」。答案是不要把失败查询的原话抄进描述，要归纳出它代表的那一类说法，并留一部分查询不参与优化、只用来验证。

  How to reason about it · think before answering

  1. The hinge word is cost. Saying too broad misfires and too narrow never fires just restates the question; the interviewer wants to know what a misfire actually costs.
  2. Give three layers of cost for over-broad descriptions: the body wastes context, its instructions interfere with the current task, and once the model has committed to one skill it is less likely to reach for the right one. One over-broad skill degrades the whole library.
  3. For too narrow: it only fires when the user phrases things exactly as you imagined, and real users never do. Such a skill is usually not bad, it is simply never exercised, so you never learn that it is bad.
  4. Give the middle as a procedure, not a feeling: cover phrasings rather than keywords, add a boundary clause that excludes adjacent capabilities, then measure trigger rate against positives and near-miss negatives and revise from the data.
  5. Add the often-missed fact that agents typically only consult skills for tasks beyond what they handle alone, so a trivially easy task will not trigger no matter how well the description matches.
  6. Expected follow-up: how do you avoid overfitting when revising? Never paste the failing query verbatim; generalize to the category it represents, and hold out a validation split.

  答题要点

  • 太泛的三层代价：占上下文、干扰当前任务、挤掉真正该用的那个 skill。
  • 太窄的代价是根本没被触发过，问题被掩盖，你连它好不好用都测不出来。
  • 写法上覆盖「多种说法」而不是「多个关键词」，末尾补一句边界排除相邻能力。
  • 用正例加近似负例量出触发率，按数据改描述，不靠手感。
  • 任务本身太简单时不会触发任何 skill，这不是描述的问题。

  Key points

  • Three costs of over-broad: wasted context, interference with the current task, and crowding out the correct skill.
  • Over-narrow means it never fires, which hides the problem rather than surfacing it.
  • Cover phrasings rather than keywords, and add a closing boundary clause that excludes adjacent capabilities.
  • Measure trigger rate with positives and near-miss negatives, then revise from the data.
  • A task simple enough for the model alone will not trigger any skill; that is not a description problem.
• skill 的正文应该写什么、不应该写什么？为什么「坑」那一段必须留在 SKILL.md 里而不是挪到引用文件？What belongs in a skill body and what does not, and why must the gotchas stay in SKILL.md rather than move to a reference file?

  国内高频海外高频进阶#agent-skills#skill-authoring

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

  1. 这题考的是你有没有真写过 skill。没写过的人会答「写清楚步骤」，写过的人会先给一条判据。
  2. 判据只有一句：**不写这一条，模型会不会做错？** 不会就是废话，删掉。解释什么是 PDF、什么是数据库迁移，模型本来就知道，写进去纯粹在稀释注意力。
  3. 该写的三类是：项目特有的约定、非显然的边界情况、以及指定用哪个工具或接口。这三类的共同点是模型的通用知识里没有。
  4. 输出格式那一段要单独强调：给模板比用文字描述可靠，因为模型对具体结构做模式匹配的能力远强于读一段散文式的格式说明。
  5. 「坑」为什么不能挪走，答案是一个先后顺序问题：**模型得先知道有坑，才会去查坑**。放进引用文件就要求它在还没撞上的时候预判自己会撞上，这个前提不成立。引用文件适合放「我知道会用到，只是现在还不需要」的材料。
  6. 可预期的追问是「那什么该挪进 references」。答案是长、且用不用得上有明确判断条件的材料，并且正文里必须写出那个条件，比如「接口返回非 200 时读错误码文件」。

  How to reason about it · think before answering

  1. This separates people who have written skills from people who have read about them. The untested answer is write clear steps; the tested answer starts with a test.
  2. The test is one sentence: would the model get this wrong without this line? If not, cut it. Explaining what a PDF is only dilutes attention.
  3. Three things belong: project-specific conventions, non-obvious edge cases, and which tool or API to use. All three are absent from the model's general knowledge.
  4. Call out output format specifically: a concrete template beats prose, because models pattern-match against structures far better than they parse a described format.
  5. Gotchas cannot move because of ordering: the model must know a trap exists before it will look it up. Putting them in a reference file assumes it can predict a collision it has not hit yet.
  6. Expected follow-up: what does belong in references? Long material whose need has a clear trigger condition, and the body must state that condition, such as read the error-code file when the API returns a non-200.

  答题要点

  • 判据是「不写这一条模型会不会做错」，不会就删。
  • 该写：项目特有约定、非显然的边界、指定的工具与接口。
  • 输出格式给模板，不要用文字描述格式。
  • 坑必须留在正文，因为模型要先知道有坑才会去查坑。
  • 引用文件放长材料，且正文必须写出「什么条件下读它」。

  Key points

  • The test: would the model get this wrong without the line? If not, delete it.
  • Include project conventions, non-obvious edge cases, and the specific tool or API to use.
  • Give a template for output format instead of describing it in prose.
  • Gotchas stay in the body because the model must know a trap exists before looking it up.
  • References hold long material, and the body must state the condition for loading each one.
• 项目级和用户级的 skill 同名时该怎么处理？为什么各家客户端在这一点上会有不同的选择？How should a client resolve a name collision between a project-level and a user-level skill, and why do clients differ here?

  国内高频海外高频深入#agent-skills#client-integration

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

  1. 这题看起来是细节题，实际在考你有没有真的装过、有没有踩过。标准答案背后有一个分歧，能说出分歧的人一眼就是实操过的。
  2. 先给通行约定：跨客户端的普遍做法是**项目级压过用户级**，理由是离手头这份代码越近的配置越具体，理应赢。同一作用域内两个目录撞名，先找到还是后找到都行，但必须固定一种并保持一致。
  3. 再给分歧：具体客户端可以有自己的层级。Claude Code 的文档给出的顺序是企业级、个人级、项目级由高到低——**个人级压过项目级**，理由是不希望一个仓库带进来的 skill 悄悄覆盖掉你自己配的同名 skill。
  4. 把两种设计的取舍讲清楚，这是本题真正的区分度：项目优先换来的是「团队约定自动生效」，用户优先换来的是「不被陌生仓库劫持」。它们各自解决的是不同的风险。
  5. 顺势带出信任问题：项目级 skill 可能来自一个你刚 clone 的陌生仓库，等于让它往你的会话里注入指令。所以多数客户端把项目级加载挂在「信任这个目录」的开关后面。
  6. 可预期的追问是「撞名了怎么发现」。答案是客户端一般会打一条被遮蔽的警告，那条日志是排查的第一现场；实现方也应该在这种时候记录诊断信息而不是静默丢弃。

  How to reason about it · think before answering

  1. It looks like trivia but it tests whether you have actually installed skills. There is a real disagreement here, and naming it marks you as someone who has hit it.
  2. Start with the common convention: project-level overrides user-level, because configuration closer to the code at hand is more specific. Within one scope, first-found or last-found are both acceptable as long as you pick one and stay consistent.
  3. Then the divergence: Claude Code documents enterprise, then personal, then project, so personal wins over project, so that a cloned repository cannot silently shadow the skill you configured yourself.
  4. Explain the trade-off, which is where the marks are: project-first buys automatic team conventions, user-first buys protection from hijacking by an unfamiliar repository.
  5. Bring in trust: project-level skills can arrive with a freshly cloned repository and inject instructions into your session, which is why most clients gate them behind a folder-trust check.
  6. Expected follow-up: how do you notice a collision? Clients normally log a shadowed-skill warning, and implementers should record diagnostics rather than dropping the skill silently.

  答题要点

  • 通行约定是项目级压过用户级，同作用域内固定一种顺序并保持一致。
  • 具体客户端可以不同，比如 Claude Code 的顺序是企业级、个人级、项目级。
  • 项目优先换来团队约定自动生效，用户优先换来不被陌生仓库劫持。
  • 项目级 skill 可能来自不可信仓库，加载应挂在目录信任检查后面。
  • 撞名要打警告并记录诊断，不能静默遮蔽。

  Key points

  • The common convention is project over user, with a fixed, consistent rule inside a single scope.
  • Clients may differ: Claude Code documents enterprise, then personal, then project.
  • Project-first gives automatic team conventions; user-first prevents hijacking by an unfamiliar repository.
  • Project-level skills can come from untrusted repositories, so gate them behind a folder trust check.
  • Log a warning and record diagnostics on a collision instead of silently shadowing.

D3 设计方法：从重复任务提炼、检查清单式与参考手册式、四种反模式与触发测试

• 什么样的任务适合做成 skill，什么样的不适合？给我一套能当场用的判断标准。Which tasks are worth turning into a skill and which are not? Give me a test I can apply on the spot.

  国内高频海外高频基础#agent-skills#skill-design

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

  1. 这题最容易答成「重复的、复杂的任务」，那是所有人都会说的话，没有区分度。面试官想听的是一套能证伪的判据，以及每一条判据背后的道理。
  2. 给三条，并且强调三条都要成立：重复（干过至少三次且还会干）、有纠正（模型第一次做时你打断过它）、结果可检验（做完能判断对错）。
  3. 逐条解释为什么。「有纠正」是最硬的一条，因为它同时证明模型确实不会、你确实会——没有纠正记录的 skill 写出来大概率是「妥善处理错误」这类正确的废话。
  4. 「可检验」这条常被忽略但很关键：它决定的不是这个 skill 能不能写，而是**你能不能迭代它**。对错要三个月后才知道的任务，你写完只能凭感觉觉得有用。
  5. 然后给反面：不满足这三条会怎样——不重复的没人用，没纠正的是废话，不可检验的没法改进。这一句把判据从清单变成了论证。
  6. 可预期的追问是「那范围多大合适」。答案是像拆函数一样：一个内聚的工作单元，且能与别的 skill 组合。两个总是一起激活的 skill 本来就是一个；描述里忍不住写「等等」说明范围太大了。

  How to reason about it · think before answering

  1. The lazy answer is repetitive and complex tasks, which anyone can say. The interviewer wants a falsifiable test plus the reasoning behind each part.
  2. Give three criteria and insist all three must hold: repetition (done at least three times and will recur), correction (you interrupted the model the first time), and checkable results (you can tell afterwards whether it was right).
  3. Explain each. Correction is the strongest, because it simultaneously proves the model does not know and that you do. Without correction history you produce generic filler like handle errors appropriately.
  4. Checkability is the one people skip, and it decides not whether you can write the skill but whether you can iterate on it. If correctness only surfaces in three months, you are guessing.
  5. Then state the failure modes: without repetition nobody uses it, without correction it is filler, without checkability you cannot improve it.
  6. Expected follow-up: how wide should one skill be? Scope it like a function: one coherent unit that composes with others. Two skills always activated together were one skill; if the description needs and so on, the scope is too wide.

  答题要点

  • 三条判据全部成立才动手：重复、有纠正、结果可检验。
  • 有纠正是最硬的一条，它同时证明模型不会而你会。
  • 可检验决定的不是能不能写，而是能不能迭代。
  • 范围按内聚工作单元切，总是一起激活的两个 skill 应该合并。
  • 描述里出现「等等」「以及相关的」，说明范围已经太大，该拆。

  Key points

  • All three must hold before you start: repetition, correction, checkable results.
  • Correction is the strongest signal because it proves both the gap and your expertise.
  • Checkability decides whether you can iterate, not whether you can write it.
  • Scope to one coherent unit; two skills that always activate together should be merged.
  • If the description needs and so on, the scope is already too wide.
• 怎么测一个 skill 的 description 好不好？自己试几句话够吗？How do you evaluate whether a skill description is good? Is trying a few prompts yourself enough?

  国内高频海外高频进阶#agent-skills#evaluation

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

  1. 题眼在后半句。答「自己试几句就行」直接出局，但只答「要写测试集」也不够——面试官要看你知不知道这个测试集该怎么设计。
  2. 先说为什么抽查不够：一个 skill 时够用，装到第十个就不行了，因为你既记不住十个描述之间会不会互相抢，也没法在改完一句话后判断是改好了还是改坏了。
  3. 然后给三件东西。第一是带标注的查询集，约 20 条，正负各半。正例要在措辞、显式程度、详略、复杂度四个维度上铺开；**最有价值的正例是那些确实该用但字面看不出来的**，字面已经念了一遍功能的查询任何描述都能命中，测不出区别。
  4. 负例是设计的重点：毫无重叠的句子测不出任何东西，真正有用的是近似负例——共享关键词或概念但目标动词不同。对 CSV 分析 skill，「改 Excel 预算表的公式」和「把 CSV 每行写进数据库」都是好负例。
  5. 第二是重复跑取触发率：模型是不确定的，每条跑三次算命中比例，阈值取 0.5。第三是训练验证拆分，六比四，验证集全程不看。
  6. 可预期的追问是「怎么判断一条查询触发了没有」。答案是把所有 skill 的名字与描述拼成目录，连同这句话交给模型问它该用哪一个——这正是客户端在发现阶段做的事，只是单独拎出来跑。

  How to reason about it · think before answering

  1. The hinge is the second half. Saying a few prompts is enough fails immediately, but saying write a test set is not enough either; the interviewer wants the design.
  2. Explain why spot checks fail: fine with one skill, useless at ten, because you cannot hold ten descriptions in your head nor tell whether an edit helped or hurt.
  3. Then give three ingredients. First, a labeled query set of about twenty, balanced positive and negative. Vary positives along phrasing, explicitness, detail and complexity; the most valuable positives are the ones where the skill applies but the wording does not say so.
  4. Negatives are where the design effort goes: unrelated sentences test nothing. Near-misses that share keywords but need something else are what matters, such as editing Excel formulas or loading CSV rows into a database for a CSV-analysis skill.
  5. Second, repeat runs for a trigger rate, since model behavior is nondeterministic: three runs per query with a 0.5 threshold. Third, a roughly sixty-forty train and validation split with the validation set untouched.
  6. Expected follow-up: how do you decide whether a query triggered? Build the catalog of names and descriptions, hand it plus the query to the model and ask which skill applies. That is exactly what a client does at discovery, run standalone.

  答题要点

  • 抽查在一个 skill 时够用，多个 skill 互相干扰时完全不够。
  • 约 20 条带标注查询，正负各半，正例在措辞、显式程度、详略、复杂度四维上铺开。
  • 负例必须是近似负例：共享关键词但目标动词不同，无关句子测不出东西。
  • 每条跑三次取触发率，阈值 0.5，因为模型行为不确定。
  • 训练验证六四拆分，训练集指导改写，验证集只用来选版本。

  Key points

  • Spot checks work for one skill and break down once several skills compete.
  • About twenty labeled queries, balanced, with positives varied by phrasing, explicitness, detail and complexity.
  • Negatives must be near-misses that share keywords but need a different action.
  • Three runs per query for a trigger rate with a 0.5 threshold, because behavior is nondeterministic.
  • Split roughly sixty-forty; train guides revision, validation picks the winning version.
• 优化 description 的时候怎么避免过拟合到你自己写的那几条测试查询？When optimizing a description, how do you avoid overfitting to the very queries you wrote?

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

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

  1. 这题是机器学习的老概念换了个场景，考的是你能不能把它迁移过来。能说出「验证集」三个字只是起点，真正的区分度在你怎么描述那个具体的错误动作。
  2. 先点明过拟合在这里长什么样：一条查询没触发，你把它的原话抄进描述，于是这一条过了，换一句同义的又不过。**抄原话就是过拟合的动作本身。**
  3. 正确做法是归纳：找出这条失败查询代表的**那一类说法**，然后把这一类补进去。比如「这几个文件我要提交了」失败了，该补的不是这句话，是「不含专业词的口语提交请求」这一类。
  4. 结构上靠拆分兜底：查询集按六比四拆成训练与验证，只用训练集的失败项指导改写，验证集全程不参与优化过程，两份都要保持正负比例接近，拆完固定不再洗牌。
  5. 还有两条实操经验。**挑版本按验证集通过率挑，不是按迭代顺序挑**——后面几轮往往在往训练集上过拟合，最好的可能是第三版而不是第五版。改五轮左右还不动就该停，问题多半在查询集本身而不在描述。
  6. 可预期的追问是「怎么知道是查询集的问题」。答案是看那些在两种配置下都失败或都成功的条目：都成功说明这条太容易、没有信息量，都失败说明要么标注错了要么要求超出模型能力，两类都该换掉。

  How to reason about it · think before answering

  1. This is a familiar machine learning idea in a new setting. Saying validation set is only the start; the discriminator is describing the exact wrong move.
  2. Name what overfitting looks like here: a query fails, you paste its wording into the description, that query passes, and a synonymous one fails. Pasting the wording is the overfitting act itself.
  3. The right move is to generalize: identify the category the failing query represents and cover that. If a casual phrasing failed, cover casual phrasings, not that sentence.
  4. Structurally, rely on the split: roughly sixty-forty, revise only from train-set failures, keep the validation set out of the loop, preserve label balance in both, and freeze the split across iterations.
  5. Two practical rules: pick the version by validation pass rate rather than by recency, since later rounds tend to overfit, and stop after about five iterations if nothing moves, because the problem is then in the queries.
  6. Expected follow-up: how do you know the queries are the problem? Look at items that pass or fail in every configuration. Always-pass items carry no information; always-fail items are mislabeled or beyond the model.

  答题要点

  • 过拟合的具体动作是把失败查询的原话抄进描述，要改成补它代表的那一类说法。
  • 查询集六四拆分，只用训练集指导改写，验证集全程不看。
  • 两个集合都要保持正负比例接近，拆完固定，不要每轮重洗。
  • 按验证集通过率挑版本，最好的那版不一定是最后一版。
  • 五轮不动就停，去查查询集本身是不是太容易、太难或标注错了。

  Key points

  • The overfitting move is pasting a failing query verbatim; generalize to its category instead.
  • Split roughly sixty-forty and revise only from train-set failures.
  • Keep label balance in both splits and freeze the split across iterations.
  • Select the version by validation pass rate; the best is not always the last.
  • If five rounds change nothing, inspect the query set for triviality, impossibility or mislabeling.

D4 带脚本的 skill：可执行附件、依赖与沙箱、跨平台，以及文档处理类 skill 的拆解

• 什么逻辑该写成脚本放进 skill 的 scripts 目录，什么该留在 SKILL.md 正文里？Which logic belongs in a skill's scripts directory and which belongs in the SKILL.md body?

  国内高频海外高频基础#agent-skills#scripts

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

  1. 这题在考分工感。答「复杂的写脚本」等于没答，因为复杂是个没有边界的词。面试官要听的是可判定的信号。
  2. 给三条信号，命中任意一条就写脚本：同一段逻辑在执行轨迹里被重新发明了第三次；结果必须逐字一致（校验、格式转换、哈希）；一条命令复杂到第一次很难敲对。
  3. 把第二条展开成分工原则，这是本题的核心句：**确定性任务交给代码，判断性任务留给模型**。让模型「按指令做」意味着每次都有偏移的可能，让它跑脚本意味着结果确定。
  4. 再给反面：只是调一个现成工具加两三个参数，直接在正文写这条命令就行，不必建 scripts 目录。很多生态有免安装的一次性运行方式，用它们时**版本必须钉死**，否则上游一发版你的 skill 行为就变了。
  5. 补一条成本视角：脚本是长期资产，要维护、要跟模板同步、要有人看得懂。三条信号一条都不命中的时候，写正文更划算。
  6. 可预期的追问是「怎么发现模型在重新发明轮子」。答案是读执行轨迹而不是只看最终产出——同一个辅助函数在几次运行里反复出现，就是该沉淀成脚本的信号。

  How to reason about it · think before answering

  1. This tests a sense of division of labor. Saying complex logic goes in scripts says nothing, because complex has no boundary. The interviewer wants decidable signals.
  2. Give three: the same logic gets reinvented a third time across execution traces; the result must be byte-identical (validation, format conversion, hashing); or a command is complex enough to be hard to get right first try.
  3. Expand the second into the core principle: deterministic work goes to code, judgment work stays with the model. Following instructions leaves room for drift; running a script does not.
  4. Give the other side: invoking an existing tool with two or three flags belongs inline in the body. Many ecosystems offer install-free one-off runners, and versions must be pinned or an upstream release silently changes your skill's behavior.
  5. Add the cost view: a script is a long-lived asset that must be maintained and kept in sync. When none of the three signals fire, prose is cheaper.
  6. Expected follow-up: how do you notice reinvention? Read execution traces rather than final outputs; the same helper appearing across runs is the signal.

  答题要点

  • 三条信号命中任一条就写脚本：重复发明第三次、结果必须逐字一致、命令复杂到难以一次敲对。
  • 分工原则是确定性任务交给代码，判断性任务留给模型。
  • 只加两三个参数调现成工具的，直接在正文写命令，但版本要钉死。
  • 脚本是长期资产，有维护成本，三条都不命中就写正文。
  • 发现重复发明要靠读执行轨迹，不是看最终产出。

  Key points

  • Write a script when any of three fire: third reinvention, byte-identical results required, or a command hard to get right first try.
  • Deterministic work to code, judgment work to the model.
  • A tool invocation with a couple of flags stays inline, with the version pinned.
  • Scripts are long-lived assets with maintenance cost; if no signal fires, write prose.
  • Spot reinvention by reading execution traces, not final outputs.
• 给 Agent 用的命令行脚本，接口设计上和给人用的有什么不同？How does designing a command-line script for an agent differ from designing one for a human?

  国内高频海外高频进阶#agent-skills#scripts#cli-design

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

  1. 题眼是「不同」。能列出五条通用 CLI 最佳实践的人很多，能说清哪几条是因为「使用者是模型」才成立的人少。
  2. 先给根本差异：人会读文档、会试错、会凭经验猜；Agent 只能读你打印的那几行字然后决定下一步。**它的全部信息就是你的输出**。
  3. 由此推出五条。绝对不能交互，这是硬要求不是最佳实践，Agent 在非交互终端里回答不了提示，会一直挂到超时。
  4. 帮助信息就是接口文档，但要短——这段输出原样进上下文，跟别的东西抢位置，这是给人用的 CLI 完全不必考虑的约束。
  5. 错误信息决定它下一次会不会做对：写清哪一项错了、期望什么、实际是什么、可选值有哪些。**错误信息本质上是给模型的提示词**，这一句是拿分点。
  6. 剩下两条：输出结构化并把数据与诊断分流到标准输出与标准错误；输出体量要可控，因为很多 Agent 环境会静默截断超长输出。再补幂等、有意义的退出码、危险操作给预演开关。
  7. 可预期的追问是「怎么验证接口设计得好」。答案是把帮助输出和一条错误信息单独发给一个没看过这个 skill 的人，他能照着敲对改对，模型大概率也能。

  How to reason about it · think before answering

  1. The hinge is the difference. Many can list CLI best practices; few can say which ones exist specifically because the caller is a model.
  2. State the root difference: humans read docs, experiment and guess from experience; an agent has only the lines you printed before deciding the next move.
  3. From that: never prompt interactively. This is a hard requirement, not a nicety, because agents run in non-interactive shells and will hang until timeout.
  4. Help output is the interface documentation, but it must be short, since it enters the context window and competes with everything else. A human CLI never faces this constraint.
  5. Error messages decide the next attempt: say what failed, what was expected, what was received, and which values are allowed. Error messages are effectively prompts for the model.
  6. Then: structured output with data on stdout and diagnostics on stderr, and bounded output size because many harnesses truncate silently. Add idempotency, meaningful exit codes, and a dry-run flag for destructive work.
  7. Expected follow-up: how do you validate the design? Hand the help text and one error message to someone who has never seen the skill; if they can act on it, the model probably can too.

  答题要点

  • 根本差异：Agent 的全部信息就是你打印的输出，它不会读文档也不会试错。
  • 绝不能交互，否则在非交互终端里会挂到超时。
  • 帮助信息就是接口文档，但必须短，因为它原样占用上下文。
  • 错误信息要写清哪项错、期望什么、实际什么、可选值有哪些，它本质是给模型的提示词。
  • 结构化输出并分流标准输出与标准错误，输出体量要可控，危险操作给预演开关。

  Key points

  • The agent's only information is what you printed; it does not read docs or experiment.
  • Never prompt interactively; a non-interactive shell will hang until timeout.
  • Help text is the interface documentation and must be short because it consumes context.
  • Error messages must state the field, the expectation, the actual value and the allowed set; they are prompts for the model.
  • Emit structured data on stdout and diagnostics on stderr, bound output size, and offer a dry-run for destructive operations.
• skill 里带脚本会带来哪些安全风险？你会怎么限制它？另外，为什么文档处理这类任务要先规划再校验后执行？What security risks come with bundling scripts in a skill, how would you contain them, and why should document tasks follow plan, validate, then execute?

  国内高频海外高频深入#agent-skills#security#workflow-design

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

  1. 这题有两半，别只答一半。前半考安全边界，后半考流程设计，两者的共同点是「在不可逆的动作之前留一道闸门」。
  2. 安全这一半按来源、权限、输入、动作四层说。来源：第三方 skill 里的脚本就是别人的代码，装之前要读 scripts 目录，跟装一个包之前看两眼是一回事——skill 更容易被当成文档而放松警惕。
  3. 权限：预批工具要卡到命令级，写「允许 git 的只读子命令」而不是「允许任意 shell」；而且这个字段还是实验性的，各家支持不一，不要把安全性全押在它上面。
  4. 输入：脚本处理的外部文件与接口返回是不可信输入。脚本不把它当代码执行就不会被直接利用，但**脚本的输出会进模型上下文**，原样回显一大段外部内容等于把那段话讲给模型听。动作：删除覆盖发布要给预演开关或确认参数，因为 Agent 会重试。
  5. 第二半给三步流程，并强调价值全在中间那步：分析脚本产出的是真值，模型不该凭记忆猜字段；校验脚本比对计划与真值，错误信息要够模型自己改对；填充脚本才落盘。
  6. 两条设计纪律要点出来：校验脚本不改数据、填充脚本不做校验，混在一起模型就没法在计划和执行之间停下来；中间产物要落盘成文件，否则校验脚本读不到，你也没法打开看。
  7. 可预期的追问是「为什么不能边填边校验」。答案是文件系统没有事务，写了一半的文档比完全没写更麻烦——它看起来是完整的。

  How to reason about it · think before answering

  1. Two halves; answer both. Security is about boundaries, the three-step flow is about process, and both come down to putting a gate before an irreversible action.
  2. Cover security in four layers. Source: a third-party skill's scripts are someone else's code, so read the scripts directory before installing, exactly as you would skim a package. Skills invite less scrutiny because they look like documentation.
  3. Permissions: pre-approve at command granularity, allowing read-only git subcommands rather than arbitrary shell, and remember the field is experimental with uneven support, so do not rely on it alone.
  4. Input: files and API responses are untrusted. A script that does not execute them is not directly exploitable, but script output enters the model's context, so echoing a large blob of external content effectively speaks it to the model. Actions: gate delete, overwrite and publish behind a dry run or explicit flag, because agents retry.
  5. For the second half, give the three steps and stress that the value is in the middle one: analysis produces ground truth, validation compares plan against it with self-correctable errors, and only the fill step writes files.
  6. Name two disciplines: validation never mutates and fill never validates, or the model loses its pause between planning and execution; and intermediate artifacts must be written to disk so the validator can read them.
  7. Expected follow-up: why not validate while filling? Filesystems have no transactions, and a half-written document is worse than none because it looks complete.

  答题要点

  • 第三方 skill 的脚本就是别人的代码，装之前要读一遍 scripts 目录。
  • 预批工具按最小权限、卡到命令级；该字段仍是实验性的，不能全押在它上面。
  • 外部输入不可信，且脚本输出会进上下文，不要原样回显大段外部内容。
  • 三步流程的价值全在中间那步校验：分析出真值、校验给可自纠的错误、执行才落盘。
  • 校验不改数据、填充不做校验、中间产物落盘；不要边填边校验，半成品文档看起来是完整的。

  Key points

  • Third-party skill scripts are someone else's code; read the scripts directory before installing.
  • Pre-approve tools at command granularity, and do not rely on an experimental field for safety.
  • External input is untrusted, and script output enters context, so never echo large external blobs verbatim.
  • The value of the three-step flow is the middle step: ground truth, self-correctable errors, then writing.
  • Validation never mutates, fill never validates, intermediates go to disk, and never validate while writing.

D5 手写一个 skill 运行时：扫描、frontmatter 解析、注入系统提示、按需读取正文

• 如果让你自己给一个 Agent 实现 skill 支持，发现阶段和激活阶段各要做什么？为什么要分成两步？If you implemented skill support in your own agent, what happens in the discovery stage versus the activation stage, and why split them?

  国内高频海外高频进阶#agent-skills#runtime#progressive-disclosure

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

  1. 这题在考你有没有把渐进式加载当成一个可实现的机制，而不是一句口号。只复述「发现、激活、执行」三个词是不够的，要落到每一步读了什么、写进了哪里。
  2. 发现：扫描约定目录，把所有含 SKILL.md 的文件夹找出来，解析出名字与描述，拼成一份清单注入系统提示。**这一步正文一个字都不进来**，清单里只有名字、描述、位置三样。
  3. 激活：模型判断当前任务命中了某条描述，才去读那一份完整的 SKILL.md，把正文放进上下文，同时告诉它技能目录在哪、附带哪些资源文件。
  4. 分两步的理由是成本结构不对称，这是本题的核心句：**披露的成本每一轮都要付，激活的成本只付一次。** 系统提示随每次请求重发，清单每多一个字都要乘会话轮数；正文只在被激活的那一轮进上下文，之后作为历史消息留着。
  5. 由这条不对称性可以顺手解释规范里的硬约束：为什么描述有长度上限而正文没有，为什么描述必须写触发条件而不是使用说明——描述是每轮都在花钱的那一段。
  6. 可预期的追问是「位置这一项能不能省」。不能：模型要靠它知道去读哪个文件，而且它的父目录是正文里所有相对路径的解析基准。

  How to reason about it · think before answering

  1. This tests whether progressive disclosure is a mechanism you could build, not a slogan. Repeating the three stage names is not enough; say what each stage reads and where it writes.
  2. Discovery: scan the conventional directories, find every folder containing SKILL.md, parse out name and description, and assemble a catalog injected into the system prompt. No body text enters here; each entry carries only name, description and location.
  3. Activation: once the model judges that a task matches a description, read that full SKILL.md into context, along with the skill directory path and a list of bundled resource files.
  4. The reason for the split is an asymmetry in cost: disclosure is paid every turn, activation is paid once. The system prompt is resent with every request, so each extra character in the catalog is multiplied by the number of turns.
  5. That asymmetry also explains the spec's hard limits: descriptions are capped and bodies are not, and descriptions must state trigger conditions rather than usage instructions, because the description is the part that keeps costing money.
  6. Expected follow-up: can the location field be dropped? No. The model needs it to know which file to read, and its parent directory is the base for every relative path in the body.

  答题要点

  • 发现阶段扫描目录、解析名字与描述、拼成清单注入系统提示，正文不进来。
  • 激活阶段才读完整 SKILL.md，并附上技能目录与资源文件名清单。
  • 分两步的根据是披露每轮付费、激活只付一次这条不对称性。
  • 这条不对称性解释了描述为什么有长度上限、为什么要写触发条件而不是使用说明。
  • 清单里位置字段不能省，它既是读取目标也是相对路径的解析基准。

  Key points

  • Discovery scans directories, parses name and description, and injects a catalog into the system prompt with no body text.
  • Activation reads the full SKILL.md and adds the skill directory plus a list of bundled resource filenames.
  • The split exists because disclosure is paid every turn while activation is paid once.
  • That asymmetry explains why descriptions are length-capped and must state triggers rather than usage.
  • The location field is required: it is both the read target and the base for relative paths.
• 你的运行时解析到一份不合规范的 SKILL.md，是拒绝加载还是降级加载？另外，两个作用域里有同名 skill 时你怎么处理？When your runtime parses a SKILL.md that violates the spec, do you refuse to load it or degrade gracefully? And how do you handle a name collision across scopes?

  国内高频海外高频进阶#agent-skills#runtime#error-handling

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

  1. 两个小问共用一个立场：**运行时是给人干活的，不是校验器。** 先把这句说出来，后面两半都好答。
  2. 宽松加载这一半要给出可判定的边界，不能只说「尽量宽松」。**唯一的硬性淘汰是缺 description**——少了它这个 skill 在发现阶段没有触发面，永远不会被选中，留在清单里只是白占 token。
  3. 其余一律只告警仍然加载：名字与目录名不一致、名字用了大写或下划线、描述超过上限。它们影响质量，不影响能不能用。
  4. 举一个最常见的畸形做证据：YAML 值里没加引号的冒号会让正规解析器判整行非法，进而拒绝整个文件。正确的兜底顺序是先用完整 YAML 解析，失败了再退回按行取值，只抠出认识的那几个标量字段。
  5. 同名冲突这一半，方向不是重点，**处理方式才是**。跨客户端通行约定是项目级压过用户级，但 Claude Code 的顺序是企业级、个人级、项目级由高到低，两种都合理，关键是固定一种并保持一致。
  6. 最糟的做法是静默丢弃：用户改了项目里那份，行为一点没变，他会去怀疑缓存和保存，就是不会想到别处有个同名的。**必须留一条警告并把两个路径都打出来**，那条日志是排查这类问题的第一现场。
  7. 可预期的追问是「宽松会不会把坏 skill 放进来」。答案是这两件事的层次不同：宽松说的是格式容错，安全靠的是来源信任与工具权限，不能拿格式校验当安全边界。

  How to reason about it · think before answering

  1. Both halves share one stance: a runtime exists to get work done, not to validate. State that first.
  2. For loose loading, give a decidable boundary. The only hard rejection is a missing description: without it the skill has no trigger surface, can never be selected, and only wastes catalog tokens.
  3. Everything else warns and still loads: a name that differs from the directory, a name using capitals or underscores, an over-long description. These hurt quality but not usability.
  4. Cite the most common malformation as evidence: an unquoted colon inside a YAML value makes a strict parser reject the whole file. The right fallback order is full YAML parsing first, then a line-wise field reader that extracts only the scalar fields you know.
  5. For collisions, the direction matters less than the handling. The cross-client convention is project over user, while Claude Code orders enterprise, personal, then project. Both are defensible; pick one and stay consistent.
  6. The worst handling is silent discard. The user edits the project copy, nothing changes, and they suspect caching or a failed save rather than a same-named skill elsewhere. Always log a warning that prints both paths.
  7. Expected follow-up: does loose loading let bad skills in? These are different layers. Looseness is format tolerance; safety comes from source trust and tool permissions, not from schema validation.

  答题要点

  • 立场是运行时不是校验器，默认降级加载。
  • 唯一硬性淘汰是缺 description，因为它没有触发面、永远不会被选中。
  • 名字不一致、名字不合规、描述超长都只记诊断仍然加载。
  • 解析顺序是先完整 YAML、失败再按行取值兜底，专治值里没加引号的冒号。
  • 同名冲突要固定一种优先级并保持一致，绝不静默丢弃，警告里要带上两个路径。

  Key points

  • A runtime is not a validator; degrade by default.
  • The only hard rejection is a missing description, which leaves no trigger surface.
  • Name mismatches, invalid names and over-long descriptions warn but still load.
  • Parse with full YAML first, then fall back to line-wise field reading for unquoted colons.
  • Fix one collision priority, keep it consistent, and never discard silently: log both paths.
• skill 的正文进了上下文之后，长会话里怎么保证它不失效？激活方式上文件读取和专用工具你会选哪个？Once a skill body is in context, how do you keep it effective across a long session? And would you activate skills by file read or by a dedicated tool?

  国内高频海外高频深入#agent-skills#runtime#long-session

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

  1. 这题考的是「演示能跑」和「上线能用」之间那段距离。前半是长会话的失效模式，后半是激活机制的取舍。
  2. 长会话有两个问题。第一个是重复激活：模型忘了自己读过，第二次又选中同一个 skill，同一段指令出现两遍既浪费又容易在措辞出入时互相干扰。修法是维护一个已激活集合，命中就直接返回。
  3. 第二个问题更要命——**被压缩掉**。压缩会把早期消息换成摘要，skill 正文落在那个区间里**不会报任何错**，模型只是悄悄退回没有这个 skill 的行为。用户看到的现象是「聊到后面它又不按规范写了」，这是这套机制里最难查的一类问题。
  4. 解法是给激活出来的那条消息打一个受保护标记，压缩时整段保留，或者在压缩后重新注入一次。标记本身很简单，难的是记得给它。
  5. 后半的取舍要给判据而不是偏好。文件读取式零新增机制，任何有读文件能力的 Agent 都能立刻支持，这正是这个格式能在几十家客户端铺开的原因；代价是没有明确钩子做去重和保护，模型还可能读错路径。
  6. 专用工具式把激活变成一次可观测可拦截的调用，能在这一步做去重、权限检查、连技能目录与资源清单一起返回；代价是多一个工具定义，且要求宿主愿意开这条通路。**判据是你控不控得住宿主**：自己写 Agent 用工具式，做通用实现用文件读取式。
  7. 可预期的追问是「资源文件要不要在激活时一起读进来」。不要，只列文件名。三阶段的全部价值就在于第三阶段大多数时候不会发生。

  How to reason about it · think before answering

  1. This is about the gap between a working demo and something you can ship. The first half is long-session failure modes, the second is the activation mechanism trade-off.
  2. Two long-session problems. Duplicate activation: the model forgets it already read the skill and selects it again, so the same instructions appear twice, wasting tokens and creating conflicts where the wording differs. Fix it with a set of already-activated names.
  3. The worse problem is compaction. Summarizing early messages can drop the skill body, and nothing errors: the model quietly reverts to its behavior without the skill. Users report that it stopped following the convention later in the conversation, and it is the hardest failure here to diagnose.
  4. The fix is to mark the activated message as protected so compaction preserves it, or to re-inject it afterward. The marker is trivial; remembering to set it is not.
  5. For the second half give criteria, not a preference. File-read activation adds no new mechanism, so any agent that can read files supports skills immediately, which is why the format spread across dozens of clients. The cost is no clean hook for dedup or protection, and the model can read the wrong path.
  6. A dedicated tool turns activation into an observable, interceptable call where you can dedupe, check permissions, and return the skill directory and resource list together. The cost is another tool definition and host cooperation. The criterion is whether you control the host.
  7. Expected follow-up: should resource files be read during activation? No, list filenames only. The value of three stages is that the third usually never happens.

  答题要点

  • 重复激活要靠已激活集合去重，否则同一段指令会出现两遍并互相干扰。
  • 压缩掉 skill 正文不会报错，模型只会悄悄退回原行为，是最难查的失效。
  • 激活出来的消息要打受保护标记，压缩时保留或事后重新注入。
  • 文件读取式零新增机制、兼容性最好，但没有去重与保护的钩子。
  • 专用工具式可观测可拦截，判据是你控不控得住宿主；两者都只列资源文件名，不预读内容。

  Key points

  • Dedupe with a set of activated skills or the same instructions appear twice and conflict.
  • Losing a skill body to compaction raises no error; the model silently reverts, which is the hardest failure to spot.
  • Mark the activated message as compaction-protected, or re-inject after compaction.
  • File-read activation adds no mechanism and has the best compatibility but offers no hook for dedup or protection.
  • A dedicated tool is observable and interceptable; choose by whether you control the host, and in both cases list resource filenames without reading them.

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

• 函数调用、MCP 和 Skills 三者的关系是什么？什么时候用哪个？How do function calling, MCP and Agent Skills relate, and when do you use which?

  国内高频海外高频进阶#agent-skills#mcp#tool-calling#architecture

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

  1. 这是本课最高频的一题。答错的典型是把三者摆成竞争关系，说「Skills 比 MCP 更轻量所以更好」——它们解决的根本不是同一个问题。
  2. 先给一句能背下来的分工：**MCP 管接线，Skills 管经验**，而函数调用是接线之前那根最短的线。
  3. 再落到缺口上。函数调用与 MCP 补的是**能力**：模型本来读不到你的数据库、发不出工单，给它工具它就能了。Skills 补的是**经验**：模型本来就会写提交信息，只是不知道你们这儿的格式。能力的缺口用工具补，经验的缺口用技能补。
  4. 然后给两条对比里最有信息量的差异。第一，上下文成本：工具定义每一轮都要重发，而 skill 每轮只有名字与描述，正文按需加载。第二，装不上时的降级：工具与协议是二值的，接不上就没有；**一个 skill 装不上仍然是一份人能读的 Markdown**，这正是它能在几十家客户端铺开的原因——它不要求宿主实现协议，只要求宿主会读文件。
  5. 选型给一条能当场走的流程：先分缺能力还是缺做法。缺能力时按复用面选，只有这一个应用要用就写函数调用，多个 Agent 都要用才值得做成 MCP 服务端。缺做法时按确定性选，靠指令说清楚就写进 skill 正文，结果必须逐字一致就配脚本。
  6. 最后一定要说配合。三者常态是叠着用：MCP 服务端把工单系统接进来成为工具，skill 的正文里写「先用工单查询工具拉出本周工单，再按这份模板归类」。**工具给它手，skill 给它章法。**
  7. 可预期的追问是「那什么时候不该用 MCP」。答案是只有一个应用要用、动作又只有两三个的时候——为它起一个服务端是过度设计，直接写函数调用更短。

  How to reason about it · think before answering

  1. The most common question in this course. The classic mistake is framing the three as competitors and saying skills are lighter than MCP, when they do not solve the same problem.
  2. Lead with the one-line division: MCP handles wiring, Skills handle experience, and function calling is the shortest wire of all.
  3. Then name the gaps. Function calling and MCP supply capability: the model cannot reach your database or file a ticket until you give it a tool. Skills supply experience: the model can already write a commit message, it just does not know your format.
  4. Give the two most informative contrasts. Context cost: tool definitions are resent every turn, while a skill costs only its name and description per turn with the body loaded on demand. Degradation: tools and protocols are binary, but a skill that fails to install is still readable Markdown, which is exactly why the format spread across dozens of clients. It requires the host to read files, not to implement a protocol.
  5. For selection give a runnable decision path. First separate missing capability from missing method. For capability, choose by reuse surface: one application means function calling, several agents justify an MCP server. For method, choose by determinism: instructions go in the skill body, byte-identical results go in a bundled script.
  6. Close on composition. The normal case stacks them: an MCP server exposes the ticket system as a tool, and a skill body says to pull this week's tickets with that tool and then group them by a template. Tools give hands, skills give procedure.
  7. Expected follow-up: when should you not use MCP? When only one application needs it and there are just two or three actions. Standing up a server is over-engineering.

  答题要点

  • 分工是 MCP 管接线、Skills 管经验，函数调用是接线之前最短的线。
  • 能力的缺口用工具或协议补，经验的缺口用技能补，三者不是竞争关系。
  • 工具定义每轮重发，skill 每轮只有名字与描述，正文按需加载。
  • skill 装不上仍是一份人能读的 Markdown，这是它跨客户端铺开的根本原因。
  • 选型先分缺能力还是缺做法：能力按复用面选，做法按确定性选；常态是三者叠着用。

  Key points

  • MCP is wiring, Skills are experience, function calling is the shortest wire.
  • Capability gaps need tools or a protocol; experience gaps need skills. They do not compete.
  • Tool definitions cost every turn; a skill costs only name and description until activated.
  • A skill that fails to install is still readable Markdown, which is why it spread across clients.
  • Choose by capability versus method: capability by reuse surface, method by determinism, and expect to combine all three.
• 一个团队要共享十几个 skill，你会怎么组织和分发？A team needs to share more than a dozen skills. How would you organize and distribute them?

  国内高频海外高频进阶#agent-skills#distribution#team-governance

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

  1. 这题考工程治理，不是考命令。面试官想听的是你按什么切包、按什么选分发路径，而不是背几条安装命令。
  2. 先讲组织。判据是**它们是否一起被采纳、一起被淘汰**：都围着同一套团队规范转、谁装了都得装全套，那就是一个包；一个是团队规范一个是你的个人习惯，凑在一起只会逼别人接受不想要的那半边。十几个 skill 通常应该切成三四个包，不是一个巨包也不是十几个碎包。
  3. 包的两条硬规矩要点出来：**包名就是命名空间**，包里的技能会被前缀成「包名冒号技能名」，撞名问题在这一层解决，所以包名要一次想好；组件目录必须在插件根下，不能塞进放清单的那个目录里，这是官方标出来的最常见错误。
  4. 再讲分发，给三条路径和各自的判据。随仓库走：直接放进项目目录跟着代码提交，零基础设施、评审走原来的流程，但只对这个仓库成立——**只跟某一个代码库有关的规范就选它**。
  5. 走市场：一个仓库加一份清单 JSON，成员各自添加一次，之后按需安装并自动收更新。一处维护多处生效、有版本、有升级说明，代价是要推动每个人添加一次。跨仓库的团队规范选它。**私有就是把市场仓库设成私有，没有中心服务器这回事。**
  6. 走组织托管：管理侧统一下发，不能随便关掉，覆盖率有保证、可审计，但流程重迭代慢，只有必须强制且不装就出事的规范才值得，比如安全合规那几条。
  7. 最后说三条不互斥，稳定组合是安全合规走托管、跨仓库规范走市场、项目独有的怪癖随仓库走。
  8. 可预期的追问是「十几个 skill 会不会把目录撑爆」。答案是发现阶段的开销只和描述总长有关，所以治理重点是**审描述的长度与互斥性**，而不是限制数量。

  How to reason about it · think before answering

  1. This tests governance, not commands. The interviewer wants your criteria for splitting packages and choosing a distribution path.
  2. Organization first. The criterion is whether they are adopted and retired together. Skills orbiting the same team convention belong in one package; a team convention and your personal habit do not, because bundling forces people to take the half they did not want. A dozen skills usually becomes three or four packages.
  3. Name two hard rules. The package name is the namespace, so skills are prefixed as package colon skill, which is where collisions are resolved; pick the name once. And component directories must sit at the plugin root, never inside the manifest directory, which is the documented top mistake.
  4. Then the three distribution paths with criteria. Ship with the repository: commit the skills alongside code, zero infrastructure, reviewed through the existing pull request flow, but scoped to that repository. Choose it for conventions tied to one codebase.
  5. Use a marketplace: a repository plus a catalog JSON, added once per person, then installed on demand with automatic updates. One place to maintain, real versions and upgrade notes, at the cost of getting everyone to add it. Private simply means a private repository; there is no central server.
  6. Organization-managed distribution: pushed centrally and not easily disabled, with guaranteed coverage and auditability, but heavy process and slow iteration. Reserve it for rules that must be enforced, such as security and compliance.
  7. Close by noting the three combine: compliance centrally managed, cross-repository conventions via a marketplace, project quirks with the repository.
  8. Expected follow-up: will a dozen skills blow up the catalog? Discovery cost scales with total description length, so governance means auditing description length and mutual exclusivity, not capping the count.

  答题要点

  • 切包的判据是它们是否一起被采纳、一起被淘汰，十几个通常切成三四个包。
  • 包名就是命名空间，撞名在这一层解决；组件目录必须在插件根下。
  • 只跟一个仓库有关的规范随仓库走，零基础设施但不跨仓库复用。
  • 跨仓库的团队规范走市场，市场就是一个仓库加一份清单 JSON，私有仓库即私有市场。
  • 必须强制的合规规范走组织托管，三条路径可以组合使用。

  Key points

  • Split by whether skills are adopted and retired together; a dozen usually becomes three or four packages.
  • The package name is the namespace where collisions are resolved, and component directories live at the plugin root.
  • Repository-scoped conventions ship with the repository: no infrastructure, no cross-repository reuse.
  • Cross-repository conventions go through a marketplace, which is just a repository plus a catalog JSON; private repo means private marketplace.
  • Mandatory compliance rules go through organization-managed distribution, and the three paths combine.
• 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.

D7 综合与复盘：把一套团队规范做成 skill 包并驱动子代理完成一次真实任务

• 你怎么证明一个 skill 真的有用，而不是感觉上更好？How do you prove a skill actually helps rather than just feeling better?

  国内高频海外高频深入#agent-skills#evaluation#methodology

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

  1. 这题在考评估能力，也在考诚实。答「我试了几次感觉好多了」直接出局，面试官要的是一个可复现的对照。
  2. 先给整体结构：同一批用例、两组只差一个变量、逐条判定、比通过率。**结论只有一个数：通过率差值。**
  3. 然后讲对照怎么做干净，这是本题最容易被忽略的一半。**绝对不要在你调试了两小时的那个会话里试**——那个上下文里散落着你手打的规范片段和你纠正过的措辞，模型产出得好是因为你自己把答案说了一遍。要用一个上下文干净的子代理，两份定义只差「预加载哪几个 skill」这一行，模型、工具集、提示词全部一致。
  4. 再讲用例集怎么配：正例、边界例、负例大约五比三比二。负例不能省，它测的是触发面有没有过宽，而**过宽是 skill 最常见的坏法**——少了负例，一个什么都抢的 skill 也能拿满分。
  5. 断言是全部重点。可判定的意思是不看好坏、只看事实成不成立：「类型字段取自那六个值之一」「范围等于仓库里真实存在的目录名」「首行不超过 50 个字符」是可判定的；「写得清楚」不是。一条断言只查一件事，失败时才知道是哪一条挂了。
  6. 最后补诚实这一层：有些判断写不出可靠断言，比如「这条评审意见有没有抓住真问题」。硬凑只会得到假绿，老实标成人工判定、抽查几条、并在结论里注明有几条是人工判的。**一份诚实的部分自动化评估远好过一份全绿的假评估。**
  7. 可预期的追问是「样本量这么小，结论站得住吗」。答话要坦率：小样本只能支撑「在这一批任务上」的结论，所以每个数字都要带测量条件，不要外推成通用效率提升。

  How to reason about it · think before answering

  1. This tests evaluation skill and honesty. Saying it felt better ends the answer; the interviewer wants a reproducible comparison.
  2. Give the structure first: one set of cases, two arms differing in exactly one variable, per-assertion judging, and a pass-rate comparison. The conclusion is a single number, the delta.
  3. Then explain how to keep the comparison clean, the half most people skip. Never test in the session you spent two hours debugging: that context is littered with convention snippets you typed and corrections you made, so good output reflects you, not the skill. Use a fresh subagent, with the two definitions differing only in which skills are preloaded.
  4. Describe the case mix: positive, boundary and negative roughly five to three to two. Negatives are non-negotiable because they measure whether the trigger surface is too wide, which is the most common way a skill goes wrong. Without them, a skill that grabs everything scores perfectly.
  5. Assertions are the core. Decidable means checking facts, not quality: the type field is one of six values, the scope equals a real directory in the repository, the first line is under fifty characters. Written clearly is not decidable. One assertion checks one thing so failures point somewhere.
  6. Close on honesty: some judgments resist reliable assertions, such as whether a review comment found the real problem. Forcing an assertion yields false green. Mark those as human-judged, sample a few, and say so in the conclusion.
  7. Expected follow-up: does a small sample support the claim? Be candid. A small sample supports a claim about that batch of tasks only, so every number carries its measurement conditions and is never extrapolated into a general efficiency gain.

  答题要点

  • 同一批用例、两组只差一个变量、逐条判定、比通过率差值。
  • 对照必须用上下文干净的子代理，不能在调试过的会话里试。
  • 两份子代理定义只差预加载 skill 那一行，模型、工具、提示词全部一致。
  • 用例要含负例，它测触发面有没有过宽，过宽是最常见的坏法。
  • 断言要可判定、一条只查一件事；判不了的老实标人工判定并在结论里注明。

  Key points

  • Same cases, two arms differing in one variable, judged per assertion, compared by pass rate.
  • The comparison needs a context-clean subagent, never the session you debugged in.
  • The two subagent definitions differ only in preloaded skills; model, tools and prompt are identical.
  • Include negative cases: they measure an over-wide trigger surface, the most common failure.
  • Assertions must be decidable and single-purpose; mark human-judged cases honestly in the conclusion.
• 一份三十页的团队规范文档要拆成几个 skill，按什么切？How many skills should a thirty-page team convention document become, and how do you split it?

  国内高频海外高频进阶#agent-skills#design#decomposition

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

  1. 这题看着开放，其实有明确的对错。答「按章节切」几乎必错，能说清为什么错才是拿分点。
  2. 先给错的那条：**章节结构是为人的阅读顺序服务的**，通常从概念讲到细节；而 skill 的边界必须为触发场景服务——模型是在「用户刚说了一句话」这个时刻决定要不要翻开它。这两种结构几乎从不重合。
  3. 然后给正确的三步。第一步通读文档，只记「什么时候有人会用到这一段」，记场景不记内容，三十页通常能压出十来个场景。
  4. 第二步把场景按**同一个时刻**聚类。提交信息的格式、类型的取值、正文写什么，可能分散在三章里，但都在「我要提交了」这一刻被用到，它们是一个 skill；同一章里的「怎么写提交信息」和「怎么拆提交」是两个时刻，要拆开。
  5. 第三步为每个聚类写一句描述并检查互斥：各写三句会触发的话、两句形似但不该触发的话，跑一遍看有没有互相抢。**抢了说明聚类没聚干净，回第二步。**
  6. 还要主动说一件面试官爱追问的事：**文档里有一大半内容不该进任何 skill**。背景、沿革、当初为什么这么定，对人有价值，对模型是纯负担。判据仍是「不写这条，模型会不会做错」。三十页压成三四百行是正常的。
  7. 最后补一类特殊内容：确定性的规则（类型只能是这六个、版本号必须匹配某个格式）更适合沉淀成校验脚本，正文只留一句「写完跑一次校验」。
  8. 可预期的追问是「到底该切几个」。答案是数量由聚类结果决定而不是先定，但如果切出七八个还互相抢，通常是场景记得太细了；如果只切出一个，说明你还是按文档整体在想。

  How to reason about it · think before answering

  1. It sounds open-ended but has a clear wrong answer. Splitting by chapter is almost always wrong, and explaining why is where the points are.
  2. Chapter structure serves a human reading order, usually concept then detail. A skill boundary must serve the trigger moment, because the model decides whether to open it right after the user speaks. The two structures rarely coincide.
  3. Give three steps. First, read the document recording only when someone would need each passage. Record situations, not content; thirty pages usually yields a dozen situations.
  4. Second, cluster situations by shared moment. Commit message format, allowed types and body content may sit in three chapters but all apply at the moment of committing, so they are one skill. Writing a commit message and splitting commits share a chapter but are two moments, so they split.
  5. Third, write one description per cluster and test mutual exclusivity with three triggering phrases and two near-miss non-triggers each. If they compete, the clustering is not clean; go back to step two.
  6. Raise something interviewers probe: most of the document belongs in no skill. Background and history matter to people and are pure overhead for a model. The test remains whether omitting a line would make the model get it wrong. Thirty pages compressing to a few hundred lines is normal.
  7. Add the special case: deterministic rules such as an allowed type set or a version format belong in a validation script, leaving the body to say run the validator.
  8. Expected follow-up: how many exactly? The count follows the clustering. Seven or eight that still compete usually means the situations were recorded too finely; exactly one means you were still thinking about the document as a whole.

  答题要点

  • 不能按章节切，章节服务人的阅读顺序，skill 边界服务触发时刻。
  • 三步：只记使用场景、按同一个时刻聚类、写描述并用正负例查互斥。
  • 互相抢说明聚类没聚干净，要退回重聚，不是改描述糊过去。
  • 文档里一大半内容不进任何 skill，判据是不写这条模型会不会做错。
  • 确定性规则沉淀成校验脚本，正文只留一句跑校验。

  Key points

  • Do not split by chapter: chapters serve reading order, skill boundaries serve trigger moments.
  • Three steps: record situations, cluster by shared moment, write descriptions and test with positive and negative examples.
  • Competing descriptions mean bad clustering; go back rather than patching the wording.
  • Most of the document enters no skill; the test is whether omitting it would cause a mistake.
  • Deterministic rules become a validation script, leaving one line in the body.
• 让子代理带着 skill 去执行任务，和在主会话里执行有什么区别？What is the difference between running a task in a subagent with skills and running it in the main session?

  国内高频海外高频深入#agent-skills#subagent#evaluation

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

  1. 这题考的是上下文隔离的价值，答得浅会变成「子代理就是开个新会话」。要说清它带来的三件事，以及每一件对应什么问题。
  2. 第一件是**上下文干净**。子代理不继承主会话的对话历史，你说过什么、纠正过什么它一概不知道。这一条在做评估时是决定性的：在调试了两小时的会话里试 skill，模型产出得好往往是因为你自己在会话里把答案说了一遍，这是评估 skill 时最常见的自欺。
  3. 第二件是**能力可以精确限定**。子代理定义里能声明可用工具、模型，也能直接声明预加载哪几个 skill。做对照时两份定义只差这一行，其它完全一致——任何第二个差异都会让结论说不清是谁的功劳。
  4. 第三件是**噪音不进主会话**。翻文件、试错、跑脚本这些过程留在子代理自己的上下文里，只把结论交回来。主会话的窗口因此能留给真正要连贯推进的那条线。
  5. 还要说清代价，只说好处会显得没做过。子代理拿不到主会话的上下文，意味着**交接摘要要写清楚**，任务描述含糊时它比主会话更容易跑偏；而且它多跑一遍系统提示与技能目录，不是免费的。
  6. 补一个实现细节能显出实感：skill 进子代理有两条路，一是在定义里预加载、启动时就注入完整正文，二是让它在执行中自己发现并激活。做对照实验用预加载，因为它把变量固定住了；做真实任务用自动发现，更接近日常。
  7. 可预期的追问是「什么时候不该用子代理」。答案是任务需要跟用户来回确认、或强依赖前面几十轮的上下文时——隔离带来的干净，这时候正好是缺陷。

  How to reason about it · think before answering

  1. This tests the value of context isolation. A shallow answer reduces it to opening a new session. Name three effects and the problem each solves.
  2. First, a clean context. A subagent does not inherit the main conversation, so it knows nothing you said or corrected. This is decisive for evaluation: testing a skill in a session you debugged for two hours usually measures your own hints, the most common self-deception here.
  3. Second, precisely bounded capability. A subagent definition can declare its tools, its model, and which skills to preload. For a controlled comparison the two definitions differ only in that line, because any second difference makes the result unattributable.
  4. Third, noise stays out. File reading, trial and error and script runs live in the subagent's own context, and only the conclusion comes back, leaving the main window for the thread that must stay coherent.
  5. Name the costs too. Without the main context, the handoff prompt must be explicit, and a vague task description sends a subagent off course faster than the main session. It also pays for its own system prompt and skill catalog.
  6. An implementation detail shows real experience: skills reach a subagent either by preloading in the definition, which injects the full body at startup, or by letting it discover and activate them during execution. Use preloading for controlled comparisons and discovery for real work.
  7. Expected follow-up: when should you not use one? When the task needs back-and-forth with the user or depends heavily on dozens of earlier turns. There, isolation is the defect rather than the feature.

  答题要点

  • 子代理有独立上下文窗口，不继承主会话历史，这是做干净对照的前提。
  • 定义里能限定工具、模型与预加载的 skill，对照时两份定义只差那一行。
  • 过程噪音留在子代理里，只把结论交回主会话。
  • 代价是交接摘要必须写清楚，任务含糊时更容易跑偏，且多付一次系统提示的开销。
  • 预加载适合做对照实验，自动发现更接近真实使用；需要与用户反复确认的任务不适合隔离。

  Key points

  • A subagent has its own context window and no inherited history, which is what makes a clean comparison possible.
  • Its definition bounds tools, model and preloaded skills, so a controlled pair differs in one line.
  • Process noise stays inside the subagent; only the conclusion returns.
  • The costs are an explicit handoff prompt, more drift on vague tasks, and paying for another system prompt.
  • Preload for controlled experiments, discovery for real work, and skip isolation when the task needs user back-and-forth.