AGENTS.md: помогает ли файл контекста агенту?

Файл контекста попадает к агенту вместе с задачей. В него обычно записывают устройство проекта, команды для проверки и правила, по которым команда принимает изменения. Чтобы выяснить, что даёт этот файл, авторы Evaluating AGENTS.md сравнили результаты четырёх связок модели и обвязки. Codex и Qwen Code получали AGENTS.md, Claude Code — CLAUDE.md. Сгенерированные файлы готовили штатной командой /init каждого агента.

Первый набор, SWE-bench Lite, содержит 300 задач из известных Python-проектов. Здесь сравнили запуски без файла и с автоматически созданным файлом. Второй набор, CTXbench, собрали специально для сравнения с инструкциями разработчиков. В нём 138 задач из 12 репозиториев, где файл уже был в истории проекта. На все задачи одного репозитория приходится один и тот же набор инструкций. Поэтому число задач даёт представление о размере выборки исправлений, а разнообразие правил команды ограничено двенадцатью файлами.

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

Сгенерированные файлы прибавили в среднем 20 % к стоимости прогона на SWE-bench Lite и 23 % на CTXbench. Статистически значимой разницы в доле решённых задач относительно запусков без файла авторы не обнаружили. На CTXbench файлы разработчиков показали результат лучше сгенерированных. При сравнении с запуском без файла преимущество файлов разработчиков статистически не подтвердилось. Ведущий отмечает, что третья версия препринта формулирует вывод осторожнее первой.

Разбор последовательности действий помогает понять, куда уходят ресурсы. При явном указании на uv агент чаще использует uv. Инструкции о проверках ведут к дополнительным запускам тестов, а указания по поиску и чтению кода — к дополнительным обращениям к инструментам. Это признаки соблюдения правил. Пользу обзора репозитория исследователи проверили отдельно, посчитав шаги до первого обращения к файлу из исходного исправления. Заметного сокращения пути они не нашли. GPT-5.1 mini, например, иногда снова искал и перечитывал файл инструкций, который уже получил.

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

Авторы также проверили, что дают отдельные разделы сгенерированного файла. Удаление указаний о тестах или инструментах позволяло сократить стоимость в дополнительных прогонах с GPT-5.2. Убедительного изменения доли решений при удалении отдельных разделов не видно. Ведущий связывает это с вопросом о назначении правила. Если команда ценит конкретную проверку, её пользу следует измерять на задачах, где эта проверка обнаруживает существенную ошибку.

Ведущий переносит этот вопрос на постановку задачи. Из жалобы «иногда падает экспорт» можно сделать подробное задание со списком сценариев, требуемым порядком действий и типом возвращаемого значения. Когда эти сведения уже есть в задании, в файле остаётся меньше полезной для конкретного прогона информации. Авторы действительно показывают, что уточнение заданий SWE-bench Lite повысило результат GPT-5.2. Ведущий рассматривает это как возможное объяснение границ эксперимента на CTXbench, где агенты помогали составлять задания и тесты, а исследователи проверяли их вручную.

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

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

В ответах на вопросы разговор переходит к идее Regenerative Software Чада Фаулера. Если реализацию можно пересобрать, команде нужны явное описание намерения, проверки поведения и история решений. Проверкой этой идеи ведущий называет учение, на котором компонент восстанавливают по требованиям и тестам. По мере изменения системы эти материалы тоже приходится пересматривать, чтобы устаревшие правила и проверки не накапливались.

В поддержке проекта поводом к обновлению инструкций могут стать повторяющиеся сбои. Ведущий приводит пример, когда агент группирует ошибки за месяц и предлагает причины, а человек проверяет, согласуются ли исправления с устройством системы. Итогом разбора может стать правило в AGENTS.md, процедура в навыке или автоматическая проверка. В финале звучит ещё один способ сохранить опыт. Агент может разбирать историю сессий и накапливать знания о проекте, из которых команда затем отбирает устойчивые правила для файла контекста.