编码代理需要仓库级测试和上下文防护
当天最强的信号是，围绕已经在处理多文件工作的编码代理，工程纪律开始变得更重要。DeNovoSWE、EsoLang-Bench 和 DeLM 都在测试代理能否构建完整仓库、通过执行进行适应，并且不浪费调用就共享已验证进展。安全论文给出明确警告：看起来正常的上下文，也能把生成或分析出来的代码带向不安全行为。
主题概况
Multi Agent Systems
Repository-scale code assistant safeguards
代码代理评估正在转向可执行的仓库级工作、基于源代码的测试生成，以及对送入模型的上下文做安全检查。实际工作是加入跨文件和依赖关系的验收测试，基于实现证据生成 API 断言，并在评论、文档、示例和附近代码进入代码生成提示前先筛查它们。
Agent reliability is an engineering control problem
这一天最强的信号是运行时纪律。STORM、OpenComputer 和 DIFFCODEGEN 指向同一个要求：在团队信任更长的自主工作之前，代理需要最新状态、可执行检查，以及围绕模型输出的低成本验证。
Agent State Verification
Agent 部署正在获得具体的控制点：并行编码代理的写入时状态检查、桌面任务的可执行状态验证器，以及用于选择或延后生成代码的运行时证据。共同模式很简单：记录代理看到的内容，把动作和当前状态对齐检查，并在系统拒绝或转派输出时保留机器可读的原因。
可执行证据主导智能体软件可靠性研究
当天最强的信号是面向智能体软件的可执行证据。论文用生成输入测试代码，用遥测诊断失败运行，并围绕技能或工具动作施加约束。现在，智能体输出要先有可检查的轨迹，团队才会信任它。
Execution Checks for Coding Agents
编码代理可靠性研究正在收敛到围绕生成代码、失败运行和可复用技能的几个小而可实现的检查。实际模式是在团队已经做出信任决策的地方收集执行证据：候选选择、重试指导或技能维护。
可执行检查正在给软件代理设定门槛
5 月 5 日的软件 AI 论文把大语言模型（LLM）放到可执行检查下。MOSAIC-Bench 暴露了分阶段编码代理的漏洞。TDD-Bench-Java 和 PoVSmith 检验生成的产物是否会失败、通过、编译，或者触发真实 bug。
Executable Validation for Agent-Written Java Code
可执行测试正在成为代理编写代码的实际控制点。最清楚的流程变化是：多票据代理工作的累计安全审查、用于依赖分诊的自动生成 JUnit 漏洞证明测试，以及在接受 Java issue 修复前先做 fail-to-pass 复现测试。