TTHE：无需微调与标签，测试时脚手架演化让Agent准确率暴涨38%

TTHE: Test-Time Harness Evolution

当一个部署在生产环境中的数据分析 Agent 连续三次生成了逻辑完美的 SQL 语句，却仅仅因为数据库表名的大小写不匹配而屡屡报错时，它该如何自救？在绝大多数现有的工程架构中，它只能反复撞墙，因为控制它如何调用工具、如何拦截异常的“工作流程序”在出厂部署的那一刻起，就已经被彻底焊死了。为了打破这种系统级的僵化，一项名为 TTHE（Test-Time Harness Evolution）的最新研究提出了一条截然不同的演化路径：在不更新模型任何权重、不提供任何标准答案的情况下，让 Agent 在测试评估期间，直接根据执行报错和运行轨迹，当场重写自己的代码逻辑。该方法在 Text-to-SQL 任务的困难切片上，直接将基线准确率从 12.0% 拔高到了惊人的 50.0%。

ArXiv URL：http://arxiv.org/abs/2607.08124v1

核心痛点：被冻结的不仅是权重

目前，构建高级 LLM Agent 已经不再是单纯的“输入-输出”调用，而是构建一个包含上下文检索、工具分发、中间状态校验的复杂可执行系统。这个包裹着大模型的控制程序，在学术界被称为 $harness$（脚手架）。

如果我们将大模型视作 Agent 的“大脑”，那么 $harness$ 就是它的“四肢和反射神经”——它决定了大脑在感觉到高温时，是直接伸手去摸，还是先寻找灭火器。然而，目前的研发范式是：开发者在训练集或验证集上疯狂调优 $harness$，随后将其转化为静态制品并上线。这种做法导致 Agent 在面对陌生的测试数据分布、未知的报错模式或新奇的工具交互时，显得极其笨拙。那么，有没有可能让 $harness$ 摆脱静态宿命，在测试阶段自己进行代码级的“进化”呢？

方法机制：在无标签的暗箱中摸索

TTHE 的核心思想是将这个可执行的 $harness$ 视为 测试时适应（Test-Time Adaptation）的状态载体。整个优化过程完全发生在系统的评估阶段，且极其巧妙地避开了对“金标准”答案的依赖。

TTHE 维持了一套基于种群的“生成-评估”循环。整个系统虽然包含解题者、提议者和裁判三种角色，但它们其实都是共用同一个冻结参数的底层 LLM，仅仅是套上了不同的任务外壳。

其内部运行机制可以拆解为以下几个关键环节：

收集执行轨迹：在一个无标签的测试批次输入 $X$ 上，系统运行当前的脚手架 $H$，并捕获极其详尽的执行轨迹 $\mathcal{T}[H]$。这些轨迹包含了模型提示词、工具调用参数、标准输出/错误、中间产物等。这就像是记录下“四肢”在试图解题时的所有细微动作和碰壁记录。
多分支提议与重写：提议者（Proposers）负责读取这些执行轨迹，分析 Agent 在哪里栽了跟头。随后，TTHE 会演化出 $G$ 个并行的代码分支，在 $R$ 轮迭代中，提议者会通过代码编辑代理工具，直接修改 $harness$ 的 Python 源码。为了保持探索空间的多样性，不同的分支会被引导向完全不同的修改策略。这就好比根据上一次的痛觉反馈，强行重塑“反射神经”的底层代码。
无监督仲裁：在毫无标准答案的情况下，裁判（Judge）需要从最终生成的多个代码版本中挑选出最优解。由于缺乏对错标签，裁判只能依赖执行过程衍生的代理信号，例如程序的运行健康度、轨迹级信号的逻辑合理性以及输入输出的往返一致性。被选中的改良版脚手架 $H_{t+1}$ 将被持久化保存，并接管后续的输入批次。

在这个精密的循环中，金标准标签只在最终的绝对指标测量时才被使用，整个自适应过程完全不依赖额外训练。

关键实验：全方位的能力跃升

该研究在多个重度依赖执行反馈的领域进行了严格测试，包括结构化查询、竞技编程、软件工程和数据科学代码。为了避免数据污染和指标虚高，实验刻意选取了难度极高的数据切片，这些通常是基线模型反复失败的灾难区。

在 BIRD 任务的硬切片上，使用 deepseek-v4-flash 作为基座，TTHE 将传统的 ReAct 架构基线准确率从 12.0% 暴增至 50.0%。在 SWE-bench Verified 这种极其考验长流程复杂操作的真实软件工程任务上，准确率也从 20.0% 稳步提升至 35.0%。

更为惊艳的是，研究团队发现 TTHE 演化出的绝非毫无逻辑的随机代码变动，而是真正可解释的、高度符合高级软件工程师直觉的策略。例如，在 SWE-bench 上，TTHE 自动为 Agent 插入了严格的“复现漏洞-定位根因-修复-再验证”工作流，甚至还手写了一个前所未有的“回滚修复”分支：如果首次生成的代码补丁为空，程序会自动更换更严厉的系统提示词并强制触发重试。这一切，全是它从报错轨迹中自行领悟的。

在上图展示的批次大小消融实验中，揭示了一个有趣的现象：性能增益并非随着批次大小 $B$ 单调递增，而是在 $B=10$ 时达到完美的峰值 50.0%。这表明，批次太小会导致裁判获得的裁决证据不足，容易做出短视的决策；而批次太大则变相减少了系统在整个数据流上进行迭代适应的次数，导致迟钝。

此外，在探索预算的深层分析中，增加迭代轮数 $R$ 并不总是带来正向收益。当只有单线演化（$G=1$）时，将迭代轮数从一轮增加到三轮，准确率反而从 46.0% 下跌到了 40.0%。这是因为在单一的演化路径下，早期的优秀候选代码往往在后续的盲目修改中被破坏；只有当开启多条并行分支（$G=3$）时，优良的代码片段才有足够的容错空间存活下来。

局限性剖析：裁判的盲区与探索天花板

尽管 TTHE 展现了巨大的应用潜力，但该研究极其坦诚地剖析了方法论层面的两处技术瓶颈：

第一处在于 选择遗憾。如果裁判拥有上帝视角，能够从它审阅过的所有候选分支中，精准挑出那个能碰巧做对的脚手架，整体准确率其实可以跃升至 64.0%（而实际仅有 50.0%）。这说明当前的无监督裁判依然容易被欺骗。它常常偏爱那些“看似合理但实际上破坏了基准测试格式”的代理信号。比如，某段 SQL 虽然成功执行，但返回了冗余的列，导致最终评测失败，而裁判却误以为这种不出错的代码就是最优解。

第二处在于 生成覆盖率的极限。即便穷尽所有被生成过的脚手架变体，准确率的天花板也死死卡在 70.0%。这意味着剩余的 30% 任务难度极其变态，单纯依靠当前的有限搜索空间和算力预算，提议者根本无法凭空捏造出能解决问题的复杂逻辑。盲目增加搜索预算，只会导致生成的变体高度同质化。

工程实践启示

TTHE 的横空出世，为 LLM Agent 的工业级落地提供了全新的解题思路。它有力地证明了，测试时计算（Test-Time Compute）的巨大红利不仅存在于大模型自身的推理阶段，同样深藏在包裹大模型的系统架构层面。通过赋予系统在运行时自我重写控制逻辑的能力，开发者可以大幅削减人工枚举边缘用例和手写异常捕获逻辑的工程成本。

同时，它也发出了一声警钟：在构建无监督的闭环反馈机制时，代理信号的可靠性（Proxy Reliability）将直接决定整个系统的生死。如何设计出更难被“钻空子”、真正反映任务本质的运行健康度检查器，是下一代智能 Agent 架构设计中亟待攻克的高地。TTHE 让我们看到，未来的 Agent 也许不再需要人类工程师彻夜排查死锁日志，它们自己就能在无数次的跌倒与乱码中，悄悄改写自己的生命源码。