可以先评测实际交付是否满足任务要求。只要有明确的输入、完成条件和可核对的结果就能开展结果验收取得工具调用及其实际返回后还能进一步排查执行过程。没有证据覆盖的环节保留为待查问题。例如让 Agent 统计订单金额最后拿到一个数字和一份结果文件即使看不到完整执行过程也可以用已知答案检查金额是否正确。但如果金额算错了仅凭最终答案还不能确定是漏了筛选条件、读错字段还是整理答案时发生了偏差。因此准备 Agent 评测时可以先问两个问题这次能保存哪些证据这些证据足以检查哪些要求EvalDock 的评测方法按实际采集范围说明可观测性帮助使用者和开发者确定评测与排查范围。黑盒、灰盒、白盒描述的是本次能看到什么下表采用 EvalDock 方法页对受测执行流程的约定。它描述某次配置下可取得的证据同一个 Agent 通过网页、命令行或 API 使用时采集范围可能不同。可观测性实际保存的证据可以开展的检查黑盒结果可见输入、最终输出、按任务保存的交付物以及外部可测耗时对照任务要求验收结果检查可直接观察的交付行为灰盒部分过程可见在输入输出之外取得部分可核验的操作、工具活动或日志验收结果并排查有记录覆盖的执行环节白盒执行流程可追踪能关联任务、关键工具调用及输入返回、执行顺序、错误和最终产物并说明覆盖范围与盲区验收结果沿可追踪流程检查偏差出现的位置这里的“白盒”指受测流程可追踪并不意味着模型内部推理完全透明。页面上的“正在查询”提示、Agent 自述的“已经检查”也不能替代实际调用和返回记录。没有核对采集范围时先记为待确认不能仅凭产品开源或看到一份日志就完成分级。只有输入输出也能先完成结果验收结果验收需要把“希望做成什么”转换成具体检查。在任务执行前写清三件事输入材料、合格结果以及能验证合格结果的办法。以一个为本文构造的订单统计示例说明。输入只有以下三条记录任务要求统计已付款订单的总金额各金额使用相同币种和单位没有退款、重复订单或其他调整项。订单状态金额A已付款120B待付款130C已付款200预期金额为120 200 320。假设 Agent 返回450即使完全拿不到过程记录也已经能够确认这个输入下的最终金额没有满足任务要求。此时适合保存输入、任务原文、输出文件、预期值和实际值。可以报告“预期 320实际 450”但不能直接写“Agent 忘记过滤待付款订单”。450 恰好等于全部金额之和提供了一条排查线索相同错误结果仍可能由不同执行问题造成。如果结果正确也应按实际检查范围记录。一次已知答案核对证明的是本次金额要求得到满足如果还要求交付 CSV、保留字段或遵守指定工具限制这些要求需要各自的检查依据。只能看到结果时有些过程要求可能无法验证应单列为未验证。增加过程记录后怎样缩小问题范围仍使用上面的构造示例可以把不同证据支持的结论分开。只有输出 450能确认结果错误原因待查。多拿到一份没有状态筛选的 SQL 文件能确认这份 SQL 的筛选条件不符合任务要求。但如果没有实际执行记录还不能确认最终答案就是执行这份 SQL 得到的。拿到关联到本次任务的实际查询调用、返回值和最终答案如果调用中的 SQL 没有状态筛选工具返回 450答案也写了 450就能确认已记录的查询缺少要求的筛选条件返回值与最终答案相符。下一步可围绕筛选条件补充检查并在修改后用同一输入验证。这条证据链把问题定位到一个可以处理的执行环节。至于为什么生成了这样的查询还需要进一步检查任务描述、上下文及其他可用记录仅凭这条链仍不能推断模型内部的思考过程。在实际任务中可以给每个关键步骤保留对应关系它属于哪次运行接收了什么输入返回了什么结果后续如何使用这个结果。对于没有记录的环节明确标出缺口不能把相邻两条日志之间的动作自动补全。图 1不同证据支持不同范围的判断。订单、金额与执行情况均为构造示例非报告原题或实测截图。EvalDock 团队绘制。EvalDock 的公开案例核对了哪些依据EvalDock 于 2026 年 9 月 19 日发布的《DSH 插件配置评测报告》中数据库查询案例的运行环境为 DSH 0.1.5-rc.1插件配置为nanmicoder/dsh-agent-teams 0.1.18。该案例交付了 SQL 查询、JSON 结果和答案文件。公开报告说明核查对照了数据库结构读取、查询工具的实际返回与三份交付文件确认查询字段、执行结果和答案之间的对应关系答案与实际查询返回一致。来源EvalDock 数据库查询案例。这项成果展示了过程证据的实际用途除了确认结果文件已生成还能检查查询返回与答案是否对应。前文的三条订单和错误金额是方法示例不是该报告的原始任务或失败记录。阅读这类案例时分别看“采集到了什么”“核对了什么”“公开了什么”。该报告公开的是经过核对的案例摘要并非全部原始轨迹报告使用过执行轨迹也不等于已经按当前约定完成白盒分级。本文的黑盒、灰盒、白盒表用于说明采集范围。EvalDock 方法页列出的输入输出评测、执行轨迹分析协议仍是方法草案尚未用于已发布结果当前 DSH 报告采用模型维度评分并结合具体案例提供交付核查依据。记录一次评测至少留下这些信息可以用下面的清单组织自己的任务记录。它是一份方法模板按实际任务填写。记录项需要回答的问题任务与配置要完成什么使用什么输入、Agent 版本、插件与环境验收标准哪些要求可由输出检查哪些要求需要过程证据证据范围实际保存了什么哪些关键环节没有记录验证结果每项要求的预期与实际是什么哪些通过、失败或尚未验证排查与下一步已确认的偏差在哪里还需补查什么修改后用什么任务复测比较两个 Agent 时还要统一任务、输入、验收标准和运行条件并确认额外采集没有改变被测执行。若一个只能取得结果另一个能记录过程可以先比较共同可验证的结果指标并单独呈现过程分析缺失的过程指标不能填成零分。更多日志提供更多排查依据本身不代表任务能力更强。EvalDock 是面向各类 Agent 的跨生态评测与选型平台为使用者提供选型与解决方案为开发者提供针对性的优化方案。将任务要求、交付成果和可用证据联系起来能够帮助开发者明确已经验证的表现并把待查问题转成下一次检查或复测任务。可从公开评测报告查看具体案例与核查范围。本文由 EvalDock 团队撰写。