Субагенты Codex: как проверить готовность продуктового запуска
Раздели проверку запуска между субагентами Codex: потребности клиентов, риски и метрики. Готовые данные, промпт и критерии проверки.
Перед запуском функции продакт сверяет потребности пользователей, ограничения команды и способ измерить результат. Эти проверки можно поручить разным субагентам Codex, а затем собрать один список решений. Разберём это на учебном запуске уведомлений о статусе заявки. Программировать не потребуется: работаем с текстовыми заметками.
Субагент — отдельный помощник внутри задачи. В актуальных версиях Codex функция доступна по умолчанию, но делегирование нужно прямо запросить или предусмотреть в инструкциях проекта. Каждый помощник расходует токены; три параллельные проверки не означают тройную экономию. Эти особенности описаны в документации Codex.
1. Собери небольшой пакет исходных данных
Открой локальный проект в Codex и создай отдельную задачу. Для первого упражнения достаточно вставить следующий текст в сообщение. Все данные вымышлены и предназначены для обучения.
Учебный продукт: сервис согласования заявок на закупку.
План: отправлять уведомление при смене статуса заявки.
Пилот: 20 компаний, две недели. Дата старта пока не назначена.
Интервью:
I1. Закупщик: «Я трижды в день открываю заявку, чтобы узнать статус».
I2. Руководитель: «Мне достаточно сводки утром, каждое изменение мешает».
I3. Администратор: «Уволенные сотрудники не должны получать письма».
Ограничения:
C1. В первой версии доступна только электронная почта.
C2. Настройки частоты уведомлений ещё не спроектированы.
C3. Поддержка может обработать не больше пяти обращений в день.
Аналитика:
M1. Есть события открытия заявки и изменения статуса.
M2. Нет событий отправки, доставки и отключения уведомлений.
M3. Базовое число ручных проверок статуса пока неизвестно.Идентификаторы I1, C2 и M3 нужны для проверки выводов. В рабочем проекте замени учебный пакет согласованными документами и укажи их даты. Если данные расходятся, попроси отметить противоречие до анализа.
2. Дай каждому помощнику отдельный вопрос
Попроси Codex выполнить три независимые проверки. Это пример редакционной постановки задачи, а не встроенные роли продукта:
Используй трёх субагентов для анализа учебного запуска выше.
1. Первый проверяет соответствие сценария потребностям I1–I3.
2. Второй проверяет операционные риски с учётом C1–C3.
3. Третий проверяет возможность измерить эффект с учётом M1–M3.
Каждому передай полный исходный пакет. Пусть вернёт максимум
три вывода в формате: проблема → ссылка на ID → что выяснить
или подготовить → критерий готовности. Факты отделяй от гипотез.
Ничего не изменяй в файлах и не отправляй внешним сервисам.
Дождись всех трёх результатов. Затем собери общую таблицу:
вопрос, основание, следующий шаг, кто должен принять решение.
Не придумывай ответственных по именам, даты и целевые значения.В активности основной задачи открой ветки помощников и проверь, что вопросы действительно разделены. В CLI для просмотра веток используется /subagents. Если делегирование недоступно, попроси прямо сообщить об этом: три раздела в одном ответе сами по себе не доказывают запуск трёх агентов.
3. Сверь выводы с исходными заметками
Ожидается не готовый вердикт «можно запускать», а список вопросов к пилоту. Например, из I1 и I2 следует конфликт желаемой частоты: немедленное письмо может помочь одному сегменту и раздражать другой. Какой вариант выбрать — решение команды.
| Основание | Полезный следующий шаг | Чего нельзя заключать |
|---|---|---|
| I2 + C2 | Уточнить потребность в утренней сводке и правило частоты | Все пользователи хотят дайджест |
| I3 | Проверить, как обновляется список получателей | Доступ уже отзывается автоматически |
| M1–M3 | Собрать базовый уровень проверок и добавить нужные события | Уведомления уже сократили ручную работу |
Проверь каждый пункт по ID. Если помощник предлагает порог успеха, попроси пометить его как предложение, а не исходное условие. Несколько агентов могут повторить одну и ту же ошибку: согласие между ними не заменяет источник.
4. Собери один список решений
Вернись в основную ветку и отправь уточнение:
Убери повторы. Для каждого спорного вывода покажи исходный ID.
Раздели итог на «выяснить до пилота» и «наблюдать во время пилота».
В первой группе оставь максимум пять пунктов. Для каждого
сформулируй вопрос команде и проверяемый результат обсуждения.
Не объявляй запуск готовым, пока эти вопросы не закрыты.Хороший итог можно перенести на короткую встречу: какое правило частоты выбираем, как исключаем бывших сотрудников, какие события нужны и кто подтвердит готовность поддержки. После встречи допиши реальные решения и заново проверь только изменившиеся части.
5. Реши, стоит ли повторять такой формат
Моя рекомендация: начинать с чтения и анализа документов. Если несколько помощников одновременно переписывают один план, сложнее понять, чья версия актуальна. Один исполнитель, собирающий итог после независимых проверок, обычно проще в управлении.
Для короткого вопроса без независимых частей хватит одного агента. Для повторяющейся процедуры можно оформить критерии в skill Codex, а качество итогов сравнить через небольшую проверку на примерах. Построение таких рабочих процессов разбираем на курсе по ИИ-агентам.
Документация сверена 21 октября 2026 года. Пример и таблица — учебные; реальный прогон трёх субагентов в рамках подготовки статьи не выполнялся.
Собери своего ИИ-агента и проверь результат
«AI Agents: от vibe coding к AI-команде»: desktop agents, MCP, skills, evals и harness. Отдельные воркшопы — от подключения инструментов до контроля качества.
7 практических воркшопов · записи · вопросы автору в чате
Посмотреть программу курса ↗