Внутренняя платформа агентов

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

Зачем платформа

Общий вывод материалов OpenAI о harness engineering: результат агента определяет не только модель, но и среда вокруг неё — инструкции, инструменты, проверки, окружения. И если агент ошибается, правильная реакция — дополнить среду, а не уговаривать агента (OpenAI). Отсюда смысл платформы: каждое такое дополнение должно попадать в общий слой и работать для всех проектов, а не оставаться в ноутбуке одного разработчика.

Подробно дисциплина разобрана в курсе «Harness engineering». Здесь — организационный взгляд: что входит в платформу и кто ею владеет.

Слои платформы

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

Способы встроить Codex

Если платформа включает собственные инструменты — бота в трекере, сервис ревью, внутренний портал, — их нужно на чём-то строить. Варианты на октябрь 2026 года, по материалам OpenAI:

• codex exec — неинтерактивный запуск для скриптов и CI: структурированный вывод, понятный код выхода. Для большинства задач автоматизации этого достаточно (non-interactive mode).
• Codex SDK (TypeScript и Python) — программное управление локальным Codex из своих сервисов.
• App Server — двунаправленный JSON-RPC-протокол, на котором работают богатые клиенты, в том числе расширение для IDE. Даёт полный набор возможностей обвязки: треды, одобрения, диффы, события. Статья OpenAI называет его рекомендуемым способом глубокой интеграции (OpenAI).
• Agents API — с сентября 2026 года в публичной бете: облачные агенты на обвязке Codex, которой полностью управляет OpenAI; окружение — песочница OpenAI, своя инфраструктура или партнёрские платформы (OpenAI).

Выбор упрощается так: CI и скрипты — codex exec; свой сервис, где агент работает рядом с вашим кодом, — SDK или App Server; облачные агенты без своей инфраструктуры — Agents API. Помните про ограничение из урока о доступе: текущие облачные окружения Codex не поддерживают GitLab (GitLab-интеграция ревью живёт в старом режиме Codex Cloud), поэтому агентству с GitLab основную автоматизацию придётся строить в своём CI.

Что взять из Symphony

Symphony — открытая спецификация оркестрации от OpenAI (OpenAI, GitHub). Идеи, полезные даже без самой реализации:

• Трекер задач как пульт управления. Каждой открытой задаче — своё рабочее пространство с агентом, статусы задачи служат машиной состояний. Для агентства на Kaiten это переносимая мысль: агент берёт карточку, работает в отдельной копии проекта и переводит карточку в статус «на ревью человеку».
• Рабочий процесс записан в репозитории. У Symphony это WORKFLOW.md: настройки опроса трекера, хуки рабочего пространства, лимит параллельных агентов, шаблон промпта. Неписаный процесс команды становится файлом.
• Секреты не в контейнере. Агенты получают доступ к трекеру через инструмент, а токен трекера в их окружение не попадает.
• Успех — это передача человеку. Успешный прогон может заканчиваться статусом вроде «Human Review», а не «Done».
• Не всё подходит. Авторы признают, что неоднозначные задачи, требующие суждения, остаются интерактивными, а агенты плохо работают как жёсткие узлы машины состояний — им лучше давать цели.

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

Порядок строительства

Рекомендация документации, которая хорошо масштабируется на платформу: не ставьте задачу на расписание, пока она не работает надёжно вручную (best practices). Отсюда порядок:

1. Политика и доступы — общая для всех, раньше всего остального.
2. Знания и навыки — шаблон AGENTS.md и три-пять общих навыков для самых частых задач агентства.
3. Инструменты — один-два MCP-сервера, которые убирают повторяющийся ручной цикл. Документация советует начинать именно так.
4. Окружения — воспроизводимый запуск каждого проекта одной командой. Без этого агент не может проверить себя.
5. Автоматизация — ревью MR и разбор упавшего CI на пилотных проектах.
6. Оценка — свои evals на реальных задачах, чтобы менять модели и настройки не вслепую.
7. Оркестрация — только когда предыдущие слои зрелые.

Как управлять платформой

• Владелец. У платформы должен быть владелец с выделенным временем, даже если это часть ставки одного сеньора.
• Версии. Фиксируйте версии Codex и моделей в CI и обновляйте осознанно: новые возможности конфигурации, например профили прав, требуют свежих клиентов.
• Пересмотр с каждой моделью. Обвязку стоит пересматривать при смене модели: то, что компенсировало слабость старой модели, может мешать новой.
• Обратная связь. Повторяющаяся ошибка агента в любом проекте — заявка на доработку платформы.

Дорожная карта внедрения harness engineering целиком — в уроке «Дорожная карта».