simbiot-harness/artifacts/mirofish-analysis-2026-10-04.md

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).