2026 年 8 月的软件工程论文里，Agent Harness 占了相当篇幅。几篇工作把运行知识、工具、中间件和执行规则放进 Harness，研究它的持续更新与回归。另一些论文关注故障注入、在线告警和恢复。RCA 与代码修复部分主要检查模型结论背后的证据。
上一篇综述讨论了 6 月下半月至 7 月的 RCA 过程评测、Agent 运行时治理与仓库级证据工程。本月继续出现了 Harness 生命周期和验证门禁方面的工作。
一、Harness 如何积累经验，又不破坏已有能力
通用 Agent 已经会检索代码、调用终端和组织长任务。具体场景中的差距往往落在 Harness 上：它向模型提供哪些知识，怎样安排调查流程，成功和失败轨迹能否转成下次可用的更新。
From General Agents to RCA Experts: A Self-Evolving Harness for Root Cause Analysis 提出的 OpsHarness 以通用编码 Agent 为执行内核，把系统画像、分层操作知识、诊断工作流、规则和 idea-card 工具放进外部 Harness。控制面负责 setup、diagnose、evolve 和 verify。每次诊断后，系统会从正确轨迹与错误轨迹中提取原子更新；候选更新必须改善来源案例，并在动态保留集上不退化，才能进入知识库。
这个验证门决定了持续演化能否成立。去掉验证后，累计经验会在后期拖低性能。完整系统在两个公开基准、四个骨干模型上平均 Top-1 为 59.0%，相对裸通用 Agent 提高 63.4%；验证门拒绝了 37% 的候选更新。工业数据上的平均 A@1 为 0.74，Direct 基线为 0.24。公开基准采用时间切分，工业标签则来自 SRE 反馈；首次出现的故障和 telemetry 信号相互纠缠的案例仍然困难。
AutoSaddler: Automatic Harness Optimization with Durable Updates from Agent Execution Traces 处理更通用的 Harness 优化。它从失败 mini-batch 诊断 prompt、工具和中间件缺陷，生成修改，再由开发集与 EvoDAG 选择更新。相对基础 Harness，GAIA2、SWE-Bench Pro 和 Terminal-Bench 2.0 分别提高 9.0、9.6 和 10.0 个百分点；相对各基准最强自动优化基线的表格结果分别高 7.4、4.4 和 6.7 个百分点。去掉 generalization-aware selection 后，GAIA2 测试集成绩从 62.0% 降至 50.6%。这里的 durable 指更新经过独立任务组筛选，实验没有覆盖长期在线运行或有状态任务。
Harness 更新也会产生回归。Agent Skills Can Be Harmful: An Empirical Study of Skill-Induced Failures in LLM Agents 用无 Skill 和语义匹配 Skill 的轨迹作为参照，筛出 125 个功能失败与 182 个高置信效率回退。功能失败中有 86 个属于任务实现错误；效率回退常由过度流程和强制加载的 Skill 正文造成。这 307 个案例经过差分筛选和人工检查，不能解释成自然部署中的发生率。
EvoUndo: Recoverability-Constrained Self-Evolution for LLM Agent Harnesses 把回滚本身纳入更新测试。600 个合成任务中，有 197 次修改提高了当前能力，却破坏了恢复路径。基础表示下，常规修复没有恢复任何一次；加入更完整的状态 witness 和 effect 记录后，oracle 设置可恢复 191 次。更严格的 fresh holdout 上，Q20-Diverse Rescue@4 只有 35%。论文使用专用的 typed Harness simulator，尚未覆盖分布式数据库、第三方 API 和不可逆外部副作用。它给出的工程要求很具体：发布自修改前，应保存可验证的旧状态，并在反事实状态中实际执行回滚测试。
二、运行时保护：故障注入、在线告警与恢复
Agent 的失败经常藏在长轨迹里。监控器需要知道哪些信号会提前变化，告警后也要有可执行的恢复动作。受控故障注入可以为这两件事提供成对的正常与异常轨迹。
AgentChaos: Chaos Engineering for Agent Systems via Programmatic Fault Injection 在 LLM HTTP client 层修改响应，对 content 和 tool-call 字段组合出 65 种故障配置。每次实验都会核对故障是否真正触发，未触发的任务不进入效果统计。注入后，各系统均有性能下降，最大 pass@1 降幅为 50 个百分点；现有诊断方法识别故障类型和步骤的准确率分别低于 53% 与 56%。显式 5xx 较容易触发重试，HTTP 200 下的空响应和截断更容易沿轨迹静默传播。实验只覆盖 LLM API 边界，每个配置的实际触发样本也较少，不能据此给不同 Agent 架构排出稳定名次。
Real-Time Detection and Repair of LLM Agent Failures 使用 one-class ESN、Mahalanobis 距离和 CUSUM 监测循环、工具级联、目标漂移与内容污染；遗漏、数字一致性和工具返回结构交给确定性检查。冻结后的 120 个新 seed 上，基础确定性检查召回 54%，加入 required coverage 后达到 93%，64 个健康样本没有误报。告警后回滚到事实采集 checkpoint，带故障位置提示的修复恢复了 45% 的失败，重采样对照为 16%，总成功率由 52% 提高到 73%。监控开销约 200 微秒每步，但跨部署直接迁移的 AUROC 只有 0.527，重新校准后才达到 0.885。
CURA: Certified Runtime Alarms for Computer-Use Agents 读取执行步数、推理语义、操作模式和屏幕变化，用成功轨迹校准 CUSUM 阈值。证书控制的是误报预算，不保证失败检出率。361 个 OSWorld 任务中出现 71 次失败，其中 64 次仍被 Agent 声称成功；当误报预算 α=0.10 时，CURA 检出 42.3% 的失败，中位提前 31 步，实际误报率为 0.066。后续监督实验恢复了 70 次失败中的 23 次。快速发生的静默失败和 Agent 内部已经形成的错误判断仍较难发现。
三、RCA 的前提是可观测数据足以支持归因
RCA 系统可以准确发现事故已经发生，却未必掌握故障最初出现的位置。最终根因标签也会隐藏错误的调查路径。本月三篇论文分别检查可观测数据充分性、轨迹证据和缺证时的弃答。
TelemetrySuffBench: Is Agent Telemetry Sufficient for Failure-Origin Diagnosis? 把失败检测、故障类型、组件定位、起源步骤定位和安全弃答拆开评测。只保留元数据、OpenTelemetry 或 OpenInference 兼容视图时，检测 F1 仍有 99.5% 至 100%，起源步骤准确率最高只有 0.5%；移除决策内容后，所有模型的起源定位准确率都变为 0。完整可观测数据下，不同模型的起源步骤 Top-1 为 33.8% 至 97.2%。主实验使用合成的延迟绑定故障，这些数字说明常见投影缺少归因所需信息，不能直接外推到所有自然故障。
Beyond Fault Localization: A Trajectory-Level Study of LLM Agents for Microservice Root Cause Analysis 分析 3,500 条微服务 RCA 轨迹，人工标注受影响节点和故障传播边。即使模型命中根因服务，传播边也可能恢复不全；Sonnet/ThinkDepth 的 Acc@1 达到 90.0%，正确运行的 Edge F1 仍只有 0.67。作者把失败整理成证据遗漏、证据误读和无依据推断，并据此构建 DIAGGUARD 的 Grounder 与 Verifier，在留出模型、数据和拓扑设置中把 Acc@1 从 43.5% 提高到 52.5%。主表征集中于 TrainTicket，主要配置只运行一次，结论仍需更多系统验证。
The Abstention Protocol: RCA for Clos Fabrics 来自 Azure 生产网络。CoreSec 将每类 telemetry 信号标为 requisite、required、sufficient 或 optional，组合结果分为健康、不健康和不确定。缺证与冲突会保留为结构化状态，系统据此弃答。三年数据覆盖 60 多个 Azure 区域、400 个数据中心和 70 多万事件，误报率由旧式加权方案的 18% 至 22% 降到 1% 以下，近期弃答率为 1.5%，误触发缓解减少 80%。这些数字来自长期生产部署，但事后 RCA 标签可能受到 CoreSec 输出影响，且没有盲评或同数据集学术基线。它仍说明了一点：信息不足应当成为诊断协议中的正式结果。
四、仓库级修复先检查任务和证据
仓库修复的失败可能在写代码之前发生。Issue 没有写出的需求需要恢复，复杂系统缺陷还依赖运行时证据。两篇基准分别测量了这两个环节。
A Unified Issue Resolution Benchmark for Requirement Clarification, Planning, and Code Generation for Coding Agents 将 Issue 解决拆成需求澄清、规划、编码和提交。基准包含 31 个 Python/Java 仓库的 163 个任务，18 种 Agent 与模型配置平均解决率为 31.5%。按照最早偏离参考过程的阶段归因，需求失败占各配置运行的 24.5% 至 46.0%。中间参考答案由最终 PR 和测试反向重建，存在后见偏差；这些比例描述的是该归因协议下的失败位置，不能当成需求问题对最终失败的因果占比。
Evaluating Agentic Code Repair Capabilities in Distributed Systems 从 13 个开源分布式系统整理 60 个历史缺陷。对 31 个最难案例，向 Agent 提供经过调查与人工清洗的日志、追踪、运行状态和定向代码笔记后，10 个模型的平均通过率从 32.6% 提高到 50.6%；出现 71 个 FAIL→PASS，也有 15 个 PASS→FAIL。上下文中位长度只有 321 tokens，强模型在成功率不变时最多减少 69% token。实验支持的是高质量、有界调试证据，论文没有分别消融日志、追踪和代码笔记，也不支持把任意生产日志直接塞进上下文。
五、测试指标要分清通过、覆盖和缺陷检出
生成测试能够编译运行，只说明它进入了测试框架。公开测试均分、整题隐藏测试全通过率、mutation score 和目标调用率测量的是不同性质，不能用一个 pass rate 代替。
SWE-bench Science: Can Coding Agents Resolve Engineering Tasks in Science? 覆盖 98 个科学软件仓库、20 个领域和 119 个任务。最佳配置的 Public Score 为 96.64%，Private Score 为 75.11%，要求一题全部私有测试通过的 Pass@1 只有 47.90%。DeepSeek-V4-Pro 的公开分为 100%，严格 Pass@1 为 42.02%。前两个分数按测试比例平均，Pass@1 按整题判定，差距部分来自指标粒度。该基准仍清楚地显示，公开测试高分不能替代隐藏契约和领域不变量的完整验证。
Auditing and Decomposing Feedback-Driven Evolution in LLM Test Generation under the Oracle Problem 审计反馈驱动的测试演化。2,836 个真实错误提交上，单参考程序会把 Evolve 相对 one-shot 的增益高估 9.46 至 14.85 个百分点。改用多实现 panel 后，在同为 9 个候选槽位时，独立重采样比确定性变异高 6.01 至 18.83 个百分点。不过 matched 条件需要三次模型调用，Evolve 只需一次，候选数相同不代表 token 和调用成本相同。Real 与 Placebo 的持出实验也没有达到预设的优越或等效标准，因此现有证据不能判定细粒度反馈本身是否有效。
XREPOTEST: Benchmarking Multilingual Repository-Level Unit Test Generation for Large Language Models 收集 41 个仓库、五种语言和 3,642 个 focal functions，评测 14 个模型。标准设置下平均编译成功率为 57.4%，Go、Rust 和 Ruby 的总体 mutation score 均值只有 3.2%。全基准有 9.7% 的样本通过测试套件，却没有通过 Invocation Rate 检查；Agent 循环可以提高测试通过率，同时降低覆盖率与 Invocation Rate。这里的 Invocation Rate 由 Tree-sitter 检查 AST 中是否出现同名直接调用，并没有在运行时确认调用了指定实现。Julia 案例甚至会调用错误 overload，论文中的这个指标应视为弱静态代理。
六、把策略放在工具边界执行
Agent 接触 Jira、ServiceNow 或生产控制面后，提示词中的安全要求很难提供稳定的执行约束。宿主系统可以在工具调用前后检查操作类型、资源、查询和返回字段。
If Agents Were Angels, No Governance Would Be Necessary: Out-of-Band Policy Enforcement at a Trusted Tool Boundary 在受控的 Jira 与 ServiceNow mock 环境中实现带外策略执行。71 个任务、3,621 次计划试验里，从 Prompt-only 切换到完整 OBPE 后，描述性的轨迹策略失败率由 57.6% 降到 0.2%；场景簇等权主估计下降 41.2 个百分点。不考虑安全约束的任务完成率由 79.1% 降到 60.9%，Judge A 评定的 safe-useful 完成率提高 21.8 个百分点。实验中 66/71 个任务本来就预期触发策略，无法估计普通良性流量的误拒率；覆盖范围也限于 mock 非流式 HTTP 工具。跨调用推断、持久审批和生产 MCP/A2A 尚未验证。
总结
| 方向 | 本月关注的问题 | 代表工作 |
|---|---|---|
| Harness 演化 | 从轨迹提取更新，用保留集阻止回归，并测试恢复路径 | OpsHarness、AutoSaddler、EvoUndo |
| 运行时保护 | 用故障注入构造异常轨迹，在线告警后回滚或升级 | AgentChaos、Real-Time Detection and Repair、CURA |
| RCA | 检查可观测数据充分性、传播证据与缺证弃答 | TelemetrySuffBench、Beyond Fault Localization、The Abstention Protocol |
| 仓库修复 | 区分需求偏差和实现偏差，提供有界调试证据 | A Unified Issue Resolution Benchmark、DDBENCH |
| 测试评测 | 分开公开分数、整题通过、mutation 与目标调用 | SWE-bench Science、Feedback-Driven Test Evolution Audit、XREPOTEST |
| 工具治理 | 在可信工具边界执行资源和字段策略 | Out-of-Band Policy Enforcement |
OpsHarness 的核心是用来源案例与动态保留集筛选更新。运行时论文更关心异常能否被及时发现，测试论文则拆开了通过、覆盖和缺陷检出。三类结果不能互相替代。生产证据目前集中在 Azure 网络 RCA，其他实验多数来自公开基准、合成故障或 mock 工具环境，迁移到真实系统仍需重新校准与验证。