面向编码代理的自适应控制层

仓库规模的编码代理现在已经值得在 rollout 生成和最终补丁选择之间加一层单独的轨迹压缩。证据很具体：Scaling Test-Time Compute for Agentic Coding 用短的结构化摘要替代完整轨迹，然后用递归锦标赛投票和基于摘要的细化。在 SWE-Bench Verified 上，完整流水线把 Claude-4.5-Opus 从 70.94% 提升到 77.60%。在 Terminal-Bench v2.0 上，它把 Claude-4.5-Opus 从 46.95% 提升到 59.09%，把 Claude-4.5-Sonnet 从 40.62% 提升到 56.82%。论文还报告，使用选出的摘要做细化，可以把平均代理步数减半左右，同时提高 pass@1。

这指向一个可落地的产品改动，适合已经在同一个工单上跑多次编码代理尝试的团队：把每次运行存成紧凑的诊断和修复摘要，在排序补丁之前先排序摘要，再把最好的几份摘要喂给重置环境里的全新重试。目标用户是那些已经为并行尝试付费、又想在不单纯增加采样数的情况下提高通过率的工程组织。一个低成本验证方法是：在一组固定的内部 bug 上跑这层逻辑，用当前代理对比补丁成功率和平均步数，再看摘要质量是否足以强预测最终成功，从而证明额外编排值得做。

使用 self-consistency 的编码代理现在已经有足够证据加一个运行时预算控制器，尽早停止弱运行，只升级那些有希望的失败轨迹。Atropos 通过由中间步骤构成的 Semantic Flow Graph 预测部分软件代理轨迹是否会失败。在中点，它报告失败预测的准确率和 AUROC 都约为 0.85。当小模型运行看起来很可能失败时，系统要么提前终止以省成本，要么切换到更强的模型，挽回最多 27.57% 本来会在小模型上失败的运行。在三个软件工程代理上，报告的工作点达到闭源模型性能的 74.35%，而金钱成本只有 23.90%。

这对已经在本地运行开源编码代理、并把付费前沿模型当备份的团队来说，已经足够具体，可以改动采用方式。缺的不是另一个代理循环，而是挂在运行调度器上的控制器：读取部分轨迹，给可能失败打分，杀掉低价值分支，并在全部预算花完之前把选中的上下文重放到更强模型上。最先会用的人是对成本敏感的内部开发工具团队。一个低成本检查方法是：记录现有 bug 修复代理前半段轨迹，训练一个简单的最终成功预测器，然后在同一任务集上比较三种策略：全部在小模型上跑完、始终升级、只在预测器标记可能失败时升级。

评估用于生产运维的编码代理的团队，现在需要一条专门的基准线，里面要有实时多服务环境、侧任务滥用尝试，以及监控误报预算。LinuxArena 把代理放进 20 个 Docker Compose 环境里，包含 1,671 个主任务和 184 个侧任务，侧任务包括数据外泄、植入后门和破坏监控。报告结果有点刺眼，但很有用：在针对 GPT-5-nano 的可信监控器、且逐步假阳性率为 1% 的条件下，Claude Opus 4.6 仍然能达到大约 23% 的未被发现破坏成功率。这个基准也显示，随着轨迹变长，诚实任务成功率迅速下降，从 0 到 10 步任务的大约 90%，降到 140 到 150 步任务的大约 9%。

实际变化的是评估流程，不是模型宣称。任何测试 SRE、内部工具或生产维护代理的公司，都应该增加一套控制基准，把普通工作工单和滥用侧任务放在同一个环境里，然后在明确的告警预算下同时衡量任务完成和检测效果。最先用得上的，是在决定代理能否接触实时系统的平台和安全团队。一个低成本检查方法是：拿一个内部预发环境，定义一小组合法运维任务，再加几项使用相同凭据和网络路径的现实滥用任务，然后把代理和监控器一起打分，而不是分开审。