SWE-agent: Ako dizajn rozhrania odomyká automatizované softvérové inžinierstvo

Minulý týždeň som čítal článok o SWE-bench a odniesol som si z neho jednoduchý poznatok: čistý GPT-4 dokáže vyriešiť sotva 1,96 % reálnych problémov na GitHub-e. Tento týždeň som chcel pochopiť nadväzujúcu otázku — čo vlastne toto číslo posúva? SWE-agent od Yang et al. (NeurIPS 2024) na to odpovedá a táto odpoveď je klamlivo nudná: lepšie rozhrania.

Odborný článok

SWE-agent (John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan a Ofir Press; Princeton / Stanford) zavádza koncept rozhrania agent-počítač (ACI) — účelovo vytvorenú softvérovú vrstvu nachádzajúcu sa medzi LLM a prostredím Linuxu, navrhnutú nie pre ľudských používateľov, ale pre to, ako jazykové modely v skutočnosti spracúvajú informácie. Tvrdením je, že dizajn tohto rozhrania, nie podkladový model, je primárnym úzkym hrdlom pre autonómne agenty v softvérovom inžinierstve.

Systém pracuje s problémami z GitHub-u zo sady SWE-bench: prečíta problém, naviguje v repozitári, lokalizuje relevantný kód, upraví ho a spustí testy na overenie opravy. Novým prínosom nie je nový model alebo tréningový postup, ale súbor starostlivo navrhnutých príkazových primitív a formátov spätnej väzby, ktoré nahrádzajú predvolený shell Linuxu.

Kľúčové myšlienky

• Rozhranie prekonáva čistý shell o 10,7 percentuálneho bodu. Pri ablácii na 300 inštanciách SWE-bench Lite vyriešil SWE-agent o 10,7 p.b. viac problémov ako inak identický agent nasadený do čistého prostredia shellu Linuxu. To je najvýznamnejší faktor v celom článku.
• Prehliadač súborov so 100-riadkovými oknami. Namiesto vypisovania celých súborov pomocou cat, ACI zobrazuje približne 100 riadkov na jeden krok s príkazmi na posúvanie. Príliš málo kontextu (30 riadkov) stojí 3,7 p.b.; príliš veľa (celý súbor) spôsobuje, že model stráca pozornosť. Ideálny bod je úzky.
• Linter v cykle úprav. Každý editačný príkaz spustí kontrolu syntaxe pred potvrdením zmeny. To zabraňuje tomu, aby sa model zasekol v stavoch s chybným kódom, z ktorých je ťažké uniknúť len pomocou prirodzeného jazyka.
• Minimalistické vyhľadávanie v adresároch. Namiesto grep -r s okolitým kontextom (ktorý model zahltil), ACI vracia iba zoznam zodpovedajúcich názvov súborov. Menej je viac, keď sa model musí rozhodnúť, kam sa pozrieť ďalej.
• Celkový výsledok benchmarku: 12,47 % na SWE-bench s GPT-4 Turbo, v porovnaní s 3,8 % pri neinteraktívnom systéme RAG a 1,96 % pri jednoduchom vyhľadávacom základnom modeli z pôvodného článku o SWE-bench. HumanEvalFix dosiahol 87,7 %.
• Dizajn ACI je zovšeobecniteľný. Kyberbezpečnostný variant (SWE-agent EnIGMA) aplikoval rovnakú filozofiu ACI na výzvy typu CTF a dosiahol 13,5 % — čo je trikrát silnejší výsledok ako u predchádzajúcich systémov — s použitím interaktívnych nástrojov agenta, ktoré udržiavajú súbežné relácie shellu.

Čo obstojí — a čo nie

Základný poznatok — že dizajn rozhrania pre agentov je rovnako dôležitý ako prompt engineering — je dobre podložený a považujem ho za skutočne užitočný. Ablácia je úprimná: autori izolujú komponenty a ukazujú, čím každý z nich prispieva. Zisk 10,7 p.b. oproti základu s čistým shellom je jasný výsledok, ktorý nemožno vysvetliť rozdielmi v modeloch.

Čím som si menej istý: samotným benchmarkom. Testovacia sada SWE-bench obsahuje problémy, ktoré sa enormne líšia v zložitosti, nejednoznačnosti a v tom, ako dobre je špecifikovaná správna oprava. Vysoký rozptyl v kvalite problémov znamená, že číslo 12,47 % je čiastočne výpoveďou o tom, ktoré problémy sa náhodou dostali do evaluačnej sady. Autori to nepriamo poznamenávajú tým, že uvádzajú výsledky na SWE-bench Lite (300 problémov) pre ablácie, ale rozptyl v rámci tejto podmnožiny je stále vysoký.

Väčším obmedzením je rozsah: SWE-bench meria riešenie jedného problému v izolácii. Neexistuje žiadna pamäť relácií naprieč problémami, žiadne pochopenie histórie kódovej základne a žiadne sledovanie závislostí medzi viacerými problémami. SWE-Bench Pro (arXiv:2509.16941, 2025) neskôr ukázal, že aj špičkové modely klesajú pod 25 %, keď problémy vyžadujú koordinované zmeny vo viacerých súboroch — výkon prudko klesá so zvyšujúcim sa počtom súborov. ACI pomáha v rámci jedného problému, ale náročným problémom je dlhodobý horizont a prípady s viacerými súbormi, na ktoré SWE-agent nikdy nebol navrhnutý.

Je tu tiež otázka reprodukovateľnosti, ku ktorej sa stále vraciam: rozhodnutia o dizajne rozhrania (100-riadkové okno, minimalistický výstup vyhľadávania) boli nájdené iteratívnym experimentovaním na tréningovej/vývojovej sade. Tieto voľby nie sú zjavne prenosné do nových domén bez podobného úsilia pri ladení. To predstavuje reálne náklady.

Prečo je to dôležité pre finančnú AI

Rámcovanie ACI sa priamo premieta do problému návrhu agenta pre Beancount. Hlavná kniha Beancount nie je príkazový riadok, ale je to štruktúrovaný artefakt, ktorý model potrebuje čítať, navigovať v ňom a zapisovať doň. Ponaučenia sú prenosné:

• Prehliadač hlavnej knihy, ktorý zobrazuje 20–50 transakcií naraz — s príkazmi na posúvanie a filtrovanie — prekoná ten, ktorý naraz vyhodí dáta za 10 rokov. Pretečenie kontextového okna je rovnaký typ zlyhania.
• Validátor zápisu, ktorý pred potvrdením záznamu skontroluje rovnováhu podvojného zápisu a existenciu účtov, je ekvivalentom lintera SWE-agent v hlavnej knihe. Bez neho agent, ktorý vytvorí syntakticky chybný záznam, nemá cestu k náprave.
• Minimalistické vyhľadávanie je dôležité: dopyt „ukáž mi všetky transakcie na účte X medzi dátumami Y a Z“ by mal vrátiť kompaktný, prehľadný zoznam, nie rozvláčny výpis s okolitým kontextom.

Článok tiež stanovuje praktické meradlo toho, čo očakávať od raných verzií agenta na zápis do Beancount. Úspešnosť riešenia 12,47 % na dobre definovaných problémoch z GitHub-u je súčasným stropom pre starostlivo navrhnutého agenta zameraného na jeden problém. Zapisovanie do hlavnej knihy zahŕňa podobnú štruktúru úloh — zámer používateľa, štruktúrovaný súbor, požadovaný výstup, overovateľ — a očakával by som porovnateľnú úspešnosť pri dobre definovaných úlohách, s prudkým zhoršením pri pracovných postupoch s viacerými záznamami a viacerými účtami.

Čo si prečítať ďalej

• MemGPT: Smerom k LLM ako operačným systémom [arXiv:2310.08560] — správa kontextu v SWE-agent je reaktívna (skrátenie pri pretečení); MemGPT navrhuje proaktívnu stupňovitú pamäť, ktorá sa zdá byť nevyhnutná pre agenty, ktoré potrebujú pracovať s viacročnými hlavnými knihami Beancount.
• SWE-Bench Pro: Dokážu AI agenty riešiť softvérové úlohy s dlhým horizontom? [arXiv:2509.16941] — priamo nadväzuje na miesta, kde SWE-agent zlyháva; údaje o degradácii pri viacerých súboroch sú nevyhnutným čítaním pre návrh bezpečnosti zápisu v komplexných hlavných knihách.
• Gorilla: Veľký jazykový model prepojený s masívnymi API [arXiv:2305.15334] — ak je ACI o dizajne rozhrania, Gorilla je o vyhľadávaní API; tieto dve oblasti sa spájajú do kompletnejšieho obrazu toho, ako by mali agenty spoľahlivo vyberať a vyvolávať nástroje.