代理可靠性取决于上下文处理和可验证的交接
最有说服力的工作把上下文处理当作工程控制。qMLX 在一台 Mac Studio 上减少了长上下文的重复预填充，ContextOps 则在推理前检查输入载荷的结构。AgentTransfer 将同样的操作纪律用于文件交换。现有证据支持可检查的组件，但多个项目仍缺少独立基准测试。
主题概况
Agent Infrastructure
代理状态与交接完整性
代理团队可以在三个具体边界提高可靠性：跨轮次保留可复用的推理状态，在每次模型调用前检查组装好的上下文，以及验证代理之间传递的文件。每项改动都可以先从本地回归测试开始，再扩大部署范围。
编码代理通过上下文、轨迹和可执行检查获得信任
本周的编码代理研究设定了一条清晰标准：生成的工作需要上下文、轨迹和可执行检查，之后才值得信任。SWE-Edit、AutoMat 和 LiveFMBench 在编辑、科学复现和形式化规约中都显示了这种模式。
可检查的编码代理控制点
编码代理的采用正在转向更小、可检查的控制点：聚焦文件查看、更安全的补丁应用、产品决策检查、带回退行为的 SAST 分诊，以及包含轨迹、文件、测试和状态变化的评估记录。
编码代理的进展来自模型周边的接口
这一时期的基线仍然是可执行评测。最强的主张来自模型外部的部分：SWE-Edit 的读写分离、Agentic Harness Engineering 的 rollout 驱动 harness 编辑，以及 SAFEdit 的测试支撑修复循环。这个方向把上下文、工具、存储、安全提醒和推理成本都当作代理性能中可测量的部分。
面向编码代理的可执行保护措施
具体的切入点都在模型周边的代码编辑路径上：更窄的读取结果、专门的补丁执行、带测试的修复循环、可版本管理的 harness 变更，以及来自未覆盖代码的排序报告。团队在改变主开发流程之前，都可以先用现有仓库和可执行测试把这些点验证一遍。
验证和耐用工具边界正在成为 AI 编码系统的核心工程工作
当天最强的信号很简单：研究正在收紧 AI 编码和分析系统周围的控制回路。最好的论文把验证、类型化失败信号或可执行检查放到智能体原本会猜测的位置。Resilient Write 给出了最清楚的系统结果，而 Verify Before You Fix 和规格推断工作显示出同样的偏好：在安全和测试中先做有证据支撑的动作。
可执行验证层
具体工作正在转向工具边界和可执行检查。面向 MCP 风格编码代理的耐久写入层看起来已经可以直接产品化。在安全分析中，修复前先看执行证据看起来是 AppSec 工作流里的一个实用变化，并且在减少误修方面有明确收益。在 Java 验证和测试里，生成的反例测试看起来适合作为噪声较多的推断规格的过滤器。
编码研究正在围绕测试、运行时可见性和精确定位收紧
这一天最清楚的模式，是对编码系统的控制更紧了。论文更多依赖测试、运行时仪表和更窄的定位方式，让输出更容易打分和检查。ZeroCoder 给出了最强的量化结果，而安全和代理论文一直在追问同一个实际问题：模型应该看到哪些证据，人又该怎样验证它实际用了什么？
可验证的代码生成工作流
这组内容里最实用的变化是三个方向：围绕可执行测试构建的代码训练循环、面向小型内部软件的测试审查式工作流，以及针对编码代理审计的运行时覆盖检查。它们都把模型输出绑定到团队能核查的东西上：通过/失败矩阵、审查过的测试，或行级读取覆盖。
软件代理工作正在更明确地强调规格、检查和整仓库任务
当天最强的证据支持这样一种软件代理：它先写下任务，在仓库尺度上行动，并通过具体检查。ReCodeAgent 和 REAgent 在生成前加入规划或需求后，拿到了可测的提升。CLI-Tool-Bench 和 SWD-Bench 则把评测收紧到端到端行为、仓库理解和下游可用性上。
仓库任务验证
最近最清楚的方向，是在仓库代理前面加上明确的规格和验证步骤，再用端到端的仓库任务来测试它们，而不是只做局部代码检查。证据支持三个具体动作：在修 issue 之前先写结构化需求，把仓库迁移包装成带规划和验证检查点的流程，以及用空工作区的黑盒 CLI 行为测试来评估 0 到 1 的代码生成。