# Хватит строить агентов в песочнице: 4 слоя, которые нужны для Enterprise AI в продакшене
Каноническая страница: https://plainews.ru/posts/enterprise-ai-harness-architecture
Опубликовано: 2026-07-11T07:02:09.254Z

Как построить надежный AI-агента для корпоративного использования? Разбираем 4 обязательных слоя: Identity, Agent Loop и Execution.
Прототипы агентов, которые работают в Jupyter Notebook или тестовом окружении, — это полбеды. Когда ты пытаешься запустить "умного собеседника" в реальной корпоративной среде, он ломается на границах: где заканчивается один сервис и начинается другой? Чтобы ваш AI-агент не превратился в дорогого, но неконтролируемого собеседника, нужно не просто добавить LLM, а построить полноценный, многослойный "каркас" (Harness).

## Почему простого LangChain или одного вызова OpenAI недостаточно

Большинство руководств по AI-агентам фокусируются на самом «мозге» — на логике, промптах и вызовах функций (tools). Это, по сути, лишь один компонент. Однако, когда мы говорим о корпоративном уровне (Enterprise), система должна соответствовать строжайшим требованиям безопасности, аудита и изоляции.

Проблема не в том, чтобы заставить агента выполнить задачу. Проблема в том, чтобы гарантировать, что:

1. **Идентичность (Identity):** Мы знаем, кто запустил агента, и какие у него права (токен, роль).
2. **Состояние (State):** Агент не теряет контекст между вызовами и может взаимодействовать с другими системами, сохраняя историю сессии.
3. **Исполнение (Execution):** Любой вызов внешнему ресурсу (база данных, API CRM) проходит через строго контролируемый шлюз.

Отсюда и возникает концепция **Harness** — это не сам агент, а вся инфраструктурная обвязка, которая делает агента надежным, аудируемым и масштабируемым в продакшене.

## Архитектурный скелет: 4 обязательных слоя AI Harness

Изучив подходы лидеров рынка (Anthropic, CNCF-проекты), удалось сформировать архитектурную модель, состоящую из четырех ключевых функциональных слоев. Это не готовый фреймворк, а скорее набор требований к интеграции open source компонентов.

Вот как выглядит этот скелет:

### 1. Input Layer (Слой входа)

Это точка входа для всего трафика в систему. Критически важно разделить, откуда пришел запрос.

- **Пользовательский трафик:** Входит через браузер и требует механизмов Single Sign-On (SSO).
- **Агентный трафик (A2A):** Обмен сообщениями между двумя агентами. Здесь необходим токен, подтверждающий, что Агент А имеет право говорить с Агентом Б.
- **Событийный трафик:** Внешние триггеры (вебхуки от CRM, алерты).

**Ключевая задача:** На этом уровне должен происходить первичный анализ идентичности и проверка базовых прав доступа.

### 2. Agent Loop Layer (Цикл агента)

Это сердце, где происходит мышление и принятие решений. Агент больше не является функцией, вызываемой один раз. Это *процесс* с памятью.

Вместо того чтобы просто отправлять промпт в LLM, агент должен находиться в цикле:

1. Получить событие (из Input).
2. Проанализировать состояние (Memory).
3. Выбрать действие (Decision).
4. Попросить выполнить действие (Execution).

**Как это работает:** Этот слой управляет памятью (историей сессии) и определяет, какой следующий шаг должен быть предпринят — вызов инструмента, запрос к человеку (Human-in-the-Loop) или завершение задачи.

### 3. Execution Layer (Слой исполнения)

Самый критичный слой с точки зрения безопасности. Он не позволяет агенту напрямую общаться с внешним миром.

Вместо прямого вызова API, агент отправляет запрос в Execution Layer. Этот слой выступает в роли **прокси и валидатора**. Он:

1. Проверяет, имеет ли пользователь/агент право вызывать конкретный API (Policy Check).
2. Изолирует вызов (например, используя микросервисы или Kubernetes Namespaces).
3. Выполняет вызов, преобразуя запрос в нужный формат и возвращая результат, который затем передается обратно в Agent Loop.

### 4. Identity, Policy & Audit Layer (Сквозной слой)

Это не отдельный слой, а **сквозная функция**, которая должна пронизывать все остальные слои. Это гарантия корпоративной безопасности.

- **Identity:** Кто вы? (Ваш JWT токен).
- **Policy:** Что вам разрешено делать? (Ролевая модель: пользователь может читать, но не может удалять).
- **Audit:** Что вы сделали? (Журнал всех действий, с привязкой к Identity).

Без этого слоя вы просто запустили бы «умный скрипт», а не управляемый корпоративный продукт.

## Как собрать Harness: Практический подход

Поскольку эта архитектура слишком сложна для одной команды, ее нужно собирать из специализированных, проверенных open source компонентов.

### Шаг 1. Управление идентификацией и правами (Identity & Policy)

Начните с самого фундамента. Вам нужен центральный источник прав.

Вместо того чтобы передавать права в виде «просто строки», используйте токены с четко определенной структурой.

**Инструмент:** Keycloak (или любой другой OIDC-провайдер). **Механизм:** Используйте JWT (JSON Web Token). Токен должен содержать не только ID пользователя, но и список ролей/прав (scope, roles).

**Концепт реализации (Python/伪код):**

```python from jwt import decode, ExpiredSignatureError

def validate_token(jwt_token: str, required_scope: str) -> bool:     try:         payload = decode(jwt_token, key="SECRET_KEY", algorithms=["HS256"])

# 1. Проверка срока действия         if payload['exp'] < time.time():             raise ExpiredSignatureError("Token expired")

# 2. Проверка прав (Policy Check)         if required_scope not in payload.get('scopes', []):             print(f"Access denied. Missing scope: {required_scope}")             return False

return True     except Exception as e:         print(f"Validation failed: {e}")         return False

# Пример вызова:

# token = get_user_token_from_sso()

# if validate_token(token, "write:crm_api"):

# # Только теперь можно вызывать API

# pass

```

### Шаг 2. Обеспечение контролируемого исполнения (Execution)

Используйте Kubernetes и принцип **Service Mesh** (например, Istio) для принудительного прогона всего трафика через прокси.

**Цель:** Ни один сервис не должен напрямую вызывать другой. Все должно идти через центральный, аутентифицированный шлюз.

**Концепция:** Создайте Tool Execution Gateway — микросервис, который принимает запрос от агента, валидирует его права через Identity Layer, а затем вызывает реальный сервис.

**Пример пайплайна (Conceptual Flow):**

1. **Агент (Pod A)** $\rightarrow$ Отправляет запрос: {"tool": "get_user_data", "params": {"user_id": 123}}
2. **Istio/Service Mesh** $\rightarrow$ Перехватывает запрос.
3. **Execution Gateway (Pod B)** $\rightarrow$ Получает запрос.
4. **Execution Gateway** $\rightarrow$ Вызывает Identity Service, проверяя: *Имеет ли Агент А право вызывать `get_user_data`?*
5. **Execution Gateway** $\rightarrow$ Если права есть, вызывает реальный User Service и возвращает результат в формате, понятном LLM.

### Шаг 3. Построение цикла и памяти (Agent Loop)

На уровне кода это требует вынесения логики из промптов и встраивания ее в управляемый фреймворк.

Если вы используете фреймворки типа LangChain или LlamaIndex, вам нужно настроить их так, чтобы:

1. **Внешняя память (Vector DB):** Все сессии сохранялись в базу данных векторов (Pinecone, Chroma). Это позволяет агенту «помнить» контекст между сессиями.
2. **Управление состоянием:** Вместо того чтобы полагаться на контекстное окно LLM, вы должны явно управлять состоянием (State Machine) в коде, которое передается в промпт.

**Пример логики State Machine (Conceptual):**

```yaml

# State Machine Diagram

START -> (Input Received) (Input Received) -> Check_Identity_Policy Check_Identity_Policy -> (Valid?) Valid? (Yes) -> Agent_Loop_Step Agent_Loop_Step -> (Needs Tool?) Needs Tool? (Yes) -> Call_Execution_Gateway Call_Execution_Gateway -> (Result Received) (Result Received) -> Update_State_Memory Update_State_Memory -> (Task Complete?) Task Complete? (No) -> Agent_Loop_Step (Cycle continues) Task Complete? (Yes) -> END ```

## Подводные камни: Где ломается идеальная архитектура

Если вы просто возьмете этот список слоев и начнете его собирать, вы упретесь в реальные проблемы:

1. **A2A Isolation (Изоляция между агентами):** Самая частая ошибка. Если Агент А может вызвать API, который используется Агентом Б, Агент А может получить доступ к данным Агента Б. Решение: Every API call must be scoped by the identity of the *caller*, not just the *user*.
2. **Транзакционная целостность:** Если агент выполняет 5 шагов, и на 4-м падает сеть, вы не должны получить состояние "частично выполнено". Требуется механизм **Saga Pattern** для отката (rollback) изменений.
3. **Деградация контекста:** Чем больше слоев, тем сложнее передавать контекст. Постоянно проверяйте, что ваш финальный промпт содержит не только "что случилось", но и "почему это случилось" (историю действий).

## Что попробовать дальше?

Не пытайтесь построить всю систему сразу. Начните с самого рискованного места: **Execution Layer**.

Сфокусируйтесь на создании минимального рабочего прототипа, который сможет выполнить одну, но критически важную функцию (например, «проверить статус заказа»), и гарантируйте, что весь этот процесс проходит через ваш собственный, аутентифицированный шлюз. Успех здесь даст вам уверенность в том, что вы контролируете безопасность, а не просто используете «умную» магию LLM.

## Источники

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