结构化上下文降低智能体成本，但更快的审查仍伴随质量风险
证据进一步支持近期的发现：编码智能体的收益取决于经过设计的上下文和可执行检查。新研究报告了更低的 token 使用量、更窄的搜索范围，以及更好的修复或规范生成结果。然而，一项大规模观察性审查研究将更快的智能体辅助决策与更多质量异味联系起来。大多数结果仍局限于特定基准或组织，因此它们支持对工作流的设计选择，而不是对已部署智能体作出广泛判断。
主题概况
Code Review
编码智能体规划、重新生成与审查中的验证调整
编码智能体工作流应将验证预算用于证据不完整的地方：向审查者公开行为和状态转换，使用现有测试套件之外的反例测试依赖替代实现，并要求多个智能体检查同一修复时提供彼此不同的诊断证据。
代理工具正在围绕证明、限定范围的记忆和可问责动作构建
这一时期最强的信号是代理的运行纪律。GlueRun-go、Vitrus 和 Callimachus 把代理工作视为需要 lease、引用、本地记忆和可审计控制路径的过程。多数主张来自工程证据、合成测试或产品指标，公开基准覆盖有限。
内部智能体的运行控制
智能体采用正在转向模型周边的运行控制：任务租约、证据包、带来源的记忆、API 调用检查和带身份信息的日志。实际工作是在现有开发者和内部工具工作流中加入这些控制，使失败可见且测试成本较低。
控制平面、诊断和复核门槛现在定义了代理可靠性工作
当天最强的证据把大型语言模型（LLM）代理当作需要受管权限、诊断和复核路径的系统。Agent Operating Systems、Type-Error Ablation 和 Monitoring Agentic Systems 给出的信号最清楚：可靠性取决于执行控制和反馈质量，也取决于模型输出本身。
代理可靠性工程接口
代理可靠性工作正在进入日常工程界面：编译器输出、监控队列、IDE 评审流程和操作前门控。最实用的改动足够小，可以先在一个语言工具链、一个受监管的代理工作流或一条代码评审路径里试点。
代码代理正按已交付系统和已验证修复循环接受评判
当天最强的信号是具体执行。SaaSBench 和 WebGameBench 评估已交付的软件行为，而 ContraFix 和 MemRepair 通过把运行时证据和历史修复放进循环来改进修复。当前重点是运维层面：环境搭建、集成、验证和审查控制决定代理是否有用。
编码代理的运行时验证循环
测试编码代理的团队应该增加验收门，运行交付出来的系统，在修复过程中保留运行时证据，并用已经执行过的 API 调用来训练工具调用器。真正有用的工作在代理周围的验证循环里：浏览器、Docker 运行时、测试、崩溃输入、安全输入和缓存的工具输出都会成为工作产物。