考察点
这道题出自字节跳动 AI Agent 岗二面，紧跟在 Agent 架构题之后，是往下钻一层的工程细节题。面试官想看的是：你是否真的把 Tool Calling 从 demo 做到了生产可用——demo 里工具调用成功率 95% 就能跑，生产上剩下 5% 的失败怎么处理才见功力。追问常往 MCP、schema 设计细节、多工具并行走。
参考答案
工具定义：schema 就是护城河
Tool Calling 的可靠性一半取决于工具描述写得好不好。我的实践是：
- 每个工具的 description 写清楚「什么时候该用、什么时候不该用」，而不只是功能说明。比如查订单工具会写「仅用于查询当前登录用户自己的订单，不要用于查询他人订单」。模型选错工具，多半是描述之间边界模糊。
- 参数用 JSON Schema 严格约束：类型、enum、pattern（比如订单号必须是
^\d{16}$）、required 都写上。模型生成参数时就有约束可依，校验层也有据可查。 - 给 few-shot 示例：在 system prompt 或工具描述里放 1-2 个正确调用示例，对参数格式复杂的工具（嵌套 JSON、时间格式）效果显著，比纯文字描述靠谱得多。
- 工具数量控制在个位数到十几个。工具太多模型的选择准确率会明显下降，超过这个量级就要做工具检索（先按语义召回 top-k 候选工具再让模型选）。
参数错误：校验 + 自愈重试
参数错误分两层处理：
第一层是确定性校验。模型的输出先过 schema 校验（类型、格式、必填），再过业务校验（日期不能是过去、金额不能为负、ID 在库里存在）。校验不过不直接报错给用户，而是把具体的校验错误信息拼回上下文让模型自己修——比如「参数 start_date 格式错误，期望 YYYY-MM-DD，收到 2026年8月」。模型拿到明确的错误反馈后修正成功率很高，一般重试 1-2 次就够，仍然失败说明模型理解不了这个任务，降级到规则兜底或转人工。
第二层是执行期错误。schema 校验过了但工具执行抛异常（库存不足、接口报业务错误码），把错误码和错误消息结构化地返回给模型作为 observation，让它决定是换参数重试、换工具、还是如实告知用户。关键是错误信息要是模型能读懂的自然语言，而不是扔一个 stack trace。
调用失败：按错误类型分流
| 失败类型 | 处理策略 |
|---|---|
| 超时、5xx、限流 | 指数退避重试（1s/2s/4s，最多 3 次），带 jitter |
| 4xx 参数类错误 | 不重试，回给模型让它修参数 |
| 工具返回空结果 | 正常分支，模型基于「无结果」生成追问或换检索词 |
| 工具不可用（降级开关） | 从候选工具列表摘除，告知模型该工具不可用 |
重试要注意幂等：查询类工具随便重试，写入类工具必须支持幂等键（idempotency key），否则网络超时后重试可能重复下单。
危险工具：隔离、确认、审计
这是生产系统和 demo 的分水岭，我按风险等级分三档：
- 只读工具（查询、检索）：默认放行，只需注意数据权限——工具内部强制带上用户身份，模型传的用户 ID 不可信，以后端 session 里的为准。
- 可逆写入（发草稿、加购物车）：放行但记录审计日志。
- 高危不可逆（支付、删除、群发消息）：三道闸。一是单独的权限 scope，Agent 默认不带这些工具的访问权，需要用户显式授权；二是 human-in-the-loop，执行前把模型组装的参数渲染成确认卡片给用户点确认，确认前的任何环节都不真正执行；三是服务端二次校验，金额上限、频率限制在工具实现里写死，不信任上游传来的任何值。
另外所有工具调用都落审计日志：谁触发、模型给的参数、最终执行参数、结果、耗时，出问题时能完整回放。
可能的追问
- 了解 MCP 吗？和自己包 Function Calling 有什么区别？ 答：MCP 把工具描述、调用协议标准化了，工具方实现一次 MCP server，各 Agent 宿主都能接，省去每个工具手写 schema 和适配代码；但权限、校验、重试这些工程问题不会因为换了协议就消失，该做的还是要做。
- 多个工具之间有依赖怎么编排？ 答：简单依赖靠模型按 ReAct 循环自己规划；依赖关系固定且复杂的（A 的输出是 B 的输入，还有分支条件），宁可用 Workflow 显式编排，模型只填参数，稳定性好得多。
- 怎么评 Tool Calling 的质量？ 答：构造带标准答案的评测集（输入 → 期望的工具+参数），离线算工具选择准确率和参数准确率；线上看调用成功率、自愈重试率、人工接管率。