Платформа агентов

«ЯКомпания» разрабатывает платформу, в которой работу выполняют специализированные ИИ-агенты. Один готовит коммерческое предложение и документы закупки, другой развёртывает кластеры и разбирает ошибки, агенты разработки получают задачи и меняют код. У каждого есть своя область ответственности, рабочие инструменты и способ проверить результат.

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

Платформа и её продукты создаются «ЯКомпанией». Представление продукта другой компанией на выступлении или совместном мероприятии не меняет его авторства.

Какие задачи решают агенты

Агент или компонент	Область работы	Результат
ipresale	Закупки и подготовка коммерческих предложений	Разбор требований, расчёт, заполненные формы, комплект подачи и список незакрытых вопросов
idevops	Инфраструктура и эксплуатация	Развёрнутые кластеры и приложения, диагностика ошибок, инфраструктурные изменения, задачи на исправление кода
Агенты разработки; описание направления — icode	Разработка и исправления в репозитории продукта	Изменения кода, проверки и результат, связанный с исходной задачей
iomp на базе roboomp и omp	Приём задач и организация их исполнения агентами	Разбор issue, комментарий с выводами или pull request с исправлением

iomp — исполнительный контур для задач разработки. Он не заменяет предметную специализацию агентов. ipresale знает процесс закупки, idevops — инфраструктуру; каждому нужны собственные инструкции, данные и доступы.

Из чего состоит агент

• Правила работы. Порядок действий, требования к результату и условия остановки сохраняются в репозитории. Уточнение процесса должно использоваться и в следующей задаче.
• Контекст. Документы закупки, профиль компании, код приложения, конфигурации или сведения об инциденте — в зависимости от задачи.
• Инструменты. Команды, API, сборщики документов, средства развёртывания и проверки. Через них агент выполняет работу.
• Состояние. Что уже выполнено, где находится результат, какая проверка прошла и что мешает продолжению. В разных процессах это файлы состояния, задачи и история изменений.
• Проверки. Расчёт сверяется с формой, комплект — с планом подачи, изменение кода — с поведением приложения, инфраструктурная операция — с состоянием системы.

Модель выбирает действия и разбирает содержание. Повторяемые операции выполняют инструменты: скачивают файлы, считают суммы, заполняют ячейки, запускают проверки. Поэтому смена формулировки ответа модели не должна менять реквизиты компании или арифметику расчёта.

Как работа передаётся между агентами

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

Один из действующих маршрутов — от ошибки приложения к задаче разработки:

Мониторинг инфраструктуры idevops
  → alert-relay
  → issue в репозитории затронутого продукта
  → GitHub webhook в iomp
  → roboomp запускает агента на omp
  → разбор причины, комментарий или pull request

Задача создаётся в репозитории продукта, а событие поступает в iomp. В неё передаются описание сигнала и сведения для поиска причины. Повторное срабатывание того же алерта дополняет открытое issue, вместо создания новой задачи каждую минуту. Сырые строки логов не переносятся в issue: они могут содержать персональные данные и токены.

Агент разработки работает с описанием задачи и кодом. Если ему не хватает диагностических данных или прав, это ограничение нужно устранить; наличие задачи само по себе не даёт доступа к инфраструктуре. Комментарий «сигнал исчез» также не доказывает, что причина устранена.

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

Что получает человек

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

Незавершённая работа обозначается явно: отсутствуют данные, не прошла проверка, нет доступа или требуется решение. Ответ модели «готово» не заменяет эти сведения.

Где проходит граница автоматизации

Права и степень самостоятельности задаются для конкретного агента и контура. Подготовка документов не даёт права отправить оферту; созданный pull request не означает, что изменение уже выпущено; возможность прочитать код не даёт права менять продуктивный кластер.

Языковая модель может ошибаться, внешний сервис — быть недоступным, а формат документа или API — измениться. Для каждого процесса нужны проверяемый результат и понятный порядок передачи нерешённой задачи человеку. Квоты и ограничения провайдера модели также могут остановить исполнение.

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

Как оценивать результат

Эффект измеряется по выполненной работе, включая проверку и исправления:

Направление	Что измерять
Подготовка предложения	Время до проверенного комплекта, объём ручных правок, пропущенные требования, незакрытые документы
Разработка	Время до принятого изменения, прохождение критериев задачи, регрессии и повторные открытия
Эксплуатация	Время до диагностики и восстановления, повторные инциденты, ошибочные действия
Передача задач	Потерянные обращения, дубли, время ожидания, задачи без результата или ответственного

Сравниваются сопоставимые задачи и одинаковые критерии приёмки. Количество агентов, файлов или вызовов модели описывает устройство системы, но не доказывает экономию времени и рост качества.