Что такое ИИ-агент с доказательной базой: разбор протокола RFB

Публикация вышла из репозитория RFB и описывает один конкретный запуск: агент строил локальный менеджер закладок, выбирая между базами данных, правилами обработки тегов и способом хранения ссылок. Исследование не претендует на научный эксперимент, это скорее рабочий протокол, открытый для проверки. Но именно такая прозрачность редко встречается в публикациях про ИИ-агентов и заслуживает разбора.

Зачем агенту исследовать до кода?

Суть метода RFB в том, что ИИ-агент (программа, которая сама выполняет цепочку действий по заданию) работает не в режиме «напиши код по описанию», а по жёсткому порядку: изучи похожие реализации, объясни каждое решение, составь план, напиши приложение и запиши проверки.

Для задачи «менеджер закладок» агент изучил три открытых проекта. linkding показал, как обрабатывать теги. Buku продемонстрировал, как SQLite (встраиваемая база данных, которая хранит всё в одном файле и не требует сервера) защищает от дублей через ограничение UNIQUE. Shaarli дал пример файлового жизненного цикла, который для данной задачи не подошёл.

Ключевое отличие от обычной генерации кода: агент не копирует архитектуру целиком, а берёт отдельные механизмы и обосновывает, почему именно они.

Два решения, которые агент обосновал

Теги из linkding. Парсер linkding удаляет пустые значения, убирает повторы без учёта регистра, преобразует пробелы внутри тегов и сортирует результат. Агент взял не всё: для новой утилиты решили убрать пустые значения и дубли, но сохранить внутренние пробелы и оригинальное написание. Иначе тег «Machine Learning» превратился бы в тег с дефисом.

Различие между «что делает источник» и «что берём для себя» зафиксировано в отчёте. Одной ссылки на репозиторий linkding без объяснения выбора было бы мало.

Уникальность URL из Buku. В схеме Buku поле URL имеет ограничение UNIQUE, вставка идёт параметризованным запросом. Агент проверил это коротким скриптом на стандартной библиотеке Python: повторный URL отклоняется, в таблице остаётся одна запись.

При этом агент честно указал ограничение: база в памяти не проверяет сохранность после перезапуска, а нормализацию адресов (слеш на конце или без него) ограничение UNIQUE не выполняет.

Как устроена цепочка доказательств?

RFB сохраняет всё в четыре файла:

• RESEARCH.md содержит результаты изучения чужих проектов
• PLAN.md описывает план реализации
• VERIFICATION.md фиксирует проверки
• evidence.json хранит связи: источник, наблюдение, решение, шаг плана, проверка

По этой цепочке можно пройти от требования к конкретному месту в чужом коде и к результату теста. Каждое решение получает один из четырёх исходов: ADOPT (берём), REJECT (не подходит этой задаче), DEFER (вернёмся позже) или NO-PATTERN (задача решается прямым кодом без заимствования архитектуры).

Для простого фильтра JSON Lines, например, агент вообще не нашёл паттерна для заимствования и обошёлся стандартной библиотекой. Исследование не заставляет утилиту обзаводиться архитектурой ради красивого плана.

Где проверка заканчивается?

Проверяющая программа rfb.py контролирует согласованность записей: разорванные связи, решения без оснований, обязательные проверки. Но она не читает чужие репозитории, не ходит в сеть и не запускает команды из JSON.

Граница честная: если агент написал неверный вывод или сохранил поддельный результат теста, структура отчёта останется формально правильной. Содержание выводов и команд нужно проверять отдельно, вручную.

Сравнительного эксперимента, который доказал бы ускорение разработки с RFB, пока нет. Автор прямо об этом говорит.

Что это даёт вам прямо сейчас?

Авторам Дзена и копирайтерам. Если вы используете ИИ-агента для генерации текстов или кода, попробуйте тот же принцип: требуйте от агента сначала показать источники и обосновать выбор, а потом уже выдавать результат. Промпт (запрос к нейросети) вида «сначала изучи три аналога, объясни, что берёшь и почему, потом пиши» работает лучше, чем «просто сделай».

Предпринимателям и разработчикам в РФ. RFB работает локально, Python и SQLite доступны без ограничений. Инструмент открыт, исходники на GitHub, README переведён на русский. Для запуска нужен Python 3.11 или новее. Вариант установки через пакет требует Node.js 22.20 или новее.

Маркетологам. Практический вывод: когда подрядчик говорит «мы использовали ИИ-агента», спрашивайте, есть ли цепочка от требования к решению и к проверке. Если нет, результат не верифицируем. Этот вопрос работает для любого проекта, не только для кода.

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

По данным репозитория Research First Builder