过去一个半月（2026.06.16—07.31），软件工程领域的 Agent 研究明显向执行过程深入。根因分析开始检查模型能否还原故障传播链、能否自己操作生产式观测工具；编码 Agent 的评测也从最终通过率转向早期错误、恢复窗口和 PR 测试覆盖。Harness、技能和记忆不再只是提示工程配件，它们逐渐被当作需要静态分析、回归测试和版本治理的软件资产。
一、RCA 评测：从根因标签走向因果过程和真实值班环境
RCA 评测正从最终根因标签扩展到诊断过程。只检查标签，很容易把复杂诊断变成服务名匹配；生产环境还要求模型自行寻找证据、操作工具，并在信息不足时控制误报。
OpenRCA 2.0 把评测对象从最终答案扩展到完整因果过程。它用 PAVE 分步标注协议，根据已知干预重建“故障注入—中间传播—症状暴露”的路径，构建了 500 个带过程标注的跨系统 RCA 实例。11 个前沿模型在严格恢复完整根因集合时平均成功率只有 20.7%；模型虽然能在 76.0% 的样本里命中至少一个正确根因服务，其中只有 61.5% 能把命中的服务放进经过验证的传播路径。这个差距说明，点中服务和完成可落地诊断之间还隔着证据组织与因果解释。
How Far Can Root Cause Analysis Go on Real-World Telemetry Data? 继续追问 RCA 失败到底出在数据还是推理。论文在 OpenRCA 的指标、日志和调用链上运行结构化多智能体流程，再用反向推理 Agent 从正确答案回查支持证据，把失败分成“证据存在但没有被利用”和“遥测本身缺失或含糊”。分析发现，多数失败案例并不缺证据，主要瓶颈是模型不能正确组合跨模态遥测信号。继续增加遥测量未必有效，检索、对齐和证据链构造更值得优先排查。
ORCA-bench 把 Agent 放进接近真实值班的环境。基准包含带 OpenTelemetry 插桩的微服务系统、6 天约 50 GB 的指标、日志和链路数据，并开放 Prometheus、Jaeger、OpenSearch/Grafana 接口和完整源码，共构造 1079 个 RCA 任务。五种前沿 Agent 在真实输入设置下的最佳准确率只有 25.3%，困难任务降到 10.0%；较弱模型在 40% 的事件报告里会捏造不合理根因。拿掉源码访问后，所有指标都下降。这个测试床仍比真实生产系统小且稳定，论文给出的差距更接近乐观下界。
二、日志与生产诊断：数据清洗、故障表征和因果图演化
日志研究覆盖检测器的输入、表征与诊断环节：清理无助于还原执行行为的日志，把 SRE 的故障分析经验写入预训练目标，再用 LLM 修正受约束的因果图。
Cleaning Logs for Downstream Tasks (Registered Report) 是一篇注册报告，研究异常检测之前的日志质量。作者提出 LogPurifier，根据日志模板依赖识别并移除不能帮助重建执行行为的 free-standing messages，再评估清洗对模型推断和异常检测的影响。论文目前给出的是方法和受控实验设计，还没有最终性能结果，不能把它写成已经证明有效的清洗方案。它提出的问题很实际：日志保留策略本身会改变下游任务，解析完就把所有模板交给模型并非中性的处理方式。
Bifrost（ASE 2026）为日志故障诊断设计“易失效表征”，用执行流预测、异常事件判别和系统组件感知三个自监督对比学习任务，统一支撑异常检测、根因定位和故障识别。在 BGL、Hadoop、Thunderbird 以及阿里巴巴工业 MLaaS 平台上，相比参数规模相近的预训练语言模型，三类任务总体平均提升 20.81%；异常检测 F1、根因定位 HR@k 和故障识别 Macro-F1 的平均提升分别为 9.83%、18.28% 和 20.88%。它仍然依赖既定日志结构和数据窗口，告警关联、证据解释与闭环修复没有被完整处理。
EvoCause 采用“LLM 离线修图、确定性模型在线诊断”的分工。系统先从告警日志学习初始因果图，LLM 根据告警语义和专家历史诊断提出边编辑，程序再检查节点身份、无环性和标注集效果，只保留更好的图。在线 RCA 不再调用 LLM，预测路径更透明，成本也稳定。论文发布的 TeleRCA 含 485681 条生产电信告警、194 种告警类型和 5621 个资源；匿名化告警名称后，Node F1 和 Case EM 分别下降 6.12 和 8.04 个百分点，说明告警语义确实参与了因果结构修正。
KRCA 已在快手生产环境落地。它先从受影响 API 下钻缩小候选服务，再用异常指标生成高召回的骨架因果图，最后由记忆增强多智能体验证候选关系并生成报告。根因服务定位 AC@1 达到 0.88，故障类型分类 AC@1 达到 0.79，相比最强基线绝对提升至少 31%；系统在快手生产环境运行超过 6 个月，平均诊断时间降低 77.3%。它对指标、调用关系和生产知识库的依赖较深，跨系统迁移仍需要重新适配。
三、Agent 失败是一条过程：长轨迹归因、早期征兆和运行时修复
轨迹诊断开始处理三个具体问题：超长轨迹中怎样主动寻找证据，错误何时从可恢复变成不可恢复，诊断结果怎样转成下一轮可执行的干预。
SAFARI 把长程 Agent 的故障归因改造成工具增强的主动调查。模型不再一次读取完整轨迹，而是按需搜索局部片段，用短期记忆维持调查状态。在 Who&When 上给定 100 万 token 预算时，它比已有方法提升约 20%；在 TRAIL 的 GAIA 子集、2.5 万 token 预算下提升约 19%。即使故障位置超过模型原生上下文 5 倍，仍能保持 0.58 precision。这种查局部证据、逐步更新假设的做法，也适合迁移到长 incident timeline 和多源日志分析。
Failure as a Process: An Anatomy of CLI Coding Agent Trajectories 对 7 个前沿模型、3 个 CLI Agent 脚手架在 Terminal-Bench 上的 3843 条轨迹做过程分析，人工检查其中 1794 条完整有效轨迹，覆盖 6.3 万多个执行步骤。论文归纳出 14 条发现，其中最关键的一点是：失败通常由认知性错误驱动，最初几步已经埋下问题，却往往要等到接近不可恢复时才暴露。最终 resolve rate 会把这段过程全部压平，也无法告诉开发者监控应该插在哪里。
AgentTether 进一步把诊断接到运行时修复。它把执行轨迹抽象成 Transition Units，构建依赖感知的 Critical Transition Graph，定位真正改变失败走向的关键状态转移，再把原因转成行为级指导写入 Repair Memory。重执行时，系统还能加入受保护的运行时干预。在 261 个 τ-bench 任务上，Banking 域中修复了 Qwen3.7-max 的 59.04% 初始失败任务，以及 GPT-5.4 的 65.12% 初始失败任务，同时减少轮次和 token。这里的比例针对初始失败子集，不能当成整体成功率。
四、Harness 与技能：从探索性配置变成需要回归治理的软件资产
Harness、skills 和运行时循环已经成为 Agent 的软件资产。稳定流程需要固化，技能升级需要回归测试，持续演化也要避免破坏旧能力。
Progressive Crystallization: Turning Agent Exploration into Deterministic, Lower-Cost Workflows in Production（微软 Azure）让 Agent 负责探索未知故障，再把反复成功的轨迹逐步固化为确定性流程。系统在 Agent 探索、混合执行和完全确定性流程之间升降级，用运行证据和安全检查控制转换。在 Azure 网络运维系统运行 8 个月后，确定性执行占比从 0% 提升到 45%；事件量翻倍的同时，单事件 Agent 成本下降 70% 以上。稳定知识最终沉淀为可测、可审计的流程，比长期依赖随机生成更适合生产运维。
The Regression Tax: Decomposing Why Skills Help and Hurt LLM Agents 专门检查技能升级的副作用。论文在两个办公自动化基准、3 种模型与 Agent 运行栈上完成 5832 次有技能/无技能配对运行，把结果拆成新增成功、保持成功、持续失败和回归。表现好的技能库往往赢在回归更少。常见问题包括技能描述渗透到无关任务、固定流程压过实际输入、流程服从替代最终结果验证。实验集中在 OfficeQA-Pro 和 SpreadsheetBench，每个条件只运行一次，结论迁移到编码和运维 Agent 还需继续验证。
这两篇放在一起看，技能和 harness 的管理方式已经很接近普通软件：要有观测数据、晋级条件、回滚路径和回归测试。平均成功率无法完整反映更新质量，旧任务是否被破坏也应进入发布门禁。
五、Agent 控制面：静态分析、依赖图与证据门控
很多 Agent 故障来自模型之外的程序结构：循环终止条件、prompt 到工具的数据流、状态迁移和“任务已完成”的判定。传统软件分析正在进入 Agent 框架，确定性控制面也开始接管高风险决策。
When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents 研究 Agent 程序里的无限循环。它把不同框架转换成统一的 Agent IR，构建 Agentic Loop Dependence Graph，恢复显式循环和框架隐式引入的反馈路径，再判断路径能否无界到达高成本工具或状态增长操作。对 6549 个真实 Agent 仓库扫描后，工具报告 74 个潜在问题，人工确认 68 个真实失败，精度为 91.9%。论文没有给出完整召回率，动态生成的工具和路由也可能逃过静态恢复。
AgentFlow 面向更一般的依赖分析。它构建框架无关的 Agent Dependency Graph，用类型化节点表示 Agent、prompt、模型、工具、记忆和控制策略，再连接组件依赖、控制流和数据流。在覆盖 5 个代表性框架、5399 个真实程序的 AgentZoo 上，论文识别出 238 个 prompt-to-tool 污染式风险。这些是静态风险，不能直接当成已被利用的漏洞；它的价值更像 Agent 时代的 SBOM、污点分析和变更影响分析底座。
Proof-or-Stop: Don’t Trust the Agent, Trust the Evidence – Loop Engineering for Verifiable Evidence-Gated Lifecycle Control 处理另一个常见问题：Agent 自称已经测试、审查或完成，并不代表状态真的成立。它只允许与当前源码绑定、可机械验证且仍然新鲜的证据触发生命周期迁移，用证据门控状态机控制无人值守循环。在 10 个机制场景和 18 类篡改中分别实现 0 次错误完成和 0 次错误接受；9240 个实验单元的消融里，证据门控把“可见测试通过、隐藏测试失败”的放大事件从 31/1800 降到 2/1800。这套机制仍受测试规格质量限制，证据门控能证明检查确实执行过，不能证明检查已经覆盖所有风险。
六、仓库级代码：上下文更长之后，证据选择和基准质量成了瓶颈
仓库级代码研究转向三个问题：模型是否真正理解跨文件依赖，哪些上下文应该保留，评测任务是否对齐真实修复。
RepoReasoner 用输出预测和调用链预测评测仓库级代码推理，并通过 pytest 动态追踪构造真实调用链，再改写输入输出以降低记忆污染。即使提供理想上下文，7 个先进模型中最佳模型的输出预测 Pass@1 也只有 69.1%；调用链预测呈现高精度、低召回，模型能找到部分正确依赖，却经常漏掉多跳关系。上下文容量继续增长后，依赖链完整性和噪声控制仍是独立问题。
MRCoder 用 Map-Reduce 式流程筛选仓库上下文。Map 阶段让轻量草稿模型在不同分区生成草稿，再按 API 一致性和逻辑相似度筛选；Reduce 阶段聚合精炼上下文并并行验证。在 CoderEval 和 DevEval 上，它减少 30%—50% 的 token，推理时间最多降低 52%，同时提升生成准确率。论文摘要没有给出统一的准确率增幅，使用额外草稿模型也带来了新的系统复杂度。
DepRepair 面向依赖升级造成的跨仓库破坏。它从上游发布说明和 API diff 里过滤证据，定位下游使用点，按变更子类给出修复指导，并用 Docker 中的消费者测试做可执行判定。DepBench 覆盖 4 个生态、95 个真实升级实例，GPT-5.5 和 Claude Opus 4.6 的通过率分别达到 89.5% 和 82.1%。未经整理的上游证据会让 Agent 通过率下降 7—23 个百分点，说明证据质量比“上下文越多越好”更关键。
PAIChecker 在 SWE-bench Verified 中发现 13.6% 的实例存在 PR 与 Issue 不对齐，并归纳出 5 类模式、11 种场景。它用多智能体识别失配，再做代码级验证；在 SWE-Gym 和 SWE-bench Multilingual 上的二分类准确率最高分别为 92.12% 和 91.67%。仓库级 Agent 的方法差距已经不大时，任务描述、目标补丁和可执行测试之间的错位会直接影响排名。
七、生成补丁之后：复现测试、PR 覆盖和 Agentic Review
补丁生成后的验证包括缺陷复现、测试覆盖和代码评审。Issue 能否转成可执行测试、改动是否被测试覆盖、评审意见能否推动补丁修订，决定了结果是否可验证。
ReProAgent 从自然语言 Issue 生成 bug reproduction tests，把流程拆成缺陷定位、根因分析、测试规划和测试生成，并结合文本检索、仓库图和运行环境交互。在 SWT-bench-lite 和 verified 上分别复现 58.43% 和 70.30% 的 Issue，相比同骨干模型的 OpenHands 提升 20.43 和 7.90 个百分点，平均成本约 0.14 美元一个实例。成功复现不等于根因判断完全正确，但它为后续补丁验证提供了可执行起点。
Test Coverage Analysis of Agentic Pull Requests 检查 4882 个 Java/Python Agent PR 的真实测试情况。修改受测代码的 PR 中，只有 49.6% 同时改了测试；现有测试覆盖 Agent 改动行的比例在 Java 中为 61.5%，Python 只有 27.0%。64.8% 的 Python PR 没有任何改动行被现有测试执行，异常处理结构的漏测率在 Java 和 Python 中分别达到 86.0% 和 81.0%。这些数字测的是覆盖，不等同于缺陷检出能力，但足以说明“测试通过”可能只代表现有测试根本没走到新代码。
SWE-Review 把一次性 PR 生成扩展成生成、审查、修订、重新验证的循环。Reviewer Agent 主动探索仓库、判断是否接受 PR、输出结构化修改意见，再由 Coding Agent 修订补丁并跑测试。论文同时构建 SWE-Review-Bench 和 SWE-Review-Traj，报告审查决策、修订后的 resolve rate 和测试时扩展都优于固定上下文的单轮审查。每日推送没有给出统一的具体增幅，这里不补数字。闭环收益仍取决于测试套件质量，评审 Agent 的额外成本也要纳入部署判断。
总结
| 方向 | 核心变化 | 代表工作 |
|---|---|---|
| RCA 评测 | 从根因标签扩展到因果链、工具操作和真实值班输入 | OpenRCA 2.0、ORCA-bench |
| 日志与诊断 | 清洗输入、学习故障表征、离线演化因果图 | Cleaning Logs for Downstream Tasks (Registered Report)、Bifrost、EvoCause、KRCA |
| 轨迹可靠性 | 主动调查长轨迹、识别早期错误、诊断后运行时干预 | SAFARI、Failure as a Process: An Anatomy of CLI Coding Agent Trajectories、AgentTether |
| Harness 与技能 | 稳定流程结晶，技能更新纳入回归测试 | Progressive Crystallization: Turning Agent Exploration into Deterministic, Lower-Cost Workflows in Production、The Regression Tax: Decomposing Why Skills Help and Hurt LLM Agents |
| Agent 控制面 | 静态分析程序结构，用外部证据控制状态迁移 | AgentFlow、Proof-or-Stop: Don’t Trust the Agent, Trust the Evidence – Loop Engineering for Verifiable Evidence-Gated Lifecycle Control |
| 仓库级代码 | 从扩大上下文转向证据筛选、依赖推理和基准审计 | RepoReasoner、MRCoder、PAIChecker |
| 测试与评审 | 从生成补丁走向复现、覆盖、审查和修订闭环 | ReProAgent、SWE-Review |
Agent 研究正转向运行过程的可观察性、错误归因、证据约束和更新后的能力保持。AIOps 与 LLM4SE 在这些问题上逐渐汇合：根因分析需要处理长轨迹和跨模态证据，编码 Agent 也需要日志、监控、回归门禁和故障恢复。后续可以关注轨迹级诊断与生产遥测的结合，以及技能、harness 和 Agent 工作流的持续验证。