不用额外模型调用，核验 Agent 是否真完成

Agent 说「完成了」，任务却可能没有写入任何结果。dev.to 的一篇文章展示了一个轻量检查器：读取任务已有的运行回执，不额外调用 LLM。在两个模型的实验中，它检出了全部 15 次注入的虚假成功，16 次正常运行也没有误报。但作者明确承认，这 15 次失败属于同一种形态，检测能力有边界。

目前能确认什么

检查器部署在调度器旁，只读取回执里的三个字段：任务声称的状态、输出数量，以及末尾几行说明。

它有三条告警规则：

• 声称成功，输出数量却为 0。
• 声称成功，说明中却提到尚未解决的失败。
• 声称成功，说明中却承认部分写入失败，例如 4 次写入中有 2 次失败。

无法解析状态时，另按 unknown 处理，不触发上述告警。检查器也不会见到错误词就报警：如果说明写着遇到 429、重试后成功，不能直接判失败。

实验共涉及两个模型、80 次尝试，其中有 74 份有效回执。作者称代码、原始记录和测试均已公开。不过，给出的节选没有完整交代其余实验结果，不能把 15 次全部检出理解为覆盖了所有失败类型。

我的判断

这套机制适合给无人值守任务补一道低成本检查。

程序员可以借鉴它检查定时采集、批量写入等任务：先找成功状态与数量、说明之间的矛盾，再把可疑运行交给人工复核。但「输出为 0」是否算失败，必须由任务约定决定，允许空结果的任务不能直接照搬。

更关键的限制在于，检查器读取的仍是任务自己的回执。如果状态、数量和说明一致地报喜，实际文件却没落盘，仅凭这些字段无法确认产物存在。

它能发现回执中的矛盾，不能替代对真实产物的验证。

三条规则的具体匹配方式、漏检案例，以及 74 份有效回执的完整分类，还要等完整原文和代码确认。