Agent 工具调用面试：参数校验、重试与执行恢复

Function Calling 是模型根据用户问题和工具定义，生成工具名称及结构化参数，再由应用执行工具、把结果交回模型的过程。完整流程可以分成五步：提供工具定义、模型生成调用、应用校验并执行、按调用标识回填结果、模型继续判断或回答。

例如用户问北京天气，应用把天气工具的用途和城市参数说明发给模型。模型提出查询北京的调用，应用实际请求天气服务，再把查询结果关联到这次调用交回模型，模型才据此组织回答。工具定义不代表函数已经执行；一次任务也可能不调用工具，或者连续调用多轮。

可靠的工具调用需要把工具定义、参数校验、受控执行和结果反馈连成闭环。模型根据上下文提出调用，应用负责验证、执行，并把真实结果交回模型。

1. 定义清楚：说明工具用途、适用条件、输入字段和返回内容，让模型知道何时该用、需要提供什么。
2. 校验参数：既检查类型、必填项等结构，也核对对象、时间和参数来源。凭证、用户身份和权限范围由应用提供与检查。
3. 受控执行：只调用允许的工具，设置超时与调用上限，按原因决定补问、有限重试或停止。下单等写操作超时后，要先确认执行状态，或使用服务端支持的幂等机制，避免重复操作。
4. 反馈并确认结果：成功返回真实数据，失败返回具体原因和可修正的信息，再检查结果是否满足任务。参数生成成功、HTTP 返回成功，都不等于任务完成。

例如用户问“这里明天会下雨吗”，系统却只有即时天气工具，就要先澄清城市，并说明当前工具不提供明天预报；即使生成了合法的北京参数，也还没有回答用户的问题。

我会把工具选择拆成 权限与可用性过滤、候选召回、重排、完整定义加载、执行校验。工具注册表保存全部能力，但每一轮只把当前任务需要的少量工具定义交给模型；没有召回到正确工具时，再有界地扩大搜索范围。

1. 先缩小合法范围：依据调用者、租户、环境权限和服务状态，确定当前可用工具集合，不能让模型靠提示词自觉排除越权工具。
2. 按当前步骤召回：结合用户目标、任务阶段和上一步结果，按能力名称、关键词、语义和业务标签检索，分类允许重叠。
3. 区分相似能力并重排：比较适用条件、必需输入、读写性质和输出能力，选出能支持当前步骤的候选。
4. 按需加载完整 Schema：候选摘要用于找工具，真正生成调用前要提供完整参数约束，再让模型选择并构造参数。
5. 由执行层再次校验：核对工具身份、当前版本、参数、资源归属和业务状态。检索到一个工具、能看到它的描述，都不等于获得调用授权。

候选数 K、路由层数和是否需要独立重排，要通过召回质量、任务成功率、Token 与延迟预算确定，没有一个适用于所有模型和工具集的“最优工具数量”。

校验 Agent 的确定性结果，要先把需求写成可检查的条件，再用程序、测试或外部系统状态验证。这里的“确定性”指结果存在明确的判定依据，例如金额是否算对、字段是否齐全、文件能否解析、业务操作是否实际完成；不是把模型温度设为零。

1. 先定义成功条件和独立依据。 明确输入范围、业务口径、预期输出与必要状态，依据来自需求、接口契约、可信数据或已确认的测试样例。
2. 分层校验。 先检查格式和类型，再查业务约束、权限和跨字段关系；数值用独立计算核对，代码用测试验证，业务操作查询执行后的状态。
3. 在关键节点放校验器。 工具执行前校验参数和执行条件，执行后核对返回内容及状态，最终答复前检查结论是否与已验证结果一致。
4. 保留通过、失败和暂时无法确认三种结果。 失败时给出具体违反的条件；超时或状态尚未可见时继续查询或等待确认，不能把“模型说成功了”当作完成。

例如统计已支付销售额，测试数据中两笔已支付订单为 100 元和 200 元，另有取消订单 50 元，预期应为 300 元。SQL 能执行、返回数字，甚至模型解释得很完整，都不能替代这一结果校验。

先把工具调用组织成有向无环图 DAG：节点是一次调用，边表示后一个调用需要前一个调用的结果。只并行运行依赖已经满足的节点，用并发上限和超时控制资源；节点成功后保存结果，再解锁后继，需要多个输入的节点要显式等齐。

失败时先判断影响范围和是否适合重试。临时故障且调用可安全重复，可以有限重试；必要依赖失败就阻断相应下游，可选信息缺失则按业务规则降级。取消尚未开始或仍可协作取消的工作，可以减少浪费，但取消等待不代表远端操作停止，更不代表已经完成的写入被回滚。最终返回每个分支的实际状态，需要补偿的副作用单独处理。

工具持续超时，我会先停止无效重复调用，确认超时发生在哪、工具是否已经执行，以及它是不是任务必需步骤，再决定重试、替代、异步等待或结束任务。

短暂网络问题可以在剩余预算内限次重试，配合退避、抖动和并发限制；长期不可用则熔断或暂时摘除。辅助工具可以降级并说明缺失，关键证据或必需业务步骤不能直接跳过，更不能让模型编造结果。涉及下单等写操作，超时不代表没有成功，优先查执行状态，重试要沿用同一业务意图的幂等键。

如果工具本来就需要很久，应改成提交任务、返回任务标识、查询或接收结果的流程。这样能释放同步等待资源，但仍需遵守任务总时限和取消规则，不能用“异步”掩盖任务没有完成。

识别工具调用循环，不能只看“同一工具调用了几次”，而要结合动作是否重复、任务是否推进、错误是否可恢复来判断，再由执行系统设置预算和停止条件。

1. 记录调用轨迹：保留工具名、规范化参数、结果摘要、错误类型及关键任务状态，发现同一动作反复出现或多个动作来回切换。
2. 检查实际进展：是否获得新证据、完成子任务或改变业务状态。返回文本变长、调用成功，都不一定代表推进了目标。
3. 分类处理失败：瞬时故障可以在预算内退避重试；参数错误要先修正；缺权限、明确不可恢复的错误应停止或转人工。合理轮询按接口约定等待，并设置截止时间。
4. 程序强制止损：限制单次调用、重试和整个任务的时间、次数及成本；持续无进展时切换策略、返回已有结果或交给人工，保留停止原因。

例如查询后台任务状态，重复得到“处理中”可能是正常轮询；但对不存在的任务 ID 反复请求，或不断改写同义查询却拿到相同资料，就需要处理无效循环。两者不能只凭重复次数区分。

工具幂等，是让同一次业务操作被重复请求时，不产生额外副作用。它要由可信执行层和业务服务保证，提示词里写“不要重复调用”只能辅助减少误调用。

我会把链路分成五步：

1. 为一次明确的业务意图生成稳定的 action_id 或幂等键，同一操作的模型重试、网络重试和恢复执行都复用它。
2. 执行前校验身份、资源、参数和有效授权，保存规范化参数摘要；同键但参数不同则拒绝。
3. 在服务端用唯一约束或条件写入原子地登记并抢占执行，记录处理中、成功、确定失败和结果未知等状态。
4. 成功的重复请求返回已有回执；处理中的请求返回状态或等待。调用下游写接口时继续使用其支持的幂等标识。
5. 超时或崩溃后先确认业务结果；结果未知时查询或对账，不能另生成新键盲目重做。

例如一次创建工单请求，即使模型再次发出相同调用，也应返回同一张工单。用户明确要再创建一张相同内容的工单，则是新的业务意图，应使用新的操作标识。

我会先判断失败属于哪一类、结果是否足够、重试是否安全，再决定重试、修正输入、切备用路径，还是返回部分结果或停止。

网络抖动、短期限流等瞬时故障可以在总预算内有限重试，使用退避和抖动；参数错误要带着具体反馈修正，缺少必要信息就补齐，权限或业务拒绝不能靠原请求反复重跑。

**空数据不一定是异常。**确实没有记录、查询条件不合适、解析失败或上游服务故障，要分别识别。下游是否继续则取决于任务成功条件：可选资料缺失可以标注后降级，关键证据或必需输入缺失就不能继续硬生成。

Agent 中断后能继续，前提是把执行进度保存到可靠存储，并知道哪些动作可以重放。我会这样设计：

1. 用稳定的任务或会话 ID 关联状态，在可恢复步骤边界保存检查点，包括目标、已确认参数、已完成结果、待执行步骤和必要的工具回执。
2. 下次进入时先查任务真实状态，区分后台仍在运行、等待用户输入、执行失败和已完成，避免把浏览器断连当作任务失败再启动一次。
3. 从检查点恢复待执行步骤。普通故障修复后继续；等待输入则补充对应信息。恢复可能重跑节点，所以工具调用要考虑幂等。
4. 对已经发起但结果不明的外部操作，先按业务标识查询或对账；确认结果后再推进，不能统一“再执行一次”。权限和已确认的操作条件也要仍然有效。

在 LangGraph 中通常由 checkpointer 保存图状态，并用同一个 thread_id 定位；需要跨进程重启恢复时，要使用数据库等持久化后端，InMemorySaver 只能在当前进程内保留检查点。

我会沿工具调用链处理两件事：执行前控制权限，数据流转时最小化暴露。

模型只提出工具名和参数；宿主根据真实用户、任务授权和资源归属决定能否执行，工具及业务服务再次校验参数与状态。文件、SQL、网络等能力使用受限环境和凭证，涉及明显外部副作用时按业务风险核对具体操作，重试也要防止重复执行。

隐私保护则覆盖用户输入、工具返回、模型上下文、日志、记忆和最终输出。先只取需要的字段，再按用途删除、掩码或替换为受控标记，凭证由后端保管。不能让模型先看到完整秘密，再只在页面展示时打星号。

例如查询订单时，后端先检查订单属于当前用户，再返回状态和必要的手机号掩码；真正需要发送通知时，由受控服务使用已授权的联系方式，模型不必拿到完整号码。