跳到主内容Agent 有几十上百个工具时怎么选？大工具集路由怎样设计和验收 · AlgoMooc面试题 · Agent 项目面试题
Agent 有几十上百个工具时怎么选？大工具集路由怎样设计和验收
query_order_detail
list_orders
search_refund_order
权限边界被过度暴露
普通用户不需要知道管理员工具的名称与参数。即使后端最终会拒绝执行，把全部高风险 Schema 发给模型仍会增加误选和提示注入利用的空间。
工具状态不断变化
某个工具可能临时故障、正在灰度、只在测试环境可用，或版本正在迁移。静态大列表无法反映每次请求的真实可用能力。
评估无法定位
最终工具选错，可能是前置召回没把正确工具找进来，也可能是候选中模型重排错，或者参数填充错。如果没有分层 Trace，只能看到“Agent 调错工具”，很难知道应该改描述、检索、排序还是权限配置。
因此，大工具集路由的核心不是加入一个更大的模型，而是把“可不可以用”和“适不适合用”拆成可观测步骤。
第零层：先从任务域和权限缩小世界
身份与租户
当前用户、Agent 服务账号和租户允许访问哪些能力。不同租户可能使用不同数据源和工具实现，不能跨租户召回。
任务域
根据产品入口或已确认意图确定大类，例如公开资料研究、内部知识查询、订单服务、代码处理。若用户当前处在“公开研究”场景，就没有必要召回订单写入工具。
环境与版本
生产、测试和本地环境暴露的工具不同。一次运行绑定 Registry 版本，避免中途候选集合发生不可解释变化。
副作用等级
只读工具可以进入自动候选，高风险写工具需要额外条件或人工审批。某些场景可以完全禁止写工具，不让它们进入模型上下文。
健康状态
已经熔断、停用或未完成灰度的工具先排除。若一个关键工具不可用，路由层可以提供备用能力或明确无可用工具，而不是让模型反复调用失败。
这一层不依赖“语义像不像”，而依赖业务事实。先过滤权限再做语义召回，可以避免一个与用户问题高度相似但无权使用的工具占据候选首位。
第一层：从工具库召回候选
经过硬过滤后，仍可能有很多工具。此时需要能力召回，把候选缩到模型能清楚比较的范围。
工具索引应该存什么
只索引工具名和一句 description 往往不够。可以为每个工具准备一份“能力文档”，包括：能解决的问题、不能解决的问题、数据域、典型输入、返回内容、前置条件、相似工具差异、参数关键词和风险标签。
例如 search_web 的能力文档要说明它只发现公开网页线索，不返回完整正文；visit_page 要说明它需要 URL，用于抽取网页细节；search_internal_docs 要说明只检索当前租户授权文档。这样相似工具才能在检索阶段拉开距离。
关键词与标签召回
工具名、领域词、参数名和任务标签可以支持稳定的精确召回。用户明确提到“打开这个网页”时，URL 与“访问”标签能快速命中 visit_page。
关键词方式可解释、速度快，但对表达变化不够敏感。只用关键词会漏掉同义表达和隐含意图。
语义召回
把任务描述和工具能力文档编码后做相似度检索，可以覆盖不同说法。但语义相似不等于工具可执行。例如用户说“帮我退掉订单”，退款查询和退款提交都可能相似，真正使用哪一个还取决于意图确认、权限和审批。
混合召回
更稳的设计是合并关键词、标签和语义结果，再去重。具体权重与候选数量要靠评估集确定，不应该提前写一个万能值。
召回层应返回候选、分数、命中理由和过滤原因。后续选错时才能确认正确工具有没有进入候选，以及它为什么排在当前位置。
第二层：对小候选集做精细选择
召回解决“可能有哪些”，重排解决“当前最适合哪个”。
重排可以读取更完整的信息：用户目标、当前步骤、已有 Observation、候选工具的详细边界和参数要求。对于强规则场景，可以先用规则排除不满足前置条件的候选；剩余几个再交给模型比较。
模型输出应是结构化决策，包括工具名、需要的参数来源、选择理由和置信状态。更重要的是允许两个合法出口：没有合适工具；信息不足，需要向用户澄清。
若系统强迫模型必须从候选中选一个，它会在“都不合适”时挑一个最像的，造成误调用。大工具集路由不仅要提高选中率，还要培养拒绝和澄清能力。
精细选择也可以分为工具选择与参数填充分开。先确定 visit_page，再基于已知 URL 构造参数。把两步混在一次自由生成里，出错后很难区分是工具错还是参数错。
正确工具必须同时满足能力匹配、前置条件和权限，而不只是描述最相似。
一份可解释的路由结果应包含什么
可以用下面的结构记录一次路由。它是教学示例，用于说明字段边界，不代表已经上线的真实接口。
{
"task_domain": "public_research",
"registry_version": "toolset_v3",
"filtered_count": 0,
"candidates": [
{"name": "search_web", "reason": "需要发现公开资料线索"},
{"name": "visit_page", "reason": "上下文中存在待访问 URL"}
],
"decision": "visit_page",
"decision_status": "selected",
"required_approval": false
}
真实日志不一定保存完整自然语言与参数，应按隐私要求存摘要。关键是保留过滤、召回和选择三个阶段的证据。否则工具选错时，只能重新读最终 Prompt 猜原因。
工具描述怎样为路由服务
小工具集里，描述主要给模型看；大工具集里，描述还承担检索文档的作用，因此需要更清楚的结构。
每个工具至少写五类信息：能力，即它能完成什么；限制，即它不能完成什么；输入，即调用前必须已有的信息；输出，即能返回何种事实；差异，即与最相近工具怎么区分。
search_web：输入查询词，返回公开网页标题、摘要和 URL，用于发现线索；不返回网页完整正文，不适合已有 URL 的精读。
visit_page：输入公开 URL 和当前信息目标，返回相关正文片段；用于已有线索后的细节获取，不负责发现新的网页列表。
两份描述同时写清边界后，召回和重排都更稳定。若描述只有“搜索网页”和“访问网页”，用户一句“找一下这篇网页的信息”就容易混淆。
描述变更必须进入回归。它既影响向量索引，也影响模型最终选择。发布时要记录索引版本和 Schema 版本，避免新描述已经生效、旧索引仍未刷新。
多级路由会不会把系统做得太复杂
只有少量工具时，直接把允许的 Schema 发给模型最简单。工具增加但领域清楚时，先用任务域和权限过滤就可能够用。相似工具明显增多、上下文成本上升后，再加入候选召回。只有当候选内部仍难区分时，才需要更复杂重排。
每增加一层都会带来新失败：分类错会丢失整个领域，召回错会漏掉正确工具，重排错会选错候选。系统必须能让高置信规则直达，也允许低置信请求回退到更大候选或请求澄清。
设计目标不是层数最多，而是在可接受成本内把错误定位得更清楚。若一个简单规则已经可靠，就不需要为了“智能路由”再调一次模型。
权限为什么必须在路由前后各做一次
路由前过滤是为了减少暴露和误选。路由后校验是为了阻止绕过。
模型上下文可能携带旧 Schema，用户输入可能诱导模型生成未展示的工具名，候选服务也可能配置错误。最终执行网关必须根据当前身份和业务对象重新授权。任何路由分数都不能替代权限。
高风险工具还要有副作用等级。即使用户有权限，当前任务也未必允许自动执行。模型可以选择“建议修改配置”，但真正修改要进入 Dry-run、审批和幂等流程。
工具不可用时怎样退路
正确工具可能被熔断、超时或处于维护状态。路由层应区分“没有这个能力”和“能力暂时不可用”。
若有语义等价、契约兼容的备用执行器，可以由网关切换；若只有功能相近但证据质量不同的工具，要把差异返回给 Agent，不能静默当作完全等价。
没有安全替代时，系统可以返回部分结果、要求用户稍后重试、转人工或明确无法完成。不要为了保证每次都有答案，把任务路由到不相关工具。
恢复后还要观察原工具重新上线是否引发缓存和版本不一致。工具健康状态与路由索引要有更新协议，否则 Registry 已禁用，召回层仍可能持续推荐。
新工具冷启动怎么处理
新工具刚注册时没有历史调用数据，不能因为没有点击或成功记录就永远排在后面。冷启动阶段主要依赖高质量能力文档、标签、参数与相似工具差异，并把它放入一组人工设计的回归任务中验证。
灰度期间可以只向指定测试任务暴露，记录它是否进入候选、是否被正确选择、参数哪里容易错。确认基本边界后再扩大，而不是用真实用户流量替代验收。若新工具与旧工具高度重叠，需要明确替换、补充还是分流关系，否则两者会互相争夺相同候选。
工具下线也要更新索引。仅在 Registry 标记禁用，但向量库还保留旧能力文档，会让召回层持续产生无效候选。索引版本、Registry 版本和一次运行看到的工具快照应该能够对应。
路由缓存怎样避免答错
相同任务可能重复出现，路由结果可以缓存，但缓存键不能只有用户文本。身份、租户、任务阶段、Registry 版本、工具健康状态和已有 Observation 都可能改变正确候选。
更安全的缓存对象通常是候选召回，而不是最终执行决定。命中后仍要重新做权限和健康校验。高风险工具不应因为上次选中过，就在当前请求里跳过审批。工具被禁用或描述更新时，也要让旧缓存失效。
缓存收益与正确性要通过真实请求分布验证。设计阶段只定义命中条件、失效条件和观测字段，不预填节省比例或延迟数字。
选不到、无权限、缺参数和工具故障不是同一种失败，应该走不同出口。
怎样构造一套不自欺的路由评估集
由于这是设计题，没有真实大工具集时不应该写“准确率达到多少”。但可以把评估方法设计完整。
单工具明显样本
验证基础能力。用户目标与某个工具高度匹配，并具备全部参数。它们不能占评估集绝大多数，否则结果会虚高。
相似工具难例
成组构造边界相近工具，例如查询订单与查询退款、搜索网页与访问网页、内部知识与公开搜索。样本要迫使系统理解数据域、粒度和前置条件。
不应调用样本
用户只是询问概念、要求解释现有内容，或系统没有对应能力。正确结果应是直接回答、拒绝或澄清，而不是强行挑一个工具。
缺参数样本
任务需要工具，但关键信息缺失。系统应请求用户补充，而不是猜订单号、路径或目标对象。
权限冲突样本
语义上最匹配的工具无权限，另一个低风险工具可提供部分信息。验证前置过滤、最终授权与降级是否一致。
故障和版本样本
正确工具临时不可用、被禁用或 Schema 升级。系统应选择兼容备用、明确降级或停止，不得调用旧端点。
多步上下文样本
当前选择依赖前一轮工具结果。例如先 Search 再 Visit。只看用户原始问题可能选错，需要把当前 State 和已知参数带入路由。
指标应该分层看
候选召回看正确工具是否进入候选，以及候选集合是否过大。最终选择看模型是否从候选中选对。拒绝能力看无工具样本是否被强行调用。参数层看选择正确后参数是否完整。安全层看越权工具是否在召回和执行阶段被挡住。端到端再看任务是否完成、调用是否必要、失败是否可解释。
不能只报一个总准确率。若召回遗漏很多，但重排在剩余简单样本上表现很好，总分可能掩盖系统根本缺陷。每条失败要归因到权限过滤、任务域、召回、重排、参数或执行。
还要准备基线：全部工具直接给模型；只做规则过滤；规则加混合召回；再加入精排。用相同任务比较，确认新增层真正解决问题，而不是增加复杂度后只在少数样本变好。
所有数字都应来自真实运行记录。还没有实现时，只提交样本设计、标注规则、Trace 字段和通过标准，不填写预期提升。
设计合格的标志，是能证明正确工具被找回、错误工具被拒绝、失败能定位。
面试官会怎样连续追问
追问一：为什么不直接用更长上下文
长上下文只能缓解容量，不解决相似工具混淆、权限暴露、健康状态、版本和每轮成本。路由仍有必要把候选缩小并留下选择证据。
追问二：只用向量检索有什么问题
语义相似不代表可调用。它可能召回无权限、高风险、缺少前置参数或数据域错误的工具。应先硬过滤，再混合召回，并允许无合适工具。
追问三：Top K 设多少
没有通用固定值。要根据工具相似度、模型选择能力、上下文成本和召回曲线在真实评估集上确定，并按任务域或置信度动态调整。
追问四：正确工具没被召回怎么办
记录召回理由和分数，区分任务域分类错、描述缺失、关键词未覆盖还是语义索引问题。低置信时可以扩大候选或回退，但高风险工具不能绕过权限过滤。
追问五：工具很多时怎样防止描述重复
使用命名空间和能力模板，强制写数据域、前置条件、返回粒度、禁止场景和相似工具差异；发布前做描述冲突检查与难例回归。
追问六：你真的在项目里实现了吗
如果没有真实大工具集，就明确这是基于现有 Tool Registry 与 Agent loop 延伸的设计方案，当前应先完成候选索引、Trace 和评估集，再谈路由效果，不报虚构准确率。
工具上百后，面试里怎样讲路由
工具达到几十上百个后，我不会把全部 Schema 直接塞给模型，而会做分层路由。先按用户、租户、任务域、环境、副作用和健康状态做确定性过滤，保证无权工具不进入候选；再把当前目标、State 和已有 Observation 作为查询，从工具能力文档中用关键词、标签和语义检索做混合召回；对小候选集再做规则校验和模型重排，同时允许无合适工具或缺信息需要澄清。执行前网关仍会重新做权限、参数与业务校验。工具描述会写清能力、限制、前置条件、输出和相似工具差异，并与索引一起版本化。评估拆成候选召回、最终选择、拒绝、参数、安全和端到端任务，重点覆盖相似工具、无调用、权限冲突和故障工具。如果项目尚未真正达到大规模，我会把这些作为设计与验收方案，不声称已有准确率或线上规模。
声称做过大工具集路由前，先核对这些
- 是否先按身份和任务过滤，再做语义召回。
- 工具能力文档是否写清边界、前置条件和相似工具差异。
- 路由是否允许“没有合适工具”和“需要澄清”。
- 执行网关是否再次授权，路由结果不能绕过安全边界。
- Trace 是否能区分过滤、召回、重排、参数和执行错误。
- 没有真实大工具集时，是否只讲设计与验收，不编造规模和准确率。
大工具集路由要先按权限和任务逐层缩小能力空间，再让模型面对一组可解释的安全候选。把上百个名字全部交给模型猜，既难以定位召回错误，也会扩大越权暴露面。
