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

1. С чего обычно начинается ошибка¶

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

взять сильную модель;
подключить пару tools;
написать амбициозный prompt;
и посмотреть, насколько “самостоятельным” получится агент.

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

2. Что хорошо подметил Викулин, и чего уже недостаточно¶

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

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

сначала выбирается самый простой исполнимый паттерн;
опасные действия выносятся в отдельный control plane;
автономность допускается только там, где уже есть policy, telemetry и rollback boundary.²⁵³

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

3. Workflow по умолчанию, агентность по необходимости¶

Anthropic довольно прямо разделяет workflows и agents и рекомендует начинать с более простого варианта.² Это один из самых полезных практических принципов во всей теме.

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

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

Это скучный совет, но он работает удивительно хорошо.

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

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

непредсказуемая стоимость;
дрейф поведения;
слабая auditability;
плохая повторяемость результатов;
сложность расследования инцидентов.

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

длинный контекст;
внешние системы;
приватные данные;
approvals;
разные роли доступа,

и система резко перестает быть “просто LLM с инструментами”.

5. Четыре принципа, на которые стоит опираться¶

5.1. Контроль раньше автономности¶

Сначала ты строишь predictable path, а уже потом расширяешь свободу агента.

5.2. Безопасность не может жить сбоку¶

Если policy, identity и approvals не встроены в runtime, потом ты будешь чинить архитектуру не эволюционно, а аварийно.

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

Долгие задачи не должны терять шаги, approvals и side effects просто потому, что кто-то перезапустил процесс.

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

Если агент “выглядит умным”, но у тебя нет traces, evals и step metadata, то ты просто не управляешь системой.⁴⁵

6. Что production-команда должна видеть всегда¶

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

какой план построил агент;
какие инструменты были вызваны;
какой контекст был подан в модель;
где именно качество деградировало;
сколько стоил каждый шаг по latency и tokens.

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

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

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

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

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