Редакция pimenov.ai на Codex app-server: архитектура собственного агентного приложения

Недавно я написал, что Codex превращается из отдельного инструмента в платформу, которую можно встраивать прямо в рабочие продукты. Следующий вопрос оказался гораздо интереснее: что именно я мог бы построить на этой платформе для себя?

Мой первый кандидат — собственная «Редакция pimenov.ai». Не ещё один чат с искусственным интеллектом и не новая CMS, а операторское приложение, которое ведёт материал от исходной идеи и исследования до проверенного черновика в Notion. Публикация на сайте и отправка в Telegram остаются отдельными действиями, которые требуют моего подтверждения.

Что здесь вообще даёт Codex app-server

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

Codex app-server предоставляет готовый агентный контур. Приложение может создавать и продолжать треды, запускать отдельные ходы работы, получать поток событий и выводить человеку запросы подтверждений. При этом интерфейс, бизнес-объекты, доступные инструменты и границы действий определяет наше приложение.

Проще говоря, Codex становится двигателем, а мы строим вокруг него машину под конкретный процесс. Для редакции двигателю не нужно знать, как выглядит весь pimenov.ai. Он получает понятную задачу, нужные источники, разрешённые инструменты и условия остановки.

Главный объект — не чат, а материал

Сейчас рабочая история материала разнесена между исходным чатом, инструкциями, исследованием, файлами, скиллом, Notion и публикационными системами. В приложении всё это объединяется в один Material Case — редакционный кейс с постоянным идентификатором и понятным состоянием.

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

Такой объект не заменяет Notion. Notion остаётся источником живых редакционных инструкций и местом, где появляется готовый черновик. Material Case нужен приложению, чтобы видеть весь путь до этой страницы и не путать подготовку текста с фактом публикации.

Один материал — несколько изолированных тредов

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

Приложение связывает эти треды через Material Case и передаёт следующему этапу только нужный результат. Исследователь не получает права писать в Notion. Автор не меняет правила публикации. Проверяющий не исправляет текст молча, а возвращает список замечаний. Тред записи получает уже проверенный пакет и всё равно останавливается перед внешним изменением.

Получается простая машина состояний: intake → research → draft → QA → assembly → approval → Notion draft. Публикацию и мониторинг разумно добавлять позже, потому что там выше цена ошибки и больше внешних систем.

Что увидит человек в приложении

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

• «Сегодня» — материалы, которые требуют внимания;
• «Входящие» — новые идеи, ссылки, голосовые и файлы;
• «Материалы» — все редакционные кейсы и их состояния;
• рабочая карточка материала — источники, текст, QA, визуалы и история;
• «Подтверждения» — действия, которые Codex не имеет права выполнять самостоятельно.

Подтверждение должно быть частью архитектуры

Самая важная часть здесь — не красивый интерфейс, а границы полномочий. Прочитать инструкции, собрать источники, проверить дубли и подготовить пакет агент может сам. Создать страницу в Notion, опубликовать материал, отправить сообщение или изменить данные — только после явного решения человека.

App-server поддерживает запросы подтверждений для команд, файловых изменений, разрешений и действий инструментов с внешними последствиями. Но сам факт поддержки не делает процесс безопасным. Наше приложение должно привязать каждое подтверждение к конкретному Material Case, показать точное действие и сохранить результат проверки после выполнения.

Что уже можно переиспользовать

Самое приятное в этой схеме: редакцию не нужно строить заново. У меня уже есть живые инструкции в Notion, скилл создания материалов, Publisher, проверки метаданных и существующий путь до сайта. В приложении они становятся инструментами и правилами, а не переписываются в новую монолитную систему.

Каким должен быть первый MVP

Первую версию я бы сознательно ограничил подготовкой одного материала до черновика в Notion. Без автоматической публикации, Telegram и сложного мониторинга. Такой MVP уже отвечает на главный вопрос: делает ли отдельное приложение редакционную работу быстрее и понятнее, чем обычный чат с тем же скиллом.

1. Создать Material Case из разговора, ссылки или файла.
2. Запустить отдельные треды исследования, текста и QA.
3. Показать полный кандидат, источники, метаданные и визуалы.
4. Запросить одно точное подтверждение на создание черновика.
5. После записи перечитать страницу и показать проверяемый результат.

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

Работает ли это на подписке ChatGPT

Для внутреннего приложения есть важный практический вариант: app-server поддерживает управляемую авторизацию через ChatGPT, а также отдельный режим с API key; документация позволяет приложению прочитать доступный тип плана и состояние лимитов. Это значит, что локальный операторский MVP можно проектировать вокруг существующей авторизации Codex, не начиная с отдельного API-биллинга.

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

Что это может дать клиентам

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

App-server здесь становится техническим ядром, но ценность создаёт сама рабочая система: человек видит состояние задачи, агент получает только нужные полномочия, каждое внешнее действие подтверждается, а результат можно проверить. Именно в таком виде собственное агентное приложение отличается от очередной кнопки «спросить ИИ».

Источники

• OpenAI: Codex as a platform
• Codex app-server — как встроить полноценного агента в своё приложение
• Codex становится платформой: агент должен жить там, где уже идёт работа

Следующий шаг

Сначала прочитайте, почему Codex становится платформой и зачем переносить агента внутрь существующей работы.

Связанные материалы

• Как я научил Codex превращать любой рабочий чат в готовую статью
• Codex научился переписываться между чатами
• Codex App — единый справочник по среде от OpenAI

Если вы хотите спроектировать собственный агентный процесс, начните не с интерфейса, а с одного объекта работы, его состояний и точек человеческого решения.

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