Closes the four CRITICAL findings from the 2026-06-13 review.
C1 — Werkzeug debug RCE / dev server in prod:
- FLASK_DEBUG defaults False (kills interactive-debugger network RCE)
- production runs gunicorn (-w 1 --threads 8) via `npm run start`; Dockerfile
builds the frontend and serves it with `vite preview` (host 0.0.0.0); gunicorn
+ uv.lock updated
- Config.validate() now runs inside create_app() so the gunicorn path enforces
SECRET_KEY (prod) / API_KEY / LLM / ZEP at boot
C2 — zero auth on all /api/* routes:
- before_request API-key guard (X-API-Key / Bearer), constant-time bytes compare,
/health + OPTIONS exempt
- AUTH_ENABLED fail-closed parse (only explicit false/0/no/off disables)
- frontend axios injects X-API-Key from build-time VITE_API_KEY, wired through
docker compose build-arg -> Dockerfile ARG -> vite build (+ frontend/.env.example)
C3 — denial-of-wallet (no cost ceiling; OASIS_DEFAULT_MAX_ROUNDS was dead config):
- OASIS_DEFAULT_MAX_ROUNDS now applied when max_rounds omitted (default 150, covers
the 144-round demo); hard ceilings OASIS_MAX_ROUNDS_CAP / OASIS_MAX_AGENTS_CAP;
runner always forwards the clamped rounds to the subprocess
C4 — no simulation deadline; env.step could wedge forever:
- every env.step (initial / round-loop / interview) wrapped in asyncio.wait_for
(OASIS_ROUND_TIMEOUT_SEC) across all 3 run scripts; per-loop total-deadline
(OASIS_RUN_TIMEOUT_SEC); gather(return_exceptions=True) + single-platform
try/except so one platform's failure can't skip env.close
New env vars documented in .env.example + README security section.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|---|---|---|
| .github/workflows | ||
| backend | ||
| frontend | ||
| locales | ||
| static/image | ||
| .dockerignore | ||
| .env.example | ||
| .gitignore | ||
| Dockerfile | ||
| LICENSE | ||
| README-ZH.md | ||
| README.md | ||
| docker-compose.yml | ||
| package-lock.json | ||
| package.json | ||
README.md
简洁通用的群体智能引擎,预测万物
A Simple and Universal Swarm Intelligence Engine, Predicting Anything
⚡ Overview
MiroFish is a next-generation AI prediction engine powered by multi-agent technology. By extracting seed information from the real world (such as breaking news, policy drafts, or financial signals), it automatically constructs a high-fidelity parallel digital world. Within this space, thousands of intelligent agents with independent personalities, long-term memory, and behavioral logic freely interact and undergo social evolution. You can inject variables dynamically from a "God's-eye view" to precisely deduce future trajectories — rehearse the future in a digital sandbox, and win decisions after countless simulations.
You only need to: Upload seed materials (data analysis reports or interesting novel stories) and describe your prediction requirements in natural language
MiroFish will return: A detailed prediction report and a deeply interactive high-fidelity digital world
Our Vision
MiroFish is dedicated to creating a swarm intelligence mirror that maps reality. By capturing the collective emergence triggered by individual interactions, we break through the limitations of traditional prediction:
- At the Macro Level: We are a rehearsal laboratory for decision-makers, allowing policies and public relations to be tested at zero risk
- At the Micro Level: We are a creative sandbox for individual users — whether deducing novel endings or exploring imaginative scenarios, everything can be fun, playful, and accessible
From serious predictions to playful simulations, we let every "what if" see its outcome, making it possible to predict anything.
🌐 Live Demo
Welcome to visit our online demo environment and experience a prediction simulation on trending public opinion events we've prepared for you: mirofish-live-demo
📸 Screenshots
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
🎬 Demo Videos
1. Wuhan University Public Opinion Simulation + MiroFish Project Introduction
Click the image to watch the complete demo video for prediction using BettaFish-generated "Wuhan University Public Opinion Report"
2. Dream of the Red Chamber Lost Ending Simulation
Click the image to watch MiroFish's deep prediction of the lost ending based on hundreds of thousands of words from the first 80 chapters of "Dream of the Red Chamber"
Financial Prediction, Political News Prediction and more examples coming soon...
🔄 Workflow
- Graph Building: Seed extraction & Individual/collective memory injection & GraphRAG construction
- Environment Setup: Entity relationship extraction & Persona generation & Agent configuration injection
- Simulation: Dual-platform parallel simulation & Auto-parse prediction requirements & Dynamic temporal memory updates
- Report Generation: ReportAgent with rich toolset for deep interaction with post-simulation environment
- Deep Interaction: Chat with any agent in the simulated world & Interact with ReportAgent
🚀 Quick Start
Option 1: Source Code Deployment (Recommended)
Prerequisites
| Tool | Version | Description | Check Installation |
|---|---|---|---|
| Node.js | 18+ | Frontend runtime, includes npm | node -v |
| Python | ≥3.11, ≤3.12 | Backend runtime | python --version |
| uv | Latest | Python package manager | uv --version |
1. Configure Environment Variables
# Copy the example configuration file
cp .env.example .env
# Edit the .env file and fill in the required API keys
Required Environment Variables:
# LLM API Configuration (supports any LLM API with OpenAI SDK format)
# Recommended: Alibaba Qwen-plus model via Bailian Platform: https://bailian.console.aliyun.com/
# High consumption, try simulations with fewer than 40 rounds first
LLM_API_KEY=your_api_key
LLM_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
LLM_MODEL_NAME=qwen-plus
# Zep Cloud Configuration
# Free monthly quota is sufficient for simple usage: https://app.getzep.com/
ZEP_API_KEY=your_zep_api_key
Security configuration (required for production)
The backend ships secure-by-default. When FLASK_DEBUG=false (the default) the app
runs under gunicorn (no Werkzeug debugger) and refuses to start unless these are set:
# A random secret (required when FLASK_DEBUG=false):
# python -c "import secrets;print(secrets.token_hex(32))"
SECRET_KEY=your_random_secret
# API-key auth is ON by default — every /api/* request must carry the key.
# Clients send X-API-Key: <API_KEY> (or Authorization: Bearer <API_KEY> ).
AUTH_ENABLED=true
API_KEY=your_strong_api_key
- The bundled web UI reads the key from the build-time var
VITE_API_KEY(set it equal toAPI_KEY) and sends it automatically asX-API-Key. It must be present before the frontend is built:- Docker: put
VITE_API_KEYin the root.env;docker compose up --buildinjects it as a build-arg (docker-compose.ymlbuild.args→ DockerfileARG VITE_API_KEY→npm run build). The pre-builtghcr.ioimage (used by a baredocker compose upwithout--build) bakes no custom key — rebuild, or useAUTH_ENABLED=falsefor that path. - Local frontend build: copy
frontend/.env.example→frontend/.envand setVITE_API_KEY, thennpm run build. (The root.envis read by the backend only, not by Vite.) - ⚠️ A key baked into the client bundle is extractable by anyone who loads the page — for multi-tenant/public exposure replace this with session login or a gateway that injects per-user tokens. For local/internal/VPN or behind-a-gateway single-host use it is sufficient.
- Docker: put
- Local development / simplest single-host demo: set
AUTH_ENABLED=falseto disable the key requirement entirely (the API is then protected only by your network boundary). - Cost controls (denial-of-wallet): a run is bounded by
OASIS_DEFAULT_MAX_ROUNDS(when the client omitsmax_rounds), the hard ceilingsOASIS_MAX_ROUNDS_CAP/OASIS_MAX_AGENTS_CAP, and per-round / total timeoutsOASIS_ROUND_TIMEOUT_SEC/OASIS_RUN_TIMEOUT_SEC. See.env.examplefor defaults. - Run the production server with a single worker (
gunicorn -w 1 --threads N); simulation run-state is held in-process, so multiple workers break stop/status routing.
2. Install Dependencies
# One-click installation of all dependencies (root + frontend + backend)
npm run setup:all
Or install step by step:
# Install Node dependencies (root + frontend)
npm run setup
# Install Python dependencies (backend, auto-creates virtual environment)
npm run setup:backend
3. Start Services
# Start both frontend and backend (run from project root)
npm run dev
Service URLs:
- Frontend:
http://localhost:3000 - Backend API:
http://localhost:5001
Start Individually:
npm run backend # Start backend only
npm run frontend # Start frontend only
Option 2: Docker Deployment
# 1. Configure environment variables (same as source deployment)
cp .env.example .env
# 2. Pull image and start
docker compose up -d
Reads .env from root directory by default, maps ports 3000 (frontend) / 5001 (backend)
Mirror address for faster pulling is provided as comments in
docker-compose.yml, replace if needed.
📬 Join the Conversation
The MiroFish team is recruiting full-time/internship positions. If you're interested in multi-agent simulation and LLM applications, feel free to send your resume to: mirofish@shanda.com
📄 Acknowledgments
MiroFish has received strategic support and incubation from Shanda Group!
MiroFish's simulation engine is powered by OASIS (Open Agent Social Interaction Simulations), We sincerely thank the CAMEL-AI team for their open-source contributions!





