Как пересобрать около 50 агентов после выхода GPT-5.6

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

Это не миграция.

Модель - только один элемент рабочего контура. Если не пересмотреть задачу, reasoning, инструменты, scope и проверку, компания просто перенесет старые решения на новую систему.

Что считается агентом

Внутри компании агентом может быть:

• сохраненная инструкция в ChatGPT Project;
• специализированный GPT;
• Work workflow;
• Codex task package;
• API-процесс;
• автоматизация с несколькими моделями;
• редакционный или исследовательский шаблон.

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

Шаг 1. Зафиксировать бизнес-задачу

Не «анализирует встречу», а:

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

Не «пишет код», а:

Вносит ограниченное изменение в существующий проект, сохраняет protected functionality и подтверждает результат тестами.

Модель выбирается под бизнес-работу, а не под название агента.

Шаг 2. Определить рабочую поверхность

Для каждого процесса нужно решить:

• Chat;
• Work;
• Codex;
• Deep Research;
• API;
• Scheduled Task;
• комбинация нескольких поверхностей.

Старый агент мог существовать в Chat только потому, что других режимов не было. Теперь многоэтапный документ логичнее перенести в Work, а инженерную задачу - в Codex.

Шаг 3. Зафиксировать текущую конфигурацию

До изменения сохранить:

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

Без baseline нельзя понять, улучшилась ли система.

Шаг 4. Найти устаревшие инструкции

Старые промты часто содержат компенсирующие формулировки.

«Думай максимально глубоко»

Может приводить к лишнему reasoning на каждой задаче.

«Проанализируй абсолютно все»

Расширяет scope и увеличивает контекст.

«Не задавай вопросов и обязательно выполни»

Опасно для критичных процессов, если данных не хватает.

«Пошагово покажи все рассуждения»

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

«Используй самую сильную модель»

Закрепляет дорогой дефолт вместо маршрутизации.

Шаг 5. Переписать scope

Новая инструкция должна содержать:

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

Для Codex особенно важны:

• protected functionality;
• запрет destructive operations;
• запрет миграций без отдельного плана;
• обязательные тесты;
• список измененных файлов.

Шаг 6. Выбрать модель по классу работы

Luna

• классификация;
• извлечение;
• нормализация;
• короткие преобразования;
• массовые ясные операции.

Terra

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

Sol

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

GPT-5.5

• временно сохраняется в проверенных процессах до приемочного сравнения.

Шаг 7. Настроить reasoning

Reasoning должен быть не частью имени агента, а политикой.

Пример:

• Low - чистые данные и четкая схема;
• Medium - основной режим;
• High - противоречия, неизвестная причина, высокая цена ошибки;
• Extra High/Pro - архитектура, миграции и критичные решения;
• Max/Ultra - только по отдельному основанию.

Нужно также определить сигнал повышения.

Например:

Если модель не может однозначно атрибутировать решение или находит противоречия между источниками, повторить на Sol High.

Шаг 8. Ввести критерии приемки

Критерий зависит от класса работы.

Встреча

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

Исследование

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

Код

• изменен только разрешенный scope;
• тесты проходят;
• добавлен regression test;
• перечислены измененные файлы;
• указано, что не проверено.

Документ

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

Шаг 9. Разделить создание и проверку

Критичный агент не должен сам быть единственным судьей своего результата.

Варианты:

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

Для кода полезно разделять разработчика и тестера. Для встреч - извлечение и проверку атрибуции. Для исследований - сбор источников и редакторскую проверку.

Шаг 10. Определить fallback

Fallback должен отвечать на вопросы:

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

Плохой fallback:

Если не получилось, попробуй еще раз.

Рабочий fallback:

Если Terra Medium не проходит критерии полноты, проверить, связана ли ошибка с отсутствием данных. При достаточных данных повторить на Sol Medium. High включать только при противоречиях или неявной причинной связи.

Шаг 11. Сохранить обратимость

Каждая миграция должна иметь:

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

Без этого невозможно отличить улучшение от случайного изменения поведения.

Карточка миграции

Порядок миграции десятков агентов

Не начинать с самых критичных.

Рациональный порядок:

1. частые некритичные задачи;
2. массовые извлечения и классификации;
3. типовые документы;
4. стандартные coding-задачи;
5. сложные исследования;
6. клиентские и финансовые документы;
7. архитектура, доступы и данные.

Почему так:

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

Что не нужно менять одновременно

Если одновременно изменить модель, reasoning, весь промт и рабочую поверхность, невозможно понять причину результата.

Лучше:

1. сохранить baseline;
2. заменить модель на том же effort;
3. проверить;
4. снизить reasoning;
5. затем обновить инструкцию;
6. после этого менять поверхность, если нужно.

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

Реестр миграции

Для каждого агента нужна карточка:

• владелец;
• бизнес-задача и аудитория;
• текущая поверхность и модель;
• reasoning;
• входные данные;
• instructions и knowledge;
• tools и права;
• approval boundaries;
• completion criteria;
• baseline и golden examples;
• regression tests;
• текущая стоимость и latency;
• fallback и версия для отката.

Без владельца агент становится бесхозной зависимостью. Без baseline невозможно доказать улучшение. Без rollback любая миграция превращается в необратимый эксперимент.

Приоритеты P0-P3

P0 - процессы, влияющие на production, клиентов, финансы, юридические документы и доступы.

P1 - регулярные операционные процессы с высокой стоимостью ручной ошибки.

P2 - внутренние исследования, документы и контент, которые проходят человеческую проверку.

P3 - экспериментальные и низкорисковые сценарии.

Миграцию лучше начинать с P2-P3, где можно быстро собрать ошибки и настроить общий стандарт, а затем переносить P1 и P0.

Feature flags и поэтапный rollout

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

Рабочая схема:

1. feature flag на новую модель;
2. небольшой процент задач;
3. параллельное сравнение со старой конфигурацией;
4. проверка качества, времени и стоимости;
5. расширение только после прохождения порогов;
6. автоматический или ручной rollback при регрессии.

Golden examples и regression suite

Для каждого класса агентов нужны реальные примеры:

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

Проверять стоит не только «нравится ли ответ», но и конкретные метрики: полноту, точность, format adherence, unsupported claims, число лишних вопросов, latency, расход и долю результатов, принятых без ручной переделки.

Маршрутизация Sol, Terra, Luna и GPT-5.5

• Luna - ясные повторяемые операции с жестким форматом.
• Terra - основной кандидат для повседневной работы, ранее выполнявшейся GPT-5.5.
• Sol - сложные, неоднозначные и дорогие по ошибке задачи.
• GPT-5.5 - временный fallback там, где новая конфигурация еще не прошла regression suite.

Нельзя назначать семейство моделей по названию агента. Выбор делается по форме задачи и измеряемому quality-cost frontier.

Внутренний стандарт v1

Каждый агент обязан иметь:

1. бизнес-задачу;
2. владельца;
3. поверхность;
4. модель;
5. reasoning;
6. входные данные;
7. формат выхода;
8. разрешенные инструменты;
9. scope;
10. out of scope;
11. критерии приемки;
12. обязательные проверки;
13. fallback;
14. правила ручного подтверждения;
15. историю версий.

Что меняем после этой статьи

1. Создаем закрытый реестр всех агентов.
2. Не раскрываем публично внутренние промты и архитектуру.
3. Мигрируем по классам риска, а не одним переключателем.
4. Убираем избыточные требования «думать максимально глубоко».
5. Для каждого агента задаем сигнал повышения reasoning.
6. Разделяем создание и проверку критичных результатов.
7. Сохраняем версию для отката.

Итог серии

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

Нужно выбирать не «самую умную модель», а конфигурацию под задачу:

поверхность -> модель -> reasoning -> инструменты -> проверка -> fallback.

Только тогда новая модель становится усилением системы, а не еще одним источником непредсказуемости и расхода.

Навигация по серии

• Предыдущая статья: Как теперь ставить задачи GPT-5.6: меньше микроменеджмента, больше результата и границ
• Страница всей серии

FAQ

С чего начать миграцию?

С реестра агентов, владельцев, бизнес-задач и baseline. Без этого невозможно понять охват и проверить регрессии.

Нужно ли переписать все промты?

Нет. Сначала определить prompt debt: дубли, устаревшие ссылки на модели, blanket rules и то, что следует перенести в параметры или инфраструктуру.

Как снизить риск?

Использовать приоритеты P0-P3, feature flags, staged rollout, golden tests, monitoring и готовый rollback на прежнюю конфигурацию.

Источники и границы выводов

Материал подготовлен по состоянию на 10 июля 2026 года. Функции, доступность и лимиты OpenAI могут меняться. Перед операционным решением стоит проверять актуальную документацию.

• GPT-5.6: Frontier intelligence that scales with your ambition
• GPT-5.6 in ChatGPT
• OpenAI model guidance
• OpenAI prompt guidance
• Reasoning models
• Codex models
• Codex rate card
• Projects in ChatGPT
• Deep research in ChatGPT
• Scheduled Tasks in ChatGPT

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