SWE-agent: Як дизайн інтерфейсу розкриває можливості автоматизованої програмної інженерії

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

Стаття

SWE-agent (Джон Янг, Карлос Е. Хіменес, Александр Веттіг, Кіліан Лірет, Шунью Яо, Картік Нарасімхан та Офір Пресс; Принстон / Стенфорд) вводить концепцію інтерфейсу агент-комп'ютер (ACI) — спеціально створеного програмного рівня, що знаходиться між LLM та середовищем Linux, розробленого не для користувачів-людей, а для того, як мовні моделі насправді обробляють інформацію. Стверджується, що дизайн цього інтерфейсу, а не базова модель, є основним вузьким місцем для автономних агентів програмної інженерії.

Система працює з проблемами GitHub із SWE-bench: вона читає проблему, навігує репозиторієм, знаходить відповідний код, редагує його та запускає тести для перевірки виправлення. Новизна полягає не в новій моделі чи процедурі навчання, а в наборі ретельно розроблених командних примітивів та форматів зворотного зв'язку, які замінюють стандартну оболонку Linux.

Ключові ідеї

• Інтерфейс перевершує чисту оболонку на 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% — що втричі краще за попередні системи — використовуючи інтерактивні інструменти агента, які підтримують паралельні сесії оболонки.

Що підтверджується, а що — ні

Основна ідея — про те, що дизайн інтерфейсу для агентів так само важливий, як і промпт-інжиніринг — добре обґрунтована, і я вважаю її справді корисною. Абляція проведена чесно: автори ізолюють компоненти та показують внесок кожного з них. Приріст у 10,7 в.п. порівняно з базовою чистою оболонкою — це чистий результат, який неможливо пояснити різницею в моделях.

У чому я менш переконаний: у самому бенчмарку. Набір тестів SWE-bench містить проблеми, які сильно різняться за складністю, неоднозначністю та тим, наскільки чітко визначено еталонне виправлення. Висока варіативність якості проблем означає, що цифра 12,47% частково є наслідком того, які саме проблеми потрапили в оцінювальний набір. Автори опосередковано зазначають це, повідомляючи результати на SWE-bench Lite (300 проблем) для абляцій, але варіативність у межах цієї підмножини все одно залишається високою.

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

Також залишається питання відтворюваності, до якого я постійно повертаюся: вибір дизайну інтерфейсу (вікно в 100 рядків, мінімалістичний вивід пошуку) був знайдений шляхом ітеративних експериментів на тренувальній вибірці. Цей вибір не є очевидно переносним на нові домени без аналогічних зусиль з налаштування. Це реальна ціна.

Чому це важливо для ШІ у фінансах

Концепція 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; ці два підходи разом створюють повнішу картину того, як агенти мають надійно обирати та викликати інструменти.