AI-порталAI-портал

Tool Result Staleness в 2026: когда старый ответ инструмента уже нельзя использовать повторно

Tool result staleness в 2026: как задавать срок годности для результатов tools, retries и cached outputs, чтобы агент не принимал решения на устаревшем внешнем состоянии.

Tool result staleness в 2026 нужен потому, что агент любит переиспользовать уже полученные результаты: из retry state, из cache, из предыдущего шага, из replayed workflow. Это ускоряет систему и уменьшает cost, но только до того момента, пока tool result ещё описывает реальный мир. Старый CRM lookup, expired payment status или устаревший browser snapshot легко превращаются в ложное основание для следующего действия.

Tool result staleness — это правило, через сколько времени результат инструмента считается слишком старым для повторного использования.
Самый вредный anti-pattern - считать любой уже полученный tool output безопасным для reuse, если он лежит в state. Внешний мир меняется быстрее, чем агентный workflow.

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

Хорошая staleness policy в 2026 обычно определяет:

  1. Какие tool results можно кэшировать
  2. Какой max age допустим
  3. Какие routes требуют forced re-check
  4. Когда stale result блокирует action
  5. Как stale status логируется в traces

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

  • срок годности зависит от tool type;
  • cached result и action support — не одно и то же;
  • retries не должны слепо переиспользовать старый external state;
  • stale tool result должен менять routing, а не просто иметь timestamp.
Без техники
Агент повторно использует CRM status из начала сессии для финального commit через 15 минут.
С техникой
Policy помечает result как stale, требует fresh lookup и не даёт системе коммитить действие на старом внешнем состоянии.
ПромптStaleness intuition
Почему cached tool result опасен для risky action?
Ответ модели

Потому что он мог быть верным в момент получения, но уже не отражать текущее внешнее состояние. Для action support это критично.

1. Разные tools стареют с разной скоростью

Полезно различать:

  • static KB lookup;
  • CRM status;
  • billing snapshot;
  • browser DOM state;
  • rate limit info;
  • temporary auth or token state.

У каждого result-а свой realistic reuse window.

2. Retry state не должен скрывать stale external world

Частая ошибка:

  • агент сделал lookup;
  • потом были retries, delays, human pause;
  • финальный step использует старый result как будто он свежий.

Именно поэтому retries и resumes нужно связывать с freshness checks.

Если result поддерживает final action, лучше спрашивать не "у нас уже есть output?", а "достаточно ли он свежий для этого шага?".

3. Tool staleness должен быть route-aware

Один и тот же result может быть:

  • нормальным для summary;
  • уже слабым для recommendation;
  • недопустимым для execute.

Например, browser snapshot пятиминутной давности ещё полезен для explanation, но уже плох как support для click/submit.

4. Stale tool result должен влиять на orchestration

Полезные реакции:

  • force re-fetch;
  • downgrade to draft;
  • block risky commit;
  • request review;
  • rebuild evidence pack.

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

State means fresh enough

Если result лежит в state, его считают валидным.

Same TTL for all tools

Очень грубая политика.

Retry without re-check

Повторный шаг опирается на старый world snapshot.

No distinction between read cache and action support

Одинаковое отношение к summary и commit paths.

No stale telemetry

Команда не видит, как часто runs используют устаревший tool output.

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

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

  • stale-tool-result usage rate;
  • forced refetch rate;
  • actions blocked by stale tool results;
  • average tool-result age at action time;
  • resume runs requiring revalidation;
  • incidents caused by reused stale outputs.

Плюсы

  • Staleness policy уменьшает решения на устаревшем внешнем состоянии
  • Делает retries и resumes безопаснее
  • Route-aware freshness улучшает action gating
  • Помогает различать cost-saving cache и unsafe reuse

Минусы

  • Нужно поддерживать TTL и revalidation rules по tool type
  • Forced refetch повышает latency и cost
  • Не всегда очевидно, какой freshness threshold достаточен
  • Без observability stale reuse трудно заметить

Пример tool freshness policy

tool_results:
  crm_lookup:
    max_age_for_action_seconds: 60
  browser_snapshot:
    max_age_for_action_seconds: 10
  kb_lookup:
    max_age_for_answer_seconds: 1800

Простой stale check

def tool_result_fresh(age_seconds, limit_seconds):
    return age_seconds <= limit_seconds

Практический совет: хороший tool result cache экономит деньги. Плохой — quietly превращает свежий внешний мир в старый snapshot, на котором агент продолжает принимать решения.

Проверьте себя

1. Почему tool result нельзя считать валидным только потому, что он уже лежит в state?

2. Что особенно важно при retries и resumes?

3. Какой anti-pattern особенно опасен?

Источники

  1. OpenAI Agents SDK - Run state
  2. OpenAI API Docs - Evaluation best practices
  3. OpenTelemetry - GenAI semantic conventions
  4. OWASP Top 10 for LLM Applications
Предыдущая
Tool Permission Reviews в 2026: как регулярно пересматривать, что агентам вообще разрешено
Следующая
Tool Schema Design в 2026: как проектировать инструменты, чтобы агент не фантазировал