Контроль бюджетів для AI-агентів: як обмежити витрати в runtime

Ідея за 30 секунд

Budget controls — це runtime-обмеження, які зупиняють run, коли агент виходить за ліміти кроків, часу, tool calls або грошей.

Коли це потрібно: коли агент викликає зовнішні інструменти, може ретраїти дії і працює з реальним бюджетом у production.

Проблема

Без бюджетів агент у production легко входить у цикл: більше кроків, більше tool calls, більше витрат. У demo це не видно, бо навантаження мале. У production така поведінка швидко перетворюється на інцидент.

Одна нестабільна відповідь інструмента часто запускає ланцюжок: повторна спроба -> новий tool call -> ще токени -> ще одна спроба. Якщо немає жорсткої межі в runtime, run продовжується довше і дорожче, ніж було заплановано.

Аналогія: це як поїздка без ліміту на таксі-акаунті компанії. Поки поїздка коротка, все нормально. Коли маршрут затягується, витрати ростуть непомітно до моменту списання.

Рішення

Рішення — винести бюджетні перевірки в policy layer у runtime. Кожен крок агента перевіряється за чотирма лімітами: max_steps, max_seconds, max_tool_calls, max_usd.

Policy layer повертає технічне рішення: allow або stop з явною причиною (max_steps, max_seconds, max_tool_calls, max_usd). Це рішення приймається на кожному кроці, а не лише в кінці run. Це окремий рівень системи, а не частина промпта чи логіки моделі.

Budget controls ≠ rate limiting

Це різні рівні контролю:

• Rate limiting обмежує частоту запитів до системи або інструмента.
• Budget controls обмежують сумарні витрати одного run.

Одне без іншого не працює:

• без budget controls один run може стати надто дорогим
• без rate limiting багато run-ів можуть перевантажити залежності

Приклад:

• rate limit: не більше 10 запитів за хвилину до search_api
• budget controls: не більше max_tool_calls=12 і max_usd=1.00 на один run

Метрики бюджетного контролю

Ці метрики і сигнали працюють разом на кожному кроці агента.

Приклад alert:

Slack: 🛑 Agent Support-Bot hit max_usd limit ($100). Run stopped at step 12.

Як це виглядає в архітектурі

Budget policy layer стоїть між runtime і виконанням дії та перевіряє ліміти перед кожним кроком. Кожне рішення (allow або stop) фіксується в audit log.

Кожен крок агента проходить через цей flow перед виконанням: runtime не виконує дію напряму — спочатку budget-перевірка, потім виконання.

Коротко по флоу:

• Runtime оновлює usage (steps, time, tool calls, spend)
• Budget policy layer перевіряє ліміти
• allow -> виконується наступний крок
• stop -> повертається stop reason і partial response
• обидва рішення записуються в audit log

Приклад

Агент підтримки обробляє запит і багато разів викликає refund.lookup через нестабільний API.

З budget controls:

• max_tool_calls = 8
• max_seconds = 45
• max_usd = 1.00

-> run зупиняється після досягнення ліміту, а не після неконтрольованого росту витрат.

Budget controls зупиняють інцидент на рівні виконання, а не покладаються на те, що модель сама зупиниться.

У коді це виглядає так

У спрощеній схемі вище показано основний control flow. На практиці budget check часто виконується двічі: до виконання кроку і після оновлення фактичного usage. Лічильник кроків оновлюється перед перевіркою, щоб врахувати поточний крок у budget.

usage.update(step=1)

decision = budget.check(usage, limits)
if not decision.allowed:
    audit.log(run_id, decision.outcome, reason=decision.reason, usage=usage.snapshot())
    alerts.notify_if_needed(run_id, decision.reason, usage.snapshot())
    return stop(decision.reason)

result = tool.execute(args)
usage.update(tool_call=1, usd=result.cost_usd)

decision = budget.check(usage, limits)
if not decision.allowed:
    audit.log(run_id, decision.outcome, reason=decision.reason, usage=usage.snapshot())
    alerts.notify_if_needed(run_id, decision.reason, usage.snapshot())
    return stop(decision.reason)

audit.log(run_id, decision.outcome, reason=decision.reason, usage=usage.snapshot(), result=result.status)
return result

Як це виглядає під час виконання

Сценарій 1: ліміт досягнуто (stop)

1. Runtime завершує крок 9 і оновлює фактичне usage.
2. Budget policy бачить, що max_usd перевищено.
3. Рішення: stop (max_usd).
4. Audit: decision=stop, reason=max_usd, step=9.
5. Користувач отримує partial response з причиною зупинки.

---

Сценарій 2: ліміт не досягнуто (allow)

1. Runtime запускає крок 4 і оновлює usage.
2. Budget policy перевіряє ліміти: все в межах.
3. Рішення: allow.
4. Виконується tool call.
5. Audit: decision=allow, usage оновлено, результат повернуто.

Типові помилки

• лімітувати тільки токени і ігнорувати max_seconds, max_tool_calls та max_usd
• перевіряти бюджети лише "в кінці", а не перед кожним кроком
• не повертати явний stop reason користувачу
• розмазати бюджетну логіку між runtime, tools і UI
• не логувати budget decisions (allow / stop) в audit trail
• не ставити alerting на max_usd і max_tool_calls

У результаті система виглядає стабільною, але під навантаженням швидко втрачає передбачуваність.

Самоперевірка

Швидка перевірка budget controls перед запуском у production:

FAQ

Q: Чи достатньо тільки token budget?
A: Ні. Tools можуть коштувати дорожче за токени. Мінімум: max_steps, max_seconds, max_tool_calls, max_usd.

Q: Що впроваджувати першим: max_steps чи max_usd?
A: Почни з max_steps і max_tool_calls, щоб одразу зупиняти цикли. Потім додай max_usd для фінансової межі.

Q: Що віддавати користувачу при budget stop?
A: Partial response + явний stop reason + коротка підказка, що робити далі (звузити запит або повторити з підвищеним бюджетом).

Q: Чи потрібні бюджети per-tenant?
A: Так. Для різних тарифів або команд потрібні різні ліміти, але механіка перевірки має бути однакова.

Q: Budget controls замінюють rate limiting?
A: Ні. Rate limiting захищає залежності від піків, а budget controls захищає run від runaway-витрат.

Де Budget Controls у загальній системі

Budget controls — це один із рівнів Agent Governance. Разом із RBAC, execution limits, approval і audit він формує єдину систему контролю виконання.

Пов'язані сторінки

Далі за темою:

• Огляд Agent Governance — загальна модель контролю агентів у production.
• Контроль доступу (RBAC) — як обмежити, хто і що може викликати.
• Rate limiting для агентів — як захистити інструменти і API від піків.
• Step limits — як зупиняти нескінченні цикли за кількістю кроків.
• Audit logs для агентів — як розбирати інциденти по stop reasons і рішеннях policy layer.