Главное про AI - Вадим Жартун
ИНСТРУМЕНТЫ АГЕНТА: 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 плохо работает, когда план зависит от результатов наблюдений («если на