Внутри MiroFish: как кодовая база из 644 символов симулирует будущее с помощью роевого интеллекта

Когда MiroFish занял первое место в GitHub Global Trending в марте 2026 года, предложение звучало неотразимо: загрузите новостную статью или проект политического решения, опишите, что хотите предсказать, и система вернёт детальный прогнозный отчёт — сгенерированный тысячами ИИ-агентов, живущих в симулированном параллельном мире. Созданный Го Ханцзяном, китайским студентом-бакалавром, MiroFish позиционирует себя как «Простой и универсальный движок роевого интеллекта, предсказывающий что угодно».

Амбиции огромны. Но что на самом деле происходит внутри кода, когда вы нажимаете «Запустить»? Это настоящая мультиагентная симуляция с эмерджентным интеллектом, или просто изощрённая обёртка вокруг вызовов LLM API? Чтобы разобраться, я проиндексировал всю кодовую базу MiroFish с помощью Code Indexer [3] — семантического поискового движка по коду — и провёл полный глубокий аудит: извлечение символов, анализ цепочек вызовов, профилирование сложности, обнаружение мёртвого кода и сканирование безопасности. Вот что я обнаружил.

Расследование: 644 символа, 5 886 перекрёстных ссылок

Code Indexer обработал 85 исходных файлов MiroFish (34 Python, 15 Vue, 8 JavaScript) менее чем за 2 секунды, создав 1 692 индексированных чанка, 644 символа и 5 886 перекрёстных ссылок. Отчёт по проекту немедленно выявил центр архитектурной тяжести: слой бэкенд-сервисов — не Vue-фронтенд — это то место, где MiroFish живёт и дышит.

Распределение символов рассказывает чёткую историю: один report_agent.py содержит 72 символа — более чем вдвое больше, чем simulation runner. Это система, которая серьёзно инвестирует в пост-симуляционный синтез интеллекта, а не только в исполнение агентов.

Архитектура: пятистадийный конвейер

MiroFish работает как пятистадийный конвейер, трансформирующий сырую исходную информацию в прогнозные отчёты. Прослеживание цепочек вызовов через инструменты find_callers и find_references Code Indexer обнаруживает удивительно глубокую архитектуру.

graph TD
  A["1. Загрузка исходных материалов"] --> B["2. Построение графа знаний"]
  B --> C["3. Создание среды и агентов"]
  C --> D["4. Двухплатформенная симуляция"]
  D --> E["5. Генерация отчёта и глубокое взаимодействие"]
  B -->|Zep Cloud API| F["Автономный граф"]
  F -->|GraphRAG| C
  C -->|LLM-генерация персон| G["Профили агентов OASIS"]
  G --> D
  D -->|Twitter + Reddit| H["БД действий агентов"]
  H -->|Graph Memory Updater| F
  E -->|InsightForge + PanoramaSearch| F

Стадии 1–2: от текста к графу знаний

Когда вы загружаете документ — новостную статью, проект решения или финансовый отчёт — MiroFish сначала пропускает его через OntologyGenerator, который вызывает LLM для извлечения типов сущностей и связей из текста. Результат — структурированное определение онтологии (типы сущностей вроде «Студент», «Медиа-издание», «Государственное учреждение»; типы рёбер вроде «reports_on», «opposes»). Эта онтология затем отправляется в Zep Cloud через GraphBuilderService.

find_references('OpenAI') в Code Indexer обнаруживает паттерн LLM-интеграции: три отдельных файла создают клиенты OpenAI — llm_client.py, oasis_profile_generator.py и simulation_config_generator.py. Все используют один и тот же OpenAI-совместимый SDK, настраиваемый через переменные окружения LLM_BASE_URL и LLM_API_KEY. Это означает, что MiroFish модель-агностичен: он работает с любым OpenAI API-совместимым провайдером — самим OpenAI, Qwen-plus от Alibaba (рекомендуемая модель), Anthropic через прокси или даже локальным Ollama.

Стадия 3: инженерия персон — где LLM становятся людьми

Именно здесь MiroFish становится по-настоящему интересным. OasisProfileGenerator (32 символа, цикломатическая сложность 28 только для поиска сущностей) не просто назначает случайные атрибуты агентам. Он запрашивает граф знаний Zep для каждой сущности, извлекает связи и контекст, затем подаёт всё это в LLM с тщательно составленным системным промптом для генерации богатого профиля персоны.

Для индивидуальных агентов (студенты, профессора, журналисты) генератор создаёт детальные предыстории, измерения личности (уступчивость, открытость, напористость), предубеждения в мнениях и паттерны поведения в социальных сетях. Для институциональных агентов (университеты, медиа-издания) он генерирует организационные стили коммуникации и официальные позиции. Каждая персона включает тип MBTI, биографический нарратив и набор «базовых убеждений», которые будут направлять поведение при симуляции.

Анализ сложности Code Indexer помечает _search_zep_for_entity (CC=28) и _build_entity_context (CC=20) как две самые сложные функции в этом модуле. Высокая сложность обусловлена обработкой многочисленных краевых случаев в API графа Zep — постраничное извлечение узлов, временная фильтрация рёбер (valid_at, expired_at) и откат к локальному поиску по ключевым словам при сбое семантического поиска Zep.

Стадия 4: симуляционный движок OASIS

Симуляционный слой MiroFish построен на OASIS (Open Agent Social Interaction Simulations) [1] — фреймворке с открытым исходным кодом от команды CAMEL-AI [4], разработанном для масштабируемой мультиагентной социальной симуляции. Ключевой вывод из статьи OASIS: значимые социальные феномены, такие как групповая поляризация и стадное поведение, проявляются только в масштабе — обычно требуя более 10 000 агентов.

Скрипт run_parallel_simulation.py (35 символов, крупнейший симуляционный файл) оркестрирует двухплатформенную симуляцию: агенты одновременно взаимодействуют в симулированном Twitter и симулированном Reddit. find_by_signature(is_async=true) в Code Indexer обнаруживает 19 асинхронных функций, приводящих в движение этот двигатель — от run_twitter_simulation (CC=29) и run_reddit_simulation (CC=31) до индивидуальных обработчиков интервью с агентами.

Каждый раунд симуляции протекает следующим образом: планировщик активности (моделирующий паттерны китайского часового пояса — пиковые часы 19:00–22:00, почти нулевая активность 0:00–5:00) определяет, какие агенты активны. Активные агенты получают свою персону, недавнюю память и текущую социальную ленту. Они выбирают из 23 возможных действий OASIS — пост, комментарий, лайк, репост, подписка, мут — и результаты записываются в базу данных SQLite и одновременно отправляются обратно в граф Zep через ZepGraphMemoryUpdater (32 символа).

Этот цикл обратной связи критически важен: действия агентов обновляют граф знаний в реальном времени, что означает, что более поздние агенты в том же раунде могут видеть и реагировать на посты более ранних агентов. Мнения эволюционируют. Информационные пузыри формируются. Вирусный контент распространяется. Симуляция не просто запускает LLM-вызовы параллельно — она конструирует эволюционирующую социальную реальность.

Стадия 5: Report Agent — ReACT встречает социологию

С 72 символами report_agent.py является самым сложным модулем MiroFish. Анализ сложности Code Indexer подтверждает: _generate_section_react (CC=31) и _post_process_report (CC=25) входят в число функций с наивысшей сложностью во всей кодовой базе.

Report Agent реализует полный цикл ReACT (Reasoning + Acting) с использованием вызова инструментов в стиле LangChain. При генерации прогнозного отчёта он имеет доступ к четырём специализированным инструментам извлечения:

• InsightForge (CC=19): Самый мощный инструмент. Автоматически декомпозирует вопрос пользователя на подзапросы, выполняет многомерный семантический поиск по графу Zep и синтезирует инсайты по сущностям с цепочками связей. find_callers('search_graph') в Code Indexer прослеживает этот инструмент непосредственно до ядра API поиска по графу.
• PanoramaSearch: Извлекает полную панораму графа, включая устаревшие/исторические факты — критически важно для понимания эволюции мнений во времени.
• QuickSearch: Легковесный семантический поиск для быстрого извлечения фактов.
• InterviewAgents: Самый замечательный инструмент — он выбирает релевантных агентов из симулированного мира по типу их персоны и роли, затем проводит LLM-«интервью», где каждый агент отвечает в соответствии с характером, основываясь на прожитом опыте симуляции.

Report Agent планирует, какие инструменты использовать, выполняет их последовательно, рефлексирует над результатами и итерирует, пока не соберёт достаточно доказательств для написания полноценного раздела. Каждый раздел генерируется независимо, затем финальный этап пост-обработки (_post_process_report, CC=25) согласовывает разделы в связный отчёт с должными цитатами из данных симуляции.

Глубокий аудит: оценка 33/100

Глубокий аудит Code Indexer рисует нюансированную картину. Проект набирает 33/100 в целом — оценка F. Но разбивка по категориям показывает, что слабые места MiroFish сконцентрированы в инженерной дисциплине, а не в ядре инноваций.

Оценка безопасности безупречна: 20/20, никаких критических находок. Это важно — MiroFish обрабатывает API-ключи и запускает фоновые процессы, так что уязвимости инъекции были бы катастрофичны. Оценка архитектуры (4/10) отражает отсутствие циклических зависимостей при 20 хотспотах связности и 11 файлах с низкой связностью. Главные болевые точки:

• Покрытие тестами: 0% — ноль тестовых файлов обнаружено. Для системы, делающей «предсказания», это критический пробел.
• Поддерживаемость: 0/15 — 30 дубликатов кода и 18 «god files» (файлов, делающих слишком много). Скрипты параллельной симуляции разделяют массивные объёмы дублированной логики между раннерами Twitter и Reddit.
• Документация: 2/10 — только 48 из 568 функций имеют документирующие строки.
• Гигиена: 0/15 — 30 магических чисел разбросаны по кодовой базе (захардкоженные таймауты, индексы массивов, пороговые значения).

Анализ мёртвого кода пометил более 100 потенциально неиспользуемых функций — многие из которых являются обработчиками маршрутов Flask, зарегистрированными через декораторы (ложноположительные), но также и подлинный осиротевший код из слоя API фронтенда. Анализ связности обнаружил, что report_agent.py и zep_tools.py изменяются вместе в 60% случаев — признак тесной связности, которая выиграла бы от более чистой границы интерфейса.

Требования к LLM: сколько это реально стоит?

MiroFish требует два внешних сервиса: OpenAI-совместимый LLM API и Zep Cloud для граф-памяти. Давайте проследим, куда идёт каждый LLM-вызов.

find_references('OpenAI') в Code Indexer идентифицирует ровно 6 точек инстанцирования клиентов OpenAI в 3 файлах. LLM вызывается при:

• Генерации онтологии — извлечение типов сущностей/связей из исходных документов (1–2 вызова)
• Генерации профилей — создание персон агентов (1 вызов на агента, потенциально сотни)
• Конфигурации симуляции — генерация временных параметров, событий и настроек платформ (3–5 вызовов)
• Выполнении симуляции — каждое действие агента в каждом раунде требует LLM-вызова через OASIS
• Генерации отчёта — цикл ReACT делает 5–15 вызовов на раздел отчёта, плюс декомпозиция подзапросов InsightForge

Для типичной симуляции с 50 агентами, работающей 72 симулированных часа (72 раунда по 1 часу, с 5–20 активными агентами в раунд), вы получаете примерно 500–1 400 LLM-вызовов только для симуляции, плюс ещё 50–100 для генерации отчёта. Рекомендуемая модель — Qwen-plus от Alibaba через Bailian API, что значительно дешевле OpenAI GPT-4. Офлайн-форк от сообщества (nikmcfly/MiroFish-Offline) даже заменяет Zep на Neo4j и использует Ollama для полностью локальной работы.

Работает ли это? Исследования за мультиагентным предсказанием

Научный фундамент подхода MiroFish покоится на статье OASIS [1], опубликованной на arXiv в ноябре 2024 года. Команда CAMEL-AI валидировала OASIS в трёх ключевых экспериментах:

• Распространение информации: OASIS достиг ~30% нормализованной RMSE при моделировании распространения информации в симулированном Twitter, воспроизведя паттерны из реальных исследований распространения новостей.
• Групповая поляризация: Симулированные агенты последовательно принимали более экстремальные мнения в ходе взаимодействий, воспроизводя хорошо задокументированный эффект поляризации — особенно выраженный с нецензурированными LLM-моделями.
• Стадное поведение: ИИ-агенты оказались более восприимчивы к стадному поведению, чем люди, особенно в следовании негативным трендам — находка с импликациями для точности предсказаний.

Более широкие исследования 2024–2025 годов подтверждают жизнеспособность мультиагентной LLM-симуляции для предсказаний. Исследование 2024 года использовало 2 686 «учёных-агентов» для прогнозирования исследовательских идей, достигнув более высоких показателей сходства с реальными публикациями 2024 года по сравнению с базовыми методами. Другой фреймворк (PREDICT, EMNLP 2024) использовал мультиагентные дебаты для детекции языка ненависти, показав, что консенсус агентов превосходит классификацию одной моделью.

Однако предсказательная сила имеет чёткие границы. Мультиагентные симуляции блестяще моделируют эмерджентные социальные динамики — формирование мнений, информационные каскады, групповое поведение. Они значительно менее надёжны для точных количественных предсказаний (цены акций, электоральные результаты), поскольку LLM-агенты неизбежно несут предубеждения из своих обучающих данных. Сила MiroFish — в качественном сценарном анализе: «Как может выглядеть общественная реакция, если объявить эту политику?» — а не «Вырастет ли рынок на 3%?»

Архитектурная критика: блеск и технический долг

Анализ связности Code Indexer выявляет сильнейший паттерн совместного изменения: run_parallel_simulation.py, run_reddit_simulation.py и run_twitter_simulation.py изменяются вместе в 83% случаев с почти идентичной логикой. Это классическое дублирование кода — циклы симуляции Twitter и Reddit по сути являются одним и тем же алгоритмом с разными конструкторами платформ OASIS. Паттерн Strategy или платформо-агностичный базовый класс симуляции устранил бы сотни дублированных строк.

Интеграция с Zep — одновременно величайшая сила проекта и его крупнейший архитектурный риск. Zep Cloud обеспечивает изощрённую граф-память с временными рёбрами (факты могут устаревать), переранжированием cross-encoder и семантическим поиском. Но ZepToolsService (1 736 строк, 49 символов) реализует собственный локальный фолбэк на поиск по ключевым словам при сбое API Zep — фактически дублируя логику поиска. А зависимость от Zep Cloud означает, что симуляция не может работать без интернета (если не использовать офлайн-форк от сообщества).

SimulationConfigGenerator заслуживает особого упоминания за внимание к культурному моделированию. Код захардкожен под паттерны поведения китайского интернета — пиковая активность 19:00–22:00 по пекинскому времени, почти нулевая активность 0:00–5:00, утренний разогрев 6:00–8:00. LLM получает промпт для корректировки этих паттернов под конкретный сценарий (студенческая аудитория может иметь более поздние пики, медиа-сущности могут быть активны 24/7). Такой уровень социокультурной калибровки редок в симуляционных фреймворках и указывает на китайское академическое происхождение проекта.

Методология расследования: Code Indexer на практике

Этот анализ был проведён целиком с использованием Code Indexer [3] — семантического поискового движка по коду, разработанного для ИИ-ассистированного понимания кода. Использованная цепочка инструментов:

• index_project — Проиндексировал 85 файлов MiroFish менее чем за 2 секунды, сгенерировав 1 692 чанка и 644 символа
• project_report — Мгновенное определение техстека (Python 51%, Vue 22%, JavaScript 12%), анализ зависимостей, идентификация ключевых модулей по плотности символов
• audit_project (deep mode) — Комплексный аудит качества: сканирование безопасности, анализ сложности, обнаружение мёртвого кода, хотспоты связности, оценка связности, анализ taint. Завершён за ~3 минуты
• find_complex_functions — Идентифицировал 15 функций с цикломатической сложностью ≥ 8, точно указав архитектурные хотспоты
• find_references — Проследил использование OpenAI SDK по всей кодовой базе, раскрыв точные точки LLM-интеграции
• find_callers (transitive) — Построил граф вызовов от API-эндпоинтов вглубь до ядра операций поиска по графу
• find_dead_code — Пометил 100+ потенциально неиспользуемых функций для очистки
• find_by_signature — Обнаружил все 19 асинхронных функций, приводящих в движение симуляционный двигатель

Рабочий процесс прошёл от «никогда не видел этот код» до «полное архитектурное понимание» примерно за 4 минуты индексации и исследования. Для бэкенда на Python объёмом 15 000+ строк со сложными межсервисными зависимостями это разница между выходными ручного исследования и полуднём систематического открытия.

Заключение: будущее — это цифровой аквариум

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

Качество кода рассказывает историю амбициозной open-source разработки: блестящие архитектурные идеи (многомерное извлечение InsightForge, культурное моделирование часовых поясов, система интервью с агентами), обёрнутые в типичный технический долг быстро развивающегося проекта — ноль тестов, дублированная логика симуляции и 18 god-файлов. Оценка аудита 33/100 жёсткая, но справедливая; оценка безопасности 20/20 успокаивает.

Может ли MiroFish предсказать будущее? Не в каком-либо точном, количественном смысле. Но он может симулировать сложные социальные реакции на новую информацию в масштабе, который был бы невозможен при традиционных опросах или фокус-группах. Подайте ему проект политического решения и 50 тщательно выстроенных персон агентов — и вы получите качественную песочницу, где разыгрываются динамики мнений: поляризация возникает, информационные пузыри формируются, вирусные нарративы распространяются. Совпадут ли эти эмерджентные паттерны с реальными исходами — целиком зависит от качества исходных данных и способности LLM убедительно отыгрывать роли.

Для исследователей, политических аналитиков и всех, кому любопытно коллективное человеческое поведение, MiroFish стоит внимания. Для инженеров — это мастер-класс по архитектуре мультиагентных систем и поучительная история о том, что бывает, когда вы отправляете 15 000 строк Python без единого теста.