批评Sakana Fugu多模型闭源编排器，技术不透明且未报告成本
明确一点，这是一个基于闭源模型的闭源编排器。如果以前你不能控制模型，现在你甚至不能控制使用哪些模型或多少。这不是“AI主权”。
我也阅读了技术报告以了解技术方面的看法：
Fugu（非Ultra版本）基本上是一个分类器，每次选择最可能正确回答的模型（即路由器）。这导致在SWE Bench Pro上比Opus低10分，在其他基准测试上略有提升。论证可能是它降低了成本，但没有相关信息，所以很可能相反。他们还有一个自动研究基准测试，与前沿模型“模型A、B、C”进行比较，这真的很疯狂，不透明地比较模型。另外，这很可能不支持开箱即用地添加新LLM，因为你需要重新训练分类器。
关于Fugu Ultra，这基本上是一个高级计划模式和编排器，是一个模型，根据查询输出包含多个“工作流”的计划。我对工作流的理解是：它们说“生成模型A子代理来实现这个，然后用模型B判断，再用模型C总结”，这只是一个测试时扩展计算策略。我认为这是一种还行的方法，但受限于它们需要在代理开始工作前预测所有内容，所以限制为5个步骤。在我看来，你需要根据t时刻获得的信息预测t+1时刻要生成什么，而不是t=0的信息。还有其他问题，例如Terminal Bench上的Fable 5分数错误，以及它们对LLM池中的模型非常模糊（只提到闭源API模型）。
最大最明显的问题是，它们引入了一种“测试时扩展”方法，即对模型进行“最佳N”，但从未报告实现基准/任务所需的输出token数量或成本。
正确的比较不应是与Opus，而是启用Ultracode/Workflows的Opus，不应是与Kimi，而是Kimi Swarm等。非常非常令人困惑的发布。
我也阅读了技术报告以了解技术方面的看法：
Fugu（非Ultra版本）基本上是一个分类器，每次选择最可能正确回答的模型（即路由器）。这导致在SWE Bench Pro上比Opus低10分，在其他基准测试上略有提升。论证可能是它降低了成本，但没有相关信息，所以很可能相反。他们还有一个自动研究基准测试，与前沿模型“模型A、B、C”进行比较，这真的很疯狂，不透明地比较模型。另外，这很可能不支持开箱即用地添加新LLM，因为你需要重新训练分类器。
关于Fugu Ultra，这基本上是一个高级计划模式和编排器，是一个模型，根据查询输出包含多个“工作流”的计划。我对工作流的理解是：它们说“生成模型A子代理来实现这个，然后用模型B判断，再用模型C总结”，这只是一个测试时扩展计算策略。我认为这是一种还行的方法，但受限于它们需要在代理开始工作前预测所有内容，所以限制为5个步骤。在我看来，你需要根据t时刻获得的信息预测t+1时刻要生成什么，而不是t=0的信息。还有其他问题，例如Terminal Bench上的Fable 5分数错误，以及它们对LLM池中的模型非常模糊（只提到闭源API模型）。
最大最明显的问题是，它们引入了一种“测试时扩展”方法，即对模型进行“最佳N”，但从未报告实现基准/任务所需的输出token数量或成本。
正确的比较不应是与Opus，而是启用Ultracode/Workflows的Opus，不应是与Kimi，而是Kimi Swarm等。非常非常令人困惑的发布。