On October 9, 2026, Google Cloud AI Research and Northwestern University published the paper “Harness²: Recursive Agent Harnessing for an Open World” on arXiv, with the code open-sourced the same day on GitHub under the Apache 2.0 license. The paper’s core conclusion: with model weights fully frozen, recursively optimizing the harness that wraps the model—eight components including the system prompt, tools, memory, and subagents—raised GLM-5’s score on WorkBuddy-Bench from 64.2 to 75.7, a single-step gain of 11.5 points; Gemini 3.5 Flash improved by 11.8 percentage points on the Harvey legal benchmark LAB; on the specialized task benchmark JobBench, Gemini improved by 4.5 points (31.5→36.0). About two weeks after publication, the code repository had accumulated roughly 6,600 GitHub Stars.
The truly striking thing about these numbers is not the absolute size of the gains but the structural fact revealed by the cross-model comparison: under the same executor, OpenCode, GLM-5 using a self-improving harness (75.7 points) surpassed Gemini 3.5 Flash using the default harness (72.4 points). In other words, a relatively weaker base model, with better “packaging,” beat a stronger base model on the benchmark. The same reversal was reproduced under another executor, Codex (75.3 vs. 74.5). This is not an edge case but a systematic phenomenon that recurred across three benchmarks and four model-harness configurations.
Eight Files, Two Recursive Layers, No Touching the Weights
To understand how Harness² works, one must first clarify how the framework defines the “harness.” Harness² decomposes the agent harness into eight editable runtime files: the system prompt, guardrails, memory, skill library, tool guidance, scripts, subagents, and a middleware plugin. The model itself is never touched; all optimization happens on these eight files.
The optimization mechanism consists of two nested recursive layers. The first is task-level recursion: each time a task is executed, the harness editor first runs the task with the base harness to obtain a reference execution trajectory, then generates two types of candidate modifications—one targeting cross-domain general agent weaknesses (planning, tool use, task delegation), the other carrying domain-specific knowledge and procedures. Both candidate versions are probe-executed under the same task setup and evaluated through “behavioral comparison” rather than comparison with a ground-truth answer: did the change actually alter the behavior it was meant to target? Finally, a synthesizer merges the effective modifications into a new harness.
This “Propose-Probe-Compose” three-step loop solves a practical deployment problem: real-world tasks usually lack a ground-truth answer for direct comparison. Previous recursive self-improvement schemes relied on reward functions or human labels and often failed when deployed in open domains. Harness² replaces ground-truth validation with behavioral comparison, bypassing this constraint.
The second layer is harness-level recursion: after a task is completed, a reflector writes the adopted modifications and evidence-supported lessons into a persistent “improvement harness” library. Subsequent tasks still start from the same base harness, but the proposal stage references this accumulated experience library, causing improvement suggestions to converge over time as the system is used. In the paper’s design, the harness editor itself uses Anthropic’s Claude Opus 4.8, running under the OpenCode framework; the frozen executors evaluated are Gemini 3.5 Flash and GLM-5.
Tool-Call Error Rate Down 36.8% Is the Number Enterprise Users Care About Most
Gaps on academic benchmarks are easily dismissed as a numbers game, but Harness² reduced the tool-call error rate by up to 36.8%, with no weight updates at all. For enterprises that rely on AI agents to execute real tasks—file operations, code execution, database queries, API calls—tool-call failures carry real costs: task interruption, human intervention, and error propagation. If a framework requiring no retraining can reduce such failures by more than a third, the calculations of procurement decision-makers change.
For developers, open source under the Apache 2.0 license means this optimization framework can legally be used in commercial products. In practice, developers do not need to change model invocation logic; they only need to expose the harness’s eight components as files to the Harness² editor to start the self-improvement loop. This is an order of magnitude less demanding on infrastructure than LoRA fine-tuning or RLHF.
For teams hoping to lower the cost of relying on large models, there is a more direct path: if the cheaper GLM-5, after harness optimization, can match or exceed Gemini 3.5 Flash’s default performance, then introducing harness optimization at the application layer is an effective form of cost arbitrage. The paper’s data has already validated the feasibility of this path under two executors.
The Leaderboard Comparability Problem Is More Far-Reaching Than Harness² Itself
The industrial impact of Harness² extends beyond the boundaries of the framework itself. Most existing large-model leaderboards—whether general or domain-specific—report the joint score of “the model plus its default harness.” Harness²’s data experimentally shows that the same model can differ by more than 11 points under different harnesses, and that different models can swap rankings under optimized versus default harnesses.
This means that at least part of the gap between adjacent ranks on current leaderboards may not be a gap in model capability but a gap in harness engineering investment. For enterprises and developers who rely on evaluation results to make selection decisions, this constitutes a substantive information problem: the model you see at rank N and the one at rank N+2 may differ simply because their engineering teams invested differently in the default harness, rather than because of a true difference in base model capability.
Discussion of the paper on platforms such as Hacker News focused on this point: how much does the harness contribute to final results, while existing evaluation systems have almost no standardized measurement or disclosure of that contribution. A leaderboard without a unified harness standard publishes numbers that are closer to “a showcase of the best prompt engineering results” than to a horizontal comparison of base model capabilities.
From Historical Precedent: Engineering-Layer Gains Are Often Underestimated Before the Architecture Layer
This is not the first precedent of “achieving significant gains at the engineering layer without changing the model itself.” Before Chain-of-Thought prompting was systematically studied, the research community generally held conservative estimates of the upper bound of prompt design; before Tool Use / Function Calling was standardized, implementations also varied widely from vendor to vendor. Looking back at these histories reveals a pattern: before a capability layer is systematized and standardized, its contribution tends to be underestimated, and after a paper quantifies it, the industry often realizes that this layer’s actual contribution to total scores is much larger than previously believed.
What Harness² does is advance “harness engineering” from an empirical practice to a measurable, recursively optimizable, and reproducible methodology. This action itself—regardless of the eventual adoption rate of the Harness² framework—provides a quantitative benchmark that can be cited and compared: the single-step gain from harness optimization on specialized tasks is on the order of 11 points, not 1–2 points.
Uncertainty and Boundaries Still to Be Verified
The experimental data published so far come from three benchmarks and four model-harness configuration combinations. The models tested in the paper are GLM-5 and Gemini 3.5 Flash; the editor is Claude Opus 4.8. The method’s generality across a broader range of models (for example, models with larger or smaller parameter counts) and more benchmarks, as well as its stability in high-concurrency production environments, still lacks independent third-party replication data.
In addition, the computational cost of recursive optimization itself deserves attention: each task-level recursion requires probe-executing multiple candidate harnesses and relies on an independent editor model (Claude Opus 4.8) to drive proposals and synthesis. For latency-sensitive or budget-constrained application scenarios, whether this extra overhead is justified depends on the value density of the specific task. The paper does not disclose inference cost data for each improvement cycle, which is a variable that must be measured independently during selection.
What Is Most Likely to Happen Next
The following are forward-looking judgments based on the above analysis, explicitly labeled as analysis rather than fact.
In the near term, the most likely industry chain reaction is that mainstream evaluation organizations will be forced to add disclosure fields for harness configuration to their results pages. Just as FLOPS transparency drove normalized comparisons of compute, Harness² provides a citable paper basis that turns the demand to “report harness settings alongside results” from practitioner intuition into an academic consensus that can be footnoted.
In the medium term, if independent replication experiments validate its cross-model generality, “harness optimization” is likely to become a standard value-added service direction for large-model API providers—similar to existing fine-tuning APIs, but without weight updates, with shorter deployment cycles and more frequent iteration.
Over the next six months, two questions matter: whether independent research teams reproduce similar magnitudes of improvement on more general benchmarks such as MMLU, SWE-Bench, and GAIA; and whether existing leaderboards (for example, Chatbot Arena-type products) begin adding harness disclosure requirements to submissions. The former determines the generality boundary of this direction; the latter determines whether it can substantively change industry comparison standards.
For developers who need to make decisions now: if your agent application is already running stably but the bottleneck is tool-call reliability and task completion rate, Harness² offers an improvement path that does not require waiting for the next generation of base models or labeled data. The code is open; the cost is the extra inference required to test harness variants, with a low floor. You can first run small-scale experiments to verify the gains before deciding whether to introduce the full recursive optimization loop.
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接