Прототипы агентов, которые работают в 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