Качество программирующего агента часто снижается не потому, что модель стала менее способной, а потому, что в проекте отсутствует чёткая операционная система, регулирующая, что агент читает, что делает и как проверяются его изменения. По мере того как работа продолжается неделями и накапливаются тысячи изменений, агент может заново искать те же файлы, противоречить предыдущему решению, угадывать команду для тестирования или перестать писать тесты, если эти шаги не сделать обязательными.
В шестой части серии «Запуск систем LLM в продакшене» Stack Overflow Blog предлагает создать вокруг модели организационный слой, включающий краткую конституцию проекта, границы автономности, многоуровневый контекст, постоянную память, комитет ревью и хук, срабатывающий после каждого изменения. При запуске нескольких агентов в одном репозитории добавляются карта владения файлами, журналы запросов и общий журнал решений.
Проблема в операционной оболочке, а не только в модели
В статье агент определяется как модель, дополненная инструкциями, инструментами, политиками контекста, хуками, изоляцией, субагентами и механизмами мониторинга. В качестве общей иллюстрации приводится результат Terminal-Bench 2.0: LangChain вывела агента из-за пределов топ-30 в топ-5, изменив только операционную оболочку; результат вырос с 52.8% до 66.5%, то есть на 13.7 пункта, при сохранении той же модели.
Практический вывод заключается в том, что неполные инструменты, расплывчатые правила или перегруженный контекст могут быть наиболее легко устранимой причиной сбоя. В отличие от модели, команда разработки может изменять этот слой и адаптировать его к своему репозиторию.
Шесть элементов дисциплинированного агента
- Конституция проекта: файл вроде CLAUDE.md или AGENTS.md, определяющий рабочий цикл: планирование, документирование, реализация, тестирование, ревью, затем фиксация изменений. В нём также должны быть указаны критерии качества и ограничения на использование пакетов поставщиков; файл следует сохранять коротким, поскольку он читается на каждой сессии.
- Границы автономности: агенту разрешаются обратимые операции, такие как чтение, редактирование, тестирование и создание коммитов, тогда как для отправки изменений, развёртывания и применения изменений инфраструктуры требуется одобрение. Необходимо проверять семантику сопоставления команд, чтобы широкие правила вроде npm:* случайно не разрешали публикацию.
- Многоуровневый контекст: корневой CONTEXT.md содержит карту проекта и способы его запуска и тестирования, а файл каждой подсистемы описывает её назначение, файлы и зависимости. В DECISIONS.md фиксируются решения, их причины и отвергнутые альтернативы. Устаревший контекст считается ошибкой, которую следует исправлять в рамках самого изменения.
- Постоянная память: материал предлагает отдельные файлы памяти для каждого факта, краткий индекс и файл graph.jsonl, связывающий подсистемы и решения отношениями вроде «зависит от» или «заменяет».
- Комитет многопланового ревью: субагенты проверяют изменение с позиций продукта, инженерии, инфраструктуры, безопасности и тестирования. Изменение блокируется только при наличии препятствия или серьёзной проблемы с высокой степенью уверенности.
- Хук после изменения: PostToolUse запускается после каждого Edit, Write или MultiEdit и выводит список напоминаний об обновлении контекста, памяти и журнала решений в рамках самого изменения, вместо того чтобы молча переписывать файлы.
При запуске флота агентов
Новая проблема возникает, когда несколько агентов работают в одном репозитории: они изменяют одни и те же файлы или отменяют решения друг друга. Статья не предлагает полагаться на прямые разговоры между ними, а рекомендует общее записанное и проверяемое состояние, включающее карту владения путями, журналы CLAIM и RELEASE, журнал прогресса и отдельную ветку для каждой задачи с участием человека в слиянии.
Эти заявки не являются настоящей блокировкой: два агента могут одновременно прочитать одно и то же состояние и заявить один и тот же путь. При необходимости фактической изоляции статья рекомендует атомарный механизм, например ветку Git с уникальным именем или условную запись в хранилище координации.
Почему этот подход важен?
Главное изменение здесь заключается в переносе фокуса со способности агента написать функцию на способность окружающей системы сохранять его направленность и проверяемость на протяжении времени. Журнал решений выполняет не только документирующую, но и договорную роль: старые решения не изменяются; вместо этого добавляются новые решения, заменяющие их, с объяснением причины и отвергнутых альтернатив. Благодаря этому история проектирования остаётся видимой и может быть связана с автоматическими проверками, например с запретом определённых импортов.
Этот подход остаётся организационным руководством, а не гарантией корректности результатов. Статья также признаёт, что основанные на файлах заявки носят рекомендательный характер, когда столкновения происходят одновременно, а человеческое ревью остаётся контрольной точкой при слиянии, отправке изменений и развёртывании. Итог материала таков: ограничение модели и создание проверяемых следов могут сильнее влиять на надёжность долгосрочной работы, чем ожидание более умной модели.