课题 D｜服务看起来修好了，旧任务也真的处理了吗？

查新截至 2026-09-07

建议定位：系统验收的复现与审计训练，环境工作较重。 与 Uptimer、故障监控和你对“真的完成了没有”的兴趣衔接。先测评分器如何判断同一批修复，不先造完整运维 Agent。

具体问题

本地有一个模拟通知队列，故障前 A、B、C 三个通知等待处理，D 已经处理。Agent 修复服务以后，页面正常，新加入的 E 也能处理，但 A、B、C 可能仍丢失，或 D 被重复执行。

因此任务的正确标准应提前写明：旧任务全部完成，已完成的不重复，新任务可处理，并按约定在重启后保持正确。这里的“恰好一次”只指本地模拟接收器观察到的效果次数，不是对真实分布式系统提供 exactly-once 保证。

你先问：较弱的验收会放过哪些不完整修复？还不需要马上提出新的修复方法。

Trivedi 等，AppWorld，2024 已检查要求之外的数据库变化，考虑副作用。Clark 等，SREGym，2026-05-12 检查故障解除与恢复，且讨论重启导致故障注入失效、造成假成功的问题。

更接近的是 Replaybook 固定版本 20260808.0.0，2026-08-08：已有重启后的验收，其旧队列场景还检查预置任务。因此不能声称首次检查持久性、首次关注积压任务，或“现有基准都不查副作用”。它是公开工程实现，不等同同行评审结论。

Advani，From Confident Closing to Silent Failure，2026-06-01 也分析了自报成功而实际失败的轨迹。本文不把其中过滤后样本的比例当作所有 Agent 的总体失败率。

这使本题目前更适合复现和具体项目验收审计。未来研究空间要来自真实、尚未被当前检查覆盖的特定全过程要求，例如从排队到完成及重启后都应保持哪些行为；本次没有确认这种新发现。

用本地 SQLite 存任务，用本地接收日志记录任务 ID。先手动注入一个简单故障，例如工作进程读取了错误的队列位置，再写一个人工正确修复。不要一开始就上 Kubernetes 和完整故障平台。

构造几种伪修复：只让健康接口返回正常；只处理新任务；重新入队所有任务导致重复。它们用来验证评分器会不会漏错，不代表真实 Agent 自然产生这些错误的比例。

然后让同一个模型在相同预算下处理故障，保存修复产物。三种评分器分别检查：健康接口；新任务 E；完整的旧任务、新任务、重复和重启行为。

为避免一个评分器改变后续状态，每种检查在相同修复产物的独立环境副本中进行。不要让第一组先消费队列，再让第二组面对不同起点。每次恢复相同故障快照，记录所有事件 ID 和时间。

报告同一批修复里：弱验收通过多少；完整验收通过多少；弱验收通过而完整验收失败多少；这些差异分别漏了什么要求。

还可以报告“弱验收通过的修复里，有多少被完整检查发现不合格”，但分母必须明确。不能把这个比例当成所有运维任务中的故障发生率。

完整评分器也需要验证。它不能因为某种实现方式与参考答案不同就判错，应检查任务要求的行为。如果一个可接受的替代修复被拒绝，要先修评分器。

Agent 不应能修改最终评分程序。用户任务必须已经明确旧任务和不重复等要求；不能事后加要求，再批评 Agent 没完成。

试点四个故障家族，每个重复三次，一个模型，共 12 次修复运行。如果每次上限 20 次调用，最多 240 次模型调用；评分器本地运行，不需要再叫模型打分。故障家族可以围绕读取位置、处理状态、重试逻辑和启动恢复，但要逐项检查正确修复确实可行。

只有发现有意义的差异后，再考虑 12 个家族、两个模型、各三次，合计 72 次运行。重复不是独立故障类型，报告时分开计数。先用一个故障估算 token 和环境耗时，再决定扩大。

SREGym 官方仓库的 Lite 说明要求约 8 vCPU／16GB 及一组容器集群工具，不宜默认为普通电脑第一周都能顺利运行。它可作为阅读和后续复用入口，当前最小方案不依赖它。

AppWorld 仓库对普通代码和受保护任务材料有不同许可条件；Replaybook 主程序的 MIT 不能自动套到独立场景包。本次未亲跑这些环境；最初使用自写小队列和虚构通知，避免无意复制受限任务材料。

若只是重复了 Replaybook 已有检查，完成复现报告即可。若弱检查没有漏过真实 Agent 修复，不要用大量人为伪修复替代自然结果来宣称普遍严重。

若从你自己的项目或公开真实故障记录中发现某个明确要求被现有验收遗漏，并在独立案例中重复出现，可以继续研究它的适用范围和改进。先查更具体的 failure recovery、backlog、repair verification、collateral damage 等工作，不直接宣布新基准。

如果下一阶段要比较“让 Agent 填旧／新／重复证据表”是否改善修复，应另开等预算实验。更严格的评分使通过率降低，不代表 Agent 变差；那是你终于看到了以前没量到的东西。

手写五个通知的正确终态；实现一个正确修复和一个只处理新通知的伪修复；证明两种检查会给出预期差异；最后才让 Agent 修一次。第一份报告应展示一个具体遗漏及其日志，而不是排行榜。