Кривая затрат, которую никто не моделирует до запуска
Обычный сервис генерирует телеметрию примерно пропорционально количеству обслуживаемых запросов. Агент — нет. Один пользовательский запрос разворачивается в этап планирования, последовательность вызовов инструментов, проход валидации, пару повторных попыток и финальный синтез. Каждый из этих этапов — это спан; каждый спан несёт атрибуты, события и часто полезную нагрузку. Умножение структурное, а не случайное.
Отраслевые отчёты начали называть эту закономерность. Материалы Splunk по наблюдаемости, обсуждения в Network World и публикации Cisco о телеметрии описывают одну и ту же картину: нагрузки, управляемые агентами и LLM, увеличивают объём наблюдаемости быстрее, чем базовый поток запросов, и значительная часть итоговых расходов скрыта, поскольку накапливается в хранении, приёме данных и лицензировании по числу мест, а не в одной видимой статье. См. материалы, связанные со Splunk, обсуждение в Network World и публикации Cisco о наблюдаемости для общего тренда.
Неудобное наблюдение: большая часть этих данных никогда не читается. Они хранятся, потому что хранение — это настройка по умолчанию: SDK трассировки экспортирует всё, бэкенд хранит это в течение настроенного окна, и никто не пересматривает политику, потому что политики нет. Счёт приходит позже, оторванный от решения, которое его вызвало.
Что агенты генерируют, а сервисы — нет
Традиционная телеметрия запросов мала и структурирована: маршрут, код состояния, длительность. Телеметрия агентов велика и семантична. Четыре категории доминируют в объёме.
Полезные нагрузки промптов и ответов. Каждый вызов модели может нести полный входной контекст и полный сгенерированный вывод. Это самые полезные записи для отладки и самые дорогие для хранения, потому что они масштабируются с количеством токенов, а не с количеством запросов.
Аргументы и результаты инструментов. Спан вызова инструмента дёшев; его атрибуты — нет. Аргументы могут быть большими структурированными объектами, а результаты — целыми документами. Когда инструмент вызывается в цикле, одна и та же структура генерируется повторно.
Промежуточные шаги рассуждения. Трассировки планирования, содержимое блокнота и проходы самокритики генерируются на каждом шаге. Они действительно ценны, когда траектория идёт не так, и почти бесполезны, когда всё идёт правильно.
Усиление повторных попыток. Шторм повторных попыток — худший случай с точки зрения соотношения затрат и информации: одна и та же логическая операция трассируется много раз, каждая попытка добавляет спаны, события и атрибуты ошибок. Количество спанов растёт, а предельная информация приближается к нулю, потому что интересный факт — это возникновение цикла повторных попыток, а не содержимое четырнадцатой попытки.
Есть также слой метаданных — количество токенов, идентификаторы моделей, задержка вызова, флаги попадания в кэш — который дёшев на запись и полезен в агрегате. При полной детализации по каждому спану он сам по себе становится существенной статьёй хранения.
Политика сэмплирования, привязанная к точкам принятия решений
Полезная абстракция — не сервис и не тип спана. Это решение. Каждый шаг агента либо читает состояние, либо изменяет состояние, либо решает, что делать дальше. Сэмплирование должно следовать этой классификации.
- Сохраняйте полные трассировки для вызовов инструментов, изменяющих состояние. Записи, удаления, платежи, исходящие сообщения, изменения файлов. Это вызовы, для которых при разборе инцидента понадобятся точные аргументы и точный результат, и где аудиторский след ценен сверх отладки.
- Агрессивно сэмплируйте чтения. Извлечение, поиск и API-вызовы только для чтения можно сэмплировать с низкой частотой с помощью head-based сэмплирования в корне трассировки или tail-based сэмплирования по статусу ошибки. Потерянная информация мала, потому что чтения воспроизводимы.
- Сохраняйте структурированные сводки на уровне траектории. Для каждой завершённой траектории храните компактную запись: план, упорядоченный список имён инструментов, результат, итоги по токенам, разбивку задержек. Это сохраняет форму произошедшего без полезных нагрузок.
- Сохраняйте сырые полезные нагрузки только при сбое. Когда траектория заканчивается ошибкой, срабатыванием guardrail или видимым пользователю сбоем, повышайте полную трассировку до долговременного хранения. Это tail-based правило, и это самая эффективная настройка в политике.
- Устанавливайте срок хранения по классу решения, а не по сервису. Изменяющий вызов может требовать длинного окна; спан чтения — часов. Выражение срока хранения как свойства класса решения делает политику понятной и позволяет пересматривать её при изменении поведения агента.
Конкретный механизм: аннотируйте каждый спан в момент генерации атрибутом класса решения — read, mutate, decide — устанавливаемым обёрткой инструмента, а не вызывающим кодом. Затем коллектор маршрутизирует по этому атрибуту. Изменяющие спаны идут в хранилище с полной детализацией и длинным окном; спаны чтения — в сэмплированный поток с коротким окном; спаны решений сохраняют атрибуты, но отбрасывают полезные нагрузки. Повышение при сбое обрабатывается tail-процессором коллектора, который ненадолго буферизует трассировку и пересылает её целиком, когда корневой спан несёт статус ошибки. Код агента не меняется; политика живёт в обёртке и конфигурации коллектора, и обе версионируются вместе с агентом.
Компромисс, названный честно
Сэмплирование уменьшает объём доказательств, доступных для разбора инцидента. Это цена, и она реальна. Чтение, которое было отсэмплировано, нельзя восстановить постфактум, и сбой, который окажется важным, может быть не тем сбоем, под который настраивалось tail-правило.
Смягчение — сэмплировать по риску решения, а не равномерно. Равномерное сэмплирование ухудшает каждое расследование одинаково; сэмплирование с учётом риска концентрирует выжившие доказательства там, где расследованию скорее всего они понадобятся. Трассировки, которые важны, выживают с полной детализацией, те, что нет, представлены сводками, а слой агрегированных метаданных остаётся достаточно полным для анализа ёмкости и затрат.
Это нужно решить до выпуска агента. Внедрение политики сэмплирования в работающий агент означает потерю базовой линии: нет чистого сравнения между старым периодом полной детализации и новым сэмплированным, и первый инцидент после изменения диагностируется по другому набору доказательств, чем последний инцидент до него. Проектирование политики вместе с агентом — так же, как проектируются схемы инструментов и guardrails, — даёт стабильную базовую линию с первого дня и режим хранения, который можно настраивать осознанно, а не обнаруживать в счёте.
Стоимость телеметрии — это свойство дизайна агента. Относитесь к ней как к таковой.
