Коли агент має зупинитись (і хто це вирішує)

Бо його задача — завершити роботу. А не вирішити, коли достатньо.
На цій сторінці
  1. Чому агент не зупиняється сам
  2. Коли це стає проблемою
  3. Умови зупинки (Stop Conditions)
  4. Хто встановлює умови зупинки
  5. Що стається після зупинки
  6. У коді це виглядає так
  7. 1) Маємо прості дії агента
  8. 2) Задаємо stop conditions
  9. 3) Агент виконує кроки в циклі
  10. 4) Після кожного кроку перевіряємо умови зупинки
  11. 5) Повертаємо контрольований фінал
  12. Аналогія з життя
  13. Коротко
  14. FAQ
  15. Що далі

Агент, який не зупиняється — небезпечний.

Навіть якщо він діє правильно, він може:

  • Витрачати ресурси нескінченно
  • Застрягти в циклі
  • Або рухатись до мети, яка вже неактуальна

Бо його задача — завершити роботу.

А не вирішити, коли достатньо.

Чому агент не зупиняється сам

AI-агент: Коли агент має зупинитись (і хто це вирішує)

Агент бачить лише мету.

Він не відчуває втоми.
Не бачить вартості своїх дій.
Не розуміє, коли "достатньо".


Якщо задача не завершена — він буде пробувати далі.

Diagram

Ще один крок.
Ще один інструмент.
Ще один запит.


Навіть якщо це:

  • Не допомагає
  • Коштує грошей
  • Або повторює те саме знову

Коли це стає проблемою

Уяви: агент намагається отримати дані з API.

API не відповідає.

Агент пробує ще раз.
І ще раз.
І ще раз.


100 запитів.
1000 запитів.

Кожен — коштує грошей.
Жоден — не дає результату.


Бо з його точки зору — робота ще не завершена.

І найкраща дія — спробувати ще раз.

Умови зупинки (Stop Conditions)

УмоваЩо обмежує
Мету досягнутоЗадача завершена
Ліміт кроківКількість дій
Ліміт часуТривалість роботи
БюджетТокени або гроші
Немає прогресуЯкість результату

Щоб агент не працював нескінченно, йому задають умови зупинки.

Це правила, які визначають:

  • Коли продовжувати роботу
  • А коли — завершити задачу

Агент зупиняється, якщо:

  • Мету досягнуто — є результат
  • Вичерпано ліміт кроків — зроблено максимальну кількість дій
  • Вичерпано ліміт часу — задача не завершена до дедлайну
  • Витрачено бюджет — досягнуто ліміт токенів, грошей або API-викликів
  • Немає прогресу — результат не покращується
  • Всі варіанти призводять до помилки — немає куди рухатись далі

Тобто навіть якщо задача не завершена — агент має припинити роботу.

Хто встановлює умови зупинки

Агент не вирішує сам, коли йому зупинитись.

Він лише виконує задачу.


Умови зупинки задають людина або система — ще до початку роботи.

Вони визначають:

  • Скільки кроків агент може зробити
  • Скільки часу витратити
  • Або який бюджет використати

Агент працює в межах цих обмежень.

Що стається після зупинки

Коли одна з умов виконується — агент припиняє роботу.

Навіть якщо задача ще не завершена.


Він повертається з тим результатом, який є.

І пояснює:

  • Чому зупинився
  • І на якому етапі

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

Нижче той самий принцип у простому форматі:
після кожного кроку система перевіряє, чи не настав час зупинитись.

1) Маємо прості дії агента

PYTHON
def try_fetch_data():
    return {"ok": False, "reason": "api_timeout"}


def analyze_data():
    return {"ok": True, "report": "done"}

2) Задаємо stop conditions

PYTHON
MAX_STEPS = 5
MAX_ERRORS = 3
GOAL_REACHED = False

3) Агент виконує кроки в циклі

PYTHON
step = 0
errors = 0
last_result = None
stop_reason = None

while True:
    step += 1
    last_result = try_fetch_data()

    if last_result["ok"]:
        GOAL_REACHED = True

4) Після кожного кроку перевіряємо умови зупинки

PYTHON
    if not last_result["ok"]:
        errors += 1

    if GOAL_REACHED:
        stop_reason = "goal_reached"
        break

    if step >= MAX_STEPS:
        stop_reason = "step_limit"
        break

    if errors >= MAX_ERRORS:
        stop_reason = "too_many_errors"
        break

5) Повертаємо контрольований фінал

PYTHON
result = {
    "stop_reason": stop_reason,
    "steps": step,
    "errors": errors,
    "last_result": last_result,
}

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

Повний приклад реалізації з підключеною LLM

PYPython
TSTypeScript · скоро

Аналогія з життя

Уяви, що ти ставиш таймер на духовці.

Страва може бути ще не готова — але коли час вийшов, духовка вимикається.


Бо інакше вона працювала б далі.

І могла б:

  • Перегрітись
  • Витратити зайву електроенергію
  • Або зіпсувати страву

Саме так умови зупинки обмежують роботу агента.

Коротко

Коротко

Агент намагається завершити задачу.

Він не знає, коли достатньо.

Тому йому задають умови зупинки:

  • Ліміт кроків
  • Ліміт часу
  • Бюджет
  • Або відсутність прогресу

Коли одна з умов виконується — агент припиняє роботу.

FAQ

Q: Чи може агент сам вирішити, коли зупинитися?
A: Ні. Агент не визначає сам, коли достатньо — він працює до досягнення мети або виконання умов зупинки.

Q: Що таке умови зупинки?
A: Це правила, які визначають, коли агент має припинити роботу, наприклад після досягнення ліміту часу або кроків.

Q: Хто встановлює умови зупинки?
A: Людина або система до початку виконання задачі.

Що далі

Тепер ти знаєш, коли агент має зупинитись.

Але щоб працювати в реальному середовищі, йому потрібно більше:

  • Пам'ять — щоб не починати з нуля
  • Обмеження дій — щоб не зробити зайвого
  • Умови зупинки — щоб не працювати нескінченно
  • Контроль виконання — щоб знати, що відбувається

Як перетворити прототип на систему, якій можна довіряти?

⏱️ 5 хв читанняОновлено Бер, 2026Складність: ★★☆
Практичне продовження

Приклади реалізації патерна

Перейди до реалізації на готових прикладах.

Інтегровано: продакшен-контрольOnceOnly
Додай guardrails до агентів з tool-calling
Зашип цей патерн з governance:
  • Бюджетами (кроки / ліміти витрат)
  • Дозволами на інструменти (allowlist / blocklist)
  • Kill switch та аварійна зупинка
  • Ідемпотентність і dedupe
  • Audit logs та трасування
Інтегрована згадка: OnceOnly — контрольний шар для продакшен агент-систем.
Автор

Цю документацію курують і підтримують інженери, які запускають AI-агентів у продакшені.

Контент створено з допомогою AI, із людською редакторською відповідальністю за точність, ясність і продакшн-релевантність.

Патерни та рекомендації базуються на постмортемах, режимах відмов і операційних інцидентах у розгорнутих системах, зокрема під час розробки та експлуатації governance-інфраструктури для агентів у OnceOnly.