Q1 工具描述（description）怎么写才算合格？
- 描述是写给模型的接口文档，不是给人看的注释。要素：什么时候用、什么时候不要用、参数含义、返回什么。
- 最容易漏的是边界：“查询订单”这类工具必须写清”仅支持最近 90 天”，否则模型会拿它去查历史数据然后拿到空结果。
- 有区分度的回答会提到：把”失败时怎么办”写进描述，例如”若查不到订单，请改用 XXX 工具”。
追问：工具数量到 50 个以上怎么办？（考察是否想到工具检索 / 分组 / 分层暴露）
Q2 模型给的参数不合法，怎么处理？
不能一概报错返回。分层处理：
| 情况 | 处理 |
|---|---|
| 可推断的缺失（如没说时间范围） | 用工具描述里的默认值补，并在结果里注明”已按默认 7 天查询” |
| 格式错误（日期写错） | 把错误原因 + 正确格式示例回灌给模型让它重试，而不是抛异常 |
| 语义越界（查了没权限的数据） | 明确拒绝并给出原因，不要静默返回空结果 |
| 参数类型正确但值不存在 | 返回”未找到”并附上可选的近似值 |
关键原则：错误信息是给模型看的输入，不是给运维看的日志。空结果和报错是两回事，混在一起模型就学不会纠正。
Q3 工具调用要不要幂等？怎么做？
- 要。模型的重试和框架的重试会叠加，一次用户请求可能触发多次同样的写操作。
- 常见做法：调用方生成幂等键（如
request_id + tool_name + 参数哈希），服务端按幂等键去重。 - 更隐蔽的问题：流式场景里中断重连后模型可能重新发起同一个工具调用——这条路径最容易被漏掉。
- 有区分度的回答会区分读工具和写工具，只对写工具做严格幂等。
Q4 多个工具可以并发调用，怎么保证正确？
- 先判断依赖关系：无依赖的才能并发。模型往往不知道两个工具之间有依赖，需要你在编排层判断。
- 并发写要处理顺序敏感：两个工具都改同一份状态时，结果取决于完成顺序 → 必须串行或加锁。
- 注意结果拼接顺序：并发返回顺序不等于调用顺序，拼回上下文时要按调用 id 对齐，否则模型会把 A 的结果当成 B 的。
- 部分失败的语义要定义清楚：是整体失败，还是允许部分成功？这决定了要不要回滚。
Q5 工具调用的循环（agent loop）什么时候停？
停不下来的循环是线上最常见的故障之一。可用的终止条件：
- 模型不再请求工具，直接给出答案。
- 达到最大轮次（必须有硬上限，且要能被配置）。
- 检测到重复调用：同样工具 + 同样参数连续出现 → 判定为卡死，中断并上报。
- 预算耗尽（token / 时间 / 金额）。
追问：第 3 条之外，还有什么”看起来在推进实际没进展”的信号？（考察是否想到观察状态是否被改变）
Q6 工具返回的内容太长怎么办？
- 截断是最差的方案——模型会基于残缺信息给出自信的错误答案。
- 更好的顺序：摘要化 → 分页 → 让模型显式请求下一段。
- 结构化返回优于自然语言返回：让模型做选择，而不是让它从长文本里找。
- 如果是列表类结果，返回总数 + 前 N 条 + “是否继续”的选项，比直接灌 500 条更有效。
Q7 怎么防止 Agent 执行危险操作？
- 分级：读操作自动执行；写操作、涉及资金/删除的操作必须人工确认。
- 白名单：参数校验在服务端做，不能只信模型的输出（模型可能被提示注入操纵）。
- 确认要展示关键信息：人工确认时必须显示”将要做什么、影响什么”，只显示工具名没有意义。
- 有区分度的回答会提到提示注入：工具返回的内容里可能藏着指令，不能直接当可信输入。
Q8 怎么评测工具调用的质量？
- 分开看选对工具（工具选择准确率）和填对参数（参数正确率）——这两类错误的原因和修法完全不同。
- 记录不该调用却调用了的比例：过度调用比调用失败更隐蔽，也更贵。
- 用固定的用例集做回归，重点覆盖”多个相似工具并存”的选择场景。
- 线上要采：工具调用轮次分布、失败率、平均轮次——轮次持续上涨通常意味着工具描述在退化。
本专题持续补充。