Я собрал армию агентов в Codex. Самым сложным оказалось управление
- Codex
- AI-агенты
- автоматизация
- инженерный менеджмент
- мультиагентные системы
В августе 2026 года я не пытался изобрести AI-организацию. Я пытался закончить историю, которая началась со сна, записанного мной четырнадцать лет назад. После партии в Dungeons & Dragons я снова о нём вспомнил, открыл Codex и начал разбирать старые заметки и обрывки текста.
Этот хобби-проект превратился в иллюстрированную повесть, зафиксированный протокол рецензирования и издательский пайплайн. На следующей неделе я применил тот же метод к разработке и начал переносить в Codex свой рабочий процесс для SDK.
Я не могу показать внутренности SDK, но могу показать pet-проекты, на которых освоил этот подход. Дело не в одной гениальной модели. Дело в том, чтобы несовершенные модели создавали работу, которую можно проверить, отклонить и продолжить, не удерживая всю систему в голове. Я называю это своей армией агентов, но на практике это операционная модель из ограниченных ролей, независимой приёмки, сохраняемых доказательств, бюджетов и человеческой ответственности.
До приложения Codex: я вручную связывал терминалы
Я уже активно использовал Claude Code в терминале вместе с Codex CLI. Они видели репозиторий, запускали инструменты и вносили настоящие изменения. Проблемой была координация: у Claude был один контекст, у Codex — другой, а планирование жило где-то ещё. Если я хотел, чтобы одна модель поспорила с другой, информацию между ними переносил я сам.
Я даже написал инструмент, который восстанавливал контексты терминальных сессий и пересылал между ними ответы. Он работал, но шиной сообщений, планировщиком, системой разрешений и монитором сбоев всё равно оставался я.
В августе 2026 года я обнаружил, что приложение Codex может держать долгие задачи, файлы, инструменты, субагентов и видимые передачи работы в одном рабочем пространстве. Я задал роли, навыки, память репозитория и правила. В процессе по-прежнему могли участвовать разные модели, но ряду терминальных окон больше не приходилось изображать организацию.
Раздельные контексты Claude Code и Codex CLI, соединённые моими скриптами и вручную перенесёнными результатами.
Codex объединил диалог, файлы, инструменты, роли и совместную работу агентов в одном месте.
Свежие контексты задач, специализированные роли, память в репозитории, отдельная проверка и явные барьеры перед релизом.
Инструменты изменились. Но важнее то, что координация переместилась из моей головы в явные границы, которые можно проверить.
Главным изменением стал не интерфейс. Координация смогла стать частью самого проекта.
Книга стала моей первой лабораторией
Я не начал с команды агенту «напиши книгу». Я принёс в Codex старые заметки и огромный объём неопределённости. Мы разобрали мир, мотивацию персонажей, недостающие сцены и то, что история должна дать почувствовать читателю. Репозиторий стал общей памятью: рукопись, лор, решения, визуальный канон, состояние производства и Git-история, связывающая доказательства с конкретной версией.
Когда появился первый полный текст, я перестал задавать самый бесполезный вопрос в творческой работе: Тебе нравится?
Вместо этого я создал изолированных читателей с разными задачами: целевой читатель, коммерческий редактор, критик целостности, защитник неоднозначности, враждебный, но справедливый скептик и более узкие специалисты. Каждый получал чистую рукопись и только одну роль — без чужих отчётов и без информации об изменении, которое, как мне хотелось, он должен был похвалить.
Я прогнал зафиксированный протокол через GPT и Claude. Более ранние аудиты DeepSeek и Mistral остались в отдельном контуре доказательств и не превратились в дополнительные голоса того же бенчмарка. Я хотел понять, обнаружат ли изолированные семейства моделей один и тот же механизм сбоя.
Одна красноречивая критика — это мнение; несколько прогонов внутри одного семейства моделей дают коррелированные свидетельства. Когда разные семейства находят один и тот же причинный пробел, который я могу проверить, аргумент становится сильнее — но не превращается в доказательство простым большинством голосов.
Мы зафиксировали промпты и структуру оценки, чтобы новая версия не могла «улучшиться» лишь потому, что я сделал тест мягче. До изменения рукописи мы записывали предполагаемый механизм проблемы, вмешательство, ожидаемый эффект, качества, которые нельзя потерять, и условие отката.
Процесс дал 290-страничную сборку для рецензирования с повестью, иллюстрациями и производственными материалами. Автоматические проверки прошли, но релизный барьер не был пройден: у нескольких изображений отсутствовали явные подтверждения соответствия канону. PDF выглядел законченным, а зафиксированное состояние говорило обратное — и я не стал его игнорировать. Теперь эти изображения зафиксированы, но всё ещё нужен новый полный прогон книги.
Этот провал научил меня большему, чем мог бы научить радостный статус «пройдено».
Затем я попробовал тот же метод в разработке
Вторым pet-проектом оказалась игра, но суть не в игре. Мне нужен был испытательный стенд, где агенты должны менять реальную кодовую базу, запускать тяжёлый движок, проверять поведение и визуальный результат и справляться с несовершенной инфраструктурой.
Концепт-арт программного испытательного стенда и его будущего главного героя. Эти изображения задают визуальную цель, но не доказывают, что текущая сборка уже её достигла.
В первой попытке один способный агент интерпретировал задачу, проектировал, реализовывал, тестировал и оценивал функцию. Это было быстро, но плохо спроектировано: «собирается» незаметно превращалось в «работает», затем в «стало лучше» и наконец в «готово». Это четыре разных утверждения.
Я разделил роли: менеджер фиксировал результат, исполнитель менял код, оператор собирал доказательства, QA искал поведенческие сбои, а визуальный и релизный рецензенты оценивали итог. Создателю больше не разрешалось принимать собственную работу.
Такая структура поймала ошибки, которые проверки кода в этой итерации пропустили. Исходники собирались, автоматическая проверка поведения проходила, файлы захвата существовали, а QA принял технический пакет. Но арт-рецензент открыл изображения и отклонил их: одно было почти чёрным, важная функция не попала ни в один кадр, а главный персонаж был неразличим в масштабе скриншота.
Реализация достигла своей узкой технической цели. Продуктовый результат оказался неприемлемым. Оба утверждения были верны.
Эксперимент также разрушил мою первую фантазию о параллельности. На Mac с 16 ГБ памяти несколько агентских сессий и запущенных ими инструментов встретились с Unity, менеджером пакетов и процессом лицензирования. Давление на память выросло, и компьютер завис.
Решением стал не более сильный промпт, а планировщик: один тяжёлый пишущий процесс за раз, никаких новых агентов во время работы Unity, отдельные worktree для действительно независимых исполнителей, дешёвые проверки до запуска движка и жёсткий лимит попыток реализации.
Больше агентов не означает больше автономности автоматически. Надёжный прогресс внутри реальных ограничений — означает.
Этот паттерн перенёсся в мою настоящую работу
В моём production SDK уже были контексты для отдельных ролей, навыки, соглашения и раздельные зоны ответственности. На второй неделе я начал переносить этот процесс в Codex. О частных результатах пока рано заявлять как об успехе, но структура ролей и доказательств переносилась между творческой, движковой и профессиональной работой — и часто выявляла провал вместо того, чтобы искусственно выдавать успех.
Переиспользуемой единицей оказался не «агент-писатель» или «агент Unity». Ею стал организационный паттерн вокруг них.
Смысл, рамки, вкус, необратимые решения
Направляет одну ограниченную задачу и контролирует бюджет
Исследователь · Автор · Инженер
Получает отдельную задачу и пытается опровергнуть готовность
Решения, артефакты, манифесты, тесты, передачи
Создание и приёмка — разные задачи. Репозиторий хранит доказательства, а владелец получает решения, а не сырой операционный шум.
Владелец определяет смысл и границы. Оркестратор создаёт ограниченный устав задачи. Специалисты производят артефакты; отдельный рецензент пытается опровергнуть завершённость; репозиторий хранит доказательства. Владелец возвращается ради компромиссов, релизов, смены направления или когда работа остановилась либо вошла в противоречие.
Именно проектированием этого слоя я теперь занимаюсь большую часть времени.
Как на самом деле выглядит автономность
Я не провожу весь день, наблюдая за агентами. По будням утром, до начала рабочего дня, я фиксирую ограниченные задачи для книги и программного испытательного стенда, а затем оставляю эти личные очереди работать без присмотра пять–семь часов. Когда начинается профессиональная работа, я переключаю контекст и активно использую агентов для своих обычных инженерных обязанностей. Репозитории, очереди задач и циклы ревью остаются разделёнными.
После работы я проверяю, что произвела смена личных проектов: артефакты, тесты, отклонённые утверждения и пакеты решений вместо потока чата. Вечером я использую небольшие задачи для быстрой обратной связи, корректирую роли или процесс, а перед сном выдаю длинные задания, способные работать до утра.
Продукты важны, но сейчас они ещё и инструменты. Мой главный эксперимент — метод разработки почти чего угодно таким способом: как долго задача может безопасно выполняться, где ломается автономность, какие доказательства переживают ночь и какое вмешательство улучшает следующую смену. В течение одного календарного дня личные очереди могут продолжать расходовать вычисления, пока я активно использую отдельных агентов в профессиональных задачах. Это параллельные вычисления, а не параллельное внимание — поэтому расход токенов совсем не похож на ситуацию, когда один агент отвечает на один вопрос.
Менее формальное описание: сейчас я живу на дофамине. Постоянный видимый прогресс удивительным образом мешает заснуть, даже когда смысл системы именно в том, что она способна продолжать работу без меня.
С чего я бы начал
Если сейчас вы переключаетесь между несколькими AI-чатами и вручную переносите выводы, не начинайте с создания двенадцати агентов.
Начните с одного болезненного рабочего процесса и трёх ролей:
- Менеджер — фиксирует один результат, не-цели, критерии приёмки и бюджет.
- Создатель — производит минимальное целостное изменение или артефакт.
- Рецензент — проверяет результат в отдельном контексте и не может незаметно его исправить.
Храните цель, решения и доказательства в репозитории. Требуйте артефакт, а не убедительный отчёт о статусе; заставьте рецензента ссылаться на то, что он проверил; завершайте работу после одного результата.
Добавляйте новую роль, только если можете назвать конфликт, узкое место или недостающую экспертизу, которые она устранит.
Ролям нужны контракты, а не костюмы
Во многих мультиагентных демо действуют блестящие разработчики и дотошные тестировщики. Характер может сделать промпт приятнее. Ответственности он не создаёт.
Операционной роли нужны пять вещей:
- Определённый вход. Что должно существовать до начала работы этой роли?
- Ограниченный выход. Какой артефакт или вердикт она должна вернуть?
- Явные полномочия. Какие инструменты, файлы и решения ей разрешено затрагивать?
- Запрещённые действия. Что она обязана передать другому, даже если знает, как это сделать?
- Условие остановки. Когда задача выполнена, отклонена, заблокирована или требует человека?
«Ты внимательный QA-инженер» слабее, чем «у тебя доступ только для чтения, ты не можешь исправлять найденное, обязан сопоставить каждый сбой с зафиксированными критериями и можешь вернуть только ACCEPT, REJECT или NEEDS_OWNER_DECISION».
Не все границы одинаково сильны. Где возможно, я использую разрешения файловой системы, worktree, белые списки инструментов и блокировки ресурсов — блокировка Unity должна принадлежать планировщику, а не вежливому промпту. Письменные инструкции слабее и не могут разрешить релиз без барьера из доказательств или решения человека.
Модель имеет значение только после того, как задача правильно сформирована. Архитектуру и финальное ревью я могу направить передовой модели, исследование — более быстрой, детерминированную работу — более дешёвой, а состязательное ревью — другому семейству моделей. Роли должны переживать такие замены. Я часто хочу, чтобы Claude оспорил план, созданный в Codex; я не хочу, чтобы оппонент редактировал реализацию, которую оценивает.
Контекст нужно собирать, а не накапливать
Один бесконечный разговор со временем помнит слишком много: устаревшие требования, сырые логи, отброшенные гипотезы и уверенные резюме версий, которых больше нет.
Теперь я предпочитаю свежие контексты выполнения, собранные из устойчивых слоёв.
Хороший промпт роли — не биография. Это последний слой над устойчивым контекстом проекта и узким контрактом задачи.
Репозиторий — это институциональная память; разговор — интерфейс к ней.
Для каждого проекта я храню цель, журнал решений, текущую итерацию, критерии приёмки, не-цели, каталог доказательств и краткую финальную передачу контекста.
Свежая задача читает то, что нужно для одного результата, записывает доказательства обратно и завершается. Стратегические разговоры остаются полезными, потому что операционный мусор в них не попадает. Это менее удобно, чем один гигантский контекст, но гораздо проще для аудита.
Счёт научил меня, что на самом деле означает параллельность
В тот момент я платил около $100 в месяц за Claude, а начинал работу с Codex примерно через подписку ChatGPT за $20. Затем я перешёл на вариант примерно за $100 и исчерпал недельный лимит примерно за два дня после подключения разработки и работы с SDK. Следующий показанный мне вариант обновления стоил около €200; я сохраняю записанные валюты, а не делаю вид, будто их можно чисто сравнить.
Это дневник использования за август 2026 года, а не сравнение тарифов. Планы и лимиты меняются, а я запускал долгие процессы с высоким уровнем рассуждения в нескольких проектах. К концу второй недели бюджеты обоих сервисов ненадолго закончились.
Полезный вывод проще:
«Параллельность — это политика расходов».
Запуск пяти рецензентов с высоким уровнем рассуждения — бюджетное решение. Модель, глубина рассуждения, число агентов, повторные попытки и время жизни задачи должны входить в контракт рабочего процесса.
Мои практические правила теперь выглядят так:
- Одна задача — один результат. Завершив одну итерацию, задача не начинает следующую исподтишка.
- Отделяйте создание от приёмки. Никто не проверяет собственную домашнюю работу.
- Сначала дешёвое доказательство. Используйте статические проверки или одного сфокусированного рецензента до дорогих сборок, широких панелей и визуальных ревью.
- У доказательств есть происхождение. Результат проверки относится к конкретной версии исходников, команде, существенным параметрам среды и конфигурации и неизменяемому артефакту.
- Полномочия и бюджет ограничены. Рецензенты остаются в режиме чтения; модель, время работы, повторы и попытки ограничены; необратимые решения возвращаются владельцу.
- Сбой останавливает цикл. «Не доказано» и противоречивые вердикты возвращаются владельцу, а не запускают незаметно новую попытку.
- Меняйте по одной переменной процесса. Если одновременно изменились маршрут и модель, не притворяйтесь, что результат показывает, что именно помогло.
Цель не в том, чтобы экономить каждый токен. Цель — тратить дорогое рассуждение там, где оно меняет решение.
Поэтому я заставил эту статью проверить саму себя
Публиковать статью о надёжных агентских процессах и не применить этот метод к самой статье казалось абсурдом. Поэтому зафиксированный снимок получили четыре роли — холодный читатель, выпускающий редактор, фактчекер и практик — один раз в GPT и один раз в Claude. Все восемь внутренних отчётов вернулись с вердиктом revise.
Консенсус, риски и вкусовые оценки разделены
Изменить, сохранить, проверить или отклонить
Восемь прочтений — не восемь независимых источников. Совпадение выводов разных семейств моделей повышает приоритет замечания, но не заменяет проверку и авторское решение.
Оба семейства оспорили одни и те же преувеличения и разошлись во мнениях о заголовке и о том, какую часть этого раздела оставить. Закрытые отчёты не доказывают, что статья хороша; они выявили утверждения, которые я мог проверить. Пайплайн не мог ни редактировать, ни публиковать, поэтому решения — и ответственность — остались за мной.
Что остаётся человеку
Я не передавал на аутсорс смысл книги, выбор существенной критики, неоднозначности, которые нужно сохранить, продуктовое направление или ответственность за SDK. Агенты способны проверять, реализовывать, тестировать и спорить; они не могут принять на себя ответственность. Роль человека поднимается уровнем выше, но не исчезает.
Моя работа всё больше заключается в проектировании организации: решить, где живёт контекст, разделить конфликтующие полномочия, определить доказательства и бюджеты и вмешаться, когда система доходит до настоящего решения.
Промпт-инжиниринг может улучшить один ответ. Организационный дизайн может сделать полезными месяцы несовершенных ответов.
Я начал с четырнадцатилетнего сна и самодельного ретранслятора между окнами терминала. Через две недели один и тот же организационный паттерн двигал вперёд книгу, программный эксперимент и часть моего профессионального процесса — и мне не требовалось наблюдать за каждым шагом.
Модели, интерфейсы, планы и лимиты будут меняться. Устойчивый навык — превращать интеллект в организацию, способную сказать вам, когда она ошибается.
Дальше я планирую опубликовать конкретные шаблоны этой системы: контракты ролей, уставы задач, пакеты доказательств и правила, по которым я решаю, какой модели достанется какая работа.