1. Reasoning effort: три рычага и четыре режима

Reasoning effort (усилие рассуждения) — управляемая глубина мышления модели. Ключевой вопрос не «умнее ли модель», а «какое усилие нужно для этой конкретной задачи». Мышление — ресурс, им нужно управлять явно, не по умолчанию.

Полезная градация по глубине; порядок цены растёт примерно на десятичный множитель с каждой ступенью:

• Reflexive — прямой ответ без рассуждения («Как тебя зовут?»).
• Standard — промпт + один вызов, без extended thinking (расширенное обдумывание).
• Deliberate — Chain-of-Thought (цепочка рассуждений) до 5 шагов: анализ, сравнение, выбор.
• Exhaustive — много итераций с reflection (рефлексия) и self-correction (самокоррекция): сложный код, многошаговый reasoning.

Эмпирика проста: высокое усилие оправдано только на меньшей части задач — оценочно один из пяти. На остальных глубокий reasoning жжёт бюджет и latency без прироста точности.

Три независимых рычага усилия:

1. Модель — Tier 1 (mini/haiku) против Tier 3 (Opus/GPT-5); разница цены порядка 15–20×.
2. Глубина reasoning — параметр API: reasoning_effort у OpenAI, budget_tokens или effort у Anthropic, thinkingLevel / thinkingBudget у Gemini, Dual Mode у DeepSeek.
3. Число шагов — max_iterations в петле плюс early stopping (ранняя остановка) при достижении цели.

В 2026 году парадигма окончательно сместилась от «текстовых инструкций в промпте» к управлению через параметры API. Внутренняя трассировка размышлений происходит автоматически; фраза «думай шаг за шагом» в пользовательском запросе теперь только зря расходует контекст, дублируя встроенную делиберацию.

Текущая раскладка API на флагманах:

Минимальный пример активации extended thinking у Anthropic:

import anthropic

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=8192,
    thinking={"type": "enabled", "budget_tokens": 4096},
    messages=[{"role": "user", "content": "..."}],
)

budget_tokens ограничивает скрытый reasoning-трейс отдельно от итогового ответа. Поднимать не «потому что можно», а под конкретный профиль задачи.

2. Кривая overthinking: три региона

Зависимость точности от объёма test-time compute (вычислений на этапе вывода) — не монотонная. На кривой три характерных региона.

accuracy
   ▲
   │       ╭─────╮
   │      ╱       ╲       ◄── inversion: точность падает
   │     ╱         ╲          (overthinking, доменно-специфично)
   │    ╱           ╲
   │   ╱
   │  ╱ ◄── token-burning: точность ровно,
   │ ╱     цена и latency растут
   │╱
   │ ◄── high-yield: +5–10% качества окупают токены
   │
   └─────────────────────────────────────►  thinking budget

1. High-yield — сложный код (уровень SWE-bench), аудит многопоточного, оптимизация SQL, доказательство теорем, ветвящиеся планы с жёсткими ограничениями. Здесь effort: high или максимальный budget_tokens окупают деньги.
2. Token-burning — извлечение JSON-сущностей, классификация интента, заполнение шаблонов, саммаризация. Глубокое мышление генерирует сотни пустых рассуждений; точность та же, счёт выше.
3. Inversion — режим, описанный в «When More Thinking Hurts» (см. обзор эффекта): при чрезмерном бюджете модель начинает сомневаться в очевидном, ломает синтаксически верные конструкции, уходит в избыточное усложнение. На зафиксированных тестах точность падала с 49.6% до 48.1%, стоимость росла на 56%, latency — критически.

Self-reflection не бесплатное добро. У слабых моделей самокоррекция нередко усугубляет ошибку — модель запутывается в собственных правках. Включать осознанно, как и любой глубокий режим.

3. Пятислойная защита: бюджет — это не экономия, это стабильность

Runaway agent (зацикленный агент) бывает не только от атаки. Гораздо чаще — от обычного бага: изменился формат API → retry-петля → 200× токенов за 40 минут. CPU/RAM при этом в норме, поэтому стандартный Prometheus такого не ловит.

Цифры порядка масштаба, чтобы калибровать тревогу:

• Развёртывание Claude Code в Uber: 95% инженеров подхватили инструмент, индивидуальные счета $500–2000 в месяц на разработчика. Годовой бюджет на AI-ассистентов исчерпан за 4 месяца.
• В малом сегменте — case из LangChain-комьюнити: отсутствие max_iterations в цикле ресерча → бесконечные проходы валидации → более $150 за решение одной задачи через o1-preview.
• В корпоративе — несколько тысяч долларов за выходные из-за рекурсивной обработки ошибок в фоновом воркере.

Защита строится из пяти независимых слоёв. Нужны все одновременно: каждый ловит то, что пропустил предыдущий.

запрос
  │
  ▼
┌─────────────┐  agentic-сессия живёт 5–20 минут;
│ 1. Timeout  │  NGINX/ALB/Ingress режут на 30–300 сек.
└─────┬───────┘  Лечение: async queue, background worker,
      │          hard-limit времени у планировщика.
      ▼
┌─────────────┐  max_iterations = 10–15 в ReAct;
│ 2. Anti-loop│  max 3 попытки исправить одну ошибку;
└─────┬───────┘  стоп-условие "No Progress" наряду с лимитами.
      │
      ▼
┌──────────────────┐  Шлюз (Portkey, LiteLLM, MLflow Gateway)
│ 3. Cost Circuit  │  считает $ в реальном времени.
│    Breaker       │  Пороги: $50 warning / $100 halt,
└─────┬────────────┘  per-task ≈ $5.
      │
      ▼
┌─────────────┐  Никаких алиасов gpt-4o или claude-3-5-sonnet —
│ 4. Model    │  только фиксированные версии (gpt-4o-2024-05-13).
│    Pinning  │  Тихое обновление модели у провайдера
└─────┬───────┘  ломает парсеры → бесконечный цикл валидации.
      │
      ▼
┌─────────────┐  OpenTelemetry-атрибуты:
│ 5. Audit Log│  gen_ai.usage.input_tokens,
└─────────────┘  gen_ai.usage.output_tokens, session_id.

Бюджетные уровни как стартовые: задача ~$0.50 / сессия ~$2 / день ~$10. Дальше калибровать по своему профилю нагрузки.

Один нюанс из практики LangGraph: даже защитные слои сами протекают. В Issue #7554 у RetryPolicy jitter добавлялся после ограничителя max_interval — фактическое ожидание уходило выше декларированного лимита. Мораль: даже backoff-логика (отступы между повторами) — это код, который надо тестировать как код.

4. AI-метрики: что мерить вместо RPS

Классический мониторинг — stateless: RPS, latency, ошибки HTTP. Распределённую транзакцию агента из десятков гетерогенных вызовов к разным моделям он не видит. Нужен другой набор показателей, собираемый шлюзом.

• tokens_per_task — суммарные токены на одну прикладную задачу, включая скрытые токены reasoning.
• cost_per_completion — итоговая стоимость сессии: (I × P_in + O × P_out) / 1_000_000.
• loop_iterations — число итераций цикла. Рост при неизменной точности = деградация планирования.
• retry_overhead_tokens — токены, сожжённые на повторные вызовы при ошибках парсинга и валидации. Прокси к качеству системного промпта и стабильности парсеров.

Алерт — при 2× от baseline по любой из метрик, не по абсолюту.

Технически собирать это удобнее всего на шлюзе (Portkey, LiteLLM, MLflow Gateway), а не внутри самого агента. Шлюз видит все вызовы — включая ретраи и fallback-переключения — и аннотирует их одним session_id. Атрибуты OpenTelemetry gen_ai.usage.input_tokens / gen_ai.usage.output_tokens плюс session_id дают сквозную трассировку одной агентской задачи поверх десятков гетерогенных LLM-вызовов. Бонус: вынос retry-логики на уровень шлюза изолирует сетевые сбои от внутренней логики агента — иначе сбой одного терминального узла порождает каскадный retry-шторм у всех вышестоящих оркестраторов с взрывным ростом retry_overhead_tokens.

При достижении критических лимитов система должна делать early stopping, а не hard error (жёсткое падение). Контролируемая остановка персистит текущую сессию: оператор вмешивается, правит промпт, продолжает с последнего валидного шага. Жёсткое падение уничтожает прогресс и провоцирует ту же retry-петлю снаружи.

5. Каскадный роутинг и budget-aware эскалация

Типичная ошибка экономики — одна (самая мощная) модель на всё: «который час?» и «напиши алгоритм» стоят одинаково дорого. Роутер оценивает сложность запроса и выбирает модель. На правильно настроенном каскаде значительная часть трафика уходит на дешёвую модель, а качество держится близко к флагману — конкретные цифры см. ниже по TRACER.

запрос
  │
  ▼
┌────────────────────┐   hit → ответ из кэша, cost = 0
│ 1. Семантический   │   miss ↓
│    кэш  (<5 мс)    │
└────────────────────┘
  │
  ▼
┌────────────────────┐   simple → cheap-модель сразу
│ 2. Классификатор   │              (Haiku 4.5, GPT-4o-mini)
│    интента ~0.5B,  │   complex → дорогая модель reasoning
│    vLLM (<5 мс)    │   ambiguous ↓
└────────────────────┘
  │
  ▼
┌────────────────────┐   confidence ≥ порога (≈ 0.85) → отдать
│ 3. Cheap-модель +  │   confidence <  порога → escalation
│    confidence      │
│    score           │
└────────────────────┘

Порог confidence (старт ≈ 0.85) калибруется на 100–200 реальных запросах. Confidence получают через structured output: {answer, confidence, reason}. «На глаз» порог не ставят — оценка с LLM-judge или ручная разметка.

Калибровка через ручную разметку — затратна. Альтернатива — обучить суррогатный классификатор на traces работы флагмана: tracer-based routing. Активация через parity gate: суррогат пускают в прод только когда его согласие с моделью-учителем на тесте выше порога α. На опубликованных результатах — до 85% рутинного трафика уходит на дешёвые локальные модели при сохранении 95% качества и общем снижении затрат на 70% (разбор LLM-routing).

Роутер бывает двух разных типов, и в проде они сосуществуют. Первый — экономический каскад по confidence (про деньги): cheap → escalate при низкой уверенности. Второй — Intent / Task Router: классификация типа запроса («объясни термин» / «дай план» / «сделай отчёт» / «найди в документах») → выбор сценария, шаблона и источника контекста, а не модели. Плюс этот же роутер работает как guardrail (защитный фильтр): отсекает вредные запросы и prompt injection (инъекция в промпт) до «мозга». Это две разные оси, и в продакшен-системе они обычно сосуществуют.

И наконец Budget-Aware Agentic Routing (BAAR) — маршрутизация под бюджет как последовательная задача принятия решений, где ошибки на ранних шагах лавинообразно накапливаются. На практике это значит:

• остаток бюджета <30% — шлюз форсит cheap-модель и перестраивает план декомпозиции в сторону минимизации шагов;
• остаток <10% — пропускаются только simple-запросы, остальное — controlled stop.

6. Architect/Editor split: архитектура экономии

Самая надёжная экономия — не «уменьшить effort», а разнести роли по моделям разного класса.

┌──────────────────┐   short JSON   ┌──────────────────┐
│ Architect        │  ─── plan ───▶ │ Editor           │
│ дорогая «умная»  │                │ дешёвая быстрая  │
│ (Opus, GPT-5.1)  │                │ (Haiku, mini)    │
│                  │                │                  │
│ ► один раз       │                │ ► каждый шаг,    │
│ ► разворачивает  │                │   свежее окно    │
│   план в JSON    │                │ ► читает прогресс│
│ ► passes: false  │                │ ► пишет passes:  │
│   для подзадач   │                │   true в Git     │
└──────────────────┘                └──────────────────┘

В исследованиях Anthropic это два профиля:

• Initializer Agent (агент-инициализатор) запускается один раз: разворачивает окружение, создаёт claude-progress.txt, init.sh, формирует JSON-файл требований, где каждой атомарной подзадаче проставлен флаг "passes": false. JSON, а не markdown — потому что модели работают со схемами точнее и реже случайно перезаписывают смежные ветки.
• Coding Agent (агент-исполнитель) запускается на каждом шаге в свежем контекстном окне: читает прогресс, выбирает подзадачу с false, выполняет, тестирует, переключает в true, коммитит в Git.

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

7. Контекст как переменная стоимости

Каждый шаг агента передаёт в модель всю накопленную историю сессии. Стоимость растёт квадратично относительно числа итераций. Поэтому борьба с контекстом — это борьба с бюджетом.

Три стратегии динамического урезания, расположенные по риску потери информации:

Tool-Result Clearing — средний путь между compaction (агрессивная потеря) и context reset (полный сброс). В заметках про context engineering этот рычаг часто пропускают.

Архитектурное правило, которое стоит запомнить: программная обвязка кодирует предположения о недостатках текущей модели, которые быстро устаревают по мере обновления моделей. Пример: Claude Sonnet 4.5 страдал «контекстной тревожностью» — при приближении к лимиту окна модель преждевременно завершала задачи и декларировала успех без тестов. Под это в harness (программная обвязка) добавили жёсткую логику context reset. С переходом на Opus 4.5/4.6 поведение исчезло на уровне весов, а логика сбросов осталась — как технический долг.

Под масштабирование долгоживущих агентов в 2026 закрепилась трёхслойная архитектура Managed Agents:

• Brain — stateless LLM. Не хранит истории; восстанавливает контекст через wake(sessionId) из внешней БД, выбирает срез событий через getEvents(start, end). Это и есть «стабильная утилизация prompt-кэша».
• Hands — одноразовые песочницы (Docker, Python-интерпретатор) с минимальным интерфейсом execute(name, input) → string. Сбой контейнера = обычная ошибка инструмента, оркестратор не падает.
• Session — персистентный append-only лог событий вне контекстного окна.

Метрики эффекта на проде: −60% p50 TTFT, более −90% p95 latency за счёт ленивой инициализации песочниц. Паттерн уже воспроизведён в enterprise — те же три слоя ложатся на стек Azure AI Foundry (Foundry Agent Service → brain, Container Apps Dynamic Sessions → hands, Cosmos DB → session log).

FAQ

Когда повышать reasoning effort, а когда держать минимальным?

Высокое усилие окупается примерно на одной задаче из пяти — там, где есть верифицируемая глубина: сложный код, аудит многопоточного, оптимизация SQL, доказательства, ветвящиеся планы с жёсткими ограничениями. На извлечении сущностей, классификации, шаблонах и саммаризации глубокий reasoning жжёт токены и latency без прироста точности, а в режиме inversion даже снижает его.

Что такое overthinking и как его поймать?

Overthinking — участок кривой, где рост test-time compute не помогает или вредит: модель сомневается в очевидном и переусложняет. Ловится по метрикам — tokens_per_task и loop_iterations растут при неизменной точности. Лечение: снижать budget_tokens/effort под профиль задачи и не включать self-reflection у слабых моделей, где она чаще усугубляет ошибку, чем исправляет.

Как защититься от runaway-агента?

Пятью независимыми слоями одновременно: timeout (async queue вместо синхронного запроса), anti-loop (max_iterations 10–15 плюс стоп «No Progress»), cost circuit breaker на шлюзе ($50 warning / $100 halt), model pinning (фиксированные версии вместо алиасов) и audit log (OpenTelemetry gen_ai.usage.* + session_id). Каждый слой ловит то, что пропустил предыдущий.

Какие метрики мерить у агента вместо RPS?

Классический stateless-мониторинг (RPS, latency, HTTP-ошибки) не видит распределённую транзакцию агента. Собирайте на шлюзе: tokens_per_task (с учётом скрытого reasoning), cost_per_completion, loop_iterations и retry_overhead_tokens. Алертьте при 2× от baseline по любой из них, а не по абсолютному порогу.

Сколько закладывать в бюджет на задачу, сессию и день?

Стартовые порядки величины: задача ~$0.50, сессия ~$2, день ~$10; на уровне cost circuit breaker — $50 warning / $100 halt, per-task ≈ $5. Это калибровочные ориентиры, а не универсальные значения — подстраивайте под свой профиль нагрузки и набор моделей.

Источники

• Anthropic — Managed Agents: трёхслойная архитектура Brain/Hands/Session и метрики latency.
• LangGraph Issue #7554 — jitter поверх max_interval в RetryPolicy.
• Кейсы runaway-стоимости: Uber — бюджет за 4 месяца, $150 за задачу на o1-preview.
• LLM routing: cut costs by 70% without losing quality — экономика каскадного роутинга.
• Turn the thinking knob off most of the time — обзор эффекта overthinking.
• Agent costs with MLflow Gateway — сбор token/cost-метрик на шлюзе.

Числовые ориентиры из текста (15–20× разница цены между tiers, 49.6%→48.1% при росте стоимости на 56%, бюджеты $0.5/$2/$10, −60% p50 / −90% p95) — это порядки величины и значения из конкретных кейсов; на вашем профиле нагрузки они будут другими.

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» — практические ориентиры порядка масштаба, а не данные одного измерения; калибруйте на своём домене.