九月的软件工程研究中，一条值得关注的主线是：为“任务已经完成”建立更具体的证据。代码修复需要满足维护者的约束，工具调用需要确认外部效果，根因分析需要辨别遥测证据与数据集先验，智能体积累的经验则需要在新任务上证明价值。这些问题分别落在测试、分布式系统、AIOps 和智能体工程中，却共同决定了自动化结果能否被信任。
本文从 9 月 1—30 日的每日论文推送中选取 11 篇重点工作，逐篇核对原文，月份按推送日期归类。延续八月软件工程前沿对 Agent Harness、运行时保护与验证证据的关注，本月进一步追问：检查是否覆盖了目标，执行是否产生了预期效果，以及改进能否迁移到新的环境。
一、测试通过，需要说明通过了哪些要求
SWE-Gate 把维护者的审查要求纳入代码智能体评测。它从真实 PR 评论中提取可执行约束，再在兼容仓库中构造修复任务，为每题分别设置功能测试与约束测试。异常信息是否保留、接口是否兼容、资源是否正确释放，都可以成为独立的验收条件。
在 75 个 Python 仓库的 303 道构造任务上，四个模型得到的 644 份功能测试通过补丁中，仍有 221 份违反约束，占 34.3%。这个比例的分母是通过功能测试的模型—任务结果，且基准专门构造了能够区分功能与约束的任务，因此不能直接推算真实开发中的缺陷比例。它的价值在于给出一种可执行的评测方式：把“修好报错”和“满足工程要求”分别计量。
Silent Success: A Release Gate That Passed on Checks It Never Ran, and Eight More 进一步检查验收程序本身。论文记录的发布门禁中，两项假阳性检查实际执行了 0 项，一致性检查只执行了 6/8 项，流水线却连续约两周显示绿色。原因是检查失败的案例先被过滤掉，门禁随后只统计剩余结果中的违规数，“没有观察到违规”于是被解释为通过。
作者的修复把结果分为通过、违规、无法确定，并在 CI 中让“无法确定”阻断发布；预期检查数量从用例定义生成，与实际执行数量一起输出。这项案例研究没有提供行业发生率，却指出一个容易遗漏的验收层次：既要检查要求是否满足，也要检查该运行的检查是否真的运行。即便数量补齐，检测器能否发现预期缺陷仍需另行验证。
二、工具执行的可靠性，取决于边界上的契约
When Tool Calls Succeed but Workflows Fail: Anomalies at the Agent-Tool Boundary 将三个容易混淆的状态分开：外部世界发生了什么、运行时知道什么、工作流分支决定提交还是撤销。超时表示结果尚不明确；撤销一段推理或恢复工作区，也不会自动撤回已经发出的邮件或部署。论文据此整理重复提交、撤销后的残留效果、依赖已撤销动作等异常，并讨论操作标识、结果查询、暂存与补偿等工具契约。
Where Does Exactly-Once Live? Model, Harness, and Tool-Contract Effects on Duplicate Side Effects in LLM Agents 用 LIMBO 沙箱检验了其中最具体的问题：写操作超时后，怎样恢复而不重复执行？它在六类模拟服务上注入故障，以真实提交的副作用账本评分；即使重复扣款后来被退款，也仍算发生过重复效果。
在明确要求每个动作只执行一次的设置下，六个较强模型面对“操作已提交、确认丢失”时，重复率合计为 0.5%；面对“原请求仍在途中、稍后提交”时升至 56%，传输层重投时为 74%。这些都是相应故障已触发时的比例。关键差别在于，回读为空可能只是原请求尚未提交。没有已知在途时间上界时，有限次验证无法据此保证重试安全。
论文随后改变服务契约，让写操作支持幂等键，重复效果明显减少；剩余错误还包括第一次未带键、重试时换了键。由此可以看出，稳定的操作身份和服务端去重，需要与模型的恢复策略一起设计。该实验使用模拟服务和设定的延迟分布，不能把其重复率当作真实产品故障率，但它清楚地区分了“推理可以解决的不确定性”和“接口必须提供的保证”。
三、根因分析要分清证据、先验与长尾
EviRCA 将遥测处理与 LLM 推理解耦。确定性模块先把指标偏离、慢调用和日志突增整理成组件级证据卡，LLM 再通过固定只读工具分析这些证据。这样可以分别追踪“真实组件没有进入候选”和“看到了证据仍判断错误”，避免把两者混成一次诊断失败。
在 OpenRCA 的 335 个查询上，两个模型后端的严格正确率为 43.9% 和 40.6%，对比实验中最佳基线为 15.2%；这里要求被询问字段、故障数量及规定容差内的时间均正确。单故障失败案例中，22.5% 的真实组件根本未被提取。这提示根因分析的改进需要同时观察证据召回和证据上的判断能力。实验使用离线全日基线、已知故障数量和闭集原因，应用到在线开放场景时还需要处理这些前提。
Does Graph Structure Earn Its Place in Microservice Root-Cause Analysis? A Controlled Study on RCAEval, and What the Benchmark Was Really Measuring 则检查高分究竟来自哪里。在 RCAEval RE1 的三个系统、375 次故障注入中，每个系统的故障集中在五个服务。仅根据训练集中故障服务的频率排序、不读取当前遥测，就能在 99.7% 的留出事故中把真因放入前五。这个数字是前五命中率，并非首位定位准确率。
在作者的分布内对照中，图模型与去掉邻居聚合的骨干模型，Avg@5 分别为 0.867 和 0.862，未观察到可靠的图特异增益。研究范围只有三个系统和一种 GNN 架构族，不能据此否定图结构的普遍价值；更值得带走的是评估方法：先报告候选先验能达到什么水平，再衡量遥测与拓扑各自增加了多少信息，并检查跨系统表现。
日志层也有类似的测量问题。TAILOR 统计的 Loghub-2.0 数据中，出现次数少于五次的模板约占全部模板的 20%，对应消息却不足总日志量的 0.01%。按消息量汇总的指标，很容易淡化这部分模板的错误。TAILOR 保持日志结构，只生成同类变量的替代值来增强稀有组，再用原始消息验证模板。在 13 个含稀有模板的数据集上，稀有组解析准确率均值由 EFParser 的 0.67 提升至 0.80；这证明的是解析层的收益，下游异常检测与根因分析收益仍需单独检验。
四、经验能够积累，还要证明能够迁移
FIRE 从已观察到的失败中提取运行时规则，在特定前置条件和事件触发时，补充简短指令或阻止工具调用。例如，结束任务前确认服务仍在运行，修改数据库前保留原始证据。规则与失败发生的时机对应，使经验能够直接介入执行过程。
在 87 道 Terminal-Bench 2.1 任务上，每个配置各运行两次，GPT-5.6 Sol 的“两次都成功”比例从 64.4% 提高到 73.6%，而“至少一次成功”只从 86.2% 提高到 87.4%。前者更直接反映重复交付的稳定性。同一配置的成本增加了 47.7%，规则又来自开发过程中观察过的任务，因此这项结果说明了特定失败干预的潜力，跨任务泛化与成本仍要分别考察。
月底的 XRepoSkill 将重点放到迁移：对齐同一问题的成功与失败轨迹，从关键分歧中提出带可执行行为谓词的规则，再用其他轨迹检验关联，并合并跨仓库支持的规则。执行新任务时最多选择三条，避免把整套经验一并塞入上下文。
在与技能学习仓库不相交的测试中，三种模型的平均解决率在 200 道 SWE-bench Pro 任务上从 47.8% 提升至 53.8%，在 DeepSWE 上从 33.9% 提升至 44.2%。历史行为筛选仍是关联证据，不能证明每条规则都有独立因果效果；但未见仓库上的最终任务表现，为经验是否具有迁移价值提供了直接检验。这里应关注规则如何被验证和选择，而不只是技能库有多少条。
Compact Documentation for Coding Agents: A Benchmark, an Optimizer, and Why It Does Not Transfer 提供了一个必要的对照。它先优化代码描述，使模型仅凭描述重建代码时更容易通过原测试；到了源码可见的修复场景，却未观察到稳定收益。在最大一组配对可评分的 58 道任务中，只提供问题、加入检索上下文、加入压缩描述，分别解决 33、30、29 道。短描述、小样本和非随机掉样限制了推广范围，这也不能证明文档普遍无用。它提醒我们：中间产物更完整、重建分数更高，仍需要通过真实任务来检验增量价值。
五、可观测性开始回答“时间花在哪项工作上”
AgentPProf 把长程智能体轨迹组织成“定位认证问题”“验证修复”等嵌套职责区间，再将 token、耗时和系统事件确定性地汇总为标准 pprof 数据。这样，工程师可以跨运行比较哪类工作反复消耗资源，而不必逐条翻阅工具调用。
它把两件事分开处理：语义标签由模型推断，资源计量由原始事件聚合。在 405 条 CodeTraceBench 轨迹上，语义分组的 B³ F1 为 0.764，高于统计分组的 0.663；但在 OSWorld-Human 上，同一提示下的分组效果不及统计方法，说明任务切分尺度仍依赖场景。论文还展示了一个具体闭环：剖析发现工具调用 ID 兼容层问题，一行修复后，在 23 个留出场景中减少约 19% 的 token，并满足预设质量非劣标准。这个数字属于该次修复，不能解释为剖析器对所有任务的固定节省。
可观测性的作用由此更加具体：让成本能追溯到某类行为，让问题能落到可修改的位置，再用留出场景验证修复效果。语义解释、准确计量和修改后的收益，各自需要自己的证据。
六、本月重点一览
| 方向 | 本月关注的问题 | 代表工作 |
|---|---|---|
| 测试与验收 | 要求是否被表达，该运行的检查是否实际执行 | SWE-Gate、Silent Success |
| 工具执行 | 如何确认外部效果，如何避免恢复时重复执行 | Agent-Tool Boundary、Exactly-Once / LIMBO |
| AIOps 证据 | 候选召回、故障先验与稀有模板分别贡献了什么 | EviRCA、图结构 RCA 对照研究、TAILOR |
| 经验迁移 | 运行时规则和上下文材料能否改善新任务 | FIRE、XRepoSkill、Compact Documentation |
| 智能体可观测性 | 把资源开销归到具体工作，并验证改动的收益 | AgentPProf |
把这些工作放在一起，九月最值得继续追踪的进展，是完成条件正在变得可检查：测试声明它覆盖的要求和实际检查总体，工具暴露操作身份与结果状态，诊断系统区分证据缺失和判断错误，经验库接受跨仓库任务检验。它们为智能体进入更长、更复杂的工程流程提供了具体抓手，也让下一次性能提升能够回答：究竟改善了哪一个环节，在什么条件下成立。