编码代理正在被要求证明、审计并为自己的工作买单

仓库级编码代理正在按其对执行证据的使用情况接受评估。TrajAudit 面向失败的代理运行，预测最早的决定性错误步骤。它的 RootSE 基准包含 93 个失败实例、超过 4,500 个执行步骤，以及约 2,700 万字符。论文报告说，在比基线至少少用 18% token 的情况下，定位准确率提升超过 24.4 个百分点。

EviACT 在自动程序修复（APR）中采用同样的方法。它把失败测试证据带入定位阶段，在测试验证前拒绝格式错误或无法构建的补丁，并在完整回归前重新运行最初失败的测试。使用 GPT-4o 时，它在 Defects4J 2.0 和 SWE-bench 变体上给出领先的修复率；在有基线成本可比时，每个 bug 的 API 成本低 70.1–88.6%。

MocklessTester 为 Java 测试加入了同类思路的更底层版本。它挖掘真实的依赖使用，编译并运行生成的 JUnit 测试，并在符号和类型状态约束下修复失败。它在 Defects4J 上报告的平均行覆盖率为 88.82%，分支覆盖率为 83.74%，执行到的真实依赖代码比基于 mock 的基线更多。

验证工作把规范视为失败来源。Verus-SpecGym 测试语言模型代理能否把非正式编程任务翻译成忠实的 Verus 规范。这个基准有 581 个来自 Codeforces 的任务。表现最强的模型解出 77.8%，而 LLM-as-a-judge 评估器漏掉了 26% 被可执行检查捕获的失败。

ConVer 使用大语言模型（LLM）编写 C 函数契约和循环不变量，然后让 ESBMC 作出通过或失败的判断。它的结果随基准难度而变：45 个 Frama-C 程序的成功率为 82–96%，一个较小的 X.509 解析器基准为 33–50%，LF-Hard 程序转换为 C 后为 67%。

这篇面向 Lean 的验证文章给出了更广泛的理由。它认为 AI 生成的软件需要独立的证明检查器，因为审查和测试跟不上生成代码的规模。文中的例子包括基于 Claude 的 zlib 形式化，以及 Lean 的 Mathlib，后者被引用为拥有超过 200,000 个形式化定理。

SEC-bench Pro 用真实的 JavaScript 引擎漏洞提升了安全代理评估门槛，并提供可复现的有漏洞、已修复和最新镜像。数据集在 V8 和 SpiderMonkey 上共有 183 个已验证漏洞。表现最强的单代理配置在 V8 任务上解出 32.0%，在 SpiderMonkey 任务上解出 38.8%。只按崩溃评分的评测器会把成功数多算 43.6%，所以目标归因会改变分数。

测试代理工作流加入了结构视角。所提方法把代理工作流转成一个由代理、工具、允许调用、受限调用和委派边组成的图。在 10 个从 SDK 派生的工作流上，生成的场景覆盖了 75 个允许工具义务中的 54 个，以及 48 个委派义务中的 36 个。对受限工具的探测在 248 个受限工具义务中发现了 23 次违规。

Keyblind 给密钥加了一道实用防线。它给代理提供假的 .env 值，只在命令运行时注入真实密钥。这里的证据来自产品而不是基准，但威胁很具体：项目提到，2025 年有超过 100,000 次暴露密钥的 LLM 对话被搜索引擎收录。

GENESIS 展示了专用代理系统如何为技术领域而构建，在这些领域里，一个小小的 API 或规范错误就可能让部署失败。对于无线接入网（RAN）工作，它把意图路由到合成、测试、加固、优化、发现或安全流水线。验证通过仿真、模拟和空口测试床进行。论文报告两个功能实现案例研究都达到 100% 成功，而使用 Opus 4.7 的 Claude Code 在这些案例中没有给出可工作的实现。

企业成本信号没有那么技术化，但很难忽视。Uber 据报在 4 个月内花完了 2026 年 AI 编码工具预算。其 COO 说，公司目前还不能把 Claude Code 的使用与有用消费功能的可测增长明确对应起来。这让按 token 计费的代理使用同时成了管理问题和工程问题。