工具调用
工具调用是 Agent 从“会说”变成“会做”的关键层。面试官通常会在这里判断你是否真的做过 Agent，而不是只会讲概念，因为一聊到工具选择、权限边界、失败恢复，做没做过系统很快就露出来了。
这一页建议按“闭环”去记，而不是按零散术语去背。先用短答版记住主链路，再用深答版补“为什么这样设计、边界在哪、错了会怎样”，这样你回答时更像在讲一个真实运行系统，而不是在背 API 名词。
高频题
1. Agent 是怎么决定调用哪个工具的？
题目：模型为什么知道该选文件搜索、数据库查询还是网页抓取？
面试官想听什么：你是否知道工具选择不是“模型神奇理解”，而是 schema、描述和运行时约束共同作用的结果。
短答版：模型主要是根据 prompt、工具描述和参数 schema 来判断该调用什么工具。工程上不能只依赖它“自己懂”，而要靠清晰描述、权限裁剪和反馈机制减少误选。
深答版：
展开深答版
这题的本质是解释工具选择机制，而不是神化模型。模型并不是“天然知道”该选哪个工具，它看到的是当前任务目标、系统提示、可用工具列表、每个工具的 description 和 schema，然后基于这些信息去推断哪个工具最匹配当前意图。
所以工具选择从来不是单纯的模型能力问题，它本质上也是接口设计问题。工具描述越清楚、边界越明确、参数语义越稳定，模型越容易选对；反过来，如果多个工具职责重叠、命名模糊、参数字段像内部黑话，误选就会很高。
工程上常见做法不是盲信模型，而是做工具裁剪、按场景暴露、分层组织和结果反馈。常见误区是以为换更强模型就能解决误选。你可以记成：
模型在选工具前，先读的是你设计的工具语言。追问方向：如果工具很多，为什么模型更容易选错？
2. 工具调用闭环的关键步骤是什么？
题目：从用户提问到工具结果被模型再次利用，中间发生了什么？
面试官想听什么：你是否真正理解工具调用是一个运行时闭环，而不是“一次函数调用”。
短答版：典型流程是：用户消息进入上下文，模型输出工具调用意图，运行时解析参数并执行工具，把结果标准化写回消息轨迹，再让模型基于新结果继续决策。关键不只是调用成功，而是结果能被下一轮推理消费。
深答版：
展开深答版
这题本质上是在考你有没有把 Agent 当成状态机来看。真正的工具调用闭环一般至少有五步：读取当前上下文、让模型生成工具调用意图、运行时做参数校验并执行工具、把执行结果结构化写回消息轨迹、再让模型基于新观察继续做下一步判断。
关键点不只是“工具有没有调成功”，而是结果是否被下一轮推理正确消费。工具不是替模型思考，它是给模型补一段新的外部观察，所以回写格式、状态标记和错误表达方式会直接影响下一轮决策质量。
工程上，如果结果回填太随意，模型会读不稳；如果原样全塞回去，又会抬高上下文成本并污染推理。常见误区是只关注“怎么调工具”，忽略“怎么把结果喂回来”。你可以记成：
工具调用不是一次函数执行，而是一轮状态更新。追问方向：如果工具结果格式不稳定，会导致什么问题？
3. 为什么权限系统不能只靠 prompt 约束？
题目：如果 prompt 里写“不要删文件”，是不是就够了？
面试官想听什么：你能不能把“行为建议”和“硬性约束”分开，不会把安全边界寄托在提示词上。
短答版：不够。prompt 只能影响模型倾向，不能形成硬约束。真正的安全边界必须落在运行时权限层，比如白名单、参数校验、人工确认和沙箱执行。
深答版：
展开深答版
这题的核心判断是，prompt 属于软约束，权限系统属于硬约束。prompt 只能影响模型倾向，让它“更可能”不去做危险动作，但它不能在模型误判、输入污染或工具描述混乱时形成真正的阻断。
只要涉及删除文件、执行命令、联网访问、写数据库、发消息这类高风险动作，最终裁决都应该落在运行时的权限层，而不是交给模型自觉克制。也就是说，模型可以提出动作意图，但能不能执行，要由工具层、白名单、参数校验、人工确认和沙箱共同决定。
工程上，硬约束确实会牺牲一部分灵活性，但换来可审计性和可控性，这是生产环境必须支付的成本。你可以记成：
Prompt 只能劝，权限系统才能拦。追问方向：哪些操作最值得加人工确认？
4. 工具失败时应该怎么处理？
题目：如果 API 超时、命令执行失败、参数不合法，Agent 应该怎么办？
面试官想听什么：你是否会先分类失败，再决定恢复策略，而不是所有失败都一把梭哈重试。
短答版：先区分失败类型。可重试错误按策略重试，参数错误应尽快反馈给模型或用户修正，权限错误要直接暴露边界。关键是把失败转成结构化反馈，而不是只吐一段日志。
深答版：
展开深答版
这题本质是在看你有没有恢复策略，而不是只会说“失败就重试”。工具失败至少可以分成四类：临时性失败、输入错误、权限拒绝和系统异常。不同类型的问题根因不同，恢复方式也应该不同。
临时网络问题可以有限重试，因为外部环境可能恢复；但参数错误和权限错误通常不该重试，因为这不是偶发问题，而是当前决策本身就错了。真正稳的系统会把失败变成结构化反馈，让模型知道“是参数错、权限不够，还是外部暂时挂了”，而不是只看到一坨日志。
工程上，失败处理的重点是分类、反馈和限界，不是盲目补救。常见误区是所有错误都自动重试三次，最后把成本和混乱一起放大。你可以记成：
先分失败类型，再决定恢复动作。追问方向：什么情况下重试反而会放大问题？
5. 工具系统怎么避免越做越乱？
题目：如果后面要不断加工具，怎么保证系统还可维护？
面试官想听什么：你有没有“可扩展工具平台”视角，而不是只会在 demo 里硬塞几个函数。
短答版：重点是统一注册、统一 schema、统一执行入口和统一结果回填。不要把工具能力散落在 if/else 里，先稳定数据结构，后面新增工具才不会变成复制粘贴工程。
深答版：
展开深答版
这题的核心是平台化思维。工具系统一开始可能只有几个能力，但只要真进入生产，后面一定会持续扩张。这时最重要的不是单个工具多聪明，而是整个系统有没有统一的数据结构、注册方式、执行入口和结果回填规范。
一个健康的工具系统里，工具的职责应该尽量收敛成三件事：声明自己能做什么、校验输入是否合法、返回结构化结果。不要让每个工具都偷偷带一套自己的调度逻辑、错误格式和权限判断，否则工具一多，主流程很快会被 if/else 和特判拖垮。
工程上，统一约束会让前期多写一点框架，但能极大降低后期维护和治理成本。常见误区是为了快，把工具能力散落在主流程里。你可以记成：
先稳定工具接口，再扩能力数量。追问方向：为什么“工具描述设计”本身就是系统质量的一部分？
扩展题
6. 为什么工具 schema 质量会直接影响 Agent 效果？
题目：同一个工具能力，如果 schema 写得很粗糙，会具体坏在哪？
面试官想听什么：你是否知道 schema 不只是参数校验层，还会反向影响模型理解、调用稳定性和错误恢复。
短答版：schema 质量差，模型就更容易误解参数语义、漏字段、乱填默认值，最后表现成误调用和高重试率。它不是文档细节，而是工具可用性的核心接口。
深答版：
展开深答版
这题的本质是把 schema 看成“给运行时校验的结构”，还是“给模型理解的契约”。如果字段命名含糊、枚举范围不清、必填和选填边界不明，模型在决策时就会出现歧义，后面的运行时校验只能在事后兜底。
好的 schema 要同时服务两件事：让模型更容易一次选对参数，也让运行时更容易识别错误并给出可恢复反馈。也就是说，schema 不只是程序读的，它也是模型读的接口语言。
工程上，前期把 schema 写清楚会增加一点定义成本，但能明显降低误调用、无效重试和 prompt 补丁数量。把 schema 当成“能过 JSON 校验就行”，是很典型的低估。
追问方向：字段命名、枚举设计和必填项约束，哪个最容易影响模型误判？
7. 为什么不能把所有工具都直接暴露给模型？
题目：工具越多是不是能力越强，为什么很多系统反而做按场景暴露？
面试官想听什么：你能不能从治理视角回答工具暴露问题，而不是只从“功能更多”出发。
短答版：不是越多越强。工具暴露面越大，模型选择噪声越大，越权风险和调试成本也越高，所以生产里通常按角色、任务和风险等级裁剪工具集。
深答版：
展开深答版
这题的核心判断是，工具暴露本身就是治理动作，不是简单功能开关。模型看到的候选工具越多，语义重叠越严重，选择噪声通常越大；与此同时，一旦高风险工具被无差别暴露，安全和审计压力也会立刻上来。
所以工具暴露不该只按“功能越多越强”来设计，而要按任务场景、用户权限、风险等级和执行阶段做裁剪。读操作、写操作、执行类工具也不该在同一层级被随意开放，因为它们带来的后果完全不同。
工程上，少暴露一点工具，会牺牲一点表面的“全能感”，但换来更稳定的路由和更清晰的边界。把工具目录做成应用商店，再期待模型自己治理，通常不是好策略。
追问方向：你会按哪些维度裁剪工具暴露范围？
8. 什么时候该并行调工具，什么时候必须串行？
题目：如果一个任务里要查多个外部信息，怎么判断是并行还是串行更合适？
面试官想听什么：你是否理解并行不是默认更优，而是取决于依赖关系、成本和失败语义。
短答版：彼此独立、结果只做汇总的查询适合并行；后一步依赖前一步结果、或者涉及副作用和确认链路时，就必须串行。核心不是追求快，而是先看依赖图。
深答版：
展开深答版
这题本质上是在考调度判断。并行调用的价值在于压缩总等待时间，但前提是各工具之间没有数据依赖，也不会因为同时执行放大副作用、资源争抢或权限风险。
所以判断标准不是“能不能更快”，而是“依赖图是不是允许并行”。只读查询、多源比对、互不影响的检索通常适合并行；但凡下一步参数、权限或动作要依赖上一步结果，串行才是更稳的设计。
工程上，并行能换来延迟收益，但会引入错误聚合、超时收敛和状态合并复杂度。盲目追求“能并就并”，很容易把原本清晰的决策链做成难回滚、难解释的并发补丁。
追问方向：并行调用里如果只失败一个工具，结果该怎么汇总才不误导模型？
9. 为什么外部写操作工具要强调幂等性？
题目：创建工单、发消息、扣库存这类工具，为什么要单独谈幂等而不是只谈重试？
面试官想听什么：你是否意识到 Agent 不只是读世界，还会改世界，所以副作用控制比“调用成功”更关键。
短答版：因为写操作一旦重试，就可能重复扣费、重复下单、重复发通知。幂等不是优化项，而是防止 Agent 把临时失败放大成业务事故的底线。
深答版：
展开深答版
这题的核心是把“模型可重试”和“业务可重试”分开。模型看到超时，可能会判断上一次请求没有成功；但真实世界里，那次调用也许已经生效了，如果没有幂等键或去重机制，再来一次就可能把副作用重复放大。
只读工具最多浪费成本，写操作工具则会改状态、发通知、扣库存、扣款，所以幂等不是优化项，而是底线设计。它的意义不是让系统更优雅，而是防止 Agent 把一次不确定结果变成真实业务事故。
工程上，幂等会增加一点接口复杂度，但换来的是恢复能力和可审计性。把“不要重复调用”交给模型记住，本质上不是工程方案。
追问方向：如果外部系统本身不支持幂等，你会怎么补救？
10. 工具结果回写为什么会污染后续推理？
题目：既然工具结果要给模型继续用，为什么不能把原始输出完整塞回上下文？
面试官想听什么：你是否理解结果回写不是日志转存，而是给下一轮推理准备可消费信息。
短答版：原始输出往往太长、太脏、太像系统内部噪声，直接回写会稀释真正关键信息，还可能把错误字段和无关细节带进后续决策。回写要做摘要、结构化和风险过滤。
深答版：
展开深答版
这题本质上是在谈“写回什么”比“拿到什么”更重要。工具原始结果里通常混着调试字段、供应商噪声、重复内容、低价值元数据，甚至异常堆栈。如果这些东西原样回写，模型下一轮看到的不是有用事实，而是一堆系统杂音。
所以结果回写的目标，不是把底层返回体完整存档，而是保留对下一步决策真正必要的事实、状态和失败信号。该摘要的摘要，该结构化的结构化，该过滤的过滤，重点是让下一轮推理更容易消费。
工程上，多一道提炼步骤会增加一点实现成本，但通常能显著降低上下文污染和后续误判。为了“不丢信息”而把一切都塞回去，常常是得不偿失。
追问方向：哪些工具结果适合只回写摘要，哪些必须保留原始字段？
11. 工具超时预算该怎么分配？
题目：Agent 一条链路里可能调很多工具，超时是给每个工具统一设一个值，还是按阶段分配？
面试官想听什么：你是否有整体预算意识，而不是把超时看成单个接口参数。
短答版：我一般按整条任务预算倒推，而不是每个工具拍脑袋设统一超时。不同工具的价值、稳定性和可替代性不同，预算也应该不同。
深答版：
展开深答版
这题的核心判断是，超时预算属于链路调度问题，不只是单个接口参数。用户能接受的总等待时间通常是固定的，所以你应该先定义整条链路的总预算，再把时间分给检索、执行、重试和模型推理这些阶段。
关键路径工具可以拿更多预算，可替代或低价值工具应该更早失败并触发降级。并行调用时还要考虑聚合等待策略，不能让一个慢工具把整轮决策都拖住。也就是说，超时不是平均分，而是按价值和依赖关系分。
工程上，预算收得太紧会增加误失败，放得太松又会拉高整体延迟和资源占用。给所有工具统一超时，看起来简单，实际往往既不高效，也不符合任务优先级。
追问方向：超时之后应该重试、降级还是直接暴露失败，怎么判断？
12. 核心工具不可用时，Agent 应该怎么降级？
题目：如果搜索、数据库或执行工具临时不可用，系统该直接报错，还是继续给答案？
面试官想听什么：你能不能把“兜底回答”和“假装完成”分开，知道什么场景能降级，什么场景必须停。
短答版：要按任务风险分级。低风险场景可以降级到保守回答或请求用户补充，高风险和需要外部确认的场景必须明确中止，不能编一个看起来完整的结果。
深答版：
展开深答版
这题本质上是在谈降级策略的边界。降级不是“工具坏了也继续装作完成”，而是当关键外部能力缺失时，系统怎样退回到一个仍然诚实、可控、风险可接受的模式。
对低风险的信息查询类任务，系统可以降级成保守回答、局部缓存结果或请求用户补充；但对资金、写操作、权限确认、高真实性要求的任务，如果关键工具不可用，就应该显式失败，而不是假装成功。换句话说，可降级和不可降级，取决于风险而不是体验。
工程上，降级能提升可用性，但如果没有风险分层，就容易把“不中断服务”做成“更隐蔽的错误”。最危险的不是报错，而是假装完成。
追问方向：你会怎么设计“允许降级”和“禁止降级”的判定规则？