第一次看到 MiroFish 这个名字我以为是某个水族论坛的爬虫脚本点进去才发现是一套多智能体Multi-Agent编排框架——它把一群各自为战的模型实例按鱼群的逻辑组织起来干活。我真正被它吸引是因为一个跑了三个月的单体 Agent 任务彻底崩了上下文塞到 170K、单轮耗时四十分钟、中间任何一步工具调用失败就得从零重来而那一步失败的概率是百分之十七。MiroFish 给出的答案不是把上下文再扩一扩而是换一种组织结构——没有头鱼每条鱼只看周围几条鱼靠分离、对齐、聚合三条局部规则让整体行为涌现出来。这篇内容适合三类人看已经被长上下文和串行延迟折磨过的 Agent 开发者、想在业务流程里落地多智能体但不知道从哪下手的工程同学以及只想搞清楚鱼群式编排到底是不是又一个概念包装的观望者。我会把它拆到能直接抄作业的程度包括参数怎么算、坑在哪、什么时候千万别用。1. MiroFish 要解决的到底是什么问题1.1 单体 Agent 撞墙的三个信号判断一个任务该不该交给鱼群先看单体 Agent 有没有出现下面三个信号。第一个信号是上下文窗口被过程数据吃掉。我在做一份行业调研时Agent 需要读六十多份材料每份材料的中间摘要、检索片段、工具返回结果全部堆在同一个上下文里最后真正用于推理的有效信息占比不到百分之八。这就像你用一张书桌办公桌上百分之九十的面积堆的是草稿纸你连键盘都快放不下了。上下文越长模型对中段信息的注意力衰减越明显这不是换个模型能解决的是结构问题。第二个信号是串行延迟随子任务数量线性增长。单体 Agent 的处理方式本质是排队先查资料、再核对、再写结论、再自检每一步都要等上一步的输出。我实测过一个包含十二个子任务的流程单轮平均耗时从 22 秒涨到 186 秒其中百分之七十的时间花在等待上而不是推理上。鱼群式编排的价值就在这里——同一层的鱼可以并行游延迟取决于最长的那条链而不是所有链相加。第三个信号是单点失败无法局部修复。单体 Agent 一旦在第 9 步跑偏第 1 到第 8 步的成果几乎全废因为它们的中间状态和错误判断已经混进上下文你没法只重跑第 9 步。这是最要命的一点成本不是线性浪费是指数级浪费。当一个任务的失败率超过百分之十重试成本就会迅速吃掉你所有的时间预算。1.2 鱼群隐喻不是修辞它对应三组工程约束很多人以为鱼群只是给项目起个好看的名字其实它精确对应了三个必须解决的工程问题。Boid 模型里有三条经典规则分离Separation要求个体不要和邻居挤在一起对齐Alignment要求个体朝向邻居的平均方向聚合Cohesion要求个体朝邻居的中心靠拢。翻译到多智能体系统里分离就是去重——别让五个 Agent 同时去查同一份资料对齐就是共识——让多个 Agent 的结论在证据层面收敛聚合就是归并——把分散的结论合成一份可交付的产物。还有两个经常被忽略的隐喻要素。一是信息素鱼群靠水体里残留的化学信号传递这里刚有人来过对应到系统里就是共享黑板Blackboard加租约机制任何 Agent 开始一个子任务前先往黑板上写一条带 TTL 的占位记录其他鱼看到就走开。二是边界鱼群不会游出鱼缸对应到系统里就是步数上限、Token 预算上限和工具白名单这三条边界如果不在配置里写死鱼群一定会跑飞。理解了这层映射你就明白为什么 MiroFish 强调没有中心调度器。中心调度器Supervisor 模式看起来更好控制但它有个致命弱点调度器本身成了单点它的上下文会随着任务规模膨胀最终变成另一个单体 Agent。鱼群式的做法是让每个 Agent 自己根据黑板的局部状态决定下一步牺牲一点全局最优换取可扩展性和容错性。1.3 几种编排路线的取舍我把市面上常见的四种编排路线摆在一起做对比这张表我建议你在动手前先看一遍因为它决定了后面所有的配置思路。方案典型延迟Token 成本容错性可解释性适合的任务单体 Agent 长上下文高随步数线性增长高上下文重复计费差单点失败全废中日志集中但噪声大子任务少于 5 个、强依赖前文的任务固定 Pipeline低可预测中中单节点可重试高流程固定步骤稳定、几乎不变形的批处理Supervisor 中心调度中中偏高调度器上下文膨胀中调度器是单点高决策链路清晰子任务有明确层级、需要强约束的场景鱼群式去中心化低取决于最长链中去重后反而更省高局部失败可隔离中需要额外做 trace 聚合子任务多、可并行、结论需要交叉验证我自己的经验规律是这样的如果你能把任务画成一张流程图用 Pipeline如果任务需要动态决策但规模不大用 Supervisor只有当子任务数量超过八个、且子任务之间可以互相验证的时候鱼群式才会体现出明显优势。硬套鱼群去做一个三步流程你会发现自己写了一堆协调代码最后收益是负的。还有一点值得提醒鱼群式编排的调试难度比 Supervisor 高一个量级。因为不存在谁负责这个概念出问题时你得从多条 trace 里反推是谁污染了共享黑板。这也是我在第 4 节专门讲可观测性的原因——没有可观测性鱼群就是一锅粥。2. 核心机制拆解把 Boid 三规则翻译成代码2.1 分离规则Agent 之间怎么不撞车分离规则要解决的是重复劳动问题。假设任务里有三个 Agent 同时发现需要查一下市场规模数据如果不加约束它们会发出三次几乎相同的检索请求花三倍的钱拿回三份一样的结果然后在聚合阶段互相冲突。这个问题在单体 Agent 里根本不存在但在并行系统里是头号杀手。MiroFish 的做法是给每个子任务算一个任务指纹落到黑板前先做一次相似度比对。指纹的生成方式我一般用两层先做关键词归一化去掉停用词、统一同义表述再对归一化后的文本做向量化余弦相似度超过 0.92 判定为重复0.85 到 0.92 之间判定为部分重叠允许执行但要求共享已检索到的证据。这个阈值不是拍脑袋定的0.92 是我在两百多个任务样本上试出来的——再高会漏掉真正的重复再低会把本来应该独立验证的任务误判成重复损失了交叉验证的价值。租约机制是分离规则的第二道保险。黑板上的每一条任务记录都带一个 TTL我通常设 90 秒。Agent 认领任务后必须在 90 秒内续约否则记录自动释放别的鱼可以接手。为什么要设 TTL因为并行系统最怕的不是重复是死鱼占位——某个 Agent 调用外部接口卡住了任务被它锁死其他鱼在外面干等。90 秒这个值来自我的接口超时分布P99 是 42 秒设两倍余量刚好。如果你的外部接口慢把 TTL 提到 P99 的两倍以上但别超过 300 秒超过就意味着整个鱼群在等一条鱼失去了并行的意义。注意任务指纹的相似度阈值一定要结合你自己的语料校准。直接抄 0.92 在中文短文本上会偏严因为中文短句的向量分布更集中建议在你的业务语料上跑一遍分布直方图再定阈值。2.2 对齐规则多个 Agent 怎么收敛到同一个答案对齐规则是整个框架里最容易做错的部分。很多实现的做法是让多个 Agent 输出答案然后取多数这在事实性任务上会翻车——五个 Agent 里有三个基于同一份错误材料得出了同样的错误结论多数投票会把这个错误固化下来。MiroFish 的思路不是对答案投票而是对证据投票。具体来说共享黑板上只允许写两类内容结论和证据引用。结论是一条带置信度的断言证据引用指向原始材料的定位文档 ID 加段落区间。一个结论的权重不是 1而是它关联的证据数量乘以该证据来源的可信度系数。可信度系数需要你自己配置一手数据设 1.0二手转述设 0.6模型自身推断设 0.3。这样当分歧出现时你可以回溯到分歧来自证据冲突而不是模型随机性这就把问题从玄学变成了可分析的问题。冲突解决走裁判机制但裁判不是每次都触发。我设的触发条件是同一话题下存在两个以上结论且加权得分的差距小于百分之十五。差距小说明证据本身打架这时候叫一个低温度0.1 到 0.2的裁判 Agent 出来把两边的证据链摆在一起做判断。差距大就别浪费钱了直接采用高分结论。这个阈值我调过好几轮0.15 是在裁判触发频率和错误结论漏网率之间的平衡点触发频率大概在百分之十二左右成本可接受。迭代轮次必须设上限。我默认设 6 轮超过就强制收敛把所有现有结论按权重排序输出并在产物里显式标注未完全收敛。这一点很重要——强行收敛会导致错误但无限迭代会导致成本失控和结果永远出不来。在推理型任务上我一般把轮次压到 4 轮因为推理任务的证据补充边际收益下降得很快。2.3 聚合规则结果怎么合并聚合不是简单拼接。我踩过的第一个坑就是让聚合 Agent 把各条鱼的输出总结一下结果它把互相矛盾的结论揉成了一段模棱两可的话读起来像正确的废话。正确的做法分三步先做断言的归一化把表述不同但含义相同的结论合并这一步可以复用 2.1 的指纹算法再做证据链合并同一个断言关联的证据去重后按可信度排序最后按主题聚类输出。有一点我强烈建议保留——冲突不要抹平。很多团队为了让最终报告好看让聚合环节把矛盾消解掉这在业务上是灾难。我现在的产物里会专门保留一个conflicts字段记录未解决的争议点、双方证据、以及裁判的判断和理由。用户看到这个字段反而更信任结果因为它说明系统没有在糊弄人。输出的结构化也很关键。我要求聚合结果必须符合一个固定的 JSON Schema结论数组、每条结论带置信度、证据引用、来源 Agent ID、是否经过裁判。这样下游系统可以直接消费也方便你把历史产物拿来做回归测试。用自由文本做聚合输出的项目几乎没法做效果评估因为每次格式都不一样。2.4 参数怎么算鱼群规模、轮次与温度参数不是越多越好MiroFish 里真正需要调的只有五六个我把常用的值和调整信号整理成一张表你可以直接当起点。参数含义我的常用值什么时候该调swarm_size并发鱼的数量4 到 9公式见下子任务数增加或延迟要求收紧时max_rounds最大迭代轮次检索类 6推理类 4收敛曲线在第几轮变平就设几轮加一separation_threshold相似度去重阈值0.92需按语料校准重复执行率高就降交叉验证不足就升lease_ttl任务租约秒数外部接口 P99 的两倍上限 300出现长时间占位就调大temperature探索 0.7 到 0.9裁判 0.1 到 0.2按角色分档探索鱼意见高度雷同就升探索温度鱼群规模我用的经验公式是swarm_size ceil(可并行子任务数 / 3)然后夹在 4 到 9 之间。为什么除以 3因为并行系统里总有约三分之一的鱼处于等待依赖或被租约挡住的状态实际同时在干活的只有三分之二左右。为什么上限是 9超过 9 之后活跃黑板的读写冲突和协调开销增长很快而收益还在下降实测超过 9 条鱼的中位任务完成时间反而上升。这个拐点跟你的黑板实现方式有关用 Redis 做黑板的话拐点大概在 12 附近用单机内存做黑板大概在 7 附近。温度的分配也值得说一句。让所有鱼都用同一个温度是最常见的错误如果探索鱼温度太低它们会给出高度雷同的结论等于没有交叉验证如果裁判温度太高它会开始发挥创意把证据链抛在脑后。我的配置是探索鱼 0.7 到 0.9、校验鱼 0.3 到 0.4、裁判 0.1 到 0.2分层明确。3. 从零跑通第一个 MiroFish 任务3.1 环境准备与依赖先说环境。MiroFish 本身是 Python 生态的项目我用的版本是 Python 3.113.9 也能跑但异步相关的部分会有兼容问题。虚拟环境一定要建因为它的依赖里对 httpx 和 pydantic 的版本比较敏感。python3.11 -m venv .venv source .venv/bin/activate python -m pip install -U pip pip install mirofish模型接入这块我有两条路线。第一条是本地推理服务我一般用 vLLM 起一个 OpenAI 兼容的端点好处是成本可控、数据不出内网适合跑批处理缺点是要有卡而且并发高的时候显存会紧张。第二条是云端 API适合做原型验证。两条路线在配置上只差一个 base_url 和 key。export MIROFISH_MODEL_BASE_URLhttp://127.0.0.1:8000/v1 export MIROFISH_MODEL_NAMEqwen2.5-14b-instruct export MIROFISH_API_KEYlocal export MIROFISH_BLACKBOARDredis://127.0.0.1:6379/3 export MIROFISH_TRACE_DIR./runs黑板建议用 Redis别用单机内存。原因很实在鱼群式编排一旦跑起来多个 Agent 会并发读写用内存字典的话你得自己处理锁而且进程一挂黑板就没了所有中间态都丢。Redis 的 SETNX 加 EXPIRE 天然就是租约语义省一大堆事。数据库编号我习惯单独分一个上面用的 /3避免和业务缓存放一起被误清。注意模型名称一定要和端点实际加载的模型一致很多兼容层不会校验这个字段但部分实现会用它来路由。名字不对可能不会报错只是结果质量莫名下降这种问题排查起来非常费时间。3.2 目录结构与配置文件逐行解读我习惯的目录结构是这样的你也可以按团队规范调整但配置、角色、产物、追踪这四块一定要分开。mirofish-demo/ ├─ config/ │ └─ swarm.yaml ├─ roles/ │ ├─ explorer.yaml │ ├─ verifier.yaml │ └─ judge.yaml ├─ runs/ │ └─ 20250612-1043-market-scan/ │ ├─ trace.jsonl │ ├─ blackboard.jsonl │ └─ result.json └─ run.py主配置我一般写成这样逐行说一下意图swarm: size: 6 # 实际并行鱼数按公式算出来再夹到 4~9 max_rounds: 6 # 收敛轮次上限超过强制收敛并标记 separation_threshold: 0.92 lease_ttl: 90 budget_tokens: 1200000 # 整群总预算不是单鱼 blackboard: backend: redis url: ${MIROFISH_BLACKBOARD} namespace: demo-market-scan # 不同任务一定用不同命名空间 tools: whitelist: [web_search, fetch_page, local_kb, sql_query] per_call_timeout: 45 max_calls_per_agent: 25这里有两个点值得展开。budget_tokens是整群预算不是单鱼预算——这一点第一次用的时候容易搞错写成单鱼预算的话六条鱼会把成本顶到六倍。namespace必须按任务区分否则两条不同的任务会互相认领对方的任务记录出现我在写市场报告结果混进来一段代码审计结论这种诡异现象。我第一次遇到这个问题时盯着黑板看了半小时才反应过来。工具白名单是安全底线。max_calls_per_agent我设 25这个数字来自观察正常一条鱼完成任务平均调用 8 到 14 次工具设 25 大概给了一倍余量如果某条鱼打到 25 还在调用基本可以确定它陷入了循环应该被熔断而不是继续喂它调用额度。3.3 角色池与工具白名单怎么配角色池的设计决定鱼群的分工形态。我的做法是用三档角色打底按任务复杂度再细分。角色职责可用工具温度Token 配额explorer广撒网找线索允许发散web_search, fetch_page0.8整群的 45%verifier对已有结论做反向验证local_kb, sql_query0.35整群的 30%judge处理冲突、做最终判断无外部工具只读黑板0.15整群的 15%writer按 Schema 生成产物无外部工具0.2整群的 10%配额分配的道理在于探索阶段消耗的 Token 最多但边际价值最高验证阶段次之裁判和写作阶段的输入已经收敛消耗自然小。裁判角色我特意不给它任何外部工具因为它一旦能自己查资料就会开始自己找证据支持自己失去中立性这是我在一个项目里切实踩过的坑。角色文件写起来很简单role: explorer temperature: 0.8 tools: [web_search, fetch_page] budget_ratio: 0.45 system_prompt: | 你只负责发现可能相关的线索不负责下结论。 每条线索必须附带可定位的来源无法定位的线索直接丢弃。 如果你发现黑板上有相似任务已被认领放弃你的任务并转向其他方向。最后一行是分离规则在提示词层面的落地。不要小看这一句它把去重从系统强制变成了Agent 自觉能省下不少黑板写入冲突。3.4 运行、观察与产物落盘启动命令很简单python run.py \ --task 整理一份某细分市场的规模、增速与主要参与者 \ --config config/swarm.yaml \ --run-name 20250612-1043-market-scan跑起来之后别盯着终端看结果先看 trace。trace.jsonl 里每一行是一条事件我一般用这两条命令快速判断鱼群健康度# 看每个 Agent 的工具调用次数分布识别循环 jq -r select(.eventtool_call) | .agent_id runs/*/trace.jsonl | sort | uniq -c | sort -rn # 看轮次收敛曲线判断 max_rounds 设得对不对 jq -r select(.eventround_end) | \(.round) \(.new_claims) runs/*/trace.jsonl第二条命令的输出特别有用。如果第 4 轮开始new_claims就掉到 0 到 1说明 6 轮是浪费如果第 6 轮还有 5 个新结论说明你设低了任务其实没收敛就被砍断了。我调整 max_rounds 的唯一依据就是这条曲线。产物 result.json 的结构大概是这样{ conclusions: [ {claim: ..., confidence: 0.78, evidence: [doc#12:p3-5], agents: [e1, v2]} ], conflicts: [ {topic: 增速口径, sides: [{claim: ..., weight: 2.4}, {claim: ..., weight: 1.8}], judge: 差额未达阈值保留分歧} ], stats: {rounds: 5, tokens: 486000, tool_calls: 61, rejected_duplicates: 23} }rejected_duplicates这个字段我每次都看。如果它是 0说明分离规则没生效大概率是阈值设太高或者命名空间冲突如果它超过总调用数的一半说明阈值设太低鱼群在做无用功。健康区间大概在百分之二十到百分之四十之间。4. 生产环境的稳定性工程4.1 可观测性一次运行一条完整 trace鱼群式系统没有中心调度器意味着谁负责这个问题没有答案所以可观测性不是加分项是必需品。我的最低要求是每条鱼、每次工具调用、每次黑板读写都要落一条带时间戳和 agent_id 的事件。落盘格式用 JSONL别用结构化日志框架的默认格式因为你要用 jq 做临时聚合JSONL 最方便。事件里必须有的字段我列一下run_id、agent_id、round、event、duration_ms、token_in、token_out、parent_event。parent_event是链路串联的关键——有了它你才能还原哪条鱼触发了哪个子任务从而在出问题时定位到具体的分支而不是对着一堆平铺日志发呆。我还会额外记录一个黑板竞争度指标单位时间内被租约拒绝的次数。这个指标突然飙升通常意味着任务分解粒度太粗多条鱼挤在同一个子任务上。这时候该做的是拆细任务而不是加大租约时间——加大租约只会让等待看起来少一点实际吞吐没变。4.2 成本控制Token 预算怎么分Token 成本失控在多智能体系统里非常常见因为并行意味着同时在烧钱。我是这么算的先估单体方案的成本上限然后把它乘以 1.5 作为鱼群的总预算上限。如果鱼群方案超过单体方案的 1.5 倍还没带来质量提升就不值得用。具体到分配我用的是三段式总预算 探索预算 验证预算 收敛预算 探索预算 总预算 × 0.45 验证预算 总预算 × 0.30 收敛预算 总预算 × 0.25 # 裁判 0.15 写作 0.10每段预算耗尽时要做不同的事。探索预算耗尽直接进入验证阶段哪怕线索还不全验证预算耗尽跳过剩余的验证任务但必须把未验证标记在对应结论上收敛预算耗尽强制输出并标记未完全收敛。这三条降级路径必须在代码里显式实现而不是等到超预算了抛异常——抛异常意味着前面所有的工作都白做了。一个反直觉的实测结论鱼群方案在中等规模任务上往往比单体更省 Token。原因是分离规则砍掉了大量重复检索验证阶段又能提前掐掉错误分支避免在错误方向上继续投入。我的数据是八到十五个子任务的任务鱼群比单体省百分之十五到百分之二十五。但子任务少于五个时协调开销会超过节省成本反而高出百分之三十。4.3 熔断、降级与死锁打破熔断的触发条件我设了三条命中任意一条就停掉那条鱼单鱼工具调用超过 25 次、单鱼连续两轮没有产生新结论、单鱼 Token 消耗超过其配额的 1.3 倍。第三条是防话痨鱼有些模型在开放式任务上会不断重复相似表述消耗大量 Token 却没有任何新信息。死锁是并行系统特有的一类问题。典型场景是A 鱼在等 B 鱼发布某个结论B 鱼在等 A 鱼先完成验证两条鱼互相持有租约谁都不动。打破死锁最有效的手段是给每条鱼加一个最大等待时长超过就放弃依赖、基于现有信息继续推进并把这次妥协记进 trace。我设的最大等待时长是租约 TTL 的两倍也就是 180 秒。注意死锁打破后产生的结论质量会下降所以不要把它当成正常路径。如果你的系统里频繁触发死锁打破说明任务依赖图设计有问题应该去改任务分解逻辑而不是调大等待时长。另外提醒一点熔断和降级一定要有可复现的输入快照。我见过太多团队在线上出问题后想复现结果因为没有保存当时的黑板状态和输入只能在本地重新跑一遍而重跑的结果因为模型随机性又不一样。我的做法是每轮结束时把黑板快照落一份出问题时直接加载快照重放这是排查多智能体问题最省时间的手段。5. 踩坑实录与问题速查表5.1 三个最典型的故障现场第一个故障现场是同质化鱼群。现象是六条鱼跑完结论高度雷同交叉验证完全没起作用。根因是我一开始给所有鱼配了同一个角色和同一个提示词它们连检索的关键词都差不多。解决方案是给不同鱼注入不同的探索视角比如一条专门找官方数据、一条专门找第三方报告、一条专门找反方观点。视角差异比温度差异更能带来多样性。第二个故障现场是黑板污染。现象是最终报告里混进了完全不相关的内容。根因就是前面提到的命名空间没隔离上一个任务的残留记录被这个任务认领了。这个坑的特点是不会报错只会让结果变得莫名其妙排查难度很高。解决方案是命名空间里带上 run_id并且在启动时检查该命名空间是否为空。第三个故障现场是裁判越权。现象是裁判 Agent 开始输出自己的新结论而不是在已有结论里做选择。根因是我给了它工具权限和过高的温度。修完之后我定了一条规则裁判的提示词里必须明确写你只能引用黑板上已有的证据不得引入新信息并且它的工具列表必须为空。这条规则看起来简单但它把裁判从第七个探索者变回了真正的仲裁者。5.2 常见问题速查表现象最可能的原因定位手段处理方式结论高度雷同角色视角单一、温度过低看各 Agent 的检索词相似度注入不同探索视角提升探索温度重复执行率高separation_threshold 过高看 rejected_duplicates 占比降阈值按语料重校准长时间无输出租约未释放、死锁看黑板租约分布与等待时长检查 TTL加入死锁打破结果混入无关内容命名空间未隔离看黑板记录来源 run_id命名空间带 run_id 并在启动时校验成本超预期预算按单鱼计算看 stats.tokens 与预算比改为整群预算加降级路径结论反复摇摆max_rounds 过高看每轮 new_claims 曲线在曲线变平的那一轮加一某条鱼一直不停循环调用、话痨看单鱼工具调用次数命中熔断条件直接停掉5.3 我总结的几条硬性经验第一条先用单体跑通再上鱼群。很多人一上来就搭鱼群结果分不清是任务本身难还是编排出了问题。我的做法是先写一个单体版本拿到基线质量和基线成本再去对比鱼群版本有没有改进。没有基线的多智能体优化就是瞎调。第二条任务分解粒度宁细勿粗。我的经验是每个子任务控制在一次工具调用能拿到大致结果的粒度上。子任务太粗会导致多条鱼挤在一起抢租约并发优势消失太细会导致协调开销占比过高。第三条收敛判据一定要显式。不要用跑到没新东西为止这种模糊判据那等于把成本交给模型决定。我的判据是连续两轮新增有效结论少于总数的百分之五命中就提前收敛通常能省掉一到两轮。第四条冲突要保留不要抹平。这条前面说过但值得再强调一次。保留冲突的输出看起来不那么完美但它诚实而且给下游的人留下了判断空间。6. 效果评估怎么证明鱼群真的更好6.1 评测集与指标设计做多智能体最容易被问的问题是你凭什么说它更好。我的评测集是这么造的从历史任务里挑五十个其中二十个是常规任务、二十个是证据冲突任务材料之间互相矛盾、十个是长尾任务需要跨领域联想。这三种任务类型衡量的能力完全不同混在一起看平均分没有意义。指标我只看四个多了就没人看结论准确率人工抽检每份产物抽十条断言、证据可追溯率断言带可定位来源的比例、平均完成时间、单位有效结论的 Token 成本。其中证据可追溯率是最容易被忽略但最重要的一个——一个结论对了但没有来源在业务上就等于不可用因为它没法被复核。6.2 我用过的对比数据与解读在同一批任务上我的对比结果大致是这样单体方案在常规任务上的准确率是百分之七十一鱼群是百分之七十九差距不算大但在证据冲突任务上差距明显拉开单体百分之五十四鱼群百分之八十三。这个结果符合预期——鱼群的价值本来就在多来源交叉验证上单来源任务用它纯属浪费。时间维度上常规任务单体平均 186 秒鱼群 94 秒长尾任务因为要拆得比较细鱼群反而略慢118 秒对 132 秒优势只有百分之十一。成本维度常规任务的单位有效结论成本鱼群比单体低百分之十八长尾任务基本持平子任务少于五个的任务鱼群高出百分之三十以上。这些数字给我的结论很明确鱼群的甜点区是子任务多、来源冲突、结论需要复核的任务。脱离这个区间它的收益迅速衰减甚至为负。6.3 什么时候不该用鱼群有四种情况我坚决不用鱼群。第一任务步骤固定且不依赖中间结果比如格式转换、批量字段抽取用 Pipeline 又快又便宜。第二任务强依赖前文语义比如长文改写拆开之后上下文就断了鱼群反而帮倒忙。第三对确定性要求极高的场景比如财务对账多智能体的随机性带来的风险远超收益。第四任务量很小、跑一次就完的场景搭编排框架的投入根本回不来。还有一个容易被忽略的点鱼群式编排对团队能力有要求。如果团队里没人能读懂 trace、没人能做黑板的状态分析出问题时只能靠重跑碰运气那这套东西在生产环境就是个定时炸弹。评估一个方案时不只看它的峰值效果也要看你有没有能力在它出问题时把它救回来。最后再分享一个小技巧如果你想低成本试水鱼群不要一开始就做通用框架挑一个你们业务里结论需要多个来源佐证的具体任务只配三条鱼一条探索、一条验证、一条裁判把 trace 和产物结构搭好。跑通三五个任务之后你会对自己业务的甜点区有非常清晰的直觉这时候再决定要不要扩到六条、九条。我在两个项目里都是这么起步的比一上来就照搬全量配置省了至少两周的摸索时间。