05 · 工具路由与 MCP 面试题¶
工具柜里同时有“查询政策”和“创建政策申请”，选错一次就可能多出一张单。发现工具像找到柜门标签，加载合同像看说明书，真正开工还得验身份；目录再聪明，也不是万能门禁卡。
配套 学习章：工具路由与 MCP，本章覆盖 Q069–Q071，从能力发现延伸到执行路径与连接授权。
Q069 大工具目录怎样做到发现、加载与执行一致？¶
优先级：P0
30–60 秒回答：
先按任务和可信身份搜索可发现目录，再加载选中工具的完整版本合同，最后才生成参数并执行校验。目录应区分用途、读写性质、权限范围和错误语义，执行仍要校验对象授权与业务条件。搜索没找到、选择错误、参数错误要分别评测；延迟进入模型上下文，也不一定等于完整定义不再随 API 请求发送。
展开详细答案、追问与案例
详细答案：
第一阶段把工具选择作为检索问题处理。目录保存稳定 ID、服务命名空间、版本、用途、输入摘要、读写性质和权限范围，先以可信身份限制可发现集合，再按任务搜索。政策条文与申请数量是不同信息需求，应分别寻找检索和聚合工具；“创建申请”即使语义相关，也不是研究摘要的必要能力。工具描述来自外部时只作为能力资料，不能用其中的命令扩大权限。
第二阶段加载完整定义，核对参数、返回字段、错误与版本，然后才准备执行。MCP 2025-11-25 的工具 schema 在未声明方言时默认采用 JSON Schema 2020-12，但服务、校验器和模型严格输出模式可能支持不同子集。升级 region 为 region_ids 时，使用兼容适配或拒绝旧定义后重载，不能依赖模型猜字段。类型通过仍要检查地区归属、查询时间与当前授权。
最后保持发现与执行可追踪。记录候选、选中版本、身份来源和实际执行合同；缓存考虑租户、权限与目录版本。Claude 的延迟加载路径仍要求请求提供完整 deferred 定义，API 再按引用展开，减少模型上下文不必然同比减少请求体。候选太少会漏工具，太多又增加选择负担，应分开测正确工具是否出现、发现后是否选对，以及参数和执行是否成功，再定位需改目录、路由还是合同。
常见追问：
- 发现了工具就能调用吗？ 不能。目录可见、工具可用、对象可访问与具体动作获准是不同条件，执行器仍按当前主体检查，不能复用管理员的发现结果扩大普通用户权限。
- schema 升级后旧调用怎么办？ 根据兼容合同适配或明确拒绝并重载，保留旧运行的版本记录。不能把字段变化与业务含义变化都交给自动重试处理。
- 路由效果差就增大候选数吗？ 先看漏召回还是误选择。若两个工具用途描述含混，应补读写性质和边界；若正确候选从未出现，再调整目录检索与候选预算。
实战案例：
四地政策研究要求条文和例外数量，初版只发现名称带“政策”的文本搜索，生成了没有真实统计的数据比较。处理时拆出文档与结构化需求，加载政策检索和申请聚合合同，不加载申请创建工具；统计明确日期、去重与撤销口径。验收用相似名字的读写工具、撤权缓存和旧 schema 三组输入，确认候选与实际执行版本可追踪，过期权限被拒绝，研究任务不会产生新申请。
常见误区：
把目录检索当授权；把 JSON 形状正确当业务有效；把某家延迟加载接口推导成所有平台都减少请求字节。
微练习：
为六个近义读写工具设计目录，并模拟权限和版本变化。验收：每次能展示候选、选择理由、加载合同和执行结果，且三类失败可分别归因。
学习与参考： 配套学习章 · Claude Tool Search · MCP 工具规范
Q070 程序化工具调用怎样节省上下文并保持调用边界？¶
优先级：P1
30–60 秒回答：
PTC 让模型生成代码，在执行环境中循环、筛选和聚合工具结果，只把必要汇总送回模型，因此可以减少中间文本和往返。底层调用与数据访问仍然发生，每个工具都要授权和计入共享预算。应区分代码运行 ID、工具尝试 ID 与业务操作 ID，按分支恢复，不把聚合成功当成全部数据齐全。
展开详细答案、追问与案例
详细答案：
先判断任务适不适合代码编排。四个地区的结构化记录可以由代码验证范围、计算数量、保留来源，再输出汇总。Claude 的应用工具 PTC 路径会在代码调用工具时暂停，应用返回结果后继续，减少中间结果进入模型上下文。这是特定执行合同，不表示底层请求被省略；若受控 SQL 已能聚合，将计算下推数据库可能比先拉全部记录更省传输。
执行层必须保留权限与数据边界。每次调用按当前主体和对象授权，代码环境的文件、网络、凭据及日志也要受控。模型最后只见合计，不能证明中间原始数据未被访问或留存。当前 Claude 文档中的 allowed_callers 是调用路径引导，不是安全边界；该产品 PTC 路径不支持 MCP connector 工具，自建适配器不能据此假定兼容，需要重新验证调用与结果合同。
可靠性由三类标识和共享预算支撑。代码运行标识关联整段执行，尝试 ID 区分每次请求，业务 ID 绑定同一写入意图。发出调用前预留调用数、并发和期限预算，避免每个分支独立认为仍有额度。权限失败应停止对应路径，限流按剩余期限退避；某地区超时只恢复该分支，并核对未知结果。输出要带已覆盖地区、缺失项和口径，不能把部分合计包装成全量统计。减少 token 的收益要与执行时延、数据量和失败恢复成本一起测量。
常见追问：
- 只传最终数值，来源可以省掉吗？ 不应省。保留来源 ID、查询范围、数据时间和缺失标记，才能复算与定位某个工具结果对最终结论的影响。
- 整个代码批次失败，直接重跑可以吗？ 先检查哪些分支已经确认。读查询也会增加负载，写调用还可能重复副作用；用保存结果和稳定业务 ID 恢复必要部分。
- PTC 一定比普通工具循环便宜吗？ 不一定。简单任务可能增加代码执行开销，传输和工具费用也未消失。比较相同任务质量下的模型输入、调用数、时间和失败成本。
实战案例：
助手用代码汇总四地申请，第二地超时，其他三地已有结果。初版重跑全部分支，并把缺失地区当零。处理时保存每地查询合同与完成状态，预算在调用前统一预留，只重试未确认分支；汇总带覆盖范围与缺失原因。验收注入限流、权限撤回与结果丢失，确认总预算不会被各分支突破，成功地区不重复处理，无权地区不会因代码入口获准，缺失数据不会变成零值进入排名。
常见误区：
把少读中间 token 当成少做底层 IO；把沙箱当数据授权；把 allowed_callers 当硬性权限控制，或把部分结果当完整成功。
微练习：
写一段明确标注的伪代码，展示预算预留、逐工具授权、三个 ID 和部分结果。验收：第二分支超时后不会重做全部工作，输出能说明缺失如何限制结论。
学习与参考： 配套学习章 · Claude Programmatic Tool Calling
Q071 MCP 授权、业务 ACL 与 A2A 任务合同怎样区分？¶
优先级：P0
30–60 秒回答：
MCP 的 HTTP 授权保护连接到受限服务，令牌应校验发行者、有效期和目标资源，业务对象 ACL 仍由服务端执行。代理不能把别的服务令牌直接透传，也要防止复用上游同意替未经授权客户端行动。A2A 提供远程 Agent 的消息与任务合同，可以与 MCP 组合；任务被接受不代表内部所有工具读取已经获准。
展开详细答案、追问与案例
详细答案：
先区分连接主体和业务对象。MCP 的授权规范针对 HTTP 传输描述授权流程，stdio 的凭据来源和部署边界不同。受保护服务应检查 token 的发行者、有效期和 audience 等目标约束，不能因为签名有效就让它访问任意资源。用户能连接政策服务，也不代表有权读取该服务里的全部租户文档；模型参数中的租户名不能代替服务端从可信身份获得的权限范围。
再分析代理成为 confused deputy 的路径。MCP 安全实践中的 OAuth 代理案例涉及共享上游 client ID、下游动态注册、上游同意状态复用，以及代理缺少对具体下游客户端的同意检查。用户曾登录上游，不等于同意每个新客户端借代理行动。应绑定具体客户端与 scope，严格校验重定向和流程状态；拒绝接受并向下游透传并非明确签发给本 MCP 服务的 token，避免绕过受众、审计和控制边界。
A2A 与 MCP 处于可组合的交互位置。前者描述远程 Agent 的发现、消息和任务状态，后者提供工具及上下文访问合同；被委派的研究 Agent 内部仍可调用 MCP。分别保留远程任务 ID、工具调用 ID 与业务操作 ID，明确身份如何受限传递。任务接受不等于证据读取获准，任务取消也不撤销已发生动作。工程取舍是跨服务互操作更方便，但身份、结果状态与恢复边界也更长，不能用一个协议名替代整条授权设计。
常见追问：
- OAuth 成功为什么还会越权？ OAuth 说明某种授权关系，不自动落实每个对象的租户与业务条件。若服务用高权限凭据执行且不检查对象范围，连接合法仍可能读取错误数据。
- 为何不能直接转发客户端 token？ 服务可能不是 token 的目标受众，下游语义也不同。应按各资源的授权合同取得并使用正确凭据，不能用透传绕过校验。
- A2A 能完全替代 MCP 吗？ 不能仅按名字判断。任务交接和工具访问解决不同合同，可以组合；具体系统仍需定义权限、产物和取消语义，不把“都是 Agent 协议”当等价证明。
实战案例：
研究助手把子任务交给远程政策 Agent，对方经代理连接第三方库。初版代理只检查用户曾登录，上游同意被新客户端复用，且工具接受模型填写的租户。处理时增加按下游客户端与范围的同意绑定、token 目标校验，并从可信主体执行文档 ACL。验收用错误 audience、未获同意客户端、越租户对象和合法请求，分别确认拒绝原因与正常路径；远程任务日志还能关联到实际工具调用，任务状态不会伪装成读取授权。
常见误区：
认为 token 有效就适用于所有服务；把一次登录当永久同意；把 MCP、A2A 当同义词，或把任务取消等同于外部副作用回滚。
微练习：
画客户端、MCP 代理、上游 API 和远程 Agent 的信任边界。验收：标出每个 token 的受众、每次对象授权的位置，以及任务 ID、调用 ID 与操作 ID 的对应关系。