Когда нам понадобилось подключить к Orpheus ещё одну систему компании, агент примерно за 20 минут подготовил короткий скилл, Python-скрипт для командной строки и спецификацию API. Этот небольшой эпизод хорошо показывает, как изменился мой подход к корпоративным агентам: всё большую часть общего устройства агента можно взять готовой.
Что раньше приходилось собирать самостоятельно
Ещё годом ранее обычный путь к агенту начинался с фреймворка. Команда строила архитектуру, распределяла контекст, выделяла подагентов и описывала передачу управления между ними. Затем эту систему приходилось отлаживать и поддерживать. Мой «Экзоскелет» для e-commerce-челленджа тоже был устроен подобным образом.
К сентябрю 2026 года я видел два параллельных изменения: модели стали сильнее, а вокруг них выросли готовые агентские движки. В исходном посте я перечислял Codex, Claude, pi, OpenCode и Hermes. Это перечень примеров на тот момент, без сравнительного теста их возможностей.
Под движком, или harness, здесь я понимаю готовую систему, которая организует работу модели с контекстом и инструментами. Развивать такую систему целиком собственными силами становится дороже относительно альтернативы: взять существующую основу и добавить сведения о компании. Для Orpheus мы выбрали именно этот путь.
Что готовый движок даёт корпоративному агенту
В популярные агентские системы вкладываются разработчики поставщиков и сообществ. Они исправляют ошибки, добавляют возможности и развивают общую механику работы. Когда мы используем такой движок, эти изменения могут становиться основой и для нашего агента. При собственной реализации поддерживать общую механику приходится команде продукта.
Но готовая система изначально ничего не знает о наших правилах. Ей нужно объяснить, где искать задачу, как устроена работа с обращением, когда оформлять MR и какие действия требуют участия человека. Нужны инструменты для доступа к данным и инструкции по их применению.
В Orpheus этот подход проявился вполне предметно: агент изучает код, логи, историю коммитов, задачи и релизы. Ценность для поддержки появляется из сочетания возможностей движка и доступа к сведениям, которые нужны для конкретного обращения. Отдельная инструкция без этих источников оставила бы значительную часть работы человеку.
Как выглядело подключение ещё одной системы
В день публикации исходного поста я попросил создать скилл для работы с очередной системой: изучить её API и предложить способ подключения. Примерно через 20 минут у меня было три связанных элемента. Ко времени публикации подключение уже использовалось в продакшене.
| Элемент | Что получилось в нашем случае | Его назначение |
|---|---|---|
| Скилл | Короткая инструкция примерно на полстраницы | Объяснить агенту, как работать с системой |
| CLI | Небольшой Python-скрипт | Выполнять обращения к API из командной строки |
| Спецификация | Файл openapi.json | Дать описание доступных операций и параметров |
По спецификации агент может искать нужные сведения с помощью rg и jq. Необязательно заранее превращать каждую операцию API в отдельный инструмент со своим описанием в агентской системе. В нашем случае небольшой интерфейс командной строки и доступная спецификация оказались достаточными для подключения.
Двадцать минут — время подготовки инструментов для одного подключения. Срок для другой системы будет зависеть от устройства API, доступов и требуемого сценария. В этом эпизоде полезен прежде всего состав решения: короткая инструкция, небольшой инструмент и спецификация вместо отдельного слоя обвязки для каждой операции.
В скилле остаются правила конкретной работы
API описывает, какие операции технически возможны. Для рабочего процесса этого мало. Агенту ещё нужно понимать, в какой ситуации искать данные, как связаны объекты и какой результат требуется от поручения. Эту часть удобно хранить в скилле рядом с инструментом.
Наш более ранний опыт в разработке дал похожий результат. Мы добавили инструменты и скиллы для Redmine и GitLab: агент стал оформлять MR, проверять состояние CI и вести задачу по принятому порядку. Об этом я писал в посте о переходе команды на работу с AI.
Для развития такого подключения полезно разделять причины ошибок. Если команда выполняется неверно, нужно разбираться с инструментом. Если агент выбирает неподходящий момент или неверно понимает результат, стоит уточнить инструкцию и контекст. Это инженерный способ локализовать проблему; сам по себе формат скилла качественного поведения не гарантирует.
Окружение проекта всё ещё требует внимания
У слова harness есть и более широкий смысл: рабочее окружение, в котором агент решает задачи. В посте о разработке я относил сюда быстрое развёртывание, линтеры, статический анализ, автотесты и правила в AGENTS.md. Выбор готового движка эту работу с репозиторием не отменяет.
Если проект трудно запустить, агенту тоже придётся разбираться с окружением. Если команда не умеет автоматически обнаруживать типовые ошибки, качество результата будет сложнее оценить. Мы вкладывались в такую инфраструктуру до распространения агентов, и это помогло перейти к совместной работе быстрее.
Оказалось, что меняется и привычка разработчика. Нужно давать агенту задачу, разбирать неудачный результат и выяснять, каких данных или инструментов ему не хватило. Постепенно улучшаются инструкции и окружение. Покупка доступа к сильной модели покрывает только часть этого перехода.
Когда собственная архитектура остаётся оправданной
В исходном посте я оставил фреймворкам и собственной логике место в узких задачах с большим потоком запусков. Если варианты действий заранее понятны, ошибки дорого обходятся, а стоимость каждого выполнения имеет значение, можно подробно описать переходы и оптимизировать сценарий под более дешёвую модель.
Это моя инженерная оценка на сентябрь 2026 года. Она требует расчёта для конкретной нагрузки: сколько стоит запуск, как часто он повторяется и сколько времени команда тратит на сопровождение. Узкая архитектура тоже потребует обновлений, проверки изменений и исправления сбоев.
Для корпоративного агента с разными задачами я бы начинал с готового движка, одной подключённой системы и нескольких реальных сценариев. Затем добавлял бы инструменты и скиллы по мере появления задач. В Orpheus этот подход позволил сосредоточить разработку на данных и процессах компании, а очередное подключение оформить короткой инструкцией, CLI и спецификацией API.
Материал может пригодиться коллегам? Отправьте им ссылку на статью.