Утверждение к обсуждению
Поставщики описывают агентов, которые работают годами, с ценой, которая гибко меняется в зависимости от активности. Формулировка привлекательна: платите за то, что используете, снижайте масштаб в простое. Но агент, работающий год, — это не длинная сессия чата. Это сервис с состоянием и жизненным циклом, и кривая затрат совсем не похожа на модель с оплатой за токены, которую сейчас предлагают облачные провайдеры и провайдеры моделей.
Отделить маркетинг от инженерии — значит задать простой вопрос: что на самом деле накапливается на длинном горизонте? Ответ — не в первую очередь токены инференса. Это постоянное состояние, периодические пробуждения и работа по исправлению, которая накапливается, когда запуск переживает допущения, заложенные в его первый час.
Постоянная память и векторные индексы
Агент, который помнит месяцами, накапливает записи памяти, эмбеддинги и структуры индексов, которые масштабируются с историей, а не с трафиком. Векторный индекс, который было дёшево перестроить при коротком запуске, становится обузой для хранения и вычислений, когда он содержит год наблюдений. Повторное эмбеддирование — скрытая стоимость: смена модели эмбеддингов, изменение чанкинга или исправление дрейфа часто означают пересчёт векторов для всей истории. Эта операция пропорциональна сохранённой истории, а не текущему объёму запросов.
То же касается эпизодических логов, транскриптов вызовов инструментов и записей решений. Их дёшево добавлять и дорого мигрировать, сокращать или переиндексировать. За год доминирующей статьёй расходов часто становится поддержание состояния, которое редко читается, но должно оставаться согласованным.
Пробуждения и перепланирование
Агент, который просыпается каждый час и не находит работы, всё равно платит за сборку контекста. Путь heartbeat может быть дешёвым при каждом вызове, но он не бесплатен: он загружает недавнее состояние, проверяет условия и решает, нужно ли эскалировать. Если путь пробуждения использует то же окно контекста, что и путь обдумывания, каждое пробуждение без действий оплачивает токены, которые не приводят к изменению состояния.
Перепланирование — другая регулярная статья расходов. Длинные запуски сталкиваются с изменившейся средой, истёкшими учётными данными и сместившимися целями. Каждое перепланирование требует восстановления рабочего набора из памяти, что означает retrieval, ранжирование и сборку промпта. Частота перепланирования зависит от того, насколько нестабильна среда, а не от того, насколько занят агент.
Повторы вызовов инструментов и сверка
Длинные запуски накапливают частичные сбои. Вызов API, который завершился успешно, но ответ был потерян; запись, которая прошла дважды; нижестоящая система, которая сменила схему посреди запуска. За год это не редкие события; это нормальный фоновый уровень распределённых систем. Стоимость — это сверка: обнаружение расхождений, решение о том, какое состояние является авторитетным, и его исправление.
Работа по сверке растёт сверхлинейно с числом интегрированных инструментов и длиной запуска, потому что каждая новая интеграция добавляет новый режим отказа и новый путь исправления. Короткий запуск может игнорировать большую часть этого. Годовой запуск — не может.
Разделяйте дешёвый путь heartbeat и дорогой путь обдумывания
Heartbeat должен быть небольшой детерминированной проверкой, которая выполняется по расписанию и не вызывает большую модель, пока не выполнено условие. Обдумывание должно быть отдельным путём со своим бюджетом, запускаемым явными сигналами. Это разделение — самый эффективный способ контролировать стоимость простоя, потому что оно не даёт пробуждениям без действий потреблять контекст уровня обдумывания.
Конкретный механизм: heartbeat читает компактный дайджест состояния (несколько килобайт) и вычисляет набор правил. Если ни одно правило не срабатывает, он записывает метку времени и завершается. Только когда правило срабатывает, агент собирает полный рабочий набор и вызывает модель. Компромисс — задержка: heartbeat не может принимать тонкие решения, поэтому некоторые условия будут пропущены до следующего цикла обдумывания. Это приемлемо для большинства целей на длинном горизонте, но не для всех.
Ограничивайте контекст на каждое пробуждение и включайте в рабочий набор только дельты
Длинные запуски соблазняют команды передавать всю историю в каждый вызов. Это самый быстрый способ сделать стоимость пропорциональной длине запуска, а не активности. Вместо этого ограничьте рабочий набор и включайте только дельты: новые наблюдения, изменившиеся выходы инструментов и явные решения с момента последнего обдумывания. Остальное остаётся в холодном хранилище и извлекается по требованию.
Компромисс — качество retrieval. Ограниченный рабочий набор может упустить релевантный контекст, который был бы включён в промпт со всей историей. Средство смягчения — шаг retrieval, который сам имеет бюджет, с чётким прави
Server rack closeup
Определяйте терминальное условие для каждого запуска
Агент без конечного состояния — это подписка. У каждого запуска на длинном горизонте должно быть явное терминальное условие: цель, которую можно отметить выполненной, дедлайн или порог отказа, останавливающий запуск. Без него агент будет продолжать просыпаться, перепланировать и накапливать состояние бесконечно, и кривая затрат это отразит.
Терминальные условия также делают ценообразование понятным. Запуск с определённым концом можно оценить по завершённой цели. Запуск без него можно оценить только по времени, а именно эта модель делает агентов на длинном горизонте дорогими.
Что инструментировать
Стоимость на завершённую цель, а не стоимость на токен. Стоимость токенов — это вход; цель — это выход. Инструментирование цели позволяет сравнивать запуски и обнаруживать, когда запуск дрейфует в бессрочное сопровождение.
Соотношение простоя и активности и доля пробуждений, не приведших к изменению состояния. Эти две метрики раскрывают путь heartbeat. Высокое соотношение простоя и активности не обязательно плохо, но высокая доля пробуждений, которые не приводят к изменению состояния и всё равно потребляют контекст уровня обдумывания, — явный сигнал, что пути не разделены.
Ежемесячная задача очистки, которая удаляет записи памяти, больше не упоминаемые ни одним решением. Память, которая никогда не читается, — это расходы на хранение без пользы, и она ухудшает качество retrieval, добавляя шум. Задача очистки должна быть консервативной: удалять записи только тогда, когда ни одна запись решения на них не ссылается, и сохранять tombstone, чтобы удаление было аудируемым.
Компромисс здесь — полнота. Очистка может удалить контекст, который будущее решение сочло бы полезным. Средство смягчения — очищать по ссылкам, а не по возрасту, и сохранять tombstone, чтобы промах retrieval можно было проследить до намеренного удаления, а не до тихой потери.
Что меняется для ценообразования
Если доминирующие затраты — это состояние простоя, хранение и перепланирование, то ценообразование, которое гибко меняется только с активностью, будет занижать цену для длинных запусков и завышать для коротких. Более честная модель следует жизненному циклу запуска: стоимость создания состояния, регулярная стоимость его поддержания и стоимость завершения и сверки. Ценообразование на основе активности может находиться поверх этого, но не может это заменить.
Инженерное следствие: агенты на длинном горизонте должны проектироваться с той же дисциплиной, что и любой сервис с состоянием: явный жизненный цикл, ограниченные рабочие наборы, разделённые горячие и холодные пути и инструментирование, которое измеряет цель, а не вход. Именно это делает годовой запуск понятным и именно это делает эластичное ценообразование осмысленным, а не декоративным.