Почему ваш POC-агент живёт в Jupyter, а не в продакшене
Вы собрали отличную команду. Написали крутого агента на LangChain. Он звонит в API, парсит документы, даёт аналитику. Запускаете локально — работает как часы. Кладёте на Kubernetes — через час всё падает: агенты теряют контекст, тулзы отвечают с задержками, память переполняется, а логов нет. Знакомая картина? 90% AI-агентов так и остаются в POC-стадии. Не потому что модели плохие, а потому что инфраструктура — сырая.
Enterprise требует SLA 99.9%, multi-tenancy, изоляции данных, аудита и возможности переключить модель без переписывания кода. Anthropic в своих документах (и в нашей прошлой статье) подсветили: без слоёной архитектуры агенты не живут. Open-source даёт всё необходимое, но как собрать это воедино?
Ключевая мысль: AI Harness — это не модель и не фреймворк. Это слой, который оборачивает LLM в production-контур: управляет жизненным циклом агента, оркестрирует инструменты, следит за безопасностью и даёт метрики. Без него агент — это просто дорогой echo-сервер.
Четыре слоя, которые держат enterprise AI
Разделим архитектуру на четыре независимых, но связанных слоя. Каждый решает свою проблему. Менять или масштабировать их можно по отдельности — именно это делает систему enterprise-ready.
| Слой | Ответственность | Основные компоненты |
|---|---|---|
| Infrastructure Layer | Вычисления, GPU, сетевое взаимодействие | Kubernetes, vLLM/TGI, Envoy, Knative |
| Orchestration Layer | Управление agent loop, планирование, ReAct | LangChain/LlamaIndex, собственный executor, K8s Job/CronJob |
| Tooling & Memory Layer | Инструменты, база знаний, контекст, MCP | MCP-серверы, Redis, pgvector, Milvus, REST/gRPC тулзы |
| Guardrails & Observability | Безопасность, аудит, мониторинг, multi-tenancy | Guardrails AI, OpenTelemetry, Grafana, RBAC (Kubernetes), OPA |
1 Infrastructure Layer: Kubernetes — это база, но не та, что вы думали
Не надо поднимать pod: llama3:70b и думать, что всё готово. Энтерпрайз требует GPU-aware scheduling, model multiplexing (одна карта под несколько моделей), autoscaling под burst requests. Используйте vLLM или TGI для инференса — они дают continuous batching и PagedAttention, что утилизирует GPU на 80%+ вместо 20% в тупой загрузке.
apiVersion: v1
kind: Service
metadata:
name: llm-orchestrator
spec:
selector:
app: llm-gateway
ports:
- port: 8000
targetPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-inference
spec:
replicas: 2
template:
spec:
containers:
- name: vllm
image: vllm/vllm-openai:latest
args: ["--model", "mistralai/Mistral-7B-Instruct-v0.3"]
resources:
limits:
nvidia.com/gpu: 1
Обязательно добавьте Knative для serverless-масштабирования — если нагрузка на агентов скачет от 0 до 1000 запросов в час, вам не нужно держать горячие поды 24/7. И Envoy для rate limiting и circuit breaker, чтобы тупой клиент не положил ваш кластер.
2 Orchestration Layer: Agent Loop — это не просто while True
Ядро агента — это цикл: получить задачу → подумать → выбрать инструмент → выполнить → проанализировать результат → повторить. В enterprise этот цикл должен быть fail-safe, observable и preemptible (можно прервать и возобновить).
Типичная ошибка — вешать весь agent loop в один долгий HTTP-запрос. Если таймаут — всё теряется. Правильно: разбить на шаги, каждый шаг — отдельный Job или Task в K8s, с сохранением состояния в Redis. Так вы получаете graceful degradation и retry на уровне инфраструктуры.
Warning: Не засовывайте ReAct-цикл в один под. В production LangChain + AgentExecutor в одном процессе — это бомба замедленного действия. Если агент завис на долгом вызове API, он заблокирует весь поток. Используйте асинхронную очередь (RabbitMQ/NATS) и выносите каждый вызов инструмента в отдельный микросервис.
Для оркестрации хорошо подходит Temporal или Kubernetes-native — комбинируйте Job для долгих операций и CronJob для периодических запусков. Deep Agents Deploy делает это одной командой, но если хотите полный контроль — собирайте сами.
3 Tooling & Memory Layer: MCP — ваш единый портал в мир тулзов
Model Context Protocol (MCP) от Anthropic — это стандарт для подключения инструментов к LLM. Вместо того чтобы для каждой модели писать свой формат tool calling, вы описываете тулзу один раз через MCP-сервер, и любой агент может её вызвать. Для enterprise это святое: экономия времени и единый API для всех моделей.
Тулзы делятся на три типа:
- Stateless — поиск в базе, калькулятор, переводчик. Легко кешируются.
- Session-aware — работа с корзиной пользователя, согласование документов. Требуют sticky-сессию или Redis.
- Long-running — запуск отчётов, генерация видео. Асинхронные с callback.
Память — это отдельная боль. У вас есть краткосрочная (текущий диалог), долгосрочная (профиль пользователя) и рабочая (контекст выполнения). Используйте pgvector для RAG — он дешевле специализированных БД и уже в Postgres. Для кеша результатов тулзов — Redis с TTL. И обязательно separate by tenant — чтобы данные клиента A не светились клиенту B.
4 Guardrails & Observability: Доверяй, но проверяй
Последний слой — это то, что отличает enterprise sandbox от реального продукта. Без него ваш агент может случайно удалить базу данных или выдать медицинский совет, за который подадут в суд.
Guardrails работают на входе (валидация промптов) и на выходе (фильтрация ответов). Открытые решения вроде Guardrails AI или NeMo Guardrails от NVIDIA позволяют задать политики (например, «не отвечай на вопросы о личных данных», «всегда проверяй источник в RAG»). Интегрируйте их как Middleware в Agent Loop.
Multi-tenancy — это не просто разные namespace в K8s. Каждый tenant должен видеть только свои данные, свои тулзы и свою историю. Используйте OPA (Open Policy Agent) для контроля доступа на уровне API и mTLS между сервисами.
Наблюдаемость: OpenTelemetry собирает трейсы каждого шага агента, Loki тащит логи (и сохраняет их в холодное хранилище для аудита), Grafana показывает дашборды: latency агента, количество вызовов тулзов, ошибки, дрейф ответов модели. Без этого вы ослепнете.
Собираем всё вместе: пошаговый план внедрения
Допустим, вы решили строить свою AI Harness. Не пытайтесь сразу поднять все четыре слоя. Идите итеративно:
- Infrastructure — поднимите K8s + vLLM с одной open-source моделью (например, Mistral NeMo или Llama 3.3 Agent). Убедитесь, что автоскейлинг и rate-limit работают.
- Orchestration — добавьте простой Agent Loop (ReAct) как отдельный микросервис с очередью. Прокидывайте вызовы LLM через Gateway.
- Tools & Memory — подключите MCP-сервер для доступа к корпоративным API и PostgreSQL + pgvector для RAG.
- Guardrails & Observability — зашейте трейсинг, добавьте фильтры и OPA.
На каждом шаге тестируйте под нагрузкой (k6 с эмуляцией AI-трафика). После слоя 2 вы уже можете отдать агента внутренним пользователям — безопасность и наблюдаемость достроите потом.
Типичные грабли (и как на них не наступить)
- Гонятся за новыми моделями. Не надо. Выберите одну стабильную (Llama 3.3 70B или Claude 3.7 Sonnet) и сфокусируйтесь на архитектуре. Модель потом заменят — если Harness model-agnostic.
- Забывают про cold start. Когда агент бездействует час, память умирает. Используйте keep-alive или warm-up запросы.
- Игнорируют cost tracking. Каждый вызов LLM стоит денег или GPU-времени. Считайте токены по каждому tenant.
- Пишут свои тулзы без MCP. Через полгода у вас будет зоопарк несовместимых интеграций. MCP — спасение.
Прогноз: куда катится enterprise AI Harness
К 2027 году four-layer architecture станет де-факто стандартом для enterprise AI. Open-source сообщество уже движется в эту сторону: Kubeflow обрастает AI-пайплайнами, K8s получает native поддержку GPU, MCP превращается в IETF RFC. Остаётся только собрать это в одно простое решение — и, возможно, ваш стартап его напишет.
Совет напоследок: не пытайтесь повторить архитектуру Google. Начинайте с малого — один слой, два агента, одна команда. Enterprise AI Harness — это не про размер, а про связанность. Если каждый компонент можно заменить, ваш продукт будет жить десятилетиями.
