给 Agent 接上四个工具，并不等于它真的会做研究。
Search 适合发现候选来源，Visit 适合读取正文，Scholar 适合寻找论文元数据与学术出处，Python 适合计算和数据处理。它们看起来分工明确，实际运行时却经常被混用。
模型可能只看搜索摘要就下结论，也可能没有 URL 便直接调用 Visit；本来查官方文档的问题，它反复使用 Scholar；一个简单换算，它不用计算工具而是凭语言模型心算；工具失败后，又不停重试同一路径。
这些错误不会总表现为接口报错。很多调用在程序上成功，研究结果却没有新增可靠证据。
所以面试官问“Agent 怎样选择工具”时，真正想听的是：
工具能力怎样描述，前置条件和输出证据等级怎样建模，路由由模型还是规则决定，如何处理失败、重复和权限，以及怎样评测工具选得对不对？
四个工具解决的是四种不同问题
Search 回答“可能去哪里找”。
它通常返回标题、摘要和链接，适合发现候选来源、扩大查询词和了解信息分布。搜索摘要只能当线索，不能默认支持最终主张。
Visit 回答“这个页面正文到底说了什么”。
它需要 URL 或页面标识，还需要当前要找的目标。好的 Visit 不把整页文本原样塞回上下文，而是保留来源信息并抽取与当前问题相关的片段。
Scholar 回答“有哪些论文或学术资料值得核验”。
它适合获取题目、作者、时间、摘要和出版信息。发现论文后，关键结论仍要回到可访问原文或可靠元数据，不能把一个标题当成完整实验结论。
Python 回答“怎样确定性计算或处理结构化数据”。
它适合单位换算、统计、表格清洗和可复现计算。生产环境必须在沙箱里运行，限制模块、文件、网络、资源和执行时间，不能直接执行模型任意代码。
工具选择取决于当前缺口需要哪一种证据或处理能力，名称相似度不能代替这个判断。
工具描述是模型看到的“说明书”
模型不会自动理解后端函数。
它通常看到工具名、description 和参数 Schema，再根据这些信息生成调用。如果 description 只写“搜索工具”“网页工具”，模型很难知道什么时候应该用、什么时候不应该用。
合格说明至少包含四件事。
第一，工具做什么。例如 Search 返回候选链接与摘要，不返回完整正文。
第二，什么时候用。例如需要发现来源时使用 Search，已有 URL 并需要核对原文时使用 Visit。
第三，什么时候别用。例如不能用 Search 摘要直接支撑关键数字，不能用 Python 访问任意网络资源。
第四，输出意味着什么。例如 Scholar 返回论文线索，不代表论文结论已经被阅读全文核验。
description 会直接参与路由策略，远不只是写给程序员的注释。改动描述后，模型行为可能发生明显变化，因此它应版本化并进入回归测试。
前置条件应该由程序检查
即使模型选择了看似正确的工具，调用时机仍可能错误。
Visit 的前置条件是存在可访问 URL 或页面 ID。如果当前只有一个模糊实体名，程序应提示先 Search，而不是让 Visit 猜页面。
Python 的前置条件是任务可以转成受控计算，并且输入数据已经明确。若数据口径尚未统一，先计算只会得到精确的错误结果。
Scholar 的前置条件是问题确实需要学术来源。查询产品当前功能时，优先官方文档；研究方法和公开实验时，再使用 Scholar。
写操作或有副作用的工具还需要用户确认、权限和幂等键。当前四类研究工具大多是只读，但架构不能默认所有工具都安全。
这些条件适合写入工具策略，由程序在执行前校验。不要只在 Prompt 里说“请正确使用工具”，然后相信模型每次都记得。
工具路由应该读懂当前研究状态
同一句“查一下性能”，在不同阶段需要不同工具。
研究刚开始，系统不知道有哪些公开资料，应该先 Search。
已经得到官方基准页面，下一步应 Visit 并核对测试条件。
需要比较两组结果，但单位不同，可以把已核验数据交给 Python 统一计算。
发现一个论文名称，却没有可靠出处，可以用 Scholar 确认元数据，再访问可用原文。
因此路由输入不能只有用户原问题。它还要看到当前子任务、已有候选来源、已确认主张、信息缺口、已执行动作、工具可用状态和剩余预算。
路由器输出也不应只有工具名，还要有调用目的、参数、期望关闭的缺口和失败后的备选策略。这些属于可审计行动摘要，不需要展示模型隐式思维过程。
一次完整工具调用要经过哪些层？
第一层，研究规划器定义当前缺口。
第二层，模型或策略选择候选工具，并给出结构化参数。
第三层，策略层检查工具是否允许、前置条件是否满足、参数是否符合 Schema、是否与历史动作重复。
第四层，统一网关处理鉴权、限流、超时、缓存、日志和真实服务路由。
第五层，工具执行并返回结构化结果或可读错误。
第六层，结果处理器判断输出属于候选线索、原文证据、计算结果还是失败状态，不能全部当成同一种 Observation。
第七层，研究状态根据新增证据更新，并决定继续、换工具或结束。
模型提出调用，策略和网关负责把不安全、不合法或无意义的动作挡在执行前。
模型路由、规则路由还是混合路由？
纯模型路由灵活。
它能理解自然语言和开放任务，遇到新情况时不必预先写完所有分支。但模型可能忽略前置条件、生成不存在的工具或在相似工具之间摇摆。
纯规则路由稳定。
例如“有 URL 且要核正文就 Visit”“需要确定性计算就 Python”。它容易审计，却难覆盖开放研究中的所有表达和组合。
混合路由通常更实用。
模型负责从任务语义和当前缺口提出候选动作；规则负责权限、Schema、前置条件、去重和硬边界；执行结果再返回模型做下一步判断。
还可以对高频简单路径使用确定规则，对边界任务调用模型路由。这样既减少不必要的模型判断，也保留开放性。
路由方案不是固定答案。工具数量、模型能力、业务风险和可解释性要求都会影响选型，需要通过真实任务 Trace 验证。
Search 和 Visit 为什么最容易混淆？
搜索结果页的摘要读起来像答案，模型容易提前收口。
但摘要可能被截断、过时或缺少限定条件。关键主张，尤其是数字、版本和政策，应打开原始页面核验。
相反，只有一个宽泛问题时直接 Visit 也不合理。Visit 需要目标页面，无法替代发现候选来源。
更稳妥的链路是：Search 发现来源，按来源类型和相关性选择候选，Visit 带着当前问题读取正文，保存证据片段和来源 ID，再更新主张。
不是每个 Search 结果都必须 Visit。低风险背景信息可以少量使用摘要，但要标明证据等级；进入最终关键结论的内容需要更严格核验。
Scholar 不是“更权威的 Search”
Scholar 的价值是针对论文和学术元数据，而不是自动提供更正确答案。
论文可能是预印本，实验条件可能不适合当前系统，结论也可能被后续工作修正。
产品当前能力、版本配置和服务状态通常应看官方文档，不应为了显得专业强行找论文。
真正需要 Scholar 的场景包括：追溯方法原始出处，核对公开实验设计，寻找相关研究和版本时间。
即使找到了论文，摘要也不能替代正文中的方法、数据集和限制。工具输出要标明它提供的是元数据、摘要还是全文片段。
Python 工具为什么必须晚一点调用？
Python 能给出精确结果，也因此更容易让错误看起来可信。
两份性能数据若单位、时间窗口或样本范围不同，直接求平均没有意义。
一张表中缺失值含义不清，清洗代码运行成功也不代表处理正确。
所以计算前先完成数据来源、口径和单位核验。执行时保存输入数据 ID、代码或操作摘要、环境限制和输出，保证结果可复现。
计算结果也是派生证据。最终报告要说明它基于哪些输入和方法，不能只给一个数字引用 Python 工具本身。
沙箱还要限制执行时间、内存、文件读写、网络和危险模块。教学示例可以简化，生产系统不能直接对模型输出使用不受控执行。
工具失败后，重试还是换工具？
先分类错误。
参数错误，应根据 Schema 修正，不能原样重试。
临时网络错误，可以有限次数退避重试。
权限或页面禁止访问，应换公开来源或明确缺口，不应绕过权限。
内容为空，可能是页面动态渲染、目标错误或相关信息不存在，需要换 Visit 方式或回到 Search。
服务限流，应由网关排队、降并发或切备用服务，不能让每个 Agent 独立快速重试。
工具能力不匹配，应换工具。例如 Search 已经找到 URL，下一步要核正文，就不该继续换关键词搜索。
错误返回需要让模型看懂：错误类型、是否可重试、建议动作和已消耗预算。只抛一个堆栈，模型很难调整策略。
重复调用怎样识别？
字符串完全相同只是最简单情况。
“方案 A 最新部署方式”和“方案 A 当前如何部署”意图接近，可能命中同一来源。需要对查询规范化，并结合目标缺口判断是否真正重复。
Visit 可以按规范化 URL、页面版本和内容指纹去重。带不同追踪参数的同一页面不应重复计为新来源。
Python 调用要看输入数据和操作语义。表达不同但对同一组数据做相同计算，也属于重复。
检测到重复后不要一律禁止。来源更新、上次失败或当前需要核验不同片段时，重新访问可能合理。系统应保存重复原因和允许条件，而不是靠一个永久黑名单。
一个教学场景：调用都成功，研究却没进展
下面是教学情境，不代表真实线上 Trace。
任务要求确认某开源项目当前版本的部署限制。
第一步 Agent 使用 Search，得到官方文档和几篇博客。
第二步它再次 Search 一个近义词，仍返回相同页面。
第三步它调用 Scholar，找到一篇介绍该方法的论文，但论文不讨论当前产品部署。
第四步它根据搜索摘要直接给出限制，没有 Visit 官方文档。
从接口看，三次工具都成功。按任务看，没有一条当前版本的正文证据。
正确路由应在第一次 Search 后选择官方候选，用 Visit 带着“当前版本部署限制”抽取原文；若需要历史方法背景，再单独使用 Scholar。这个例子说明工具成功率不能代表研究进展。
工具路由怎样评测？
第一，工具能力匹配。
当前缺口需要发现来源、核正文、查论文还是做计算，所选工具是否匹配。
第二，调用时机。
工具名正确，但前置条件未满足或阶段错误，也应判为问题。
第三，参数质量。
查询是否包含关键对象和时间，Visit 是否有 URL 与目标，Python 输入是否有核验数据。
第四，证据增量。
调用后是否新增主张、来源、冲突解决或缺口关闭。返回很多文本却没有研究增量，价值有限。
第五，失败恢复。
参数错、超时、权限、空结果和限流时，系统能否选择正确的修复或降级。
第六，执行代价与安全。
观察重复调用、缓存、超时、工具预算、越权和副作用确认。
工具名准确率只是一个局部指标，还要检查阶段、参数、证据和恢复。
离线集应包括正常任务和边界任务：无 URL 的 Visit、无需论文的 Scholar、单位未对齐的 Python、同义重复查询、最新信息与缓存冲突、权限受限页面和不存在工具。
在线或回放评估要看完整轨迹。最终答案对了，可能是模型绕过错误调用猜对；最终答案错了，也可能是来源确实不存在。需要把路由、工具执行和证据生成分层归因。
工具注册表应该怎样治理？
工具名、description、Schema、权限和版本都属于产品配置，不应散落在 Prompt 和业务代码里。
注册表应记录工具所有者、适用场景、证据等级、超时、重试、缓存、敏感参数、健康状态和替代工具。
发布新版本时，用固定回归集比较工具选择和参数变化。description 的一次修改可能让模型从 Search 转向 Visit，也可能提高某个工具的误用率。
下线工具时先从候选列表移除，再处理运行中的任务和旧 Trace。不要让模型仍看到一个网关已经无法执行的工具。
对不同用户或租户，暴露的工具集合可能不同。路由器只能在当前权限允许的注册表中选择，不能先生成越权调用再等后端报错。
缓存命中后还需要重新判断吗？
需要。缓存只说明同类调用以前执行过，不说明旧结果仍适合当前任务。
同一个 Search query 在“最新发布”问题里可能必须绕过旧缓存，在稳定概念查询里则可以复用。Visit 缓存也要绑定页面版本、访问时间和权限范围，不能把另一个租户或旧版本内容直接返回。
路由器应先判断当前任务的时效要求和证据目的，再决定是否允许网关使用缓存。缓存命中后，结果仍要标明获取时间与来源状态，并进入正常证据分级。
缓存还能帮助重复检测，但不能代替它。两个不同查询命中相同页面，可能说明来源确实关键，也可能说明 Agent 一直绕圈，需要结合是否关闭了新缺口判断。
因此缓存策略、路由策略和证据新鲜度必须联动，不能由各工具独立设置一个永久规则。
面试官继续追问，怎么接？
追问一：工具 description 为什么这么重要？
它是模型理解能力、时机和边界的主要输入。描述含糊会让相似工具互相替代，因此要版本化并做路由回归。
追问二：模型和规则谁负责选工具？
模型适合理解开放语义并提出候选，规则适合检查权限、前置条件、Schema、去重和硬边界。生产系统通常采用混合路由。
追问三：Search 结果为什么不能直接当证据？
摘要可能截断、过时或缺限定条件。关键主张应 Visit 原始页面核正文，并保存来源和片段。
追问四：工具调用成功率高，为什么报告仍可能差？
调用可能选错阶段、返回重复信息或没有关闭任何缺口。要看证据增量和最终主张支持，而不只看接口状态。
追问五：怎样避免 Python 工具带来安全风险？
使用沙箱、资源和模块限制、网络与文件权限控制、超时和审计。输入数据先核验，输出保留可复现记录。
如何讲清一次工具路由决策
Deep Research 的工具路由要同时看工具能力、当前研究状态和运行边界。Search 用来发现候选，Visit 核对正文，Scholar 查论文和学术元数据，Python 做受控计算。注册表除了名称和 description，还应声明输入 Schema、证据等级、前置条件、权限、成本、超时、缓存和副作用。
我会采用混合路由：模型根据当前子任务、证据缺口和已有来源提出候选工具与参数，程序检查权限、前置条件、Schema 和重复动作，再由统一网关执行鉴权、限流、超时和日志。返回结果要区分线索、原文证据、派生计算和错误。失败时按参数、网络、权限、内容为空或限流分类，决定修参、重试、换工具、降级或停止。
验收不能只算工具名准确率。我会检查调用时机、参数质量、证据增量、重复率、失败恢复、安全边界和最终报告，并用无 URL 的 Visit、口径未对齐的 Python、同源重复 Search 等边界样本回归。每次调用都应推动一个明确研究缺口向前，工具数量多没有独立价值。
路由 Trace 能否回答这四个问题
从一次真实调用倒推当时的信息缺口、候选工具、程序拦截与证据增量，判断路由是否可解释、可复现。
- 每个工具是否明确写出能力、禁用场景、前置条件和证据等级？
- 路由是否读取当前缺口与历史动作，而不是只看用户原问题？
- 工具失败和重复调用能否分类型恢复，而不是原样循环？
- 是否能从 Trace 证明调用增加了证据，而不只是接口返回成功？
最后再检查路由决策是否可复现：同一任务使用了哪个注册表版本、当时缺什么证据、为什么允许该工具，都应能从 Trace 回查；否则即使报告正确，也无法解释下一次为何走了另一条路径。