Agent Execution Platform

Взгляд на агентную систему как на платформу управляемого выполнения, а не как на одного умного помощника. Тезис в самой короткой форме: агенту нужна платформа, а не магия — предсказуемый путь исполнения, в который автономность добавляется дозированно.

Три соседние заметки про одно и то же с разной высоты Agent Anatomy — из чего агент состоит (четыре компонента). Agent Architecture — как собрать надёжный цикл своими руками, слой за слоем, в одном процессе. Эта заметка — что должно окружать этот цикл, когда у системы появляются права, арендаторы, подтверждения и расследования.

Почему минимальной формы не хватает

Минимальная агентная система — это model + tools + instructions. Как стартовая рамка она полезна: не даёт улететь в лишнюю сложность. Она перестаёт быть архитектурой ровно в тот момент, когда появляются доступ к внутренним системам, приватные данные, длинные сессии, контур записи, подтверждения и несколько ролей.

Формулировка, которая отделяет прототип от платформы: сильная модель, хорошая подсказка и пара инструментов — это ещё не платформа, если нет рантайма и доверия. Пять опор эксплуатационной платформы: framework, model, tools, runtime, trust.

Атрибуция не подтвердилась Книга приписывает эту рамку материалам Google Cloud. Веб-сверка 2026-08-23 такой рамки у Google не нашла: их платформа агентов организована вокруг четырёх опор — Build, Scale, Govern, Optimize. Сама пятёрка как инженерная формулировка полезна и вывод про «нет рантайма и доверия — значит прототип» остаётся в силе, но ссылаться на неё как на рамку Google нельзя.

Восемь слоёв и вопрос отказа, который закрывает каждый

Смысл слоя не в красоте схемы, а в том, какой конкретный отказ он предотвращает:

Слой Что закрывает
Входной слой Смешение каналов (чат, API, вебхуки, события) с логикой исполнения
Идентичность и сессия Поломку прав доступа, аудита и изоляции арендаторов (Agent Identity)
Плоскость управления Действие без реальной управляемости (Agent Control Plane)
Оркестрационный рантайм Развал выполнения при первом повторе, паузе или перезапуске
Модельный слой Возвращение модели в положение «центра мира»
Память и знания Бесконтрольное разрастание контекста (Context Layers)
Исполнение инструментов Слишком большой радиус поражения и контур записи внутри модели (Tool Gateway)
Телеметрия и оценки Невозможность измерить качество и расследовать сбой (Agent Audit Log)

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

Как называется переиспользуемая часть этих слоёв

Восемь слоёв выше описаны так, как если бы их собирали самостоятельно. На практике часть из них поставляется готовой, и у этой части есть имя — harness, исполнительная обвязка (Agent Harness).

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

Развилка «строить или встроить» решается не целиком, а по слоям. Оркестрационный рантайм, исполнение инструментов и телеметрия — то, что чаще берут готовым: они дороги в разработке и одинаковы у всех. Идентичность, плоскость управления и знания остаются своими: они выражают правила конкретной организации, и обвязка их не знает.

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

Четыре сущности, которые в маленькой системе кажутся одним, а после первого инцидента оказываются разным:

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

Практическая проверка различия: у каждой из четырёх свой ответ на вопрос «что произойдёт при перезапуске процесса» — и если ответ одинаковый, значит их действительно смешали.

Что не относится к рантайму

Граница, которую команды регулярно размывают:

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

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

Что эксплуатационная команда должна видеть всегда

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

Связано с

  • Agent Harness — переиспользуемая часть этих слоёв и протокол, которым к ней подключаются
  • Agent Control Plane — слой, где живёт право на действие
  • Agent Architecture — сборка самого цикла внутри рантайма
  • Agent Anatomy — из каких компонентов состоит ядро
  • Agent Identity — субъекты, к которым привязан запуск
  • Context Layers — дисциплина сборки контекста
  • Tool Gateway — граница исполнения
  • Agent Audit Log — что остаётся после запуска
  • Agent vs Workflow — как выбрать минимально достаточную форму исполнения
  • Durable Execution — живучесть выполнения при перезапусках