Fugu Ultra v2

1. 多模型自动编排

Ultra v2 的核心是模型调度。

收到任务后，系统会判断要不要拆分、每一步交给哪个模型，以及中间结果怎么继续传下去。用户不用自己维护模型 Router，也不用手动安排一整套 Agent 流程。

这个设计更适合研究、代码分析、开发这类需要连续推进的任务。翻译、短文本总结、小段代码之类的工作，本身一步就能完成，多一层编排未必有必要，反而可能增加等待时间和费用。

2. 100 万 Token 上下文、图像输入和联网搜索

Ultra v2 支持最高 100 万 token 上下文，可以处理大型代码库、长文档、论文和成批研究资料，也能接收图像并调用联网搜索。

100 万 token 更像一个上限，不适合当成常规用法。超过 272K 后价格会提高，而且把资料全部塞进上下文，也不一定比先筛选再分析更有效。

如果任务只涉及其中几份文件，先检索相关内容，再交给模型处理，通常更省成本。

3. OpenAI 兼容 API

Fugu Ultra v2 使用 OpenAI 兼容 API。

已经按照 OpenAI API 形式开发的项目，接入时不用重写整套调用层。开发者提交任务后，后台的模型选择和调度交给 Fugu 处理。

好处是少维护一层多模型路由，代价则是控制权会减少。团队如果需要精确指定每一步使用哪个模型，或者严格记录每次调用成本，自己搭工作流可能更合适。

4. 相比上一代，模型池调整更明显

Ultra v2 相比 v1，一个重要变化是模型池。

新版移除了 Fable 5、Fable 5.1 和 GPT-6 Astra，训练截止时间更新到 2026 年 8 月 28 日。

这个改动降低了系统对少数旗舰模型的依赖。某个模型涨价、接口调整或者表现变化时，调度系统可以替换底层模型，而不必跟着重做整套产品。

从 v1 迁移到 v2 也比较直接。SDK 不需要更换，只需要把模型 ID 改成：

fugu-ultra-v2.0

Fugu Ultra v2 的优势在于把任务拆解和模型选择交给系统处理。研究、大型代码库分析、长资料整理这类任务，本来就需要多个步骤，自动调度能减少自己搭工作流的成本。

它的限制也很实际：多模型调用会增加 token 消耗，长上下文价格更高，后台调度又减少了一部分可控性。官方 Benchmark 成绩不错，但单看分数还不足以判断它在真实工作流里的表现。

如果你经常做研究、代码分析、Agent 工作流，或者希望减少对单一模型供应商的依赖，Fugu Ultra v2 值得测试。

如果主要需求是日常问答、翻译、普通写作和简单代码，直接使用成熟的单模型更省事。对成本特别敏感，或者希望精确控制每一步模型调用的人，也未必适合它。

我自己会优先拿它测试代码库分析和长资料研究。日常问答和简单写作，没有切过去的必要。