编码研究正在收紧对代理实际完成内容的检查
4 月 19 日的编码研究，最强的地方在于系统不再相信表面成功。PDB、Prometheus 和 Terminal Wrench 各自加了一层更严格的检查：编辑是否精确，补丁是否符合已验证的需求，代理是否在不欺骗验证器的情况下完成任务。实际信息很清楚。更好的编码代理现在同样依赖评估层和控制层，而不只是依赖原始生成质量。
主题概况
Evaluation
Solution Fidelity Controls
这一天的编码代理研究指向三个容易在真实工作流里测试的近期待办事项：给调试代理加 diff 大小控制、在自动修复前先验证可执行需求、以及对基准验证器做对抗性审查。它们有一个共同点：测试通过或任务验证器通过，已经不足以说明系统是否以精确、可审查的方式解决了预期问题。
编码研究正在把代理和评估周围的控制层说得更具体
4 月 18 日的研究最强的地方，是编码系统更容易运行、审计和信任。当天的重点是代理的运维控制、对评估偏差的直接测试，以及面向仓库的工具，用来为 AI 工作准备代码库。HiveMind、LLM judge 审计和 Workstream 把主要模式都抓住了：当论文把模型外面的控制层说清楚，结果就会更好。
代理可靠性控制
近期最清楚的工作，是给编码代理及其评估加上控制层。证据支持三件具体的事：把共享代理流量放到调度代理后面，为任何用于软件决策的 LLM 评审器加入提示扰动检查，并在上线更重的 AI 工作流之前扫描仓库里缺失的面向代理文档和保护措施。
编码代理的进步来自更紧的反馈循环和更严格的证据
这一时期最清楚的信号是，编码研究正在围绕证据、上下文和反馈收紧控制回路。CollabCoder、仓库压缩研究，以及 SAP HANA 测试生成论文都显示出同一条实用规则：更好的结果来自更有选择性的引导和更严格的检查，而不是让代理在没有约束的情况下跑更久。最强的论文用通过率、延迟或 mutation score 的具体提升支撑了这个判断。
Controlled agent feedback loops
这些证据里能用的模式是：更严格地控制代理能看到什么、下一步尝试哪种修复、以及如何判断输出。仓库工具可以在生成前压缩上下文，因为被引用的研究显示，选择性压缩同时改善了质量和延迟。基于测试的编码循环可以把失败导向计划修复或代码修复，因为这个决定提高了通过率，也减少了重试。生成测试需要在未见过的代码库上使用 mutation score 作为门槛，因为公共基准上的成绩没有延续到 SAP HANA，而单靠编译反馈会奖励更弱的测试。
真实仓库证据是当前代码代理仍然达不到的标准
这一天最强的信号是，代码研究正在收紧到可在真实仓库中核查的证据上。CodeSpecBench、R²Eval 和 Ace 从不同角度指向同一个限制：语义理解、仓库上下文和团队协调，比原始生成速度更能限制当前代码代理的能力。
基于仓库的代码审查
当前的 coding agent 工作指向三个具体变化：把可执行规格检查加进 pull request 审查，把仓库上下文推理 trace 加进评估，并在广泛的模型搜索之前，先把跨文件后续编辑交给 IDE 和语言服务器工具。共同模式很简单：仓库证据暴露出最终补丁评分和本地编辑流程仍然漏掉的失败。
代码代理研究正在围绕显式控制面展开
当天最强的工作都在把代码代理收紧到显式结构、受限动作和不确定条件下的判断上。Contract-Coding 给出最清楚的仓库级结果，DeepGuard 提供了更明显的安全提升，HiL-Bench 则显示请求帮助仍然是弱项。主线是可检查的控制：合约、护栏，以及能暴露判断缺口的评估。
编码代理控制门
近期最清楚的变化，是围绕编码代理增加更明确的控制点：仓库生成前先放合同工件，给代码生成加安全评分并配上受限编辑工具，以及在需求含糊时先做澄清。证据更支持具体构建和流程调整，而不是更大的自治承诺。
软件代理工作正在更明确地强调规格、检查和整仓库任务
当天最强的证据支持这样一种软件代理：它先写下任务，在仓库尺度上行动，并通过具体检查。ReCodeAgent 和 REAgent 在生成前加入规划或需求后，拿到了可测的提升。CLI-Tool-Bench 和 SWD-Bench 则把评测收紧到端到端行为、仓库理解和下游可用性上。
仓库任务验证
最近最清楚的方向，是在仓库代理前面加上明确的规格和验证步骤，再用端到端的仓库任务来测试它们，而不是只做局部代码检查。证据支持三个具体动作：在修 issue 之前先写结构化需求，把仓库迁移包装成带规划和验证检查点的流程，以及用空工作区的黑盒 CLI 行为测试来评估 0 到 1 的代码生成。