拆解 MiroFish 的多智能体 IPC 通信几百个 Agent 怎么不打架地传消息【免费下载链接】MiroFishA Simple and Universal Swarm Intelligence Engine, Predicting Anything. 简洁通用的群体智能引擎预测万物项目地址: https://gitcode.com/GitHub_Trending/mi/MiroFish当你想一次性采访200 个模拟 Agent问它们各自对某条新闻的看法时会立刻撞上现实问题Flask 后端和模拟脚本是两个独立进程没有一个现成的消息队列命令发出去、响应收不回来整个模拟流程就卡死在这里。MiroFish 这个简洁通用的群体智能引擎用一套基于文件系统的多智能体 IPC 通信机制解决了这个跨进程协调问题——不引入任何消息中间件只用两个目录和 JSON 文件。图MiroFish 首页上传报告后即可生成 Agent 群体并开始多智能体模拟推演拆开看两个进程怎么靠两个目录传话 把它想象成食堂打饭你点完餐把取餐牌带唯一编号的票放在前台窗口后厨轮着取牌、做菜做好后把餐按编号放回出餐口你反复瞄出餐口看到自己的编号就取走。全程没有对讲机没有网络只有两个窗口和一批带编号的票——断网、后厨短暂罢工都不影响票还在窗口上恢复后继续取。MiroFish 的 IPC 通信就是这套双窗口 编号票模型四个核心组件各司其职SimulationIPCClientFlask 端生成 UUID 作为command_id把命令序列化成 JSON 写入ipc_commands/目录然后按poll_interval默认0.5s轮询ipc_responses/目录等回票SimulationIPCServer模拟脚本端按文件修改时间排序轮询命令目录取到命令后执行把响应写回响应目录并删除原命令文件IPCCommand命令结构包含command_id、命令类型、参数字典、时间戳IPCResponse响应结构status取值pending / processing / completed / failed成功带result失败带error命令类型只有三种interview单个 Agent 采访、batch_interview批量采访、close_env关闭环境。客户端另外维护一个env_status.json心跳文件check_env_alive()靠它判断模拟环境是否存活——相当于食堂的营业中牌子。图MiroFish 多智能体模拟流程的 Step 2 环境搭建右侧面板展示 Agent 图谱与激活事件安装到跑通的最短路径第一步装环境。Python 要求3.11~3.12Node18克隆后一条命令装全所有依赖git clone https://gitcode.com/GitHub_Trending/mi/MiroFish cd MiroFish npm run setup:all配置LLM_API_KEY、LLM_BASE_URL、LLM_MODEL_NAME等环境变量后npm run dev同时拉起前后端前端http://localhost:3000后端 APIhttp://localhost:5001。第二步最小可运行示例。这一步只验证 IPC 链路本身创建客户端发一条单 Agent 采访命令并等待响应。单命令推荐超时60s轮询间隔默认0.5s不用动。from backend.app.services.simulation_ipc import SimulationIPCClient client SimulationIPCClient(simulation_dir./simulation) resp client.send_interview( agent_id1, prompt你怎么看行业的最新进展, timeout60.0 ) print(resp.status.value, resp.result if resp.status.value completed else resp.error)收到completed说明客户端、命令目录、模拟进程、响应目录整条链路都通了。第三步扩展批量采访。一次问多个 Agent 时别循环发单命令用批量命令一次打包超时调到120s复杂批量可到300s脚本端启动后命令才会被处理--max-rounds可截断模拟轮数官方提示 LLM 消耗较大先试 40 轮以内interviews [ {agent_id: 1, prompt: 问题1}, {agent_id: 2, prompt: 问题2}, ] resp client.send_batch_interview(interviews, timeout120.0) client.send_close_env(timeout30.0) # 结束后关闭环境python backend/scripts/run_twitter_simulation.py --config simulation_config.json --max-rounds 40图模拟跑通后的图谱关系可视化右侧面板可点开任意节点查看 Agent 的 Summary 与标签选型与踩坑哪里适合用、哪里容易翻车什么场景适合 / 不适合适合同机跨进程。Flask 后端与模拟脚本共享同一文件系统同机或同容器无需开端口、配网络、绕防火墙部署成本几乎为零适合低频、长耗时命令。一次 LLM 采访动辄秒级到分钟级文件 I/O 的开销在这种时间尺度上可以忽略适合需要崩溃恢复。命令是持久化的磁盘文件模拟进程重启后按 mtime 轮询即可接管残留命令天然幂等不适合毫秒级高频消息。写文件 0.5s轮询的延迟下限摆在那里高频场景该用内存队列不适合跨机器分布式。文件 IPC 天然是单机机制跨机需要真正的消息队列或 RPC高频坑 一句话修复坑 1命令发出后一直等到 TimeoutError→ 根因模拟进程没启动或env_status.json不是alive命令文件在目录里没人取 → 修复发命令前先调client.check_env_alive()确认环境存活再启动对应模拟脚本坑 2ipc_commands/里的命令文件长期不消失→ 根因脚本端解析命令后崩溃、没来得及写响应命令文件成了孤儿 → 修复重启模拟脚本让poll_commands重新接管对反复失败的命令文件先删后重发避免脏文件干扰排序坑 3批量采访频繁超时→ 根因批量命令内部是逐个 Agent 串行调 LLM子命令越多总耗时越长 → 修复单批控制在几十个以内做拆批超时按子命令数量线性放大到120~300s调优思路批量合并N 条单采访命令合成 1 条batch_interview文件 I/O 和轮询次数直接减 N-1 倍动态超时close_env给30s就够批量采访按子命令数放大别一刀切轮询间隔权衡延迟敏感时把poll_interval从0.5s降到0.1~0.2s代价是两端 CPU 空转上升失败隔离收到failed先看error再决定重试盲目重发只会让命令目录堆积继续深挖源码在哪、示例在哪核心源码simulation_ipc.py——客户端、服务端、命令/响应结构全在这一个文件里不到 400 行一次读完模拟脚本示例scripts/——run_twitter_simulation.py、run_reddit_simulation.py、run_parallel_simulation.py都在这套 IPC 上实现了各自的命令处理端照抄结构即可接入新平台进程编排simulation_runner.py——负责拉起模拟脚本并接管 IPC 的完整流程行为测试tests/——含模拟启动失败等边界场景的断言改造 IPC 时先跑一遍想接自己的命令类型扩展点只有一个在CommandType枚举加一项再在服务端的命令分发里加一个分支——命令结构、轮询、超时、清理这套基础设施不用动这正是文件 IPC 留给你的全部自由度。【免费下载链接】MiroFishA Simple and Universal Swarm Intelligence Engine, Predicting Anything. 简洁通用的群体智能引擎预测万物项目地址: https://gitcode.com/GitHub_Trending/mi/MiroFish创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考