# MiroFish (github 666ghj/MiroFish): разбор и применимость — 2026-10-04

Задача: t-261004062405-fa9926. Метод: клон репо (depth 1), разбор кода backend
(58 py-файлов, ~17.2k строк) + README. Версия зависимостей: camel-oasis==0.2.5,
zep-cloud==3.25.0, flask>=3.0, openai>=1.0.

## Вердикт

**Как движок — НЕ берём. Как источник паттернов — да, 3-5 идей.**
Причины против движка: (1) стоимость — README сам пишет «High consumption,
попробуйте сначала <40 раундов»; (2) жёсткая привязка к Zep Cloud (внешний
SaaS-граф памяти, счёт отдельно от LLM) и OASIS/camel-ai; (3) китайский
дефолт-стек (qwen-plus через dashscope) — у нас 9router; (4) это продукт-платформа
(Flask 5001 + React 3000 + Docker), а не библиотека — интеграция = second brain.

## Архитектура (проверено по коду)

Пайплайн: **Graph Building → Environment Setup → Simulation → Report → Interaction**

1. **Graph Building** (`graph_builder.py` 879 строк, `ontology_generator.py` 732):
   seed-материалы (новости/политики/финанс.сигналы, PDF/текст) → извлечение
   сущностей и связей → GraphRAG-граф в Zep (онтология генерится LLM).
2. **Environment Setup** (`oasis_profile_generator.py` 1248): из сущностей Zep
   LLM-ом генерятся персоны агентов — индивидуальные и групповые
   (`generate_profile_from_entity` → `_generate_profile_with_llm`, JSON-схема,
   username, bio, persona-текст) → конфиг агентов инжектится в OASIS.
3. **Simulation** (`simulation_runner.py` 2033, `run_parallel_simulation.py` 1699,
   twitter/reddit скрипты): движок **OASIS (camel-ai)** — двухплатформенная
   параллельная симуляция соцсети (Twitter+Reddit). Раунды = часы×60/минут_на_раунд,
   есть max_rounds-обрезка (контроль стоимости). Каждый агент за раунд —
   действие через `LLMAction` (≥1 LLM-вызов на активного агента за раунд).
   Память: каждое действие → episode-текст → динамическое обновление Zep-графа
   (`zep_graph_memory_updater.py` 791: описатели create_post/like/repost/
   comment/follow/search).
4. **Report** (`report_agent.py` 2619 — самый большой модуль): ReportAgent с 4
   инструментами — `insight_forge`, `panorama_search`, `quick_search`,
   `interview_agents` (интервьюирует агентов мира post-factum); протокол
   `<tool_call>{...}</tool_call>`, трекер «не все инструменты использованы»
   дожимает агент до полного отчёта.
5. **Interaction**: чат с любым агентом мира + ReportAgent (фронт).

Память = **Zep Cloud** (knowledge-graph + temporal): не векторная база, а граф
сущностей с би-темпоралью; free-тариф «на простое использование».

## Оценка стоимости прогона

Формула расхода: ~ `N_агентов × N_раундов` LLM-вызовов (действия) + граф/онтология
+ персоны + отчёт (десятки вызовов) + инференс Zep (граф-обновления, отдельный счёт).

- Заявленный дефолт: qwen-plus. README: «<40 раундов на старте».
- Пример: 100 агентов × 40 раундов ≈ 4–5k вызовов ≈ 15–25M входящих токенов
  (контекст платформы в каждом) → **~$10–25 на qwen-plus за прогон**;
  на премиум-модели класса GPT-4o — **×10–30 (сотни $)**.
- Осмысленный прогнозный прогон (500+ агентов, 100+ раундов) — **сотни $ за
  прогон** даже на дешёвых моделях + Zep Cloud сверх.
- Контекст: наш burn 9router = 2291.81 у.е./7д — один-два «взрослых» прогона
  MiroFish съели бы заметный кусок недельного бюджета без прямой выручки.

## Что берём (идеи заимствования)

1. **Персона-из-сущности** (`_generate_profile_with_llm`): LLM-генерация
   структурированной персоны агента из записи графа знаний (JSON-схема, инди/групп).
   Куда: v2 aum-pilot — вместо placeholder-модели продуктивности, агентные симуляции
   решений кооператива (роли: Alex/Vlad/Yura/клиент) с сгенерированными персонами.
2. **ReportAgent-паттерн**: отчётёр = агент с узким набором инструментов
   (сводка/поиск/дип-поиск/интервью) + трекер обязательного использования всех
   инструментов. Куда: наш «отчёт-адвокат» в aum-pilot и часовые дайджесты —
   интервью опрошенных агентов симуляции вместо голой статистики.
3. **Episode→граф памяти**: действие → компактный episode-текст → обновление
   графа по ходу симуляции (не в конце). Куда: память ритмичных агентов харнеса
   — но на нашем RAG (без Zep: episode → embedding → граф связей) — паттерн
   повторяем, сервис не покупаем.
4. **Предпродажная симуляция спроса**: OASIS даёт готовую соц-динамику
   (лайк/репост/коммент/фоллов). Идея под AUM: перед запуском лендинга/прайса —
   дешёвый прогон (20–40 раундов, flash-модель, 50–100 агентов-«клиентов» из
   персон сегмента) → прогноз реакции и возражений. Это прямой кандидат в
   наши симуляции поведения пользователей.
5. **Автогенерация конфига из NL-запроса** (`simulation_config_generator.py`):
   «что хочешь узнать» естественным языком → параметры прогона + max_rounds
   (жёсткий потолок стоимости). Куда: постановка задачи → конфиг прогона
   aum-pilot; потолок раундов — в наши длинные симуляции.
6. **IPC/прогресс долгих прогонов** (`simulation_ipc.py` + progress %):
   отдельный процесс, структурированный прогресс, чистая обрезка. У нас уже
   есть _llm_worker — позаимствовать схему прогресса/тримминга.

## Чего не берём

- Zep Cloud (внешний SaaS, счёт отдельно, данные наружу) — свой RAG/graph.
- OASIS целиком (тяжёлый camel-ai стек) — только если сделаем п.4; тогда
  изолированный Docker-стенд, flash-модель через 9router, budget-cap на прогон.
- Их фронт/платформу — у нас свои каналы (портал, MCP, TG).