Vlad S

В первоисточнике: с шутками и песнями)))

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

Согласен, асинхронный сбор логов постфактум не защищает от первого необратимого действия, а лишь фиксирует инцидент.
В предложенной архитектуре этот риск компенсируется за счет разделения проверок:
1. Синхронный Policy Check (Safe-Action Engine) перехватывает деструктивные вызовы вроде pay или delete до их отправки во внешнюю инфраструктуру. На этом этапе критические операции блокируются до подтверждения оператором (Human-in-the-Loop).
2. Асинхронный Action Trace используется для логирования некритичных событий (чтение, промежуточные рассуждения агента, изменения состояния). Это позволяет не создавать лишних задержек в производительности системы.

Замечание про необходимость идемпотентности на стороне API также полностью справедливо. Без механизмов вроде Idempotency-Key сетевые сбои или повторные вызовы со стороны агента неизбежно приведут к дублированию транзакций.

Классическая ловушка "ошибки выжившего" наоборот: если объем агентских операций вырос, например, в 10 раз, то рост сбоев на 62% — это на самом деле гигантский качественный скачок в стабильности систем.
Считать инциденты на 1000 вызовов + долю корректных эскалаций — это уже зрелый продуктовый подход к ИИ, а не просто хайп-метрики.
Про границы автономности мысль отличная, зафиксировал.

Я согласен, что на практике самая сложная часть: это не столько retrieval, сколько управление самими связями. Откуда они появились, насколько можно доверять источнику и когда эти связи перестают быть актуальными?
GraphRAG это не инструмент на все случаи жизни. Для простых фактов часто быстрее и чище работает обычный RAG, а граф действительно раскрывает себя там, где нужно пройти по сложным цепочкам связей.

Egress-контроль и поведенческий профилинг действительно закрывают ключевые слепые зоны.
По egress-контролю согласен полностью: проверка того, что и куда агент отправляет, решает проблему эксфильтрации через легитимные API, если белые списки подкреплены валидацией структуры запросов.
По поведенческому базису сделаю лишь одну оговорку: классический аномалия-детект идеально работает на детерминированных рабочих агентах, где норма стационарна, но пасует на исследовательских системах, где перебор гипотез и хаотичные действия являются штатным режимом. Поэтому профилировать имеет смысл не синтаксис операций, а выходы за границы разрешенного графа намерений конкретной задачи.

Согласен. Ограничение частоты (rate limit) защищает только от шумного перебора, ведь умный агент просто увеличит задержку между запросами и обойдет фильтр.
Введение суммарного бюджета полномочий на сессию решает эту проблему. Жесткий потолок на объем выгрузки (Egress Budget) остановит утечку данных, выдача токенов с минимальным TTL строго под микро-задачу сузит вектор атаки, а лимит на общее число действий позволит принудительно гасить контейнер при его исчерпании. Контроль ресурсов и намерений здесь действительно эффективнее контроля скорости.

Согласен, средние величины маскируют риски. В агентных системах распределение затрат имеет «тяжелый хвост»: редкие зацикливания обходятся на порядки дороже медианы.
Для защиты маржинальности необходимы три барьера:
- Мониторинг p95/p99: Ключевыми метриками для COGS должны стать хвостовые показатели стоимости задачи, а не среднее арифметическое.
- Финансовый лимит (Token TTL): Введение жесткого лимита бюджета на одну задачу. При достижении 90% от лимита инференс принудительно блокируется.
- Превентивный HITL: Автоматическая заморозка контекста и передача тикета человеку с саммари ошибки, чтобы не сжигать ресурсы на бесконечные циклы.
Без контроля p95/p99 и автоматического брекзита фиксированные тарифы неизбежно ведут к кассовому разрыву из-за нескольких аномальных сессий.

Согласен, расчет честного E2E TCO - задача со звездочкой. Сплит-роутинг оправдан там, где сложность системы становится осознанным выбором для управления рисками и затратами на дистанции. Это переход от простого потребления API к управлению собственной AI-инфраструктурой. Сложно, дорого в разработке, но на масштабе — единственный способ не работать «на аптеку» (то есть на провайдеров моделей).

Цена ошибки (Cost of Error) - важнейший критерий.
В зрелых enterprise-системах роутер оценивает запросы по двум осям: сложность и критичность. Если промпт связан с финансами, юриспруденцией или внешними API-действиями, скор критичности взлетает - и запрос уходит на Frontier-модель автоматически, даже если он лингвистически прост.
Экономия на токенах точно не должна превращаться в расходы на юристов.