От Anthropic Cores к 4 слоям: Enterprise AI Harness на open source

О том, как сделать агента, написано много. О том, как развернуть его в production — гораздо меньше. Пока нет даже общего языка, что конкретно считать harness, где проходят границы, где еще harness, а где уже нет. Какие слои обязательны, а без каких можно обойтись. Эта статья не закрывает вопрос, а предлагает одну из возможных рамок для обсуждения.

Что получилось

Reference architecture для self‑hosted Enterprise AI Harness на Kubernetes. Четыре функциональных слоя и основные точки интеграции между ними.

На схеме четыре слоя: Input, Agent Loop, Execution и Identity, Policy & Audit, каждый из которых разобран ниже. Поверх них два сквозных условия, которые не укладываются в один слой: multi‑tenancy (изоляция тенантов живёт и в runtime, и в данных) и Kubernetes‑native deployment (это контекст развёртывания, не слой harness).

Это результат разбора модели Anthropic, CNCF‑проектов и MCP‑экосистемы и сведения десятков компонентов в единую рабочую схему. Не продукт, не framework: архитектурная модель, которую можно собрать из open source‑компонентов.

Почему это вообще сложно

По отдельности большинство этих проектов хорошо документированы. kagent поднимает агента, LiteLLM маршрутизирует модели, FastMCP отдаёт инструменты, Keycloak выпускает токены. Каждый делает своё дело.

Сложность начинается на границах между ними. Как протащить identity от пользователя до MCP‑вызова (Model Context Protocol)? Где заканчивается runtime агента и начинается execution? Что делать с capabilities, которые живут локально в pod, и с инструментами, доступ к которым идёт по сети? Как изолировать tenant runtime и при этом не сломать A2A между агентами?

Ответы на эти вопросы, а не выбор ещё одного фреймворка, сформировали архитектуру ниже.

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

Anthropic Cores

Anthropic описывают harness как runtime для агента: среду, которая принимает события, ведёт stateful‑сессию, выдаёт доступ к инструментам и управляет выполнением. Не сам агент и не один из его «умных» промптов, а вся обвязка вокруг него. Без неё агент очень быстро превращается в дорогого собеседника с завышенной самооценкой.

В этой модели агент живёт не в вакууме, а в цикле событий, состояний и действий. Он что‑то увидел, что‑то вызвал, что‑то сохранил, что‑то поменял и пошёл дальше. Это не «один компонент», а целая инфраструктура.

В Claude Managed Agents Harness разложен на четыре core‑концепта: Agent, Environment, Session и Events. Agent: не просто модель, а всё, что определяет поведение: model, system prompt, tools, MCP servers и skills. Session: рабочий экземпляр агента в конкретной среде. Events: сообщения, которыми приложение и агент обмениваются. Environment: runtime‑среда, в которой всё это вообще имеет шанс происходить. Это не философия ради философии, а сильная и элегантная рамка, в которой удобно думать о runtime.

Разные условия, разная архитектура

Удобство всегда конкурирует с безопасностью. Anthropic подходят к безопасности как к системному свойству: session, model и sandbox разделены, credentials вынесены за границу прямого доступа агента. Это работает. Но только если у вас есть ресурсы и команда уровня Anthropic.

Любой продукт в корпоративной среде сталкивается с ревью, диффами, approvals, policy gates и pipeline. Агент уже не может быть просто «умным собеседником». Он должен стать декларативным артефактом, за который не стыдно ни на review, ни в production.

В такой модели уже недостаточно просто «запустить агента». Декларативные агенты и skills не красивая идея, а почти обязательное условие. Если это нельзя ревьюить, тестировать и безопасно выкатывать, рано или поздно оно превращается не в систему, а в зоопарк.

Поэтому Identity и Policy пришлось выделить как самостоятельный архитектурный слой. Environment, наоборот, пришлось вынести за пределы harness: Dev, Test и Prod — это не слой архитектуры, а контекст развёртывания. Kubernetes, namespaces, Helm и NetworkPolicy в этой модели выступают как инфраструктурная среда, а не как часть runtime.

В общем, я зашёл с другой стороны и поднялся на другой уровень абстракции: сгруппировал те core, которые можно сгруппировать, чтобы упростить сборку, и вынес отдельно те части, которые нельзя нормально закрыть одним готовым open source‑проектом. Так появились четыре слоя, которые позволяют собирать harness из доступного open source ПО.

Четыре слоя harness

1. Input: слой входа.

2. Agent Loop (ReAct): слой агентного цикла.

3. Execution: слой исполнения.

4. Identity, Policy & Audit: сквозной слой идентичности, прав и аудита.

Дальше я буду использовать именно эти термины.

Input: это слой, где разделяются пользовательский, агентный и событийный трафик. Человек входит через браузер и SSO (Single Sign‑On), агент через JWT (JSON Web Token) и A2A (Agent‑to‑Agent), а внешние события вроде алертов или CRM‑хуков могут попадать в систему через webhook в workflow. Эти контуры по‑разному проходят identity и policy, поэтому их смешивание только размывает границы и усложняет архитектуру.

Agent Loop (ReAct): состояние, реакция на события, выбор следующего действия. Здесь агент перестаёт быть «одним запросом к модели» и становится процессом с памятью, делегированием задач другим агентам и вмешательством человека (HITL, Human‑in‑the‑Loop). Без этого слоя агент просто функция без состояния, а не система.

Execution: слой управляемого доступа к внешним ресурсам. Он включает инструменты, workflow и LLM‑вызовы, но не сводится к простому вызову функции: весь трафик проходит через контролируемые границы, а доступ к возможностям ограничивается отдельно для каждого инструмента. Это может быть MCP‑сервер, n8n workflow или LLM‑провайдер. В любом случае речь идёт о доступе к capability, а не о прямом обращении к бэкенду.

Identity, Policy & Audit: сквозной слой идентичности, прав, контроля и расследования. Он отвечает на четыре базовых вопроса.

Identity и Policy: кому и что можно.

Audit: кто и что сделал.

Эти функции служат разным целям, но должны работать вместе: первые защищают систему, второй позволяет разбирать инциденты. Без этого слоя harness остаётся красивой, но небезопасной конструкцией.

Его стоит выделять как отдельный архитектурный срез, чтобы проще было разграничивать ответственность и анализировать сбои.

Изоляция данных реализуется как четыре взаимодополняющих слоя: RLS в PostgreSQL для platform‑данных; namespace‑per‑tenant и NetworkPolicy для agent runtime; header‑scoped изоляция через trusted gateway для session/state; и per‑tenant пути в Vault для секретов.

Skills — не Prompt и не Execution

Отдельно стоит отметить природу реализации skills. Skills — это pod‑local capability injection: OCI‑образы со SKILL.md и скриптами, которые монтируются в pod агента при старте. В prompt попадают только метаданные skill’а, а полный SKILL.md подгружается лениво при обращении к конкретному skill.

Skills живут в lifecycle образа и расширяют самого агента, тогда как tools живут в runtime‑сети и дают доступ к внешним возможностям.

Компоненты по слоям

Границы проходят не между модулями, а между логически связанными группами компонентов.

Как это работает вместе

Покажу на конкретном примере, как четыре слоя работают в одном запросе. Возьмём паттерн из статьи AI Agents & Agentic Workflows. Задача приходит как task, затем распределяется между агентами, проходит через workflow и завершается review результата. В качестве конкретного примера рассмотрим инженерную задачу: «добавить новую валидацию в API‑метод, обновить тесты и подготовить итоговый diff для review».

Input + Identity: задача приходит из Telegram, Jira, Web UI или другого рабочего канала и сразу превращается в структурированный task, а не в обычный чат‑запрос. TG Bot или frontend получает JWT у Keycloak и передаёт запрос через agentgateway. agentgateway валидирует токен, проверяет CEL‑политику, инжектит trusted headers, пишет OTEL‑trace и передаёт агенту доверенный identity‑контекст. Кто поставил задачу, из какого tenant пришёл запрос и с какими правами его можно исполнять.

Agent Loop (ReAct): kagent поднимает сессию и работает уже не с «голым текстом», а с task‑контекстом: целью, ограничениями, доступным scope, критериями завершения и доступными ролями агентов. Через agentgateway определяет, какие sub‑agents доступны, например, analyst, implementer и reviewer и проводит задачу по цепочке task → agents → flow → review: один агент уточняет требования и формирует план, второй вносит изменения, третий выполняет независимую проверку результата.

Execution: каждый sub‑agent получает только свой разрешённый набор capability и инструментов через agentgateway, а доступ к MCP‑инструментам и backend‑сервисам проходит по контролируемому access path. Реализация ограничена policy, scope, approval и сетевой изоляцией. Агент может менять только разрешённые файлы, запускать только разрешённые проверки и не получает постоянного доступа к секретам, при необходимости временные учётные данные выдаются как short‑lived credentials с TTL и auto‑revoke.

Identity, Policy & Audit: сквозной слой на всём маршруте. На каждом шаге фиксируется, кто инициировал действие (JWT claims), что было разрешено политикой (CEL), какой агент что выполнил и какие проверки были пройдены (OTEL traces и audit events). Секреты агент напрямую не видит. Доступ выдаётся через Vault или аналогичный secret broker, а затем автоматически отзывается, что позволяет сохранить разделение между reasoning, execution и privileged access.

Что дальше

Каждый из слоёв заслуживает отдельного разбора, от конкретных компонентов до стыковки между собой. В одну статью это не помещается, поэтому дальше разберу слои по отдельности, от input и identity boundary до agent loop и execution layer, и покажу, как из open source‑зоопарка получается то, что можно назвать harness.

За последние месяцы вокруг агентных систем появилось огромное количество новых проектов. Но проблема сегодня уже не в том, как написать ещё одного агента, а в том, как безопасно запускать сотни агентов в production. Мне кажется, именно harness может стать тем уровнем абстракции, который для агентных систем окажется тем же, чем Kubernetes стал для контейнеров.

Это не финальная архитектурная истина, а рабочая reference architecture для построения self‑hosted Enterprise AI Harness на Kubernetes. A2A‑взаимодействие и аудит ещё дорабатываются, нагрузочное тестирование не проводилось. Но базовые цепочки собраны, границы безопасности между слоями и внутри runtime проведены явно. Дальнейшая работа не изобретение новых сущностей, а доводка policy, маршрутов и эксплуатационной надёжности.

Понятие harness пока не устоялось. Разные команды приходят к разным границам, и это нормально. Если вы строили агентную обвязку или просто думали о том, какие слои обязательны, а без каких можно обойтись, поделитесь опытом в комментариях.