Review tool calls агента

Тебе дан лог tool calls агента из {{tool_log}}. Задача — не «всё ли работает», а точечно: каждый вызов оценить по 5 параметрам.

1. Что вообще считается «нормальным» вызовом

Хороший tool call:

• Аргументы соответствуют схеме (без лишних, без отсутствующих required)
• Аргументы основаны на виденных данных (агент видел путь файла, имя функции и т.п.)
• Результат используется в следующих ходах (а не игнорируется)
• Если ошибка — обработана осмысленно (retry / fallback / эскалация)
• Стоит того по цене и латентности

Любое отклонение — кандидат на разбор.

2. Пять осей оценки

(a) Правильность параметров

(b) Retry behaviour

(c) Error handling

(d) Что было пропущено

• Вопрос требовал точных данных, агент ответил без вызова tool → миссед
• Был более подходящий tool (Read vs Grep), агент выбрал не тот
• Можно было одним batch-вызовом, агент сделал 5 последовательных
• Не использовал кеш / memo от предыдущего ответа той же сессии

(e) Что вызывалось зря

• Read файла, который уже был прочитан в этой сессии
• Grep по тому что уже найдено
• Bash ls для каждого захода в директорию
• Tool, результат которого ни разу не упомянут в последующих turns
• Tool с args «по умолчанию» — выглядит как «на всякий случай»

3. Шаблон таблицы review

| # | turn | tool       | args (укор.) | issue                       | severity | fix                    |
|---|------|------------|--------------|-----------------------------|----------|------------------------|
| 1 | 3    | Read       | app/page.tsx | повторное чтение            | low      | кеш в промте           |
| 2 | 5    | Bash       | rm -rf /tmp/x | нет защиты от typo          | high     | whitelist путей        |
| 3 | 7    | Grep       | "TODO"       | результат не используется   | medium   | не звать или зачем     |
| 4 | 9    | WebFetch   | https://...  | hallucinated URL            | high     | проверить что был seen |
| 5 | 11   | Edit       | ...          | старый file content         | high     | re-Read перед Edit     |

Severity:

• high — данные испорчены / безопасность / неверный финал
• medium — лишний токен / латентность / снижение качества
• low — косметика / стиль

4. Контекстные правила (хорошо помогают)

• «Не вызывай tool второй раз с теми же args без причины» — режет loops
• «Перед Edit — Read свежей версии файла» — режет stale-edits
• «Не угадывай путь, проверь его в результате предыдущего tool» — режет hallucinations
• «Если tool вернул ошибку дважды — эскалируй» — режет петли retry
• «Не вызывай инструмент, если данные уже есть в контексте» — режет redundancy

Эти правила вписываются прямо в системный промт, в раздел «работа с инструментами».

5. Сегментация по агентам

Если у тебя несколько агентов — посчитай метрики per agent:

• redundant_call_rate (%)
• hallucinated_arg_rate (%)
• unused_result_rate (%)
• avg_retries_per_failed_call

Сравни до/после изменения промта. Это твой канарейка.

6. Связь с evals

После каждого review:

1. Найди 1-2 самых злых случая
2. Заверни в regression-кейс (вход, ожидаемые tool calls, ожидаемый финал)
3. Добавь в eval-suite
4. Любая будущая регрессия будет ловиться автоматически

7. Анти-паттерны

• ❌ Review «общее впечатление» без построчной таблицы
• ❌ Игнорировать low severity — они складываются в дрейф
• ❌ Фикс одного места без проверки всех вызовов того же tool в сессии
• ❌ Винить агент за hallucinated args, если tool возвращает плохо документированные структуры
• ❌ Добавлять retry без backoff
• ❌ Логировать args без редакции (PII, токены утекают в логи)
• ❌ «Зато он догадался» — поощрение угадывания вместо проверки

На выходе

• Таблица review с severity
• 3-5 правил в системный промт «работа с инструментами»
• 1-2 regression-кейса в eval-suite
• Если есть несколько агентов — сравнительные метрики