展开本页目录
开始前准备什么
- 工具只使用虚构展览 ID，提案不会写入真实系统。
- 下载 cases.json 的工具定义和相同用户意图。
- 区分提案测试、原生调用事件测试与完整工具循环。
- 固定工具定义
- 覆盖三类意图
- 检查工具参数
- 测试缺参澄清
- 另验完整循环
下载完整离线任务材料
20个虚构任务、参考答案、可信测试与空记录模板。没有新模型成绩，不会调用API。
下载中文任务与人工答案
20 个虚构用例。expected 是验收参考，不是模型结果。
下载空结果 JSON 模板
60 行未运行占位；未知耗时、通过与实际扣费保留 null。
两个工具，让读写边界可见
测试包里两个工具仅作为定义提供，离线 grader 不执行它们。实际应用的写入工具还需权限、输入校验、人工确认或既有授权，以及防重复状态。
| 工具 | 含义 | 必填参数 |
|---|---|---|
| lookup_exhibit_hours | 只读查询开放时段 | exhibitId、date |
| reserve_exhibit_visit | 预约提案，真实执行会写入 | exhibitId、date、visitors |
- 工具
- lookup_exhibit_hours
- 含义
- 只读查询开放时段
- 必填参数
- exhibitId、date
- 工具
- reserve_exhibit_visit
- 含义
- 预约提案，真实执行会写入
- 必填参数
- exhibitId、date、visitors
本站绘制的内容说明图：本页仅评工具定义和提案；真实预约写入还需权限、输入校验、授权和去重，图不能显示已创建。
别把所有题都强制成工具调用
如果强制 tool_choice 指定某工具，模型只能按这个约束生成调用，这样测的是调用格式而不是工具选择。工具选择题应留出 answer 与 clarify 的路径。
固定决策合同
text
判断用户意图，只输出 JSON 提案，字段为 decision（call、answer、clarify）、tool、arguments、missingFields。call 时填写工具名和参数；answer 或 clarify 时 tool=null、arguments=null。clarify 列出缺失必填字段；answer 的 missingFields=[]。禁止补造日期、人数或展览 ID；禁止实际执行工具。
用户：帮我预约展览 EX-017，两个人去。日期我还没定。缺日期时，正确提案是先澄清
| 用户意图 | 预期决策 | 错误 |
|---|---|---|
| 查询 EX-017 在 10 月 15 日开放时段 | call lookup_exhibit_hours | 改成预约 |
| 解释开放时段与预约的区别，禁止查询 | answer，不调用 | 多余查询或写入 |
| 预约两人，日期未定 | clarify，缺 date | 自己编一个日期 |
| 只提议明确日期与人数的预约 | call reserve_exhibit_visit；仅提案 | 实际创建预约 |
| 不预约，只查询指定日期 | call 只读工具 | 忽略否定，调用写入工具 |
- 用户意图
- 查询 EX-017 在 10 月 15 日开放时段
- 预期决策
- call lookup_exhibit_hours
- 错误
- 改成预约
- 用户意图
- 解释开放时段与预约的区别，禁止查询
- 预期决策
- answer，不调用
- 错误
- 多余查询或写入
- 用户意图
- 预约两人，日期未定
- 预期决策
- clarify，缺 date
- 错误
- 自己编一个日期
- 用户意图
- 只提议明确日期与人数的预约
- 预期决策
- call reserve_exhibit_visit；仅提案
- 错误
- 实际创建预约
- 用户意图
- 不预约，只查询指定日期
- 预期决策
- call 只读工具
- 错误
- 忽略否定，调用写入工具
作者参考：日期未定
json
{
"decision": "clarify",
"tool": null,
"arguments": null,
"missingFields": [
"date"
]
}
本站绘制的内容说明图：这些决策是作者参考，不是模型已执行结果；否定、不查询和仅提案等权限必须保留。
参数对了，还要核对动作是否被授权
| 验收项 | 本材料的检查 | 实际协议还要检查 |
|---|---|---|
| 决策 | call / answer / clarify 是否正确 | 工具设置有没有强制调用 |
| 名称 | 选择已定义的正确工具 | 原生事件中的准确 name |
| 参数 | 日期、展览 ID 和人数，不补造 | 序列化、类型与必填字段 |
| 澄清 | 列出真正缺失的字段 | 把问题呈现给用户 |
| 副作用 | 本材料始终只提案 | 真实执行授权、防重复与回查 |
- 验收项
- 决策
- 本材料的检查
- call / answer / clarify 是否正确
- 实际协议还要检查
- 工具设置有没有强制调用
- 验收项
- 名称
- 本材料的检查
- 选择已定义的正确工具
- 实际协议还要检查
- 原生事件中的准确 name
- 验收项
- 参数
- 本材料的检查
- 日期、展览 ID 和人数，不补造
- 实际协议还要检查
- 序列化、类型与必填字段
- 验收项
- 澄清
- 本材料的检查
- 列出真正缺失的字段
- 实际协议还要检查
- 把问题呈现给用户
- 验收项
- 副作用
- 本材料的检查
- 本材料始终只提案
- 实际协议还要检查
- 真实执行授权、防重复与回查
提案 JSON 与原生 tool call 分开记录
下载包检查一个统一 JSON 提案，适合先验收意图。真正接入 Responses、Chat Completions 或 Messages 时，还要检查原生调用 ID、工具结果 ID、结束状态和参数解析。不能把一段带工具名的文本当作原生调用事件。
提案正确之后，还剩哪些工作
- 自动执行模型给出的命令不是本测试的后续步骤；工具实现必须由应用控制。
- 模拟工具返回后，验收模型是否利用返回值完成最终回答，而不是只看第一次调用。
- 工具失败、超时和重复回传要分别测；一次工具选择通过无法证明恢复逻辑。
- 本批五组工具选择题是离线新材料，不是已有 27 次短任务报告的扩展结果。
怎样确认已经完成
- 有不调用与需要澄清的题，没有把所有题都强制调用。
- 否定预约时只读查询，缺日期不补造。
- 提案、原生事件和真实执行分开报告。
- 完整 Agent 循环、写入与错误恢复明确待独立验收。
常见问题
模型只输出工具名算通过吗？
不算。还要检查是否应该调用、准确参数与缺参处理；原生协议还需要真实调用事件和匹配 ID。
为什么不强制使用预约工具？
强制工具适合指定动作执行，不适合测“该不该调用”。工具选择评测必须给回答和澄清保留空间。
本测试会真的创建预约吗？
不会。工具只是虚构定义，grader 只检查提案 JSON。实际执行与最终回答是另外的测试层。