Зачем нужна эта книга¶

Материалов про ИИ-агентов уже много. Гораздо меньше материалов, которые рассматривают агентную систему как то, что нужно проектировать, ограничивать, выпускать, расследовать и поддерживать в промышленной эксплуатации.

Эта книга нужна, чтобы закрыть именно этот разрыв.

Канонические сценарии книги

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

Чем она не является¶

Это не:

руководство по одному фреймворку;
гайд по продукту конкретного вендора;
сборник промптов;
экскурсия по бенчмаркам и AI-новостям;
проверочный список безопасности без архитектурной модели.

Что она пытается сделать¶

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

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

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

В сравнении с документацией фреймворков¶

Документация полезна, когда ты уже понимаешь, какую систему хочешь собрать. Она хорошо объясняет сценарии оркестрации, графы состояний, работу с SDK и детали интеграции.

Но она редко отвечает на вопросы такого класса:

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

Эта книга пытается стоять над фреймворками, а не спорить с ними.

В сравнении с документацией поставщиков¶

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

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

В сравнении с подходом “проверочный список безопасности”¶

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

Эта книга пытается сделать именно это.

Какой результат задуман¶

После книги читатель должен:

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

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