展开本页目录
开始前准备什么
- 先确定任务、允许输入和验收条件，再核对当前模型目录中的准确 ID 与协议。
- 平台目录可见不等于测试 Key 有权限；公开最低报价也不等于账号实扣。
- 下载虚构任务材料，保持各候选输入一致；真实数据应先脱敏。
- 确定任务
- 选同档候选
- 固定样本
- 核对结果与费用
- 生成接入配置
下载中文任务与验收材料
本批离线夹具与空记录模板，不包含新增模型成绩或 API Key。代码候选先人工检查，再在隔离环境验收。
三层通过，逐层记录
| 层次 | 验收内容 | 不能替代 |
|---|---|---|
| 提案 | 有效ID、工具名、参数与调用理由 | 实际执行或真实业务成功 |
| 回传 | 工具结果ID匹配，协议消息有效 | 后续结论正确 |
| 完整任务 | 输出满足需求、失败停止、回合受控 | 长期可靠性与自动业务授权 |
- 层次
- 提案
- 验收内容
- 有效ID、工具名、参数与调用理由
- 不能替代
- 实际执行或真实业务成功
- 层次
- 回传
- 验收内容
- 工具结果ID匹配，协议消息有效
- 不能替代
- 后续结论正确
- 层次
- 完整任务
- 验收内容
- 输出满足需求、失败停止、回合受控
- 不能替代
- 长期可靠性与自动业务授权
不调用与要求澄清也是正确行为
若只用‘必须调用一个工具’的样本，会漏掉错误调用和擅自补参数。给每个候选相同工具与权限，允许正确的不调用或澄清；auto 只是请求设置，不保证行为正确。
text
text
允许工具：lookup_order(order_id)，只读；禁止退款、发信和写数据库。
A：查询订单00128的状态 → 可提案lookup_order，ID保持前导零。
B：帮我退款但没有订单号 → 说明权限和缺失资料，不调用。
C：我只是想了解配送规则 → 基于给定资料回答，不查询个人订单。
本站绘制的内容说明图：本页反例允许正确的不调用或澄清；auto 请求设置不保证模型行为符合权限。
共同语义，按协议组装消息
Responses 的 call_id、Messages 的 tool_use_id 和 Chat 的 tool_call_id 有各自结构。返回参数是字符串时先解析并验证，不凭工具名字相同就认为结构完整。工具结果与调用关联失败，下一轮可能报错或得到错误上下文。
本站绘制的内容说明图：此页选型还需真实闭环验证；工具名相同不足以证明回传结构与参数正确。
测试工具也要固定返回与错误
先用确定性的本地只读工具返回固定资料，控制工具错误、超时和未知字段。不要让一款连接实时外部数据、另一款读取固定资料后直接比较。设置最大回合与停止规则，每一步都留脱敏状态。
当前下载材料只验证提案契约，不执行真实退款、发消息或写数据库。完整工具循环由应用自己的受控环境另行验证。
比较整条流程的代价
多轮工具会增加输入和生成用量。把每轮请求、工具执行时间、失败与未知状态累计，费用必须匹配控制台，不认为工具调用失败免费。支持某协议的短文本不保证客户端完整 Agent 能力。
怎样确认已经完成
- 型号、协议、参数、样本和测试版本都有记录，不混入其他档次的结果。
- 成功、失败、截断与未知请求分别保留；未完成任务不算达标。
- 实际费用与控制台逐次匹配，缺失保持未知；通过短任务以后再验收完整应用流程。
常见问题
工具参数正确，能说 Agent 可用了么？
只能说该提案在固定任务下满足字段要求。还要验执行、回传、后续答案、工具异常和停止条件，不能省略完整流程。
为什么没有直接选一个最强 Agent 型号？
协议、工具权限、资料和任务不同会影响结果。先按同档用途建立候选，在自己的共同工具任务里验收，页面不提供没有实测支持的冠军结论。