Пределы наблюдения
Системами агентов обычно управляют, наблюдая за ними. Эмитируются трейсы, строятся дашборды, задаются пороги и устанавливается дежурство. Это полезно, но это другое свойство, нежели контроль. Дашборд наблюдает уже совершённое действие. К моменту, когда панель краснеет, вызов инструмента уже выполнен, запись уже применена, а внешний побочный эффект уже произошёл. Лучшее, что может сделать стек мониторинга, — сократить интервал между ущербом и его обнаружением.
Наблюдение также зависит от полноты телеметрии. Если обёртка инструмента забывает эмитировать событие, если путь повторной попытки обходит инструментированный клиент или если новая интеграция поставляется без декоратора трассировки, дашборд молчит именно для тех действий, которые поняты хуже всего. Пробелы в покрытии телеметрии распределены неравномерно; они сосредоточены вокруг самого нового и наименее проверенного кода, где и концентрируются инциденты.
Наблюдаемый агент с широкими правами — всё ещё агент с широкими правами. Наблюдаемость не сокращает множество достижимых состояний. Она добавляет камеру в комнату, которая остаётся незапертой. Именно модель прав определяет, что возможно; дашборд определяет лишь то, что замечено.
Пороги оповещений вносят дополнительное искажение. Пороги настраиваются для снижения шума, а значит, настраиваются на терпимость к определённой частоте аномалий низкого уровня. Это разумный операционный компромисс для обнаружения, но неверный инструмент для предотвращения. Политика, которая срабатывает, когда чувствительная операция происходит больше заданного числа раз за интервал, — это политика, допускающая первые несколько вхождений. Предотвращение требует решения до первого вхождения, а не ограничения частоты после него.
Практическое следствие в том, что управление, выраженное только как мониторинг, тяготеет к одному и тому же режиму отказа: система хорошо понята в совокупности и не ограничена в конкретном. Совокупный взгляд действительно ценен для анализа ёмкости, стоимости и качества. Но это не поверхность контроля.
Кодирование инвариантов
Альтернатива — выражать политику как предусловия, проверяемые на границе, где намерение агента становится действием: на вызове инструмента. Каждая возможность агента достижима через какой-то интерфейс инструмента, и этот интерфейс — самая узкая точка, в которой можно обеспечить соблюдение решения. Если проверка происходит там, она происходит для каждого вызывающего, включая тех, кто был добавлен после написания политики.
Предусловие — это предикат над предлагаемым вызовом и окружающим контекстом. Оно может ссылаться на аргументы, идентичность запрашивающего агента, сессию, затрагиваемый ресурс и состояние среды. Примеры формы, а не конкретного содержания, включают: целевой ресурс должен находиться внутри пространства имён из белого списка; операция должна быть чтением, когда сессия не повышена; полезная нагрузка не должна содержать поле, помеченное как ограниченное; вызов должен сопровождаться действительным токеном одобрения, выданным отдельным рабочим процессом.
Типизированные схемы делают это принудительно соблюдаемым, а не благим пожеланием. Если входные данные инструмента описаны схемой с обязательными полями, перечислимыми значениями и ограниченными типами, то некорректный вызов терпит неудачу на этапе разбора, до запуска любого обработчика. Поведение «при сбое — отказ» следует из схемы, а не из защитного кода внутри обработчика. Агент, который выдаёт правдоподобный, но не соответствующий политике аргумент, не достигает побочного эффекта; он получает структурированный отказ и должен решить, что делать дальше.
Конкретный механизм выглядит так. Среда выполнения агента не вызывает инструменты напрямую. Она вызывает шлюз политики со структурированным запросом:
{
"agent": "research-worker-3",
"session": "s-8841",
"tool": "documents.write",
"arguments": {"collection": "contracts", "document_id": "c-2210", "body": "..."},
"context": {"approval": null, "elevated": false}
}
Шлюз вычисляет пакет политик — версионированный набор правил с детерминированным вычислителем. Вычисление возвращает решение, код причины и версию политики. Только при разрешении шлюз вызывает нижележащий инструмент. Отказы возвращаются агенту как обычные результаты инструмента, чтобы агент мог адаптироваться без необходимости для среды выполнения особым образом обрабатывать ошибки.
Здесь важны два свойства. Во-первых, движок политик находится вне контекста модели. Это не промпт, не системное сообщение и не документ, который агент может извлечь. С ним нельзя спорить, его нельзя пересказать и обойти последующей инструкцией. Единственное влияние модели на решение — это содержание запроса, который она подаёт. Во-вторых, решение детерминировано при заданных запросе и версии политики. Один и тот же вызов, вычисленный дважды против одного и того же пакета, даёт один и тот же результат, что и делает решение объяснимым после факта.
Честный компромисс в том, что это переносит сложность, а не устраняет её. Каждая новая возможность требует записи в политике, и каждое изменение политики — это изменение производственного поведения, требующее проверки. Шлюз на пути запроса добавляет задержку и новый режим отказа: если шлюз недоступен, правильное поведение по умолчанию — отказ, а значит, сбой уровня политики становится сбоем возможностей агента. Команды, принимающие этот шаблон, обычно соглашаются на эту цену, потому что альтернатива — сбой, который беззвучен и неограничен. Обмен — доступность возможностей на их ограниченность.
Есть второй компромисс, который стоит назвать. Строгие схемы и узкие белые списки сокращают пространство действий, которые может предпринять агент, что может снизить его полезность на задачах, которые не были предусмотрены. Средство смягчения — не ослаблять границу, а делать изменения политики быстрыми и проверяемыми, чтобы граница могла двигаться осознанно, а не быть б
rver-rack-closeup-2ef8e4-33fefc.jpg)
Контроль, который нельзя подтвердить доказательствами, — это контроль, который будет поставлен под сомнение. Каждое решение политики, как разрешение, так и отказ, должно эмитировать запись, достаточную для реконструкции рассуждения без доступа к живой системе. Эта запись включает запрос, решение, код причины, версию политики и подпись над канонической сериализацией решения.
Подпись важна по конкретной причине: она делает запись защищённой от подделки и относимой к точке обеспечения соблюдения, а не к конвейеру логирования. Строку журнала можно отредактировать, удалить или переупорядочить. Подписанную запись решения можно проверить независимо, а пропуск в последовательности обнаружим.
Сохранение версии политики вместе с решением — это то, что делает прошлое поведение повторно объяснимым. Политики меняются. Решение, верное при одном пакете, может быть неверным при следующем. Без версии аудитор, рассматривающий историческое действие, вынужден угадывать, какие правила действовали. С версией тот же вычислитель можно воспроизвести против записанного запроса и точно воспроизвести решение. Это превращает аудит из интервью в проверку.
Отказы заслуживают такого же хранения, как и разрешения. Отказ — доказательство того, что граница работала. Это также первичный сигнал для настройки политики: отказ, который постоянно срабатывает против законной работы, указывает на слишком широкое правило, а отказ, который никогда не срабатывает в классе сессий, может указывать на недостижимое правило. Сохранение обеих сторон делает поверхность политики наблюдаемой, не делая её совещательной.
Последний элемент — тестирование изменений политики против записанных трейсов до развёртывания. Если решения записываются вместе с их запросами, то кандидатный пакет политик можно вычислить офлайн против корпуса реальных исторических вызовов. Результат — дифф: какие ранее разрешённые вызовы теперь были бы отклонены и какие ранее отклонённые вызовы теперь были бы разрешены. Этот дифф проверяем теми же людьми, которые проверяют политику, и он превращает изменение политики из акта суждения в акт измерения. Он также выявляет случаи, которых никто не предусмотрел, — а именно там обычно и живут регрессии политики.
В этом практическая разница между наблюдаемостью и управлением. Наблюдаемость создаёт запись о том, что произошло. Управление создаёт границу, ограничивающую то, что может произойти, плюс запись решений границы, которую можно независимо проверить. Первое необходимо для эксплуатации системы. Второе необходимо для делегирования ей полномочий.
Что это означает для проектирования систем
Рассматривайте границу инструментов как плоскость управления. Поместите вычислитель политик вне досягаемости модели. Сделайте схему первой линией защиты и позвольте некорректным вызовам терпеть неудачу с отказом. Эмитируйте подписанные решения для обоих исходов и сохраняйте прикреплённую версию политики. Воспроизводите кандидатные политики против записанного трафика до того, как они попадут в производство.
Ничто из этого не заменяет наблюдаемость. Трейсы, метрики и дашборды остаются способом понимать и улучшать систему. Меняется порядок: граница решает, запись доказывает, дашборд объясняет. Система, управляемая таким образом, не зависит от того, что модель выберет правильно. Она зависит от того, что модель не может выбрать иначе.