MiroFish群体模拟通信机制拆解：2个JSON目录背后的3个设计决策

MiroFish群体模拟通信机制拆解2个JSON目录背后的3个设计决策【免费下载链接】MiroFishA Simple and Universal Swarm Intelligence Engine, Predicting Anything. 简洁通用的群体智能引擎预测万物项目地址: https://gitcode.com/GitHub_Trending/mi/MiroFishMiroFish是一个简洁通用的群体智能引擎支持数千到数万级智能体的社会模拟推演。模拟跑起来之后后端如何向里面某个智能体提问这套MiroFish文件IPC通信机制的答案是2个JSON目录本文拆解它的命令协议与状态机。场景模拟跑到一半向智能体提一个问题MiroFish里用到这套机制最直接的场景是模拟运行中的采访操作。打开前端运行页一次模拟会以独立子进程方式跑在Twitter/Reddit双平台上智能体们正在发帖、点赞、评论。这时你想问3号智能体你对当前局势怎么看。后端Flask进程和模拟进程是两个独立进程两者之间没有开任何网络端口、没有消息队列——后端只是往模拟目录下写了一个JSON文件模拟脚本每隔一轮轮询同一个目录发现新命令后执行采访再把结果写回另一个目录。用户点击采访到拿到回答全程就是写文件→等文件两件事。命令里到底放了什么字段模拟端凭什么按顺序处理这就是下面要拆的部分。机制拆解4个类、2个目录不依赖任何附加服务整个通信层集中在backend/app/services/simulation_ipc.py一个文件里数据格式、客户端、服务端都在其中。IPC客户端与服务端各负责什么把它想成餐馆的前台和后厨两边不喊话只对单。前台把点单条贴在传菜窗口A后厨做完把回执贴到传菜窗口B前台隔几秒扫一眼窗口B。SimulationIPCClient后端Flask侧点单方send_command()生成一个 uuid4 作为command_id把命令写成ipc_commands/{command_id}.json随后以默认0.5秒为间隔轮询ipc_responses/目录等到同名文件即返回IPCResponse同时删掉命令和响应两个文件。SimulationIPCServer / 脚本端 IPCHandler模拟进程侧接单方模拟脚本实际用的是 backend/scripts/run_reddit_simulation.py 里同目录约定的IPCHandlerpoll_command()每轮扫描ipc_commands/按文件修改时间排序取出最早的命令执行——先写入的先处理天然FIFO。两个目录ipc_commands/、ipc_responses/由双方构造函数自动创建模拟进程由 backend/app/services/simulation_runner.py 以子进程方式拉起并置于独立进程组两端只需要约定同一个模拟数据目录。命令JSON有哪些字段像点菜单一样格式固定少一个字段后厨都不接单。一条命令文件长这样# ipc_commands/ 目录下的命令文件由 SimulationIPCClient 自动生成 { command_id: 9f8a2c1e-4b7d-4c3e-9f1a-2d5e6b7c8a90, # uuid4同时就是响应文件名 command_type: batch_interview, # 仅3种interview / batch_interview / close_env args: {interviews: [{agent_id: 3, prompt: 你如何看待局势}]}, timestamp: 2026-08-30T01:02:11.482310 }三种命令类型对应三类意图interview采访单个智能体batch_interview一次问一批模拟端用一次env.step()并行执行全部采访动作close_env优雅关闭环境。响应文件只有4个字段command_id、status、result、error。命令文件和响应文件共用command_id做文件名配对靠查同名文件完成不需要任何路由映射表——这是整个协议里最省的设计。命令状态机怎么流转状态流转像一张维修工单待处理、处理中、已完成、已取消。CommandStatus定义了 pending / processing / completed / failed 四个状态但注意一个工程细节落盘的只有终态——completed 或 failed。pending 存在于客户端的等待循环里processing 存在于模拟脚本的执行瞬间都不写文件省掉了一半的写盘开销。超时预算按命令类型分档单条采访默认60秒批量120秒关闭环境30秒全局采访180秒客户端超时后会主动删除命令文件并抛TimeoutError不遗留垃圾。另外还有一个旁路信号模拟端在env_status.json里写alive/stoppedAPI 每次发命令前先check_env_alive()环境死了就直接报错而不是傻等超时。技术点睛为什么用文件而不用socket权衡是进程崩溃后命令仍留在磁盘上cat一下就能现场排障且零网络配置代价是响应延迟的下限就是两端的轮询间隔吞吐受磁盘IO约束。但向运行中的模拟问几个问题本来就是低频请求响应场景用简单换性能损失是匹配的选择。效果数据源码里都能查到的三个数字这套机制的指标不夸张但每个数字都能从代码里直接核对。常规路径响应延迟约0.5秒起步。客户端轮询间隔poll_interval0.5秒脚本端在主循环里逐轮拉命令端到端最快延迟≈两个轮询周期之和。原因轮询模型没有连接建立和心跳开销延迟确定性强最坏情况被超时上限封顶。批量超时是单条的2倍单条60秒、批量120秒、全局180秒。原因一次采访本质是一次LLM调用超时按模型最慢响应预留批量并不随智能体数量线性放大因为模拟端把整批动作压缩进一次env.step()并行执行10个智能体和100个智能体的墙钟时间差距很小。目录始终接近空目录。每条命令正常结束后命令文件和响应文件被双端删除都有 try/except 兜底磁盘上不会随时间累积文件。原因把目录为空当作隐式不变量既控制磁盘占用也让人一眼看出通信是否卡住。落地路径3个文件、1条脚本先读什么先跑什么想摸清全链路先读3个文件、跑1条命令就够。先读 backend/app/services/simulation_ipc.py数据类、客户端、服务端全在这一处是协议的唯一事实来源。再读 backend/app/services/simulation_runner.py 的子进程启动与check_env_alive()部分理解命令发送前的存活检查。最后读 backend/scripts/run_reddit_simulation.pyTwitter/parallel 版本结构相同里的IPCHandler看命令在模拟端如何被执行成ManualAction。跑起来先用 Web 流程准备一次模拟并触发采访接口或直接在命令行执行python backend/scripts/run_reddit_simulation.py --config 配置文件路径单平台运行观察ipc_commands/目录的文件进出。适合的场景同机两个进程需要低频请求响应每分钟数十次以内、需要崩溃可恢复、不想引入消息中间件。不适合的场景毫秒级高频流式通信、数千QPS的并发投递——轮询间隔会成为硬上限跨机器部署也不行文件系统是介质两端必须共享同一目录。技术点睛若确实要跨机器把两个目录换成共享存储或对象存储协议本身不用改代价是文件修改时间跨机排序不再可靠需要改用 timestamp 字段显式排序可靠性从操作系统转移到协议自己肩上。结尾用文件系统当通信介质看起来老派但它把通信层的复杂度从网络协议栈降维成目录文件名让工程的复杂度预算花在智能体行为本身而不是接线图上。一个值得延伸的问题这个项目里动作日志、运行状态、环境存活全是文件IPC只是其中之一——当系统所有状态都可以落盘排障面就缩小到一条ls这或许是比通信机制本身更值得借鉴的部分。【免费下载链接】MiroFishA Simple and Universal Swarm Intelligence Engine, Predicting Anything. 简洁通用的群体智能引擎预测万物项目地址: https://gitcode.com/GitHub_Trending/mi/MiroFish创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考