Interview Bank

Agent Skills in 7 Days: Turn Experience Into Reusable Capability

D2 Writing Your First Skill: How to Write description's Trigger Words, How to Layer the Structure, How to Install It Into a Client

• How should a client resolve a name collision between a project-level and a user-level skill, and why do clients differ here?项目级和用户级的 skill 同名时该怎么处理？为什么各家客户端在这一点上会有不同的选择？

  Common in ChinaCommon overseasDeep dive#agent-skills#client-integration

  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.

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

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

  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.

  答题要点

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

D3 A Design Method: Distilling From Repeated Tasks, Checklist Style vs. Reference-Manual Style, Four Anti-Patterns, and Trigger Testing

• When optimizing a description, how do you avoid overfitting to the very queries you wrote?优化 description 的时候怎么避免过拟合到你自己写的那几条测试查询？

  Common in ChinaCommon overseasDeep dive#agent-skills#evaluation

  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.

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

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

  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 Skills With Scripts: Executable Attachments, Dependencies and Sandboxing, Cross-Platform Support, and Breaking Down Document-Handling Skills

• 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?skill 里带脚本会带来哪些安全风险？你会怎么限制它？另外，为什么文档处理这类任务要先规划再校验后执行？

  Common in ChinaCommon overseasDeep dive#agent-skills#security#workflow-design

  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.

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

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

  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.

  答题要点

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

D5 Hand-Building a Skill Runtime: Scanning, Frontmatter Parsing, Injecting the System Prompt, Reading the Body on Demand

• 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?skill 的正文进了上下文之后，长会话里怎么保证它不失效？激活方式上文件读取和专用工具你会选哪个？

  Common in ChinaCommon overseasDeep dive#agent-skills#runtime#long-session

  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.

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

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

  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.

  答题要点

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

D6 Organizing and Distributing: Plugins and Marketplaces, Versioning and Team Sharing, and the Division of Labor Between Function Calling, MCP, and Skills

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

  Common in ChinaCommon overseasDeep dive#agent-skills#versioning#distribution

  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.

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

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

  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.

  答题要点

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

D7 Capstone and Retrospective: Turning a Team's Conventions Into a Skill Pack and Driving a Subagent Through a Real Task

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

  Common in ChinaCommon overseasDeep dive#agent-skills#evaluation#methodology

  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.

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

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

  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 那一行，模型、工具、提示词全部一致。
  • 用例要含负例，它测触发面有没有过宽，过宽是最常见的坏法。
  • 断言要可判定、一条只查一件事；判不了的老实标人工判定并在结论里注明。
• What is the difference between running a task in a subagent with skills and running it in the main session?让子代理带着 skill 去执行任务，和在主会话里执行有什么区别？

  Common in ChinaCommon overseasDeep dive#agent-skills#subagent#evaluation

  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.

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

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

  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.

  答题要点

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