Tool Result Validation в 2026: почему нельзя слепо доверять даже своим инструментам

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

Хороший tool result validation в 2026 обычно проверяет пять вещей:

1. Schema / format
2. Freshness
3. Business consistency
4. Trust level
5. Actionability

Что особенно полезно

• typed tool responses;
• explicit status и source_timestamp;
• cross-check перед risky commit;
• sanitization текстовых полей;
• разделение read result и commit-ready result.

Billing tool вернул `eligible_for_refund=true`. Можно ли сразу инициировать refund?

1. Tool output - это untrusted operational input

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

• trusted by transport: ответ вообще пришёл от правильного инструмента;
• trusted by format: ответ соответствует ожидаемой схеме;
• trusted by meaning: на его основе действительно можно принимать действие.

Большинство систем останавливается на первом уровне. Но production-проблемы обычно начинаются между вторым и третьим.

2. Schema validation - только первый фильтр

Typed tool outputs заметно лучше свободного текста, потому что уменьшают хаос формата:

• статус можно проверить явно;
• поля доступны коду;
• легче строить retries и alerts.

Но schema-valid response всё ещё может быть:

• старым;
• неполным;
• логически противоречивым;
• unsafe для commit.

Поэтому schema validation полезна как входной барьер, но не как финальное разрешение.

3. Freshness и provenance критичны

Особенно для:

• billing;
• inventory;
• pricing;
• policy lookup;
• identity and permissions.

Полезные поля в tool output:

• status;
• source_timestamp;
• data_version;
• partial;
• error_details;
• provenance.

Без этого агент почти не понимает, насколько результат свежий и complete.

4. Business consistency важнее transport success

Типичный dangerous case:

• lookup технически успешен;
• JSON валиден;
• но значения не согласуются с текущим state.

Примеры:

• refund amount больше, чем разрешено policy;
• order currency не совпадает с текущим account region;
• user имеет статус, несовместимый с requested action;
• tool вернул partial search result, но агент трактует его как полный.

Эти ошибки не ловятся простым try/except.

5. Textual tool outputs тоже требуют sanitization

Особенно когда инструменты возвращают:

• search snippets;
• scraped web text;
• email bodies;
• log fragments;
• human-authored notes.

Такие outputs могут содержать:

• injected instructions;
• HTML / markdown noise;
• misleading error messages;
• огромные нерелевантные фрагменты.

Поэтому tool validation часто включает ещё и:

• truncation;
• sanitization;
• content-type checks;
• trust marking before reinjection into prompt.

6. Read result не равен commit-ready result

Это одна из самых полезных границ.

Хорошая система сначала превращает tool output в:

• normalized state;
• validated proposal;
• only then commit input.

Такой pipeline обычно выглядит так:

1. tool response;
2. schema check;
3. business check;
4. optional second-source or approval;
5. commit payload.

Если напрямую перескочить с tool output к commit, агент начинает использовать инфраструктурный ответ как business truth.

7. Что чаще всего ломают команды

No explicit status model

Непонятно, где success, partial, not_found, stale и degraded.

Error blob as data

HTML или stack trace попадает обратно в prompt как будто это полезный контекст.

No freshness boundary

Старый lookup используется как основание для нового side effect.

No cross-check for risky writes

Один ответ инструмента автоматически авторизует действие.

No trust labels

Система не различает verified data, tentative data и untrusted text.

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

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

• tool schema failure rate;
• stale-result usage rate;
• partial-result misinterpretation rate;
• commit blocked by validation;
• error-blob reinjection incidents;
• second-check disagreement rate.

Эти метрики очень быстро показывают, является ли tool layer инженерным контрактом или просто ещё одним местом для надежды.

Пример typed tool response

{
  "status": "ok",
  "source_timestamp": "2026-04-01T09:10:00Z",
  "data_version": "billing_v7",
  "partial": false,
  "order_id": "ord_1821",
  "eligible_for_refund": true,
  "max_refund_amount": 129.0,
  "currency": "USD"
}

Простой validation gate

def validate_tool_result(result, now):
    if result["status"] != "ok":
        return False, "tool_not_ok"
    if result.get("partial"):
        return False, "partial_result"
    if is_stale(result["source_timestamp"], now):
        return False, "stale_result"
    if result["max_refund_amount"] <= 0:
        return False, "invalid_business_value"
    return True, "ok"

Практический совет: если tool output потенциально может запустить side effect, относитесь к нему как к proposal input, а не как к final authority. Именно этот сдвиг обычно делает agent stack заметно безопаснее.