@eliebakouch: 明确一下，这是一个建立在闭源模型之上的闭源编排器。如果以前你无法控制模型...

需要明确的是，这是一个基于闭源模型的闭源编排器。如果说以前你无法控制模型，那么现在你甚至连哪些模型被使用、用了多少都无法控制。这并非“AI主权“。

我也阅读了技术报告以了解技术方面的看法：

fugu（非ultra版本）基本上是一个分类器，用于选择每一轮中最有可能正确回答的模型（换句话说，一个路由器）。这使得在SWE Bench pro上相比Opus得分低了10分，在其他基准测试上略有提升但很小。有人可能会说它能降低成本，但没有任何相关信息，所以很可能相反。他们还有一个自动研究基准测试，与前沿模型“Model A, B and C“进行比较，不公开比较的模型是什么真是疯狂。另外，这可能不支持开箱即用地添加新LLM，因为你需要重新训练分类器。

关于fugu ultra，它基本上是一个高级计划和编排器，是一个模型，对于查询会输出包含多个“工作流“的计划。我对工作流的理解是：“生成模型A子代理来完成这个，然后用模型B来评判，用模型C来总结”，这只是一个测试时扩展计算策略。我认为这是一种还可以的方式，但受限于他们需要在代理开始工作之前预测所有内容，这就是为什么他们将其限制为5步。在我看来，你需要根据在t时刻获得的信息来预测在t+1时刻生成什么，而不是根据t=0时刻的信息。还有其他问题，比如Fable 5在Terminal Bench上的得分是错误的，而且他们对于LLM池中包含哪个模型非常含糊不清（只提到了闭源API模型）。

最大且最明显的问题是，他们引入了一种“测试时扩展“方法，对模型进行“Best of N“，但他们在基准测试/任务中从未报告过输出token数量或成本。

这里好的比较不是与Opus，而是启用了Ultracode/Workflows的Opus；不是与Kimi，而是与Kimi Swarm等。发布非常令人困惑。

Sakana AI (@SakanaAILabs): 推出Sakana Fugu：一个可通过单一模型API访问的完整多代理编排系统。

我们的’Fugu Ultra’模型性能与Fable和Mythos相当，提供前沿能力而无出口管制风险。

尝试一下：https://t.co/aDEFyySWlS 🐡