Sakana Fugu 深度解析：「多智能体即单模型」如何终结手工编排时代

2026 年 6 月 22 日，Sakana AI 发布了 Fugu——一个「多智能体即单模型」的产品。 用户只需调用一个 OpenAI 兼容的 API 端点，Fugu 内部自动决定是直接处理任务，还是组建一个专家模型团队来协作完成。模型的选择、委派、验证、综合——全部在内部完成，多智能体系统的复杂性永远不会到达用户的代码。

这不是又一个 Multi-Agent 框架。CrewAI、AutoGen、LangGraph 解决的是「如何编排多个 Agent」的问题，而 Fugu 解决的是一个更根本的问题——「为什么还需要手工编排？」

Agent 架构的三次范式跃迁：

• 第一代（2023-2024）：单 Agent 时代。 一个模型 + 工具调用，GPT-4 + Function Calling 是典型代表。局限在于能力边界——没有任何单一模型能精通所有领域。
• 第二代（2024-2025）：手工编排时代。 CrewAI、LangGraph、AutoGen 等框架让开发者手动定义 Agent 角色、通信协议和工作流。强大但脆弱——编排逻辑本身成为系统最大的维护负担。
• 第三代（2026-）：学习编排时代。 Fugu 代表的方向——编排器自身通过强化学习和进化算法学会如何协调 Agent，不再需要人工设计工作流。

Fugu 的核心洞察是： 编排本身也可以是一个可学习的任务。就像我们不需要为每个新任务手写神经网络架构一样，我们也不应该为每个新的多 Agent 系统手写编排逻辑。

Fugu 最反直觉的设计是：编排器（orchestrator）本身就是一个语言模型。 它不是用规则引擎或决策树来决定如何分配任务——它是一个经过专门训练的小型语言模型，学会了「何时委派、委派给谁、如何综合结果」。

架构分层：

第一层：用户接口层。 对外暴露一个 OpenAI 兼容的 API 端点。用户发送请求，就像调用一个普通模型一样。没有任何多 Agent 的概念泄露到接口层。

第二层：编排决策层。 Fugu 模型接收用户请求后，首先判断：这个任务我可以直接处理，还是需要组建专家团队？如果需要团队，哪些模型适合？如何分配子任务？

第三层：专家执行层。 被选中的模型在各自的「角色」中执行任务。编排器管理 Agent 之间的通信——包括任务描述、中间结果传递和最终综合。

第四层：结果验证层。 编排器对各个专家的输出进行交叉验证和综合，生成最终的一致答案。

两个产品变体：

• Fugu（标准版）：适合日常编码、代码审查、聊天机器人。延迟低，成本可控。支持从模型池中 opt-out 特定模型，满足数据隐私和合规要求。
• Fugu Ultra：面向高难度多步骤问题。协调更深的专家模型池，池固定不可 opt-out。在工程、科学推理等基准测试上与 Anthropic Fable 5 和 Mythos Preview 比肩。当前模型 ID 为 fugu-ultra-20260615。

关键设计决策——递归调用： Fugu 模型本身也可以被放入 Agent 池中，被自己递归调用。这意味着在某些场景下，Fugu 可以先用自身能力尝试解决，发现不足时再调用更强的专家模型。

Fugu 不是凭空出现的——它建立在 Sakana AI 两篇 ICLR 2026 论文之上：Trinity 和 Conductor。 这两篇论文分别解决了学习编排的两个核心问题：如何进化出高效的协调策略（Trinity），以及如何用自然语言实现灵活的 Agent 间通信（Conductor）。

3.1 Trinity：进化的 LLM 协调器

Trinity 的核心思想是用进化算法来「生长」出一个协调器。 不是人工设计协调逻辑，而是让多个候选协调策略通过多轮迭代进化，保留表现最好的策略。

Trinity 的三角色模型：

• Thinker（思考者）：负责理解任务、分解子问题、制定计划
• Worker（执行者）：负责执行具体的子任务
• Verifier（验证者）：负责检查 Worker 的输出质量，发现问题时要求重做

进化过程： 多个候选协调器并行运行，每轮迭代后根据任务完成质量进行选择和变异。经过数百代进化，最终产生一个高效的协调策略——这个策略往往出人意料地高效，因为它不受人类设计偏见的约束。

关键发现： 进化出的协调器在多个基准测试上超越了人工设计的协调策略，同时使用的 token 更少。这说明人类在设计编排逻辑时存在固有的认知偏差——我们倾向于设计过于复杂的流程，而进化能找到更简洁的路径。

3.2 Conductor：自然语言编排

Conductor 解决的是另一个关键问题：Agent 之间如何通信？ 传统 Multi-Agent 系统使用结构化消息（JSON、protobuf），但 Conductor 证明了自然语言本身就是最高效的 Agent 间通信协议。

Conductor 的训练方法： 使用强化学习（RL）训练一个编排器，让它学会：

• 为不同的 LLM 池生成针对性的 prompt
• 根据任务特征动态调整协调策略
• 在 Agent 之间传递上下文时保持信息完整性

Conductor 的突破性发现： 当编排器使用自然语言进行协调时，它可以利用 LLM 的语义理解能力来传递复杂的上下文——这是结构化消息做不到的。例如，一个 Agent 可以用自然语言向另一个 Agent 解释「这个代码片段的性能问题在于 O(n²) 的嵌套循环，建议改用哈希表」——这种语义丰富的通信在 JSON 中很难表达。

Trinity + Conductor → Fugu： Fugu 将两篇论文的方法融合并大幅工程化。Trinity 提供了进化协调策略的基础框架，Conductor 提供了自然语言通信的灵活性，Fugu 在此基础上增加了商业化所需的产品化能力——包括双模型变体、OpenAI 兼容 API、模型池管理等。

理解 Fugu 与传统 Multi-Agent 框架的差异，关键在于区分「编排」和「执行」。 CrewAI、LangGraph、AutoGen 解决的是执行层面的问题——如何让多个 Agent 协同工作。Fugu 解决的是编排层面的问题——如何决定哪些 Agent 应该协同工作。

四个维度的对比：

维度一：编排方式。 CrewAI 要求开发者预定义角色（Researcher、Writer、Reviewer）和工作流（顺序、并行、层次化）。LangGraph 用图结构定义状态转移。Fugu 的编排器通过训练学会了编排策略——用户只需要发送请求，编排器自动决定如何处理。

维度二：错误恢复。 在传统框架中，错误恢复需要开发者在编排逻辑中显式定义——「如果 Agent A 失败，回退到 Agent B」。Fugu 的编排器可以动态感知执行质量，自动触发重试或替换策略。

维度三：模型池管理。 CrewAI 等框架的模型池是静态配置的。Fugu 的模型池是动态可替换的——Fugu 标准版支持 opt-out 特定模型，满足数据合规需求。

维度四：用户体验。 传统框架面向开发者，需要编写 Python 代码定义 Agent 和工作流。Fugu 面向所有用户，一个 API 调用即可。

但 Fugu 不是替代品——它是上层抽象。 对于需要精细控制 Agent 行为的场景（如合规审计、特定业务流程），CrewAI/LangGraph 的显式编排仍然更合适。Fugu 更适合「我只需要结果，不关心过程」的场景。

Fugu 的出现对企业 AI 部署有三个层面的影响。

5.1 降低 Multi-Agent 开发门槛

过去： 部署一个多 Agent 系统需要一个工程团队花费数周时间设计角色、定义工作流、编写胶水代码、调试通信协议。

现在： 一个 API 调用。Fugu 内部处理所有编排逻辑。

实际影响：

• 初创公司可以快速获得企业级 AI 能力，不需要组建庞大的 AI 工程团队
• 现有产品可以通过替换 API 端点来获得多 Agent 能力，无需重写架构
• IT 团队的维护负担大幅降低——不再需要维护复杂的 Agent 编排代码

5.2 模型供应商的解耦

Fugu 的一个重要特性是模型池的可替换性。 编排器不绑定任何特定的模型供应商——它可以在运行时调用来自不同供应商的模型。

这意味着：

• 供应商锁定风险降低：不再依赖单一模型供应商，Fugu 可以在底层自动切换到最优模型
• 成本优化：编排器可以根据任务复杂度选择成本合适的模型——简单任务用便宜模型，复杂任务用强模型
• 合规灵活性：Fugu 标准版支持 opt-out 特定模型，满足数据驻留和隐私合规要求

5.3 出口管制的新应对策略

Sakana AI 在发布中特别强调了「without the risk of export controls」。 这是一个值得关注的信号。

背景： 2025-2026 年，美国对先进 AI 模型的出口管制持续收紧。Anthropic Fable 5、OpenAI 的某些前沿模型受到出口限制。但 Fugu 作为一个编排器，其核心能力不在于单一模型的强度，而在于协调策略——这是一种不同的技术路径。

企业应对策略：

• 混合部署：使用 Fugu 编排本地模型 + 云端模型，在合规前提下获得最优性能
• 渐进迁移：从单一供应商迁移到 Fugu 编排的多供应商架构，降低政策风险
• 成本分层：利用 Fugu 的智能路由，将 80% 的简单请求路由到成本更低的模型

5.4 实战接入代码

Fugu 使用 OpenAI 兼容 API，迁移成本极低。

# 从 OpenAI SDK 迁移到 Fugu 只需修改 base_url 和 api_key
from openai import OpenAI

# 初始化 Fugu 客户端
client = OpenAI(
    base_url="https://api.sakana.ai/v1",
    api_key="your-sakana-api-key"
)

# 使用 Fugu（标准版）
response = client.chat.completions.create(
    model="fugu",  # 或 "fugu-ultra-20260615" 使用 Ultra 版
    messages=[
        {"role": "system", "content": "你是一个专业的代码审查助手。"},
        {"role": "user", "content": "审查这段 Python 代码的性能问题..."}
    ],
    temperature=0.7
)

print(response.choices[0].message.content)

# Fugu Ultra 适合高难度多步骤任务
response_ultra = client.chat.completions.create(
    model="fugu-ultra-20260615",
    messages=[
        {"role": "user", "content": "设计一个分布式任务调度系统，要求..."}
    ]
)

# 响应中包含 usage 信息，可以看到编排 token 消耗
print(f"总 token: {response_ultra.usage.total_tokens}")
# 注意：编排 token 也计入费用

评估一个编排系统的价值，最终要看数字。 Fugu Ultra 在多个权威基准测试上取得了与前沿单一模型比肩的成绩，这对于一个「不直接解题而是协调专家」的系统来说意义重大。

关键基准成绩：

• SWE-Bench Pro：Fugu Ultra 得分 73.7，与 Anthropic Fable 5 和 Mythos Preview 处于同一梯队。SWE-Bench Pro 测试的是真实软件工程任务的解决能力，包括跨文件修改、调试和测试修复。
• GPQA-Diamond：在研究生级别的科学推理测试中，Fugu Ultra 的表现优于多个单一前沿模型。这得益于编排器能够针对不同科学领域调用不同的专家模型。
• LiveCodeBench：在实时编程任务中，Fugu 标准版已经能够处理大多数中等难度的编程挑战，延迟与直接调用单一模型相当。

编排开销分析：

Fugu Ultra 的定价模型区分了「可见模型工作」和「编排工作」的 token 消耗。在基准测试中，编排开销约占总 token 的 20-40%。对于简单任务（如单次代码生成），编排开销较低（约 10-15%）；对于复杂的多步骤任务（如跨文件重构），编排开销可能达到 40-50%。

这意味着什么： 如果你的任务主要是简单查询或单次生成，直接调用单一模型更经济。如果你的任务涉及多领域知识综合、多步骤推理或需要高可靠性的工程任务，Fugu 的编排开销换来的性能提升是值得的。

Fugu 代表了 Agent 架构的重要方向，但它远非完美。 在决定采用之前，需要清醒认识其局限性。

局限一：模型池不可自定义。 Fugu 标准版支持 opt-out 特定模型，但你不能 opt-in 自己的模型。这意味着如果 Fugu 的模型池中没有适合你特定领域需求的模型，编排器再聪明也无能为力。Ultra 版的模型池更是完全固定。

局限二：调试困难。 当编排器做出错误决策时（如选错了专家模型、综合了错误的结果），你很难追溯原因。编排逻辑是一个经过 RL 训练的小模型，它的决策过程不像人工设计的编排逻辑那样可读。对于需要严格审计追踪的场景（如金融合规、医疗决策），这是一个严重的限制。

局限三：成本不透明。 编排 token 也计入费用，但用户很难提前估算一个复杂任务的实际成本。在基准测试中编排开销占 20-40%，实际生产环境中可能更高。对于成本敏感的应用，需要仔细评估。

局限四：供应商依赖。 虽然 Fugu 解耦了底层模型供应商，但它本身成为了一个新的供应商锁定点。如果 Sakana AI 的服务出现问题或改变定价策略，迁移成本不容忽视。

局限五：出口管制的灰色地带。 Fugu 强调「without the risk of export controls」，但这是一个动态的政策领域。如果 Fugu 的模型池中包含了受管制的模型，编排器是否也受管制？这个问题目前没有明确答案。

Sakana Fugu 的意义不仅在于一个新产品——它验证了一个新的技术方向：编排本身是可以学习的。

从 Trinity 的进化协调器到 Conductor 的自然语言编排，再到 Fugu 的产品化落地，Sakana AI 用三年的时间证明了：我们不需要手工设计 Agent 之间的协作方式，我们可以让系统自己学会如何协作。

这并不意味着 CrewAI、LangGraph 等框架会消失——它们仍然在需要显式控制的场景中不可或缺。但 Fugu 开辟了一个新的可能性空间：对于那些「我只需要结果」的场景，自编排系统可能是更好的选择。

展望未来 12 个月，三个趋势值得关注：

1. 自编排成为默认选项：随着编排器质量的提升，越来越多的企业会默认选择自编排方案，只在特殊场景使用手工编排。

2. 编排器成为新的竞争焦点：模型能力的竞争会逐渐让位于编排能力的竞争——谁能更高效地协调模型，谁就能提供更好的性能。

3. Agent 架构的「芯片化」：就像芯片将电路设计封装为不可见的黑箱一样，Fugu 将多 Agent 编排封装为一个 API 调用。未来的 AI 应用开发者可能完全不需要了解内部有多少个 Agent 在协作。

Agent 编排的「学习革命」才刚刚开始。