Как исследовать программу с REA и Kimi Code: от вопроса до проверки

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

В этой связке REA собирает технические наблюдения о программе, а Kimi Code подключает агента, который помогает задавать вопросы, интерпретировать результаты и планировать проверки. Модель не заменяет анализатор: важно видеть, какие выводы подтверждены материалами, а какие остаются предположениями.

Ниже — последовательный разбор от выбора цели до тестов. Он подходит для программ, которые вы написали сами, открытых проектов и другого ПО, исследовать которое вам разрешено.

1. Выберите законную цель и один сценарий

Сначала проверьте свои права

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

Не начинайте с задачи «разобрать всё»

Сформулируйте один вопрос о наблюдаемом поведении. Например: почему калькулятор после ввода «200 + 10%» показывает 220? Такой вопрос задаёт границы проверки: нужно понять, от какого числа вычисляется процент и как результат отображается. Просьба «полностью изучить приложение» слишком широка — агенту будет трудно выбрать важные участки, а вам будет сложно проверить ответ.

Полезная формула запроса: «При каких входных данных происходит это действие? Какие функции или правила на него влияют? Что подтверждает каждую часть ответа?» Чем точнее вопрос, тем легче отделить найденные факты от догадок.

2. Подключите REA к Kimi Code

Что делает каждый компонент

REA предоставляет инструменты анализа через MCP — открытый способ подключать внешние инструменты к агенту. В зависимости от типа цели REA может исследовать файлы приложения, JavaScript и .NET, либо подключать профильные средства для анализа нативных бинарных файлов. Результатом становятся не «ответы модели», а наблюдения с описанием источника и ограничений.

Kimi Code — среда, в которой агент получает доступ к этим инструментам. В документации Kimi Code предусмотрены пользовательская и проектная конфигурации MCP, интерактивная настройка через команду /mcp-config и просмотр состояния подключений через /mcp. После изменения настроек создайте новую сессию, чтобы сервер REA появился среди доступных инструментов. Текущую последовательность установки и совместимые анализаторы проверяйте в документации REA и справке Kimi Code по MCP.

В качестве модели можно использовать доступную в вашей конфигурации версию Kimi, например Kimi K3. REA и Kimi Code при этом остаются отдельными компонентами: первый добывает технические сведения, второй организует работу агента и помогает разбирать результаты.

3. Ведите разбор по циклу «вопрос — доказательство — проверка»

Идите от одной гипотезы к следующей

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

Такой цикл помогает не запускать одну и ту же тяжёлую процедуру повторно без причины. Если выводов много, просите агента разбирать сохранённые результаты частями и ссылаться на конкретные Evidence ID — идентификаторы записей с доказательствами.

Разделяйте наблюдения, выводы и неизвестное

В отчёте держите три отдельные группы. Наблюдение — то, что инструмент действительно нашёл: вызов функции, строку, ветвление или связь между модулями. Вывод — объяснение того, что это может означать для поведения программы. Неизвестное — то, чего имеющихся данных не позволяют установить.

Это особенно важно для статического анализа. Если декомпилятор показал ветвление, это ещё не доказывает, что конкретная ветка выполнялась при запуске. Чтобы подтвердить такое предположение, понадобятся динамическое наблюдение или проверка на входных данных. Не просите модель выдавать предположение за увиденное исполнение программы.

4. Распараллеливайте независимые вопросы, а не весь анализ подряд

Как распределить работу между агентами

Когда первая карта программы готова, составьте перечень независимых вопросов: где меняется состояние, что происходит при ошибке, как обрабатывается крайнее значение, какие модули отвечают за экспорт. В Kimi Code команду /swarm можно использовать для параллельных подзадач одного типа. Попросите каждого участника вернуть краткий вывод со ссылками на доказательства, а затем сведите ответы в общий список открытых вопросов.

У Kimi есть также отдельный облачный продукт Agent Swarm. В его справке указана возможность создавать до 300 субагентов и выполнять более 4 000 вызовов инструментов в одной задаче. Это не тот же режим, что /swarm внутри Kimi Code: облачная система рассчитана на масштабные текстовые и исследовательские задачи, использует ресурсы аккаунта и может передавать ей материалы из запроса. Для локального анализа бинарного файла сотни агентов не заменяют подключённый анализатор и проверку человеком.

Передайте в облачную систему только те выводы и файлы, которыми разрешено делиться. Для Agent Swarm действуют квоты и расход кредитов, зависящие от задачи и числа субагентов; актуальные ограничения опубликованы в официальной справке Kimi.

5. Учитывайте, какие данные покидают компьютер

Локальный анализ не означает полностью локальную работу

REA может выполнять анализ на вашем устройстве, но сам агент обычно обращается к модели через выбранного провайдера. В зависимости от задачи в запрос к модели могут попасть фрагменты кода, имена файлов, найденные строки и результаты инструментов. Если вы используете облачный Agent Swarm, его сервис также получает те материалы, которые вы отправляете туда.

Проверьте правила обработки данных у выбранного провайдера и настройки Kimi Code. Если исходный код или двоичный файл нельзя передавать за пределы организации, не отправляйте в облако ни сам файл, ни его чувствительные фрагменты. Для работы с закрытыми системами заранее согласуйте локальную модель, допустимый объём контекста и хранение журналов.

6. Восстановите правило, а не копируйте программу

Разделите оригинал, описание и новую реализацию

Когда механизм стал понятнее, зафиксируйте его в виде спецификации: входные условия, порядок действий, результат, ошибки и ограничения. Затем реализуйте нужное поведение в собственном коде. Исходная программа остаётся неизменённым эталоном, описание правила — отдельным документом, новая реализация — отдельным проектом.

Так проще объяснить происхождение решения и проверить его независимо. Не переносите фрагменты исходного кода в новую программу без соответствующего разрешения: цель такого процесса — восстановить и проверить поведение, а не получить копию чужой реализации.

7. Проверьте результат на одинаковых входных данных

Составьте матрицу тестов

Запустите исходную и новую программы на одних и тех же сценариях. Для каждого правила проверьте обычный пример, границы диапазона, ноль и отрицательные значения, очень большие числа, пустые или повреждённые данные и обе стороны каждого условия. Если приложение меняет состояние, проверьте не только отдельное действие, но и последовательность действий.

Сравнивайте не только итоговый экран. Важны формат данных, сообщения об ошибках, округление, побочные эффекты и то, как программа ведёт себя при повторном вызове. Запишите вход, ожидаемый результат, фактический результат обеих версий и ссылку на вывод REA, который объясняет правило.

Совпадение тестов — не доказательство полной идентичности

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

Что даёт такая связка

REA помогает структурировать техническое исследование и оставлять проверяемый след; Kimi Code — задавать последующие вопросы, распределять независимые задачи и формировать тесты; инженер определяет законную область анализа и принимает решение о том, что считать подтверждённым. Такой подход полезен для совместимости, сохранения старого ПО и изучения собственного кода — при условии, что права на исследование и передача данных провайдеру заранее проверены.

Для продолжения можно открыть страницу REA, библиотеку REA-Prompts и обзор инструментов обратного анализа с ИИ. В репозитории REA опубликованы текущие ограничения, документация и инструкция по настройке.