TL;DR
ABF Agent Harness — это «обвязка» вокруг LLM-агента для расследований, где нужно идти по цепочке записей. Она состоит из трёх частей. Первая: рабочая память из трёх секций (подтверждённое, открытые зацепки, заметки), которую агент ведёт сам. Вторая: инструменты для этой памяти, предпросмотр отчёта и сжатие контекста. Третья: пять коротких правил в промпте. Статья в целом — бенчмарк по отслеживанию украденных криптоактивов, а обвязка — их предложенное решение.
Главная находка: готовые агенты общего назначения теряют результат из-за переуверенности. Один из них ссылается на записи, которых он не открывал: «источник» назван, но реально не прочитан. Такие утверждения не засчитываются. Все агенты, включая лучшего, останавливаются раньше времени: на больших задачах не доходят до конца, хотя бюджет ещё есть. Простой обход «в ширину» по фиксированному порядку в итоге находит больше.
Обвязка решает это структурой. Агент записывает каждую открытую зацепку в список и закрывает её с указанием итога. Каждое число в отчёте берёт только из реально полученного ответа. Останавливается, когда зацепки исчерпаны или кончился бюджет. С тем же моделью обвязка нашла заметно больше, чем Codex, и намного больше, чем Claude Code.
Схема метода
ПАМЯТЬ (агент ведёт сам, обновляет после каждого шага):
findings → подтверждённые факты, из них собирается отчёт
leads → открытые вопросы; каждый закрывается с пометкой «чем закончился»
notes → наблюдения «на потом»
ИНСТРУМЕНТЫ: правка памяти · предпросмотр отчёта перед сдачей · сжатие контекста
ПЯТЬ ПРАВИЛ В ПРОМПТЕ:
1-2. Знания предметной области (в оригинале — про блокчейн)
3. Каждое значение — только из полученной записи или текста задачи
4. Продолжай, пока не исчерпаны все leads / не вышли за границы / не кончился бюджет
5. Отправляй каждое найденное подтверждённое звено
Всё это работает в одном непрерывном прогоне агента, а не в цепочке отдельных запросов.
Пример применения
Задача: Вы проверяете контрагента перед сделкой на 12 млн ₽. Агент в Claude Code с доступом к открытым источникам (ЕГРЮЛ, картотека арбитражных дел, сайт ФНС) должен выяснить связанных лиц и риски. Цепочка ветвится: у учредителя ещё пять компаний, у каждой свои суды. Типичный провал: агент разбирает две ветки, пишет «рисков не выявлено» и ссылается на карточки, которые не открывал.
Промпт:
Ты проводишь проверку контрагента ООО «Вектор-Снаб» (ИНН указан в задаче) перед сделкой на 12 млн ₽.
Цель: найти связанные компании и лица, судебные споры и признаки однодневки.
РАБОЧАЯ ПАМЯТЬ. Веди файл memory.md и обновляй его после каждого шага:
## findings — подтверждённые факты. Формат: факт | ссылка на источник, который ты открыл
## leads — открытые вопросы. Закрывая, пиши итог: «подтвердилось / не подтвердилось / вне границ / недоступно»
## notes — наблюдения на потом
ПРАВИЛА:
1. Идти надо за контролем, а не за формальными совпадениями: смотри, кто реально управляет компанией (учредитель, директор, адрес, телефон), а не только кто числится по названию.
2. Проверяй полные реквизиты (ИНН, ОГРН) — не доверяй компаниям с похожим названием.
3. Каждое число, дата и название в отчёте берутся только из страницы, которую ты открыл в этом прогоне, или из текста задачи. Не открывал — не цитируй.
4. Не останавливайся, пока в leads есть открытые пункты. Исключение: пункт вне границ (только РФ, только последние 5 лет) или кончился лимит в 60 обращений к источникам.
5. В итоговый отчёт включи каждый подтверждённый факт из findings.
Перед сдачей отчёта сделай предпросмотр: перечисли все утверждения и напротив каждого — источник, который ты открывал. Утверждения без источника убери или верни в leads.
Результат: Агент заведёт файл памяти и будет пополнять его по ходу работы. В списке leads появятся ветки: учредитель, его другие компании, суды по каждой. Каждая ветка закроется с пометкой итога. В конце придёт отчёт, где у каждого факта есть ссылка на открытую страницу. Вместо «рисков не выявлено» по двум веткам вы увидите, какие пункты закрыты, какие недоступны и какие остались вне границ.
Почему это работает
Слабость. LLM-агент ведёт расследование «в голове» контекста. Когда ветвей много, одна из них молча выпадает, и всё, что за ней, не проверено. Модель также склонна выдавать правдоподобные ссылки на то, что она не читала. Кроме того, она рано объявляет работу законченной.
Сильная сторона. LLM хорошо ведёт структурированные записи и следует простым явным правилам. Если зацепки лежат в списке, невыполненное видно и агенту, и вам. Правило «цитируй только полученное» превращает размытое «не выдумывай» в проверяемое условие.
Как метод использует это. Список leads не даёт молча бросить ветку: её надо закрыть с итогом. Правило остановки даёт чёткий критерий, когда считать работу законченной. Предпросмотр отчёта — последняя проверка «утверждение ↔ источник».
Рычаги управления: - Правила 1–2 (знания предметной области) → заменяйте на свои: что в вашей области считается «настоящей» связью и какие бывают двойники. - Условие остановки (правило 4) → меняйте границы и лимит обращений под задачу. Меньше лимит — дешевле и менее полно. - Статусы закрытия зацепок → добавьте свои, например «требует эксперта». - Предпросмотр → делайте обязательным шагом, если для вас дорога ложная ссылка.
Шаблон промпта
В оригинале правила 1–2 про блокчейн: «следуй за контролем над средствами, а не за движением монет» и «проверяй активы и полные адреса от подделок-двойников». Здесь они заменены плейсхолдерами. Правила 3–5 и структура памяти взяты как есть.
Ты проводишь расследование: {задача}.
Границы: {что в рамках задачи, что вне}. Лимит: {число} обращений к источникам.
РАБОЧАЯ ПАМЯТЬ. Веди {файл или раздел ответа} и обновляй после каждого шага:
## findings — подтверждённые факты (формат: факт | источник, который ты открыл)
## leads — открытые вопросы; закрывая, указывай итог: {варианты итогов}
## notes — наблюдения на потом
ПРАВИЛА:
1. {Правило предметной области: за чем идти по существу, а не по форме}
2. {Правило проверки двойников: что легко перепутать и как проверять полностью}
3. Каждое значение в отчёте берётся только из источника, который ты получил в этом прогоне, или из текста задачи.
4. Продолжай, пока в leads есть открытые пункты. Исключения: пункт вне границ или исчерпан лимит.
5. В итоговый отчёт включи каждый подтверждённый факт из findings.
Перед сдачей сделай предпросмотр: перечисли утверждения отчёта и источник для каждого. Без источника — убери.
Подставляйте: {задача} — цель расследования, {границы} — рамки поиска, {варианты итогов} — статусы закрытия зацепки, правила 1–2 — знания вашей области.
🚀 Быстрый старт — вставь в чат:
Вот шаблон «рабочая память + пять правил». Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про границы поиска, лимит обращений, статусы закрытия зацепок и два правила предметной области. Они нужны, потому что именно эти поля отличают расследование в вашей области от чужой. Структура памяти и правила 3–5 универсальны, их она оставит.
Ограничения
⚠️ Обвязка не решает ранний останов: все агенты, включая обвязку, заканчивают раньше времени и теряют результат на больших задачах. Лучший результат по полноте в статье дал не агент, а фиксированный обход в ширину. Список leads смягчает проблему, но не снимает её.
⚠️ Нет разбора вклада частей: в доступном тексте не видно сравнения «только память» против «только правила». Что именно дало прирост, неизвестно. Шаблон выше собран из описания компонентов, дословных промптов авторов в тексте нет.
⚠️ Один кейс и узкая область: все задачи построены на одном инциденте (взлом Bybit, февраль 2025) в блокчейне. Перенос на другие области — ваша гипотеза, авторы его не проверяли.
⚠️ Сравнение не изолирует причину: Codex и Claude Code работали в стандартной конфигурации. Низкий результат Claude Code — про ссылки на непрочитанное в этом бенчмарке, а не вердикт об инструменте.
⚠️ Нужен проверяемый источник: правило «цитируй только полученное» работает, когда есть что считать «полученным» (ответ инструмента). В обычном чате без инструментов оно слабее.
Как исследовали
Команда взяла реальный случай: кражу у биржи Bybit в феврале 2025 года, и 90 дней движения средств по Ethereum и Bitcoin. Из этого сделали 58 задач, выпустили 33, оценивали на 31. В них около двух тысяч «эталонных звеньев» цепочки, скрытых от решателя.
Хитрость в проверке. Каждое утверждение агента автоматический проверяющий сверяет с записями, на которые агент сослался. Звено засчитывается, только если агент сам получил все эти записи. Поэтому «цитирование непрочитанного» не проходит, и именно так выяснилось, что Claude Code теряет результат из-за переуверенности. У всех решателей одинаковый лимит запросов, рассчитанный по эталонному решению.
Сравнивали обвязку, Codex на той же модели, Claude Code и фиксированные трассировщики (программы с жёстким порядком обхода). Обвязка нашла около 75% звеньев, Codex около 47%, Claude Code около 10%. Нераскрытые «кастодиальные сервисы» (точки, где следы обрываются) обвязка распознала в 89% случаев, трассировщики ни разу. Достоверность утверждений 98%.
Неожиданность в том, что все агенты проиграли простому обходу в ширину по итоговой полноте: они раньше заканчивают. Для практики вывод такой: контролируйте условие остановки и ведите явный список невыполненного.
Адаптации и экстраполяции
🔧 Техника: добавить обязательный предпросмотр → ловить ссылки на непрочитанное
Заканчивайте промпт блоком: «Перед сдачей составь таблицу: утверждение | источник | открывал ли ты его в этом прогоне (да/нет). Строки с "нет" удали или верни в leads». Это моя вариация правила 3. Авторы описывают предпросмотр как инструмент проверки отчёта, но не такую таблицу.
🔧 Техника: привязать остановку к проверяемому условию → меньше раннего останова
Замените «продолжай, пока есть leads» на «не сдавай отчёт, пока не покажешь список leads с итогами по каждому». Агенту труднее «забыть» ветку, когда её надо предъявить. Это моя гипотеза, статья её не проверяла.
Ресурсы
- ABF-Bench: A Verifiable Benchmark for Agentic Blockchain Forensics — Xiaohang Yu, Hejia Geng, William Knottenbelt (Imperial College London; University of Oxford). Бенчмарк обещан к публикации после принятия статьи.
- На основе: LOCARD (формализация агентной блокчейн-форензики), RiskTagger, SWE-bench, BrowseComp, Cybench, τ-bench, WebArena.
- Примечание: текст исследования в доступном виде обрывается на разделе гипотез. Раздел с экспериментами не прочитан, выводы взяты из аннотации и введения.