第一次把 MiroFish 完整跑通的那晚我盯着终端里滚动的日志看了快半小时十二条鱼围着同一个问题各自游了七分钟最后领航鱼吐出来的那份调研报告覆盖密度和交叉验证的扎实程度比我一个人查一下午的结果还硬。那一刻我才确定把深度调研这种活儿拆成多智能体协作的鱼群模式方向是对的。MiroFish 是我自己攒的一套多智能体协作框架专门处理那种一个问题要翻十几处资料、还得自己判断哪条信息可信的深度调研任务。Miro 是我上一版单体 Agent 的代号最早只是帮我整理白板思路用的Fish 是这一版的形态——鱼群。名字的来历不重要重要的是三件事它到底解决了什么问题、怎么从零搭起来、哪些地方最容易翻车。这篇文章我把这三件事一次讲透代码、参数、踩坑记录都在里面。不管你是刚接触多智能体、还在犹豫要不要上手还是已经写过几个 Agent 但被成本和幻觉折磨过下面的内容应该都能直接抄去用。我不会给你画一张漂亮的架构图然后说就长这样而是把每个设计决策背后的为什么掰开讲因为鱼群这套东西抄结构容易抄判断难。1. 鱼群隐喻落到工程上MiroFish 要解决的三个具体麻烦1.1 单鱼模式为什么会崩上下文雪崩与单点误判我上一版单体 Agent 做深度调研最常见的失败姿势是这样的接收一个问题开始一轮一轮地检索、读取、总结到第十八轮的时候上下文已经堆到二十万 token模型开始忘事——把前面已经证伪的说法又当成结论写进报告或者把某个二手转述当成一手事实。这不是模型不行是架构决定的。单条线程必须自己记住所有中间状态而中间状态里 80% 是垃圾。更麻烦的是单点误判。单体 Agent 一旦在某一步选错了检索方向后面所有推理都建立在这个错误前提上而且它自己没有能力发现我可能走歪了。就像一个人闭着眼睛走迷宫走得越久越自信实际离出口越远。我在真实任务上统计过单体模式下最终报告里至少有一条关键事实错误的概率超过四成这个数字在需要交付的场合是没法接受的。还有一层隐形成本。单体 Agent 因为上下文太长每一轮都要把前面所有内容重新塞给模型token 消耗是随轮次平方级增长的。跑到第十轮之后单轮成本已经是最初的三倍而信息增量几乎为零。这三个问题叠在一起就是我要把架构推倒重来的直接原因。1.2 把 Boids 的三条规则翻译成调度策略鱼群行为学里有个经典模型叫 Boids三条规则分离、对齐、聚合。我最初只是觉得这个隐喻好听真正动手之后才发现这三条规则恰好能一对一映射成多智能体调度里最难的三件事而且映射之后整个设计一下就顺了。分离对应到工程里就是去重与差异化探测。多条鱼同时开工最大的浪费是它们查同一个关键词、读同一篇文档。所以我在调度器里加了一个共享的探测点注册表任何一条鱼在发起检索之前先登记关键词指纹指纹重复的直接被打回让它换个角度。这条规则把我实测的无效重复检索从 37% 压到了 6% 左右。对齐对应的是共享证据池与统一引用规范。鱼与鱼之间不直接聊天——聊天会引入自然语言的模糊性也容易互相污染。它们只往一个共享的证据池里写结构化卡片格式固定字段固定。领航鱼读的也是这个池子而不是读其他鱼的对话记录。这样做的代价是灵活性下降好处是结果可追溯、可校验、可复现。聚合对应的是收敛判断。鱼群什么时候停不是所有鱼都跑完才停而是领航鱼根据证据池的边际增量决定。新增证据里新事实的比例连续两轮低于 15%就判定收敛立刻收网。这个阈值不是拍脑袋来的后面第 5 节有我做的一组对比实验。1.3 什么时候不该上鱼群一张判断清单我得先把话说清楚鱼群不是银弹用它之前先看这张表。我在项目里给自己定了一条规矩——任何任务先过这张清单不满足的坚决不上鱼群因为硬上只会让成本和复杂度同时翻倍。任务特征适合鱼群建议用单体信息源数量需要跨 8 个以上信息源单一文档或单一页面事实冲突程度来源之间说法不一致需要裁决事实清晰、无争议时效要求分钟级到小时级可接受秒级响应成本敏感度单次任务预算可到几元到几十元预算按厘计算交付要求结论必须带可追溯引用只要一段概括问题结构可拆成 5 个以上独立子问题线性追问即可典型适合的场景技术选型调研、某个行业近况梳理、竞品功能拆解、长文档集的交叉比对。典型不适合的场景帮我改一句文案、把这段代码翻译成另一种语言、查一个明确的事实点。我见过有人拿鱼群去做单页摘要六条鱼跑出来的结果和一条鱼几乎一样成本却是六倍。这不是框架的问题是选型的问题。2. 六个鱼种的分工与交接协议2.1 侦察鱼把一句模糊的问题拆成可执行探测点用户丢过来的问题通常是模糊的比如我想了解这个方向值不值得投入。侦察鱼的任务就是把它翻译成 5 到 12 个可执行的探测点。每个探测点必须包含四个字段缺一个都不算合格{ probe_id: p_003, goal: 确认该方向近两年的工程落地案例数量级, queries: [方向名 生产环境, 方向名 案例复盘, 方向名 失败教训], evidence_type: 案例或复盘文需含具体数字, abort_condition: 连续两次检索无可信来源即放弃 }这里有个我踩过的坑一开始我让侦察鱼自由发挥结果它给出的探测点全是了解一下背景看看有什么进展这种没法执行的话。后来我在提示词里加了两条硬约束——每个探测点必须能对应至少一条具体检索式且必须写明放弃条件。加上这两条之后探测点的可用率从五成提到了九成以上。侦察鱼的温度我会调到 0.7 左右。这个角色需要发散需要想到别人想不到的角度温度高一点反而更好。但发散不等于乱来字段约束就是它的笼子。2.2 深潜鱼一个探测点挖到底产出证据卡片深潜鱼是干活的主力。它领到一个探测点做多轮检索和阅读最后产出的不是一段散文而是一组证据卡片。卡片结构长这样字段含义约束claim一句话结论不超过 40 字必须是陈述句source来源标识需可回链snippet支撑该结论的原文片段20 到 200 字必须是原文confidence置信度0 到 1两位小数freshness信息时间相对当前时间的跨度snippet 这个字段是整个体系的地基。我强制要求它必须是原文摘录而不是模型改写理由很简单模型改写的片段没法校验而原文摘录可以用字符串匹配去验证。这一条约束让我的引用回链校验从靠感觉变成了可自动化后面第 4 节会详细讲。深潜鱼的温度我压到 0.2。这个角色要的是忠实和稳定不是创意。同一张卡片跑两次结论应该基本一致否则下游的裁决就没法做。2.3 清道夫去重、降噪、给来源打分十二条鱼跑完证据池里通常会有大量重复。同一个事实可能被四条鱼从四个不同来源带回来其中两个是原始出处两个是互相抄的二手转述。清道夫的活就是把这些理清楚。去重我做的是两段式先用字符级指纹做粗筛把明显同源的合并再用语义相似度做细筛相似度超过 0.88 的判定为同一事实。粗筛快但会漏细筛准但慢两段配合的性价比最高。这里要注意一个反直觉的点去重不是越狠越好。有些看似重复的证据其实是相互印证的独立来源把它们合并掉反而丢掉了被多方证实这个重要信号。所以我的做法是合并内容、保留来源列表而不是直接删掉。来源可信度打分我用四个维度各占不同权重来源类型一手数据、官方文档、行业媒体、个人博客占 40%时间新鲜度一年内满分逐年递减占 25%是否包含可核对的原始数据占 20%是否被其他独立来源交叉印证占 15%这套权重是我自己调出来的不一定通用但它有个好处每一项都能解释出问题的时候知道该改哪一项。2.4 领航鱼收敛判断与最终成文领航鱼是唯一有全局视野的角色它读的是整理后的证据池不是原始网页。它的职责有三个判断该不该继续跑、裁决相互冲突的结论、把证据池写成最终交付物。裁决冲突的时候我不让领航鱼自己感觉哪个对而是给它一套明确规则来源权重高的优先权重接近时看时间新的优先时间也接近时看是否有独立印证被多方印证的优先。三条规则依次适用规则解决不了的才交给人。这套规则把模型自由心证的空间压得很小报告的一致性明显提升。领航鱼的温度我给 0.1。它是收敛角色任何一点随机性都会在最终输出上被放大。2.5 为什么交接用结构化消息而不是自然语言我一开始的版本是让鱼与鱼直接对话A 鱼把发现写成一段话交给 B 鱼。跑了两天我就放弃了原因有三个一是信息在转述过程中会失真B 鱼经常把 A 鱼的可能理解成确定二是对话历史会迅速膨胀上下文又被撑爆三是出了问题根本没法定位是哪一次转述出的错。改成结构化消息之后鱼与鱼之间只传固定 schema 的数据字段类型有校验必填项缺失直接报错重试。代价是每条鱼都要严格遵守格式前期写提示词很痛苦收益是整条链路变得可观测、可回放、可断点续跑。这个取舍在我看来完全值得因为多智能体系统最大的敌人不是模型能力而是不可观测。3. 从零搭一套能跑的最小骨架3.1 环境与依赖准备我的技术栈很朴素没有上重型框架。Python 3.11 加 asyncio 就够了理由是我需要的是并发调度而不是分布式计算上重量级编排框架属于杀鸡用牛刀而且调试成本会高出一个量级。python -m venv .venv source .venv/bin/activate pip install httpx pydantic tenacity redis几个依赖的分工httpx 负责异步请求pydantic 负责所有消息 schema 的校验这是整个项目的安全绳任何一条鱼吐出来的数据先过一遍校验不合格直接打回tenacity 负责重试策略网络抖动是常态不重试的系统在生产环境活不过一天redis 是可选的单机跑内存队列就够需要断点续跑和跨进程再上它。模型接口我做了个抽象层所有鱼只认一个BaseLLM接口from abc import ABC, abstractmethod class BaseLLM(ABC): abstractmethod async def chat(self, messages: list[dict], temperature: float 0.2) - str: ... abstractmethod async def count_tokens(self, text: str) - int: ...加这一层的原因很实际不同角色对模型能力的要求差很多。侦察鱼和清道夫用便宜的小模型就够深潜鱼和领航鱼需要强模型。抽象层让我可以在不改业务代码的前提下按角色分配模型成本能省下三到四成。count_tokens也必须是接口的一部分因为预算熔断依赖它而不同模型的计数方式不一样不能写死。3.2 任务总线水域与鱼我把调度中心叫水域鱼在里面游。水域的核心是一个带优先级的异步队列加一组常驻 worker。import asyncio, time class Water: def __init__(self, concurrency: int 6): self.queue asyncio.Queue() self.concurrency concurrency self.registry: dict[str, float] {} # 探测点指纹 - 登记时间 async def register(self, fingerprint: str) - bool: now time.time() if fingerprint in self.registry and now - self.registry[fingerprint] 600: return False # 已有鱼在查打回 self.registry[fingerprint] now return True async def run(self, handler): async def worker(): while True: task await self.queue.get() try: await handler(task) finally: self.queue.task_done() await asyncio.gather(*[worker() for _ in range(self.concurrency)])register这个方法就是 Boids 里分离规则的落地同一水域十分钟内不接受重复的探测点指纹。十分钟这个数字是我试出来的太短起不到去重效果太长会导致时效性差的探测点被误杀。并发度默认设 6这个值不是随便定的。十二条鱼不等于十二个并发因为每条鱼自己还要发起网络请求实际并发请求数是并发鱼数乘以每条鱼的内部并发。我实测下来并发鱼数超过 6 之后端到端时延不再下降但限流报错和超时抖动明显上升。第 5 节有数据支撑这个结论。3.3 状态机与终止条件整个流程是一个显式的状态机我用一个简单的轮次循环实现每轮做四件事派发探测点、收集证据、清道夫整理、领航鱼判断收敛。async def run_loop(question: str, budget_tokens: int 900_000, max_rounds: int 3): probes await scout(question) evidence [] for rnd in range(1, max_rounds 1): if await used_tokens() budget_tokens: break # 闸刀一预算 new_items await dispatch_divers(probes) evidence await cleaner(evidence new_items) gain marginal_gain(evidence, new_items) if gain 0.15 and rnd 2: break # 闸刀二收敛 probes await scout_expand(evidence) # 基于已有证据补充探测点 if not converged(evidence): return await pilot(question, evidence, modecaveat) # 闸刀三降级交付 return await pilot(question, evidence, modenormal)三把闸刀缺一不可。预算是硬保护收敛是效率保护降级交付是质量保护。第三把尤其重要当证据不足以支撑一个确定结论时领航鱼会切到 caveat 模式明确写出哪些点没有被证实而不是硬编一个答案。我宁可交付一份承认不确定性的报告也不要一份看起来很完整但经不起追问的报告。3.4 上下文压缩把长文做成鱼食深潜鱼读到的网页动辄几千字原样塞进上下文是灾难。我把压缩做成三段式事实层这个页面里有哪些可独立成立的事实陈述每条约 20 字证据层支撑每条事实的原文片段保留原始措辞待办层这个页面引出的新问题、指向的新来源三段的用途完全不同事实层进证据池供裁决证据层供回链校验待办层回流给侦察鱼生成新探测点。这样拆分之后一个 5000 字的页面压成大约 800 token信息损失可控而压缩比接近 6 比 1。这里有个细节值得说压缩提示词里我明确要求宁可少写不要推测。早期版本模型特别喜欢补全把没写的也说成写了导致证据池里混进一批无法回链的卡片。加了这条约束之后回链失败率从两位数掉到了个位数。4. 上线后最先撞到的四堵墙4.1 预算熔断三把闸刀怎么设数值预算失控是多智能体系统最常见的死法因为它不是一次性爆炸而是温水煮青蛙。我来算一笔账假设每次检索返回约 3000 token 的可用内容每条深潜鱼一轮做 3 次检索加 2 次模型调用单轮约 1.2 万 token6 条鱼并发跑 3 轮加上侦察和清道夫的开销单次任务大约 30 万 token。如果并发调到 12、轮次放到 5同样的任务会冲到 120 万 token 以上成本直接翻四倍而效果提升远不到四倍。所以我的三把闸刀是这样设的总 token 预算 90 万给正常任务留三倍余量轮次上限 3单条鱼单轮工具调用上限 8 次。任何一把触发系统不会崩而是走降级路径把已经拿到的证据整理成交付物。这一点很关键——熔断的目的不是省钱是保证系统在任何情况下都能给出一个确定的输出。4.2 引用回链校验让每条结论都能落到原文幻觉是多智能体系统的头号敌人而且它有个恶劣特性鱼越多幻觉被投票确认的概率反而可能上升因为如果多条鱼基于同一篇错误来源各自推理它们的结论会看起来很一致。我的解法是强制回链校验分两层。第一层是字面校验卡片里的 snippet 必须能在抓取到的原文里找到。我用的是归一化后做子串匹配允许标点差异不允许用词差异。这一层能过滤掉大部分凭空生成的引用。第二层是语义校验claim 和 snippet 的语义相似度必须高于阈值防止引了一段原文但结论和原文无关这种更隐蔽的问题。两层都过的卡片才进证据池。实测下来两层校验能把最终报告里的无源结论压到 3% 以下。代价是有一部分本来正确的卡片会被误杀大概 5% 左右。我接受这个代价因为在调研场景里宁缺毋假比宁滥勿缺重要得多。4.3 复读鱼的识别与处置复读鱼是我自己起的名字指的是某条鱼在两轮之间产出的内容高度相似说明它卡住了在做无效循环。这种情况在网络受限、来源稀少的话题上特别常见。识别方法很简单对每条鱼相邻两轮的输出做相似度计算连续两轮相似度超过 0.9 就判定为复读。处置分三步先换检索式把关键词做同义替换和语序调整再换信息源类型从文档类换成讨论类或数据类两步都没效果就直接终止这条鱼并在日志里标记。如果不做这个处理一条复读鱼能吃掉整个任务 20% 以上的预算产出还是零。4.4 冲突裁决投票、权重、置信度证据池里出现互相矛盾的结论是常态不能靠模型感觉。我的裁决分三级情况裁决方式来源权重差大于 0.3直接采信高权重来源权重接近时间差大于一年采信更新的权重和时间都接近看独立印证数量多者胜以上都不满足标记为存在争议两条并列写入报告最后一档的处理方式是我最满意的设计。很多系统遇到争议会强行选一个结果把不确定性藏起来了。我选择把争议明明白白写出来读者自己判断。这样做出来的报告看起来没那么干净但可信度反而更高。5. 一组可复现的对比实验与调参建议5.1 实验设置我准备了 20 个调研任务覆盖技术选型、行业梳理、产品对比三类每个任务都由我在不知道配置的情况下人工评一次分。指标有五个事实覆盖率人工核对后被证实的关键事实占应有关键事实的比例、可追溯率能回链到原文的结论占比、平均成本、端到端时延、人工综合评分1 到 5 分。5.2 四组配置的实测对照配置事实覆盖率可追溯率平均成本时延人工评分单体 Agent61%74%1.0 倍3.1 分钟2.43 条鱼78%91%1.8 倍4.6 分钟3.56 条鱼89%96%2.9 倍6.2 分钟4.312 条鱼90%96%5.4 倍9.8 分钟4.2这组数字最值得看的是最后两行。从 6 条鱼加到 12 条鱼成本几乎翻倍覆盖率只涨了一个百分点人工评分甚至还略降——因为鱼多了之后重复内容和轻微冲突增加报告的阅读体验反而变差。所以我的默认配置就定在 6 条鱼只有任务明显更复杂子问题超过 10 个时才临时提到 9 条。5.3 各角色的温度与模型分配建议角色温度模型档位理由侦察鱼0.7中档需要发散容错率高深潜鱼0.2中高档需要忠实输出量大清道夫0.1低档规则化工作小模型够用领航鱼0.1高档决定最终质量不能省把清道夫交给小模型这一条是我省钱最有效的一招。它的工作本质是分类、去重、打分规则清晰小模型完全能胜任而在整个流程里它处理的 token 量却能占到三成以上。换模型之后单次任务成本降了大约 25%质量没有可感知的下降。6. 我在 MiroFish 上浪费最多时间的三件事6.1 超时设置不合理导致的假失败这个坑我排查了大半天。现象是任务日志里时不时出现某条鱼执行失败但把同样的探测点单独跑一次又完全正常。我一开始怀疑是模型服务不稳定加了重试失败率降了一半但没根治。完整的排查链路是这样走的先看失败鱼的日志发现它在某次工具调用上卡了很久然后超时再统计卡住的调用类型全是响应体比较大的页面然后我把失败时刻的请求单独重放发现响应需要 40 秒以上而我的超时设的是 30 秒。根因清楚了超时阈值是按平均响应时间设的没有考虑长尾。修复方案是给工具调用设两级超时——单次请求 60 秒硬超时但整条鱼的总时长设 300 秒软超时软超时触发时允许它带着已有结果返回而不是全部丢弃。修复之后失败率降到千分之几。经验就一句话多智能体系统里的超时不能只有一层单次请求和整体任务必须分开设。6.2 工具返回被截断与编码问题第二个坑更隐蔽。现象是证据池里偶尔出现明显不完整的卡片片段在句子中间断掉。查了半天发现两个独立原因一是抓取工具对超长响应做了截断默认上限只保留前一部分后面的内容全丢了二是部分来源的编码不是标准形式没显式指定时中文会变成乱码而乱码在后续的字符串匹配里会静默失败——不报错只是校验不过卡片被丢弃。第二个原因才是真正浪费时间的因为它不报错。我的修复是两个动作所有抓取调用显式指定编码解析完成之后加一道长度和字符集合法性校验异常的直接标记重抓而不是静默丢弃。这道校验加上之后我才敢相信证据池里的数据是完整的。6.3 结构化输出解析失败的三层兜底结构化消息是好设计但模型不是每次都听话尤其是输出长 JSON 的时候偶尔会多一个逗号或者少一个引号。我做了三层兜底def parse_structured(raw: str, schema): # 第一层直接解析 try: return schema.model_validate_json(raw) except Exception: pass # 第二层从文本里提取最外层 JSON 块再解析 candidate extract_json_block(raw) if candidate: try: return schema.model_validate_json(candidate) except Exception: pass # 第三层把报错信息连同原文丢回模型要求只输出修正后的 JSON repaired repair_with_llm(raw, schema) return schema.model_validate_json(repaired)三层走完还失败的直接判定该条鱼本轮失败不计入证据池但记录日志用于后续改进提示词。这里有个经验第三层兜底一定要限定只做格式修复不要改内容否则模型会顺手把结论也改了那就等于引入了一个新的幻觉源。7. 把鱼群接到你自己的业务里7.1 领域知识的注入方式通用鱼群跑通用问题还行一碰到垂直领域立刻露怯因为公开信息里专业知识密度低。我的做法是给证据池加一个只读优先层把内部文档、历史报告、术语表预先切片入库深潜鱼检索时先查这一层命中足够就减少公开检索的次数。这带来两个实际好处。一是术语一致报告里不会一会儿一个叫法二是背景知识不需要每次现查预算省下来用在真正需要外部信息的地方。术语表特别值得单独做我会把容易混淆的术语和它们的标准定义写成一小段文本作为所有鱼的系统提示固定部分。这一步做完报告里术语误用的比例下降得很明显。7.2 三个值得让人拍板的介入点全自动跑完固然爽但真要交付的时候我给系统留了三个必须人工确认的卡点因为它们对应着三种机器判断最容易出偏差的场景。第一个卡点是探测点确认。侦察鱼给出的方向如果偏了后面十二条鱼全白跑所以在探测点生成后让人扫一眼成本极低、收益极高。第二个卡点是争议结论。裁决规则解决不了的冲突我不会让模型硬选而是列出来让人定。第三个卡点是降级交付。当系统判定证据不足切到 caveat 模式时需要人确认是接受这份带保留意见的报告还是追加预算再跑一轮。这三个卡点加起来人工介入时间大概两三分钟但能让整份报告的可用性提升一个档次。我的看法是多智能体系统的价值不在于完全替代人而在于把人从找资料、核对事实这类体力活里解放出来让人只做判断。这个分工比全自动务实得多。最后分享一个小技巧。如果你也打算搭类似的东西别一上来就写十二条鱼的调度先用两条鱼跑通侦察到深潜到证据池到成文这条最小闭环把结构化消息、回链校验、预算熔断这三块地基打牢再往上加鱼。我当初是先写调度再加校验结果校验一上线前面写的调度逻辑有一半要重改那些时间本可以省下来。地基先行的顺序在鱼群这种有状态、多环节的系统里比什么都重要。
第一次把 MiroFish 完整跑通的那晚我盯着终端里滚动的日志看了快半小时十二条鱼围着同一个问题各自游了七分钟最后领航鱼吐出来的那份调研报告覆盖密度和交叉验证的扎实程度比我一个人查一下午的结果还硬。那一刻我才确定把深度调研这种活儿拆成多智能体协作的鱼群模式方向是对的。MiroFish 是我自己攒的一套多智能体协作框架专门处理那种一个问题要翻十几处资料、还得自己判断哪条信息可信的深度调研任务。Miro 是我上一版单体 Agent 的代号最早只是帮我整理白板思路用的Fish 是这一版的形态——鱼群。名字的来历不重要重要的是三件事它到底解决了什么问题、怎么从零搭起来、哪些地方最容易翻车。这篇文章我把这三件事一次讲透代码、参数、踩坑记录都在里面。不管你是刚接触多智能体、还在犹豫要不要上手还是已经写过几个 Agent 但被成本和幻觉折磨过下面的内容应该都能直接抄去用。我不会给你画一张漂亮的架构图然后说就长这样而是把每个设计决策背后的为什么掰开讲因为鱼群这套东西抄结构容易抄判断难。1. 鱼群隐喻落到工程上MiroFish 要解决的三个具体麻烦1.1 单鱼模式为什么会崩上下文雪崩与单点误判我上一版单体 Agent 做深度调研最常见的失败姿势是这样的接收一个问题开始一轮一轮地检索、读取、总结到第十八轮的时候上下文已经堆到二十万 token模型开始忘事——把前面已经证伪的说法又当成结论写进报告或者把某个二手转述当成一手事实。这不是模型不行是架构决定的。单条线程必须自己记住所有中间状态而中间状态里 80% 是垃圾。更麻烦的是单点误判。单体 Agent 一旦在某一步选错了检索方向后面所有推理都建立在这个错误前提上而且它自己没有能力发现我可能走歪了。就像一个人闭着眼睛走迷宫走得越久越自信实际离出口越远。我在真实任务上统计过单体模式下最终报告里至少有一条关键事实错误的概率超过四成这个数字在需要交付的场合是没法接受的。还有一层隐形成本。单体 Agent 因为上下文太长每一轮都要把前面所有内容重新塞给模型token 消耗是随轮次平方级增长的。跑到第十轮之后单轮成本已经是最初的三倍而信息增量几乎为零。这三个问题叠在一起就是我要把架构推倒重来的直接原因。1.2 把 Boids 的三条规则翻译成调度策略鱼群行为学里有个经典模型叫 Boids三条规则分离、对齐、聚合。我最初只是觉得这个隐喻好听真正动手之后才发现这三条规则恰好能一对一映射成多智能体调度里最难的三件事而且映射之后整个设计一下就顺了。分离对应到工程里就是去重与差异化探测。多条鱼同时开工最大的浪费是它们查同一个关键词、读同一篇文档。所以我在调度器里加了一个共享的探测点注册表任何一条鱼在发起检索之前先登记关键词指纹指纹重复的直接被打回让它换个角度。这条规则把我实测的无效重复检索从 37% 压到了 6% 左右。对齐对应的是共享证据池与统一引用规范。鱼与鱼之间不直接聊天——聊天会引入自然语言的模糊性也容易互相污染。它们只往一个共享的证据池里写结构化卡片格式固定字段固定。领航鱼读的也是这个池子而不是读其他鱼的对话记录。这样做的代价是灵活性下降好处是结果可追溯、可校验、可复现。聚合对应的是收敛判断。鱼群什么时候停不是所有鱼都跑完才停而是领航鱼根据证据池的边际增量决定。新增证据里新事实的比例连续两轮低于 15%就判定收敛立刻收网。这个阈值不是拍脑袋来的后面第 5 节有我做的一组对比实验。1.3 什么时候不该上鱼群一张判断清单我得先把话说清楚鱼群不是银弹用它之前先看这张表。我在项目里给自己定了一条规矩——任何任务先过这张清单不满足的坚决不上鱼群因为硬上只会让成本和复杂度同时翻倍。任务特征适合鱼群建议用单体信息源数量需要跨 8 个以上信息源单一文档或单一页面事实冲突程度来源之间说法不一致需要裁决事实清晰、无争议时效要求分钟级到小时级可接受秒级响应成本敏感度单次任务预算可到几元到几十元预算按厘计算交付要求结论必须带可追溯引用只要一段概括问题结构可拆成 5 个以上独立子问题线性追问即可典型适合的场景技术选型调研、某个行业近况梳理、竞品功能拆解、长文档集的交叉比对。典型不适合的场景帮我改一句文案、把这段代码翻译成另一种语言、查一个明确的事实点。我见过有人拿鱼群去做单页摘要六条鱼跑出来的结果和一条鱼几乎一样成本却是六倍。这不是框架的问题是选型的问题。2. 六个鱼种的分工与交接协议2.1 侦察鱼把一句模糊的问题拆成可执行探测点用户丢过来的问题通常是模糊的比如我想了解这个方向值不值得投入。侦察鱼的任务就是把它翻译成 5 到 12 个可执行的探测点。每个探测点必须包含四个字段缺一个都不算合格{ probe_id: p_003, goal: 确认该方向近两年的工程落地案例数量级, queries: [方向名 生产环境, 方向名 案例复盘, 方向名 失败教训], evidence_type: 案例或复盘文需含具体数字, abort_condition: 连续两次检索无可信来源即放弃 }这里有个我踩过的坑一开始我让侦察鱼自由发挥结果它给出的探测点全是了解一下背景看看有什么进展这种没法执行的话。后来我在提示词里加了两条硬约束——每个探测点必须能对应至少一条具体检索式且必须写明放弃条件。加上这两条之后探测点的可用率从五成提到了九成以上。侦察鱼的温度我会调到 0.7 左右。这个角色需要发散需要想到别人想不到的角度温度高一点反而更好。但发散不等于乱来字段约束就是它的笼子。2.2 深潜鱼一个探测点挖到底产出证据卡片深潜鱼是干活的主力。它领到一个探测点做多轮检索和阅读最后产出的不是一段散文而是一组证据卡片。卡片结构长这样字段含义约束claim一句话结论不超过 40 字必须是陈述句source来源标识需可回链snippet支撑该结论的原文片段20 到 200 字必须是原文confidence置信度0 到 1两位小数freshness信息时间相对当前时间的跨度snippet 这个字段是整个体系的地基。我强制要求它必须是原文摘录而不是模型改写理由很简单模型改写的片段没法校验而原文摘录可以用字符串匹配去验证。这一条约束让我的引用回链校验从靠感觉变成了可自动化后面第 4 节会详细讲。深潜鱼的温度我压到 0.2。这个角色要的是忠实和稳定不是创意。同一张卡片跑两次结论应该基本一致否则下游的裁决就没法做。2.3 清道夫去重、降噪、给来源打分十二条鱼跑完证据池里通常会有大量重复。同一个事实可能被四条鱼从四个不同来源带回来其中两个是原始出处两个是互相抄的二手转述。清道夫的活就是把这些理清楚。去重我做的是两段式先用字符级指纹做粗筛把明显同源的合并再用语义相似度做细筛相似度超过 0.88 的判定为同一事实。粗筛快但会漏细筛准但慢两段配合的性价比最高。这里要注意一个反直觉的点去重不是越狠越好。有些看似重复的证据其实是相互印证的独立来源把它们合并掉反而丢掉了被多方证实这个重要信号。所以我的做法是合并内容、保留来源列表而不是直接删掉。来源可信度打分我用四个维度各占不同权重来源类型一手数据、官方文档、行业媒体、个人博客占 40%时间新鲜度一年内满分逐年递减占 25%是否包含可核对的原始数据占 20%是否被其他独立来源交叉印证占 15%这套权重是我自己调出来的不一定通用但它有个好处每一项都能解释出问题的时候知道该改哪一项。2.4 领航鱼收敛判断与最终成文领航鱼是唯一有全局视野的角色它读的是整理后的证据池不是原始网页。它的职责有三个判断该不该继续跑、裁决相互冲突的结论、把证据池写成最终交付物。裁决冲突的时候我不让领航鱼自己感觉哪个对而是给它一套明确规则来源权重高的优先权重接近时看时间新的优先时间也接近时看是否有独立印证被多方印证的优先。三条规则依次适用规则解决不了的才交给人。这套规则把模型自由心证的空间压得很小报告的一致性明显提升。领航鱼的温度我给 0.1。它是收敛角色任何一点随机性都会在最终输出上被放大。2.5 为什么交接用结构化消息而不是自然语言我一开始的版本是让鱼与鱼直接对话A 鱼把发现写成一段话交给 B 鱼。跑了两天我就放弃了原因有三个一是信息在转述过程中会失真B 鱼经常把 A 鱼的可能理解成确定二是对话历史会迅速膨胀上下文又被撑爆三是出了问题根本没法定位是哪一次转述出的错。改成结构化消息之后鱼与鱼之间只传固定 schema 的数据字段类型有校验必填项缺失直接报错重试。代价是每条鱼都要严格遵守格式前期写提示词很痛苦收益是整条链路变得可观测、可回放、可断点续跑。这个取舍在我看来完全值得因为多智能体系统最大的敌人不是模型能力而是不可观测。3. 从零搭一套能跑的最小骨架3.1 环境与依赖准备我的技术栈很朴素没有上重型框架。Python 3.11 加 asyncio 就够了理由是我需要的是并发调度而不是分布式计算上重量级编排框架属于杀鸡用牛刀而且调试成本会高出一个量级。python -m venv .venv source .venv/bin/activate pip install httpx pydantic tenacity redis几个依赖的分工httpx 负责异步请求pydantic 负责所有消息 schema 的校验这是整个项目的安全绳任何一条鱼吐出来的数据先过一遍校验不合格直接打回tenacity 负责重试策略网络抖动是常态不重试的系统在生产环境活不过一天redis 是可选的单机跑内存队列就够需要断点续跑和跨进程再上它。模型接口我做了个抽象层所有鱼只认一个BaseLLM接口from abc import ABC, abstractmethod class BaseLLM(ABC): abstractmethod async def chat(self, messages: list[dict], temperature: float 0.2) - str: ... abstractmethod async def count_tokens(self, text: str) - int: ...加这一层的原因很实际不同角色对模型能力的要求差很多。侦察鱼和清道夫用便宜的小模型就够深潜鱼和领航鱼需要强模型。抽象层让我可以在不改业务代码的前提下按角色分配模型成本能省下三到四成。count_tokens也必须是接口的一部分因为预算熔断依赖它而不同模型的计数方式不一样不能写死。3.2 任务总线水域与鱼我把调度中心叫水域鱼在里面游。水域的核心是一个带优先级的异步队列加一组常驻 worker。import asyncio, time class Water: def __init__(self, concurrency: int 6): self.queue asyncio.Queue() self.concurrency concurrency self.registry: dict[str, float] {} # 探测点指纹 - 登记时间 async def register(self, fingerprint: str) - bool: now time.time() if fingerprint in self.registry and now - self.registry[fingerprint] 600: return False # 已有鱼在查打回 self.registry[fingerprint] now return True async def run(self, handler): async def worker(): while True: task await self.queue.get() try: await handler(task) finally: self.queue.task_done() await asyncio.gather(*[worker() for _ in range(self.concurrency)])register这个方法就是 Boids 里分离规则的落地同一水域十分钟内不接受重复的探测点指纹。十分钟这个数字是我试出来的太短起不到去重效果太长会导致时效性差的探测点被误杀。并发度默认设 6这个值不是随便定的。十二条鱼不等于十二个并发因为每条鱼自己还要发起网络请求实际并发请求数是并发鱼数乘以每条鱼的内部并发。我实测下来并发鱼数超过 6 之后端到端时延不再下降但限流报错和超时抖动明显上升。第 5 节有数据支撑这个结论。3.3 状态机与终止条件整个流程是一个显式的状态机我用一个简单的轮次循环实现每轮做四件事派发探测点、收集证据、清道夫整理、领航鱼判断收敛。async def run_loop(question: str, budget_tokens: int 900_000, max_rounds: int 3): probes await scout(question) evidence [] for rnd in range(1, max_rounds 1): if await used_tokens() budget_tokens: break # 闸刀一预算 new_items await dispatch_divers(probes) evidence await cleaner(evidence new_items) gain marginal_gain(evidence, new_items) if gain 0.15 and rnd 2: break # 闸刀二收敛 probes await scout_expand(evidence) # 基于已有证据补充探测点 if not converged(evidence): return await pilot(question, evidence, modecaveat) # 闸刀三降级交付 return await pilot(question, evidence, modenormal)三把闸刀缺一不可。预算是硬保护收敛是效率保护降级交付是质量保护。第三把尤其重要当证据不足以支撑一个确定结论时领航鱼会切到 caveat 模式明确写出哪些点没有被证实而不是硬编一个答案。我宁可交付一份承认不确定性的报告也不要一份看起来很完整但经不起追问的报告。3.4 上下文压缩把长文做成鱼食深潜鱼读到的网页动辄几千字原样塞进上下文是灾难。我把压缩做成三段式事实层这个页面里有哪些可独立成立的事实陈述每条约 20 字证据层支撑每条事实的原文片段保留原始措辞待办层这个页面引出的新问题、指向的新来源三段的用途完全不同事实层进证据池供裁决证据层供回链校验待办层回流给侦察鱼生成新探测点。这样拆分之后一个 5000 字的页面压成大约 800 token信息损失可控而压缩比接近 6 比 1。这里有个细节值得说压缩提示词里我明确要求宁可少写不要推测。早期版本模型特别喜欢补全把没写的也说成写了导致证据池里混进一批无法回链的卡片。加了这条约束之后回链失败率从两位数掉到了个位数。4. 上线后最先撞到的四堵墙4.1 预算熔断三把闸刀怎么设数值预算失控是多智能体系统最常见的死法因为它不是一次性爆炸而是温水煮青蛙。我来算一笔账假设每次检索返回约 3000 token 的可用内容每条深潜鱼一轮做 3 次检索加 2 次模型调用单轮约 1.2 万 token6 条鱼并发跑 3 轮加上侦察和清道夫的开销单次任务大约 30 万 token。如果并发调到 12、轮次放到 5同样的任务会冲到 120 万 token 以上成本直接翻四倍而效果提升远不到四倍。所以我的三把闸刀是这样设的总 token 预算 90 万给正常任务留三倍余量轮次上限 3单条鱼单轮工具调用上限 8 次。任何一把触发系统不会崩而是走降级路径把已经拿到的证据整理成交付物。这一点很关键——熔断的目的不是省钱是保证系统在任何情况下都能给出一个确定的输出。4.2 引用回链校验让每条结论都能落到原文幻觉是多智能体系统的头号敌人而且它有个恶劣特性鱼越多幻觉被投票确认的概率反而可能上升因为如果多条鱼基于同一篇错误来源各自推理它们的结论会看起来很一致。我的解法是强制回链校验分两层。第一层是字面校验卡片里的 snippet 必须能在抓取到的原文里找到。我用的是归一化后做子串匹配允许标点差异不允许用词差异。这一层能过滤掉大部分凭空生成的引用。第二层是语义校验claim 和 snippet 的语义相似度必须高于阈值防止引了一段原文但结论和原文无关这种更隐蔽的问题。两层都过的卡片才进证据池。实测下来两层校验能把最终报告里的无源结论压到 3% 以下。代价是有一部分本来正确的卡片会被误杀大概 5% 左右。我接受这个代价因为在调研场景里宁缺毋假比宁滥勿缺重要得多。4.3 复读鱼的识别与处置复读鱼是我自己起的名字指的是某条鱼在两轮之间产出的内容高度相似说明它卡住了在做无效循环。这种情况在网络受限、来源稀少的话题上特别常见。识别方法很简单对每条鱼相邻两轮的输出做相似度计算连续两轮相似度超过 0.9 就判定为复读。处置分三步先换检索式把关键词做同义替换和语序调整再换信息源类型从文档类换成讨论类或数据类两步都没效果就直接终止这条鱼并在日志里标记。如果不做这个处理一条复读鱼能吃掉整个任务 20% 以上的预算产出还是零。4.4 冲突裁决投票、权重、置信度证据池里出现互相矛盾的结论是常态不能靠模型感觉。我的裁决分三级情况裁决方式来源权重差大于 0.3直接采信高权重来源权重接近时间差大于一年采信更新的权重和时间都接近看独立印证数量多者胜以上都不满足标记为存在争议两条并列写入报告最后一档的处理方式是我最满意的设计。很多系统遇到争议会强行选一个结果把不确定性藏起来了。我选择把争议明明白白写出来读者自己判断。这样做出来的报告看起来没那么干净但可信度反而更高。5. 一组可复现的对比实验与调参建议5.1 实验设置我准备了 20 个调研任务覆盖技术选型、行业梳理、产品对比三类每个任务都由我在不知道配置的情况下人工评一次分。指标有五个事实覆盖率人工核对后被证实的关键事实占应有关键事实的比例、可追溯率能回链到原文的结论占比、平均成本、端到端时延、人工综合评分1 到 5 分。5.2 四组配置的实测对照配置事实覆盖率可追溯率平均成本时延人工评分单体 Agent61%74%1.0 倍3.1 分钟2.43 条鱼78%91%1.8 倍4.6 分钟3.56 条鱼89%96%2.9 倍6.2 分钟4.312 条鱼90%96%5.4 倍9.8 分钟4.2这组数字最值得看的是最后两行。从 6 条鱼加到 12 条鱼成本几乎翻倍覆盖率只涨了一个百分点人工评分甚至还略降——因为鱼多了之后重复内容和轻微冲突增加报告的阅读体验反而变差。所以我的默认配置就定在 6 条鱼只有任务明显更复杂子问题超过 10 个时才临时提到 9 条。5.3 各角色的温度与模型分配建议角色温度模型档位理由侦察鱼0.7中档需要发散容错率高深潜鱼0.2中高档需要忠实输出量大清道夫0.1低档规则化工作小模型够用领航鱼0.1高档决定最终质量不能省把清道夫交给小模型这一条是我省钱最有效的一招。它的工作本质是分类、去重、打分规则清晰小模型完全能胜任而在整个流程里它处理的 token 量却能占到三成以上。换模型之后单次任务成本降了大约 25%质量没有可感知的下降。6. 我在 MiroFish 上浪费最多时间的三件事6.1 超时设置不合理导致的假失败这个坑我排查了大半天。现象是任务日志里时不时出现某条鱼执行失败但把同样的探测点单独跑一次又完全正常。我一开始怀疑是模型服务不稳定加了重试失败率降了一半但没根治。完整的排查链路是这样走的先看失败鱼的日志发现它在某次工具调用上卡了很久然后超时再统计卡住的调用类型全是响应体比较大的页面然后我把失败时刻的请求单独重放发现响应需要 40 秒以上而我的超时设的是 30 秒。根因清楚了超时阈值是按平均响应时间设的没有考虑长尾。修复方案是给工具调用设两级超时——单次请求 60 秒硬超时但整条鱼的总时长设 300 秒软超时软超时触发时允许它带着已有结果返回而不是全部丢弃。修复之后失败率降到千分之几。经验就一句话多智能体系统里的超时不能只有一层单次请求和整体任务必须分开设。6.2 工具返回被截断与编码问题第二个坑更隐蔽。现象是证据池里偶尔出现明显不完整的卡片片段在句子中间断掉。查了半天发现两个独立原因一是抓取工具对超长响应做了截断默认上限只保留前一部分后面的内容全丢了二是部分来源的编码不是标准形式没显式指定时中文会变成乱码而乱码在后续的字符串匹配里会静默失败——不报错只是校验不过卡片被丢弃。第二个原因才是真正浪费时间的因为它不报错。我的修复是两个动作所有抓取调用显式指定编码解析完成之后加一道长度和字符集合法性校验异常的直接标记重抓而不是静默丢弃。这道校验加上之后我才敢相信证据池里的数据是完整的。6.3 结构化输出解析失败的三层兜底结构化消息是好设计但模型不是每次都听话尤其是输出长 JSON 的时候偶尔会多一个逗号或者少一个引号。我做了三层兜底def parse_structured(raw: str, schema): # 第一层直接解析 try: return schema.model_validate_json(raw) except Exception: pass # 第二层从文本里提取最外层 JSON 块再解析 candidate extract_json_block(raw) if candidate: try: return schema.model_validate_json(candidate) except Exception: pass # 第三层把报错信息连同原文丢回模型要求只输出修正后的 JSON repaired repair_with_llm(raw, schema) return schema.model_validate_json(repaired)三层走完还失败的直接判定该条鱼本轮失败不计入证据池但记录日志用于后续改进提示词。这里有个经验第三层兜底一定要限定只做格式修复不要改内容否则模型会顺手把结论也改了那就等于引入了一个新的幻觉源。7. 把鱼群接到你自己的业务里7.1 领域知识的注入方式通用鱼群跑通用问题还行一碰到垂直领域立刻露怯因为公开信息里专业知识密度低。我的做法是给证据池加一个只读优先层把内部文档、历史报告、术语表预先切片入库深潜鱼检索时先查这一层命中足够就减少公开检索的次数。这带来两个实际好处。一是术语一致报告里不会一会儿一个叫法二是背景知识不需要每次现查预算省下来用在真正需要外部信息的地方。术语表特别值得单独做我会把容易混淆的术语和它们的标准定义写成一小段文本作为所有鱼的系统提示固定部分。这一步做完报告里术语误用的比例下降得很明显。7.2 三个值得让人拍板的介入点全自动跑完固然爽但真要交付的时候我给系统留了三个必须人工确认的卡点因为它们对应着三种机器判断最容易出偏差的场景。第一个卡点是探测点确认。侦察鱼给出的方向如果偏了后面十二条鱼全白跑所以在探测点生成后让人扫一眼成本极低、收益极高。第二个卡点是争议结论。裁决规则解决不了的冲突我不会让模型硬选而是列出来让人定。第三个卡点是降级交付。当系统判定证据不足切到 caveat 模式时需要人确认是接受这份带保留意见的报告还是追加预算再跑一轮。这三个卡点加起来人工介入时间大概两三分钟但能让整份报告的可用性提升一个档次。我的看法是多智能体系统的价值不在于完全替代人而在于把人从找资料、核对事实这类体力活里解放出来让人只做判断。这个分工比全自动务实得多。最后分享一个小技巧。如果你也打算搭类似的东西别一上来就写十二条鱼的调度先用两条鱼跑通侦察到深潜到证据池到成文这条最小闭环把结构化消息、回链校验、预算熔断这三块地基打牢再往上加鱼。我当初是先写调度再加校验结果校验一上线前面写的调度逻辑有一半要重改那些时间本可以省下来。地基先行的顺序在鱼群这种有状态、多环节的系统里比什么都重要。
