如何校验 Agent 产生的确定性结果？

核心回答

校验 Agent 的确定性结果，要先把需求写成可检查的条件，再用程序、测试或外部系统状态验证。这里的“确定性”指结果存在明确的判定依据，例如金额是否算对、字段是否齐全、文件能否解析、业务操作是否实际完成；不是把模型温度设为零。

1. 先定义成功条件和独立依据。 明确输入范围、业务口径、预期输出与必要状态，依据来自需求、接口契约、可信数据或已确认的测试样例。
2. 分层校验。 先检查格式和类型，再查业务约束、权限和跨字段关系；数值用独立计算核对，代码用测试验证，业务操作查询执行后的状态。
3. 在关键节点放校验器。 工具执行前校验参数和执行条件，执行后核对返回内容及状态，最终答复前检查结论是否与已验证结果一致。
4. 保留通过、失败和暂时无法确认三种结果。 失败时给出具体违反的条件；超时或状态尚未可见时继续查询或等待确认，不能把“模型说成功了”当作完成。

例如统计已支付销售额，测试数据中两笔已支付订单为 100 元和 200 元，另有取消订单 50 元，预期应为 300 元。SQL 能执行、返回数字，甚至模型解释得很完整，都不能替代这一结果校验。

校验依据怎样保持独立

校验器需要判断“是否满足要求”，而不是复述生成结果。预期金额应从明确的支付状态和原始记录独立计算；代码测试应从需求和接口契约推导；创建资源是否完成，应查询业务系统中的对应对象。

如果生成器和校验器都直接使用同一段错误推理，两次得到一致答案也不能证明正确。可以让模型辅助提取检查项，但规则本身要落到可检查的条件，并用已知正确、已知错误及边界样例验证校验器。

结果可能有多种合法表示，比较时按契约处理：JSON 对象的键顺序通常不重要，列表是否有序、金额精度、日期时区和空值含义则需要事先约定。SQL 或代码也可能有多种正确写法，通常应比较行为和结果，不能只匹配一份参考文本。

不同结果分别怎样验证

结构化数据： 先解析，再按 Schema 检查字段、类型、枚举、范围和是否允许额外字段。注意，声明一个字段的类型，并不自动让它成为必填项；缺失字段和值为 null 也不同。结构通过后仍要查业务规则，例如金额与明细是否一致、日期区间是否合理、对象是否属于当前用户和租户。

计算与查询结果： 从可信输入独立计算或与参考查询对照，核对过滤条件、连接粒度、去重、单位与舍入。对复杂查询可先用小型固定数据集覆盖正常、空结果、重复关联、边界日期等情况，再检查实际数据范围。单纯判断“结果非空”会漏掉大量错误。

代码和文件： 代码先做语法、类型与依赖检查，再运行与需求对应的测试；文件检查实际存在、格式可解析以及关键内容是否完整。一个测试命令退出成功，还要确认目标测试确实执行了，不能把未收集到测试或被跳过误当通过。

业务操作： 结合工具调用结果、资源 ID 和业务系统状态检查后置条件。例如“已创建工单”应能查到对应工单，其归属、内容和状态符合本次请求；只有一段成功文案或一条请求日志，不足以证明创建完成。

SQL 例子：解析通过为什么还可能错

电商问数教程使用数据库的 EXPLAIN 提前发现语法、表名和字段名等问题。这是一层有用的检查，但无法判断“销售额应排除哪些状态”，也无法保证连接没有放大金额。

在前面的三笔订单示例中，漏掉支付状态条件的 SQL 可以正常执行，却返回 350 元。结果校验器按事先确认的口径得到 300 元，才能指出具体问题。若金额已经因一对多连接被重复累计，还要检查订单粒度与关联关系，而不是让模型把最终数字改成参考答案。

执行生成 SQL 前，仍需限制允许的语句、表和数据范围，并设置资源预算。数据库能解析某条语句，不代表它适合在当前权限和环境中执行。修正后的 SQL 也应重新通过相应校验，再进入后续流程。

超时、异步和最终结论怎样处理

一次操作超时，可能是请求没有到达，也可能是业务已经完成但响应丢失。先用稳定的请求标识、幂等键或资源 ID 查询实际状态；不能直接将未知当失败并重复执行。若系统存在异步处理或可见性延迟，就在截止时间内检查预期状态，仍无法确认时保留未知状态及原因。

最终结论也要绑定到证据。例如故障诊断中，工具选择正确只说明路径合理；还要检查诊断条件是否满足、证据时间范围是否匹配、反例是否被排除。没有明确判定规则的开放式结论，可以用专家标准或模型评审补充，但应与已经通过程序校验的部分区分。

如果通过 Hook 接入校验，可以在工具调用完成、产物落盘或任务结束等事件后触发相应检查。Hook 提供触发时机，真正的判定仍由校验规则和外部证据完成；也要处理校验器报错或未运行的情况。

追问：校验失败后怎么让 Agent 修正

返回具体、可操作的错误，例如“输出缺少 currency 字段”“金额与有效订单合计不一致”“请求已受理但业务状态仍在处理中”。格式问题可以重新生成对应字段，计算或查询问题应回到产生错误的步骤，状态未知则进入查询与恢复流程。

修正应有次数或时间预算，并保留原结果、失败规则、校验依据及版本。规则本身也要回归测试，防止校验器过松放过错误，或过严拒绝合法结果。总体成功率如何统计，可继续看Agent 输出质量与任务成功率评估；本题重点是单次结果依据什么判定。

DeerFlowPython

基于 DeerFlow

核心回答

DeerFlow 可以把确定性检查随子任务传递：主 Agent 在 task 中提供 acceptance_criteria，子任务执行结束后，程序读取实际文件或已记录的命令结果，逐项返回检查结果。模型的完成说明、子任务的 completed 状态和检查条件是否成立分别记录，不能互相替代。

这条检查链适合确认文件存在、格式可解析和特定执行记录。研究结论是否有依据、数据口径是否正确，仍要依据需求另作核对；主 Agent 再根据具体未满足项安排修正或补证。

把检查条件随子任务传递

例如委派整理企业资料，要求交付结构化数据和摘要文件，可以附上两项条件：

file:/mnt/user-data/outputs/companies.json json-valid
file:/mnt/user-data/outputs/summary.md non-empty

这是检查项示例。第一项检查文件能否按 UTF-8 JSON 解析；第二项检查摘要文件非空。即使两项都成立，数据也可能缺少企业名称、来源或日期，摘要也可能遗漏关键反证，因此不能把这两项扩成“研究结果正确”。必填字段可以再用 JSON Schema 校验，结论则需要对照原始来源；这些是业务侧应增加的判据。

程序实际检查了什么

普通 task 在子任务进入 COMPLETED，且委派携带检查条件时，才调用确定性检查器。检查器通过当前线程的工作区读取文件，归一化虚拟路径并核对可访问范围；支持的条件包括：

• 文件存在、非空，以及 file_written 对应文件的读取确认。
• json-valid 检查 JSON 语法，csv-columns 检查必需表头；它们不检查每行数据与业务含义。
• tests_passed:<command> 对照已记录的 bash 执行，核对命令归属、状态与测试摘要；它不会在父任务里重新执行测试。

检查有读取与证据边界。比如 JSON 文件超出该版 50,000 字节检查上限、测试命令或输出无法可靠归因、产生记录的 Shell 来源未知或为持久会话时，对应条件会保留为未验证。只看到退出码为零、构建成功或“没有测试”，都不应直接视为测试通过。检查器实现。

失败、未知和执行结束怎样区分

每项结果使用 checked 和 holds 记录，返回给主 Agent 的清单区分：

• holds：这项执行条件已有证据支持。
• does not hold：已检查，条件不成立，可以针对具体原因修正。
• UNVERIFIED：现有检查或证据不足，需要补充验证。

该版普通 task 的返回路径仍将子任务标为 completed，同时附上检查结果；条件不成立不会自动改成 failed，检查器异常时还可能没有清单。应用不能只读任务状态就宣布验收成功。检查调用与结果回传。

主 Agent 的提示要求针对不成立的条件修补、对未知项补证，并复用已经确认的产物。这是后续决策要求，不是程序已经自动完成修复。若业务要求全部检查通过才能交付，应在应用交付层读取检查结果，并为字段、口径和来源等业务条件增加独立校验。主 Agent 的处置规则。

对应教程

参考资料