Как мы мигрировали AGENTS.md под GPT‑5.6 Sol и не потеряли контроль

Всё началось с простой и довольно тревожной мысли: появилась GPT-5.6 Sol, модель стала самостоятельнее, а значит, наши старые инструкции могли начать работать не так, как раньше.

Я прочитал несколько разборов, посмотрел официальные рекомендации OpenAI и пришёл к Стёпе с понятным человеческим запросом: давай обновим AGENTS.md, потому что новая модель активнее действует, запускает субагентов и иначе трактует правила.

Самый опасный вариант в этот момент — немедленно открыть файл и начать его переписывать.

Именно этого мы не сделали.

Вместо правок мы сначала собрали пакет работы, зафиксировали исходное состояние, построили проверочную матрицу и провели границу: до отдельного решения ни одного изменения в рабочем AGENTS.md, настройках, Notion, Linear или GitHub.

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

И главное: не потеряли контроль над более самостоятельной моделью.

На какой конфигурации мы это делали

Моя рабочая схема довольно нетипична: MacBook Pro M5 — основная машина, на которой я каждый день работаю с Codex. Mac mini M4 Pro — второй постоянно доступный контур со своей установкой Codex, локальными настройками, подключениями и состоянием авторизации. Это не запасной компьютер, а полноценная вторая рабочая среда.

Поэтому миграцию нельзя было считать завершённой после проверки одного ноутбука. Глобальные правила и зашифрованные профили нужно было синхронизировать, а версии Codex CLI, OAuth-сессии, пути к Node.js и набор MCP — проверить на каждой машине отдельно. В такой конфигурации особенно хорошо видно: одинаковый AGENTS.md ещё не гарантирует одинаковое поведение агента.

Новая модель не требует немедленно переписывать всё

Когда выходит новая сильная модель, возникает естественное желание срочно «оптимизировать промпт». Кажется, что старые правила устарели, новая модель умнее и теперь ей нужно объяснять всё по-другому.

Но здесь легко попасть в ловушку.

Большой AGENTS.md обычно растёт не от плохой архитектуры, а от реального опыта. В нём накапливаются правила безопасности, договорённости о Git, работа с продакшеном, секретами, субагентами, Notion, Linear, файлами и проверками. Если начать бездумно вырезать «лишнее», можно вместе с повторами удалить то, что однажды уже спасло от ошибки.

Поэтому первая задача была не «написать новый файл», а понять:

• какие правила должны загружаться всегда;
• какие нужны только в определённых типах задач;
• где есть повторы и противоречия;
• какие факты устаревают со временем;
• где модель обязана остановиться;
• как доказать, что после сокращения поведение не стало опаснее.

Это сильно меняет сам подход. Мы перестаём редактировать текст по вкусу и начинаем проектировать рабочий договор между человеком и агентом.

Сначала пакет работы, потом изменения

Мы зафиксировали несколько обязательных вещей.

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

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

В-третьих, доказательство результата: не субъективное «стало чище», а сравнимые проверки до и после.

В-четвёртых, путь отката: снимок исходного состояния, контрольные суммы, резервные копии и точное понимание, какие изменения можно вернуть.

Отдельной линией мы начали собирать материалы для будущей публикации. Каждый факт помечался как один из трёх классов:

• официальный — подтверждён документацией OpenAI;
• наблюдаемый — получен в нашем запуске;
• гипотеза — выглядит разумно, но ещё требует проверки.

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

Что было не так со старым AGENTS.md

Старый файл не был плохим. Наоборот, он хорошо отражал несколько месяцев реальной работы.

Проблема была в другом: он разросся примерно до 70 килобайт и 342 строк. В одном постоянном слое соседствовали:

• общие правила безопасности;
• инструкции для продакшена;
• работа с документами;
• маршрутизация между Notion, Linear и GitHub;
• правила дизайна;
• доступы и секреты;
• обработка ошибок;
• субагенты;
• конкретные сведения о текущем состоянии сервисов;
• длинные объяснения отдельных рабочих режимов.

Модель получала всё это почти в каждой задаче, даже если я просил перевести абзац или проверить одну команду.

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

Мы решили разделить постоянные принципы и специализированные процедуры.

Короткое ядро и тематические инструкции

Новая структура получилась двухуровневой.

В коротком AGENTS.md остались правила, которые должны действовать всегда:

• приоритет прямого ограничения пользователя;
• границы мутаций;
• требования к секретам;
• правила работы в грязном репозитории;
• обязательная проверка после изменений;
• условия остановки перед продакшеном;
• ответственность главного агента;
• запрет считать промежуточный результат завершённой задачей.

Подробные процессы переехали в тематические файлы:

• работа по принципу Codex-first;
• эксплуатационные задачи, ошибки и внедрения;
• дизайн и инструменты;
• доступы, MCP и изоляция среды выполнения.

Модель читает такой файл только тогда, когда тема действительно затронута.

Это похоже на нормальную документацию в компании. Сотруднику не выдают на каждую мелкую задачу одновременно инструкции отдела кадров, аварийный план, руководство по бренду и схему доступа к серверам. Есть короткие общие правила и материалы по конкретной работе.

После миграции постоянное ядро уменьшилось примерно с 70 до 18 килобайт: на 75 процентов. Количество строк сократилось с 342 до 133.

Но уменьшить файл было недостаточно. Нужно было доказать, что вместе с объёмом мы не вырезали осторожность.

Как мы проверяли поведение модели

Мы собрали набор сценариев, которые отражают не красоту текста, а реальные риски.

Среди них были:

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

Для секретов использовались только искусственные значения. Для изменений — одноразовая рабочая папка. Внешние подключения и плагины в проверочной среде были отключены.

Мы смотрели не только на финальный ответ модели. Проверялись команды, обращения к инструментам, изменения файлов и признаки внешних мутаций.

Результат оказался хорошим:

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

Постоянный входной контекст на коротких проверках уменьшился примерно на 36 процентов.

При этом скорость ответа не улучшилась. В некоторых запусках новая версия даже была немного медленнее. Мы не стали прятать этот результат: задержка зависит от маршрута, источников и инструментов, поэтому пока её нельзя честно считать выигрышем.

Это полезный урок. Оптимизация инструкций не обязана мгновенно ускорять модель. Её главная ценность здесь — ясность, управляемость и меньшая стоимость постоянного контекста.

Затем всплыли доступы

После проверки AGENTS.md мы перешли к внедрению и обнаружили следующий слой задачи: настройки MCP и доступы на двух машинах.

Здесь очень легко испугаться и начать отзывать все ключи подряд. Особенно если в старых настройках встречаются следы прежних способов подключения.

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

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

Ротация без доказательств тоже создаёт риск. Можно сломать рабочие процессы, забыть один потребитель, потерять доступ или оставить старый ключ активным в неожиданном месте. Безопасность — это не максимальное количество движений. Это точное действие по подтверждённой причине.

Статические доступы мы оставили в зашифрованном хранилище на основе SOPS, age и mise. Они передаются только в отдельный дочерний процесс через специальную обёртку. Глобально в оболочку и в настройки Codex секреты не экспортируются.

OAuth-сессии остались там, где им и положено быть: в собственном хранилище приложения или сервиса.

Оказалось, что «подключённый сервис» — это не одна вещь

Самым интересным открытием стал MCP.

Я думал о подключении Notion, Linear или GitHub как об одном соединении: либо работает, либо нет. На практике один сервис мог одновременно существовать в четырёх вариантах:

• встроенный MCP;
• подключение через приложение;
• прямой API;
• локальный MCP-процесс.

Один маршрут работал, другой рядом с ним возвращал ошибку авторизации, а при запуске Codex создавалось впечатление, что сломан весь сервис.

Например, приложение Linear уже отвечало, прямой API тоже работал, но отдельный встроенный MCP не имел своей OAuth-сессии и шумел ошибкой. Похожая ситуация была с GitHub и Cloudflare.

Решение получилось простым: на каждый сервис оставить один доказанный рабочий маршрут, а не коллекцию подключений «на всякий случай».

Мы:

• восстановили OAuth для Notion там, где он действительно был нужен;
• оставили рабочие подключения приложений для Notion, Linear и GitHub;
• сохранили проверенные API-маршруты для Linear и Cloudflare;
• выключили неавторизованные дубли;
• перевели локальные MCP на единый Node.js 24;
• исправили адрес, который перенаправлял запрос и превращал его в ошибку;
• выровняли права на локальные файлы авторизации;
• удалили устаревший маршрут к несуществующему локальному процессу.

Context7, Refero, X, Plaud и Tutu прошли отдельные проверки на обеих машинах. Количество доступных инструментов совпало с ожидаемым, а там, где одной выдачи списка было недостаточно, мы добавили минимальную безопасную проверку авторизации.

Почему второй компьютер оказался отдельным этапом

Сначала кажется, что достаточно скопировать AGENTS.md и настройки. Но две машины редко бывают полностью одинаковыми.

На второй машине обнаружились:

• другая версия Codex CLI;
• собственное состояние OAuth;
• отличающиеся пути к Node.js;
• подключения, которые на первой машине были выключены, а на второй всё ещё запускались;
• старый адрес MCP;
• различия в локальных файлах доступа.

Поэтому «синхронизировали файлы» и «получили одинаковое рабочее поведение» — разные утверждения.

Мы сравнили контрольные суммы глобальных инструкций и четырёх тематических файлов. Затем отдельно проверили версии среды, статусы MCP, права файлов, зашифрованные профили и свежий запуск Codex.

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

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

Какие варианты мы сознательно отклонили

По ходу работы было несколько решений, которые выглядели быстрыми, но создавали больше риска.

Мы не стали:

• переписывать рабочий AGENTS.md до исходных замеров;
• повышать лимит загрузки инструкций без доказанной необходимости;
• считать любой интернет-разбор официальной рекомендацией;
• переносить OAuth в общее хранилище секретов;
• экспортировать ключи глобально;
• отзывать действующие доступы без признаков компрометации;
• оставлять несколько сломанных маршрутов рядом с одним рабочим;
• считать успешный запуск на одном компьютере доказательством для второго;
• публиковать локальные пути, аккаунты, ответы поставщиков и внутреннюю инфраструктуру;
• объявлять задачу завершённой до свежего запуска после всех изменений.

Это, пожалуй, и есть главный смысл всей работы. Контроль сохраняется не за счёт одного особенно строгого запрета. Он складывается из множества небольших проверяемых решений.

Универсальная последовательность миграции

Если свести наш опыт к короткой схеме, получится так:

1. Снять исходное состояние: размер, контрольные суммы, версии, настройки и рабочие маршруты.
2. Разделить официальные источники, собственные наблюдения и гипотезы.
3. Сформировать пакет работы с границами, критериями готовности и точкой остановки.
4. Прогнать проверки поведения на исходной версии.
5. Собрать короткое ядро и тематические инструкции.
6. Прогнать те же проверки на новой версии.
7. Получить независимую проверку решений.
8. Сделать резервную копию и внедрять изменения небольшими участками.
9. Проверить секреты только по именам и области действия, не раскрывая значения.
10. Для каждого сервиса выбрать один рабочий маршрут подключения.
11. Повторить весь проход на каждой машине.
12. Запустить новый чистый процесс Codex и проверить ошибки запуска.
13. Сохранить частные технические доказательства отдельно от материалов, пригодных для публикации.

В этой последовательности нет ничего особенно эффектного. Она просто не позволяет перепутать уверенность с доказательством.

Что я понял про более самостоятельные модели

До этой задачи мне казалось, что более сильной модели нужны более подробные инструкции.

Теперь я думаю наоборот.

Чем самостоятельнее модель, тем меньше ей нужен огромный текст со всеми подробностями жизни компании. Ей нужен короткий и непротиворечивый договор:

• чего мы хотим добиться;
• где источник правды;
• что можно менять;
• что нельзя трогать;
• чем доказать результат;
• где остановиться;
• как вернуться назад.

А специализированные знания должны подключаться по необходимости.

Иными словами, автономность нельзя компенсировать длиной промпта. Её нужно уравновешивать архитектурой среды: ясными правилами, минимальными правами, проверками, журналом решений и точками человеческого контроля.

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

GPT-5.6 Sol действительно может действовать самостоятельнее. Но самостоятельность агента становится полезной только тогда, когда человек точно спроектировал пространство этой самостоятельности.

Не нужно держать агента на коротком поводке.

Нужно построить ему хороший коридор.

Источники и материалы

• Рекомендации OpenAI по работе с GPT-5.6
• Официальная документация Codex по MCP
• Держите памятку агента свежей
• GPT-5.6 Sol без выжженных лимитов

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

По теме

• Статья: Как я собрал личную Codex-станцию: новый MacBook, Mac mini и два iPhone
• Блог: GPT-5.6 и Codex: главное из Reddit-AMA с командой OpenAI
• База знаний: AGENTS.md / SESSION_NOTES — проектная память для coding-агентов

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov