Проще говоря, LLM - это мозг для генерации ответа, а архитектура агента - это рабочее место, правила, инструменты, память, наблюдение и тормоза. Без архитектуры агент быстро превращается в длинный промпт, который может красиво рассуждать, но плохо управляется, ошибается в действиях и не оставляет следов для отладки.
Базовая архитектура обычно включает входной канал, LLM, системный prompt, context builder, состояние задачи, память, RAG или поиск по данным, tool registry, planner, executor, policy gate, guardrails, human approval, audit log, observability и evals. В простом MVP часть этих ролей может быть внутри одного backend-сервиса, но ответственность все равно нужно разделять.
Типовой поток выглядит так: пользователь или система создает задачу, backend собирает контекст, модель определяет намерение и следующий шаг, policy gate проверяет права и риск, executor вызывает разрешенный tool, результат возвращается в state, агент решает продолжать или завершить, а важные действия попадают в лог. Если действие рискованное, оно уходит в approval, а не выполняется напрямую.
Planner и executor лучше не смешивать в голове модели без контроля. Planner может предложить шаги и нужные tools, но executor должен проверять схему аргументов, права, лимиты, idempotency, ошибки API и audit log. Даже если модель “уверена”, backend не должен выполнять запрещенный tool.
Память и RAG решают разные задачи. Память хранит факты о текущей или прошлой работе агента: сессия, предпочтения, результаты действий, важные решения. RAG ищет проверенный контекст в документах, базе знаний или данных компании. Оба слоя требуют правил хранения, доступа, удаления и проверки качества.
Хорошая архитектура снижает риск prompt injection, hallucinations, excessive agency и утечек данных. Защита не должна держаться только на фразе в системном промпте. Нужны backend-ограничения: allowlist tools, ACL, metadata filters, rate limits, PII handling, approval workflow, sandbox, логи и тесты.
Архитектура должна расти постепенно. Для первой версии достаточно одного сценария, 2-3 tools, read-only или draft-only режима, явных правил безопасности и простого набора evals. Multi-agent, долгосрочную память, сложный orchestration и автоматическую запись лучше добавлять после того, как базовый agent loop понятен и наблюдаем.
Примеры
- CRM-агент читает сделку, собирает контекст, предлагает follow-up, но отправка письма проходит через approval и audit log.
- RAG-агент получает вопрос, ищет chunks в базе знаний, добавляет citations и отвечает только по найденному контексту.
- Coding agent получает issue, читает репозиторий, предлагает diff, запускает тесты и отдает результат на code review.
- Browser agent открывает сайт, собирает данные, но не отправляет формы и не вводит секреты без разрешенного policy gate.
- Multi-agent система разделяет роли: router выбирает специалиста, researcher ищет факты, writer готовит ответ, reviewer проверяет риск.
Где используется
- проектирование ИИ-агента перед MVP
- выбор tool calling и backend executor
- RAG и память агента
- human-in-the-loop и approval
- guardrails и policy gate
- observability и agent trace
- LLMOps и evals
- безопасность AI-агентов
- multi-agent orchestration
- выбор фреймворка: LangGraph, OpenAI Agents SDK, n8n или Flowise
Связанные термины
Частые вопросы
Что такое архитектура ИИ-агента простыми словами?
Это схема всей системы вокруг модели: откуда берется задача, какой контекст получает агент, какие tools он может вызвать, где проверяются права, кто подтверждает рискованные действия и как все логируется.
Почему недостаточно хорошего системного промпта?
Промпт направляет поведение модели, но не гарантирует безопасность. Права tools, validation, approval, ACL, rate limits, sandbox и audit log должны жить в backend-архитектуре, а не только в тексте инструкции.
Какие модули нужны в минимальной архитектуре агента?
Минимум: входной канал, LLM, системный prompt, сбор контекста, состояние задачи, 1-3 tools, executor, правила безопасности, логирование и ручное подтверждение опасных действий.
Чем planner отличается от executor?
Planner решает, какие шаги нужны и какой tool вызвать. Executor выполняет действие в реальной системе: проверяет аргументы, права, лимиты, ошибки и пишет audit log.
Когда нужна multi-agent архитектура?
Когда задачу естественно разделить на роли: ресерч, анализ, написание, проверка, выполнение. Если один агент с несколькими tools справляется, multi-agent лучше отложить, чтобы не усложнять систему раньше времени.
