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

Tool Output Provenance в 2026: как не потерять происхождение данных, когда агент опирается на tool result

Tool output provenance в 2026: как сохранять источник, время, scope и trust level у tool results, чтобы агент не превращал чужие данные в безымянный факт.

Tool output provenance в 2026 нужен потому, что агентные системы очень быстро теряют происхождение данных. Tool отдал value, агент вставил его в reasoning, потом в handoff, потом в финальное действие, и через пару шагов уже невозможно понять, откуда именно взялась эта цифра, насколько она свежая, для какого scope она была валидна и можно ли ей доверять. В итоге tool output начинает жить как "факт", хотя на самом деле это всего лишь результат конкретного вызова в конкретных условиях.

Provenance — это информация о происхождении данных: какой tool их вернул, когда, в каком контексте и с каким уровнем доверия.
Самый вредный anti-pattern - сохранять только значение tool result и выкидывать metadata. Тогда через один-два шага система уже не может различить verified source, stale lookup и guessed fallback.

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

Хороший tool-output provenance в 2026 обычно хранит:

  1. Какой tool вернул данные
  2. Когда вызов произошёл
  3. Для какого scope результат валиден
  4. Какой trust level у результата
  5. Можно ли использовать его для action или только для hint

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

  • provenance нужен не только для audit, но и для runtime policy;
  • tool result без metadata быстро становится опасным "анонимным фактом";
  • freshness и scope почти так же важны, как само значение;
  • provenance должен доезжать до reviewer и policy engine.
Без техники
Агент знает только `balance=1200`.
С техникой
Агент знает: `balance=1200`, source=`billing_api`, fetched_at=`12:31`, scope=`account_42`, trust=`action_support`.
ПромптTool-provenance intuition
Почему недостаточно хранить только value из tool result?
Ответ модели

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

1. Value без provenance почти всегда теряет смысл

Одно и то же значение может означать разное:

  • fetched from canonical API;
  • copied from cache;
  • returned by fallback;
  • produced in degraded mode;
  • scoped to another tenant or session.

Без provenance эти различия исчезают.

2. Provenance должен быть operational, а не только логическим

Минимально полезно хранить:

  • tool_name;
  • invocation_id;
  • fetched_at;
  • subject or scope id;
  • trust tier;
  • expiry or freshness window.

Так policy engine может принимать решения не по "value exists", а по качеству этого value.

Если tool result можно показать человеку или использовать для risky action, provenance должен доезжать до этого места вместе со значением, а не оставаться в trace где-то отдельно.

3. Provenance помогает различать support и hint

Полезно разделять:

  • action-supporting result;
  • review-supporting result;
  • hint-only result;
  • cached informational result;
  • degraded fallback result.

Иначе агент начинает использовать любую цифру как равнозначное основание.

4. Provenance должен переживать handoffs и state transitions

Иначе типовая деградация выглядит так:

  • tool вернул структурированный result;
  • planner сохранил только value;
  • reviewer получил summary без source;
  • action layer воспринял summary как canonical fact.

Это одна из самых частых причин ложной уверенности в agent pipeline.

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

Metadata dropped after parsing

Сохраняется только итоговое значение.

No freshness field

Непонятно, устарел ли результат.

Scope lost across handoffs

Результат начинает жить вне исходного subject.

Trust not encoded

Hint и verified output выглядят одинаково.

Provenance only in logs

Runtime policy не видит происхождение.

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

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

  • percent of tool results with full provenance;
  • action attempts using provenance-incomplete data;
  • stale result usage rate;
  • cross-scope result contamination;
  • degraded outputs consumed as action support;
  • reviewer packets missing tool source metadata.

Плюсы

  • Tool provenance снижает риск анонимных и устаревших фактов
  • Помогает policy engine различать support и hint
  • Усиливает auditability и reviewer trust
  • Делает tool chaining безопаснее и понятнее

Минусы

  • Нужно хранить больше metadata и передавать её дальше по pipeline
  • Слишком бедные tool schemas тяжело адаптировать
  • Без enforcement provenance быстро начинает теряться
  • Часть legacy tools не умеет отдавать хороший context

Пример provenance-aware result

{
  "value": 1200,
  "tool_name": "billing_api",
  "invocation_id": "tool_9f2",
  "fetched_at": "2026-04-10T12:31:00Z",
  "scope_id": "account_42",
  "trust_tier": "action_support",
  "expires_at": "2026-04-10T12:36:00Z"
}

Простой gate

def usable_for_action(result):
    return result.get("trust_tier") == "action_support" and result.get("scope_id") is not None

Практический совет: зрелая agent system хранит не только "что вернул tool", но и "почему этому значению вообще можно доверять в текущем контексте".

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

1. Почему provenance у tool result важен?

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

3. Что полезно кодировать в provenance?

Источники

  1. OpenAI Agents SDK - Tools
  2. OpenTelemetry GenAI Semantic Conventions
  3. OpenAI API Docs - Evaluation best practices
  4. OpenAI Agents SDK - Run context
Предыдущая
Tool Evidence Linking в 2026: как связывать tool results с конкретными claims и действиями агента
Следующая
Tool Permission Models в 2026: какие права давать агенту на вызов инструментов