Перейти к основному содержанию
Рассуждающий агент, застрявший в цикле повторов, разворачивающий тысячу подзадач или просто убегающий в середине плана, может потратить реальные деньги до того, как кто-нибудь заметит. Вердикт cap_cost firewall — это предохранитель для этого: вы создаёте потолок в центах на прогон один раз, и шлюз отклоняет следующий вызов инструмента в тот момент, когда накопленные траты прогона его пересекают, — до того как этот вызов достигнет модели или инструмента. Это контроль стоимости ИИ-агента, применяемый на шлюзе, а не прикрученный к циклу вашего агента. Как каждый вердикт firewall, правило cap_cost живёт в политике рабочего пространства, привязывается к ключу и вступает в силу на следующем вызове без передеплоя.

​
1. Предохранитель трат на прогон

cap_cost — это вердикт правила, который вы создаёте с одним дополнительным полем — cap_cost_cents, потолком трат прогона в центах USD. Когда правило совпадает с вызовом инструмента, движок сравнивает накопленные траты прогона агента с этим потолком:
  • Под потолком → вызов разрешается; вычисление продолжается.
  • Над потолком → вызов отклоняется, с причиной, называющей общую сумму прогона против потолка. Это терминальный исход-предохранитель — прогон не может выпустить ещё один управляемый вызов до свежего прогона.
Потолок привязан к прогону агента, не к одному запросу. Длинный прогон, уже сжёгший большую часть своего бюджета, отклоняется на своём следующем вызове, даже когда этот один вызов дёшев — предохранитель срабатывает на текущей сумме, а не на маржинальной стоимости.
Область прогона, с откатом на запрос. Когда запрос несёт id прогона агента, потолок применяется к накопленным тратам прогона. Вызов без связи с прогоном (например, голый MCP-диспетч без переданной сессии) вместо этого откатывается к сравнению на запрос. В любом случае предохранитель срабатывает до того, как сверхбюджетный вызов диспетчеризован.

​
2. Один конкретный пример

Ограничьте любой прогон на ключе $5.00 накопленных трат. Единственное wildcard-правило делает это — cap_cost_cents равно 500 (центов): 
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
Создайте его в редакторе правил консоли на политике, которую вы создали (см. Создание и привязку политики). Написание правила — действие Developer+. Привяжите политику к ключу через firewall_policy_id или сделайте её default рабочего пространства, и каждый прогон, которым управляет этот ключ, теперь ограничен. Вы можете ограничить потолок уже, чем «каждый инструмент». Сузьте глоб имени инструмента, так чтобы к предохранителю учитывалось только дорогое семейство вызовов — например, cap_cost на *.search, чтобы ограничить разворачивание веб-поиска, оставляя дешёвые локальные инструменты неучтёнными.
Сложите более дешёвый предупреждающий уровень с приоритетами. Правило audit с меньшим потолком на более высоком приоритете (меньшем числе) позволяет вам наблюдать, как прогон приближается к своему бюджету, в ленте событий до того, как сработает применяющее правило cap_cost. Побеждает первое совпадение, так что ставьте наблюдателя первым.

​
3. Где он срабатывает — и где не может

cap_cost имеет смысл только до того, как вызов диспетчеризован — это та единственная точка, где остановка вызова всё ещё предотвращает траты. Так что он живой на двух pre-dispatch поверхностях и отклоняется на post-dispatch:
Поверхностьcap_cost?
inbound (рекламируемые инструменты)Применяется.
mcp (диспетч tools/call)Применяется.
response (выданные моделью вызовы)Отклоняется при сохранении — останавливать нечего.
egress (исходящее назначение)Отклоняется при сохранении — останавливать нечего.
Правило cap_cost, привязанное к response или egress, отказывается при сохранении, так что правило никогда не может отображаться как живое, будучи неспособным когда-либо отклонить. Оставьте стадию пустой, чтобы покрыть обе pre-dispatch поверхности, или привяжите его к inbound / mcp.
cap_cost_cents обязателен и неотрицателен для правила cap_cost. Консоль и API отклоняют правило cap_cost без потолка, так что неправильно настроенный потолок не может молча пропускать каждый вызов.

​
4. Как выглядит предохранитель, когда он срабатывает

Сверхбюджетный вызов — это обычный deny firewall:
  • На inbound ретрансляция возвращает HTTP 400 с кодом ошибки firewall_blocked. Блокировка срабатывает до вызова вышестоящей модели, так что она не стоит токенов модели, и помечается skip-retry — повторный прогон того же вызова просто снова сработал бы предохранителем.
  • На mcp он возвращается как ошибка инструмента, так что модель видит отказ и может остановиться или спросить пользователя, а не упасть.
Причина deny называет цифры, например cap_cost: estimated run cost $5.40 exceeds cap $5.00, так что оператор, читающий ленту событий, видит ровно, почему сработал предохранитель.
События никогда не несут буквальный cap_cost. Вы создаёте вердикт как cap_cost, но движок разрешает его в конкретный allow или deny до того, как событие записывается. Лента показывает allow/deny, который агент реально увидел — потолок стоимости прогона — это причина, а не метка вердикта. Это отражает то, как вердикты разрешаются.

​
5. Разверните его безопасно

Поскольку сработавший предохранитель жёстко останавливает прогон, валидируйте его до применения. Включите shadow-режим на политике: правило cap_cost всё равно вычисляется, а потенциальный deny понижается до audit, с префиксом [shadow] would …. Наблюдайте за лентой событий, чтобы подтвердить, что потолок срабатывает там, где вы ожидаете, — и только там, где ожидаете, — затем выключите shadow-режим, чтобы начать применять. Вы также можете прогнать политику вхолостую против образца вызова во вкладке Test (песочница Developer+), чтобы увидеть разрешённый вердикт и совпавшее правило до того, как что-либо начнёт от него зависеть.

​
6. Как он вписывается в остальной firewall

cap_cost — один вердикт из шести. Он естественно сочетается с другими контролями на той же политике:

Вердикты

Полный набор — allow, audit, deny, sanitize, pending_approval, и как cap_cost разрешается.

Блокировать опасные инструменты

Отклонять деструктивный shell, удаления и другие высокорисковые вызовы напрямую.

Справочник правил

Полный язык сопоставления — глобы, клаузы аргументов, последовательности.

Детектирование аномалий

Всплески стоимости, флагируемые против обученного базиса по часу недели.
Потолок стоимости прогона — статический, детерминированный backstop; firewall также обучается нормальной форме стоимости каждого рабочего пространства и флагирует всплески против 14-дневного базиса по часу недели в читаемой Member ленте аномалий. Используйте cap_cost для жёсткой остановки, аномалии для раннего сигнала.
Квота-лимиты на самом ключе (credit_limit_usd) ограничивают общие траты по всем прогонам; cap_cost ограничивает один прогон. Они компонуются — убегающий цикл срабатывает предохранителем на прогон задолго до того, как сможет исчерпать пожизненный кредит ключа. См. область: ключи, политики, рабочие пространства.

​
Куда двигаться дальше

Создать и привязать политику

Создайте политику, выберите default-вердикт, привяжите её к ключу.

Shadow-режим

Измерьте потолок до того, как он изменит трафик.
Об угрозах убегающего агента, которые подстраховывает потолок трат, см. избыточную автономию и опасные вызовы инструментов.