MiroFish 不是预言机：把多代理模拟做成可检视的决策沙盒
MiroFish 不是预言机：把多代理模拟做成可检视的决策沙盒
当团队要推估一项政策、产品发布或舆情事件会怎么发展，最常见的做法是找专家开会、做问卷，或拿过去资料建立模型。MiroFish 提出另一种路径：先把一组现实素材转成知识图谱，再生成一批具不同设定的 AI 代理人，让它们在模拟的社群环境中互动，最后整理出可能出现的情境与报告。
这个方向很吸引人，尤其当我们想问「如果改变一个条件，讨论可能往哪里走？」但我认为理解 MiroFish 的关键，不是把它当成能预知未来的系统，而是把它放在更务实的位置：一个可调整假设、观察互动、比较情境的多代理决策沙盒。它能帮忙扩展讨论，不能替真实世界背书。
先分清楚「预测」和「推演」
MiroFish 的 README 将它定位为预测引擎，并以新闻、政策草案、金融讯号等素材作为输入。依照官方流程，系统会抽取素材中的人物与关系，建立图谱，产生代理人设定，再让代理人在类似 Twitter、Reddit 的环境中互动，最后由 ReportAgent 整理结果。使用者也能在模拟后与代理人或报告代理互动。
这套流程真正擅长回答的，是「在这组输入、这些角色设定与这套互动规则之下，会长出哪些可能的讨论路径？」它并没有因为代理人数量很多，就自动变成对真实人群的抽样调查；也没有因为报告写得完整，就自动证明某个情境会发生。
这是「推演」和「预测」之间的重要界线。可靠的预测通常还需要明确的评估资料、基准模型、误差指标，以及对不同事件反复验证的纪录。就我查阅的 MiroFish 官方 README、快速开始文件与程式入口而言，没有看到可重复的预测准确率基准。因此，在缺少验证前，模拟输出应被视为待检查的假设，而不是决策结论。
MiroFish 的工作流程，拆成四个环节
1. 从素材建立图谱
使用者先提供种子材料与想回答的问题。MiroFish 的图谱服务会把文字交给 Zep Cloud，建立节点与关系；程式中的 GraphBuilderService 也明确以 Zep API 建立 standalone graph。这一步的作用，是让后续代理人设定有一份可查询的背景脉络，而不只是从一段提示词凭空开始。
素材品质会直接影响后面的推演。如果材料只呈现单一立场、缺少关键角色，或把未证实的说法当成事实，图谱与代理人设定就可能把这些偏差一路带进模拟。换句话说，图谱不是事实查核器；它整理的是输入内容，不会自动替输入补上可靠性。
2. 由模型生成模拟设定与代理人
接着，MiroFish 会依照模拟需求、文件内容与图谱实体，生成时间设定、事件设定以及一批代理人设定。官方程式把这些设定拆成不同阶段处理，代理人设定也会分批产生。每个代理人的个人资料、背景描述与行为设定，都是模拟的初始条件之一。
这表示结果不只取决于「有多少代理人」，也取决于系统如何从材料抽出角色、如何描述角色，以及模型如何依照设定产生行动。若某个重要立场没有进入素材，增加代理人数量也不会神奇地补出具代表性的真实民意。
3. 在 OASIS 社群环境中执行互动
MiroFish 使用 CAMEL-AI 的 OASIS 作为模拟引擎。OASIS 专案本身是开源的社群互动模拟器，README 说明其环境涵盖 Twitter 与 Reddit 类型的平台互动，代理人可以追踪、留言、转贴等。MiroFish 的执行程式则可选择 Twitter、Reddit 或平行模式；是否启用图谱记忆更新也有独立参数，而且程式中的预设值是关闭。
这些设计让模拟不只是一次性的文字问答：代理人会在平台规则与事件设定下反复采取行动，系统记录互动，再将结果提供给后续报告与探索。值得注意的是，OASIS README 提到的规模能力属于上游引擎的说明，不能直接当成 MiroFish 在任意硬体、任意模型或任意设定下都能达到的效能保证。
4. 产生报告，再回到互动探索
模拟结束后，ReportAgent 会根据模拟环境整理报告；使用者也能进一步与报告代理或特定代理人对话。这个互动介面很适合追问「这个情境为什么出现？」或「某个角色遇到不同资讯时可能怎么反应？」
但要记得，对代理人的追问仍然是在同一个合成环境里进行。它可以帮助我们解释模型内部发生了什么，不能把代理人的回答当成真实受访者证词，也不能拿来取代外部查证。
哪些情境适合拿它来试
我会优先把 MiroFish 用在「产生值得查证的情境」而非「替人做最后决策」。例如，公关团队可用一份已查证的事件资料，探索不同回应方式可能引发哪些讨论分支；产品团队可以比较两种功能发布说明，找出使用者可能误解的地方；研究或创作团队则可以用角色与背景设定，探索故事情节或社群互动的可能走向。
好的问题通常范围清楚、条件可变，也能指出哪些结果需要外部验证。例如：「如果公告延后一周，哪些利害关系人可能改变立场？」比「预测这家公司未来会怎样」更适合作为第一个实验。前者可以拆成可比较的条件；后者太广，容易让输出看起来完整，却很难判断是否真的有用。
如何开始：先跑一个小规模情境
MiroFish 官方快速开始提供原始码与 Docker 两种部署方式。原始码路径需要 Node.js 18 以上、Python 3.11 至 3.12，以及 uv。系统还需要一个相容 OpenAI SDK 格式的 LLM API，以及 Zep Cloud 帐户。环境变数范例包含 LLM_API_KEY、LLM_BASE_URL、LLM_MODEL_NAME 与 ZEP_API_KEY；请把实际凭证留在本机 .env，不要贴进程式码、Issue 或公开日志。
git clone https://github.com/666ghj/MiroFish.git
cd MiroFish
cp .env.example .env编辑本机 .env，填入模型服务与 Zep Cloud 的必要设定后，再安装前后端依赖并启动：
npm run setup:all
npm run dev依照 README，前端预设在 http://localhost:3000，后端 API 预设在 http://localhost:5001。若启动失败，先分别确认 Node.js、Python 与 uv 版本，再检查 .env 是否填妥、模型服务的 LLM_BASE_URL 是否可连线，以及 Zep Cloud 凭证是否有效。第一次测试不要直接喂入大量文件或设定很多轮：官方 README 提醒模拟消耗可能偏高，并建议先从少于 40 轮的设定开始。这是专案提供的使用建议，不代表所有模型、素材与场景的成本都相同。
我的建议是先用一份短而可查证的材料，写下一个具体问题，固定代理人规模与其他设定，只改一个条件，观察报告是否真的呈现出可比较的差异。把原始素材、模型名称、模拟轮数、角色设定与输出都记录下来，之后再用访谈、问卷、历史案例或专家检视去验证。若每次更换提示词、角色数与事件设定，结果就很难知道是哪个变因造成的。
把一次模拟做成可回顾的小实验
如果我想用 MiroFish 探索一项公告的反应，不会只输入「大家会怎么想？」然后把生成报告当答案。我会先写下决策问题，例如「先公布完整时程，或先发布原则说明，哪一种更容易引发对交付日期的误解？」接着准备一份相同的背景材料，确认关键角色与事件都在其中，再把两种公告方式设为不同情境。
比较时一次只改一个主要条件。基准组与变化组尽量沿用相同的材料、代理人规模、模拟轮数与模型设定，并保存每次使用的文件版本、问题描述、设定、执行时间及输出。若同一组设定重跑后出现不同走向，也把差异留下来，而不是只挑最符合预期的一次。这些纪录能让团队回头检查：结论是由哪个输入或设定推动，还是只是一段读起来很有说服力的叙事。
阅读报告时，我会把「模拟中实际发生的行为」、「代理人或报告代理对行为的解释」，以及「团队因此提出的现实世界假设」分开记录。三者不是同一种证据。接下来再挑出最重要的两三个假设，用过去事件、使用者访谈、专家检视或小规模实验来验证。若外部资料不支持模拟结果，就应修正假设，而不是为了保住报告而替结果找理由。
这种做法不会让模拟突然变成经过校准的预测模型，但能让它成为有边界、有纪录、可以被反驳的探索流程。对团队而言，这往往比追求一份看似完整的「未来答案」更有实际价值。
导入前要看见的限制
第一，代理人不是人口统计样本。 代理人是依照素材与模型生成的角色，不等同于从真实使用者中随机抽样。若要研究舆情或市场反应，仍要用真实调查、客服资料或其他外部证据交叉比对。
第二，初始材料会形成锚点。 图谱与角色设定建立在种子材料上；材料的选择、缺漏与描述方式都可能影响推演方向。开始前应列出资料来源、时间范围、尚未确认的主张，以及刻意纳入的不同立场。
第三，成本与资料边界需要先盘点。 这个流程依赖外部 LLM API 与 Zep Cloud，模型呼叫、代理人数、互动轮数和报告长度都可能影响耗用。自行架设前端或后端，不代表整条资料处理路径都是离线；敏感材料必须先确认是否允许送往外部服务，也要先估算 API 费用与资料保留政策。
第四，授权要配合部署方式确认。 GitHub 专案 metadata 标示 AGPL-3.0。若要修改程式、对外提供服务或纳入商业产品，应先阅读专案授权全文，确认适用义务；不要只看「开源」两个字就假设没有条件。
因此，我不会把 MiroFish 用来直接决定投资、医疗、公共政策或其他高风险选择，也不会把模拟报告包装成民意预测。比较合适的做法，是将它当作一个假设生成器：先让它提出可能情境，再由人回到资料、专家与现场验证，最后才决定哪些情境值得采取行动。
结语：把它当成模拟室，而不是水晶球
MiroFish 的亮点，是把知识图谱、代理人设定、社群互动与报告探索串成一条可操作的流程。对需要快速展开「如果……会怎样？」讨论的团队来说，这比单轮聊天更有结构，也能留下可追问的模拟脉络。
然而，模拟的细节再丰富，也不会自动变成真实世界的证据。若把它放在「提出假设、比较情境、找出下一步要查什么」的位置，它值得小规模试用；若期待它直接告诉我们未来会发生什么，就超出了目前公开证据能支持的范围。把 MiroFish 当成模拟室，而不是水晶球，才是比较稳健的使用方式。
参考资料