SWE-agent: Как дизайнът на интерфейса отключва автоматизираното софтуерно инженерство

Миналата седмица прочетох статията за SWE-bench и останах с прост извод: чистият GPT-4 едва решава 1,96% от реалните проблеми в GitHub. Тази седмица исках да разбера последващия въпрос — какво всъщност променя това число? SWE-agent от Yang и др. (NeurIPS 2024) отговаря на него и отговорът е измамно скучен: по-добри интерфейси.

Статията

SWE-agent (John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan и Ofir Press; Принстън / Станфорд) въвежда концепцията за Интерфейс Агент-Компютър (Agent-Computer Interface - ACI) — специално изграден софтуерен слой, разположен между LLM и Linux среда, проектиран не за човешки потребители, а за начина, по който езиковите модели всъщност обработват информация. Твърдението е, че дизайнът на този интерфейс, а не базовият модел, е основното тясно място за автономните софтуерни инженерни агенти.

Системата работи по GitHub issues от SWE-bench: тя чете проблема, навигира в хранилището, локализира съответния код, редактира го и изпълнява тестове, за да провери корекцията. Иновативният принос не е нов модел или процедура за обучение, а набор от внимателно проектирани примитиви за команди и формати за обратна връзка, които заменят стандартния Linux shell.

Ключови идеи

• Интерфейсът превъзхожда чистия shell с 10,7 процентни пункта. При аблационен тест върху 300 инстанции на SWE-bench Lite, SWE-agent решава с 10,7 пункта повече проблеми в сравнение с идентичен агент, поставен в чиста Linux конзола. Това е най-големият лост за влияние в статията.
• Преглед на файлове с прозорци от 100 реда. Вместо да използва cat за цели файлове, ACI показва около 100 реда на ход с команди за превъртане. Твърде малко контекст (30 реда) коства 3,7 пункта; твърде много (целия файл) кара модела да губи фокус. Оптималната точка е тясна.
• Линтер в цикъла на редактиране. Всяка команда за редактиране изпълнява синтактична проверка преди записване на промяната. Това предотвратява засядането на модела в състояния с дефектен код, от които е трудно да се излезе само чрез естествен език.
• Минималистично търсене в директории. Вместо grep -r с околен контекст (който претоварва модела), ACI връща само списък със съвпадащи имена на файлове. По-малкото е повече, когато моделът трябва да реши къде да погледне след това.
• Пълен резултат от бенчмарка: 12,47% на SWE-bench с GPT-4 Turbo, спрямо 3,8% за неинтерактивна RAG система и 1,96% за базовото търсене от оригиналната статия за SWE-bench. HumanEvalFix достигна 87,7%.
• Дизайнът на ACI е универсален. Вариант за киберсигурност (SWE-agent EnIGMA) приложи същата ACI философия към CTF предизвикателства, постигайки 13,5% — три пъти по-силно от предишни системи — използвайки интерактивни инструменти за агенти, които поддържат паралелни shell сесии.

Какво се потвърждава — и какво не

Основното прозрение — че дизайнът на интерфейса за агенти е толкова важен, колкото и промпт инженерингът — е добре подкрепено и го намирам за наистина полезно. Аблацията е честна: авторите изолират компонентите и показват какво допринася всеки от тях. Предимството от 10,7 пункта пред чистия shell е чист резултат, който не може да бъде обяснен с разлики в моделите.

Това, в което съм по-малко убеден: самият бенчмарк. Тестовият набор SWE-bench съдържа проблеми, които варират огромно по сложност, неяснота и това колко добре е дефиниран финалният пач. Голямата вариация в качеството на проблемите означава, че цифрата 12,47% е отчасти твърдение за това кои проблеми случайно са попаднали в набора за оценка. Авторите отбелязват това косвено, като отчитат резултати върху SWE-bench Lite (300 проблема) за аблациите, но вариацията в тази подгрупа все още е висока.

По-голямото ограничение е обхватът: SWE-bench измерва решаването на единичен проблем в изолация. Няма памет за сесиите между различните проблеми, няма разбиране на историята на кодовата база и няма проследяване на зависимости между множество проблеми. SWE-Bench Pro (arXiv:2509.16941, 2025) по-късно показа, че дори най-добрите модели падат под 25%, когато проблемите изискват координирани промени в множество файлове — производителността рязко спада с увеличаване на броя на файловете. ACI помага в рамките на един проблем, но трудният въпрос е случаят с дълъг хоризонт и множество файлове, за който SWE-agent никога не е бил проектиран.

Съществува и въпросът за възпроизводимостта, към който се връщам: изборът на дизайн на интерфейса (100-редов прозорец, минималистичен изход при търсене) е намерен чрез итеративни експерименти върху набора за обучение/разработка. Тези избори не са очевидно преносими към нови области без подобни усилия за настройка. Това е реална цена.

Защо това е важно за AI във финансите

Рамкирането на ACI се пренася директно върху проблема с дизайна на агенти за Beancount. Счетоводната книга на Beancount не е команден ред, но е структуриран артефакт, който моделът трябва да чете, навигира и записва. Уроците се пренасят:

• Браузър за счетоводни книги, който показва 20–50 транзакции наведнъж — с команди за превъртане и филтриране — ще се представи по-добре от такъв, който изсипва данни за 10 години наведнъж. Препълването на контекстния прозорец е същият тип грешка.
• Валидатор на записите, който проверява баланса по метода на двойното записване и съществуването на сметките преди потвърждаване на записа, е счетоводният еквивалент на линтера на SWE-agent. Без него агент, който генерира синтактично грешен запис, няма път за възстановяване.
• Минималистичното търсене е важно: заявка "покажи ми всички транзакции в сметка X между дати Y и Z" трябва да връща компактен списък за бърз преглед, а не подробен изход с излишен околен контекст.

Статията също така поставя практичен ориентир за това какво да очакваме от ранните версии на агент за обратен запис в Beancount. Коефициент на решаване от 12,47% при добре дефинирани проблеми в GitHub е текущият таван за внимателно проектиран агент за единични задачи. Обратният запис в счетоводна книга включва подобна структура на задачите — намерение на потребителя, структуриран файл, изискван резултат, проверител — и бих очаквал подобни нива при добре дефинирани задачи, с рязко влошаване при работни процеси с множество записи и множество сметки.

Какво да прочетете след това

• MemGPT: Towards LLMs as Operating Systems [arXiv:2310.08560] — управлението на контекста в SWE-agent е реактивно (съкращаване при препълване); MemGPT предлага проактивна йерархична памет, което изглежда необходимо за агенти, които трябва да разсъждават върху многогодишни Beancount книги.
• SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? [arXiv:2509.16941] — директно продължение на темата за това къде SWE-agent не успява; данните за влошаването при работа с множество файлове са задължително четиво за проектиране на безопасност при обратен запис в сложни счетоводни книги.
• Gorilla: Large Language Model Connected with Massive APIs [arXiv:2305.15334] — ако ACI е за дизайна на интерфейса, Gorilla е за извличането на API; двете се комбинират в по-пълна картина за това как агентите трябва да избират и извикват инструменти надеждно.