AR AIRun / Blog

Как создать агента AIRun через Codex, Claude Code или OpenCode

Подготовьте агента AIRun в помощнике разработки через MCP: опишите задачу, проверьте граф и передайте черновик человеку для настройки прав и запуска.

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

Для такой работы подойдут Codex, Claude Code, OpenCode или другой MCP-клиент с поддержкой удалённого Streamable HTTP и Bearer-токена. Выбор клиента не меняет границу прав: подключение создания готовит черновики. Публикация, запуск, выдача доступов и согласование рабочих действий через него недоступны.

Подключите помощника к MCP создания

В своей установке AIRun откройте «Рабочее пространство → MCP-создание агентов» по пути /agents/mcp/. Выпустите отдельный ключ создания и скопируйте адрес сервера /mcp/create именно вашей установки. На этой странице находятся примеры подключения для разных клиентов; адрес демонстрационного стенда для работы компании использовать не нужно.

Токен сохраните в переменной среды AIRUN_MCP_TOKEN процесса помощника. Он показывается один раз. Настройте передачу токена по инструкции выбранного клиента; секрет не нужно вставлять в запрос к модели, YAML агента или общий файл проекта. Параметры подключения и доступность сервера проверьте до постановки задачи.

Формат настроек зависит от клиента и его версии. Для подключения используйте пример на странице AIRun и официальные инструкции: Codex, Claude Code, OpenCode.

Опишите результат и ограничения

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

Пример запроса:

Изучи airun_creation_guide и подготовь черновик агента для еженедельной сводки по выбранным проектам. Сначала уточни источники, период и состав отчёта. Агент должен только читать данные, отмечать недоступные источники и отделять показатели от объяснений модели. Проверь YAML через airun_validate_agent, сохрани черновик и верни ссылку для проверки в AIRun. Не публикуй, не запускай и не назначай права.

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

Помощник собирает YAML и граф

Первый вызов – airun_creation_guide. Он возвращает актуальный шаблон, правила графа, действующие ограничения и публичные названия доступных профилей модели. Благодаря этому помощник опирается на формат конкретной установки, а не на пример из старой переписки.

YAML описывает конфигурацию агента: инструкцию, объявленные инструменты, начальный узел и переходы между шагами. AIRun поддерживает узлы обращения к модели, вызова инструмента, агентного выполнения, согласования и завершения. Узел завершения сам по себе не делает новый запрос к модели. Для агентного шага задаются доступные инструменты и предел действий.

Это подготовка поддерживаемого графа, а не автоматическая конвертация любого кода. Если у вас уже есть скрипт, помощник может разобрать его алгоритм и предложить подходящие шаги. Произвольный Python, JavaScript или команда оболочки не становятся исполняемым агентом только потому, что их текст передали через MCP. Для отдельной операции может потребоваться заранее подключённый API или инструмент.

Проверьте и сохраните черновик

airun_validate_agent проверяет YAML без сохранения: структуру графа, типы узлов, переходы и объявления инструментов. Успешная проверка ещё не подтверждает, что корпоративный источник доступен, права выданы, а ответ модели полезен. Эти проверки выполняются отдельно.

После исправлений airun_create_agent создаёт карточку с версией в статусе pending – на проверку человеку. Помощник возвращает review_url, по которому её можно открыть в AIRun. Для создания используется request_id: повтор той же операции с тем же идентификатором не должен создавать вторую карточку.

До принятия версии помощник может читать и дорабатывать собственный черновик через инструменты этого ключа. Обновление создаёт следующую pending-версию. Ключ ограничен созданными им карточками; он не получает доступ к другим агентам, запускам или настройкам, даже если его владелец – администратор.

Решение о рабочем запуске принимает человек

В AIRun проверьте назначение агента, инструкцию, граф и список инструментов. Выберите модель, настройте бюджет и лимиты, выдайте реальные права на системы через AIGate/MCP. Объявление инструмента в YAML и регистрация карточки в AIGate сами по себе таких прав не выдают.

Затем уполномоченный человек принимает версию и выполняет необходимые действия допуска через обычный интерфейс. Созданная MCP-версия до этого не является текущей и опубликованной. После принятия карточки человеком ключ создания больше не может читать или изменять её версии. Рабочий запуск остаётся отдельным действием.

Весь путь выглядит так:

  1. Описание задачи в помощнике разработки.
  2. Правила MCP, YAML и проверка графа.
  3. Черновик pending и ссылка на проверку в AIRun.
  4. Выбор модели, настройка прав, бюджета и лимитов человеком.
  5. Принятие версии и отдельный первый запуск.
  6. Проверка ответа и истории действий на тестовых задачах.

Начните с ручного запуска и сопоставьте ответ с источниками. Расписание или запуск по событию добавляйте после успешной проверки процесса. Что измерять перед расширением, разобрано в статье о пилоте AIRun, а разделение исполнения и контроля – в материале об AIRun и AIGate.

Share this article

Telegram ВКонтакте