更聪明的计算远比更多的计算更有效。
这正是蚂蚁集团 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 的学术编辑实习生 � �
感兴趣的小伙伴欢迎关注 � � 了解详情
� � 点亮星标 � �
科技前沿进展每日见
盛鹏配资提示：文章来自网络，不代表本站观点。
