С чего начать¶

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

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

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

Эта страница нужна для одного: быстро выбрать маршрут чтения.

Если читать только одно¶

Если нужен самый короткий вход в идею книги, прочитай Главу 1. Почему агенту нужна платформа, а не магия.

Там формулируется главный тезис: производственную агентную систему нельзя строить как “модель плюс набор инструментов”. Ее приходится проектировать как управляемую операционную систему.

Что это за книга¶

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

Маршрут на 30 минут¶

Если времени мало, пройди этот путь:

После этого маршрута у тебя уже должна сложиться рабочая рамка:

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

Если хочешь идти по сквозному кейсу

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

Канонические маршруты сценариев

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

Маршруты по ролям¶

Если ты инженер продукта¶

Этот путь нужен, чтобы быстро перейти от идеи агента к рабочей архитектуре.

Если ты платформенный инженер¶

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

Если ты инженер по безопасности¶

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

Если ты руководитель или архитектор¶

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

Если хочешь сразу код и артефакты¶

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

Это полезно, если тебе сразу нужны скелет среды исполнения, контракты политик, путь памяти, телеметрия и артефакты раскатки.

Если нужно быстро решить конкретную задачу¶

Безопасное выполнение инструментов¶

Память и извлечение¶

Наблюдаемость, оценки и раскатка¶

Главная линия схем безопасного агента¶

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

Что открыть рядом с книгой¶

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