Harness Self-Evolution: Updating vs. Benefit Capabilities

Definíciók¶

External harness¶

A modell köré épített szerkeszthető artifact-ok összessége: - P — prompts (system + user) - S — skills (konkrét task-végrehajtási eljárások) - M — memories (epizodikus, szemantikus, procedurális) - T — tools (API, kód, fájlrendszer)

A harness nem modell paraméter — a modell fagyott, a környezet frissül.

Harness self-evolution¶

Iteratív folyamat, ahol az evolver (e) a task-solving agent (f) execution evidence-e alapján frissítja a harness-t:

$$H_{t+1} = e(\text{evidence}(f, H_t, \text{task}))$$

Két komponens képesség (Lin et al., 2026-05-28)¶

Képesség	Definíció	Mért mennyiség
Harness-updating (Δupdate)	Az evolver képessége hasznos update-eket produkálni	Pass rate növekedés fix agent mellett, evolvert váltva
Harness-benefit (Δbenefit)	Az agent képessége hasznát venni a frissített harness-nek	Pass rate növekedés fix evolver mellett, agentet váltva
Base capability (M_base)	Task-solving képesség harness evolution nélkül	Pass rate az eredeti H_0 harness-szel

Lin et al. (2026-05-28, arXiv:2605.30621) — Updating vs. Benefit¶

A két fő felfedezés¶

Finding 1: Harness-updating is FLAT in base capability¶

7 LLM × 3 benchmark, fix task-solving agent, vary evolver. Eredmény: Δupdate max 3.1 pp eltérés bármely benchmarkon, függetlenül az evolver base capability-jétől.

"Even the Qwen3.5-9B evolver induces gains comparable to those of Claude Opus 4.6."

Implication: az evolver képessége nem a fő limitáció. A frontier modell használata evolverként nem éri meg a költségét.

Finding 2: Harness-benefit is NON-MONOTONIC in base capability¶

Invertált kísérlet: fix evolver, vary task-solving agent.

Tier	Példa modell	Δbenefit
Weak-tier	Qwen3-32B, Llama-3.3-70B	kevés (nem tölti be / nem követi a harness-t)
Mid-tier	GPT-OSS-120B	legtöbb (sweet spot)
Strong-tier	Claude Opus 4.6	kevesebb (performance ceiling)

Implication: a post-evolution score driver-e a task-solving agent harness-benefit képessége, nem az evolver frissítéseinek minősége.

Weak-tier failure modes¶

A weak-tier modellek két egymástól független okból nem benefitálnak:

Failure Mode 1: Harness invocation failure¶

Skill-load rate: Qwen3-32B 25.1% vs erős modellek ~96%
A weak-tier modell nem is TÖLTI BE a releváns harness artifact-ot
Ez a primary limitáció

Failure Mode 2: Harness adherence failure¶

Adherence decay across trajectory: weak-tier 4× erősebb
Qwen3-32B: 0.52 → 0.13 a trajectory során
A weak-tier betartja a harness-t, amíg frissen töltve, de elveszti a hosszú task során

Methodológia (Lin et al.)¶

Benchmarks (3, komplementer agent képességek)¶

Benchmark	Fókusz
SWE-bench Verified	Long-horizon code repair
MCP-Atlas	Multi-server tool orchestration
τ-bench	Trajectory-based agent evaluation

Modellek (7 LLM, capability tier-ek)¶

Tier	Modellek
Strong	Claude Opus 4.6, Sonnet 4.6
Mid-strong	Qwen3-235B, GPT-OSS-120B
Weak	Qwen3-32B, Llama-3.3-70B, Qwen3.5-9B

Metrikák¶

M_base(f) — agent base capability, H_0 alatt
Δupdate(e) — evolver harness-updating gain (fix agent, vary evolver)
Δbenefit(f) — agent harness-benefit gain (fix evolver, vary agent)
Harness-Following Rate — judge-elt metrika
Phase-Level Adherence Score — judge-elt metrika (Appendix D.3, D.4)

Gyakorlati javaslatok (Lin et al. Recommendation)¶

(i) Capability budget → task-solving agent, NEM az evolver¶

Mert a Δupdate flat, az evolver-be fektetett compute alacsony megtérülésű. A post-evolution score driver-e a task-solving agent Δbenefit képessége.

"Allocate capability budget to the task-solving agent, not the evolver."

(ii) Bake harness invocation into training¶

Weak-tier modellek 25%-os load rate-jét training oldalról kell javítani. Reward signal: "has loaded the relevant skill?" → training objective. Ez a primary lever.

(iii) Strengthen long-horizon instruction following¶

Adherence decay 4× erősebb weak-tier-nél. A long-horizon trajectory instruction fidelity training prior. Phase-level adherence score mérése a training alatt early-stop indikátorként.

Zhang et al. (2026-06-08, arXiv:2606.09498) — Self-Harness¶

A Self-Harness paradigma¶

Három lehetséges paradigma a harness-fejlesztés koordinátáin:

Human harness engineering — tapasztalt ML/agent mérnökök manuálisan írják és revideálják a system promptokat, tool-definíciókat és futásidejű szabályokat. Auditálható, de nem skálázódik a heti/havi modellrelease-ek ütemére.
Meta-Harness — erősebb külső agent javítja a gyengébbet (ADAS, Meta-Harness, Language Agents as Optimizable Graphs). Az optimalizáló nem ugyanaz a modell, mint az értékelt ágens.
Self-Harness — a rögzített modell önmaga javítja a saját körülötte lévő harness-t, strukturált végrehajtási bizonyítékok és szigorú regressziós kapuk felhasználásával. Nincs szülső erősebb ágens vagy emberi mérnök.

Az iteratív loop három fázisa (Zhang et al.)¶

A Self-Harness egy háromfázisú ciklikus folyamat, amely minden iterációban a viselkedési bizonyítékot mérhető harness-változtatássá alakítja:

1. Weakness Mining (gyengeség-bányászat). A ciklus kiindulópontja az aktuális h_t harness és egy rögzített modell M. A modellt a D_in held-in feladathalmazon futtatják, és minden feladatról keletkezik egy y_i kimenet, egy τ_i execution trace, valamint egy z_i = E(x_i, τ_i, y_i) verifikátor-kimenet (pass/fail). A Self-Harness ezeket a trace-eket klaszterezi, és nem izolált hibákat, hanem modell-specifikus failure pattern-eket azonosít.

A klaszterezés failure signature alapján történik: (c_i, q_i, m_i), ahol c_i a terminal verifier-level cause, q_i a causal status, m_i az absztrakt agent mechanism. Két failed trace akkor kerül egy klaszterbe, ha mindhárom komponensben megegyeznek — ez biztosítja, hogy ne superficiális tüneteket, hanem reusable mechanizmusokat csoportosítsunk.

2. Harness Proposal (harness-javaslat). A bányászott failure pattern-ek alapján a rendszer ugyanazt a modellt hívja meg, de most proposer szerepben. A modell feladata, hogy egy K darabos, diverz, de minimális jelölt-szerkesztést generáljon, ahol minden szerkesztés egy konkrét failure-mechanizmusra van rákötve.

Diverzitás proposal branches között (különböző mechanizmusok, surface-ek, hipotézisek)
Minimalitás branch-en belül (csak a szükséges felületet módosítja, megőrzi az unrelated harness viselkedést)
Minden szerkesztéshez audit record: targeted pattern, edited surface, expected effect, regression risks

3. Proposal Validation (regressziós validáció). Egyetlen jelölt szerkesztés sem kerül azonnali elfogadásra. A rendszer a D_in held-in spliten és a D_out held-out spliten egyaránt értékeli az aktuális h_t és a jelölt h_t^(j) = Δ_j(h_t) harness változatot. Az elfogadási szabály kógens: csak olyan szerkesztés kerül promótálásra, amely javítja a teljesítményt anélkül, hogy a held-out spliten mérhető degradációt okozna.

Held-in split: a javaslat megoldja-e a motiváló bizonyítékot?
Held-out split: regressziós teszt — a proposer soha nem látta
Acceptance rule: javít legalább egy split-en a másik rontása nélkül
Több kompatibilis candidate → merge-ölve a következő h_{t+1} harness-ba
Minden átmenet auditálható (changed surfaces, split-wise outcomes, accept/reject)

Kísérleti eredmények (Terminal-Bench-2.0)¶

89 containerized terminal task közül 64 kiértékelve (multimodal és unstable web task-ok kiszűrve).

Modell	Held-in (előtte→utána)	Held-out (előtte→utána)	Relatív javulás (held-out)
MiniMax M2.5	43.0% → 50.0% (+16%)	40.5% → 61.9% (+53%)	53%
Qwen3.5-35B-A3B	15.1% → 36.0% (+138%)	23.8% → 38.1% (+60%)	60%
GLM-5	47.7% → 57.0% (+20%)	42.9% → 57.1% (+33%)	33%

Abszolút maximum nyereség: 21.4pp (held-out) Relatív maximum nyereség: 138% (held-in, Qwen3.5)

A javulások nem korlátozódnak a held-in failure-ökre, amik a proposal evidence-t szolgáltatták: mindhárom modell javít a held-out spliten is, és egyetlen promoted harness sem degradálja egyik splitet sem. Ez alátámasztja a Self-Harness központi célját: a proposed edit-ek reusable execution mechanism-eket céloznak, nem case-specifikus failure-öket.

Modell-specifikus változások (Zhang et al.)¶

MiniMax M2.5: korai artifact creation, structured tool output kezelés, tool-use loop korlát, "redirect after long tool calls"
Qwen3.5-35B-A3B: dependency precheck, retry discipline, loop breaking, artifact recovery after tool errors
GLM-5: persistent environment settings (cd/export tartósak maradnak shell session-ök között), transition exploration→implementation, faster task resolution

A Self-Harness korlátai (Zhang et al.)¶

Csak bounded harness edit, nem open-ended self-improvement
Accepted edits-ek tükrözhetnek benchmark-specifikus failure pattern-eket
A protokoll függ a verifier outcome-ok és trace record-ok minőségétől
Magasabb stakes-ű harness-változtatásokhoz a pass-rate non-regression önmagában nem elég — erősebb acceptance gate-ek kellenének

Comparison: Lin et al. kontra Zhang et al.¶

Dimenzió	Lin et al. (2605.30621)	Zhang et al. (2606.09498)
Fókusz	Két képesség szétválasztása (updating vs. benefit)	End-to-end self-improvement loop
Benchmark	SWE-bench + MCP-Atlas + τ-bench	Terminal-Bench-2.0
Modellek	7 LLM (Claude Opus, Qwen, GPT-OSS, Llama)	3 modell (MiniMax M2.5, Qwen3.5, GLM-5)
Evolver	Vary evolver (fix agent) és vary agent (fix evolver)	Fix modell saját maga az evolver
Acceptance	Pass rate növekedés mérése Δupdate és Δbenefit	Non-regression: javít ≥1 split, nem rontja a másikat
Központi tanulság	Evolver képessége FLAT, agent Δbenefit a driver	Modell-specifikus failure-ökből célzott edit-ek, reusable mechanism-ekre

A két cikk komplementer: Lin et al. a harness evolution képesség-dekompozícióját adja (melyik komponens számít), Zhang et. al az end-to-end pipeline-t mutatja be, ami a gyakorlatban is működik. A Self-Harness loop (Zhang et al.) az, amit a gyakorlatban meg lehet valósítani; a Lin et al. metric dekompozíció (Δupdate, Δbenefit) pedig arra ad eszközt, hogy diagnosztizáljuk, hol van a szűk keresztmetszet a mi saját self-evolution rendszerünkben.

Kapcsolódó kutatások¶

Harness Engineering¶

A1, GEPA, TextGrad, DSPy — prompt optimization módszerek (ezek a score-ba konfundálják az updatert és a benefitet)

Self-Evolving LLM Agents¶

Sirius (Mem0 ecosystem)
Evo-Memory (test-time learning)
SE-Agent (SWE-bench)
A-EVO-Lab keretrendszer

Self-Improvement Loopok¶

Reflexion (verbal feedback)
Agentic context engineering
STOP (recursive self-improvement code generation-hoz)
ADAS, Meta-Harness (külső optimalizálás)
AI Scientist, AlphaEvolve, Alita, Gödel Agent, Darwin Gödel Machine (önfejlesztő rendszerek)

OpenClaw Párhuzam¶

A mi OpenClaw setup-unk pont egy harness self-evolution rendszer:

Komponens	Elem a mi rendszerünkben
Task-solving agent (f)	Az LLM (ollama/minimax-m3:cloud)
External harness (H)	SOUL.md, AGENTS.md, USER.md, MEMORY.md, HEARTBEAT.md, cron payloads, skills
Evolver (e)	A pipeline (beszélgetés → summary → wiki topic update → rebuild indexes)
Execution evidence	A session-ök teljes tartalma (capture-elve)
Harness-updating	A pipeline új leckéket, summary-kat ír ki
Harness-benefit	Az LLM a következő session-ön használja-e az új MEMORY.md-t

A két paper tanulságai a mi rendszerünkre¶

A evolver (pipeline) fejlesztésének alacsony a megtérülése (Lin et al. Finding 1). Mert a harness-updating flat — a Qwen3.5-9B-szintű evolverünk (a Whisper/summarize/wiki-rebuild pipeline) ugyanolyan jó update-eket produkál, mint egy erős modellre épített evolver. A pipeline-t egyszerűsíteni, nem trükkösíteni kell.
A task-solving agent (az LLM) képessége a fő limitáció (Lin et al. Finding 2). A mi esetünkben: ha a modell nem olvassa el a MEMORY.md-t (harness invocation failure), akkor az egész evolver-pipeline kidobott idő. Pre-flight check szükséges: a session startup tényleg betölti-e a MEMORY.md-t?
Long-horizon instruction following erősítése (Lin et al. Recommendation iii). A mi session-jeink általában 30-60 percesek. A 4× erősebb adherence decay hosszú conversation-öknél probléma. HEARTBEAT.md checklist rendszeres felolvasása segíthet (a broken window check most 08:00-kor fut, de session közben is lehetne).
Harness invocation training (Lin et al. Recommendation ii). Ha weak-tier modellre váltanánk (pl. Ollama lokális 9B), akkor a 25%-os load rate problémát jelentene. Most a mi Sonnet-class modellünk valószínűleg erős tier (96%+ load rate), de ha downgradelnénk, ez lenne az első kudarc.
Self-Harness acceptance gate (Zhang et al. Validation). A mi evolver-pipeline-unk jelenleg nem tartalmaz explicit regression gate-et — ha egy summary rossz, bekerül a wiki-be és rontja a downstream keresések minőségét. A Self-Harness minta alapján érdemes lenne egy held-out validation split-et bevezetni: minden új MEMORY.md entry vagy wiki topic update előtt ellenőrizni, hogy a meglévő keresési pontok (queries) továbbra is helyes találatokat adnak-e. Ha a regression gate romlást jelez, a módosítás elutasítódik.
Modell-specifikus harness edit-ek (Zhang et al. Per-model changes). A mi rendszerünkben is megfigyelhető, hogy a mi Sonnet-class modellünk másképp viselkedik, mint egy gyengébb modell. Például: Sonnet "érti" a magyar nyelvi konvenciókat, míg egy Ollama 9B valószínűleg nem. A Self-Harness minta alapján a mi esetünkben a harness-t (cron payloadok, MEMORY.md struktúra) a mi modellünk specifikus gyengeségeihez kellene hangolni — nem egy általános "best practice" felé.

Limitációk¶

Lin et al.¶

3 benchmark, 7 LLM — viszonylag szűk coverage
A "flat" eredmény lehet specific ezekre a benchmarkokra (SWE-bench + MCP-Atlas + τ-bench mind agent-értékelés, nem kreativitás / tudás)
A weak-tier failure mode-ok részletes mechanizmusa nem teljesen feltárt (miért 25% a load rate, és hogyan javítható traininggel?)
Phase-level adherence judge LLM-alapú, nem determinisztikus (Appendix D.4)

Zhang et al.¶

Csak bounded harness edit, nem open-ended self-improvement
Accepted edits-ek tükrözhetnek benchmark-specifikus failure pattern-eket
A protokoll függ a verifier outcome-ok és trace record-ok minőségétől
Magasabb stakes-ű harness-változtatásokhoz a pass-rate non-regression önmagában nem elég

Források¶

arXiv:2605.30621v1 — Harness Updating Is Not Harness Benefit¶

Szerzők: Minhua Lin, Juncheng Wu, Zijun Wang, Zhan Shi, Yisi Sang, Bing He, Zewen Liu, Tianxin Wei, Zongyu Wu, Zhiwei Zhang, Dakuo Wang, Xiang Zhang, Benoit Dumoulin, Cihang Xie, Yuyin Zhou, Suhang Wang, Hanqing Lu
Affiliations: Penn State, UCSC, Amazon, Emory, UIUC, Northeastern
Dátum: 2026-05-28
GitHub: https://github.com/A-EVO-Lab/a-evolve/tree/release/harness-evolution
Wiki raw: (paper txt deleted)

arXiv:2606.09498v1 — Self-Harness: Harnesses That Improve Themselves¶

Szerzők: Hangfan Zhang, Shao Zhang, Kangcong Li, Chen Zhang, Yang Chen, Yiqun Zhang, Lei Bai, Shuyue Hu
Affiliations: Shanghai Artificial Intelligence Laboratory
Dátum: 2026-06-08
URL: https://arxiv.org/html/2606.09498v1
Magyar összefoglaló: summaries/tanulmanyok/2026-06-16_self-harness-harnesses-that-improve-themselves.md
Wiki raw: raw/papers/2026-06-16_self-harness_arxiv_2606.09498.md

SoL-Pi (NVlabs, arXiv:2609.20519, 2026-09-17) — RSI-inspired auto-research loop a harness-rétegre¶

A SoL-Pi egy RSI-inspired rendszer, amely a coding agent-ek harness-rétegén (nem modell-súlyokon) kutat hatékonysági mechanizmusokat. 152 javasolt irány × 500 végrehajtható environment × 3000+ futás × 60 000+ interakció után négy mechanizmus maradt életben, amelyek kombinálva 44.7–49.0%-os token-csökkentést és ~33%-os API költség-megtakarítást érnek el az EdgeBench 51 feladatos benchmarkon, miközben a feladat-pontszám 93.7–106%-át tartják a Pi baseline-hoz képest.

A négy mechanizmus: 1. Action Fusion — fájl-szerkesztés + követő parancs egyetlen tool request-be; kiküszöböli az intermediate model round-tripet 2. Online Context Compact — plan-step completion boundary-nél cost gate (cache-rewrite költség vs. projected input savings); csak akkor compactol, ha megtakarítás várható 3. ObservationPack — 10 KiB-nél nagyobb tool output-okat lokálisan archiválja; a következő két provider request-ben teljes, utána csak handle + head/tail excerpt 4. Evidence-Preserving Reducer — build/test logokból (≥4 KiB) egy olcsóbb modell (GPT-5.6 Luna) "receipt"-et készít; determinisztikus verifier ellenőrzi (séma, source hash, exit status, pontos idézetek, méret); fallback az eredeti logra ha verification elbukik

A broad-to-deep funnel: outer stage 152 javasolt irány 6 proposal family-ben (context, progress, tools, delegation, prompt and policy, improvement and evaluation); inner stage független, disposable lineage-okban fejleszti a kiválasztott irányokat. Az EdgeBench 11 task = one-way acceptance of frozen candidates; 40 task = final held-out evaluation, soha nem táplál vissza a keresésbe.

SI-FMA-igazítás (Ren et al. 2026 §9.1): - (1) Fast exploration in scaffold: a harness (Σ) módosítása a cél; modell-súlyok (θ) érintetlenek; javaslatok reverzibilisek a held-out előtt - (2) Critic as governed infrastructure: EdgeBench acceptance criteria-k és capability toleranciák fagyasztva vannak; az optimalizáló AI nem módosíthatja a saját acceptance szabályait - (3) Layered gating: capability gate + efficiency gate + Pareto nondominated selection + held-out validation

Cross-backend transfer: a GPT-5.6 Sol trajectory-kon fejlesztett SoL-Pi módosítás nélkül átkerült Opus 5-re: 94.3% score retention, 44.7% token-csökkentés, 33.5% költség-megtakarítás. Sőt, a Performance pont Opus 5-ön 50.482 score-t ér el (a SoL-Pi cross-backend is javít).

Agent swarms (kernel benchmark): Codex coordinator + 20× SoL-Pi workers → 1127 ciklus (vs. 1366 Pi swarm, 1333 single agent), 26.8% API költség-megtakarítás a Pi swarm-hoz képest; 8/8 speed threshold átment.

Hosszú távú vízió: "pretraining the harness" — a harness-t "taníthatóvá" tenni sok feladaton való futtatással (hasonlóan a modell-pretraining-hez); "recursive efficient improvement" — egy hatékonyabb harness alacsonyabb költséget jelent a következő harness-t fejlesztő auto-research-hez.

Forrás: https://arxiv.org/abs/2609.20519 · Kód: https://github.com/NVlabs/SoL-Pi

LangChain: How to Build a Model Router in the Harness (2026-10-01) — a routing mint harness-szintű beavatkozás¶

A LangChain a saját kódoló agentjén (Open SWE) mérte meg a feladatonkénti modellválasztást: medián költség −64% (0,94 dollár a 2,61 dollárral szemben), mérhető minőségromlás nélkül (mergelési arány 29,2% vs. 27,3%, p = 0,49). A szálak 56%-a a kiegyensúlyozott, 34%-a a gyors, csak 10%-a a csúcs-szintre ment; a szintek között 30-szoros költségszórás van.

Miért tartozik ide (a harness self-evolution témához):

A modellválasztás a harness rétege, nem a modell-súlyoké. A cikk központi érve pontosan az, amit a Lin et al./Zhang et al. felosztás „external harness”-ként definiál: a döntés helye az a réteg, ahol a domain- és feladatkontextus összeáll. A szerzők kimondják, hogy egy általános gateway ezzel nem rendelkezik, ezért ott a döntés vak
A „routing mint kontextus-mérnökség” ugyanaz a gondolat, mint a SoL-Pi context-mechanizmusai: a harness azon dönt, milyen információt lásson a döntéshozó, hogy a viselkedés jó legyen
A SoL-Pi-hoz képest más mechanizmus, azonos cél. A SoL-Pi a kontextus tömörítésével és a tool-fúzióval ér el 44,7-49%-os token-csökkentést; a LangChain a modell megválasztásával 64%-os költségcsökkenést. Mindkettő a harness-rétegen dolgozik, és egyaránt érintetlenül hagyja a modell-súlyokat — ez pontosan az SI-FMA (1) szabálya: „fast exploration in scaffold, weights untouched”
A kudarc-dokumentálás módszertani minta. Az ellenkező irányú kontrollt (minden a gyors modellre) egy napon belül leállították, mert a mérnökök azonnal jelezték a minőségromlást. Ez a „governed critic” gyakorlati megfelelője: a harness-változtatást nem elég mérni, a rossz irányt is dokumentálni kell
A value tengely tanulsága ránk nézve: a szerzők a kritériumokat a saját feladat-elemzésükből írták, és elismerik, hogy a router „mélyen csatolt” az Open SWE feladataihoz. Azaz a harness-változtatás feladathalmaz-specifikus, nem általános — ugyanaz a korlát, amit a Self-Harness modell-specifikus változtatásainál is láttunk

Forrás: https://www.langchain.com/blog/how-to-build-a-model-router-in-the-harness · Archív: https://archive.codenewsletter.ai/2105704739585565066 · Kód: https://github.com/langchain-ai/open-swe (agent/middleware/model_selection.py) · Magyar összefoglaló: summaries/tanulmanyok/2026-10-01_langchain_model_router_in_the_harness.md