Глава 2. Референсная архитектура безопасного агента¶

1. Начнем не со слоев, а с одного живого кейса¶

Возьмем того же агента поддержки из первой главы.

Пользователь пишет:

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

Если смотреть на задачу слишком упрощенно, может показаться, что дальше все очевидно:

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

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

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

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

2. Минимальная форма агента и почему ее мало¶

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

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

Практический гайд OpenAI полезен тем, что начинает с очень простой формы: у минимальной агентной системы обычно есть три вещи.³

• model
• tools
• instructions

Это хорошая стартовая рамка. Она полезна тем, что не дает сразу улететь в лишнюю сложность.

Но для эксплуатации этого уже недостаточно. Как только у тебя появляются:

• доступ к внутренним системам;
• приватные данные;
• длинные сессии;
• контур записи;
• подтверждения;
• несколько команд и ролей,

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

Здесь тезис из первой главы получает первое прямое доказательство. Формулы model + tools + instructions достаточно, чтобы прототип выглядел убедительно. Но ее уже недостаточно, чтобы объяснять права, побочные эффекты, ответственность и восстановление, как только система касается реальности.

2.1. Что относится к архитектуре рантайма агента, а что нет¶

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

К архитектуре рантайма агента обычно относятся:

• model;
• instructions;
• tools;
• memory;
• процедуры планирования или навыки;
• runtime;
• защитные правила и политики.

А вот несколько вещей к архитектуре рантайма обычно не относятся:

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

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

3. Как один запрос должен проходить через систему¶

Посмотрим на тот же кейс поддержки уже как на архитектурный путь.

3.1. Входной слой¶

Сообщение не должно сразу попадать в модель. Сначала система превращает его в нормализованный запрос:

• кто пользователь;
• из какого арендатора пришел запрос;
• какой канал входа;
• какой класс риска;
• какая сессия и какой trace_id;
• к какой политике будет привязан этот запуск.

Иными словами, в систему входит не "текст", а управляемый контекст выполнения. Этим слоем закрывается первая группа провалов из главы 1: неясный субъект, неясная область действия и невозможность потом восстановить, что именно система вообще обрабатывала.

3.2. Слой управления¶

Дальше система должна решить, что этому запуску вообще разрешено:

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

Это и есть плоскость управления. Она отвечает не за "ум", а за право системы действовать. Именно здесь снимается один из самых дорогих рисков демо-мышления: путаница между “модель предложила” и “система имеет право сделать”.

3.3. Рантайм¶

Потом запрос попадает в рантайм, где выбирается паттерн выполнения:

• здесь достаточно обычного рабочего процесса;
• здесь нужен single-agent loop;
• здесь нужно прерывание на подтверждение;
• здесь запуск должен сохраниться в контрольной точке и продолжиться позже.

Хороший рантайм выглядит скучно. Он не поражает "магией", а делает ход выполнения предсказуемым. Здесь закрываются провалы вокруг повторов, пауз, перезапусков и длинных путей исполнения.

3.4. Модельный слой¶

Только после этого в дело входит модель:

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

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

3.5. Слой инструментов¶

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

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

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

3.6. Трассировка и оценка¶

На каждом шаге система должна оставлять след:

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

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

4. Теперь можно посмотреть на карту целиком¶

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

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

Ниже уже полезно показать платформу "видом сверху".

flowchart TB
    user["Пользователь / API / событие"] --> interface["Входной слой"]
    interface --> identity["Идентичность и сессия"]
    identity --> control["Плоскость управления агентом"]
    control --> runtime["Оркестрационный рантайм"]
    runtime --> cognition["Модельный слой"]
    runtime --> memory["Память и знания"]
    runtime --> tools["Исполнение инструментов"]
    runtime --> telemetry["Телеметрия и оценки"]
    tools --> external["Внешние системы / MCP / SaaS"]
    memory --> stores["Векторная БД / база знаний / профильная память"]
    control --> approval["Подтверждения / политики / квоты"]
    telemetry --> audit["Трассы / метрики / аудит"]

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

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

5. Пять опор эксплуатационной платформы¶

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

• framework
• model
• tools
• runtime
• trust

Эта рамка полезна по очень практической причине. Она быстро отрезает самообман.

Если у тебя есть только:

• сильная модель;
• хорошая подсказка;
• пара инструментов,

но нет runtime и trust, у тебя еще не платформа. У тебя прототип.

6. Какие архитектурные решения нужно принять явно¶

Уже на ранней стадии полезно принять несколько решений не "по ходу дела", а явно.

6.1. Какие слои контекста существуют¶

Google правильно дисциплинирует сборку подсказки через слои контекста.⁵⁶

Обычно достаточно явно развести:

• static context: роль, политики, разрешенные возможности, фиксированные инструкции;
• session context: то, что живет в рамках сессии;
• turn context: то, что относится только к текущему запросу;
• cached context: то, что стоит подмешивать выборочно.

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

6.2. Где проходит право на действие¶

У модели не должно быть права напрямую исполнять внешний побочный эффект.

Право на действие должно жить в сочетании:

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

Именно поэтому плоскость управления так важна: она отделяет "модель предложила" от "система имеет право сделать".

6.3. Когда делить систему на несколько агентов¶

Практический гайд OpenAI правильно не романтизирует multi-agent как выбор по умолчанию.³ Новое архитектурное руководство Microsoft полезно тем, что делает путь усложнения более явным: сначала команда должна спросить, не остается ли задача обычным прямым вызовом модели, затем достаточно ли одного агента с инструментами, и только потом переходить к многоагентной оркестрации.⁷

Эта дисциплина важна, потому что каждый лишний агент добавляет:

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

Обычно разделение оправдано, когда:

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

Если этих признаков нет, один агент с хорошим графом рабочего процесса почти всегда проще и надежнее.

Практическая лестница усложнения выглядит так:

1. direct model call для одношаговой работы;
2. single agent with tools для одной предметной области с динамическими действиями;
3. multi-agent orchestration только там, где специализация, разделение безопасности или параллельная декомпозиция действительно оправдывают дополнительную сложность рантайма.

Каталог паттернов Anthropic полезен тем, что делает эту лестницу менее абстрактной: он называет промежуточные формы рабочего процесса, которые командам обычно нужны до полной агентной автономности.¹ На практике пропущенный вопрос часто звучит не как «нужен ли нам агент?», а как «какой более маленький паттерн оркестрации уже решает задачу достаточно безопасно?»

Обычно это значит, что сначала стоит проверить такие варианты:

• prompt chaining, если задачу можно разложить на фиксированные последовательные шаги с проверкой между ними;
• routing, если входящие запросы делятся на несколько классов, которым нужны разные подсказки, инструменты или последующие пути;
• parallelization, если уверенность или задержка улучшаются при разнесении независимых проверок;
• orchestrator-workers только тогда, когда подзадачи заранее неизвестны и их нужно делегировать динамически;
• evaluator-optimizer, если итеративная критика действительно улучшает артефакт.

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

Эта лестница полезна тем, что превращает архитектуру в явную дисциплину против переусложнения. Вопрос должен звучать не как "можно ли разбить это на несколько агентов?", а как "какая минимальная форма сложности все еще надежно работает в эксплуатации?"

7. Быстрый тест зрелости для архитектурной сложности¶

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

Более сильная планка такая:

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

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

8. Что нельзя смешивать в одну кучу¶

Есть минимум четыре вещи, которые стоит различать с самого начала:

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

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

9. Минимальный кодовый принцип¶

Если хочется увидеть всю идею в очень сжатом виде, шаблон выглядит так:

from dataclasses import dataclass


@dataclass
class ToolRequest:
    tool_name: str
    actor_id: str
    risk_class: str
    payload: dict


def execute_tool(request: ToolRequest, policy_engine, approval_service, gateway):
    decision = policy_engine.evaluate(request)
    if not decision.allowed:
        raise PermissionError(decision.reason)

    if decision.requires_approval:
        approval_service.require_human_signoff(request, decision)

    return gateway.call(request.tool_name, request.payload)

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

10. Быстрый архитектурный разбор своей системы¶

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

Ты должен уметь внятно ответить на такие вопросы:

• Где запрос превращается в управляемый контекст выполнения?
• Где система решает, что вообще разрешено?
• Какие действия требуют подтверждения и где это принудительно проверяется?
• Какие побочные эффекты идут только через шлюз или песочницу?
• Какие поля гарантированно попадают в трассы?
• Что происходит после повтора, частичного отказа или перезапуска?

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

11. Что нужно вынести из этой главы¶

Если кратко, хорошая агентная платформа держится на нескольких скучных, но очень ценных вещах:

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

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

12. Что делать сразу после этой главы¶

Если ты проектируешь агентную систему прямо сейчас, зафиксируй хотя бы это:

1. Где именно у тебя входной контекст выполнения?
2. Где живет право на действие?
3. Какой паттерн рантайма у тебя выбран первым?
4. Какие побочные эффекты идут только через шлюз?
5. Какие поля команда должна видеть в трассе с первого дня?

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

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

Эта глава соединяет несколько типов доказательности:

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

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

• Глава 1. Почему агенту нужна платформа, а не магия
• Часть II. Контур безопасности
• Глава 3. Контур безопасности и границы доверия