Глава 1. Почему агенту нужна платформа, а не магия¶

1. Начнем не с магии, а с типичного провала¶

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

Представь обычную историю.

Команда делает агента для внутренней поддержки:

• агент читает письмо клиента;
• находит нужную статью в базе знаний;
• создает тикет;
• при необходимости зовет человека на подтверждение.

На демо все выглядит отлично. Агент быстро отвечает, уверенно выбирает инструменты и кажется почти самостоятельным.

Проблемы начинаются позже:

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

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

Это очень важный момент для всей книги: чаще всего ломается не "ум" модели. Ломается сама инженерная конструкция вокруг нее.

Поэтому эта книга на самом деле не о том, как сделать агента магическим. Она о том, как не дать этой магии развалиться при первом повторе, первом побочном эффекте, первой границе подтверждения, длинном контексте или первом инциденте.

2. Что именно в таких системах обычно отсутствует¶

Когда команда думает про агента как про "LLM плюс несколько инструментов", она почти всегда недостраивает самые дорогие слои:

• явные границы доверия;
• контур управления опасными действиями;
• правила подтверждения;
• идемпотентность и границы отката;
• наблюдаемость по шагам;
• понятный жизненный цикл изменений.

Из-за этого агент сначала выглядит впечатляюще, а потом быстро становится дорогим, хрупким и трудным в сопровождении.

Именно поэтому безопасную агентную систему удобнее мыслить не как одного умного помощника, а как платформу управляемого выполнения.

Это и есть главный тезис книги в самой короткой форме: агентам нужна платформа, а не магия.

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

3. Что Викулин поставил правильно, и чего сегодня уже недостаточно¶

Статья Дмитрия Викулина хорошо ставит стартовый вопрос: из каких блоков вообще состоит надежный агент.¹ Для входа в тему это правильная отправная точка.

Но для промышленной системы списка блоков уже мало. На практике сильные команды довольно быстро переходят к более жесткой инженерной рамке:

• сначала выбирают самый простой исполнимый паттерн;
• опасные действия выносят в отдельный контур управления;
• автономность разрешают только там, где уже есть политики, трассировка и понятная граница отката.²⁶³

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

4. По умолчанию выбирай workflow, а не агента¶

Это один из самых полезных практических принципов во всей теме.

Anthropic довольно прямо разделяет workflows и agents и рекомендует начинать с более простого варианта.² OpenAI приходит к очень похожему выводу: агент оправдан только тогда, когда он покупает реальную полезную гибкость, а не просто делает систему современно звучащей.⁴

Если перевести это на инженерный язык, получится простое правило:

• если путь выполнения известен заранее, пиши workflow;
• если системе нужен ограниченный выбор следующего шага внутри узкого контура, используй single-agent loop;
• если задача естественно делится на независимые подзадачи с разными контекстами и ответственностью, только тогда думай про multi-agent.

Это консервативный совет. И именно поэтому он работает.

Одна из самых полезных практических мыслей у Anthropic состоит в том, что на раннем этапе команде не стоит по умолчанию опираться на фреймворк.² Если задачу уже решают прямой вызов API и небольшой слой оркестрации, то лишняя абстракция почти всегда ухудшает отладку, разбор цепочки подсказок и рабочую ответственность, а не улучшает их.

5. Когда агент действительно нужен¶

Агент начинает быть оправданным не по стилю, а по характеру задачи.

Хорошие признаки такие:

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

А вот признаки в пользу обычного рабочего процесса другие:

• шаги почти всегда одинаковые;
• условия переходов легко формализуются;
• цена ошибки в контуре записи заметная;
• требования к объяснимости и повторяемости очень высокие;
• "свобода агента" звучит красиво, но почти не добавляет пользы.

6. Правила выбора: workflow, single-agent или multi-agent¶

Ниже самая полезная короткая рамка для старта.

В текстовом виде то же правило звучит так: известный путь — workflow; ограниченный выбор следующего шага — single-agent loop; независимые подзадачи с разными владельцами — только тогда multi-agent.

Есть и еще одно практическое правило:

• если ты не можешь в одном абзаце объяснить, зачем здесь нужен именно агент, скорее всего, он пока не нужен;
• если не можешь объяснить, зачем здесь нужен именно multi-agent, он почти наверняка преждевременный.

7. Что команды чаще всего делают неправильно на старте¶

Почти все ранние ошибки повторяются:

• выбирают агента раньше, чем описали нормальный рабочий процесс;
• называют multi-agent любую систему, где просто больше одного шага;
• тащат фреймворк раньше, чем команда может внятно объяснить базовые подсказки, контракты инструментов и пути отказа;
• начинают спорить о подсказке и модели раньше, чем определили границы доверия, подтверждения и наблюдаемость;
• оценивают успех по демо, а не по тому, что произойдет после первого повтора, первого таймаута и первого инцидента.

Если в системе пока нет ответа на эти вопросы, спор о "более умной агентности" почти всегда преждевременный.

8. Почему "магия" ломается раньше, чем кажется¶

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

• длинный контекст;
• внешние системы;
• приватные данные;
• подтверждения;
• разные роли доступа;
• дорогостоящие побочные эффекты.

После этого внезапно выясняется, что главные проблемы уже не в "качестве ответа", а в другом:

• стоимость становится непредсказуемой;
• поведение начинает дрейфовать;
• результаты трудно повторить;
• инциденты трудно расследовать;
• команда больше не уверена, что реально контролирует контур записи.

Вот в этот момент "агент" перестает быть просто LLM с инструментами и превращается в полноценную инженерную систему.

9. Четыре принципа, на которых стоит строить дальше¶

9.1. Контроль важнее автономности¶

Сначала ты строишь предсказуемый путь выполнения. Только потом дозированно добавляешь свободу.

9.2. Безопасность нельзя прикрутить сбоку¶

Если политики, идентичность и подтверждения не встроены в рантайм, потом ты будешь не развивать систему, а чинить архитектуру в аварийном режиме.

9.3. Состояние должно быть явным¶

Длинные задачи не должны терять шаги, подтверждения и побочные эффекты только потому, что кто-то перезапустил процесс или переиграл запрос.

9.4. Наблюдаемость важнее впечатления¶

Если агент "выглядит умным", но у тебя нет трасс, оценок и метаданных по шагам, ты не управляешь системой.⁵⁶

flowchart LR
    A["Запрос"] --> B["Контекст выполнения"]
    B --> C["Политики / подтверждения"]
    C --> D["Путь выполнения"]
    D --> E["Модель / память / инструменты"]
    E --> F["Трассы / оценочные сигналы"]
    F --> G["Выпуск / жизненный цикл"]

10. Что эксплуатационная команда должна видеть всегда¶

Минимально полезный набор очень приземленный:

• какой план построил агент;
• какие инструменты были вызваны;
• какой контекст попал в модель;
• где именно качество деградировало;
• какие подтверждения были запрошены;
• шел ли рантайм по фиксированному рабочему процессу, ограниченному циклу или делегированному многоагентному пути;
• сколько стоил каждый шаг по задержке и токенам.

Как только этот список исчезает из поля зрения, агент начинает превращаться в черный ящик.

11. Что делать сразу после этой главы¶

Если ты проектируешь агентную систему прямо сейчас, начни не с промпта, а с трех вопросов:

1. Где здесь достаточно обычного workflow?
2. Какие действия реально опасны и потребуют отдельного контура управления?
3. Какие сигналы команда должна видеть в первый день эксплуатации?

Если на эти вопросы пока нет ответа, рано обсуждать "уровень автономности". Сначала нужна платформа исполнения.

12. Короткий вывод¶

Если из этой главы запомнить только одну мысль, пусть будет эта:

Хороший агентный продукт начинается не с максимальной автономности, а с предсказуемой платформы, в которой автономность добавляется дозированно.

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

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

13. Что эта глава доказывает¶

Эта глава доказывает не то, что агенты всегда нужны. Наоборот: она показывает, что полезная агентность начинается с ограничения.

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

14. Модель доказательности этой главы¶

Читай утверждения этой главы с разным уровнем уверенности:

• Standards / normative sources: задают ожидание управляемости, аудита и контроля риска, но не готовую схему агента.
• Vendor / platform practice: OpenAI и Anthropic сходятся в том, что начинать лучше с более простой исполнимой формы и добавлять агентность только там, где она дает полезную гибкость.
• Runtime practice: устойчивое выполнение, подтверждения и воспроизводимые трассы — инженерные механизмы, а не метафоры.
• Устойчивые утверждения: рискованные побочные эффекты требуют явных точек контроля; трассы и eval signals нужны для производственной ответственности.
• Быстро меняющаяся область: agent frameworks, SDK и orchestration patterns будут меняться быстрее, чем сам принцип управления.
• Авторская интерпретация: формула platform, not magic — синтез этих практик в одно проектное правило этой книги.

15. Что читать дальше¶

• Часть I. Основания
• Глава 2. Референсная архитектура безопасного агента
• План книги