Три соседние заметки про одно и то же с разной высоты 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).
Граница между заметками проходит по вопросу, а не по теме: здесь — из чего рантайм состоит, там — что из этого берут готовым и по какому протоколу к нему подключаются.
Развилка «строить или встроить» решается не целиком, а по слоям. Оркестрационный рантайм, исполнение инструментов и телеметрия — то, что чаще берут готовым: они дороги в разработке и одинаковы у всех. Идентичность, плоскость управления и знания остаются своими: они выражают правила конкретной организации, и обвязка их не знает.
Что нельзя смешивать в одну кучу
Четыре сущности, которые в маленькой системе кажутся одним, а после первого инцидента оказываются разным:
- краткосрочное состояние — текущее состояние выполнения;
- долгосрочная память — факты, профили, эпизоды;
- поиск — доступ к внешним знаниям;
- исполнение инструментов — реальные действия во внешнем мире.
Практическая проверка различия: у каждой из четырёх свой ответ на вопрос «что произойдёт при перезапуске процесса» — и если ответ одинаковый, значит их действительно смешали.
Агент подаёт заявку, а не запускает
Строка «оркестрационный рантайм» в таблице выше про повторы и перезапуски. У неё есть вторая половина, которая проявляется, как только агентов становится несколько, а их работа — дорогой: кто именно порождает процессы и занимает ресурсы.
Устройство, к которому это сходится: агент подаёт заявку на работу, а запуск, выбор устройства, окружение процесса, повтор при инфраструктурном сбое и освобождение ресурса принадлежат одному компоненту. Не потому, что агенту нельзя доверять, а потому, что арифметика ресурсов сходится только там, где четыре факта видны одновременно:
- какая работа подана;
- какая попытка допущена к запуску;
- какая группа процессов и какое физическое устройство ей выделены;
- когда выделение освобождено.
Разнесённые по агентам, эти четыре факта не сходятся никогда: каждый видит свой запуск и не видит соседних, и совокупная нагрузка становится величиной, которую никто не знает.
Что при этом остаётся у агента. Компонент допуска решает, когда работа пойдёт, и не решает, какая: выбор гипотезы, содержание задачи и её научная или предметная осмысленность остаются снаружи. Смешение этих двух ролей — типовая ошибка: планировщик, начинающий отбрасывать заявки по существу, превращается в невидимого редактора замысла.
Неизвестное потребление трактуется консервативно. Заявка, у которой спрос на ресурс не измерен, получает эксклюзивное размещение, а не средний профиль (Unknown Not A Value). И профили не подменяются молча: заявка, отправленная под несуществующий профиль, отвергается, а провалившаяся работа не переносится автоматически на другой класс устройств — иначе результат окажется получен не в тех условиях, в которых заявлен.
Что не относится к рантайму
Граница, которую команды регулярно размывают:
- обучающий набор и модель вознаграждения — это разработка модели, а не рантайм;
- пользовательский интерфейс — продуктовая поверхность, а не ядро агентной логики;
- контекстное окно — свойство выбранной модели, а не самостоятельный слой архитектуры (Context Window).
Различие практическое: если деградирует маршрутизация инструментов, путь подтверждения или дисциплина поиска, причина живёт в контуре рантайма, и искать её в интерфейсе или в выборе модели бесполезно.
Для эксперимента runtime хранит происхождение исполнения
Исследовательский агент не должен сам пересказывать, какой код он якобы запустил. Платформа связывает run с immutable source archive или commit, effective command, environment, parent experiment и первичными logs. Тогда результат можно воспроизвести и отличить от вывода модели о результате.
OpenResearch реализует запуск из committed snapshot и сохраняет commit_sha, но часть научных инвариантов оставляет инструкциям: skill запрещает менять runner у потомка и переписывать answered node, тогда как API допускает explicit child run_command, а Git-ветка остаётся изменяемой. Для Autoresearch Experiment Trees это граница платформы: критические условия сопоставимости должны отклоняться кодом или явно создавать новую линию эксперимента, а не зависеть от послушания модели.
Что эксплуатационная команда должна видеть всегда
Минимальный набор, при исчезновении которого агент превращается в чёрный ящик: какой план построил агент, какие инструменты были вызваны, какой контекст попал в модель, где деградировало качество, какие подтверждения запрашивались, по какому паттерну шёл рантайм и сколько стоил каждый шаг.
Связано с
- Agent Harness — переиспользуемая часть этих слоёв и протокол, которым к ней подключаются
- Agent Control Plane — слой, где живёт право на действие
- Agent Architecture — сборка самого цикла внутри рантайма
- Agent Anatomy — из каких компонентов состоит ядро
- Agent Identity — субъекты, к которым привязан запуск
- Context Layers — дисциплина сборки контекста
- Tool Gateway — граница исполнения
- Agent Audit Log — что остаётся после запуска
- Agent vs Workflow — как выбрать минимально достаточную форму исполнения
- Durable Execution — живучесть выполнения при перезапусках
- Batch Close Protocol — как компонент допуска участвует в закрытии пачки: заморозка приёма вместо остановки
- Agent CostControl — вторая причина держать допуск в одном месте: совокупная стоимость видна только там
- Autoresearch Experiment Trees — commit-addressed runs, experiment lineage и run contract для исследовательского цикла