Многопроцессорные системы в 2026 году: ReAct, надзиратели, стаи, LangGraph и Strands
Руководство по шаблонам потока управления в многокомпонентных системах — последовательные, параллельные, типа «центр и спицы», графовые, управляемые событиями, критические и с участием человека — а также о том, как к ним применимы фреймворки вроде LangGraph и Strands.
Следующий этап генеративного ИИ — это не только более умные модели. Речь идет о системах, в которых несколько агентов могут рассуждать, вызывать инструменты, делегировать задачи, проверять результаты, восстанавливаться после сбоев и координировать свои действия. Это область многопроцессорных систем (MAS).
Минимальное приложение на основе LLM выглядит как простой путь от пользователя к модели:
User
↓
LLM
↓
Response
Производственная архитектура с участием нескольких агентов более сложна:
User
│
▼
┌─────────────┐
│ Orchestrator│
└──────┬──────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
└───────────┼───────────┘
▼
Verification
│
▼
Action
Единого шаблона не существует. К распространенным форматам относятся агенты типа ReAct, последовательные и параллельные конвейеры, схемы управления в стиле «центр и спицы», иерархии, механизмы передачи задач, стаи агентов, разделение на планировщик и исполнитель, рабочие процессы на основе графов, агенты, реагирующие на события, циклы критика и оценки, а также механизмы участия человека в процессе. Фреймворки вроде LangGraph, Strands Agents и Amazon Bedrock AgentCore предоставляют примитивы для реализации этих паттернов. В следующих разделах идеи изложены отдельно, чтобы команды перестали рассматривать несопоставимые концепции как конкурентов.
1. Что такое многопроцессорная система?
Многопроцессорная система — это совместная работа специализированных агентов над более крупной целью. Вместо того чтобы одна модель выполняла всё:
LLM
├── Research
├── Coding
├── Database
├── Security
├── Decision making
└── Execution
обязанности можно разделить:
Supervisor
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Research Agent Security Agent Execution Agent
│ │ │
▼ ▼ ▼
Search Security APIs
Tools Tools Tools
Каждый агент может иметь собственные инструкции, инструменты, память, окно контекста, выбор модели, правила действий, обязанности и критерии оценки. Специализация — основная причина отказа от конструкций с одним агентом.
2. Большее количество агентов не всегда лучше
Дополнительные агенты увеличивают затраты и сложность. Три агента часто означают три запроса и три контекста:
3 agents
↓
3 × prompts
3 × contexts
3 × tool interfaces
3 × failure surfaces
3 × observability requirements
Агенты, обменивающиеся информацией, увеличивают расходы и затрудняют отладку:
Agent A → Agent B
Agent B → Agent C
Agent C → Agent A
Agent A → Agent D
Agent D → Agent B
Хорошее проектирование определяет, какие обязанности следует разделить и как должен осуществляться контроль между ними.
3. Агент ReAct
ReAct означает Reason + Act. Цикл включает рассуждения, выбор инструмента, наблюдение и продолжение работы — например, анализ необычной нагрузки процессора в базе данных:
Reason
↓
Call CloudWatch
↓
Observe CPU metrics
↓
Call logs
↓
Observe errors
↓
Reason
↓
Return diagnosis
Преимущество: динамический выбор инструмента, когда следующий шаг зависит от последнего наблюдения.
Недостаток: длинные циклы увеличивают задержки, расход токенов, затраты и вероятность сбоев. ReAct представляет собой шаблон рассуждений, а не полную многопроцессорную топологию сам по себе.
4. Последовательная архитектура с несколькими агентами
Самая простая форма многопроцессорной архитектуры — это конвейер:
Document Agent
↓
Extraction Agent
↓
Risk Agent
↓
Decision Agent
Процесс в стиле банковской системы может выглядеть так:
Bureau Agent
↓
Policy Agent
↓
Risk Agent
↓
Decision Agent
Когда использовать: порядок имеет значение, результаты одной стадии поступают на следующую, рабочий процесс предсказуем, и важны журналы аудита.
Основное ограничение: сбой на каком-либо этапе может заблокировать всю цепочку — поэтому в производственных системах применяются повторные попытки, контрольные точки и механизмы восстановления.
5. Параллельная обработка / распространение и сбор данных
Независимые задачи не обязаны выполняться последовательно:
Agent A
↓
Agent B
↓
Agent C
Специалисты работают одновременно:
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└──────────┼──────────┘
▼
Aggregator
При анализе архитектуры облака могут быть задействованы несколько агентов для обработки данных:
Architecture Request
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Cost Agent Security Agent Performance Agent
│ │ │
└──────────────┼──────────────┘
▼
Architecture Agent
затем результаты собираются воедино.
Преимущество: сокращение времени выполнения задач. Проблема: необходимость надежного сбора данных.
6. Модель «центральный узел и периферия» / руководитель
Центральный руководитель направляет задачи специалистам:
Supervisor
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Research Coding Finance
Agent Agent Agent
│ │ │
Tools Tools Tools
При поступлении запроса от пользователя:
User:
"Analyze this AWS account and identify security and
cost problems."
руководитель может распределить задачи следующим образом:
Supervisor
│
├──→ Security Agent
│
└──→ FinOps Agent
│
▼
Aggregator
│
▼
Report
Преимущество: централизованный контроль. Проблема: центральный узел становится узким местом и критической инфраструктурой, поскольку через него проходит каждое решение:
Agent A ─┐
Agent B ─┼──→ Supervisor
Agent C ─┤
Agent D ─┘
7. Иерархическая архитектура с несколькими агентами
Когда одного руководителя недостаточно, добавляются уровни:
Global Supervisor
│
┌───────────┴───────────┐
▼ ▼
Engineering Lead Business Lead
│ │
┌────┴────┐ ┌────┴────┐
▼ ▼ ▼ ▼
Coding Testing Finance Risk
В корпоративных облаках часто используется иерархия руководителей:
Enterprise Agent
│
├── Cloud Supervisor
│ ├── Security Agent
│ ├── FinOps Agent
│ └── Operations Agent
│
└── Application Supervisor
├── Coding Agent
├── Testing Agent
└── Documentation Agent
Структура соответствует органиграмме; затраты связаны с дополнительными расходами на координацию.
8. Архитектура на основе передачи задач
Один агент передаёт ответственность за разговор другому:
Agent A
│
│ handoff
▼
Agent B
│
│ handoff
▼
Agent C
В процессах обслуживания клиентов технические проблемы часто передаются другим специалистам:
Customer Agent
│
│ technical issue
▼
Technical Agent
│
│ billing issue
▼
Billing Agent
В отличие от постоянного руководителя, получатель становится активным ответственным — это удобно для обслуживания клиентов, направления звонков к специалистам, работы вспомогательных систем и реализации конверсационных рабочих процессов.
9. Архитектура стаи
В такой архитектуре отсутствует постоянный центр управления; агенты сотрудничают динамически:
Agent A
↙ ↘
Agent B ←→ Agent C
↘ ↙
Agent D
Каждый может считать, что другой партнер более подходит для выполнения задачи. Гибкость сопряжена с серьезными вопросами: кто контролирует систему? Без четких границ существует риск возникновения циклов, дублирования работы, экспоненциального роста объема данных, непредсказуемых сценариев развития и высоких затрат на обработку информации. Обязательна строгая система управления состоянием и четкие условия завершения работы.
10. Архитектура планировщика и исполнителя
Необходимо разделять процессы планирования и выполнения:
User Goal
│
▼
Planner
│
┌────────┼────────┐
▼ ▼ ▼
Task 1 Task 2 Task 3
│ │ │
▼ ▼ ▼
Executor Executor Executor
│ │ │
└────────┼────────┘
▼
Result
Для задачи «мигрировать этот приложение в AWS» планировщик может определить последовательность шагов:
1. Analyze application
2. Identify dependencies
3. Design AWS architecture
4. Estimate cost
5. Generate Terraform
6. Validate Terraform
Затем исполнители выполняют каждый из этих шагов. Этот подход полезен, когда сложные цели разбиваются на конкретные задачи.
11. Агенты на основе графов
Здесь отлично справляются такие фреймворки, как LangGraph. Вместо свободной цепочки операций:
Agent → Agent → Agent
следует использовать граф состояний:
START
│
▼
Research
│
┌──────┴──────┐
▼ ▼
Valid Invalid
│ │
▼ ▼
Analysis Research
│
▼
Verification
│
▼
END
Узлы могут быть агентами, инструментами, функциями, модулями проверки, элементами для утверждения человеком или маршрутизаторами. Совместное состояние в сочетании с явными связями обеспечивают больший контроль, чем принудительная импровизация модели при каждом переходе.
12. Агенты Strands
AWS Strands Agents — это SDK для агентов, использующих инструменты. Концептуально:
Agent
│
┌───────┼────────┐
▼ ▼ ▼
Tool Tool Tool
│ │ │
▼ ▼ ▼
AWS APIs Databases
Агенты анализируют инструменты и действуют на основе полученных данных. Агенты Strands также могут входить в состав многоагентных структур:
Supervisor Agent
│
┌─────┼─────┐
▼ ▼ ▼
AWS SQL Research
Agent Agent Agent
Важное различие: Strands — это фреймворк/SDK; supervisor — архитектурный паттерн. Они дополняют друг друга, а не конкурируют.
13. Агенты LangGraph
LangGraph акцентирует внимание на явных состоянийных рабочих процессах, представленных в виде графов:
START
│
▼
Supervisor
│
├──────→ Research Agent
│
├──────→ Data Agent
│
└──────→ Security Agent
│
▼
Validator
│
┌───┴───┐
▼ ▼
Success Retry
│
▼
END
Вы сами определяете состояния, узлы, связи, условную маршрутизацию, точки контроля, возможности повторных попыток, элементы для утверждения человеком и механизмы сохранения данных — то есть тот контроль, который необходим производственным системам.
14. Системы с множеством агентов, управляемые событиями
Не каждый поток является синхронным. События могут пробудить агентов:
AWS Event
│
▼
EventBridge
│
├────→ Security Agent
│
├────→ FinOps Agent
│
└────→ Operations Agent
Пример операций:
CloudWatch Alarm
↓
EventBridge
↓
Incident Agent
↓
RCA Agent
↓
Remediation Agent
↓
Human Approval
↓
AWS API
Полезно для управления облачными ресурсами, мониторинга безопасности, реагирования на инциденты, FinOps и автоматизации.
15. Архитектура критика/оценщика
Один агент генерирует; другой оценивает:
Generator Agent
│
▼
Generated Result
│
▼
Critic Agent
│
┌──┴──┐
▼ ▼
Pass Fail
│ │
▼ ▼
Done Retry
Пример анализа архитектуры:
Architecture Agent
↓
AWS Architecture
↓
AWS Best-Practice Evaluator
↓
Pass?
/ \
Yes No
↓ ↓
Done Revise
Поскольку результаты работы модели не всегда заслуживают доверия, оценщик выполняет функцию контроля качества.
16. Системы с множеством агентов с участием человека
Полная автономия не всегда подходит для изменений с высоким влиянием:
Agent
↓
Analyze
↓
Recommend
↓
Human Approval
↓
Execute
Пример устранения проблем в области безопасности:
Security Agent
↓
Detect vulnerable resource
↓
Remediation Agent
↓
"Delete public access?"
↓
Human Approval
↓
AWS API
Искусственный интеллект предлагает возможные действия. Политика в сочетании с одобрением человека определяет, что может быть выполнено.
17. Важная таксономия
Эти концепции существуют на разных уровнях:
MULTI-AGENT SYSTEM
│
┌────────────────┼────────────────┐
│ │ │
Architecture Reasoning Framework
Pattern Pattern / Runtime
│ │ │
▼ ▼ ▼
Supervisor ReAct LangGraph
Sequential Plan-Execute Strands
Parallel Critic Bedrock
Hierarchical AgentCore
Handoff
Swarm
Event-driven
Такой подход предотвращает ложные сравнения вроде «LangGraph против supervisor против ReAct», создающие впечатление, что речь идет о трех конкурирующих продуктах.
18. Как они сочетаются
Мощность проявляется в составлении таких решений:
User
│
▼
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
ReAct ReAct ReAct
│ │ │
└──────────┼───────────┘
▼
Critic
│
┌────┴────┐
▼ ▼
Pass Fail
│ │
▼ ▼
End Retry
Одна концепция может объединять механизмы оркестрации supervisor, параллельную обработку данных, логику принятия решений ReAct, оценку критиков и попытки повтора — реализуемые с использованием LangGraph, Strands, Bedrock, AgentCore, Step Functions или пользовательского кода.
Выбор шаблонов в условиях ограничений
При определении топологии следует учитывать бюджеты, связанные с задержками, токенами и сложностью работ в режиме дежурства. Последовательные конвейеры проще аудитировать, когда регуляторы обращают внимание на порядок выполнения операций. Модель распространения данных полезна, когда независимые анализы занимают большую часть времени. Надзорные механизмы необходимы, когда политика маршрутизации должна оставаться централизованной. Графы помогают при наличии необходимости в контрольных точках и человеческом участии. Для ситуаций, требующих свободной передачи задач, необходимы наиболее совершенные инструменты для отслеживания процессов. Выбирайте наименее сложную плоскость управления, которая всё же позволяет четко определять возможные сценарии сбоев.
19. Какую архитектуру следует использовать?
Универсального решения не существует. Необходимо соответствовать структуре управления конкретной проблеме. Полезный вопрос заключается не в том, «какая фреймворков лучше?», а в том, «какой паттерн управления потоками задач требуется для данного рабочего процесса?»
20. Архитектура производства будущего
Системы производства окружают агентов идентификаторами, разрешениями, инструментами, состоянием, памятью, ограничениями, механизмами оценки, возможностями наблюдения, функциями повторных попыток, средствами контроля затрат и подтверждением действий человеком. Индустрия переходит от концепции «агента» к концепции «системы агентов».
21. Основной вывод
Работа с несколькими агентами заключается в разделении функций интеллекта и контроле сотрудничества, а не в создании агентов ради самих по себе. Агенты рассуждают и действуют; надзиратели делегируют задачи; графы контролируют переходы между состояниями; стаи децентрализуют управление; планировщики разделяют задачи на части; проверяющие верифицируют результаты; люди утверждают решения. LangGraph и Strands (среди прочих) предоставляют базовые элементы для реализации. Инженерные вопросы сводятся к тому, какие агенты существуют, как они взаимодействуют, что они могут делать, как проверяются решения и что происходит при сбоях.
Ментальная модель, которую следует запомнить
LLM
↓
Agent
↓
Multi-Agent
↓
Orchestration
↓
Tools + Memory + State
↓
Verification
↓
Observability
↓
Production Agent System
Команды, которые пропускают рассмотрение этой системы, часто увеличивают размер моделей, оставляя вопросы оркестрации, разрешений и оценки без внимания. Эти пробелы проявляются в некорректных результатах, бесконтрольном выполнении инструментов или ситуациях, когда невозможно безопасно откатить действия агентов. Инвестиции в управление потоком выполнения, проверку и человеческий контроль обычно приносят большую пользу, чем простая замена модели.
Будущее — это не только более умные модели. Это также лучшие системы, построенные на их основе.