当 Agent 有 100 个 Tool 时，如何做工具分组、动态子集检索、schema 治理、监控和 meta-tool/Skill 收口？｜高频面试题解析

60 秒回答模板

如果 Agent 有 100 个 Tool，我不会把所有工具一次性暴露给模型，而会把它设计成分层工具路由系统。第一层做工具分组和能力地图：按业务域、读写类型、风险等级、输入实体、使用频率和权限边界把工具归类，例如查询类、写入类、分析类、审批类、通知类。第二层做动态子集检索：先根据用户意图、上下文实体、权限和当前任务阶段，从工具目录中召回 5 到 10 个候选工具，再让模型在这个小集合里选择，必要时用规则过滤高风险或不适用工具。第三层做 schema 治理：所有工具必须有统一命名、清晰描述、JSON schema、字段枚举、错误码、幂等标识、超时、重试和版本管理；废弃工具要下线或隐藏，避免长尾工具污染选择。第四层做监控：记录候选召回、最终选择、参数校验失败、工具成功率、延迟、成本、重试、误调用、人工纠正和按工具分布的任务成功率。第五层做 meta-tool 或 Skill 收口：把一组经常组合使用的底层工具封装成更高层能力，例如“创建工单”“查询订单并解释异常”，让模型面对稳定的业务动作，而不是 100 个原子 API。核心取舍是：原子工具多，灵活但难选；高层 Skill 少，稳定但需要设计好边界和可观测性。

考点 分层路由

难度 真实面经题

回答目标让候选人能说明大规模工具 Agent 的核心不是工具越多越好，而是通过分组、检索、schema、监控和 Skill 收口，把工具选择从不可控的长列表变成可治理的分层能力系统。

深入解析

不要把 100 个工具直接暴露给模型

工具数量过多会让模型选择空间膨胀，prompt 变长，工具描述互相干扰，近义工具容易误选，低频工具也会污染上下文。工程上应把工具选择拆成先召回候选、再精排或调用，而不是让模型在完整工具库里自由搜索。

工具分组先建立能力地图

分组维度可以包括业务域、资源对象、读写属性、风险等级、权限范围、是否有副作用、输入实体和调用频率。能力地图要能回答：这个工具解决什么任务，需要什么前置条件，会改变什么状态，失败如何处理。分组不是为了目录好看，而是为了路由、权限和监控都能复用。

动态子集检索降低选择难度

动态检索可以用关键词、embedding、标签、规则和上下文实体组合。先从用户意图、当前 state、已识别实体、会话阶段和用户权限召回候选工具，再做风险过滤和去重，最后只给模型少量高相关工具。对高风险写工具，可以要求先通过确认节点或只在特定状态下出现。

schema 治理决定工具可用性

100 个工具最容易坏在契约不一致。工具应统一命名风格、描述模板、参数 JSON schema、必填字段、枚举值、默认值、返回结构、错误码、分页、幂等键、超时和重试策略。schema 版本要可追踪，废弃字段要兼容或迁移，否则模型会学到过期接口。

工具路由要结合规则和模型

纯规则路由稳定但覆盖不足，纯模型路由灵活但容易误选。常见做法是规则先做硬约束，例如权限、风险、状态和实体类型；检索层召回候选；模型负责在候选中选择和填参；参数校验层再拦截不合法调用。这样能把自由度限制在可控范围内。

监控要贯穿候选到执行

只记录工具成功率不够，还要记录候选召回列表、模型最终选择、未选择的相似工具、参数校验失败、错误类型、延迟、重试、fallback、人工纠正和任务结果。这样才能区分是工具检索召回错、模型选择错、schema 描述错、参数抽取错，还是工具本身不稳定。

用 meta-tool 和 Skill 收口复杂流程

当多个原子工具经常按固定顺序组合时，应封装成 meta-tool 或 Skill，让 Agent 选择一个高层业务动作。Skill 内部可以处理子步骤、重试、校验和回滚，对外提供更稳定的输入输出契约。这样减少模型的步骤规划压力，也降低多工具链路中间状态暴露。

治理闭环要处理长尾和废弃工具

工具库需要生命周期管理。低频但高价值工具保留在特定 Skill 或检索标签下；低频且误调用多的工具要改描述、合并或下线；重复工具要统一入口；高失败率工具要降权或熔断。工具越多，越需要 owner、版本、质量分和使用统计，而不是只增不减。

易错点

把 100 个工具全部塞进 prompt，让模型自由选择，忽略 token 成本和误选风险。
只按业务名称粗略分组，没有考虑读写属性、权限、副作用、风险和输入实体。
动态检索只用文本相似度，不结合 state、用户权限、当前阶段和硬规则过滤。
工具 schema 各写各的，参数命名、返回结构、错误码、分页和版本都不统一。
只监控工具执行成功率，不记录候选召回、模型选择、参数校验和误调用反馈。
对高风险工具缺少确认、dry-run、幂等、审计和回滚，导致 Agent 一次误判就产生副作用。
盲目封装 meta-tool，把所有能力都藏起来，导致无法调试、无法复用，也丢失必要灵活性。
工具库只增不减，没有 owner、质量分、下线策略和重复工具治理。

面试官追问

动态子集一般召回多少工具合适？

没有固定数字，但目标是让模型选择空间足够小又不漏关键工具。常见可以控制在 5 到 10 个候选，再根据任务复杂度调整。关键是用离线评测看召回率和误选率，而不是拍脑袋定数量。

如何处理两个工具描述很相似？

先从工具目录治理入手，明确适用场景、输入对象、权限和返回差异；如果本质重复，就合并或用一个高层 Skill 收口。短期也可以在检索和路由层加互斥规则，防止相似工具同时进入候选。

高风险写工具如何防误调用？

高风险工具默认不进入普通候选，只在权限、状态、意图和实体都满足时召回；调用前要求参数校验、dry-run、用户确认或人工审批；执行后记录审计日志，并提供回滚或补偿路径。

schema 版本升级会影响 Agent 吗？

会。模型依赖工具描述和字段契约，如果字段改名、枚举变化或错误码变化没有兼容，会导致填参失败或错误处理失效。应做版本标记、兼容层、回归样本和灰度，旧 schema 下线前确认没有流量依赖。

meta-tool 会不会降低灵活性？

会有这个取舍。meta-tool 把常见流程封装得更稳定，但不适合所有临时组合任务。实践中可以保留少量高层 Skill 处理高频流程，同时让专家模式或低风险场景仍可访问原子工具。

工具路由效果怎么评测？

可以构建标注任务集，分别看候选召回率、最终工具选择准确率、参数准确率、无效调用率、任务成功率、步骤数和成本。还要分析错误归因：漏召回、误召回、选择错、填参错或工具执行失败。