AgentScope 2.0.9: агенту нужен регламент с приёмкой шагов

Допустим, агент выполняет один шаг правильно в 95% случаев.

Тогда цепочка из 10 шагов без проверок пройдёт без ошибки примерно в 60% случаев (0,95 в десятой степени).

При точности 90% на шаг останется 35%.

Цифры условные, механизм реальный: ошибка на третьем шаге незаметно доходит до десятого, и на выходе получается аккуратно оформленный неверный результат. Пример из интеграционной практики.

Агент сопоставляет прайс поставщика с каталогом в PIM, пересчитывает цены и выгружает их в 1С.

Если агент перепутал артикулы при сопоставлении, выгрузка всё равно пройдёт без технических ошибок, и неверные цены первыми увидят покупатели.

Обычно компании в такой ситуации переходят на более мощную модель.

Точность на шаге вырастает на несколько процентов, но цепочка без проверок остаётся хрупкой: каждая дополнительная ступень снова умножает вероятность сбоя.

Веха - это кусок работы с заранее заданным критерием готовности.

Агент выполняет веху, затем код или человек через `/sop` проверяет её, и только после этого стартует следующая.

Если проверка не прошла, агент повторяет одну эту веху, а прогон с начала перезапускать не нужно.

Сохранённое состояние решает вторую проблему продакшена.

Если упал сервис, истёк таймаут у API провайдера или оператор остановил процесс на ночь, прогон продолжится с последней принятой вехи.

Для задачи, которая идёт часами и расходует токены, это прямая экономия денег.

Ручная проверка через API позволяет вставить в процедуру подпись ответственного сотрудника там, где ошибка дорого стоит: при изменении цен, отправке документов в ЭДО, записи проводок в учётную систему.

Инженеры давно применяют эту логику в CI/CD: сборка попадает в прод только после тестов.

Разработчики AgentScope перенесли её на агентов.

Модуль помечен как экспериментальный, его API ещё может поменяться, поэтому строить на нём критичный прод сегодня рискованно.

Сам принцип можно применять уже сейчас на любом фреймворке или на собственном оркестраторе.

TeamPipeline ускоряет задачи, которые делятся на независимые части: разбор пачки договоров, проверку карточек товаров по категориям, сверку остатков по складам. У параллельности есть цена: каждый участник тратит свои токены и добавляет свою точку отказа.

Если результаты участников никто не проверяет, лидер собирает итог из непроверенных кусков.

Поэтому мы используем SOP и TeamPipeline в паре: участники работают параллельно внутри вехи, а на её границе результат проверяют.

Три голосовых провайдера позволяют выбрать по цене, задержке и качеству речи. У российских компаний есть дополнительный вопрос: голос клиента в звонке содержит персональные данные, и передачу таких данных зарубежному провайдеру юристам нужно проработать отдельно, до запуска пилота.

Четыре правила, которые мы применяем в проектах AI-native integration: 1. Сначала регламент, потом модель.

Если сотрудник не может перечислить шаги процесса и критерии приёмки каждого шага, агент с этим процессом тоже не справится. 2. Машинная проверка там, где она возможна.

Сверка сумм, валидация по JSON-схеме, контрольные остатки.

Человека подключаем там, где ошибка обходится дороже его времени. 3. Сохранённое состояние.

Длинный процесс должен переживать сбой без потери выполненной работы. 4. Модели за шлюзом.

Наш LLM & Security Gateway логирует запросы, маскирует персональные данные и позволяет сменить провайдера (GigaChat, YandexGPT, Qwen, Claude) без переписывания агента.

Агент получает доступ к 1С, PIM и CRM через MCP-серверы с ограниченными правами.

Шаги оркестрации и события проходят через Kafka или n8n, поэтому каждая веха видна в логах, и её можно перезапустить отдельно. Снаружи схема выглядит простой.

Чтобы она работала, команда до первого демо строит контракты данных, тесты и мониторинг.