--- title: 'Harness Self-Evolution: Updating vs. Benefit Capabilities' category: topic sources: - (paper txt deleted) - (paper txt deleted) - tanulmanyok/2026-06-16_self-harness_arxiv_2606.09498.md - tanulmanyok/2026-10-01_langchain_model_router_in_the_harness.md created: 2026-06-11 updated: '2026-10-02' tags: - ai - agent - harness - self-evolution - harness-updating - harness-benefit - evolver - base-capability - weak-tier-failure - harness-invocation - harness-adherence - long-horizon-instruction-following - self-harness - weakness-mining - harness-proposal - proposal-validation - terminal-bench - minimax-m2.5 - qwen3.5 - glm-5 - shanghai-ai-lab - regression-testing - propose-evaluate-accept - swe-bench - mcp-atlas - tau-bench - claude-opus - qwen - gpt-oss - llama - penn-state - ucsc - amazon aliases: - harness-evolution - evolution-capabilities - harness-decoupling - self-harness - self-improving-agents confidence: high summary: 'Két kulcsfontosságú arXiv paper a harness self-evolution témában. (1) arXiv:2605.30621v1 (Lin, Wu, Wang et al., 2026-05-28, Penn State + UCSC + Amazon + Emory + UIUC + Northeastern) — a harness self-evolution két független képességre bontható: harness-updating (az evolver minősége) és harness-benefit (az agent fogékonysága). Felfedezések: (i) harness-updating FLAT a base capability-ben (Qwen3.5-9B evolver ugyanolyan jó update-eket produkál, mint Claude Opus 4.6, Δupdate max 3.1pp eltérés); (ii) harness-benefit NON-MONOTONIC — weak-tier keveset benefitál, mid-tier a legtöbbet (GPT-OSS-120B), strong-tier performance ceiling-et üt (Opus 4.6). Weak-tier failure modes: 25.1% skill-load rate Qwen3-32B vs ~96% strong-nál; adherence decay 4× erősebb. (2) arXiv:2606.09498v1 (Zhang, Zhang, Li et al., 2026-06-08, Shanghai AI Lab) — Self-Harness paradigma: az LLM-alapú agent a saját harness-ét javítja iteratív Weakness Mining → Harness Proposal → Proposal Validation ciklusban. Terminal-Bench-2.0 benchmarkon 3 modell (MiniMax M2.5, Qwen3.5-35B-A3B, GLM-5) held-out pass rate 40.5%→61.9%, 23.8%→38.1%, 42.9%→57.1% — abszolút nyereség 21.4pp-ig, relatív 138%-ig. Modell-specifikus változások: M2.5 korai artifact + tool loop korlát, Qwen3.5 dependency precheck + retry discipline, GLM-5 persistent environment + exploration→implementation.' --- ## 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: 1. **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. 2. **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. 3. **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 1. **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. 2. **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? 3. **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). 4. **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. 5. **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. 6. **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: · Kód: ### 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:** · Archív: · Kód: (`agent/middleware/model_selection.py`) · Magyar összefoglaló: `summaries/tanulmanyok/2026-10-01_langchain_model_router_in_the_harness.md`