编码代理可靠性测试架
编码代理的采用已经适合转向更窄的测试架工作：分离的 bug 修复角色、围绕不可靠工具的恢复测试，以及面向库行为重叠团队的基于意图的测试迁移。证据最强的部分来自报告可执行评估、测量回归，或通过工作流水线发现真实缺陷的论文。
主题概况
Software Engineering
编码代理需要普查数据、成本控制和安全证据
这一时期的重点是编码代理问责：测量真实使用情况、控制工具成本，并在代码运行后检查安全性。最有力的证据来自 1.8 亿仓库普查、贝叶斯控制和 BigBag；产品项目补充了治理需求，但评估较少。
编码智能体运行保障
编码智能体的采用现在需要运行记录，这些记录要能应对微弱痕迹、高成本验证，以及只停留在静态检查层面的安全声明。实际工作包括仓库多信号普查、智能体运行的验证器预算控制器，以及面向代码和工具使用的漏洞利用支撑评审关卡。
编码代理需要经过失败测试的指导和带关卡的执行
这一时期的编码代理工作由运行证据来判断：用失败来测试仓库指令，用基线测试为拉取请求设关卡，以及用基准暴露语言和项目规模上的差距。Probe-and-Refine、Phoenix 和 Multi-LCB 定下了基调：有用的自动化需要一个执行环境来记录尝试过什么，以及失败发生在哪里。
编码代理发布控制
仓库维护者现在可以把代理指令、拉取请求创建和模型选择当作可测试的软件工作来处理。实际做法包括：在失败探针后修订的紧凑仓库指导、由基线对照测试和权限门禁阻断的 issue 代理拉取请求，以及覆盖生产所用语言和项目规模的评估套件。
代码代理正在按生产工人来管理
当天的主要信号是对代码代理的操作纪律要求。Trace、AgentBeats 和 ComAct 都把代理当作系统来处理，这些系统需要可执行的规则、可重复的评估，以及更安全的动作通道，团队才能在真实软件工作中信任它们。
代理自主性检查点
编码代理团队现在有了几个可以加控制的具体位置：仓库说明的可执行检查、代理拉取请求进入审查前的拒绝门，以及用于 CAD 工作的沙箱化程序动作通道。共同压力来自审查浪费和不安全的自主性，尤其是在代理可以修改仓库、发起拉取请求或操作专业 Windows 软件的工作流里。
编码代理需要仓库级测试和上下文防护
当天最强的信号是，围绕已经在处理多文件工作的编码代理，工程纪律开始变得更重要。DeNovoSWE、EsoLang-Bench 和 DeLM 都在测试代理能否构建完整仓库、通过执行进行适应，并且不浪费调用就共享已验证进展。安全论文给出明确警告：看起来正常的上下文，也能把生成或分析出来的代码带向不安全行为。
Repository-scale code assistant safeguards
代码代理评估正在转向可执行的仓库级工作、基于源代码的测试生成，以及对送入模型的上下文做安全检查。实际工作是加入跨文件和依赖关系的验收测试，基于实现证据生成 API 断言，并在评论、文档、示例和附近代码进入代码生成提示前先筛查它们。
编码代理需要轨迹、关卡和支出控制，自主性才可信
本周研究把大型语言模型（LLM）代理视为受控的软件工作者。最有力的工作要求提供轨迹、可执行检查、工具限制和审查关卡。Claude Code 说明这已经不只是基准测试问题：编码代理正在进入软件供应链。
编码智能体控制闸门
编码智能体已经接近日常工程工作，团队需要围绕合并、代码库导航和训练数据设置具体控制。实际做法是保留智能体轨迹，测试精确找代码这一步，并把高风险工具使用或 AI 编写的变更送入可见的审查闸门。
Claude Code 让递归自我改进成为生产治理问题
当天的信号很窄，但很明确：AI 编码代理已经进入 AI 实验室内部的软件供应链。Claude Code 是最具体的例子，Anthropic 说 Claude 在 5 月写了它发布代码的五分之四以上。