1. 从 Sakana Fugu 技术报告看多智能体系统到底解决了什么问题如果你最近在关注 LLM 智能体方向大概率会刷到 Sakana Fugu 技术报告。它讨论的核心不是「再训一个更大的模型」而是一个更工程化的问题当不同厂商的前沿模型各有所长时能不能用一个学习到的编排器把它们组织起来让整体表现超过任何单个模型。Fugu 和 Fugu-Ultra 就是这条思路下的两个产物前者偏日常低延迟后者偏复杂任务的质量上限。我先把这份报告里最值得开发者关注的三件事讲清楚。第一Fugu 把「多智能体系统」包装成了单一模型接口你调用它就像调用一个普通模型但内部会动态路由、委派、协调多个专业智能体。第二Fugu-Ultra 用 GRPO 训练一个 Conductor让它用自然语言设计最多 5 步的智能体工作流每一步指定子任务、负责的工作者 ID、以及访问列表。第三它专门解决了多智能体函数调用的内存管理问题工作流内智能体隔离跨工作流共享内存。这三件事对做 LLM 应用的开发者意味着什么意味着你不需要自己去手写一套固定的多智能体通信拓扑也不需要为每个任务手动调参。编排器本身是训练出来的它会根据查询自适应地决定用哪个模型、怎么组合。报告里给出的评估结果也印证了这一点Fugu-Ultra 在 SWE Bench Pro 上达到 73.7Terminal Bench 2.1 上 82.1GPQA Diamond 上 95.5多项基准达到最优或次优。但报告毕竟是报告落到工程实践里你更关心的是我能不能复现一套类似的智能体角色配置GRPO 的训练参数该怎么设多智能体协作效果怎么验证这篇就按这个思路走先讲清楚 Fugu 的架构逻辑再给可复制的配置和训练参数最后给验证协作效果的具体动作。中间会用到 TaoToken 作为统一接入层把多个模型的调用收敛到一个 Base URL 上这样你在本地就能搭一个缩小版的编排实验环境。需要提前说明的是Fugu 依赖闭源 API 模型报告里也提到推理延迟高于单模型调用定性实验样本量有限。所以下面的配置是「可跟做的工程复现思路」不是对原系统的逐行还原。你按这个思路搭出来的东西能验证多智能体协作的核心机制也能帮你判断 GRPO 在你的任务上是否值得投入。2. TaoToken 前置把多模型调用收敛到一个 Base URL要复现 Fugu 这类多智能体系统第一道坎不是算法是接入。Fugu 的工作者池里同时有 Gemini、Claude、GPT 系列如果你每个厂商都单独申请 Key、单独维护 SDK、单独处理重试和限流光是接入层就能吃掉你一半精力。更麻烦的是当编排器要在运行时动态切换模型时你需要一个统一的调用入口否则代码里会散落一堆 if-else。TaoToken 在这里的角色就是统一接入层。它提供 OpenAI 兼容的 API 接口你可以用同一套 SDK、同一个 Base URL、同一个 Key 去调用不同厂商的模型。对多智能体系统来说这一点很关键编排器只需要知道「工作者 ID 对应哪个 Model ID」不需要关心底层是哪家厂商。你换模型、加模型、去掉某个模型都只改配置不改调用逻辑。具体接入信息如下。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。你需要在控制台创建 API Key地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。创建好之后把 Key 存到环境变量里不要硬编码到代码中。这里有个容易踩的坑很多人第一次配的时候会把 Base URL 写成 https://taotoken.net/api/v1 或者带斜杠结尾结果 SDK 拼接路径时出现双斜杠或者路径错位。正确的做法是 Base URL 只写到 /api让 SDK 自己去拼 /v1/chat/completions。如果你用的是 OpenAI Python SDKbase_url 参数就填 https://taotoken.net/api 。还有一个前置动作是确认你的工作者池里有哪些模型可用。Fugu 报告里的池子是 Gemini-3.1-Pro、Claude-Opus-4.8、GPT-5.5你在 TaoToken 控制台里能看到当前支持的模型列表选三个能力互补的就行。选模型的原则参考报告里的路由分布分析Terminal Bench 类任务峰值在 GPT 系GPQA 类科学任务峰值在 Gemini 系软件工程和调试类任务 Opus 系有优势。你不需要完全照搬但要让池子里的模型有差异化专长否则编排器学不到东西。配置完成后你可以先用模型对话页面手动验证一下调用是否通。地址是 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。在里面选一个模型发一条简单请求确认返回正常。这一步看起来多余但能帮你排除掉 90% 的接入问题避免后面调试编排逻辑时把接入错误误判成算法错误。3. 可复制配置智能体角色定义与 GRPO 训练参数这一节给两份可直接复制的配置。第一份是智能体角色配置用 JSON 描述工作者池和角色第二份是 GRPO 训练参数用 TOML 描述。两份配置的路径和字段名都按可运行的标准来写你复制后改一下模型 ID 和路径就能用。先看智能体角色配置。这份配置的核心是把「工作者 ID」和「模型 ID」解耦编排器只认工作者 ID实际调用时再映射到具体模型。这样你换模型时只改映射表不动编排逻辑。配置里还定义了每个角色的专长标签这些标签会作为提示词的一部分传给 Conductor帮助它做路由决策。{ worker_pool: [ { worker_id: 0, model_id: gemini-3.1-pro, role: scientist, strengths: [science, factual_recall, multimodal], max_tokens: 8192, temperature: 0.3 }, { worker_id: 1, model_id: claude-opus-4.8, role: engineer, strengths: [software_engineering, debugging, security], max_tokens: 8192, temperature: 0.2 }, { worker_id: 2, model_id: gpt-5.5, role: mathematician, strengths: [math, planning, algorithm_design], max_tokens: 8192, temperature: 0.2 } ], conductor: { model_id: gpt-5.5, max_workflow_steps: 5, access_list_enabled: true, isolation_mode: within_workflow, shared_memory: cross_workflow }, base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY }这份配置里几个字段值得展开说。max_workflow_steps设为 5和报告里 Fugu-Ultra 的上限一致。isolation_mode设为within_workflow对应报告里的「工作流内智能体隔离」目的是防止第一个智能体设定的路径主导后续所有智能体也就是报告里说的「编排崩溃」。shared_memory设为cross_workflow对应「持久共享内存」让智能体能观察先前工作流中的工具调用避免重复调用工具重新发现相同的工件。再看 GRPO 训练参数。报告里明确提到 Fugu-Ultra 用 GRPO 训练使用分组补全计算蒙特卡洛优势函数奖励为 Conductor 特定奖励训练时不施加 KL 散度惩罚。下面这份 TOML 把这些关键点都落成了可配置项。[grpo] algorithm grpo group_size 8 learning_rate 1e-6 kl_penalty 0.0 clip_ratio 0.2 max_grad_norm 1.0 num_train_epochs 3 per_device_batch_size 2 gradient_accumulation_steps 8 [reward] format_weight 0.0 correctness_weight 1.0 partial_correctness_score 0.5 parse_failure_score 0.0 [workflow] max_steps 5 allow_parallel true access_list_required true [memory] within_workflow_isolation true cross_workflow_shared true这里解释几个关键参数。group_size 8是分组补全的组大小GRPO 的核心就是用同一 prompt 的多条补全来估计优势组太小方差大组太大显存吃紧8 是个常见起点。kl_penalty 0.0对应报告里「不施加 KL 散度惩罚」这是 Fugu-Ultra 训练设置的一个明确特征你如果发现训练不稳定可以适当加一点但报告的做法是设为 0。partial_correctness_score 0.5对应报告里的奖励机制无法解析工作流给 0输出匹配真实解给 1否则给 0.5。奖励函数这块要特别注意。报告里的奖励是递进条件格式条件不满足直接 0正确性条件满足给 1否则 0.5。这个设计的好处是给模型一个中间信号避免只有 0 和 1 导致稀疏奖励。你在实现时解析工作流的逻辑要健壮因为一旦解析失败奖励直接归零模型学不到任何东西。建议在解析器里加详细的错误日志方便排查是格式问题还是内容问题。配置写好后把 API Key 设到环境变量里。如果你在本地跑可以这样操作export TAOTOKEN_API_KEY你的Key如果你用 Coding Plan 做长期编码和 Agent 实验可以在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 了解套餐配置。对于需要反复跑 GRPO 训练的场景稳定的调用配额比单次低价更重要因为训练过程中会有大量并发请求。4. 验证请求跑通一次多智能体协作并检查结果配置写完下一步是验证。验证分两层先验证单次调用能通再验证多智能体协作真的发生了。很多人跳过第一层直接跑编排结果报错时分不清是接入问题还是逻辑问题。第一层验证用 curl 发一个最小请求确认 Base URL 和 Key 都对。命令如下curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-5.5, messages: [{role: user, content: 回复 OK}], max_tokens: 16 }如果返回里有choices字段且内容正常说明接入层通了。如果报 401检查 Key 是否复制完整、是否有多余空格。如果报 model not found检查模型 ID 是否和控制台里的一致。第二层验证跑一次完整的编排流程。下面这段 Python 代码模拟了 Conductor 生成工作流、执行工作流、收集结果的过程。代码里用了一个简化的工作流结构你可以直接跑观察输出。import os import json from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY] ) WORKER_POOL { 0: gemini-3.1-pro, 1: claude-opus-4.8, 2: gpt-5.5 } def conductor_plan(query): prompt f你是一个编排器。根据用户问题设计一个最多5步的工作流。 每一步包含subtask自然语言子任务、worker_id0/1/2、access_list依赖哪些先前步骤。 只输出JSON格式{{steps: [{{subtask: ..., worker_id: 0, access_list: []}}]}} 用户问题{query} resp client.chat.completions.create( modelgpt-5.5, messages[{role: user, content: prompt}], temperature0.2 ) return json.loads(resp.choices[0].message.content) def execute_workflow(workflow, query): results [] for i, step in enumerate(workflow[steps]): context query for idx in step[access_list]: context f\n\n步骤{idx}结果{results[idx]} resp client.chat.completions.create( modelWORKER_POOL[step[worker_id]], messages[{role: user, content: f{step[subtask]}\n\n上下文{context}}], temperature0.2 ) results.append(resp.choices[0].message.content) return results query 计算 2 的 10 次方并解释计算过程 workflow conductor_plan(query) print(生成的工作流, json.dumps(workflow, ensure_asciiFalse, indent2)) results execute_workflow(workflow, query) for i, r in enumerate(results): print(f步骤{i}结果{r[:200]})跑通后你会看到 Conductor 生成的工作流 JSON以及每个步骤的执行结果。这里的关键观察点是Conductor 是否为不同子任务分配了不同的 worker_idaccess_list 是否体现了步骤间的依赖如果所有步骤都分配给同一个 worker说明你的提示词或奖励设计没有引导出差异化路由需要调整。成功结果的判断标准有三个。第一工作流能被正确解析成 JSON没有格式错误。第二不同步骤的 worker_id 有差异说明编排器在做路由决策。第三最终结果比单模型直接回答更完整或更准确。你可以做个对照实验同一个问题分别用单模型直接回答和用编排流程回答对比结果质量。如果你想更直观地看多智能体协作过程可以在模型对话页面手动模拟先让一个模型出方案再把方案和原始问题一起发给另一个模型做审查观察第二个模型是否能发现第一个模型的问题。这个手动过程就是「构建者-调试者」模式的简化版报告里提到的 GPT 构建、Opus 调试就是这个思路。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth这一节按真实报错来组织。你在复现过程中大概率会遇到下面几类错误每一类我都给出原因和排查动作。第一类401 Unauthorized。这是最常见的接入错误。原因通常是 Key 无效、Key 过期、或者请求头格式不对。排查动作先确认环境变量TAOTOKEN_API_KEY是否设置成功用echo $TAOTOKEN_API_KEY检查。然后确认请求头是Authorization: Bearer key注意 Bearer 后面有一个空格。如果还是 401去控制台重新创建一个 Key地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。创建后立即复制有些控制台只显示一次。第二类local proxy failed。这个报错通常出现在你本地设置了网络代理但代理配置和 SDK 的请求方式冲突。排查动作检查环境变量里是否有HTTP_PROXY、HTTPS_PROXY、ALL_PROXY如果有先临时清掉再试。另外检查 SDK 是否被配置了自定义的 http_client有些 http_client 会读取系统代理设置。如果你在公司网络环境里确认网络策略允许访问 API 地址。第三类reading choices 相关报错比如KeyError: choices或IndexError: list index out of range。这类错误说明返回的 JSON 结构和你预期的不一样。原因可能是请求被限流、模型返回了错误信息、或者响应体为空。排查动作先把原始响应打印出来不要直接取choices[0]。在代码里加一层判断resp client.chat.completions.create(...) if not resp.choices: print(空响应原始返回, resp) raise ValueError(模型未返回有效结果)如果原始返回里有error字段按错误信息处理。常见的是rate_limit_exceeded这时候需要降低并发或等待重试。第四类OAuth 相关报错。如果你用的是 Claude Code 或类似的编码助手可能会遇到 OAuth token 过期或认证失败。这类工具通常有自己的认证流程和 API Key 是两套机制。排查动作确认你用的是 API Key 模式还是 OAuth 模式。如果用 API Key在配置里明确指定 Base URL 和 Key不要混用 OAuth 配置。Claude Code 的接入配置里Base URL 填 https://taotoken.net/api Key 填你的 API KeyModel ID 填你选的模型。这三件套要写全缺一个都可能报认证错误。除了这四类还有一个高频问题是「工作流解析失败」。这不是接入错误是 Conductor 输出的 JSON 格式不对。排查动作在解析前先做清洗去掉 markdown 代码块标记用json.loads时加 try-except失败时打印原始文本。如果频繁解析失败在 Conductor 的提示词里加 few-shot 示例明确输出格式。最后提醒一个配置层面的坑如果你同时用了 CC Switch、Cline MCP、Codex auth.json 这类工具注意它们的配置文件路径和字段名各不相同。CC Switch 通常改的是 settings 文件Cline MCP 改的是 MCP 配置Codex auth.json 改的是 auth 文件。不管哪个核心三件套都是 Base URL、Key、Model ID。Base URL 统一用 https://taotoken.net/api Key 用你的 API KeyModel ID 用控制台里确认过的模型 ID。三件套写全再排查其他问题。6. 把编排实验落到长期工作流从验证到持续迭代跑通一次验证请求只是起点。真正有价值的是把编排实验变成可重复、可迭代的工作流。这一节讲怎么从单次验证过渡到持续迭代以及在这个过程中怎么用 TaoToken 的能力降低摩擦。第一步是建立基线。在你开始调编排逻辑之前先记录单模型在目标任务上的表现。比如你选 20 个测试问题分别用池子里的三个模型单独回答记录正确率、平均耗时、平均 token 消耗。这个基线是你判断编排是否带来增益的参照。没有基线你无法区分「编排有效」和「任务本身简单」。第二步是固定评估集。报告里用了 SWE Bench Pro、Terminal Bench 2.1、GPQA Diamond 等标准基准你在自己的场景里也需要一个固定评估集。评估集要满足两个条件有明确的正确性判断标准覆盖不同类型的任务。比如你可以混合代码题、数学题、事实问答每类 10 到 20 题。每次调整编排逻辑或 GRPO 参数后都在同一个评估集上跑对比结果。第三步是迭代编排策略。从最简单的开始先只做单步路由让 Conductor 为每个问题选一个 worker不做多步工作流。这个阶段的目标是验证路由是否有效也就是编排器的选择是否比随机选择或固定选择更好。如果单步路由都学不好多步工作流更难。单步路由稳定后再逐步增加步骤数从 2 步到 3 步观察增益来自哪里。第四步是监控关键指标。除了最终正确率你还要关注几个过程指标工作流解析成功率、平均步骤数、worker 分布是否均衡、单次请求的 token 消耗。解析成功率低说明格式约束不够强worker 分布过度集中说明路由没有学到差异化token 消耗异常高说明工作流有冗余步骤。这些指标能帮你在正确率变化之前就发现问题。第五步是处理长尾任务。报告里提到 Fugu-Ultra 在 Humanitys Last Exam 这类多学科任务上三个智能体分布高度平衡数学问题路由到 GPT化学和生物问题路由到 Gemini。这说明编排器在细粒度上做了区分。你在自己的场景里也要观察哪些任务类型路由一致哪些任务类型路由混乱。路由混乱的任务类型往往是提示词或奖励设计需要调整的地方。如果你需要长期跑这类实验Coding Plan 会比按次调用更合适地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。长期编码和 Agent 实验的特点是请求量大、并发高、需要稳定配额按次调用容易在训练中途遇到限流打断实验节奏。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的参数说明和示例。如果你在配置过程中遇到文档没覆盖的问题优先检查三件套是否写全再检查请求格式是否符合 OpenAI 兼容规范。最后说一个实操经验多智能体系统的调试成本比单模型高很多因为出错时你面对的是多个模型的交互轨迹。建议在早期就加详细的日志记录每个步骤的输入、输出、worker_id、耗时。这些日志在排查「为什么编排器选了错误的 worker」这类问题时非常关键。日志不用多复杂结构化输出到文件就行但一定要有。