Как построить управляемый корпоративный runtime агентов
MCP — интерфейс, а не операционная модель
MCP стандартизирует доступ к возможностям. Но корпоративный runtime по-прежнему должен отвечать за идентичность, политики, оркестрацию, доказательства и ответственность.
Model Context Protocol решает важную задачу совместимости: даёт AI-приложениям единый способ обнаруживать и вызывать инструменты, ресурсы и промпты.
Это важнейший строительный блок. Но сам по себе он не является операционной моделью компании.
MCP стандартизирует возможности. Корпоративный runtime должен управлять исполнением.
Граница, которой MCP намеренно не управляет
Представим, что сервер предоставляет инструмент approve_payment. Протокол может описать аргументы и передать вызов. Но компания всё равно должна решить, кто вправе запросить действие, в рамках какой бизнес-цели, с каким лимитом, на основании каких доказательств, с чьим согласованием и как результат изменит состояние организации.
Это не вопросы транспорта. Это вопросы управления и исполнения.
Интерфейс и runtime
Обнаружение, схемы, ресурсы, промпты и стандартизированный вызов инструментов.
Человек, агент, сервис, организация и делегированные полномочия, стоящие за запросом.
Что субъект вправе делать в этом контексте, с какими лимитами и согласованиями.
Зачем нужно действие, как оно связано с планом и что должно произойти до и после него.
Входные данные, решения, результаты инструментов и изменения состояния, обеспечивающие аудит.
Каждому вызову нужен конверт исполнения
Для значимой работы недостаточно передать имя инструмента и аргументы. Runtime должен сформировать конверт исполнения, который сопровождает запрос и остаётся связанным с результатом.
- Идентичность субъекта и делегированная роль.
- Организация, рабочее пространство и граница данных.
- Цель, задача и шаг, обосновывающие действие.
- Класс риска и решение политики.
- Лимиты бюджета, времени, данных и повторных попыток.
- Необходимое согласование и разделение обязанностей.
- Ключ идемпотентности, correlation ID и ссылки на доказательства.
- Ожидаемое изменение состояния и путь отката или компенсации.
MCP-вызов — только часть этого конверта. Операционная система вокруг него решает, должен ли такой вызов вообще существовать.
Шесть контуров управления runtime
1. Реестр возможностей
Обнаружение должно превращаться в управляемый каталог. Для каждой возможности реестр хранит владельца, версию, среду, чувствительность данных, побочные эффекты, стоимость, состояние и разрешённых потребителей.
2. Идентичность и делегирование
Агент не должен автоматически получать все полномочия создавшего его человека. Делегирование задаётся явно, ограничивается областью и временем и может быть отозвано. Runtime определяет и техническую идентичность, и бизнес-роль.
3. Решение и применение политик
Policy engine принимает решение. Точка применения гарантирует, что его нельзя обойти. Для рискованных действий могут потребоваться подтверждение человека, двойной контроль или ограниченная среда исполнения.
4. Оркестрация и состояние
Вызовы инструментов принадлежат устойчивым задачам с владельцами, зависимостями, повторными попытками и результатами. Если процесс остановился, другой субъект должен продолжить его без восстановления намерения из истории чата.
5. Наблюдаемость и доказательства
Логи показывают, что запрос произошёл. Доказательства объясняют, почему он был разрешён, какие входные данные имели значение, что изменилось и как результат связан с бизнес-целью.
6. Оценка и обучение
Успешное выполнение не равно полезному результату. Runtime оценивает качество, стоимость, соблюдение политик и последующие эффекты, а затем предлагает изменения навыков, промптов, маршрутов или контролей.
Классы риска делают автономность практичной
Не каждое действие требует человека. Если относиться ко всем вызовам одинаково, получится либо опасная автономность, либо невыносимая усталость от согласований. Простая классификация делает компромисс явным.
Пример классов действий
Ограниченное извлечение без внешнего эффекта; обычно выполняется автоматически и полностью журналируется.
Черновики, внутренние обновления и безопасно отменяемые действия; автоматическое исполнение в рамках политики.
Внешние коммуникации, расходы, изменение доступа или обязательства; согласование или двойной контроль.
Необратимые, регулируемые или высокорисковые операции; строгая авторизация, доказательства и контролируемое исполнение.
Архитектура, которая масштабируется
Используйте MCP на границе возможностей. Между автономными субъектами и инструментами поставьте корпоративный runtime. Свяжите runtime с задачами, организационной памятью, согласованиями, наблюдаемостью и оценкой результатов.
Так MCP останется простым и переносимым, а компания получит то, что протокол и не должен предоставлять: целостную модель полномочий и ответственности.
Инструмент может быть совместимым, но небезопасным. Runtime превращает совместимость в управляемую работу.
