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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Правила выбора: рабочий процесс, одиночный агентный цикл или многоагентная схема¶

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

Печатная рамка выбора¶

Начинай с наименее динамичной формы, которая безопасно решает задачу.

Рабочий процесс¶

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

Одиночный агентный цикл¶

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

Многоагентная схема¶

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

Печатная схема выбора:

1. Если путь известен, выбери рабочий процесс.
2. Если нужен ограниченный выбор следующего шага, выбери одиночный агентный цикл.
3. Если подзадачи независимы и у них разные владельцы, только тогда переходи к многоагентной схеме.

Текстовая формула выбора: известный путь — рабочий процесс; ограниченный выбор следующего шага — одиночный агентный цикл; независимые подзадачи с разными владельцами — многоагентная схема только после доказанной необходимости.

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

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

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

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

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

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

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

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

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

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

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

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

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. Где здесь достаточно обычного рабочего процесса?
2. Какие действия реально опасны и потребуют отдельного контура управления?
3. Какие сигналы команда должна видеть в первый день эксплуатации?

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

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

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

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

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

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

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

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

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

14. Проверяемые утверждения главы¶

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

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

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

• Стандарты и нормативные источники: задают ожидание управляемости, аудита и контроля риска, но не готовую схему агента.
• Практика поставщиков и платформ: OpenAI и Anthropic сходятся в том, что начинать лучше с более простой исполнимой формы и добавлять агентность только там, где она дает полезную гибкость.
• Практика среды исполнения: устойчивое выполнение, подтверждения и воспроизводимые следы выполнения — инженерные механизмы, а не метафоры.
• Устойчивые утверждения: рискованные побочные эффекты требуют явных точек контроля; следы выполнения и оценочные сигналы нужны для производственной ответственности.
• Быстро меняющаяся область: агентные программные каркасы, инструментальные наборы и шаблоны оркестрации будут меняться быстрее, чем сам принцип управления.
• Авторская интерпретация: формула «платформа, а не магия» — синтез этих практик в одно проектное правило этой книги.

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

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