Эпоха простого proof-of-concept'а — один вызов API, один ответ — закончилась в 2023-м. К 2026-му компании, переносящие LLM в production, сталкиваются с тем, что мы называем "многоагентной оркестрацией": несколько моделей одновременно, каждая имеет доступ к своим инструментам, работают параллельно или последовательно, полностью наблюдаемы и воспроизводимы. В этой статье мы разберём, какие решения вы принимаете при построении многоагентной архитектуры, что действительно обещают SDK-и и какие трейдоффы скрывают разные топологии оркестрации.
Что Обещают Agent SDK'и и Что Они Дают
LangChain, CrewAI, Semantic Kernel, LlamaIndex — все позиционируют себя как "agent SDK". Общее обещание: дайте LLM право использовать инструменты, установите иерархию принятия решений, управляйте цепочками. Но работает ли это на практике в production?
Первая проблема: abstraction overhead. Высокоуровневые библиотеки типа LangChain упрощают binding инструментов, но усложняют отладку. Когда в production вызов инструмента падает, непонятно — это ошибка внутреннего состояния LangChain или ответ API? Приходится парсить trace'и. Если у вас есть нативная поддержка инструментов, как в Anthropic Computer Use API, использование SDK напрямую обычно даёт лучшую видимость.
Вторая проблема: versioning. Agent SDK'и быстро эволюционируют, breaking changes выходят часто. LangChain 0.1 → 0.2 deprecate'ил целые структуры цепочек. Вместо того чтобы ждать патчей с пиненной версией, иногда проще реализовать tool use логику самостоятельно. Особенно если ваша оркестрация содержит специфичную business логику — SDK'и слишком opinionated для таких случаев.
Третья выгода: встроенная наблюдаемость. LangSmith, eval suite LlamaIndex визуализируют цепочку вызовов. Это критично для production отладки — какой агент вызвал какой инструмент, где произошла задержка, сколько token'ов потратила каждая prompt. Если вы пишете оркестрацию с нуля, эту телеметрию нужно реализовать самостоятельно. SDK'и здесь экономят время, но несут risk lock-in'а.
Tool Use: Выше Function Calling
Tool use — это когда LLM генерирует структурированный output для запроса к внешним API. OpenAI function calling, Anthropic tool use, Google function calling — одна идея, разные форматы. Интересная часть — зависимости между инструментами.
Простой пример: автоматизация email-кампаний. Инструмент 1: list_segments (список сегментов из CRM). Инструмент 2: get_segment_stats (метрики по сегменту). Инструмент 3: create_campaign (создание кампании). Эти три нужно вызывать последовательно, потому что output каждого — input для следующего.
Сложный пример: агент аналитики. query_bigquery, fetch_gsc_data, fetch_ga4_events можно вызвать параллельно — они независимы. Параллельное выполнение снижает latency в production, но оркестратор должен управлять concurrency limit'ом и rate limit'ом. Anthropic SDK поддерживает параллельные tool call'и, а OpenAI function calling последователен (по состоянию на Q2 2026). Значит, вы пишете оркестратор сами.
Критический трейдофф в tool use: детерминизм vs. гибкость. Если вы скажете LLM "выбери один из этих трёх инструментов", каждый run может выбрать по-разному. Если жёстко закодировать последовательность, теряется гибкость, но выигрываете воспроизводимость. В production обычно гибридный подход: критичный путь hard-code, опциональные решения оставляете LLM.
Пример Цепочки Tool Вызовов
# Последовательная цепочка (output одного = input другого)
def orchestrate_campaign(prompt: str, client: AnthropicClient):
# 1. Получить список сегментов
segments = client.tool_use("list_segments", {})
# 2. Стат для каждого сегмента (параллельный batch)
stats_calls = [
client.tool_use("get_segment_stats", {"segment_id": s})
for s in segments["ids"]
]
stats = asyncio.gather(*stats_calls)
# 3. Кампания для сегмента с лучшей engagement
best_segment = max(stats, key=lambda x: x["engagement"])
campaign = client.tool_use("create_campaign", {
"segment_id": best_segment["id"],
"message": prompt
})
return campaign
Здесь структура: list_segments → get_segment_stats (параллельно) → create_campaign (последовательно). LLM участвует только в финальной генерации сообщения — это полу-автономная архитектура. Логикой tool вызовов управляет оркестратор.
Параллельная vs. Последовательная Топология
В многоагентных системах две основные топологии: параллельная (множество агентов работают одновременно, output'ы объединяются) и последовательная (каждый агент создаёт input для следующего).
Параллельная топология обычно используется для специализации. Пример: pipeline создания контента. Агент A пишет заголовок, Агент B создаёт параграфы тела, Агент C оптимизирует SEO-описание. Все три получают один и тот же brief, output'ы объединяются. Преимущество: каждый агент специализируется в своей области, prompt'ы короче, token'ов дешевле (контекст не раздувается). Недостаток: координационный overhead. Merge logic ваша ответственность — если output'ы противоречивы, нужна ручная согласованность.
Последовательная топология для уточнения и валидации. Агент A генерирует черновик, Агент B fact-check'ит, Агент C корректирует тон. Каждый получает output предыдущего. Преимущество: каждый этап улучшает предыдущий, reasoning'е логичен, easy to debug. Недостаток: latency — каждый агент ждёт своей очереди. Общее время = N × средняя latency агента.
В Roibase мы используем гибридный паттерн для Geo-оптимизации контента: параллельные агенты скраппят citation'ы из разных search engine'ов (ChatGPT, Perplexity, Gemini), последовательная цепочка агентов согласовывает эти citation'ы с brand mention pattern'ами. Параллельная часть ускоряет сбор данных, последовательная обеспечивает глубину анализа.
Сравнение Топологий
| Архитектура | Latency | Специализация | Отладка | Use Case |
|---|---|---|---|---|
| Параллельная | Низкая (макс длит агента) | Высокая | Merge logic сложен | Сбор данных, анализ из множества источников |
| Последовательная | Высокая (сумма latency'ей) | Низкая | Linear trace | Уточнение, валидация, multi-step reasoning |
| Гибридная | Средняя | Высокая | Сложная | Production pipeline'ы |
Orchestration State и Воспроизводимость
Построив многоагентную систему, главное решение: где хранить state? Три варианта.
Stateless оркестрация: Каждый агент независим, промежуточные output'ы оркестратор держит в памяти. Преимущество: replay просто, горизонтальное масштабирование возможно. Недостаток: memory pressure — в длинной цепочке потратите ГБ на conversation history.
Stateful оркестрация: Промежуточный state сохраняется во внешнее хранилище (Redis, PostgreSQL). Преимущество: низкий memory usage, crash recovery. Недостаток: I/O overhead, нужны гарантии консистентности.
Гибридный (checkpointing): State сохраняется на ключевых milestone'ах. Например, каждые 5 вызовов агента — checkpoint. При crash восстанавливаетесь с последнего checkpoint. Преимущество: баланс между performance и reliability. Недостаток: complex implementation.
В production паттерн, который мы используем в First-Party Data & Измерение: писать orchestration state в log stream. Каждый вызов агента — structured log в BigQuery, для replay используется event sourcing. Так можно ретроспективно анализировать attribution chain — какой output агента повлиял на какую downstream метрику.
Eval и Observability: Отладка Оркестрации
В многоагентной системе отладка сложная — точек отказа много. Агент A выбрал неправильный инструмент? Агент B неправильно спарсил input? Оркестратор неверно объединил output'ы? Observability stack обязателен.
Метрики, которые нужны:
- Agent-level latency (p50, p95, p99) — какой агент bottleneck?
- Tool success rate — какой API call часто падает?
- Token usage per agent — cost attribution
- Eval score — используя LLM-as-judge, оценивайте каждый output агента 0–1
Паттерн eval'а, который мы используем: reference-free scoring. Supervisor LLM (например, GPT-4) оценивает каждый output агента по скорам "task completion" и "hallucination". Эти скоры сохраняются как time series, детектируется регрессия. Если hallucination score Агента A вырос с 0.1 до 0.3, откатываете версию prompt'а.
Другой паттерн от Anthropic: Claude как evaluator. Большой context window позволяет передать всю цепочку агентов в одном prompt'е и спросить: "есть ли логические ошибки в цепочке?" Эта мета-evaluation используется перед production deploy'ом в процессе QA.
Tradeoff'ы Оркестрации и Матрица Решений
Выбирая многоагентную архитектуру, смотрите на эти трейдоффы:
1. Complexity vs. control: SDK ускоряет implementation, но obscure'ит отладку. Custom оркестратор даёт control, но требует maintenance.
2. Latency vs. specialization: Параллельные агенты быстры, но усложняют координацию. Последовательные глубже reasoning, но медленнее.
3. Cost vs. quality: Каждый вызов агента — token cost. Больше агентов = лучше качество, но cost растёт линейно. В production нужно найти "minimum viable agent count".
4. Determinism vs. adaptability: Hard-coded tool sequence'ы reproducible, но не handle edge case'ы. LLM выбирает инструменты — адаптивно, но non-deterministic.
Матрица решений, которую мы используем в Roibase:
| Usecase | Топология | SDK | State Management |
|---|---|---|---|
| Сбор данных | Параллельная | LlamaIndex | Stateless |
| Уточнение контента | Последовательная | Custom | Checkpointing |
| Real-time inference | Гибридная | Anthropic SDK | Redis cache |
| Batch processing | Параллельная | LangChain | PostgreSQL |
Перенос Оркестрации в Production
Когда многоагентная система идёт в production, три вещи критичны.
Rate limiting: Параллельные агенты превышают rate limit API. В оркестраторе используйте token bucket или semaphore pattern. Если у Anthropic API лимит 50 req/min, число параллельных агентов throttle по этому.
Fallback strategy: Что если агент упадёт? Простой retry с exponential backoff + jitter. Если агент не критичен (например, опциональный SEO tag generator), используйте circuit breaker и переходите в fail-safe mode.
Cost monitoring: Логируйте token cost для каждого вызова агента. В production отслеживайте метрику $/request по агентам. Если какой-то агент создаёт cost spike, оптимизируйте его prompt или отключите.
Сила многоагентной оркестрации не в том, чтобы "делать больше, чем один LLM", а в том, чтобы сделать бизнес-процессы модульными, наблюдаемыми и масштабируемыми. Для долг