Agent Self-Evolution: Harness Principles from Google, Fudan & EverMind

Why Harness Needs Self-Evolution

The core reason is that software environment changes now outpace manual rule maintenance. Three specific drivers: (1) accelerating delivery cadence and complex multi-cluster deployments make yesterday's configurations obsolete; (2) traditional Harness relies on engineers maintaining massive YAML, prompts, tool definitions, and execution rules, where errors cause task failures and resource waste; (3) self-evolution introduces LLM-driven continuous optimization—real-time collection of runtime data, execution results, and exception feedback to automatically adjust prompts, toolchains, configurations, and execution strategies, forming a closed optimization loop.

Harness Definition and Evolution Routes

Harness is the entire engineering scaffolding outside the model that enables an Agent to work. Harness² decomposes it into eight categories: system prompt, guardrail rules, memory, skills, tool usage guides, scripts, sub-agents, and plugins. Fudan's AHE uses seven: system prompt, tool descriptions, tool implementations, middleware, skills, sub-agent configs, and long-term memory. The same model placed in different Harness shows vastly different task performance because decision flows, available tools, and feedback constraints change.

Historically, Agent optimization had three routes: (1) train/fine-tune models—high cost, impossible for closed-source; (2) optimize prompts—simple but turns experience into long-context burden with weak executability; (3) modify the Agent system itself (tools, middleware, memory, execution constraints)—most effective but manual and unscalable. Harness self-evolution automates the third route.

Multi-Agent Architecture and Four-Layer Observability

Mainstream implementations split into a Task Agent (executes) and an Evolution Agent (modifies). AHE further defines three roles: Code Agent runs tasks, Agent Debugger reads traces to analyze root causes, Evolve Agent modifies Harness and records rationale.

Four-layer observability enables automatic evolution:

Component Observability : Harness split into file-level components with fixed mount points, Git-trackable. Failures map to component categories; a logic change is a commit, reversible at file granularity.

Experience Observability : Long-horizon Agents generate millions of tokens; Agent Debugger distills traces into a layered evidence library—benchmark overview, per-task reports, raw traces—supporting on-demand drill-down.

Decision Observability : Every modification writes a Change Manifest recording evidence, inferred root cause, modified files, expected fixed tasks, and regression risks.

Verification Observability : Next-round automated evaluation; if predictions fail, rollback.

Harness² Recursive Self-Verification

Harness²'s task-level recursive self-verification requires no ground-truth answers. It runs baseline Harness plus two modified candidates concurrently, compares behavioral differences across runs, and retains only modifications supported by behavioral evidence. This avoids "self-propose, self-evaluate, self-inflate" hallucination loops.

Three Technical Approaches

Google Research: Harness² (Recursive Agent Harnessing)

Team: Google Research, RSI direction, Apache 2.0, paper "Harness²: Recursive Agent Harnessing for an Open World". Core: recursive meta-Harness optimization for open-world tasks. Harness itself becomes the optimization target. System automatically reads failure traces, iteratively modifies prompts, toolchains, skill libraries, execution control logic—never touching base model weights. Differs from prompt optimization by multi-layer recursion, parallel multi-candidate sampling, and best-of inheritance.

Experiments on WorkBuddy-Bench (office, web, code): GLM-5 baseline 64.2 → 75.7 (+11.5), surpassing native Gemini 3.5 Flash; Gemini 3.5 Flash 72.4 → 77.5. Parallel k=5 amplifies gains. Key insight: weak base models with high-quality recursive Harness can outperform stronger native bases. Limitations: higher token cost from multi-round retries and multi-candidate sampling; gains largest on weaker bases, diminishing on strong ones.

Fudan + PKU + Qizhi: AHE (Agentic Harness Engineering)

Paper arXiv:2604.25850, targeting code Agents. Core innovation: joint evolution of all Harness components, not just prompts. Evolvable objects include tools, middleware, long-term memory, sub-agents, skill descriptions, execution scheduling logic. Prompt-only optimization even yields negative returns.

Starting from minimal seed Harness (basic bash only), 10 auto-iterations on Terminal-Bench 2 raised pass@1 from 69.7% to 77.0% (+7.3 pp), exceeding human-crafted Codex-CLI (71.9%) and prompt-only methods (ACE, TF-GRPO). Generalization: evolved Harness frozen and transferred to SWE-Bench Verified retains positive gains; same Harness improves Qwen, Gemini, DeepSeek consistently, proving learned general execution paradigms, not benchmark overfitting. Engineering lesson: Harness is systems engineering; memory, tools, scheduling chains are high-leverage optimization points.

Component ablation (adding single components back to seed): long-term memory +5.6 pp, tools +3.3 pp, middleware +2.2 pp, system prompt alone -2.3 pp—counterintuitive evidence that prompt discipline requires tool/middleware/memory support to materialize.

EverMind: HarnessBank

Paper "HarnessBank: Semantic Gene-Bank Search with Gated Verification for Agent-Harness Self-Evolution". Focus: trustworthy, verifiable evolution. Solves false gains, overfitting, noise-induced score inflation. Architecture: strong isolation dual-role. Evolver Agent reads failure traces, diagnoses root causes, generates new Harness candidates. Deterministic verification kernel (code, no LLM scoring) handles all gain adjudication, significance testing, activation checks, sealed tests. Philosophy: LLM proposes changes, deterministic code judges effectiveness.

Harness Gene Bank stores each valid Harness with "where×why" semantic coordinates (modification location, fault type solved). Evolution supports recombination of old solutions and fault-driven re-invention, avoiding search collapse and task overfitting. Four gating layers: validity check, activation check, paired significance test, sealed offline test. Only candidates passing all enter the bank.

Results: across 7 Agent benchmarks, stable 5.1–15.4 pp gains; gains retain on sealed test sets, no train-set rise / offline collapse. Positioning: Harness² favors recursive trial-and-error open exploration; AHE favors code-scene full-component co-evolution; HarnessBank emphasizes trustworthiness and statistical rigor for production pipelines requiring strict metric audits.

Engineering Implementation Four-Step Method

Minimal viable loop per AHE:

File-based Harness : split configs into prompt/, tools/, middleware/, skills/, memory/ directories; all modifications land in files; model and evaluator immutable.

Save full rollouts : retain messages, tool calls, scores, results; traces must answer what Agent saw, did, and why it failed.

Write Change Manifest : record evidence, root cause, expected fixes, regression risks; next round auto-validates and rolls back ineffective changes at file granularity.

Layered trace analysis : generate overview, per-task, raw trace three-layer reports; drill down on demand instead of feeding full traces to Evolution Agent.

EverMind Product Suite: HarnessBank, Raven, EverMe

EverMind (GitHub: https://github.com/EverMind-AI) commercializes the self-evolution stack. Three components:

HarnessBank = offline/nearline Harness version factory & review system. Dual-Agent: Task Agent runs tasks with current Harness, emits full traces; Evolver Agent reads failures, diagnoses categories (unclear tool descriptions, missing pre-checks, wrong memory timing, incorrect multi-step orchestration), auto-generates Harness batches. Gene bank + gated selection: candidates run on sealed test sets; regressions discarded, overfit samples discarded, only statistically significant improvements retained.

Raven = online dynamic scheduling engine. Fixed Harness versions have task-specific weaknesses. Raven dynamically adjusts memory, skills, tools, execution strategies during task runtime.

EverMe = consumer-facing digital twin. Builds business flywheel: user interaction → memory consolidation → Raven-driven execution → user feedback → failure/negative samples flow back to HarnessBank as evolution material. EverMe does not iterate Harness or schedule runtime; it provides the data flywheel.

Complete Self-Evolution Flow

User request in EverMe (digital twin).

Raven reads long-term memory, matches skills, selects tool strategies, executes under current Harness.

Collect user feedback, record success/failure traces.

Failure traces and negative feedback flow to HarnessBank.

Evolver Agent diagnoses failures, batch-generates new Harness candidates.

Candidates pass screening and sealed tests; qualified versions enter bank.

New Harness versions deployed to Raven.

Loop repeats.

Throughout: base LLM weights frozen, no fine-tuning. Evolution targets outer Harness, memory strategies, skill libraries, tool orchestration.

Summary and Outlook

Harness self-evolution's underlying principle: dual-Agent architecture plus three-layer observability, advancing experience from prompt language layer to system layer of tools, middleware, memory. Benchmarks show clear gains within controlled settings, with weaker models benefiting more—though gains must be re-evaluated under equal inference budgets. Landing path is clear: file-based Harness, full trace persistence, Change Manifest, layered analysis—four steps to a minimal loop. As model capabilities converge, competition shifts from "who has the strongest model" to "whose scaffolding evolves better." Traditional Harness ensures AI follows rules; self-evolving Harness ensures AI continuously improves those rules. Advanced Harness should not only execute but also discover problems, summarize experience, adjust strategies—upgrading from manual maintenance to model-driven, from static config to dynamic evolution.