架构选择

Sakana Fugu 用学习到的模型池换路由可见性

官方产品文案说，Fugu 通过一个 API 协调模型池，并用学习到的协作模式代替手写工作流。同一份 FAQ 又说你看不到是哪些底层模型回答了查询。这两条加在一起，才是它和自建图的真正比较。

2026 年 8 月 17 日核对

1. 买 Fugu 时你买到什么

你买到一个 OpenAI 兼容（现在也兼容 Anthropic Messages）的接口，可以把工作路由到一个模型池。官方页面还说：Fugu 可以从池中排除特定提供方或模型；Ultra 使用固定完整池，并在一到三个代理之间路由；路由细节专有且不暴露；新的公开前沿模型预计大约两周训练评估后才会进入 Fugu 更新。运维含义是：工作流代码更少，路径控制更少，Ultra 的成本对象还包含编排 token。

2. 留下一张图时你留下什么

自建设计——LangGraph、手写路由器或简单回退列表——让你可以记录每一跳、钉死每一个模型，并拒绝一个你叫不出名字的供应商。重试、评估和失败模式也归你。这是更多工程。当审计、数据驻留或事故响应需要具名工作者时，这些额外工作是正确的。

3. 从官方约束推出的决策规则

若你必须先选原因
在欧盟/EEA 之外尽快上线编程或评审助手Fugu官方日常默认；可以排除代理
为更难的多步质量多花钱Ultra，然后评估固定池；一到三代理；已公布费率
在审计日志里点名每个模型自建官方 FAQ 说 Fugu 不暴露这张图
排除某个提供方但仍要托管池Fugu，不是 Ultra官方 FAQ 说 Ultra 池是固定的
服务欧盟/EEA 生产用户官方 Fugu 产品都不行官方可用性限制

选择器 编码了后三行。即使工作负载本来像 Cyber 候选，只要你要求完整路由可见性，它也会推荐自建编排。

4. 允许混合，不允许混账

有些团队会把受监管工作流留在自建图，把 Fugu 留给内部研究。只要日志和账单分开，这是自洽的。把 Ultra 流量送到合作方，再把本站官方 Ultra 公式套到一张不分项编排字段的发票上，则不自洽。合并成本报告前先比较 usage 对象。

把决定写成约束，而不是口味：“我们必须点名工人”或“我们可以接受专有路由”。口味会漂。约束能熬过下一次模型改名。欧盟/EEA 生产用户在官方产品可用之前，两边都不是答案；那是可用性规则，不是架构偏好。具体规则已写进 选择器。

如果选 Fugu 的唯一理由是“听说它比前沿模型更强”，先停下来，用 评估手册 在自己的任务上测。官方分数是厂商证据，不能告诉你：在真正会产生法律或运维风险的工作流上，你能不能接受一条看不见的路由。合作方入口也不能自动解决可见性问题，见 访问地图。

Fugu 可以排除部分提供方，Ultra 的池是固定的。需要排除某个供应商又还想托管池时，官方文档指向 Fugu 而不是 Ultra。需要点名每一个工人时，两边托管模型都不够，只能自建。把这三条写进架构备忘，比再讨论一次“哪个名字听起来更强”有用。备忘里还要写清谁有权改这条约束，以及下一次复审日期，避免半年后只剩一个口头决定。

本页不覆盖什么

这里不比较具体自建框架的性能，也不给 LangGraph 或任何编排库做排名。比较点只有官方已经写明的约束：路由不暴露、Fugu 可排除代理、Ultra 池固定、欧盟/EEA 不可用。框架选型是另一篇文章，而且不属于本站当前证据范围。混合使用时也要把账单和日志拆开，避免把官方 Ultra 公式套到字段不同的发票上。约束写进备忘后，就不要再按模型名的响亮程度改架构。复审时先重读官方 FAQ，确认路由仍不暴露，再决定是否继续托管。若 FAQ 仍说看不到底层模型，审计要求就没有消失。

选择器已把“必须看见每一跳”编码成自建编排结果。那不是口味，是官方 FAQ 推出来的硬边界。不要为了省事把这条改回托管模型池上。

来源