MiroFish

MiroFish 自称"简洁通用的群体智能引擎，预测万物"，但更诚实的读法是：它是一个情景生成器，而不是预言机。你给它一条新闻或一个事件，它会生成一群扮演不同角色的 Agent，展示可能出现的连锁反应。项目于 2025 年 11 月以 AGPL-3.0 协议开源，到 2026 年 9 月下旬 star 已突破 75,000，这既是它作为最热门开源多智能体项目之一的证明，也正好说明 star 数和成熟度是两回事。中文技术圈很快就给出了准确的定位：MiroFish 补充的是利益相关方、二阶影响和反直觉路径，而不是预测未来。

核心功能

• 角色群：大量 Agent 承担不同角色，输出反映的是彼此冲突的利益，而不是把意见平均后的一个声音。
• 事件驱动输入：给它一条新闻或一段事件描述，它会围绕它生成情景空间。
• 连锁反应映射：价值在于单个分析者容易跳过的那二阶、三阶影响。
• Python 实现：引擎是 Python 写的，想改角色设定或评估循环的团队都能直接上手。
• 本地优先的分支：nikmcfly/MiroFish-Offline、tt-a1i/MiroFish-local 等社区项目用 Neo4j 与 Ollama 替换了付费图存储，整套可以跑在自己的机器上。
• 多种入口：除仓库之外，还有 CLI 分支和 mirofish.ai 的托管站点。

适用场景

谁应该使用这个工具？

• 已经有初判的分析者：把它当作压力测试最有用，能逼出第一版答案漏掉的反对意见和依赖关系。
• 评估多智能体方法的研究者：代码库是一份可研究、可扩展的角色模拟具体实现。
• 做情景规划的团队：在拍板之前，先模拟不同利益群体可能如何反应。

解决的问题

1. 单一视角：一个模型一个答案。一群角色能把被单一叙事压平的利益摆出来。
2. 漏掉二阶效应：一个事件真正有意思的后果很少是第一层的，而这正是模拟要暴露的东西。
3. 模拟工具太贵：它开源，且许多分支可跑在本地基础设施上，成本不像企业级模拟套件那样构成门槛。

定价方案

引擎在 AGPL-3.0 下免费开源，官方托管入口是 mirofish.ai。实际成本是群体消耗的 token 和算力，随角色数量和模拟长度增长，再加上你接入的图或向量存储。社区分支专门用 Neo4j 与 Ollama 替换付费组件来压低这份账单；另外如果你打算把修改版当作网络服务提供，AGPL 条款需要认真对待。

优势对比

相比竞品：

1. 群体而非单发：问 30 个角色和问一个模型 30 次是两种操作，分歧本身才是产品。
2. 可改造的底座：当你要测的正是方法本身时，Python 加成熟的 fork 生态胜过闭源模拟产品。
3. 离线路径：离线与本地分支意味着流程不依赖第三方图服务。

独特卖点：

• 把自身定位为情景生成器而非预测引擎，这个说法既准确又有用。
• 活跃的 fork 生态说明社区在把它适配到受限环境。
• AGPL-3.0 是实打实的约束，但也意味着改进会留在开源侧。

用户评价

对 MiroFish 最有价值的评价来自一位中文技术评论者：它更适合被定义为"情景生成器"而不是预测未来的工具，其作用是补充利益相关者、二阶影响和反直觉路径，输出质量仍取决于角色设定、初始信息和评估方法。这与代码库一致：引擎是框架，严谨程度要你自己提供。第二种常见反应是对规模的怀疑。群体很容易生成看似合理的故事，却很难给出事实真相，因此把它用于规划的团队，应把输出当成待验证的假设清单，而不是可直接汇报的结论。

快速开始

入门指南

1. 先读仓库：README 与离线分支文档会告诉哪些组件是付费的、哪些可以替换。
2. 选择部署方式：用托管入口试水，数据不能出网就从本地分支开始。
3. 认真设计角色阵容：让角色拥有互相冲突的利益和明确的信息获取渠道，不要写十个通用分析师的副本。
4. 先跑一次小模拟：用熟悉的事件配少量角色，先校准你自己对它输出的判断。
5. 先复核再调查：把生成的情景转成待核实清单，然后逐条核实。

集成

• Neo4j 等图存储，参考离线分支的架构。
• Ollama 与本地模型运行时，用于本地变体。
• 你自己的评测脚本；项目发布的是引擎，不是评分权威。
• Agent 框架，如果你希望角色由另一套运行时执行。

常见问题

MiroFish 能预测未来吗？

不能，更准确的说法是情景生成器。它补充利益相关者、二阶影响和反直觉路径，但输出质量取决于角色设定、输入信息和你的评估方式。

免费吗？

引擎是 AGPL-3.0 且免费使用。成本是模拟消耗的 token 与算力，若使用托管配置还会包含付费后端组件。

能完全离线运行吗？

可以。nikmcfly/MiroFish-Offline、tt-a1i/MiroFish-local 等社区分支用 Neo4j 与 Ollama 替换付费图存储，这也是处理私有数据的常规做法。

仅内部使用也要关注协议吗？

AGPL-3.0 主要在你把修改版作为网络服务提供时产生影响。内部使用是常见情形，但作为产品发布前请与法务确认。

最大的限制是什么？

验证。生成看似合理的情景很容易，判断哪些是真的需要在工具之外做功课。

替代方案

如果 MiroFish 不适合，可以考虑：

• Jeff：需要的不是情景群体，而是每个选项一个校准好的判断时，可看这个本地决策模型。
• Buzz：目标是和 Agent 协作，而不是让 Agent 做模拟时。
• Dots：OpenAI 的常驻智能体，适合有明确交付物的任务。
• LangGraph：想用自己的编排语义定义明确的 Agent 图时更合适。

使用技巧

1. 把冲突写进角色：互相认同的角色只会产出摘要，互相反对的角色才产出情景。
2. 固定输入再改角色：一次只改一个变量，否则你不知道是哪个因素改变了输出。
3. 扩角色前先算 token 账：成本随群体规模增长，第一轮跑出来的东西通常不是你要留下的那一版。
4. 把输出当假设：模拟里任何值得汇报的内容，都值得在模拟之外再核实一遍。

总结

MiroFish 把一个容易被吹过头的想法做成了扎实的实现：模拟多种视角，就能看见单一分析者会漏掉的后果。它的热度是真实的，"情景生成器"的定位是诚实的，fork 生态也让它在数据不能出楼的环境里可用。只要你自带评估方法，并计划对有趣的情景做外部核实，它就能在规划流程里占住一个位置。