代码代理正按已交付系统和已验证修复循环接受评判
当天最强的信号是具体执行。SaaSBench 和 WebGameBench 评估已交付的软件行为，而 ContraFix 和 MemRepair 通过把运行时证据和历史修复放进循环来改进修复。当前重点是运维层面：环境搭建、集成、验证和审查控制决定代理是否有用。
主题概况
Tool Calling
编码代理的运行时验证循环
测试编码代理的团队应该增加验收门，运行交付出来的系统，在修复过程中保留运行时证据，并用已经执行过的 API 调用来训练工具调用器。真正有用的工作在代理周围的验证循环里：浏览器、Docker 运行时、测试、崩溃输入、安全输入和缓存的工具输出都会成为工作产物。
编码代理正在按接口、token 成本和仓库证据接受评判
5 月 4 日最强的工作把大语言模型（LLM）编码代理当作工程系统来审视，关注受限工具、显式仓库状态和可测量成本。Terminus-4B、ARISE 和 TSCG 给出了最清楚的证据：当代理拿到合适的接口时，更小的专用组件可以节省 token，或者改善修复效果。
受约束的编码代理接口
编码代理团队可以通过把终端输出、工具 schema 和仓库证据放到更小、可测试的接口后面，拿到具体收益。最清楚的落地方向是有边界的命令执行、用于长工具目录的编译式工具描述，以及在代理改代码前暴露定义-使用证据的仓库上下文工具。生成式仓库工作流也应包含静态 API 和类型检查，因为很多失败在运行测试前就能被发现。