考察点
这道题是纯工程题，面试官想确认你真做过 Agent 落地而不是跑过 demo。三个子问题对应三个层次：schema 定义决定模型「调得准不准」，失败兜底决定系统「稳不稳」，危险工具防护决定「敢不敢上线」。追问常见方向：模型老传错参数怎么办、怎么评估工具调用的成功率、MCP 之类协议怎么接入。
参考答案
Schema 定义：让模型调得准
工具 schema 是给模型看的接口文档，写得好坏直接决定调用成功率。主流做法是用 JSON Schema 描述，一个工具至少包含 name、description、parameters 三块。
几个实战要点。第一，description 是 prompt 的一部分，要写清楚这个工具干什么、什么时候该用、什么时候不该用，而不是一句「查询订单」。比如「根据订单号查询订单详情，适用于用户询问物流、金额、状态时；不支持按用户 ID 批量查」。模型选工具基本就靠这段话。
第二，参数要收着定义。能用 enum 就不用自由字符串，能用整数就不用浮点，必填参数越少越好。参数名要有自解释性，start_date 比 t1 好得多。日期格式、单位（秒还是毫秒）在 description 里写明，不然模型会自由发挥。
第三，返回结构也要设计。工具返回值会直接进上下文，别把几百行的原始 API 响应丢回去，裁剪成模型需要的字段，错误时返回结构化的错误码和可读原因，让模型能据此修正下一步。
{
"name": "query_order",
"description": "根据订单号查询订单详情。适用于用户询问物流、金额、订单状态。不支持模糊搜索。",
"parameters": {
"type": "object",
"properties": {
"order_id": {
"type": "string",
"description": "18 位数字订单号，如 202608021234567890"
}
},
"required": ["order_id"]
}
}
失败兜底：分层处理
工具调用失败是常态，设计时按三层兜。
模型层重试：参数校验失败、工具返回业务错误时，把错误信息作为 observation 喂回上下文，让模型自己修正参数重试。这利用了模型的自我修正能力，大部分参数错误这一步就能解决，但要在 prompt 里限制同一工具的重试次数（一般 2-3 次），防止死磕。
框架层重试：网络超时、HTTP 5xx 这类瞬时故障，框架做带指数退避的重试，比如 1s、2s、4s，最多三次。注意只对幂等的读操作自动重试，写操作盲目重试会产生重复下单这类事故。
降级与熔断：工具持续不可用时，要么降级到备选方案（搜索 API 挂了换另一个），要么优雅地告诉用户「该功能暂时不可用」，而不是让 Agent 在循环里空转。对第三方依赖加熔断器，错误率超阈值就短路一段时间。
危险工具防护
涉及写操作、花钱、对外触达的工具（发邮件、下单、删数据、转账），默认按危险工具处理。
- 权限白名单：Agent 会话按场景授予最小工具集，客服场景的 Agent 根本不该看到删除类工具。
- 人工审批（human-in-the-loop）：危险操作执行前暂停循环，把动作和参数展示给用户确认，确认后才放行。金额、收件人这类关键参数要明文展示。
- 参数硬校验：框架层做模型无法绕过的校验——金额上限、目标地址白名单、操作频率限制。不要信模型自己会守住边界，prompt 约束是软的，代码校验才是硬的。
- 沙箱与审计：代码执行类工具跑在隔离沙箱里，限制网络和文件系统访问；所有工具调用留审计日志，谁触发、传了什么参数、返回什么，出了问题能回放。
一句话总结设计哲学：把模型当成一个聪明但不可信的实习生——schema 写得足够清楚它才能干对，校验和审批做得足够硬它才闯不了祸。
可能的追问
追问：模型总是传错参数，怎么排查？
先拉调用日志看错误分布：参数缺失多半是 description 没写清必填约束，格式错误多半是 schema 定义太宽松（给 enum 或 pattern 收紧），语义错误（传了不该传的值）则要在 description 里补正反例。也可以在系统层加一层「参数校验失败原因」的自动反馈，让模型自我修正。
追问：工具数量很多时怎么办？
工具太多（比如上百个）全塞进上下文会稀释注意力、拉高成本。常见做法是按场景动态装载：用向量检索或意图分类先召回 top-K 相关工具，只把这批 schema 给模型；或者分层组织，先选工具组再选具体工具。
追问：了解 MCP 吗，和你自己定义 schema 什么关系？
MCP（Model Context Protocol）是 Anthropic 推的工具/资源接入协议，把「工具发现、调用、鉴权」标准化，工具方实现一次 MCP Server，各 Agent 框架都能接。它解决的是生态互通问题，但 schema 设计、失败兜底、危险防护这些工程原则不变，只是承载的协议换了。