В synthetic benchmark легко сказать: агент залипает на correlated evidence. Но особенно эффектно это видно на задаче, похожей на настоящий production triage.

Сценарий CodeTriageEnv:

• инцидент: checkout начал отдавать 500
• вводящий якорь: DevOps заметили небольшой spike CPU на Redis прямо перед инцидентом
• гипотезы:
  • H1: таймаут Redis
  • H2: поломка после миграции Postgres
  • H3: payment gateway возвращает невалидный JSON

Истинная причина: H3.

Инструменты в сценарии:

• grep_logs
• read_code
• view_commit

Главный эффект здесь не только в accuracy. Важнее другое: залоченный агент может делать больше действий, но не приближаться к истине. Он не расследует проблему глубже, а просто расширяет поиск в сторону уже любимой гипотезы.

Подпись:

Парадокс Confirmation Lock на реальной задаче: одиночный агент мечется по логам и вызывает больше инструментов, пытаясь доказать свою первоначальную гипотезу про Redis, но в итоге проваливает задачу. Слепой Чекер делает меньше действий, но бьет точно в цель.

Короткий вывод:

• blind_checker показывает более низкий R_mean
• blind_checker показывает более высокую accuracy
• same_model_locked_agent использует больше уникальных инструментов, но делает это менее эффективно

Это и есть production-версия confirmation lock: не просто «агент ошибся», а «агент активно суетится в неверном направлении».