企业官网建设流程全解析

可以先评测实际交付是否满足任务要求。只要有明确的输入、完成条件和可核对的结果，就能开展结果验收；取得工具调用及其实际返回后，还能进一步排查执行过程。没有证据覆盖的环节，保留为待查问题。

例如，让 Agent 统计订单金额，最后拿到一个数字和一份结果文件，即使看不到完整执行过程，也可以用已知答案检查金额是否正确。但如果金额算错了，仅凭最终答案，还不能确定是漏了筛选条件、读错字段，还是整理答案时发生了偏差。

因此，准备 Agent 评测时，可以先问两个问题：这次能保存哪些证据？这些证据足以检查哪些要求？EvalDock 的评测方法按实际采集范围说明可观测性，帮助使用者和开发者确定评测与排查范围。

黑盒、灰盒、白盒，描述的是本次能看到什么

下表采用 EvalDock 方法页对受测执行流程的约定。它描述某次配置下可取得的证据；同一个 Agent 通过网页、命令行或 API 使用时，采集范围可能不同。

这里的“白盒”指受测流程可追踪，并不意味着模型内部推理完全透明。页面上的“正在查询”提示、Agent 自述的“已经检查”，也不能替代实际调用和返回记录。没有核对采集范围时，先记为待确认；不能仅凭产品开源，或看到一份日志，就完成分级。

只有输入输出，也能先完成结果验收

结果验收需要把“希望做成什么”转换成具体检查。在任务执行前写清三件事：输入材料、合格结果，以及能验证合格结果的办法。

以一个为本文构造的订单统计示例说明。输入只有以下三条记录，任务要求统计已付款订单的总金额；各金额使用相同币种和单位，没有退款、重复订单或其他调整项。

预期金额为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 时，还要统一任务、输入、验收标准和运行条件，并确认额外采集没有改变被测执行。若一个只能取得结果，另一个能记录过程，可以先比较共同可验证的结果指标，并单独呈现过程分析；缺失的过程指标不能填成零分。更多日志提供更多排查依据，本身不代表任务能力更强。

EvalDock 是面向各类 Agent 的跨生态评测与选型平台，为使用者提供选型与解决方案，为开发者提供针对性的优化方案。将任务要求、交付成果和可用证据联系起来，能够帮助开发者明确已经验证的表现，并把待查问题转成下一次检查或复测任务。可从公开评测报告查看具体案例与核查范围。

本文由 EvalDock 团队撰写。