ИИ-агенты в 2026: устройство, выбор модели и провалы в проде

Под «AI-агентом» в 2026 году называют что угодно — от хитрого промпта до ChatGPT с памятью. Если вернуть слову смысл, окажется, что большинству задач достаточно обычного workflow, а провалы в проде — про границы, бюджеты и качество данных, а не про «выбор модели».

1. Чат-бот, LLM, агент — три уровня зрелости

Под «AI-агентом» сейчас называют что угодно. Полезная градация:

• Чат-бот — реактивный: триггер → ответ → конец. Stateless, без памяти о цели после диалога.
• LLM с RAG — генерирует и рассуждает по контексту, но не выполняет действий в системах.
• Workflow — оркестрация модели и инструментов по предопределённому коду; разработчик пишет шаги, LLM встроена в поток, но не управляет им.
• AI-агент — stateful, multi-step: получает цель → декомпозирует → выбирает инструменты → исполняет → проверяет результат → повторяет.

Чат-бот     ──>  LLM + RAG    ──>  Workflow         ──>  Agent
триггер →        генерация          фикс. шаги           цель + цикл
ответ            по контексту       (логика в коде)      (логика в модели)

Полезная переформулировка: агент — это надёжная система-обвязка вокруг ненадёжной вероятностной модели. Ценность не в «уме» LLM, а в слое надёжности вокруг — оркестрация, инструменты, логи, evals, guardrails.

2. Когда нужен агент, а когда — workflow

Agentic-подход повышает latency и стоимость; оправдан он не всегда. Эмпирика: ~80% задач закрываются обычным workflow — последовательностью шагов, которую пишет разработчик, а LLM встроена как одно из звеньев.

Anthropic в гайде «Building Effective AI Agents» предлагает не одно бинарное «agent vs не agent», а пять базовых паттернов, которые перекрывают большинство задач:

Это лестница сложности: один LLM-call → workflow → агент. Поднимайся только при необходимости.

Триггеры, когда нужен именно agent:

• задача занимает ≥3 шагов или >1 системы;
• решения зависят от контекста на ходу, исход не предопределён;
• результат можно проверить автоматически — тесты, ответ API, изменение состояния.

Если хотя бы одного из этих условий нет — workflow надёжнее и дешевле.

3. Анатомия: четыре компонента

Агент раскладывается на 4 компонента:

                         ┌─────────────────────┐
                         │   Цель пользователя │
                         └──────────┬──────────┘
                                    ▼
                            ┌───────────────┐
                            │  Мозг — LLM   │  reasoning, планирование
                            └───────┬───────┘
                                    │
              ┌─────────────────────┼─────────────────────┐
              ▼                     ▼                     ▼
        ┌──────────┐         ┌──────────┐         ┌──────────────┐
        │ Tools    │         │ Memory   │         │ Knowledge    │
        │ API,     │         │ short /  │         │ base (RAG)   │
        │ shell,   │         │ session /│         │ доменные     │
        │ DB       │         │ long     │         │ документы    │
        └──────────┘         └──────────┘         └──────────────┘

• Мозг — LLM: reasoning + planning, решает «что делать дальше».
• Tools (инструменты, «руки»): function calling — API, shell, браузер, БД, вычисления.
• Memory: working memory (контекст в промпте сейчас), session history (прошлые ходы сессии), long-term (vector DB / файлы / логи прошлых траекторий).
• Knowledge base — RAG: справочники и доменная документация, защита от галлюцинаций.

Контринтуитивный факт из AgentBench: главная причина провала агентов — слабые long-term reasoning и decision-making у мозга-LLM, а не нехватка инструментов. «Дать агенту 50 функций» — анти-паттерн.

4. Tool calling и обрыв контекста

Tool calling (вызов инструментов) под капотом работает просто: модель возвращает JSON с именем функции и аргументами, рантайм исполняет, результат возвращается в контекст следующим шагом цикла.

{
  "name": "find_customers",
  "description": "Поиск клиентов по запросу. Топ-5 совпадений.",
  "parameters": {
    "query": {"type": "string"},
    "limit": {"type": "integer", "default": 5}
  }
}

Эмпирическое правило: хороший description инструмента решает больше, чем выбор модели. find_customers(query, limit=5) — узкий контракт с понятными границами. database(query) — «делай что хочешь», и модель действительно начнёт «делать что хочет».

Когда инструментов в каталоге становится много, проявляется context cliff (обрыв контекста): схемы всех инструментов кладутся в активный prompt, и качество выбора падает не линейно, а скачком.

selection accuracy
   ▲
95 │ ████████  ←  ~10 tools
   │ ████████
85 │ ███████   ←  ~50 tools
   │ ████
15 │ ██        ←  ~100 tools
   │ ▏         ←  ~700 tools
 0 │
   └────────────────────────────►
    10   50   100        700+   tools

Три механизма деградации:

1. Lost-in-the-middle (потерянное в середине): трансформер распределяет внимание неравномерно — токены в середине длинного контекста получают меньший вес. Описание инструмента, оказавшееся в середине каталога, модель «не видит».
2. Tool collision (коллизия инструментов): при росте каталога границы между близкими endpoints (search_issues / list_issues / get_issue) размываются — модель путает или смешивает параметры.
3. Prompt budget starvation (голод бюджета промпта): под схемы съедается столько токенов, что для system prompt и guardrails места не остаётся.

Митигации:

• Semantic top-K — эмбеддинг запроса + cosine similarity по описаниям инструментов → в активный prompt идут только k наиболее релевантных схем.
• Progressive disclosure — инструменты разнесены по namespaces (github__*, notion__*), быстрый классификатор определяет нужный набор под шаг.
• Schema minimization — короткие descriptions, примитивные типы, fixed enums вместо свободного текста.

5. Выбор модели: 4 критерия, не «возьми флагман»

«Один флагман на всё» — главный источник перерасхода. Четыре критерия:

• Качество — общий бенчмарк + свои evals на домене. Общие лидерборды ≠ прод.
• Контекст — размер окна и эффективный recall в его середине. Окно 1M токенов не значит, что модель удержит 1M (lost-in-the-middle).
• Стоимость — $/1M токенов на input/output. Агент делает десятки вызовов на задачу, цена умножается.
• Latency + tool use — reasoning-режимы дают +5–10% качества ценой 2–5× по времени. Голосовому агенту это смерть UX, code-агенту — норма.

Практика: подбирай модели на роли. Дешёвая на классификацию и tool-execution, средняя на «исполнителя», флагман — только на gatekeeping (compliance, финансовые согласования).

Архитектурный приём экономии — Architect/Editor split:

┌──────────────────┐                   ┌──────────────────┐
│ Architect        │   short JSON      │ Editor           │
│ дорогая «умная»  │ ──── plan ─────►  │ дешёвая быстрая  │
│ модель           │                   │ модель           │
│                  │                   │                  │
│ ► короткий план  │                   │ ► основной объём │
└──────────────────┘                   └──────────────────┘

Экономия 50–80% бюджета, причём качество часто выше: «редактор» не отвлекается на архитектуру.

6. Бенчмарки 2026: что меряют и scaffold effect

Классические MMLU/GSM8K/HumanEval насыщены — все фронтиры выше 95%. Что реально меряют:

• SWE-bench Verified — 500 GitHub-issue, отобранных вручную; модель пишет patch, проходящий тесты.
• SWE-bench Pro — то же, но архитектурно сложные multi-file задачи под enterprise-структуру кода.
• OSWorld-Verified — desktop computer-use: файловая система, браузер, Linux-окружение.
• ARC-AGI-2 — невербальное логическое рассуждение по визуальным паттернам.
• ARC-AGI-3 — интерактивные игровые среды, цель не задана; модель должна сама её вывести. Все фронтиры пока около нуля — это сдвинутая граница.
• τ-bench (Tau-bench) — многоходовая надёжность в обслуживающих диалогах: транзакции, удержание состояния через 20+ ходов.

Главная ловушка чтения — scaffold effect (почему бенчмарки обманчивы): балл модели = веса + обвязка (verification, retry-loops, state-saving, инжиниринг харнесса). Смена scaffold вокруг тех же весов сдвигает результат на 10–18 п.п. Поэтому к vendor-score применяют дефлятор ×0.7 — грубая, но рабочая оценка «как будет в вашем окружении без оптимизированной обвязки».

Пять правил чтения:

1. 3+ бенчмарка под свою задачу, не одну цифру.
2. Дата старше 6 месяцев — устарело.
3. Vendor-score умножай на ~0.7 (best-case scaffold).
4. Scaffold (Claude Code, Aider, Codex и пр.) смещает результат на 10–20%.
5. Verified vs Pro — на сложных закрытых данных балл падает примерно в 3×; в проде реальность ближе к Pro.

Финал — свои evals на 50–200 примерах своего домена. Не пытайся построить идеальный набор сразу: 20 примеров → найди где сыпется → добей до 50–100 на проблемных кейсах.

7. Почему агенты падают в проде

Типология провалов, повторяющаяся из обзора в обзор:

• Scope creep — пилот расширяют новыми инструментами и ветками, state-tracking растёт, систему уже не отладить. Лекарство: v1.0 решает одну задачу хорошо; расширение — через sub-agents с узкой ролью.
• Data quality drift — на чистых тестах работает, на боевых данных рассыпается из-за пропусков, форматов, дубликатов. У агента ошибки накапливаются по цепочке. Лекарство: до интеграции — аудит данных, не код.
• Security & governance — нет access controls, audit logs, защиты от prompt injection. Не проходит security review.
• Integration debt — хрупкие хардкод-интеграции с legacy. Лекарство — стандартизированные интерфейсы (MCP).
• Cost overruns — runaway-циклы без бюджетных лимитов жгут токены. Нужны max_iterations, max_tokens, max_cost одновременно.
• Governance gaps — единая бинарная политика на все агенты: read-only не нужны те же ограничения, что action-executing.
• Organizational resistance — нет владельца со стороны бизнеса, нет вовлечения пользователей.

Отдельно security как класс:

• Over-permissioning (лишние права) — агенту выдают доступ шире, чем нужно для задачи; при компрометации это превращается в blast radius всей системы.
• Indirect prompt injection — модель не отличает инструкции от данных. Атакующий встраивает команду в PDF, email, веб-страницу — агент это читает и исполняет. Защита архитектурная: изоляция привилегий между «контентным» и «действующим» агентами, HITL на действиях с побочным эффектом, иммутабельный action log.

8. Локальный self-host: Ollama

Self-hosted inference оправдан, когда данные не должны уходить за периметр, объёмы делают API дорогим или нужен контроль над инфраструктурой. Минимальный сетап:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:8b

# Длинный контекст и тюнинг под прод:
export OLLAMA_CONTEXT_LENGTH=131072    # 128K
export OLLAMA_FLASH_ATTENTION=1        # Flash Attention для длинных входов
export OLLAMA_KV_CACHE_TYPE=q8_0       # квантованный KV-cache, ~½ памяти

Ollama поднимает локальный inference-сервер с OpenAI-совместимым API — клиенты, агенты и оболочки подключаются меняя только base URL.

Что важно держать в голове про память:

VRAM ≈ веса модели + KV-cache(растёт с длиной контекста) + активации

Поэтому при локальном запуске решают не только параметры модели, но и квантизация (GGUF Q4 экономит ~4× относительно FP16) и GQA (Grouped-Query Attention уменьшает KV-cache). На ноутбуке потолок — модели уровня 7–8B; «более-менее разумная» локалка требует ~12–15 ГБ RAM. На старте часто берут облачный API, а локальный inference оставляют для приватных шагов.

Готовые оболочки: Dify (RAG + агенты + аналитика), Open WebUI (офлайн, LDAP), RAGFlow (глубокий парсинг таблиц, GraphRAG, реранкинг). Для оркестрации цикла агента — LangGraph: граф состояний, чекпоинтеры под рестарт, conditional edges под exit-условия (max_iterations, no_progress).

FAQ

Когда нужен полноценный агент, а когда хватит workflow?

Workflow закрывает примерно 80% задач и почти всегда дешевле и предсказуемее. Агент оправдан, только когда выполнены все три условия сразу: задача требует ≥3 шагов или больше одной системы, ход решения зависит от контекста и заранее не определён, а результат можно проверить автоматически (тесты, ответ API, изменение состояния). Нет хотя бы одного — берите workflow.

Что такое context cliff и как с ним бороться?

Context cliff — скачкообразное, а не линейное падение точности выбора инструмента при росте каталога: схемы всех инструментов забивают активный prompt. Три механизма: lost-in-the-middle, tool collision и prompt budget starvation. Митигации: semantic top-K (в prompt идут только релевантные схемы), progressive disclosure по namespaces и schema minimization.

Как выбрать модель для агента?

По четырём критериям, а не «бери флагман»: качество (общий бенчмарк плюс свои evals на домене), эффективный recall в середине окна (а не номинальный размер контекста), стоимость $/1M токенов (агент делает десятки вызовов на задачу) и latency с tool-use. Подбирайте модели на роли: дешёвую — на классификацию и tool-execution, флагман — только на gatekeeping.

Можно ли доверять бенчмаркам из карточки модели?

Не как абсолюту. Балл = веса + обвязка (scaffold), и смена обвязки сдвигает результат на 10–18 п.п. Практическое правило: смотрите 3+ бенчмарка под свою задачу, игнорируйте цифры старше 6 месяцев, умножайте vendor-score на ~0.7 и помните, что на сложных закрытых данных (Pro против Verified) балл падает примерно втрое. Финальный критерий — свои evals на 50–200 примерах домена.

Почему агенты падают в проде?

Не из-за «выбора модели», а из-за границ, бюджетов и качества данных: scope creep, data quality drift, дыры в security и governance, integration debt с legacy и cost overruns от runaway-циклов. Отдельный класс — безопасность: over-permissioning и indirect prompt injection. Лечится архитектурно: узкие роли, аудит данных до интеграции, бюджетные лимиты и изоляция привилегий.

Источники

• Anthropic — Building Effective AI Agents: пять базовых паттернов и граница workflow ↔ agent.
• Lost in the Middle: How Language Models Use Long Contexts — неравномерное внимание трансформера по длине контекста.
• MCP tool overload: why more tools make your agent worse и The tool-bloat epidemic — деградация при росте каталога инструментов.
• Бенчмарки: SWE-bench, τ-bench, OSWorld, ARC-AGI.
• Why AI benchmarks are misleading — про scaffold effect и чтение vendor-score.

Цифры обрыва контекста (≈95/85/15% на 10/50/100 инструментах), дефлятор ×0.7 и оценка «~80% задач = workflow» — практические ориентиры порядка масштаба, а не данные одного измерения; калибруйте на своём домене.