Tool calling 最容易错在哪？
为什么 argument 是瓶颈，怎么改？
先弄清楚：每个概念是什么
- Tool selection 与 argument generation
- 选哪个 tool，和参数怎么填，是两件事。
- Personal context
- 参数的值常常在用户的数据里，不在这句话里。“我妈”“上次那家店”要先查出来才能填。
- Schema validation
- 执行前检查参数的类型、必填项、取值范围。
- Constrained decoding
- 解码时只允许生成符合 JSON schema 的 token。它保证格式合法，不保证值正确，因为填错的日期和人在格式上也合法。
- Argument accuracy
- 逐个参数和 gold 比较。比之前先归一化日期格式和 ID，等价的写法不算错。例：3 个参数对了 2 个 → 0.67；整个调用全对才算对的口径下是 0。
30 秒回答
Tool calls fail in two ways: picking the wrong tool, or filling in the wrong arguments. Apple's ASTRA-bench found that argument generation was the main bottleneck when agents work over personal context. The right value often isn't in the request: "my mom" or "last Friday" has to be resolved from the user's data first. I'd measure selection and arguments separately. To improve: resolve entities and dates with dedicated tools before the main call, validate arguments against the schema, and return precise errors so the model can retry.
错误类型和对策
| 错误 | 例子 | 对策 |
|---|---|---|
| 格式错 | 缺必填项、类型不对 | schema validation、constrained decoding |
| 值没 resolve | sender="我妈" | 先调 contact resolver，拿到 ID 再填 |
| 时间错 | “上周五”算错日期 | 把当前日期放进 context；日期计算用代码 |
| 编造值 | 填了一个不存在的 ID | 只接受前面的 tool 返回过的 ID |
| 依赖没处理 | 第二步的参数要用第一步的结果 | 按依赖顺序执行，返回结果带稳定的 ID |
必答点
- selection 和 argument 分开量，argument 再按参数拆开
- ASTRA-bench：personal context 下 argument 是主要瓶颈
- 原因：值藏在用户数据里，要先 resolve
- 对策：先 resolve、再校验、错误信息要具体、可重试
- constrained decoding 只管格式
追问
tool 的描述怎么写，模型才不容易填错？
参数名自解释，写明单位、时区和格式，能枚举的给枚举值。再给一两个调用例子，容易混的两个参数写清区别。
填错了怎么恢复？
返回结构化的错误，写明哪个参数、为什么不对、合法值是什么。模型据此重试，次数设上限（见 tool 调用失败与重试）。
来源ASTRA-bench（Apple）：4 个 protagonist、2,413 个 scenario、time-evolving personal context，高复杂度下模型明显变差 · WWDC26 246（开发者 API 里有 ContactResolver）· tool calling 基础见 Agent、tool calling 和 MCP