Agentic-пайплайны в enterprise: паттерны и антипаттерны

Почему agentic workflows важны для enterprise

Agentic workflows объединяют reasoning LLM, выполнение tool calls, retrieval и policy controls, чтобы автоматизировать многошаговые задачи с меньшим участием человека. В enterprise это обычно означает переход от чат-ассистентов к системам, которые могут:

• классифицировать и маршрутизировать запросы,
• собирать контекст из корпоративных источников,
• вызывать API и внутренние сервисы,
• передавать задачу человеку при необходимости,
• и формировать аудируемый результат.

На бумаге это выглядит просто, но внутри реальной организации появляются latency budgets, access control, compliance, change management, dependency sprawl и разная готовность к автономии. Поэтому архитектура должна оптимизировать в первую очередь надёжность, а уже потом новизну.

Полезная ментальная модель: enterprise agent — это не один prompt. Это workflow runtime. Модель — лишь один компонент в более широкой control plane.

Если спроектировать всё как «LLM плюс tools», почти неизбежно появятся такие проблемы, как:

• неконтролируемый fan-out tool calls,
• дублирующиеся действия,
• drift контекста,
• неконтролируемый cost,
• и результаты, которым downstream-системы не могут доверять.

Ниже — паттерны, которые помогают сделать agentic workflows operationally sane.

---

Практическая reference architecture

Diagram brief: Схема слоёв, где показаны:

• Channel layer: web app, Teams/Slack, API, ticketing system
• Orchestration layer: policy engine, planner, state machine, retry controller, human approval gate
• Model layer: LLM, small classifier model, embedding model
• Knowledge layer: RAG index, document store, vector DB, metadata catalog
• Tool layer: CRM, ERP, email, internal APIs, MCP servers
• Governance layer: authN/authZ, audit logs, prompts registry, safety filters, secrets management
• Observability layer: traces, metrics, cost tracking, evaluation harness

Практическая enterprise-архитектура agentic-системы обычно разделяет обязанности так:

1. Intent capture — принять запрос от пользователя или системы.
2. Policy check — определить, разрешена ли задача, насколько она рискованна и нужен ли approval.
3. Context assembly — собрать релевантные данные из retrieval-систем и business APIs.
4. Planning — разбить работу на ограниченные шаги.
5. Execution — вызвать tools с явными аргументами.
6. Verification — проверить результат, найти аномалии, сравнить с правилами.
7. Escalation or completion — передать человеку или завершить действие.
8. Audit and learning — сохранить traces для evaluation, compliance и улучшений.

Эта архитектура должна быть явной. Если orchestration спрятана внутри одного prompt, вы теряете контроль над safety, observability и возможностью итераций.

---

Шесть архитектурных паттернов

1) Retrieve-then-act

Это самый безопасный default для enterprise-workflows. Сначала agent собирает authoritative context через RAG, структурированные запросы или API lookup, и только потом решает, что делать.

Лучше всего подходит для: support triage, policy lookup, contract summarization, internal knowledge assistants, incident response prep.

Почему работает: модель меньше склонна hallucinate actions, когда до планирования у неё есть правильные факты.

Design notes:

• Prefer structured retrieval для operational facts.
• Ограничивайте context минимально необходимыми evidence.
• Записывайте, какие источники повлияли на action.

Частый implementation choice: retrieval pipeline + deterministic business rules + LLM для synthesis.

---

2) Planner-executor split

Planner создаёт bounded plan, executor выполняет по одному шагу за раз.

Лучше всего подходит для: multi-step operations, cross-system fulfillment, onboarding, procurement workflows, internal ops automation.

Почему работает: разделение planning и execution снижает accidental tool chaining и делает failures проще для локализации.

Design notes:

• Делайте planner output machine-readable.
• Ограничивайте каждый шаг одним intent.
• Перепланируйте после tool results, если state существенно изменился.

Пример формы:

• Planner: «собери customer record, проверь entitlement, подготовь response, запроси approval, если refund выше threshold».
• Executor: выполняет каждый шаг с явными preconditions.

Этот паттерн полезен, когда LLM нужно reasoning, но нельзя позволить ей самой импровизировать execution path.

---

3) Human-in-the-loop approval gates

Высокорисковые действия должны проходить approval gate до execution.

Лучше всего подходит для: financial actions, external communications, data deletion, access grants, production changes, legal or compliance-sensitive tasks.

Почему работает: сочетает machine speed с accountable human judgment.

Design notes:

• Заранее определите risk thresholds.
• Показывайте человеку concise evidence bundle, а не весь raw prompt.
• Фиксируйте identity approver и rationale.

Не используйте approval gates как заплатку для плохой automation design. Gate должен защищать bounded process, а не спасать хаотичную систему.

---

4) Event-driven agent orchestration

Вместо ожидания запроса от пользователя system реагирует на events: создан ticket, истекает contract, упала data quality job или KPI вышел за threshold.

Лучше всего подходит для: operations, customer success, compliance monitoring, ITSM, supply chain alerts.

Почему работает: многие enterprise workloads уже event-native.

Design notes:

• Используйте durable queues и idempotent handlers.
• Кодируйте event metadata так, чтобы agent понимал urgency и ownership.
• Отделяйте detection от action, чтобы избежать noisy auto-remediation.

Этот паттерн хорошо сочетается с policy rules и bounded automation.

---

5) Tool-calling with a narrow capability surface

Дайте agent только те tools, которые действительно нужны, и expose их через маленькие, чёткие interfaces.

Лучше всего подходит для: production systems, где надёжность важнее гибкости.

Почему работает: меньше tools — меньше ambiguity, меньше blast radius и проще security review.

Design notes:

• Оборачивайте internal services через stable contracts.
• Валидируйте каждый tool input.
• Проектируйте tools вокруг business verbs, а не вокруг raw infrastructure primitives.

Например, create_support_case лучше, чем execute_generic_api_request.

Narrow tool surfaces особенно полезны при интеграции через MCP, потому что они подталкивают к reusable, versioned tool definitions вместо ad hoc prompt glue.

---

6) State-machine governed autonomy

Используйте explicit state machine, чтобы контролировать, какие действия разрешены на каждом этапе.

Лучше всего подходит для: onboarding, claims handling, case management, procurement, compliance workflows.

Почему работает: state machines делают autonomy legible. Они явно задают, что agent может сделать next и какие условия должны быть истинны.

Design notes:

• Моделируйте states, transitions, guards и terminal outcomes.
• Держите LLM как decision-support component внутри state machine, а не выше неё.
• Храните state externally, чтобы работу можно было продолжить после failure.

Для enterprise это часто самый удобный паттерн, когда нужна deterministic control с точечной reasoning.

---

Пять anti-patterns, которых стоит избегать

1) Unbounded autonomous loops

Если agent может бесконечно думать, вызывать tools и retry без бюджета, он рано или поздно создаст cost, delay или damage.

Симптомы: runaway API calls, повторные retries, дублирующиеся tickets, длинный tail latency.

Исправление: step limits, timeouts и budget caps.

---

2) Prompt-as-orchestrator

Огромный prompt, в котором живёт вся orchestration logic, хрупок и плохо тестируется.

Симптомы: hidden dependencies, нечитаемая логика, version drift и debugging методом проб и ошибок.

Исправление: перенесите control flow в code или workflow engine; prompt оставьте для reasoning.

---

3) Tool sprawl without governance

Каждая команда добавляет свои wrappers, naming conventions и permissions model.

Симптомы: duplicate capabilities, inconsistent schemas, security exceptions и unclear ownership.

Исправление: стандартизируйте tool contracts, регистрируйте capabilities centrally и применяйте consistent authz/audit logging.

---

4) No verification layer

Agent, который выполняет actions без проверки outputs, опасен в любой enterprise-среде.

Симптомы: invalid records, silent partial failures и слабая confidence в automation.

Исправление: добавьте schema validation, post-action checks, business rule validation и anomaly detection.

---

5) Treating autonomy as a binary

Команды часто спрашивают, система «agentic» или «not agentic». На практике autonomy — это spectrum.

Симптомы: over-automation в рискованных областях или under-automation там, где риск низкий.

Исправление: назначайте autonomy levels по workflow step, data sensitivity и business impact.

Хороший enterprise design позволяет одним шагам быть fully automated, а другим — требовать approval или deterministic handling.

---

Decision matrix: когда что использовать

Сценарий	Рекомендуемый паттерн	Уровень автономии	Главная причина	Лучший guardrail
Internal knowledge Q&A	Retrieve-then-act	Low	Сначала факты, потом действия	Source citation и confidence threshold
Ticket triage and routing	Event-driven orchestration	Low to medium	Высокий объём, повторяемость	Idempotency и queue retries
Refund request handling	Planner-executor split	Medium	Несколько шагов, понятные policy	Approval выше threshold
Access provisioning	State-machine governed autonomy	Medium	Строгий lifecycle и audit needs	Role-based policy checks
Customer-facing email drafting	Human-in-the-loop gate	Low	External impact, важен tone	Human approval before send
Cross-system fulfillment	Tool-calling with narrow capability surface	Medium	API-heavy, bounded actions	Tool allowlist и input validation

Как пользоваться matrix:

• Если задача в основном informational — начинайте с retrieve-then-act.
• Если задача включает несколько systems — отделяйте planning от execution.
• Если действие необратимо или externally visible — добавляйте approval.
• Если процесс имеет lifecycle states — моделируйте их явно.

Самая частая ошибка — пытаться применить один паттерн ко всем workflows. Зрелые enterprise-программы комбинируют их.

---

Как естественно вписывается Agent Shaker

Agent Shaker можно использовать как practical accelerator для prototyping и operationalizing agentic workflows в enterprise-среде. Его естественная роль — не заменить architecture, а стандартизировать часть workflow surface.

Типичные точки естественного fit:

• определение repeatable agent flows,
• упаковка tool integrations,
• эксперименты с prompt и policy variants,
• создание reusable templates для orchestration.

При грамотном использовании Agent Shaker помогает перейти от ad hoc experiments к governed workflows. Особенно полезен он тогда, когда нужно сравнивать patterns side by side, тестировать tool boundaries и поддерживать implementation consistency между командами.

Agent Shaker — open-source платформа координации агентов, которую мы делаем в AnetLab. Она даёт единый слой поверх моделей и инструментов: запуск сценариев, сравнение конфигураций бок о бок, трассировка вызовов к MCP-серверам и воспроизводимые прогоны. Репозиторий открыт — можно взять его как стартовую точку и собрать свой контур.

---

Чеклист внедрения

Перед запуском enterprise agent workflow проверьте следующее:

• Бизнес-результат чётко определён.
• У workflow есть bounded autonomy level.
• Каждый external tool имеет stable contract.
• Authentication и authorization enforced.
• Prompts, policies и tool schemas versioned.
• Есть retrieval strategy для authoritative data.
• Каждое действие логируется с trace IDs.
• Есть retry policy и step budget.
• High-risk actions требуют approval.
• Outputs валидируются до downstream use.
• У команды есть evaluation harness.
• Ownership for failures задокументирована.

Если чего-то из этого нет, workflow, скорее всего, ещё не готов к production autonomy.

---

FAQs

1) Что такое agentic workflow в enterprise-контексте?

Это workflow, в котором AI-system может рассуждать о задаче, собирать контекст, выбирать tools и выполнять bounded steps под control policy.

2) Чем это отличается от chatbot?

Chatbot в основном отвечает на сообщения. Enterprise agentic workflow может выполнять multi-step work, взаимодействовать с systems и формировать auditable outcomes.

3) Нужна ли всем enterprise-agent systems полная автономия?

Нет. Большинству production-систем нужна selective autonomy в зависимости от риска, impact и data sensitivity.

4) Где здесь RAG и MCP?

RAG обычно используют для grounding agent в authoritative enterprise knowledge. MCP часто применяют, чтобы expose tools и services через standardized interfaces.

5) Какая самая большая архитектурная ошибка?

Считать prompt всей системой. Настоящие agentic workflows требуют orchestration, policy, verification и observability вне модели.

6) Нужно ли применять agent для каждой automation-задачи?

Нет. Используйте agent там, где reasoning, context selection или dynamic planning дают value. Там, где process уже well-defined, лучше deterministic automation.

7) Как контролировать cost?

Задавайте step budgets, routing простых запросов на smaller models или rules, кэшируйте retrieval results и ограничивайте unnecessary tool calls.

---

Related Articles

• Архитектура enterprise AI: четыре решения, которые всё определяют
• MCP для enterprise: протокол, безопасность и границы
• RAG на .NET: архитектура, которая переживает продакшн
• Как вывести AI PoC в продакшн: 90 дней по фазам

---

CTA

Если ваша команда оценивает agentic workflows в enterprise-системах, начните с одного bounded use case и спроектируйте orchestration layer до масштабирования autonomy.

Agent Shaker может помочь стандартизировать workflow surface, сократить implementation drift и ускорить experimentation с governed agent patterns.

Попробовать Agent Shaker или рассказать про вашу задачу — соберём решение под ваш контур, а не под готовый шаблон.