面向代理编写代码的验证关卡
近期最清晰的产品方向，是把验证放进执行闭环里。一条路径是外部策略层：只有满足可追溯性和测试义务的代理修改才能通过。另一条路径是代码仓库迁移工作流：把翻译后的测试和修复报告当作一等工件。第三条路径是面向 AI 编写代码的安全关卡：在选定的 diff 上证明可利用性，而不是依赖提示词或传统静态扫描器。
主题概况
Verification
验证和耐用工具边界正在成为 AI 编码系统的核心工程工作
当天最强的信号很简单：研究正在收紧 AI 编码和分析系统周围的控制回路。最好的论文把验证、类型化失败信号或可执行检查放到智能体原本会猜测的位置。Resilient Write 给出了最清楚的系统结果，而 Verify Before You Fix 和规格推断工作显示出同样的偏好：在安全和测试中先做有证据支撑的动作。
可执行验证层
具体工作正在转向工具边界和可执行检查。面向 MCP 风格编码代理的耐久写入层看起来已经可以直接产品化。在安全分析中，修复前先看执行证据看起来是 AppSec 工作流里的一个实用变化，并且在减少误修方面有明确收益。在 Java 验证和测试里，生成的反例测试看起来适合作为噪声较多的推断规格的过滤器。
编码代理研究正在把结构和外部检查变成主要控制面
这一天的研究表明，编码代理在控制被写下来并在模型外检查时会更好。最清楚的证据来自形式化规格、架构描述文件、harness 管理的内存和预算化评估。还有一个应用系统结果也很突出：LLM 引导的查询计划编辑在 Apache DataFusion 中带来了可测量的速度和内存收益。
Agent Runtime Infrastructure
这些证据里最清楚的可落地变化，是用于代码导航的结构化文件、代理 harness 里的记忆控制，以及在 Apache DataFusion 中经过执行验证的计划重写。每一项都给出了一种具体的构建或流程改动，并带有可测量的效果；更宽泛的结对编程和基准论文，更适合作为支持性背景，而不是立刻要做的产品方向。
软件代理研究正在收敛到可验证的训练循环和硬控制闸门
这一天最清楚的工作，是让软件代理更容易评分、更容易重跑，也更容易在检查失败时被拦住。Atomic-skill RL、Agent-CoEvo 和 Nidus 分别在训练目标、仓库修复和工程治理三个位置收紧控制环。和前几天相比，重点更少放在证明代理能在真实环境中行动，更多放在建立训练和验证设置，让这些动作可以被测量。
带执行检查的软件代理工作流
这里最可操作的工作，是把软件代理放进带硬执行检查的循环里。最清楚的近期构建方向有三个：一个会连同代码一起改测试的仓库修复工作器、一个面向高吞吐审计型运营的编译式工作流工具，以及一个用于微服务集成测试的在线依赖模拟器。它们都有明确用户、可控试点，而且报告结果具体到足以放进现有工程流程里验证。
软件研究正在围绕代码可验证的信号展开
今天的研究集中在能在运行时被检查的软件工作。最强的论文把推理接到代码执行、证明义务或测试行为上。Think-Anywhere、WybeCoder 和 SemLoc 都把松散的自然语言指导换成系统可以验证、打分或拒绝的中间信号。
可执行的语义检查
当模型输出被转成代码可以执行、评分或拒绝的检查时，软件工具会更有用。近期最清晰的产品方向是面向命令式例程的验证式代码生成，以及和测试行为绑定的语义故障定位。另一个更窄的训练方向也可行：在专有任务上，先按执行行为过滤自生成代码样本，再做偏好微调。