Session 0011

Agent 能力分层设计

Agent 的能力不是同质的：Tool 是原子操作，Skill 是流程方法论，CLI 是现有工具。三者的选型、注册、加载和调度决定了 agent 的能力边界、token 效率和可维护性。面试考的是你能否解释"为什么这个能力做成 tool 而不是 skill"。

1. 训练目标

本页要练会：给定一个 agent 能力需求，判断应该做成 Tool、Skill 还是 CLI，并解释注册、渐进式加载、优先级调度和版本演进的工程选择。

可靠依据：Claude Code skill system / OpenAI Agents SDK tool registry / LangGraph tool node / MCP (Model Context Protocol)。本页把真实系统的能力分层设计转成面试题。

题量标准：5 个中大型深题 + 7 个知识广度题。深题用于系统设计和追问承压，广度题用于查漏补缺。

2. 五个深题

深题 01

你要给 agent 添加"代码审查"能力。做成 Tool、Skill 还是 CLI？决策依据是什么？

考察点：考能力分层的核心判断框架。面试官想看你是否理解三者的本质差异，而不只是"都能实现"。

7+ 分回答骨架：代码审查需要组合多种能力（读文件、理解语义、应用最佳实践、生成建议），不是原子操作 → 不适合做单一 Tool。审查标准需要上下文判断（不同语言、框架、团队规范不同）→ 需要模型智能决策 → 适合 Skill。但底层需要调用 CLI 工具（eslint、pylint、git diff）做静态检查 → Skill 编排 CLI。最终方案：Skill（审查流程 + 最佳实践）+ CLI（静态检查工具）+ Tool（git diff API 封装）。决策矩阵：原子操作 → Tool；流程方法论 → Skill；已有成熟工具 → CLI；复杂场景三者组合。

继续追问会衍生：衍生知识点：atomicity criterion、composition pattern、capability boundary、hybrid design。

知识展开

概念	是什么	工程落点	面试表达 / 常见坑
atomicity criterion	原子性判断标准：如果一个能力是单一动作、输入输出明确、需要确定性执行、返回结构化数据，适合做成 Tool。如果是多步骤流程、需要上下文判断、组合现有工具，适合做成 Skill。	Read/Write/Edit 是 Tool（原子文件操作）；TDD/Debugging/Code Review 是 Skill（流程方法论）。	面试表达：不是"能不能做成 tool"的问题，而是"做成 tool 是否合理"的问题。审查逻辑做成 tool 会丧失灵活性。
composition pattern	组合模式是 Skill 编排 Tool 和 CLI 完成复杂任务，而不是把所有逻辑塞进一个 tool。	Skill 定义审查流程和检查项 → 调用 Read tool 读文件 → 调用 Bash 执行 eslint → 模型综合判断 → 输出审查意见。	强回答要说"Skill 是编排层，Tool 和 CLI 是执行层，两者职责不同"。
capability boundary	能力边界是判断一个功能属于哪一层的具体标准。Tool 边界是"一次调用、一个动作"；Skill 边界是"一个完整工作流"；CLI 边界是"已有成熟工具"。	新增能力时先问：这是原子操作吗？需要模型判断吗？有现成工具吗？三个问题决定归属层。	常见坑是把所有能力都做成 Tool（丧失灵活性）或都做成 Skill（丧失确定性）。

深题 02

Skill 渐进式加载是怎么实现的？为什么不把所有 skill 内容一次性加载到 context？

考察点：考 context 效率和能力覆盖的权衡。面试官想看你是否理解"索引常驻、内容懒加载"的设计模式。

7+ 分回答骨架：渐进式加载分两层。第一层：启动时只加载 skill 索引（名称 + 一句话描述 + 触发条件），每个 skill 约 50 tokens，50 个 skill 只需 2500 tokens。第二层：模型根据用户意图和索引信息判断需要某个 skill 时，调用 Skill tool 加载完整内容（500-5000 tokens），注入当前对话上下文。不一次全加载的原因：token 浪费（50 个 skill 全加载可能 50K+ tokens，占据大量 context 预算）；启动延迟；信噪比下降（大量无关 skill 内容干扰模型判断）。核心设计：索引与内容分离、模型决策触发、加载即执行。

继续追问会衍生：衍生知识点：lazy loading、index-content separation、trigger condition、load-on-demand cost。

知识展开

概念	是什么	工程落点	面试表达 / 常见坑
lazy loading	懒加载是只加载元数据索引，完整内容按需加载。在 agent 场景中，skill 索引常驻 system prompt，完整 skill prompt 按需注入。	索引包含 skill name、description、trigger condition。完整内容通过 tool 调用获取，只在触发时消耗 token。	面试表达：这和编程中的懒加载是同一个模式 — 用最小的 context 成本覆盖最大的能力范围。
index-content separation	索引与内容分离是让模型有"知道有这个能力"的信息（索引），但不预加载"怎么用这个能力"的细节（内容）。	索引放在 system prompt 或 system-reminder 中；内容放在独立文件，通过 Read tool 或 Skill tool 读取。	强回答要说清索引的粒度选择：太少（模型不知道有这个能力）vs 太多（索引本身浪费 token）。
trigger condition	触发条件是告诉模型"什么时候该用这个 skill"的判断规则，写在索引的 description 字段中。	例如"Use when implementing any feature"（TDD skill）或"Use when encountering any bug"（debugging skill）。触发条件越精确，模型误触发越少。	常见坑是触发条件太宽泛（每个任务都触发），导致 skill 加载频率过高，token 浪费。

深题 03

Agent 有 50 个 Tool 和 30 个 Skill，如何设计能力注册和发现机制，避免模型选错或漏选？

考察点：考能力管理不只是"注册所有工具"。面试官想看你是否理解能力膨胀后的选择困难和分组策略。

7+ 分回答骨架：能力膨胀会导致三个问题：Tool description 过长占 token（50 个工具 × 200 tokens = 10K）；模型选择准确率下降（候选越多越容易选错）；冲突和重复难以管理。解决方案：能力分组（按领域/场景分组，如文件操作组、网络组、数据库组）；动态注册（根据任务类型只注册相关工具子集）；能力优先级（高风险工具标记为需要审批，低风险工具自动执行）；描述优化（每个 tool 的 description 包含正面触发条件和反面排除条件）。Skill 同理：索引中写明 trigger condition 和 anti-trigger，模型按索引选择。

继续追问会衍生：衍生知识点：capability grouping、dynamic registration、selection accuracy、description optimization。

知识展开

概念	是什么	工程落点	面试表达 / 常见坑
capability grouping	能力分组是按领域或场景将工具和技能组织成逻辑组，减少模型的选择空间。	例如 MCP server 按服务分组（GitHub tools、Slack tools、File tools）；Claude Code 按功能分组（文件操作、搜索、执行）。	面试表达：50 个平铺工具不如 5 个分组 × 10 个工具，模型先选组再选工具，准确率更高。
dynamic registration	动态注册是根据当前任务上下文只注册相关的工具子集，而不是把所有工具都给模型。	编码任务只注册文件操作和终端工具；数据分析任务只注册数据库和可视化工具。注册集随任务阶段变化。	强回答要说"不是给得越多越好，而是给得越精准越好"。过多工具反而降低选择准确率。
description optimization	工具描述优化是让模型在有限信息下做出正确选择，包括正面触发（什么时候该用）和反面排除（什么时候不该用）。	例如 Read tool："Reads a file. Do NOT use for directories. Prefer over cat/head/tail." 正面和反面信息都有。	常见坑是只写"这个工具做什么"，不写"什么时候不该用"，导致模型在不合适场景也调用。

深题 04

多个 Skill 同时被触发时，如何决定执行顺序和优先级？

考察点：考能力调度。面试官想看你是否理解 skill 之间的依赖、冲突和优先级。

7+ 分回答骨架：Skill 调度需要处理三种情况：独立 skill（可并行执行，如 code review + test generation）；依赖 skill（必须串行，如 brainstorming → planning → implementation）；冲突 skill（互斥，如两个 skill 对同一文件有不同修改建议）。优先级规则：process skill 优先于 implementation skill（先决定"怎么做"再"做什么"）；安全 skill 优先于功能 skill（安全检查不能跳过）；用户显式请求的 skill 优先于自动触发的 skill。实现上可以用 skill 的 metadata 标注 priority、depends_on、conflicts_with 字段，调度器根据这些关系构建执行 DAG。

继续追问会衍生：衍生知识点：skill dependency、execution DAG、priority rules、conflict resolution。

知识展开

概念	是什么	工程落点	面试表达 / 常见坑
skill dependency	Skill 依赖是某些 skill 必须在其他 skill 完成后才能执行。例如 implementation skill 依赖 planning skill 的输出。	在 skill metadata 中声明 depends_on 字段；调度器确保被依赖的 skill 先执行。	面试表达：不是所有 skill 都能并行，有些有严格的先后顺序，跳过 planning 直接 implementation 会导致方案偏差。
execution DAG	执行有向无环图是 skill 调度的核心数据结构，节点是 skill，边是依赖关系，无环保证不会死循环。	调度器对 DAG 做拓扑排序，确定执行顺序；独立节点可并行执行。	强回答要说 skill 调度本质上和工作流引擎的任务调度是同一个问题。
priority rules	优先级规则决定多个 skill 冲突时谁先执行。典型规则：process > implementation，safety > feature，explicit > auto。	在 skill metadata 中声明 priority level 或 priority group；调度器按规则排序。	常见坑是所有 skill 优先级相同，导致关键流程 skill 被普通 skill 抢占。

深题 05

Tool 和 Skill 的版本如何管理？一个 tool 的 schema 变更如何不破坏现有 skill？

考察点：考能力演进。面试官想看你是否理解 API 契约变更对上下游的影响。

7+ 分回答骨架：Tool schema 变更是 breaking change 风险：新增必填字段会导致旧调用失败；删除字段会导致依赖它的 skill 报错；修改字段语义会导致静默错误。版本管理策略：语义化版本号（major.minor.patch）；向后兼容变更（新增可选字段、放宽校验）不升 major；不兼容变更必须升 major 并保留旧版本过渡期；skill 声明依赖的 tool 版本范围（如 "file-tools >=2.0 <3.0"）；灰度发布新版本 tool，监控调用成功率和 skill 兼容性。Skill 本身也需要版本管理：prompt 变更可能改变模型行为，需要 eval 验证。

继续追问会衍生：衍生知识点：schema versioning、backward compatibility、dependency range、canary release。

知识展开

概念	是什么	工程落点	面试表达 / 常见坑
schema versioning	Tool schema 版本化是像 API 版本化一样管理工具定义的变更，确保下游 skill 和 agent 不被意外破坏。	每个 tool schema 带版本号；变更类型标注为 compatible（新增可选字段）或 breaking（修改/删除字段）。	面试表达：tool schema 变更和 REST API 变更是同一个问题，需要同样的版本管理纪律。
backward compatibility	向后兼容保证旧版本的调用方在新版本下仍能正常工作。对 tool 来说，新增可选字段是兼容的，新增必填字段是不兼容的。	兼容变更直接发布；不兼容变更需要保留旧版本、发布迁移指南、设定旧版本下线时间。	强回答要说"新增必填字段是最常见的不兼容变更，需要灰度 + 迁移期 + 下线通知"。
canary release	金丝雀发布是将新版本 tool 先给少量用户使用，监控错误率和 skill 兼容性，确认无问题后再全量发布。	新版本 tool 先注册给 5% 用户或内部测试；监控 tool call 成功率、skill eval 通过率；达标后逐步放量。	常见坑是直接全量替换 tool schema，出问题后影响所有用户。

3. 七个广度题

编号	问题	准确回答
广度 01	Tool 和 Skill 的一句话区别？	Tool 是模型调用的原子操作（输入 → 执行 → 结构化输出）；Skill 是注入模型的流程方法论（指导"怎么做"，用已有工具执行）。
广度 02	为什么 Skill 不直接内联到 system prompt？	内联会浪费 token（大部分 skill 大部分时间不需要）；懒加载只消耗触发时的 token，context 效率更高。
广度 03	CLI 工具和 Tool 的区别是什么？	Tool 是 agent 运行时原生的结构化调用；CLI 是终端命令，通过 Bash tool 间接调用。CLI 输出是文本，需要模型解析；Tool 输出是结构化的。
广度 04	什么时候应该把 CLI 包装成 Tool？	当 CLI 的输出需要结构化解析、需要权限控制、需要幂等保证、或者调用频率高需要降低模型解析成本时。
广度 05	Skill 的 description 写多少合适？	足够让模型判断"该不该触发"即可，通常 1-2 句话包含触发条件和反面排除。太长浪费索引 token，太短导致误触发。
广度 06	两个 Skill 对同一问题有不同建议怎么办？	按优先级规则选择；优先级相同时由模型根据上下文判断；冲突严重时需要人工确认或 skill 元数据标注 conflicts_with。
广度 07	如何评估一个 Skill 是否有效？	对比有 skill 和无 skill 的任务完成质量（paired eval）；监控 skill 触发准确率（该触发时触发了吗）和触发后的任务成功率。

4. 知识索引

atomicity criterion

原子性判断标准：单一动作、输入输出明确、需要确定性 → Tool；多步骤、需判断、组合工具 → Skill。

composition pattern

Skill 编排 Tool 和 CLI 完成复杂任务，Skill 是编排层，Tool/CLI 是执行层。

capability boundary

能力边界：Tool = 一次调用一个动作；Skill = 一个完整工作流；CLI = 已有成熟工具。

lazy loading

懒加载：索引常驻 system prompt，完整内容按需注入，用最小 context 成本覆盖最大能力。

index-content separation

索引与内容分离：模型知道"有这个能力"但不预加载"怎么用"的细节。

trigger condition

触发条件告诉模型"什么时候该用这个 skill"，越精确误触发越少。

capability grouping

能力分组减少模型选择空间，50 个平铺工具不如 5 组 × 10 个工具。

dynamic registration

动态注册：根据任务上下文只注册相关工具子集，给得越精准越好。

description optimization

工具描述包含正面触发和反面排除，帮助模型正确选择。

skill dependency

Skill 依赖：某些 skill 必须在其他 skill 完成后才能执行。

execution DAG

执行有向无环图：节点是 skill，边是依赖，支持拓扑排序和并行执行。

priority rules

优先级规则：process > implementation，safety > feature，explicit > auto。

schema versioning

Tool schema 版本化管理变更，区分兼容和不兼容变更。

backward compatibility

向后兼容保证旧调用方在新版本下仍正常工作。

canary release

金丝雀发布：新版本先给少量用户，监控成功后再全量。

5. 巩固训练

练习	要求	自检
分层决策	给 5 个能力需求（如"数据库查询"、"日报生成"、"部署上线"、"用户画像"、"文档搜索"），分别判断做 Tool/Skill/CLI 并说明理由。	每个判断是否包含原子性、确定性、现有工具三个维度的分析。
加载策略设计	为一个有 40 个 skill 的 agent 设计渐进式加载方案，计算索引 token 预算。	是否说清索引粒度、触发条件设计、懒加载成本和全加载成本的对比。
版本变更影响	一个 tool 新增了一个必填字段，分析对现有 3 个 skill 的影响和迁移方案。	是否覆盖 breaking change 识别、兼容期设计、灰度策略和回退方案。
调度 DAG	画出 5 个 skill 的依赖关系 DAG，标注并行和串行节点，给出执行顺序。	是否正确识别依赖、冲突和独立关系；是否能说出拓扑排序结果。

6. 弱回答红线

只说"都能做，看需求"，不给出具体的判断标准和决策框架。
把渐进式加载说成"减少 prompt 长度"，不提索引-内容分离、触发条件设计和 token 效率计算。
把能力管理说成"注册所有工具就行"，不提分组、动态注册和描述优化。
不考虑 skill 之间的依赖、冲突和优先级，假设所有 skill 可以独立并行。
不讨论版本管理和兼容性，假设 tool schema 可以随意修改。

有不清楚的地方？

这节课涉及的概念较多且相互关联。如果你对某个具体场景的能力分层有疑问（比如"我这个项目里的 XX 功能应该做成 tool 还是 skill"），随时向 agent 追问。agent 可以针对你的具体项目给出分层建议。

推荐阅读：Anthropic Tool Use 官方文档 — 理解 tool 的 schema 设计、调用生命周期和最佳实践。结合 MCP (Model Context Protocol) 了解工具标准化注册和发现协议。