可执行的编程证据
可执行证据正在成为代理评估和编程工作流的实际标准。近期最清晰的落地方向有三个：一个可回放的评估器，用真实状态和工具轨迹来检查；一个仓库接入层，在补丁生成前证明环境能跑起来；以及一个在没有测试用例时使用教师样例的科学编程流程。
主题概况
Software Engineering
验证和耐用工具边界正在成为 AI 编码系统的核心工程工作
当天最强的信号很简单：研究正在收紧 AI 编码和分析系统周围的控制回路。最好的论文把验证、类型化失败信号或可执行检查放到智能体原本会猜测的位置。Resilient Write 给出了最清楚的系统结果，而 Verify Before You Fix 和规格推断工作显示出同样的偏好：在安全和测试中先做有证据支撑的动作。
可执行验证层
具体工作正在转向工具边界和可执行检查。面向 MCP 风格编码代理的耐久写入层看起来已经可以直接产品化。在安全分析中，修复前先看执行证据看起来是 AppSec 工作流里的一个实用变化，并且在减少误修方面有明确收益。在 Java 验证和测试里，生成的反例测试看起来适合作为噪声较多的推断规格的过滤器。
软件智能体研究正收紧到可执行证据和控制循环上
本周的软件智能体研究在“结论能否通过执行和明确控制来检验”这一点上最有说服力。重心很务实：更严格的评估、更紧的上下文与权限边界，以及更强地使用编译器、测试和运行时信号。ProdCodeBench、SWE-STEPS 和 Squeez 很能体现这种重点。
可执行的 agent 工作流基准
本周指向了 coding agent 工作流中的三个实际改动：用真实生产会话搭建离线回放基准，在 agent 循环中加入工具输出裁剪以减少重复上下文加载，以及按相互依赖的 PR 序列来评估 agent，而不是一次只看一个任务。这三个方向都依赖可执行的检查方式，例如稳定测试、保留的仓库状态，以及可测量的 token 或延迟变化。
Software-agent evidence is getting tighter around control loops, compilers, and architecture checks
这一天的研究最强的部分，是那些可以用明确控制来检查的软件代理。证据最扎实的工作把模型接到编译器、工单状态、校验器门控或经过基准测试的设计工件上。这让我们更清楚地看到代理现在能做什么，以及可靠性还会在哪些地方失效，尤其是在架构理解上。
软件代理控制门
软件代理工作里的控制面现在变得更具体了，尤其是在工单、编译器和评审门给系统划出硬边界的地方。最清楚的近期落地方案是：用于有边界维护工作的 Jira 关联执行循环、利用编译器反馈提升编译成功率的 GnuCOBOL 修复服务，以及在提示词驱动的系统变更被当成普通代码修改通过之前将其拦下的架构评审门。
编码代理研究正变得更难作弊，也更容易验证
这一阶段最强的内容集中在那些要面对真实状态、真实失败模式和真实执行后果的编码代理上。SWE-STEPS 和 ABTest 让评估更具体。GrandCode 给出一个醒目的现场结果，而 IndustryCode 用更难的工业任务把上限拉回到现实。当前重点更少放在一次性补丁是否成功，更集中在代理能否在时间、工具和仓库历史中保持稳定。
仓库代理安全门
代码代理评估正在转向真实仓库状态、真实用户失败轨迹和真实扩展安全检查。眼下最明确的近期开销变化，是基于支持失败构建内部回放套件、带仓库健康评分的有状态 pull request 序列基准，以及在第三方技能接触开发者机器或 CI 之前设置隔离步骤。