Большинство статей об ИИ-агентах разбирают один слой — как агент думает. Промпт-чейнинг, роутинг, оркестратор-воркеры, ReAct, plan-and-execute. Про это написано много и хорошо. Но инциденты, которые реально происходят на практике, — не про неправильно выбранный паттерн оркестрации. Они про то, что агенту позволили сделать то, что никто не разрешал.
Служба поддержки с доступом на чтение к базе заказов перешла с SELECT на DELETE после того, как клиент написал «спишите двойную оплату». Агент оплатил счёт на 4200 долларов, был перезапущен во время выполнения — и оплатил его снова при повторе. Это не сбой рассуждений. Модель в каждом из этих случаев сделала то, что выглядело разумно. Это архитектурные провалы, и живут они в двух слоях, которые обычно лежат под фреймворком.
Три слоя агента
У агента три слоя. Первый — фреймворк: как агент думает. Второй — harness (обвязка): как агент действует. Третий — governance: что агенту вообще разрешено делать. Второй и третий в литературе почти не покрыты.
| Слой | Решает | Примеры | Описано? |
|---|---|---|---|
| Фреймворк | как агент думает | LangGraph, CrewAI, Agent Framework | Да, много |
| Harness | как агент действует | цикл, бюджеты, песочницы, уплотнение контекста, ретраи | Едва |
| Governance | что агенту разрешено | политики, идентичность, согласования, аудит, редактирование вывода | Едва, и обычно как маркетинг вендора |
Агент = модель + обвязка. Модель предлагает, обвязка располагает. Вызов инструмента — это запрос, а не действие. Всё, что превращает этот запрос в безопасное действие, живёт за пределами модели.
Что такое harness
Если отбросить фреймворк, у агента остаётся несколько точек, в которые можно вмешаться. На практике их пять:
| Точка | Что вешается |
|---|---|
| before_model | сжатие контекста, инъекция памяти, проверка бюджета |
| after_model | защита вывода, проверка цитат |
| before_tool | брокер привилегий, шлюз согласования, идентичность, бюджеты, песочница — возвращает ALLOW / DENY / PAUSE |
| after_tool | редактирование, карантин недоверенного контента |
| on_event | аудит, учёт стоимости, предохранители |
В продакшене эти стыки уже есть под другими именами: Microsoft Agent Framework называет их middleware, LangGraph — обёртки узлов и interrupt, Claude Code — hooks. Если в вашем фреймворке такие точки существуют, все паттерны переносятся. Если нет — это диагноз.
Пять правил, которые делают почти всю работу
- Вызов инструмента — это запрос, а не действие. Модель никогда ничего не исполняет. Если декоратор инструмента в вашем фреймворке вызывает функцию напрямую, у вас нет границы управления. Есть надежда.
- Fail closed. Незарегистрированный инструмент, отсутствующая политика, неизвестный токен, исчерпанный бюджет — всё это означает отказ. Регистрация — не авторизация.
- Отказ должен быть виден модели. Отклонённый вызов возвращается как результат инструмента: DENIED by policy: причина. Тогда агент может перепланировать: пойти к человеку, попробовать другой путь или честно признать неудачу. Молчаливый отказ превращает агента в стопор или фантазёра.
- Политика в коде, а не в промпте. «Ты не должен менять данные клиентов» в системном промпте — это рекомендация. Модель под давлением её игнорирует, а при промпт-инъекции ей прямо приказывают её игнорировать. Детерминированная проверка не подлежит обсуждению.
- Самый строгий контроль побеждает, а порядок срабатываний влияет на стоимость, а не на безопасность. Если контроли конфликтуют, DENY побеждает PAUSE, PAUSE побеждает ALLOW. Порядок определяет лишь то, сколько вы потратите до отказа и насколько внятным будет сообщение об ошибке.
18 паттернов: что уже готово
В репозитории проекта — 18 паттернов, разделённых на две группы: governance (11) и harness (7). Каждый оформлен как обычный Python-хук, который монтируется — без изменений — и в LangGraph, и в Microsoft Agent Framework. Тесты проверяют, что сообщения об отказе идентичны байт в байт, потому что они приходят из одного и того же кода. Паттерны портируются. Фреймворк — это сантехника.
| Паттерн | Предотвращает |
|---|---|
| Identity Propagation | путаницу ролей, когда один сервисный аккаунт обладает правами всех |
| Tool Privilege Broker | использование разрешённого инструмента неразрешённым способом |
| HITL Approval Gate | необратимые действия без согласования с человеком |
| Cost & Tool Budgeting | бесконечный цикл, о котором вы узнаёте из счёта |
| Durable Execution | повторную оплату из-за ретрая |
| Sandboxed Execution | выход агентского кода за пределы рабочей области |
С чего начать
Не нужно внедрять все 18. Для низкорискового бота, который читает документацию, хватит двух. Если агент касается системы записи — начните с Identity Propagation и Privilege Broker. Если у него есть цикл без явного ограничения — с бюджетирования. Это отправные точки, а не обязательный набор.
Где проходит граница
Настоящее корпоративное управление включает управление API, сетевые политики, облачный IAM, управление секретами и центр мониторинга. Ничто из этого не помещается в репозиторий. «Полный AI-гоvernance» как библиотека — это подмножество с уверенным брендом.
То, что реально нужно агенту, — часть, принадлежащая его собственному дизайну: точки, где политика встречается с циклом, решения, которые принимаются на код-ревью, а не в Terraform. Там, где паттерну нужна инфраструктура, это говорится прямо: Python-функция — не изоляция, контейнер — изоляция. Аудит становится доказательством только тогда, когда корень цепочки публикуется там, куда агент не может дотянуться.
Если у вашего агента есть инструменты, есть и архитектурный долг. Он сводится к одному вопросу: кто решил, что агент может выдавать возвраты, и что мешает ему выдать тот, который не должен? Ответ на этот вопрос и есть два недостающих слоя.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.