Agent Stop Conditions в 2026: когда агент должен остановиться, а не пробовать ещё раз

Короткая версия

Хорошие agent stop conditions в 2026 обычно учитывают:

1. Goal achieved
2. No progress / repeated state
3. Budget exhausted
4. Risk threshold exceeded
5. Escalation required

Что особенно важно

• stop rules должны смотреть не только на количество шагов, но и на trajectory quality;
• repeated failures без нового evidence должны останавливать run;
• risky actions после degraded retrieval или weak tool signals лучше блокировать stop condition-ом;
• terminal states должны быть typed: success, abstain, needs_review, failed_safe.

Когда агент должен остановиться, даже если у него остались шаги?

1. Stop condition — это часть политики, а не только техники

В production полезно различать:

• техническую невозможность продолжать;
• бессмысленность продолжения;
• опасность продолжения;
• необходимость human escalation.

Эти четыре причины могут приводить к разным terminal states.

2. No-progress detection важнее, чем кажется

Самый частый loop-паттерн:

• агент слегка переформулирует тот же запрос;
• вызывает тот же tool с теми же аргументами;
• получает тот же тип ошибки;
• продолжает, потому что формальный max_steps ещё не достигнут.

Полезно отдельно отслеживать:

• repeated tool signature;
• unchanged evidence set;
• repeated plan branch;
• identical error class;
• zero delta in confidence.

3. Stop conditions должны быть связаны с risk tier

Для low-risk research agent можно терпеть больше exploration. Для:

• external send;
• code write;
• money movement;
• policy decision;
• browser submit

правильнее останавливать run раньше, особенно если:

• retrieval degraded;
• tool outputs неполные;
• approval path недоступен;
• confidence падает.

4. Typed terminal states лучше, чем один общий failure

Полезные terminal states:

• success;
• needs_clarification;
• needs_human_review;
• abstain;
• failed_safe;
• budget_exhausted.

Так orchestration и product layer понимают, что делать дальше, а не видят только бинарное "получилось / не получилось".

5. Что особенно часто ломают команды

Max-steps only

Нет понимания progress quality.

Retry without state analysis

Повторяется один и тот же шаг под новым текстовым описанием.

No risk-aware stopping

Опасные маршруты продолжаются слишком долго.

One generic failure terminal

Нельзя различить abstain, review и технический сбой.

No trace-level metrics

Команда не видит, какие loops чаще всего приводят к бесполезной активности.

6. Какие метрики полезны

Минимальный dashboard обычно включает:

• runs stopped by no-progress rule;
• repeated-tool-loop rate;
• budget-exhausted rate by route;
• average step count before safe stop;
• incidents prevented by stop policy;
• percent of risky runs ending in typed escalation instead of blind retry.

Пример stop policy

routes:
  refund_agent:
    max_steps: 8
    no_progress_window: 2
    stop_on_repeated_tool_error: true
    terminal_on_missing_approval: needs_human_review
  research_agent:
    max_steps: 14
    no_progress_window: 3
    terminal_on_weak_evidence: abstain

Простой no-progress sketch

def should_stop(run):
    if run.goal_achieved:
        return "success"
    if run.repeated_tool_errors >= 2:
        return "failed_safe"
    if run.no_progress_steps >= 2:
        return "needs_human_review"
    if run.retry_budget_exhausted:
        return "budget_exhausted"
    return None

Практический совет: зрелый агент останавливается не тогда, когда "больше не может", а тогда, когда дальнейшая активность уже не даёт хорошего operational tradeoff.