Перейти к контенту

SWE-agent: как дизайн интерфейса открывает возможности автоматизации разработки ПО

· 6 мин чтения
Mike Thrift
Mike Thrift
Marketing Manager

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

Статья

2026-05-01-swe-agent-agent-computer-interfaces-automated-software-engineering

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. Для сравнения: неинтерактивная RAG-система показала 3,8%, а базовая модель с простым поиском из оригинальной статьи SWE-bench — 1,96%. На 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; сочетание этих подходов дает более полную картину того, как агенты должны надежно выбирать и вызывать инструменты.