Один материал — полная картина: от single agent к мультиагентному конвейеру в 2026

В прошлом году мы собрали для B2B SaaS «универсального агента поддержки»: один system prompt с персонами пресейла, постпродажи, котировок и troubleshooting плюс FAQ на двадцать страниц. Первая неделя — восторг. На третьей он гонял upsell внутри тикетов на возврат и слал клиентам внутренние кодовые имена.

Никто не обвинил модель в глупости. Проблема была простой: четыре должности — один сотрудник. В 2026 консенсус крепнет: single agent не умер, но подходит для задач с чёткими границами и короткой цепочкой инструментов. Как только нужны исследование → спека → код → тесты → ревью → релиз — многоэтапная, параллельная, взаимно корректирующая работа — пора проектировать мультиагентный конвейер.

Без энциклопедии «что такое агент» — только путь миграции из OpenClaw, IDE-агентов и внутренних PoC. Если память и стоимость уже болят, смотрите Agent Memory vs лог чата и счёт команды агентов.

Эра single agent: силён в роли, слаб в сотрудничестве

Ранние продукты соревновались в «экспертности» system prompt и плавности смены персон. Параграфы «старший архитектор», «язвительный ревьюер», «терпеливый PM» — модель меняет тон в одном треде. Это single-agent role-playing.

Плюсы очевидны: один деплой, короткий trace, простой дебаг. Cursor, Claude Code и кастомные GPT довели эту линию в 2024–2025.

Потолок тоже:

• Загрязнение контекста—заметки, diff и логи тестов в одном окне; поздние шаги наследуют шум.
• Размытая ответственность—неясно, планирование или исполнение сломалось; один этап не перезапустить.
• Нулевой параллелизм—модель думает линейно, команды — нет.
• Сложно разделить права—агент кода и агент прод-БД не должны делить один набор tools; один prompt это плохо режет.

Когда задача — не «ответить», а «отдать mergeable PR», утолщение prompt даёт мало. Это не деградация модели — форма задачи стала инженерной: нужны handoff, контракты и replay.

Эра мультиагентов: от «один актёр — много масок» к handshake

Мультиагентная коллаборация меняет метафору: не один актёр в масках, а несколько ролей на сцене, связанных режиссурой и сценарием. Planner только декомпозирует, Coder трогает разрешённые пути, Reviewer читает diff без права «поправить пару строк».

Выравнивание через три механизма:

• Общее состояние—планы, снимки дерева, результаты тестов, todo в графе или store, не в чате.
• Структурированные передачи—JSON, patch, checklist; следующий шаг ест только валидные поля, не «см. выше».
• Завершение и арбитраж—готово, эскалация человеку, rollback решает Evaluator или правило, не последний агент.

Разбив «универсальную поддержку» на Intent Router, FAQ Retriever, Ticket Writer и Escalation Guard, мы свели утечки внутреннего жаргона к нулю — не сменой модели, а отсутствием клиентских tools у Escalation Guard.

Внутри одного агента: ReAct и слои

Перед разбиением на команду разберите анатомию одного агента. LangChain, OpenAI Agents SDK, Cursor — скелет в 2026 похож:

Сверху вниз:

• Слой инструкций—system prompt, AGENTS.md, Skills переводят цели в ограничения. Skills — переиспользуемые подпрограммы до апгрейда в узел.
• Цикл ReAct—Reason → Tool → Observe. Сердце агента.
• Tools и runtime—filesystem, Git, sandbox. MCP — де-факто стандарт 2026.
• Детерминированные ограничения—hooks, middleware, evaluators вне цикла.
• Состояние и память—планы, логи, store питают следующий ReAct реальностью, не галлюцинацией прогресса.

Мультиагенты не выбрасывают диаграмму — копируют блоки и связывают графом. LangGraph разделяет сообщения внутри треда и cross-thread store (концепции памяти).

Паттерны конвейера: четыре топологии

«Мультиагенты» ≠ «больше голов». Сначала топология:

Тренд 2026: выносить детерминированное из LLM. Формат, lint, тесты, теги — в CI или hooks; агент думает и чертит черновик. На cloud Mac агент шлёт diff, xcodebuild всегда в изолированном runner — как «разработчики не трогают прод».

Концепции multi-agent LangChain моделируют Supervisor, Swarm, Handoff как рёбра графа — ребро важнее модели.

Стек 2026: Harness / Framework / Runtime

Больше трёх узлов в IDE, VPS или cron — «один Python со prompt'ами» не масштабируется. Три слоя:

Runtime (LangGraph) — какой узел следующий, где состояние, как rollback. LangGraph как Pregel supersteps для глобального планирования.

Framework (LangChain) — модели, tools, RAG как детали без навязанной топологии.

Harness (DeepAgents и др.) — тест, деплой, согласование с людьми; гонка 2026 — кто вывозит в прод, а не кто умнее звучит.

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

Минимум для внутренних пилотов — без привязки к вендору:

• Граф состояний, не оргструктура—узлы = глаголы, рёбра = контракты данных.
• Schema на каждую передачу—JSON Schema для частичных retry.
• Минимальные tools на узел—reviewer только чтение.
• Один trace id на всю цепочку.
• Слои памяти—внутри треда, между сессиями, RAG раздельно.
• Бюджет по узлам—большая модель планирует, малая форматирует.

Делите и execution: шлюз OpenClaw на VPS, xcodebuild и тяжёлая browser-автоматизация на облачном Mac — чтобы один ноутбук не был и мозгом, и мышцами, уходящими в офлайн при закрытии крышки.

Ещё вопросы