Один агент или multi-agent: как выбирать архитектуру без лишней оркестрации

Короткий ответ

Один агент или multi-agent: как выбирать архитектуру без лишней оркестрации — это production-задача, а не демонстрационный prompt. Практический принцип: начинать с одного агента и выделять специалистов только там, где различаются права, контекст, инструменты или критерии приёмки. Ключевое решение: multi-agent оправдан организационной или технической границей, а не желанием имитировать отдел инженеров. В инженерной среде результат принимается по evidence, traceability и воспроизводимой проверке, а не по уверенности формулировки модели.

Agent/RAG-платформы быстро меняются. Технические ссылки этой статьи проверены 02.10.2026; перед внедрением перепроверяются статусы API, preview/GA, лимиты, хранение данных и доступность функций.

Граница системы и предмет контроля

Агентный контур отличается от обычного чата наличием цикла действий. Модель не только формирует текст, но выбирает инструмент, передаёт типизированные аргументы, получает результат, обновляет состояние и решает, требуется ли следующий шаг. Поэтому объект проектирования — не prompt как строка, а полный runtime: модель, tools, permissions, state, approvals, verifier и журнал выполнения.

Для инженерного применения критично отделять рассуждение и предложение действий от изменения реальных данных. Чтение справочника, расчёт в детерминированном модуле, создание рабочей копии CAD-файла и выпуск утверждённой ревизии имеют разный риск. Права должны назначаться по операциям, а не по факту того, что «агенту нужен доступ к системе». Это позволяет увеличивать полезную автономность без потери управляемости.

Рабочее правилоmulti-agent оправдан организационной или технической границей, а не желанием имитировать отдел инженеров. Это правило должно быть закреплено в runtime policy, а не существовать только как рекомендация пользователю.

Что должно быть определено до запуска

карта задачФиксируется явно, имеет owner и проходит валидацию до использования в следующем шаге.

границы доменовФиксируется явно, имеет owner и проходит валидацию до использования в следующем шаге.

набор инструментов по ролямФиксируется явно, имеет owner и проходит валидацию до использования в следующем шаге.

объём общего контекстаФиксируется явно, имеет owner и проходит валидацию до использования в следующем шаге.

правила передачи ответственностиФиксируется явно, имеет owner и проходит валидацию до использования в следующем шаге.

Артефакты и архитектурные границы

Архитектуру агента удобно раскладывать на control plane и execution plane. В control plane находятся policy, identity, лимиты, approvals и выбор маршрута; в execution plane — конкретные tools, очереди, sandbox и внешние API. Такое разделение не даёт модели самостоятельно расширять собственные полномочия и позволяет независимо версионировать orchestration и исполнительные компоненты.

Контракт tool должен быть строже естественного языка: схема аргументов, единицы, enum, обязательность полей, idempotency key, ожидаемые ошибки и postcondition. Если инструмент меняет реальный объект, ответ «200 OK» недостаточен — нужен change receipt и повторное чтение состояния либо другой независимый verifier.

routing matrixEvidence для аудита и сравнения версий; по нему восстанавливается фактическое выполнение.

handoff contractКонфигурационно управляемый объект: version, owner, change history и дата действия.

shared context schemaКонфигурационно управляемый объект: version, owner, change history и дата действия.

specialist toolsetИмеет стабильный идентификатор, статус приёмки и связь с исходной задачей.

end-to-end traceEvidence для аудита и сравнения версий; по нему восстанавливается фактическое выполнение.

Практический workflow

Шаг 1. решить задачу одним агентом как baseline. Сначала исключите неоднозначность цели: агент не должен сам изобретать критерий завершения.

Шаг 2. выделить реальные конфликтующие контуры. Tool contract валидируется отдельно от prompt и имеет тесты на неверные аргументы.

Шаг 3. определить specialist contracts. Write-операции отделяются отдельным permission и не наследуются от read-доступа.

Шаг 4. ввести один формат handoff payload. Checkpoint сохраняет уже выполненные side effects и контекст следующего шага.

Шаг 5. проверить loop prevention. Verifier должен быть независим от генеративного утверждения, где это возможно.

Шаг 6. сравнить качество и цену с baseline. Trace должен позволять восстановить последовательность действий без чтения скрытого reasoning.

Шаг 7. оставить multi-agent только при измеримом выигрыше. До повышения прав версия обязана пройти regression и негативные cases.

После tool-call проверяется не текстовый комментарий модели, а фактический результат инструмента: код возврата, схема ответа, изменённый объект и ожидаемая postcondition. Несовпадение переводит задачу в controlled exception и блокирует следующий side effect.

Инженерный сценарий

Входкарта задач; границы доменов; набор инструментов по ролям; объём общего контекста; правила передачи ответственности. Данные должны быть привязаны к проекту, revision и владельцу.

Действиеначинать с одного агента и выделять специалистов только там, где различаются права, контекст, инструменты или критерии приёмки. Каждый tool-call проходит серверную валидацию и попадает в trace.

Контрольявные условия handoff; минимизация копирования истории; единый owner финального результата; ограничение рекурсии; согласованный формат артефактов. Для критических изменений добавляется независимое подтверждение.

Выходrouting matrix; handoff contract; shared context schema; specialist toolset; end-to-end trace. Финальный результат должен быть пригоден для повторной проверки без скрытого контекста.

Для agent workflow удобно иметь три режима: dry-run без side effects, execute-with-approval и bounded execution. Переход между ними определяется классом риска и зрелостью eval-набора.

Что измерять

handoff accuracyСчитайте на одну успешно завершённую задачу и анализируйте хвост распределения.

handoff countСчитайте на одну успешно завершённую задачу и анализируйте хвост распределения.

end-to-end latencyСмотрите распределение, минимум median и p95; отдельно выделяйте timeout/длинный хвост.

context tokens per taskСчитайте на одну успешно завершённую задачу и анализируйте хвост распределения.

cross-agent defect rateПоказывайте абсолютное число и нормированную частоту; critical события не усредняйте с обычными.

Для агента итоговая точность без анализа траектории недостаточна. Одновременно контролируют success, выбор tools, число шагов, вмешательства человека, policy violations, latency и стоимость успешной задачи.

Критерии приёмки

Контроль	Минимальный критерий
Scope	Для «Один агент или multi-agent: как выбирать архитектуру без лишней оркестрации» однозначно определено, что система делает и что остаётся вне её полномочий.
Data	Все входы имеют источник, revision/status и область применимости; неизвестные значения не подставляются автоматически.
Control	явные условия handoff; минимизация копирования истории; единый owner финального результата.
Evidence	Сохраняются routing matrix, handoff contract, shared context schema, specialist toolset; по ним можно восстановить ход операции.
Quality	Минимум две профильные метрики контролируются на versioned eval-наборе: handoff accuracy и handoff count.
Release	Изменяющие действия имеют approval/rollback там, где цена ошибки выходит за согласованный риск.

Failure modes и защитные меры

Главная ошибка — считать правильный финальный ответ доказательством правильной траектории агента. В production проверяются выбранные tools, аргументы, approvals, фактические side effects и postconditions.

агенты передают задачу по кругу. Защитная мера: явные условия handoff; событие сохраняется как regression/incident case.
контекст разрастается и дорожает. Защитная мера: минимизация копирования истории; событие сохраняется как regression/incident case.
разные специалисты меняют одни и те же данные. Защитная мера: единый owner финального результата; событие сохраняется как regression/incident case.
ответственность за финал размыта. Защитная мера: ограничение рекурсии; событие сохраняется как regression/incident case.
маршрутизация сложнее самой задачи. Защитная мера: согласованный формат артефактов; событие сохраняется как regression/incident case.

Как переводить из пилота в production

Пилотный агент получает один класс задач и минимальный набор tools. Сначала снимаются traces в read-only/dry-run, затем добавляются approvals для side effects. Model upgrade и изменение tool schema проходят один и тот же regression suite; несовместимый schema change блокирует rollout.

Перед выдачей write-доступа отдельно тестируют timeouts, retry, duplicate delivery, partial failure и отмену задачи. Canary-версия получает ограниченную долю трафика и budget; превышение intervention/rollback threshold автоматически возвращает стабильную версию.

Traceability и эксплуатационная запись

Минимальный trace: task ID, actor identity, model/runtime, prompt/template, список доступных tools, каждый tool-call с аргументами и результатом, policy decision, approval, state transition, verifier и final status.

Чек-лист перед production

КонтрактScope, входы, tools и stop condition описаны до запуска.

ПраваRead/write, сеть и секреты ограничены минимально необходимым.

EvidenceКаждый критичный вывод или action связан с источником и trace.

EvalsЕсть обычные, граничные, негативные и regression cases.

RollbackДля side effect проверено восстановление, а не только наличие команды отката.

OwnerНазначен владелец качества процесса и владелец технической платформы.

Навигация по Wave AI R5 · часть 1 из 5

Часть «Агенты» содержит 7 связанных материалов. Серия идёт от архитектуры к контролю и измерению; каждая статья самостоятельна и ссылается на соседние элементы общего production-контура.

1. ИИ-агент в инженерной системе: runtime, tools, state и verifier 2. Один агент или multi-agent: как выбирать архитектуру без лишней оркестрации 3. Tool calling для инженера: типизированные контракты вместо «сделай что-нибудь»4. MCP и корпоративные инструменты: как подключать агент к системам без бесконтрольного доступа 5. Память агента: session state, проектный контекст и долгоживущие знания 6. Human-in-the-loop: где ставить approval gates в инженерном агенте 7. Observability агента: traces, spans, tool calls и разбор отказов

← ИИ-агент в инженерной системе: runtime, tools, state и verifier Tool calling для инженера: типизированные контракты вместо «сделай что-нибудь» →R4: Decision log и traceability

Связать AI-контур с проверяемыми данными Fits Calc

Fits Calc целесообразно использовать как детерминированный расчётный и справочный слой: агент получает структурированные входы и результаты через контролируемые tools, а не воспроизводит инженерный расчёт свободным текстом. Это упрощает verifier, traceability и повторную проверку.

Открыть Fits Calc →

Источники и официальная документация

Проверено: 02.10.2026Production controls обязательныHuman approval — по риску действия