Часть I. Основания¶
Первая часть отвечает на вопрос, от которого зависит, будет ли иметь смысл вся остальная книга: как должна выглядеть современная архитектура безопасного агента, если проектировать ее не как игрушку, а как платформенный продукт?
Короткий маршрут по первой части
Если времени мало, пройди этот путь:
- Глава 1: понять, нужен ли здесь вообще агент, а не обычный рабочий процесс;
- Глава 2: провести один запрос через референсную архитектуру;
- Часть II: увидеть, где проходят настоящие границы доверия.
Этого уже достаточно, чтобы обсуждать систему как инженерный контур, а не как идею.
Что решает эта часть¶
- Она объясняет, почему агент не равен LLM и почему LLM принимает только часть решений.
- Она показывает, почему безопасность нельзя прикрутить после MVP: она должна жить внутри рантайма.
- Она утверждает, что большинству эксплуатационных сценариев полезнее не максимальная автономия, а правильная связка
workflow + guarded autonomy. - Она задает многоагентный дизайн как решение про контроль и владение, а не как вопрос эстетики.12
- Она тихо подготавливает весь дальнейший маршрут читателя: границы доверия, дисциплину памяти, контракты исполнения, сбор доказательств, бюджеты здоровья, контуры суждения, владение, воплощение рантайма и управление жизненным циклом.
Быстрый self-check перед переходом дальше¶
Перед переходом к периметру безопасности читатель уже должен уметь ответить на четыре базовых вопроса о своей системе:
- почему здесь нужен именно агент, а не просто рабочий процесс;
- где на самом деле живет право на действие;
- какие слои обязательны до первого рискованного контура записи;
- что пока должно оставаться одноагентным, а какие сигналы позже оправдают разделение.
Если ответы на эти вопросы пока расплывчаты, к первой части стоит возвращаться как к рабочей рамке, а не только как к введению.
Что ты должен вынести из этой части¶
К концу первой части у читателя должны быть:
- референсная схема платформы безопасных агентов;
- критерии, когда агент действительно нужен, а когда лучше выбрать рабочий процесс;
- критерии выбора между рабочим процессом, одним агентом и подагентами;
- список обязательных слоев, без которых система будет хрупкой;
- язык, на котором можно обсуждать архитектуру с platform-, security- и product-командами.
В этой части¶
- Глава 1. Почему агенту нужна платформа, а не магия
- Глава 2. Референсная архитектура безопасного агента Эта глава продолжает тот же кейс поддержки из главы 1 и показывает, как один запрос проходит через слои платформы.
- Практика. Инструкции, сценарии и шаблоны запросов
- Практика. Координатор и передача управления
- Почему выбран этот стек публикации
- Библиография и ссылки
Куда она ведет дальше¶
После первой части у читателя уже должна быть рабочая рамка: оправдан ли здесь агент, как выглядит базовая платформа и где начинаются настоящие границы доверия.
Из этого естественно рождается следующий вопрос: если эта архитектура настоящая, где именно она становится опасной? Следующий логический шаг — Часть II, где тот же запрос пересекает периметр безопасности, шлюз инструментов и границу подтверждения.
Дальше книга расширяет тот же аргумент по порядку:
- Часть II находит границы доверия и действия;
- Часть III делает память частью операционной модели;
- Часть IV превращает исполнение в контракты и управляемое использование инструментов;
- Часть V вводит сбор сигналов, здоровье и суждение;
- Часть VI назначает владение;
- Часть VII превращает модель в исполнимую структуру;
- Часть VIII управляет системой через изменения, реакцию, доказательства и ответственность.