更聪明的计算远比更多的计算更有效。

这正是蚂蚁集团 CodeFuse 团队，用一篇 ACL 2026 主会论文验证的核心结论。

Test-Time Scaling（TTS）是通过在推理阶段投入更多计算资源，让 Agent 多次尝试、探索不同推理路径再选最优的关键范式，是当前 LLM 在复杂任务上取得 SOTA 的核心方法。

然而业界主流 TTS 方法对所有推理步骤一视同仁地投入计算，大量 Token 浪费在确定性操作上，且多轨迹选择仅靠 " 谁得票多 "，Agent 自我验证通过率 88% 中却有 35.7% 是错的——

投入翻倍，收益边际递减。

针对这一现状，蚂蚁集团 CodeFuse 团队提出 EGSS：

通过 " 工具熵 " 指标精准识别高不确定性决策点、只在关键步骤展开多候选探索，并首创跨轨迹测试整合机制用客观执行结果替代主观评分，两阶段闭环精准解决计算冗余与选择脆弱两大痛点。

EGSS 在 SWE-Bench-Verified 上全模型一致提升 5-10%，GLM-4.6+EGSS 达到 74.6% 创下开源方法新纪录，更以 K=4 打败 K=8 节省 38-42%Token。

这有力说明了，更聪明的计算远比更多的计算更有效。

TTS 的性能危机：越强大，越昂贵

Test-Time Scaling（TTS）是当前 LLM 在复杂软件工程任务上取得 SOTA 的关键范式——

通过在推理阶段投入更多计算资源来探索多样化的推理路径，从而提升代码生成和 Bug 修复的效果。

但现实很骨感：TTS 正在用惊人的资源消耗换取边际递增的收益。

痛点一：计算冗余与低效探索

现有方法普遍采用均匀搜索扩展或大规模重复采样，没有任何轨迹间的协调机制。

大量计算被浪费在确定性操作上（比如读取文件、简单编辑），而真正需要深入探索的高不确定性决策点却得不到足够的计算资源。

痛点二：补丁选择机制脆弱

多轨迹 TTS 的最终选择环节常常丢弃中间调试信号，仅依赖终端排序。

这导致 " 共识错误 "，即多条轨迹收敛到一个看似合理但实际错误的补丁上。

实证显示：88% 的轨迹包含自我验证，但其中 35.7% 仍产出错误补丁—— " 自我欺骗性调试 "。

下图为各种 TTS 方法在性能与 Token 使用量上的权衡，EGSS 位于 Pareto 前沿。

从图中可以清晰看到：

EGSS 在 " 性能 - 成本 "Pareto 前沿上占据绝对优势，用更少的 Token 实现了更高的 Resolved%。

两个关键发现：问题出在哪？

发现一：不是所有步骤都需要 " 用力 "

Tool Entropy 分析发现，Agent 轨迹中大部分的动作都在执行固定化的操作，表现为观测指标为：

大量步骤是低熵确定性操作（如读文件），仅少数高熵步骤才是关键分支点。

均匀分配计算是严重浪费，应将资源集中于不确定步骤。

下图表明，Agent 轨迹中的工具熵分布呈明显右偏态，大部分步骤为低熵操作。

发现二：自我验证≠正确验证

88% 的轨迹包含自我验证，但其中 35.7% 仍产出错误补丁。

单一视角验证会陷入 " 确认偏差 " ——

Agent 自以为验证通过，实则接受了无效补丁。需要跨轨迹的多维度交叉验证。

EGSS 框架：精准打击，闭环验证

EGSS 框架整体架构为，熵引导的两阶段闭环。

其核心思想是：用结构化的架构复杂性替代暴力的均匀扩展。

两个阶段分别精准解决两大痛点。

阶段一：动态逐步搜索（DSS）——解决 " 计算冗余 "

鉴于现有 TTS 对所有步骤一视同仁地投入计算，导致大量 Token 浪费在确定性操作上，而关键决策点反而探索不足。

所以 EGSS 决定利用工具熵识别高不确定性步骤，只在这些 " 关键岔路口 " 投入额外计算。

具体怎么做？

1、实时监控工具熵：每一步监控 Htool（at   | st），当熵值超过阈值（q75   ≈ 1.16）时，判定为高不确定性决策点。

2、在高熵步骤展开多候选：对高熵步骤进行 stepwise rollout（默认 4 个候选动作），而非在所有步骤都扩展。

3、引入 Judge 评估与剪枝：经过微调的 Qwen3-8B Judge 对每个候选动作打分，结合模型似然和 Judge 评分排序，保留 Top-K 高质量轨迹。

轨迹评分公式：

基座模型对数似然，衡量动作的 " 自然度 "；

Judge 评分信号，从五个维度评估动作质量（步骤一致性、上下文感知、目标优先级、工具使用合理性、诊断精度）；

控制两者权重；

长度惩罚，避免偏向短轨迹。

关键设计哲学在于，只在 ~25% 的高熵步骤调用 Judge，其余 ~75% 的确定性步骤直接通过。

这意味着 DSS 将计算资源精准投放到 " 最需要思考 " 的步骤，而非无差别地撒网。

最终，DSS 在相同 K 值下 Oracle 指标全面优于 Repeat Sampling（如 GLM-4.6 K=4：77.4%vs73.4%），说明熵引导的搜索确实产生了更多高质量候选。

阶段二：测试整合增强（TCA）——解决 " 补丁选择脆弱 "

鉴于多轨迹 TTS 的最终选择环节丢弃了中间调试信号，仅靠终端排序容易受 " 共识错误 " 影响，且单轨迹自我验证存在 35.7% 的 " 自我欺骗 " 率，无法可靠区分正确与错误补丁。

所以 EGSS 选择将多条轨迹中的异构调试信号整合为统一的可执行测试套件，用客观的测试结果而非主观评分来筛选补丁。

四步流水线：

Step 1：调试动作提取

从 DSS 生成的轨迹树中收集所有调用调试工具（如测试生成、测试执行）的节点，形成调试信号集合 A_debug。

这些信号来自不同轨迹的不同视角，天然具有多样性。

Step 2：整合测试套件生成

TestConsolidationAgent 分析 A_debug 中的异构调试意图，结合代码仓库上下文，合成为统一的可执行测试文件。

覆盖各条轨迹发现的边界情况、不同回归测试视角、单条轨迹遗漏的测试维度。

Step 3：补丁评估与过滤

TestEvaluationAgent（仅配备 Bash 工具，确保安全隔离）在每个候选补丁上执行整合测试套件，计算通过率，保留通过率超过阈值 τ 的补丁。

用客观测试结果替代主观 LLM 评分——补丁好不好，跑测试说了算。

Step 4：偏好选择投票

多个独立的 PreferenceSelector（Kimi-K2、GLM-4.6、Qwen3-Coder-480B）各自读取代码、应用补丁、执行验证后投票。整合测试已过滤大部分错误，投票进一步降低单模型偏差。

两阶段的闭环协同：

DSS 通过熵引导搜索产生高质量、高多样性的候选集（" 种好草 "）；TCA 通过跨轨迹测试整合和多模型投票从中可靠地选出最优补丁（" 挑好苗 "）。

没有 DSS 的多样候选，TCA 无从选择；没有 TCA 的可靠筛选，DSS 的好候选也可能被错误淘汰。

实验结果：以少胜多，全面领先

主实验：SWE-Bench 上的全面突破

关键发现为，EGSS 在 K=4 时就超越了所有基线方法，GLM-4.6 达到 73.8%，创下开源 LLM 新 SOTA。

Token 效率：K=4 打败 K=8

下图为不同采样策略下的平均 Token 使用量对比：

完整 Token 消耗对比

EGSS 用一半的候选数量（K=4 vs K=8），不仅节省了 38-42% 的 Token，还实现了更高的准确率。

虽然 TCA 本身引入了 3%-13% 的额外 Token 开销，但 DSS 产生的高质量候选使得更小的 K 值即可超越基线 K=8 的效果——这是 " 以小博大 " 的典型范式。

补丁选择：TCA 的稳定优势

TCA 在各 K 值下一致优于 Dei Aug，且随着 K 增大趋近 Oracle 上界——

这说明 TCA 能有效利用更多候选的优势，而不会因噪声增加而退化。

消融实验：Test Consolidation 是核心驱动力

TC Top1 大幅超越随机基线：GLM-4.6 在 N=8 时提升 +7.2%；

TC Top3 接近 Oracle 上界：GLM-4.6 在 N=8 时 TC Top3 达到 77.6%，仅差 Oracle2%；

Test Consolidation 是主要性能驱动力：整合测试套件的排名能力几乎触及理论上界，Augmentation 投票机制提供额外稳定性。

核心启示：结构化复杂性 > 暴力扩展

在复杂领域如软件工程中，结构化的架构复杂性是实现成本效益自主性的必要前提，而非简单的开销。

通过用 " 熵引导的定向探索 " 替代 " 暴力的均匀扩展 "，用 " 跨轨迹测试整合 " 替代 " 单一视角验证 "，EGSS 在减少 38-42%Token 消耗的同时达到了更优精度，这证明了聪明的计算远比更多的计算更有效。

代码：https://github.com/codefuse-ai/CodeFuse-Agent

论文：https://arxiv.org/pdf/2602.05242

一键三连「点赞」「转发」「小心心」

欢迎在评论区留下你的想法！

—  完  —

我们正在招聘一名眼疾手快、关注 AI 的学术编辑实习生 

感兴趣的小伙伴欢迎关注  了解详情

点亮星标

科技前沿进展每日见