用可验证故障检验 Agent 的数据排障能力

数据流水线报错后，最耗时间的往往是追查：输入哪里坏了，处理停在哪一步，日志够不够证明判断。Hermes Data Reliability 尝试把这段调查交给 AI Agent，让它收集证据、解释失败，再给工程师一个可审查的下一步。

作者搭建的是一个小型 AWS 实验环境，尚未证明它能稳定处理生产故障。但它提出了一个值得借鉴的方向：Agent 的价值不只在于给出原因，还在于交代证据，以及哪些事情根本没有查明。

先造一个有标准答案的故障

这个实验使用 Nous Research 开发的 Hermes Agent，调查一条刻意简化的数据处理链路。下面的结构保留了文件生成、消息通知和处理结果，方便逐步核对故障发生在哪里：

Producer Lambda -> S3 input -> SQS -> Processor Lambda -> S3 output

要注意 SQS -> Processor Lambda 这一段：输入文件已经生成，不代表处理能够成功完成。

Producer 生成一个包含 5 条记录的 JSON 文件。Processor 要求每条记录的 amount 都是数字，将数值翻倍，再把结果写回 S3。作者在第 3 条记录中放入了错误类型，用它触发校验失败：

{
  "record_id": 3,
  "amount": "not-a-number"
}

关键是 "amount": "not-a-number"：字段存在，但字符串不满足处理器的数字要求。

这种设计的价值是有一个已知答案。Agent 如果认定是 SQS 投递异常，或者把原因归到 S3 写入权限，就能与实际故障对照，而不只是检查报告听起来是否合理。

不过，原文给出的诊断文字只是示意，并非某次实测运行的输出。它大致应当解释：第 3 条记录类型错误，建议在源头修正，再审查如何重新处理文件；现有证据不能证明修正后的运行已经成功。不能把这段示例当成 Agent 已经答对的成绩。

为什么日志采集要和 Agent 调查分开

整个流程分为采集、调查和报告三步。

采集器读取配置好的 CloudWatch 日志，按照 YAML 中的规则匹配错误，把命中的事件存入 SQLite。独立 worker 随后领取事件、启动 Hermes，让 Agent 在授权范围内选择要检查的材料，例如附近日志、输入文件和已保存的处理尝试详情。

最后，报告列出失败阶段、原因解释、不确定性、建议操作，以及使用过的证据引用。

确定的采集工作交给普通代码，需要追问和判断的调查交给 Agent。

这样拆分有两个实际好处。第一，Hermes 忙碌或不可用时，采集器仍然可以工作。事件和采集进度持久化后，进程重启也能从保存状态继续。第二，调查可以单独限制时间、工具调用次数和尝试次数，避免一个棘手事件不断触发模型调用。

作者还明确把中断和失败的尝试计入预算。对准备在 Node 服务里接入 Agent 的团队，这一点很实用：工具报错同样消耗资源，不能因为没有获得结果，就让重试无限继续。原文没有公布具体预算数值，因此这里只能借鉴约束方式，无法照搬参数。

证据引用能检查，但不能替你判断对错

当前工具只提供只读访问，实际变更由工程师决定。权限也由模型之外的代码执行：每次工具请求都检查批准的资源、允许的时间窗口和剩余预算，AWS 凭证留在模型容器之外。

这里的边界很清楚。告诉模型「只能读这些文件」是一条指令；工具层真正拒绝越界读取，才是执行约束。

宿主还会记录每次工具调用返回了哪些证据。在自动调查结论被接受前，系统检查报告引用的证据是否确实由本次调查取得。这能拦住凭空添加来源、引用未读取材料的问题。

引用真实存在，不等于推理已经正确。

Agent 可能拿到了正确日志，却误读字段含义或事件顺序。引用校验只能证明它看过这些材料，不能证明结论成立，解释仍然需要审查。

日志和文件内容也被视为不可信输入。即使日志里出现要求更改任务、扩大权限的文字，也不能获得指挥 Agent 的资格。它们是待分析的数据。

同样，读文件失败不能直接写成「文件不存在」；搜索没做完，也不能写成「没有相关事件」。权限不足、输入不可用、结果不完整，都应当进入报告，而不是被包装成确定判断。

我的判断

我认可这个项目对角色的定位：先帮助工程师调查，再提出可审查的建议。相比把原始日志直接贴进聊天窗口，它把事件保存、调查预算、证据记录和权限约束纳入了流程，更适合做成持续运行的系统。

但它还没有给出足够证据，证明 Agent 比现有排障方式更准确或更省时间。原文列出 3 个评估场景：异常记录、包含误导指令的日志、不可用的输入文件，没有公布成功率、耗时、成本或对照结果。当前更适合把它看作实验设计和工程经验。

尤其是类型错误这种已知故障，普通校验规则就能直接定位，未必需要模型介入。Agent 是否有额外价值，要看它能否在需要关联多处线索的案例中减少人工调查，而这部分仍待验证。

能力范围也要看清。目前它依靠配置好的 CloudWatch 日志匹配发现显式失败；静默停摆、输出超期检测和 Snowflake 集成都属于后续计划。一个任务根本没启动，未必留下可匹配的报错，不能指望现有流程自然覆盖。

能拿来做什么

• 如果你在维护 Node 数据导入或异步处理任务，可以先构造一个已知原因的失败样本，把输入、日志和处理记录留齐，再检查 Agent 的结论能否逐项对应证据。
• 如果准备接入自动排障，先用规则匹配并持久化事件，再启动独立调查 worker，同时限制时间、工具调用和重试次数，把失败尝试也计入预算。
• 给排障报告固定设置「已确认事实」「尚未核实」「建议操作」等内容要求，并检查引用是否来自本次工具返回，减少把猜测写成事实的机会。
• 首轮评估可以复用原文的 3 类案例，分别检查诊断能力、对误导指令的处理，以及证据不足时能否明确承认限制，再补充自己业务中的可复现故障。