Разработчики часто обнаруживают, что им приходится снова и снова исправлять одни и те же ошибки у ИИ-агентов. Лорен Тан, работающая в команде SpaceX по ИИ и над React Compiler, разработала систему для решения этой проблемы. Ее подход, реализованный через набор навыков агента под названием "pstack", направлен на предотвращение повторяющихся ошибок путем проектирования кода и установления правил, которые направляют поведение ИИ.

Система Тан общедоступна и позволила ей отправить около 2500 pull-запросов в августе, в среднем по 80 в день, при этом ее агенты самостоятельно объединяли свой код. Мэтт Покок отметил ее вклад, включив ее в число трех лучших создателей навыков.

Проблема временных решений

Часто возникает проблема, когда ИИ-агенты внедряют временные обходные пути для исправления ошибок. Например, ошибка, вызывающая дублирование товаров в корзине покупок, может быть устранена агентом путем добавления кода для скрытия дубликатов с комментарием, указывающим, что это "временное решение, его можно игнорировать". Хотя это может пройти тесты и казаться исправлением непосредственной проблемы, первопричина ошибки остается. Затем это обходное решение может быть скопировано другими агентами для аналогичных проблем, распространяясь по всей кодовой базе. Тан сравнивает это с бонсай, где каждое исправление обрезает ветку, только для того, чтобы та же неправильная ветка отросла в другом месте, поскольку агенты склонны копировать существующие шаблоны.

Подход "Садоводство": Архитектурные исправления

Тан выступает за подход "садоводство", который включает в себя "подключение" кода для управления его ростом, а не постоянное "подрезание" ошибок. Эта иерархия исправлений отдает приоритет архитектурным решениям, которые предотвращают возникновение ошибок в первую очередь. Рейтинг выглядит следующим образом:

1. Архитектура: Проектирование кода таким образом, чтобы ошибка не могла возникнуть.
2. Правило линтера или Тест: Обнаружение ошибки во время непрерывной интеграции (CI).
3. Навык или Правило Агента: Управление поведением ИИ.
4. Проверка кода человеком: Наименее эффективный, помеченный как "NGMI" (Не справится).

Для примера с ошибкой в корзине исправление высшего уровня включало бы реструктуризацию данных для использования одной строки на продукт с указанием количества, тем самым предотвращая дублирование записей. За этим последовало бы удаление всех случаев обходного пути. Решение второго уровня — это правило линтера, которое помечает код, скрывающий дубликаты, и направляет пользователей к фактическому исправлению. Правило Тан "исправляй корневые причины", которое предписывает агентам отслеживать симптомы до их источника, представляет собой решение третьего уровня. Проверка кода человеком — четвертый уровень.

pstack: Фреймворк для поведения агентов

Фреймворк pstack от Tan разработан для агентов, которые работают с ограниченным контекстом, копируя соседние примеры и выбирая кратчайший путь к компиляции. Чтобы противодействовать этому, pstack делает правильный подход самым простым. Фреймворк Grok Bot, над которым работает Tan, применяет единый метод для всех операций: каждая функция имеет свою папку, правила линтинга предотвращают некорректные импорты, а комментарии к коду запрещены, чтобы агенты не использовали их как предлог для обходных путей.

pstack функционирует как бесплатный плагин для Cursor, предлагая 50 навыков. Пользователи активируют его командой "poteto mode", за которой следует их задача. Система выбирает один из 23 плейбуков (например, исправление ошибок, новая функция, производительность, выпуск) и разбивает шаги на список дел, вызывая другие навыки по мере необходимости. Многие из этих навыков представляют собой одиночные правила, такие как "удаляй перед добавлением" или "после двух неудачных исправлений ставь под сомнение общее предположение".

Рабочий процесс включает:

1. Ввод задачи: Отчет об ошибке, запрос на новую функцию или проблема с производительностью.
2. Выбор плейбука: "Poteto mode" выбирает соответствующий плейбук.
3. Воспроизведение/Картирование проблемы: Агент воспроизводит ошибку или картирует проблему.
4. Проектирование исправления: Агент проектирует решение.
5. Реализация исправления: Агент реализует решение.
6. Проверка: Исправление доказывается в работающем приложении.
7. Атака другими моделями: Различные ИИ-модели пытаются сломать исправление.
8. Выпуск: Исправление развертывается.

Любая повторяющаяся проблема интегрируется в репозиторий как "провод", улучшая кодовую базу для будущих задач. Grok Bot отслеживает Slack, X и трекеры ошибок, преобразуя новые отчеты в проекты, которые выполняют этот цикл, позволяя одному человеку управлять большим объемом pull-запросов.

Ошибка корзины через цикл pstack

Применение сценария ошибки корзины к циклу pstack:

1. Инициация: "Режим Poteto, товары отображаются в корзине дважды, сначала воспроизведите это." Это запускает плейбук исправления ошибок.
2. Воспроизведение: Агент использует сгенерированный навык проверки для запуска приложения, подтверждения его работоспособности, взаимодействия с ним и получения доказательств ошибки (два худи, появляющиеся в корзине). Этот навык проверки включает инструкции по запуску приложения, проверке его работоспособности, навигации по нему, получению доказательств и отображению расположения функций.
3. Анализ первопричин: Агенты только для чтения отслеживают клик от кнопки до корзины с помощью навыка "как". Навык "почему" анализирует прошлые коммиты и чаты, выявляя предыдущее временное решение. Агент тестирует гипотезы с доказательствами, пока не будет выявлена причина — двойной клик, отправляющий запрос дважды.
4. Проектирование и реализация исправления: Вмешивается навык "архитектор". Два агента независимо друг от друга проектируют исправление: один предотвращает двойные клики по кнопке, а другой модифицирует корзину, чтобы запретить дублирование товаров. Судья ИИ оценивает эти проекты, а ведущий агент принимает дизайн корзины, сохраняя исправление кнопки. Grok Bot пишет код, а Opus 5.5 принимает критические решения.
5. Проверка: Записывается сбойный тест (ожидается одно худи после двойного клика). Агент повторно тестирует работающее приложение, подтверждая, что появляется только одно худи.
6. Фаза атаки: Три модели пытаются сломать исправление с помощью навыка "допросить", их результаты категоризируются как "действовать", "рассмотреть", "принято к сведению" и "отклонено".

В полностью автоматическом режиме pstack развертывает агентов-верификаторов для каждого pull request, имитируя поведение пользователя для поиска регрессий и их исправления до тех пор, пока PR не будет объединен.

Цикл обзора и исправления

Перед слиянием изменения просматриваются судьей, тремя моделями и группой верификаторов. После слияния Лорен Тан просматривает историю коммитов и выборочно проверяет работу. Если два агента используют один и тот же обходной путь, она добавляет в систему "провод".

Новейший навык Тан, "исправить", замыкает этот цикл. Он анализирует недавние коммиты, откаты и комментарии к обзорам, чтобы выявить повторяющиеся ошибки агентов. Шаблон устанавливается, если ошибка возникает дважды. Для обходного пути "скрыть дубликат", который появился 40 раз, "исправить" реализует исправления высшего уровня: сначала архитектуру корзины для предотвращения дубликатов, затем удаление всех экземпляров обходного пути. Если архитектура невозможна, он переходит к решениям на основе типов, затем к правилам линтинга с сообщениями об ошибках, указывающими исправление, затем к тестам и, наконец, к документации. Каждая новая проверка должна завершиться неудачей на реальной исторической ошибке. Таблица в инструкциях агента сопоставляет правила с механизмами их применения.

Навык архитектора также был улучшен для проактивного выявления потенциальных проблем, таких как задачи двойного назначения, списки, синхронизированные вручную, и импортируемые внутренние компоненты. В слепых тестах его проекты улучшились примерно на один балл из восьми.

Система pstack также становится более оптимизированной. В сентябре Тан сократила 34 инструкции, которым Opus 5.5 следовал неявно. Навык обзора, протестированный с этими инструкциями и без них, обнаружил 142 из 154 внедренных проблем без них и 139 с ними. Основной принцип заключается в кодировании уроков в виде правил линтинга, проверок или скриптов, а затем удалении инструкций, поскольку агенты учатся на репозитории, в котором они работают.

Агенты Тан по-прежнему совершают ошибки, но каждая повторяющаяся ошибка преобразуется в постоянный "провод", такой как корзина, предотвращающая дубликаты, или ошибка линтинга, направляющая к правильному исправлению. Это гарантирует, что будущие агенты, сталкивающиеся с аналогичными проблемами, не будут иметь обходных путей для копирования, позволяя кодовой базе расти в соответствии с дизайном Тан.