К книге
Главное про AIГлава 7. От чата к AI-агентам и мультиагентным средам
38%
Глава 7. От чата к AI-агентам и мультиагентным средам
8

Продавец корпоративного AI-сервиса показывал на демо «агента», который «бронирует переговорку на завтра для встречи с клиентом». Агент — а на деле это был чат-бот с памятью диалога — выдавал в ответ гладкий абзац: «Я забронировал вам переговорку номер 3 на 14:00, встреча с ООО Ромашка, приглашение отправлено Ивану Петровичу». Менеджер открывал календарь — пусто. Переспрашивал: «Какие инструменты ты вызвал?» Агент не терялся и генерировал правдоподобный JSON-объект вызова функции, которой у него не было. Выглядел как агент, говорил как агент, отчитывался как агент — и не действовал. Менеджер закрыл демо и больше не возвращался к этому вендору.

В эпизоде сконцентрированы три сюжета, на которых строится вся глава: чат, мимикрирующий под агента; LLM, галлюцинирующий вызов инструмента; и провал различения «модель рассуждает» и «система действует». Продавец обещал инфраструктуру действий, а показал генератор красивых отчётов. Разные виды одного и того же провала.

Разница между чатом и агентом — не в пользовательском интерфейсе и не в длине контекстного окна. Разница в том, что у чата нет средств действовать, а у агента они есть: память состояния, инструменты и многошаговое планирование. У каждого из этих средств — конкретная цена в токенах, задержке и риске ошибки. И не каждое «AI-решение», которое продавец называет агентом, содержит все три.

AI-агент — это модель плюс средства для действий. Модель даёт рассуждение, средства — возможность действовать. Anthropic в декабре 2024 года напомнила индустрии ключевое: если задача решается проще, агентскую систему строить не нужно. К этому тезису мы вернёмся в разделах про выбор архитектуры и платформы.

ПРИРОДА AI-АГЕНТА: ОПРЕДЕЛЕНИЕ ПО СУЩЕСТВУ

В декабре 2024 года инженерная команда Anthropic (Эрик С. (Erik S.) и Барри Чжан (Barry Zhang)) опубликовала текст «Building Effective Agents», и за полгода он стал одним из самых цитируемых в индустрии определений того, чем агент отличается от цепочки вызовов LLM. Их центральное различение: все варианты попадают в зонтик «агентские системы», но внутри него проходит архитектурная граница между workflow и agent. Workflow — это системы, в которых модель и инструменты оркестрируются через предопределённые пути в коде, то есть разработчик заранее прописал, что и в каком порядке происходит. Agent — это системы, в которых модель сама динамически направляет свои процессы и использование инструментов, удерживая контроль над тем, как задача будет выполнена. Anthropic добавляет: «Agentic-системы обменивают задержку и стоимость на лучшее качество выполнения задачи. Workflows — для чётко определённых задач, где важны предсказуемость и консистентность. Agents — там, где гибкость и решения, принимаемые моделью, нужны в масштабе».

Здесь проходит практический водораздел: workflow дешевле и стабильнее, агент гибче и опаснее.

16 октября 2025 года та же команда Anthropic (Барри Чжан (Barry Zhang), Кит Лазука (Keith Lazuka), Махеш Мураг (Mahesh Murag)) выпустила материал «Equipping agents for the real world with Agent Skills». В нём формализуется то, что интуитивно делает агента специалистом, а не болтуном. Agent Skills — это организованные папки инструкций, скриптов и ресурсов, которые агент обнаруживает и динамически загружает, чтобы лучше справляться с конкретными задачами. Skills превращают агента общего назначения в специализированного — без переписывания модели.

Ключевой инсайт — трёхуровневая модель прогрессивного раскрытия, по аналогии с хорошо организованным руководством пользователя. На уровне 1 в системный промпт заранее загружаются только поля name и description из YAML-фронтматтера — агенту известно, какие навыки у него есть, но не их содержимое. На уровне 2, когда агент решает, что навык релевантен, он подгружает полное тело SKILL.md. На уровне 3 сам переходит к дополнительным файлам (reference.md, forms.md) по мере необходимости. Anthropic подчёркивает: «Агенты с инструментами файловой системы и исполнения кода не нуждаются в том, чтобы читать навык целиком в контекст. Значит, объём контекста, упакованного в навык, фактически неограничен».

В декабре 2025 года Agent Skills опубликованы как открытый стандарт на agentskills.io для кросс-платформенной переносимости. Похожая логика работает и в обратную сторону внутри агента: навыки, загруженные в контекст все сразу, съедают бюджет окна без пользы. Прогрессивное раскрытие снимает эту проблему. На том же принципе построено постепенное обнаружение в MCP, к которому мы вернёмся ниже.

Из практического разбора архитектуры AI-агента на Хабре извлекается минимальная, но дисциплинирующая модель того, что вообще происходит в агенте, когда он «думает и действует». Цикл: сообщение поступает → собирается контекст → LLM выдаёт ответ → если в ответе есть вызов инструмента, он исполняется → результат возвращается в контекст → цикл повторяется. Это в маркетинге так называют «автономным сотрудником», а в коде — while True: think_and_act(). Правило группировки вызовов, которое держит архитектуру от хаоса: запросы только на чтение идут параллельно, всё, что меняет данные, — строго по очереди. Если агент дважды подряд вызывает read для одного и того же файла, второй вызов ждёт первый — иначе он может получить устаревшую версию и работать с ней.

23 января 2025 года OpenAI выпустила Operator — research preview агента, использующего собственный браузер для автономного выполнения задач. Operator запускался только для Pro-пользователей в США по адресу operator.chatgpt.com, а 17 июля 2025 года полностью интегрирован в ChatGPT как ChatGPT agent — теперь к нему можно добраться через пункт «agent mode» в выпадающем меню композитора. Стоит остановиться, потому что в одном продукте видны все три слагаемых из тезиса раздела: память состояния (Operator помнит, на каком шаге формы вы остановились, и возвращает управление в нужной точке), инструменты (виртуальный браузер с мышью и клавиатурой вместо API-интеграций), многошаговое планирование (открыть сайт, найти товар, заполнить корзину, подтвердить заказ, ввести данные карты — цепочка из 5–15 шагов).

Под капотом ChatGPT agent работает модель Computer-Using Agent (CUA): она соединяет GPT-4o vision с обучением с подкреплением для работы с графическими интерфейсами, видит страницу через скриншоты и возвращает управление пользователю, когда застревает. Безопасность держится на трёх слоях: takeover mode (агент просит пользователя ввести логин или платёжные данные и не скриншотит то, что введено), user confirmations перед существенными действиями (отправка заказа, отправка письма) и watch mode для чувствительных сайтов вроде почты и финансов. Партнёры запуска — DoorDash, Instacart, OpenTable, Priceline, StubHub, Thumbtack, Uber и муниципалитет Стоктона, Калифорния.

ЧАТ ПРОТИВ АГЕНТА: СЕМЬ КРИТЕРИЕВ РАЗЛИЧИЯ

Четыре риска не озвучиваются в продажах и съедают бюджет в рабочей эксплуатации. Непредсказуемость: агент может пойти неожиданным путём — у него есть выбор. Цепные ошибки: ошибка на шаге N усиливается на шаге N+1, маленький сбой в начале превращается в большой в конце. Стоимость: длинные цепочки — большие затраты на токены. У задачи из 15 шагов бюджет в десять раз больше, чем у одного вызова. Контроль: когда агент сделал не то, остаётся открытым вопрос «кто отвечает и как это заметить вовремя».

Здесь полезно представить себе агента через аналогию со стажёром, у которого есть доступ к инструментам, инструкциям и право на ошибку. Когда приходится объяснять эту разницу клиенту, который выбирает AI-инструмент для команды, я обычно говорю так: стажёр-человек учится два года, прежде чем ему доверяют сложные задачи. Агент учится за пять итераций на вашем eval-наборе, но доверять ему можно не больше, чем стажёру в первую неделю: он сделает 80% работы правильно, 15% с ошибками, которые вы заметите при приёмке, и 5% с ошибками, которые вы не заметите, пока клиент не пожалуется. Разница со стажёром — скорость. Агент делает за минуту то, что стажёр делает за день, но цена ошибки та же. Если стажёр ошибочно отправит досудебную претензию клиенту — скандал. Если агент ошибочно отправит — тот же скандал, плюс объяснения «это AI сделал», которые никто не хочет слышать.

Лицензия на ошибку — это «вы несёте ответственность за ошибки агента». Отговорка «это AI сделал» не работает.

Anthropic в 2024–2025 годах предостерегала от моды на агентов, когда каждую задачу пытались решить агентом. Для многих приложений достаточно оптимизировать одиночные вызовы LLM с поиском и in-context примерами, без агентской обвязки. Агент нужен там, где задача объективно требует многошаговости и динамического выбора инструментов. Иначе — преждевременное усложнение, которое ест бюджет, не давая выигрыша в качестве.

ЧАТ ИЛИ АГЕНТ: КРИТЕРИИ ВЫБОРА ИНСТРУМЕНТА

Anthropic даёт чёткий критерий: workflows — для чётко определённых задач, где важны предсказуемость и консистентность. Agents — там, где гибкость и решения, принимаемые моделью, нужны в масштабе. Если задача — «классифицировать входящее письмо по 5 категориям», вам нужен workflow: один запрос к LLM, один JSON-ответ, никакой динамики. Если задача — «обработать претензию клиента: понять, что он хочет, найти релевантный договор, оценить риски, составить ответ», вам нужен агент: разные претензии требуют разных шагов, и заранее прописать путь невозможно.

Практическое правило: если в задаче больше 2–3 шагов и шаги зависят от результата предыдущих — это кандидат на агента. Если шаги линейны и не зависят от контекста — workflow или просто цепочка LLM-вызовов. Если задача помещается в один хорошо сформулированный промпт — чат. Это не абсолют, а отправная точка: бывают задачи с 5 шагами, которые workflow решает стабильнее, чем агент (когда шаги заранее известны, а отклонения редки и обрабатываются по ветке «иначе — эскалация на человека»).

ПРИЗНАКИ ЗАДАЧИ, КОТОРОЙ НУЖЕН АГЕНТ, А НЕ ЧАТ

– Задача объективно многошаговая (больше 2–3 шагов).

– Шаги зависят от результата предыдущих (не «сначала A, потом B, потом C», а «после A решаем — B или D»).

– Нужны разные инструменты на разных шагах (поиск, отправка письма, обновление CRM, проверка статуса).

– Состояние между шагами нужно сохранять (на каком шаге формы остановились, какие данные уже собрали).

– Коррекция ошибок нужна на уровне задачи, а не на уровне одного ответа (если шаг 3 провалился, переделать шаги 2 и 3, а не переписывать весь промпт).

ПРИЗНАКИ ЗАДАЧИ, КОТОРОЙ ДОСТАТОЧНО ЧАТА ИЛИ WORKFLOW

– Один запрос — один ответ, без промежуточных шагов.

– Формат ответа фиксирован, и качество можно проверить автоматически.

– Нет внешних инструментов (только встроенная информация в модели).

– Нет необходимости в долгосрочном состоянии (сессия длится один запрос).

– Ошибка на любом «шаге» (если бы он был) — это просто плохой ответ, который пользователь переспросит.

ЧЕК-ЛИСТ: АГЕНТ ПЕРЕД ВАМИ ИЛИ ЦЕПОЧКА ВЫЗОВОВ

Прежде чем строить агента, спросите себя: можно ли задачу разложить в линейный конвейер, где шаги не зависят от контекста? Если да — это workflow, а не агент. Workflow проще, дешевле, стабильнее. Если нет — кандидат на агента, но сначала проверьте, что у вас есть инфраструктура для планирования и памяти. Агент без инфраструктуры — либо чат-бот, притворяющийся агентом, либо скрипт, который через неделю упадёт в продакшене.

Прежде чем называть чат-бот «агентом», спросите себя: есть ли у него инструменты, которые он реально вызывает, а не имитирует вызов в JSON? Сохраняет ли он состояние между сессиями? Может ли он сам перепланировать после неудачного шага? Три «нет» — это чат-бот, а не агент. Называть вещи своими именами — не только точность, это дисциплина мышления о своих инструментах.

AI-ПЛАТФОРМЫ: ПУТЬ ОТ ИНСТРУМЕНТА ДЕЙСТВИЯ К ПРОДУКТУ

В 2025–2026 годах сформировался рынок коробочных AI-платформ, превращающих средства для действий в готовый продукт. Salesforce Agentforce, Microsoft Copilot Studio, IBM watsonx Orchestrate, Google Gemini Enterprise, OpenAI ChatGPT agent — пять корпоративных платформ для глобального рынка, у каждой своя философия. Разница между ними — не в том, «какая модель лучше», а в том, как организованы инструменты, как управляется состояние, какие есть ограничения и кто платит за ошибку. Параллельно оформился второй эшелон — с открытым кодом и проприетарные «персональные» агенты для разработчиков и продвинутых пользователей. В 2026 году здесь выделяются три: Claude Code (Anthropic), OpenClaw и Hermes Agent (Nous Research).

На российском рынке параллельно развивается свой стек корпоративных платформ. На середину 2026 года в нём выделяются две заметные системы.

Yandex AI Studio (Yandex B2B Tech) — платформа с визуальным конструктором агентов на базе моделей YandexGPT и других, едиными API без необходимости разворачивать собственный инференс, поисковым компонентом с подтверждаемыми ответами и SaluteSpeech-интеграцией для голосовых сценариев.

GigaChat Enterprise (Сбер, представлен 3 марта 2026 года, разработчик «Салют для бизнеса», входит в группу Сбер) — корпоративная платформа на базе флагманской модели ГигаЧат Ультра с тремя конфигурациями поставки: локальная для крупнейших компаний и объектов КИИ, гибридная для среднего и крупного бизнеса в приватном облаке, облачная.

Разница с западным стеком — в фокусе, не в философии. Западные платформы опираются на глубокую интеграцию со своими экосистемами (CRM, Office, Workspace), российские — на развёртывание на собственных серверах компании и гибридные конфигурации под требования регуляторов и критической информационной инфраструктуры (КИИ).

Salesforce Agentforce (выпущен в сентябре 2024, обновлён до версии 2dx в июне 2025 и до версии 3 в июне 2025) — корпоративная инфраструктура агентского AI, глубоко встроенная в Salesforce Data Cloud и Customer 360. Агент Agentforce видит все данные о клиенте, которые есть в CRM, и действует от имени пользователя внутри экосистемы Salesforce. Команда Salesforce в июне 2025 выпустила Agentforce 3 с Command Center — центром управления, который показывает, какие агенты что делают, и позволяет вмешаться в реальном времени. Ценообразование переведено в понятную бизнесу метрику: «по количеству выполненных действий» (actions), а не по токенам или вызовам. Снимается риск «агент сожрал месячный бюджет за один день».

Microsoft Copilot Studio (обновлён Wave 2 весной 2025) — расширение экосистемы Microsoft 365, где агент Copilot получает доступ к Outlook, Teams, SharePoint, Excel, Power Platform и действует от имени пользователя в корпоративной среде. Сильная сторона — низкий порог входа для компаний, уже живущих в экосистеме Microsoft: сотрудник может собрать агента в визуальном конструкторе, не привлекая разработчиков. Microsoft в мае 2025 объявил о Microsoft 365 Copilot Wave 2 — Spring 2025, где Copilot получил более 200 новых агентов и фреймворк для создания собственных.

IBM watsonx Orchestrate (обновление на TechXchange 2025) — корпоративный фокус на отрасли: агент специализируется на конкретных бизнес-процессах (HR, закупки, финансы) и обучен на отраслевых данных IBM. Развёртывается на собственных серверах компании и интегрируется с mainframe-системами, что критично для банков и страховых компаний, не готовых отдавать данные в облако.

Google Gemini Enterprise (объявлен в апреле 2025 на Google Cloud Next, обновлён в августе 2025) — мультимодальный агент с длинным контекстом, опирающийся на Google Agentspace (единое пространство для агентов с доступом к корпоративным данным через поиск) и Gemini Enterprise (корпоративный чат-бот с агентскими возможностями). Особенность — глубокая интеграция с Google Workspace (Gmail, Drive, Docs) и фирменная мультимодальность: агент видит не только текст, но и картинки, видео, аудио в одном контексте.

OpenAI Operator (январь 2025) → ChatGPT agent (июль 2025) — агент, который действует через браузер и работает с любым веб-сайтом через визуальный интерфейс (computer use). Это снимает необходимость создавать API для каждого сервиса, в который вы хотите встроить агента, — достаточно, чтобы у сервиса был веб-интерфейс. Цена — каждый шаг оказывается дороже и медленнее, чем у API-агента: скриншот, действие, новый скриншот.

КОРПОРАТИВНЫЕ ПЛАТФОРМЫ: КРИТЕРИИ ВЫБОРА

CLAUDE CODE, OPENCLAW, HERMES AGENT: АГЕНТЫ ДЛЯ РАЗРАБОТЧИКОВ

Параллельно с корпоративными платформами в 2025–2026 годах оформился сегмент агентов, которые ставит себе на машину инженер, исследователь или продвинутый пользователь. Здесь три имени, определяющих ландшафт в 2026 году.

Claude Code (Anthropic) — агент для разработчиков и офисных пользователей с доступом к Claude API. Если claude.ai — это чат, Claude API — это конструктор, то Claude Code — готовый терминальный продукт, который «из коробки» даёт агенту руки: файлы, команды shell, git, MCP-серверы. Продукт появился в 2025 году как ответ на Cursor и Windsurf (IDE — интегрированные среды разработки со встроенным AI), и к маю 2026 года Anthropic существенно расширил его функциональность в сторону Skills (текстовые инструкции с прогрессивным раскрытием), Plugins (бандлы для дистрибуции) и MCP-маркетплейса.

Архитектурно это CLI-процесс: устанавливается через npm или официальный installer, авторизуется через Anthropic API ключ или подписку Pro/Max, работает в локальном терминале разработчика. Под капотом — модели семейства Claude 4.6 (Sonnet 4.6 для скорости, Opus 4.6 для сложных задач). Инструменты, которые агент использует из коробки: Read, Edit, Write, Bash, Grep, Glob. Расширения — Skills, Plugins, MCP-серверы, Subagents, Hooks, Agent Teams. Плагин-маркетплейс работает по команде /plugin install, и на момент мая 2026 года доступно более 425 plugins и 2810 skills от комьюнити плюс 28+ официальных plugins от Anthropic.

Отличие от корпоративных платформ — ориентация на индивидуального пользователя, а не на корпоративный workflow. Claude Code не приходит с готовыми коннекторами к Salesforce, ServiceNow или M365; он требует, чтобы пользователь сам настроил MCP-сервер или Skills под свои задачи. Это и его сила (лёгкий, настраивается под что угодно), и его слабость (корпоративному заказчику нужен корпоративный уровень готовых интеграций и поддержки). На май 2026 года Claude Code предлагается по подписке Free / Pro $20 / Max $100–200 в месяц, Team $25–150 за место и Enterprise по контракту, а API-тарифы Haiku, Sonnet и Opus идут отдельно от подписки по обычной сетке в $/M tokens. Скрытый расход: одна и та же квота расходуется и на claude.ai-чат, и на Claude Code, при активной работе с обоими лимит легко превысить.

OpenClaw — открытая AI-агент-платформа (открытый исходный код), ориентированная на «персонального AI-ассистента, который живёт на ваших устройствах». Если Claude Code — это «разработчик + Claude», то OpenClaw — «обычный пользователь + любая модель + 23 мессенджера».

Архитектурно OpenClaw строится прежде всего на локальной установке: один процесс-контроллер ставится на устройство пользователя (macOS, Linux, Windows, Raspberry Pi) и управляет сессиями, каналами, инструментами и событиями. На 3 июня 2026 года (релиз 2026.6.1) — 377 тысяч звёзд на GitHub, 197 релизов, 3,2 миллиона пользователей, 500+ тысяч запущенных инстансов. Архитектурная особенность — контроль над данными по умолчанию: данные остаются у пользователя, исходящий трафик — только HTTPS-запросы к API модели (никаких входящих портов), интеграция с инфраструктурой офисного firewall/VPN идёт «как есть». Это не позиция «сначала подключимся к облаку, а потом настроим приватность», а архитектурно приватная система, к которой опционально подключается облачная модель.

OpenClaw можно ставить на собственный сервер компании, и данные не покидают периметр — кроме текста запроса к API модели и ответа. Возможности, которые делают OpenClaw уникальным среди открытых альтернатив: более 20 каналов мессенджеров (включая WhatsApp, Telegram, Slack, Teams и Signal), голосовая активация и режим разговора на macOS, iOS и Android, режим визуального рабочего пространства («живой холст»), маршрутизация между несколькими агентами для изоляции разных каналов в разных рабочих пространствах. Поддержка моделей: пользователь приносит свои API-ключи (BYOK) и подключает Claude, GPT-5 (+ Codex), Gemini, DeepSeek, GitHub Copilot (для Enterprise), а через ClawRouters — автоматическая маршрутизация по сложности и цене (экономия 40–60% по заявлению вендора).

Риски, которые нужно знать. К апрелю 2026 в OpenClaw выявлено шесть серьёзных уязвимостей: критическая (оценка CVSS 8.8 из 10, «высокая опасность») позволяла удалённо выполнить код через вредоносный навык и исправлена в релизе 2026.1.29; остальные — инъекция команд и подделка серверных запросов, часть из них затрагивает слой MCP. CVE — публичный реестр уязвимостей, такие номера присваиваются каждой обнаруженной проблеме безопасности. Из 2 857 навыков на ClawHub 341 помечен как вредоносный (335 из них — одна кампания). Цифра значит одно: открытая экосистема — не только свобода, но и необходимость проверять, что именно вы ставите.

Hermes Agent (Nous Research) — долгоживущий обучаемый AI-агент с открытым исходным кодом. Если Claude Code — это «агент-инструмент для работы в IDE», а OpenClaw — «агент-ассистент для мессенджеров», то Hermes — «агент-сотрудник, который растёт вместе с вашим проектом». К 29 мая 2026 года (релиз v0.15.2): 181 тысяча звёзд на GitHub, 1322 контрибьютора, около 10 655 коммитов, MIT-лицензия. Python 84% плюс TypeScript 12%. Поддерживает macOS, Linux, Windows (native, без WSL2), WSL2, Termux (Android).

Архитектурная идея — замкнутый цикл обучения, в котором агент сам курирует свою память между сессиями. Четыре элемента цикла: (1) агент сам курирует свою память между сессиями с периодическими напоминаниями модели сохранить знание, (2) полнотекстовый поиск по прошлым сессиям (как поиск в поисковых системах, только по своим логам), (3) автономное создание навыков после сложных задач — агент сам превращает удачно решённый рабочий процесс в переиспользуемый навык, (4) улучшение навыков во время использования по мере повторения процедуры. Навыки построены на открытом стандарте agentskills.io и переносимы между платформами — это отличает Hermes от OpenClaw, где навыки живут в закрытом ClawHub, и от Claude Code, где навыки привязаны к экосистеме Anthropic.

Шесть терминальных бэкендов дают Hermes гибкость развёртывания: локально (прямое исполнение), Docker (контейнерная изоляция), SSH (удалённые машины), Singularity (высокопроизводительные вычислительные среды), Modal и Daytona (serverless с гибернацией, оплата только за время работы). Hermes может работать за $5 VPS, на графическом процессоре (GPU) или в serverless-инфраструктуре, которая стоит почти ничего в простое.

По количеству каналов (20+ мессенджеров: Telegram, Discord, Slack, WhatsApp, Signal, Email, CLI) Hermes близок к OpenClaw, но с другим акцентом: Hermes инвестирует в обучение и безопасность, OpenClaw — в широту экосистемы. Hermes поддерживает 200+ моделей: Nous Portal (собственный шлюз), OpenRouter, NovitaAI, NVIDIA NIM (Nemotron), Xiaomi MiMo, z.ai (GLM), Kimi/Moonshot, MiniMax, Hugging Face, OpenAI, Anthropic — работает с любой моделью, не привязан к одному вендору.

СОПОСТАВЛЕНИЕ ТРЁХ ПЛАТФОРМ ПО ДЕСЯТИ ОСЯМ

ОСИ РАСХОЖДЕНИЯ ТРЁХ ПЛАТФОРМ

Философия. Claude Code — инструмент от одного вендора с готовым мнением о том, как должен работать агент. OpenClaw — открытая экосистема с собственным каталогом. Hermes — обучаемый исполнитель с долговременной памятью.

Распределение модели. Claude Code — проприетарный, только Anthropic. OpenClaw — свои ключи пользователя через ClawRouters с автоматической маршрутизацией. Hermes — 200+ моделей, переключение через hermes model.

Безопасность. Claude Code — корпоративный уровень через тарифные планы, без открытого кода. OpenClaw — открытый код с шестью CVE за 4 месяца и рисками цепочки поставок в ClawHub. Hermes — открытый код с самой консервативной песочницей (корневая файловая система закрыта для записи, отключённые возможности Linux-контейнера, изоляция процессов на уровне операционной системы, сканер команд до выполнения).

Каналы взаимодействия. Claude Code — CLI/IDE. OpenClaw — 23+ мессенджеров из коробки. Hermes — 20+ мессенджеров плюс TUI с многострочным вводом и автодополнением по слешу.

Цена владения. Claude Code — фиксированная подписка, но квота расходуется на claude.ai. OpenClaw — $0–$9,99/мес плюс API. Hermes — $0 плюс оплата за токены, обычно дешевле Claude Code Pro на длинных сессиях.

Если выбирать между тремя платформами, представьте, что AI-агент — это писатель, и есть три издательства, которые могут его напечатать. Claude Code — это Penguin Random House: крупное, качественное, дистрибуция по всему миру, редакторы, корректура, обложка, ISBN. Автор пишет рукопись, отдаёт в издательство, через полгода книга лежит в магазине. Но Penguin Random House решает, в каком формате выйдет книга, каким шрифтом набрана и под каким лейблом. OpenClaw — это самиздат через Amazon KDP: автор сам контролирует обложку, цену, дистрибуцию, может в любой момент обновить текст, и аудитория у него глобальная, но никто не проверил рукопись на ошибки, и есть риск, что конкурент напишет отзыв с вредоносным QR-кодом. Hermes — это блог-платформа с подпиской: автор пишет посты, платформа их не редактирует, но зато показывает читателям, что именно им интересно, через полгода автор понимает свою аудиторию лучше, чем они сами себя, и пишет уже не для всех, а для тех десяти человек, которые возвращаются. Все три издательства печатают книги. Ни одно не лучше «по определению» — у каждого своя аудитория, своя экономика и свой риск.

ИНСТРУМЕНТЫ АГЕНТА: SKILL, PLUGIN И MCP-СЕРВЕР

Чтобы агент мог выйти за пределы разговора — прочитать файл, отправить письмо, обновить CRM, проверить документ в реестре — ему нужны инструменты. В современных платформах используются три способа их подключить, и они не конкурируют, а дополняют друг друга.

Skill (навык) — это инструкция для агента: текст или скрипт, который объясняет модели, как вести себя в конкретной ситуации. Например, skill «обработай входящее письмо» говорит агенту: прочитай, определи тему, выбери шаблон, заполни, отправь. Skill — это инструкция в голове агента, без отдельного процесса.

Plugin (плагин) — это код с побочными эффектами, который агент вызывает. Например, плагин «отправить email» или «создать задачу в Jira». Плагин работает внутри среды агента и может изменить внешнюю систему.

MCP-сервер (Model Context Protocol) — это внешний процесс, к которому агент подключается по стандартному протоколу. До MCP каждая интеграция (с почтой, с CRM, с базой) была отдельным проприетарным API у каждого вендора. MCP, открытый стандарт от Anthropic (ноябрь 2024), позволяет один раз написать интеграцию и использовать её с Claude, GPT, Gemini, локальными моделями. К апрелю 2026 MCP поддержали OpenAI, Google DeepMind, Microsoft, Cloudflare.

В реальной архитектуре три уровня сочетаются: skill говорит агенту, что делать, plugin выполняет действие в среде агента, MCP-сервер даёт доступ к внешним системам. Skill вызывает plugin, plugin дёргает MCP-сервер, MCP-сервер общается с внешним API. Это не «или-или» — это три слоя одного стека.

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

Три риска, которые нужно учитывать. Безопасность: MCP-сервер может быть скомпрометирован, и ответственность за проверку лежит на операторе. Известны атаки «tool poisoning», когда вредоносный сервер отдаёт агенту ложные инструкции. Зрелость: протоколу два года, экосистема молодая, ошибки в реализациях случаются. Lock-in: если вы построили агента вокруг MCP-серверов Anthropic, переход на OpenAI потребует перепроверки каждого сервера.

Пять типовых MCP-серверов для офисного агента. Файловая система (чтение и запись файлов). GitHub (чтение кода, создание issue, merge PR). Google Workspace или Microsoft 365 (чтение и отправка писем, работа с документами). CRM вроде Salesforce или HubSpot (чтение и обновление карточек клиентов). Корпоративная база знаний (Notion, Confluence) для поиска по внутренним документам.

КРИТЕРИИ ВЫБОРА ПЛАТФОРМЫ

Где живут ваши данные? Если в Salesforce — Agentforce. Если в Microsoft 365 — Copilot Studio. Если в Google Workspace — Gemini Enterprise. Если в нескольких экосистемах — посчитайте стоимость интеграции против стоимости миграции.

Какой у вас бюджет на кастомную разработку? Коробочные платформы дешевле на старте, но ограничивают гибкость. Кастомные агенты (LangGraph, CrewAI) дороже, но дают полный контроль.

Какие регуляторные требования? Банки и госкомпании часто требуют локального развёртывания. Не все платформы его поддерживают: IBM и OpenAI Enterprise — да, Salesforce и Google — только облако.

Какой срок до первого результата? Copilot Studio и Agentforce — дни до пилота. Кастомные агенты — недели до пилота. «Вчера» — коробочная платформа. Нужен контроль над данными — Hermes или OpenClaw, но закладывайте недели на настройку.

Том Кёйлаертс (Tom Cuylaerts), автор i-scoop.eu, в апреле 2026 описал ключевое архитектурное различие между двумя открытыми агентами: Hermes даёт глубину обучения, качество памяти и операционный контроль, OpenClaw — широту экосистемы. Выбор между ними идёт не по «кто лучше», а по приоритету: безопасность и обучение или широта каналов и низкий порог входа. Цифры риска OpenClaw из предыдущего раздела здесь работают против второго приоритета.

АРХИТЕКТУРНЫЕ РЕШЕНИЯ ДЛЯ AI-АГЕНТОВ

После выбора платформы начинается выбор архитектуры конкретного агента. Архитектура выбирается между двумя полюсами — workflow и агентом. Выше мы уже заложили, что workflow дешевле и стабильнее, агент гибче и опаснее, теперь разберём, как это выглядит в коде и как между ними выбирают.

В архитектуре workflow путь выполнения фиксируется заранее, LLM решает только локальные задачи внутри этого пути. Пример: пользователь пишет письмо → LLM извлекает тему → если тема А, вызвать функцию X; если тема Б, вызвать функцию Y; иначе — функцию Z. LLM принимает одно решение (классификацию), а разработчик заранее прописал, что делать в каждом случае. Workflow не справляется с задачами, которые не вписываются в заранее описанные ветки.

В архитектуре агента LLM получает контроль над тем, какие инструменты вызвать и в каком порядке. Тот же пример: пользователь пишет письмо → LLM сама решает, какие действия предпринять → вызывает нужные инструменты → оценивает результат → если он неудовлетворительный, вызывает другие инструменты или уточняет у пользователя. LLM принимает много решений, путь выполнения не предопределён. Агент справляется с нестандартными задачами, но менее стабилен, дороже и сложнее в отладке.

Гибрид сочетает оба подхода: часть пути предопределена (workflow), часть зависит от решений LLM (агент). Пример: LLM извлекает структуру претензии → если в претензии упоминается неустойка, агент берёт на себя поиск пунктов договора и оценку рисков; если упоминается срок поставки, workflow запускает стандартный процесс. Гибрид даёт предсказуемость workflow там, где она нужна, и гибкость агента там, где она оправдана.

ПАТТЕРНЫ РАССУЖДЕНИЯ АГЕНТА

ReAct (Reason + Act) появился в 2022 году и стал дефолтным паттерном для большинства agent-фреймворков. Цикл: модель генерирует мысль (Reason), выбирает действие (Act), наблюдает результат (Observe), цикл повторяется.

Проблема ReAct — стоимость: каждое наблюдение загружается в контекст, контекст растёт, стоимость растёт линейно с числом шагов. Для задачи из 15 шагов ReAct съедает в 5–10 раз больше токенов, чем его собрат ReWOO.

ReWOO (Reasoning WithOut Observations) решает эту проблему радикально: агент сначала строит план из всех необходимых наблюдений, потом исполняет план без повторных вызовов LLM между шагами. На независимых бенчмарках ReWOO сокращает расход токенов до 5x по сравнению с ReAct. Минус — ReWOO плохо работает, когда план зависит от результатов наблюдений («если на шаге 3 ответ окажется X, то на шаге 4 делаем Y»). В таких случаях приходится возвращаться к ReAct или комбинировать паттерны.

Plan-and-Execute — двухфазный паттерн: сначала отдельный вызов LLM строит план (список шагов), затем второй цикл исполняет план. Сильная сторона — план можно показать пользователю до начала действий и получить одобрение, либо скорректировать. Слабая сторона — если план построен на неверной гипотезе, всё исполнение идёт в неверном направлении, и перепланирование стоит дорого.

Reflexion добавляет к любому из этих паттернов петлю самокритики: после каждого действия (или серии действий) агент оценивает результат и, если он неудовлетворительный, переделывает. Reflexion полезен в задачах, где первая попытка часто ошибочна (генерация кода с юнит-тестами, многошаговые вычисления), но удваивает или утраивает стоимость.

ФРЕЙМВОРКИ ДЛЯ АГЕНТОВ: КРИТЕРИИ ВЫБОРА

LangGraph (от LangChain) — Python-фреймворк, представляющий агентный процесс как явный граф состояний. Узлы графа — шаги (вызов LLM, вызов инструмента, проверка условия), рёбра — переходы между шагами, в том числе циклические (вернуться и переделать). LangGraph хорошо подходит для сложных workflow с возвратом к предыдущим шагам, где простой ReAct-цикл не справляется. Минус — требует Python-разработчика, готового думать в терминах графа состояний, а не «вот вам список инструментов, агент сам разберётся».

OpenAI Agents SDK — оркестратор многоагентных сценариев в экосистеме OpenAI, появившийся в 2025 году. Сила — низкий порог входа: разработчик на OpenAI API получает готовый фреймворк для построения агентов с инструментами, передачей задач между агентами, встроенными ограничителями и журналированием всех вызовов. Если вы уже в экосистеме OpenAI, это путь наименьшего сопротивления. Минус — привязка к моделям и инфраструктуре OpenAI.

Claude Agent SDK — развитие Claude Code в сторону переиспользуемых компонентов. В мае 2026 года Anthropic расширил Claude Code Skills (текстовые инструкции с прогрессивным раскрытием), Plugins (бандлы для дистрибуции) и MCP-маркетплейс, эти же компоненты доступны через SDK для встраивания в собственные приложения. Если вы строите продукт вокруг Claude 4.6, Claude Agent SDK — нативный выбор.

CrewAI — фреймворк с открытым исходным кодом, представляющий агентов как «членов команды» с ролями и целями. Подход привлекателен для тех, кто мыслит в терминах «назначить агента-исследователя, агента-копирайтера, агента-редактора». Минус — ролевая метафора иногда скрывает реальную сложность оркестрации, при росте числа агентов (больше 5) контроль над системой становится рыхлым.

АНАТОМИЯ АГЕНТА: РАЗБОР ПО СЛОЯМ

Архитектура работающего агента (например, Hermes Agent или Claude Code) раскладывается на пять слоёв, и каждый из них — отдельная точка отказа, точка расширения и объект для оптимизации.

Ядро (core) запускает главный цикл while True: think_and_act() при поступлении сообщения и останавливает его при достижении финального состояния. Инструменты (tools) — функции, которые агент может вызвать; каждая, как правило, лежит в отдельном файле или модуле. Подсистема инструментов (tool subsystem) группирует вызовы в пачки, валидирует аргументы, обрабатывает ошибки и решает, что запускать параллельно (read-only), а что строго последовательно (с побочными эффектами). Bridge — компонент, через который агент общается с удалёнными клиентами (MCP-серверами, внешними API, другими агентами). Память (memory) — долговременное хранилище между сессиями, обычно набор markdown-файлов с индексацией и поиском. Когда вы оптимизируете агента, вопрос «в каком слое у нас бутылочное горлышко?» — первый, который нужно задать себе перед любыми правками промпта.

ПРИЗНАКИ НАЗРЕВШЕЙ СМЕНЫ АРХИТЕКТУРЫ

– Агент стабильно проваливается на одном и том же шаге, и простые правки промпта не помогают. Признак того, что шаг выделен неправильно (нужно разбить или объединить с соседним).

– Стоимость одной задачи выросла в 3–5 раз по сравнению с базовой, а качество не улучшилось. Признак раздутого контекста (агент тащит в окно лишнее) или неправильного паттерна (нужен ReWOO вместо ReAct).

– Время выполнения задачи выросло до неприемлемого (5+ минут на рутинную операцию). Признак длинной цепочки с лишними шагами, либо последовательного вызова read-only операций, которые можно параллелить.

– Появились граничные случаи, которые рабочий промпт не покрывает, и они встречаются чаще 5% случаев. Признак того, что workflow пора превращать в агент для этой ветки, или наоборот — вынести ветку в отдельный workflow.

Здесь уместна кухонная метафора: агент — кухня с одним поваром, который одновременно читает заказ (рассуждение), идёт к полке за ингредиентами (действие), возвращается к плите (наблюдение), пробует блюдо (оценка) и решает, добавить ли соли (перепланирование). Если повар работает один — это ReAct-цикл: каждое его действие возвращает его к плите, контекст его «головы» (что в сковородке, что в заказе, что на полке) растёт с каждым шагом. ReWOO — когда повар сначала обходит полку и записывает, что возьмёт, потом уже готовит, не возвращаясь к полке. Plan-and-Execute — когда повар сначала выдаёт заказчику список блюд, получает одобрение, потом готовит. Reflexion — когда после каждой тарелки повар пробует и решает, что досолить.

У каждой кухни — своя метрика качества. У ReAct — гибкость в неожиданных заказах. У ReWOO — скорость на стандартных. У Plan-and-Execute — предсказуемость для заказчика. У Reflexion — вкус блюд при высокой цене.

МУЛЬТИАГЕНТНЫЕ СИСТЕМЫ: ПРЕДЕЛ ВОЗМОЖНОСТЕЙ ОДНОГО АГЕНТА

Мультиагентная AI-система — архитектура, в которой несколько специализированных агентов работают совместно под управлением оркестратора, решая задачу, которую один агент не способен решить в одиночку. Вместо одного универсального AI система содержит набор узкоспециализированных агентов: агент поиска, агент анализа данных, агент планирования, агент проверки качества — и координатор, распределяющий задачи между ними. Gartner прогнозирует, что к 2027 году каждый третий enterprise-софт будет содержать AI-агентов против 1% в 2024. По оценкам BCG, выручка от мультиагентных систем достигнет $53 млрд к 2030 году против $5,7 млрд в 2024.

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

БАЗОВЫЕ АРХИТЕКТУРНЫЕ ПАТТЕРНЫ

Hub-and-Spoke (hub = оркестратор, spokes = рабочие агенты). Оркестратор принимает запрос, разбивает на подзадачи, отдаёт рабочим агентам, собирает результаты. Самый простой в отладке: весь trace идёт через одну точку. Минус — узкое горлышко в оркестраторе: при росте числа агентов он становится ограничителем пропускной способности всей системы.

Pipeline (конвейер). Агенты выстроены в цепочку: выход одного становится входом следующего. Подходит для задач с естественной последовательностью этапов (извлечение данных → анализ → формирование отчёта → проверка). Минус — один сбой в середине конвейера останавливает всё, и перепланирование сложнее, чем в Hub-and-Spoke.

DAG (directed acyclic graph). Агенты образуют направленный ациклический граф: выходы нескольких агентов сходятся в узел-агрегатор. Подходит для задач, где несколько параллельных потоков анализа сходятся в финальный синтез. Сложнее в отладке, чем Pipeline, но эффективнее, когда подзадачи действительно независимы.

Swarm (рой). Агенты общаются друг с другом напрямую, без центрального оркестратора, по принципу стаи. Подходит для исследовательских задач, где невозможно заранее предсказать, какие агенты понадобятся. Минус — отладка превращается в расследование: какой агент, кому и что передал, и в каком порядке.

КООРДИНАЦИЯ: ОРКЕСТРАЦИЯ ПРОТИВ СОБЫТИЙНОЙ МОДЕЛИ

Координация между агентами бывает двух типов, выбор между ними — выбор между предсказуемостью и гибкостью.

Оркестрация — централизованная схема. Есть явный оркестратор (workflow или агент-координатор), который знает все шаги и распределяет задачи. Оркестрация даёт предсказуемость, лёгкое журналирование вызовов и быструю отладку. Цена — узкое горлышко: при росте числа агентов оркестратор становится ограничителем всей системы.

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

Практическое правило: если задача линейна и редко меняется — оркестрация. Если задача эволюционирует, появляются новые типы запросов, состав агентов меняется чаще, чем раз в квартал — событийная координация. Команда Databricks в 2025 году описала реальный случай гонки состояний в своей мультиагентной системе: два агента одновременно пытались обновить одну запись в общем хранилище признаков — базе данных с подготовленными признаками для ML-моделей, — один из них видел устаревшую версию. Решение — переход на архитектуру, где каждое изменение записывается как последовательность событий, с атомарными операциями и явными блокировками. Фактически это элемент оркестрации, встроенный в событийную координацию.

ПРИЗНАКИ ЗАДАЧИ, КОТОРОЙ НУЖНА МУЛЬТИАГЕНТНАЯ АРХИТЕКТУРА

– Задача разбивается на 3+ чётко различных подзадачи, каждая со своей экспертизой (поиск + анализ + проверка качества).

– Подзадачи можно выполнять параллельно (экономия задержки).

– Каждая подзадача требует своего контекста, который не должен попадать в общий промпт (например, юридический анализ и технический анализ с разной терминологией).

– Результат одной подзадачи — вход для другой, и связь между ними предсказуема.

– Команда разработки может разделиться по подзадачам и работать параллельно.

ПРИЗНАКИ ИЗБЫТОЧНОСТИ МУЛЬТИАГЕНТНОЙ АРХИТЕКТУРЫ

– Задача может быть решена одним агентом с 5–10 инструментами.

– Все «агенты» будут использовать одну и ту же модель (нет выигрыша от специализации).

– Координация между агентами требует сложного workflow, который сам становится источником багов.

– Стоимость и задержка от мультиагентной системы превышают выигрыш от параллелизма.

– Отладка занимает больше времени, чем сама задача.

Мультиагентные системы в реальной работе без инфраструктуры оценки качества дают долю сбоев (failure rate) от 41 до 86,7%. Anthropic в материалах 2025 года о многоагентных системах описал реальную нагрузку, в которой мультиагентная система тратит в 15 раз больше токенов на задачу, чем одиночный агент с хорошим промптом.

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

Самый распространённый паттерн мультиагентной системы в 2026 году — «ведущий плюс рабочие» (lead agent + worker agents). Один «ведущий» принимает запрос от пользователя, разбивает его на подзадачи, распределяет между «рабочими», собирает результаты и формирует финальный ответ. У каждого «рабочего» своя роль, свои инструменты, свой системный промпт, а «ведущий» не выполняет работу сам — только координирует. Anthropic в 2025 году выпустил фреймворк Claude Projects + Skills, который реализует этот паттерн «из коробки». Начинать стоит с двух агентов (supervisor + worker) и наращивать итеративно по мере отладки: три агента в рабочей эксплуатации без наблюдения — три отдельных источника сбоев, не один. И ещё одна рекомендация, которую разработчики мультиагентных систем обычно формулируют уже после первого провала: не стройте мультиагентную систему, пока один агент с пятью инструментами не упёрся в свой потолок. Переход к мультиагентности — не апгрейд, это смена класса задачи.

РЕЗЮМЕ

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

Выбор платформы идёт не по принципу «какая модель лучше», а по тому, где живут данные и какие регуляторные требования. Пять корпоративных платформ закрывают разные ниши через интеграцию с экосистемами. Для разработчиков — Claude Code, OpenClaw и Hermes Agent с разными акцентами. В любой платформе живут три уровня расширений: skill, plugin и MCP-сервер.

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

MCP стал отраслевым стандартом подключения инструментов: одна интеграция работает с любой моделью, поддерживающей протокол. Progressive discovery сокращает расход токенов на порядок. Модель без инфраструктуры — чат, инфраструктура без дисциплины выбора — сожжённый бюджет.

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

Что толку от платформы и агента, если непонятно, в какой процесс их вообще ставить? Следующая глава переводит разговор из технической плоскости в управленческую: какие процессы в офисе первыми отдавать AI, какие не отдавать ни в коем случае, и как собрать воркфлоу вокруг модели, чтобы он ускорял рутину, а не ломал то, что работает. Там же — десятиминутный тест «брать или не брать», балльная оценка кандидата и три метрики, по которым ROI считается без сложных финансовых моделей.

Предыдущая главаГлава 8 из 21Следующая глава