«Агентный ИИ» в 2026 году звучит в каждом втором питче: модель сама вызывает инструменты, планирует шаги, «делает работу за оператора». Часть сценариев уже даёт измеримую пользу. Другая часть — красивое демо, которое нельзя пускать к деньгам, оборудованию или античиту. Разница почти всегда в одном: есть ли у агента право менять мир без человека и как вы это право наблюдаете.

В OtherCode мы разделяем агентов в IDE (ускорение инженера) и агентов в продукте (часть UX заказчика). Правила разные. Ниже — рабочие сценарии, явные запреты и требования к observability, которые мы закладываем в проекты.

Что такое агент на практике (без маркетинга)

Агент — цикл:

1. Получить цель и контекст.
2. Решить: ответить сразу или вызвать tool (API, БД, поиск, очередь).
3. Получить результат tool.
4. Повторить до STOP или лимита шагов.
5. Вернуть итог + трассировку.

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

Связанный инженерный контекст: разработка с AI и продуктовые границы вайбкодинга в статье про вайбкодинг.

Агенты в IDE vs агенты в продукте

| | IDE / внутренние агенты | Продуктовые агенты | |--|-------------------------|-------------------| | Пользователь | Разработчик | Клиент / оператор | | Цена ошибки | Сломанная ветка, откат git | Деньги, данные, простой линии | | Контур | Dev-машина, staging | Prod API, квоты, аудит | | Критерий успеха | Зелёный CI, принятый MR | Метрики бизнеса + эскалация | | Секреты | Запрет prod-ключей | Строгий ACL, least privilege |

Путать эти контуры опасно: «агент хорошо чинит тесты локально» ≠ «агент может сам перепрошить контроллер».

Где агенты помогают OtherCode

Внутренние инструменты студии

• Разбор типовых логов GitLab job и черновик гипотезы «почему упал pipeline».
• Сбор changelog из списка MR по правилам шаблона.
• Помощь в миграции конфигов между стендами (с diff для человека).
• Черновики runbook по уже существующим ansible/helm-манифестам.

Агент предлагает; инженер применяет. Self-hosted инфраструктура и GitLab CI остаются источником истины: агент не получает права docker compose down на prod.

OCR / NLP пайплайны (URAP)

В URAP агентность проявляется осторожно:

• Маршрутизация документа — выбрать цепочку обработки (счёт / акт / паспорт изделия).
• Дозапрос инструмента — «перечитать зону», «сверить ИНН с справочником».
• Черновик комментария оператору при низкой уверенности.

Финальная запись в учётную систему — после порога уверенности или ручного подтверждения. Модель не «додумывает» критичные поля без флага. Базовый контур OCR описан в материале про распознавание документов.

Content Factory

Агентский цикл здесь ближе к редакции: research → draft → style check → SEO checklist. Каждый шаг — отдельный tool с лимитом. Публикация — отдельное право, часто только у человека или по жёсткому правилу заказчика.

Synapse Stream

Для потоковой платформы агенты уместны в support-контуре: разобрать аномалию метрик, предложить запрос к логам, набросать постмортем. В hot-path обработки потока агентов нет — там детерминизм и предсказуемый latency важнее «гибкости». См. Synapse Stream.

Diom (Flutter) и клиентские приложения

Клиент может содержать «умного помощника», но tools выполняются на backend: бронирование, изменение профиля, платежные намерения. Мобильное приложение не хранит ключи LLM и не получает универсальный shell. Агент на сервере работает под user-scoped токеном, не под сервисной УЗ с полными правами.

Где агенты запрещены (жёсткий список)

| Зона | Почему нельзя | |------|----------------| | Команды SCADA / уставки Galvatec, Typhoon (STM32) | Физический ущерб, безопасность персонала | | Автоматические платежи / списания | Fraud, необратимость, регуляторика | | Античит и санкции в играх / LBS | Обход правил = потеря доверия и экономики | | Массовое удаление данных | Один галлюцинированный tool-call | | Смена firewall / SSH / CI variables | Компрометация всего периметра | | Отправка сообщений клиентам без модерации | Юридический и репутационный риск |

Для промышленности агент максимум готовит рекомендацию инженеру на HMI: «похоже, датчик X вне диапазона». Нажатие «применить команду» — человек или аттестованный rule engine с whitelist.

Observability: без неё агент — лотерея

Минимальный набор, который мы требуем в продуктовых агентах:

1. Trace id на весь цикл рассуждения.
2. Список tool-call: имя, аргументы (с маскированием секретов), результат, длительность.
3. Лимиты: max steps, max tokens, timeout, circuit breaker на внешние API.
4. Идемпотентность опасных операций (ключ идемпотентности на стороне API).
5. Human escalation: UI «принять / отклонить / править» для классов действий.
6. Метрики: success rate, доля эскалаций, стоимость токенов на задачу, p95 latency.

Если после инцидента нельзя ответить «какой tool с какими аргументами вызвал агент в 14:03» — контур не готов к production.

Пример политики действий

read_*          → allow
draft_*         → allow + audit
write_low_risk  → allow if confidence > t OR human approve
write_high_risk → human approve only
payment_*, scada_*, firewall_* → deny (нет tool в whitelist)

Whitelist инструментов важнее «умного» системного промпта. Промпт агент может игнорировать; отсутствующего tool он не вызовет.

Архитектурный каркас коротко

[UI / IDE]
    ↓
[Agent Orchestrator] — план, лимиты, политика
    ↓
[Tool Gateway] — auth, ACL, rate limit, audit
    ↓
[Domain APIs] — URAP, Content Factory, CRM, ...
    ↓
[LLM Provider Adapter] — см. мультипровайдерность

Tool Gateway — то место, где живёт безопасность. LLM никогда не получает прямый доступ к SSH-бастиону self-hosted инфраструктуры или к Modbus-шине.

Роли в команде вокруг агентов

Внедрение ломается, когда «агентами занимается кто придёт». В OtherCode на продуктовый агентный контур назначаем явные роли:

| Роль | Ответственность | |------|-----------------| | Product owner политики | Какие цели агенту можно ставить в UX | | Владелец Tool Gateway | Whitelist, ACL, ревью манифеста tools | | Дежурный по качеству | Метрики эскалаций, стоимость, ложные действия | | Инженер фичи | Промпты, оркестратор, тесты с fixture |

Для IDE-агентов достаточно тимлида и общей политики секретов — отдельный «владелец Cursor» не нужен. Для URAP и Content Factory без владельца whitelist через три месяца агент обрастает опасными shortcuts «для удобства поддержки».

Сценарии «агент + очередь» vs «агент + синхронный чат»

В Content Factory и URAP длинные задачи идут через очередь: пользователь видит статус, агент (или оркестратор шагов) работает асинхронно, результат проходит валидацию. Синхронный чат оставляем для коротких подсказок оператору («что означает этот код ошибки»). Смешение режимов в одном UX путает: человек ждёт ответ 30 секунд, а пайплайн документа реально занимает минуты.

| Режим | Пример в OtherCode | Риск без контроля | |-------|--------------------|-------------------| | Sync chat | Подсказка в админке | Таймауты, частичный ответ | | Async job | Пакет OCR + NLP | Потеря идемпотентности | | Human-approve gate | Публикация контента | «Утечка» черновика наружу | | Scheduled agent | Ночной разбор метрик Synapse | Ложные алерты без порогов |

Тестирование агентов

Обычного unit-теста на промпт мало. Мы добавляем:

• fixture tool responses — подмена ответов API, чтобы проверить ветвления политики;
• хаос: tool недоступен, tool вернул 500, tool вернул противоречие;
• лимит шагов: агент обязан остановиться и эскалировать, а не крутиться;
• регрессия whitelist: новый tool не появляется в prod без review манифеста.

В GitLab CI такие тесты гоняются без реальных ключей LLM где возможно (recorded fixtures). Живые вызовы — в отдельном nightly job с квотой.

Команда разработки: агенты в IDE без смешения с prod

Инженерский агент в Cursor ускоряет рутину так же, как описано в практике скорости разработки с AI, но он не является продуктовым агентом. Разделение:

• отдельные API-ключи / корпоративные endpoint’ы для IDE;
• запрет монтировать prod kubeconfig и SSH к бастиону в среду агента;
• MR только из feature-ветки; агент не пушит в main;
• секреты self-hosted инфраструктуры — вне контекста чата.

Если агент «помогает написать GitLab job», человек обязан проверить, что job не печатает masked variables и не качает зависимости с недоверенного зеркала.

Flutter, веб и промышленность: три разные планки допуска

Diom (Flutter): продуктовый помощник может предлагать действия в UI («заполнить форму по прошлому заказу»), но изменение баланса, санкции и античит-подобные механики — вне whitelist. Клиент показывает intent; сервер исполняет под ACL пользователя.

Next.js-сайты студии и заказчиков: агентность чаще в CMS/редактуре (Content Factory), чем на публичной странице. Публичный чат-бот без RAG и модерации — источник галлюцинаций и юридических рисков; если делаем — только с retrieval по утверждённой базе и логом.

Galvatec / Typhoon: рекомендательный контур максимум. Любой write в OT — аттестация, стенд, двухфакторное подтверждение инженером. Агент, который «сам подкрутил уставку», в наших проектах не допускается архитектурно: tool просто отсутствует.

Типичные ошибки внедрения агентов

Агент с правами сервиса «как у админа». Удобно в демо, катастрофично в проде. Нужен user impersonation или узкий service account на tool.

Нет стоп-условия. Агент крутит цикл, пока не закончится бюджет. Всегда max steps + dollar budget.

Смешение IDE-агента и prod-ключей. Локальный Cursor/агент с .env от production — путь к утечке через промпт или логи плагина.

Оценка только по «вау» на счастливом сценарии. Нужны хаос-тесты: недоступный tool, частичный ответ, противоречивые данные.

Игнонирование стоимости. Агентный цикл легко делает 20 вызовов модели там, где хватило бы одного RAG-ответа.

Скрытый tool «выполнить произвольный SQL». Даже «для отладки» — дыра. Нужны параметризованные read-модели.

Отсутствие продуктового владельца политики. Если whitelist tools меняет любой разработчик без ревью — через месяц агент умеет слишком много.

Как внедрять по шагам

1. Начать с read-only агента (поиск, объяснение, черновик).
2. Добавить tools с идемпотентными и обратимыми действиями.
3. Включить approve для write.
4. Собрать метрики эскалаций за 2–4 недели.
5. Только потом расширять whitelist — и никогда до SCADA/платежей без отдельного контура и аттестации.
6. Вынести манифест tools в репозиторий: diff + review как у кода.
7. Настроить алерты: всплеск отказов tool, рост стоимости цикла, аномалия частоты approve.

Итог

AI-агенты перестали быть только демо: в IDE, внутренних тулах, URAP и Content Factory они ускоряют рутину. В OtherCode граница простая — агент предлагает и автоматизирует безопасное; человек или жёсткий whitelist закрывает опасное. Observability, Tool Gateway, раздельные ключи для IDE и prod важнее красивого системного промпта. Synapse Stream держит агентов вне hot-path; промышленные контроллеры — вне write-доступа модели.

Нужен агентный сценарий в продукте или правила для команды разработки — оставьте заявку, разберём whitelist действий и схему аудита под ваш домен.