WEBVTT
Kind: captions
Language: zh-CN

00:00:00.000 --> 00:00:02.260
一个核心的业务流程依赖于

00:00:02.260 --> 00:00:05.360
一个单一的、参数量最大的 LLM。

00:00:05.360 --> 00:00:08.670
当这个模型在某个特定的编码

00:00:08.670 --> 00:00:10.320
任务上出现逻辑漏洞，

00:00:10.320 --> 00:00:13.150
或者供应商突然调整了定价和

00:00:13.150 --> 00:00:14.280
服务路径时

00:00:14.280 --> 00:00:17.590
整个系统的可靠性和可预测性

00:00:17.590 --> 00:00:19.080
瞬间就崩了。

00:00:19.080 --> 00:00:21.950
这种对单一巨型模型的依赖，正

00:00:21.950 --> 00:00:24.740
在成为构建企业级复杂 Agent 的

00:00:24.740 --> 00:00:26.080
一个结构性风险。

00:00:26.640 --> 00:00:29.950
Sakana AI 推出了 Sakana Fugu，它不是

00:00:29.950 --> 00:00:32.240
要再造一个更大的 LLM，

00:00:32.240 --> 00:00:35.080
而是提出了一种全新的架构思

00:00:35.080 --> 00:00:37.890
路：用一个智能的“项目经理”来调

00:00:37.890 --> 00:00:38.760
度一群专家。

00:00:38.760 --> 00:00:42.030
Fugu 的核心价值，在于它将 AI 系统

00:00:42.030 --> 00:00:44.930
的设计，从单纯地追求“模型能力”

00:00:44.930 --> 00:00:45.480
的黑箱，

00:00:45.480 --> 00:00:48.090
转化成了一个可调度的“协作生

00:00:48.090 --> 00:00:48.800
态系统”。

00:00:48.800 --> 00:00:51.770
它的运作方式，是接收一个复杂

00:00:51.770 --> 00:00:52.280
请求，

00:00:52.720 --> 00:00:55.230
然后不会直接扔给一个模型，而

00:00:55.230 --> 00:00:57.980
是会先做出决策。它会动态地判

00:00:57.980 --> 00:00:58.240
断，

00:00:58.240 --> 00:01:00.730
这个任务需要一个思考者（Think

00:01:00.730 --> 00:01:01.720
er）来规划

00:01:01.720 --> 00:01:04.640
需要一个执行者（Worker）来编码，

00:01:04.640 --> 00:01:08.100
还是需要一个验证者（Verifier）来复

00:01:08.100 --> 00:01:08.520
核。

00:01:08.520 --> 00:01:11.900
随后，它会根据任务的特性，将这

00:01:11.900 --> 00:01:15.290
些角色分配给一个由多个前沿 L

00:01:15.290 --> 00:01:17.280
LM 组成的“可替换池”。

00:01:17.840 --> 00:01:21.250
这个“可替换池”的设计，是 Fugu 最值

00:01:21.250 --> 00:01:23.480
得关注的架构点。它直接解决了

00:01:23.480 --> 00:01:26.200
你在做企业级应用时最头疼的

00:01:26.200 --> 00:01:28.520
供应商锁定和合规性问题。

00:01:28.520 --> 00:01:30.680
你可以根据数据隐私要求

00:01:30.680 --> 00:01:33.540
随时把池子里的某个模型换成

00:01:33.540 --> 00:01:36.330
自有的私有模型，或者切换到另

00:01:36.330 --> 00:01:37.920
一个提供商的方案，

00:01:37.920 --> 00:01:40.290
架构的韧性一下子就被拉上

00:01:40.290 --> 00:01:40.760
来了。

00:01:41.240 --> 00:01:43.850
很多人可能会误以为 Fugu 只是

00:01:43.850 --> 00:01:46.560
一个高级的 API 网关，但这个判断

00:01:46.560 --> 00:01:49.140
是错的。它本身是一个经过训练

00:01:49.140 --> 00:01:50.160
的语言模型，

00:01:50.160 --> 00:01:52.980
它的协调逻辑是自适应的。它能

00:01:52.980 --> 00:01:54.960
递归地阅读自己的输出

00:01:54.960 --> 00:01:57.930
然后决定是否需要调整协调策

00:01:57.930 --> 00:02:01.130
略，这比传统的固定流程复杂得

00:02:01.130 --> 00:02:01.320
多。

00:02:01.320 --> 00:02:04.320
从性能数据来看，Fugu Ultra 在软

00:02:04.320 --> 00:02:07.660
件工程基准测试，比如 SWE-Bench

00:02:07.660 --> 00:02:09.880
Pro 上表现非常亮眼，

00:02:10.320 --> 00:02:13.250
拿到了七十三点七分，甚至在编码和推

00:02:13.250 --> 00:02:16.490
理的特定场景下 超过了像 Claude

00:02:16.490 --> 00:02:20.560
Opus 4.8 和 GPT-5.5 这样的顶尖模型。

00:02:20.560 --> 00:02:23.290
这说明，在处理真实代码库的错

00:02:23.290 --> 00:02:26.170
误修复和复杂逻辑定位上 协同

00:02:26.170 --> 00:02:28.610
智能确实能带来实打实的工程

00:02:28.610 --> 00:02:29.120
增益。

00:02:29.120 --> 00:02:31.730
但这里需要一个清晰的边界判

00:02:31.730 --> 00:02:31.920
断。

00:02:32.440 --> 00:02:35.090
Fugu 提升的是“流程的可靠性”和“任

00:02:35.090 --> 00:02:37.640
务的广度”，而不是“特定领域知识

00:02:37.640 --> 00:02:40.380
的深度”。在长上下文召回或某些

00:02:40.380 --> 00:02:42.550
需要极度细致的文本理解场景

00:02:42.550 --> 00:02:42.840
下

00:02:42.840 --> 00:02:45.570
底层模型的原始能力依然是瓶

00:02:45.570 --> 00:02:45.840
颈。

00:02:45.840 --> 00:02:48.860
所以，对于一个架构师来说，判断

00:02:48.860 --> 00:02:51.490
点在于：你的项目，更需要一个“

00:02:51.490 --> 00:02:53.740
大而全”的单一模型提供的深度

00:02:53.740 --> 00:02:54.160
理解，

00:02:54.160 --> 00:02:56.660
还是更需要 Fugu 这种“灵活、可替换”

00:02:56.660 --> 00:02:59.280
的协同生态提供的流程可靠性？

00:02:59.800 --> 00:03:01.970
如果你是在构建复杂的、多步骤

00:03:01.970 --> 00:03:03.160
的 Agent 工作流，

00:03:03.160 --> 00:03:06.000
那么 Fugu 这种“工作流驱动”的思维，

00:03:06.000 --> 00:03:08.800
是目前绕开单一模型性能天花

00:03:08.800 --> 00:03:09.920
板的关键路径。

00:03:09.920 --> 00:03:12.810
如果你是决策者，第一步的实践

00:03:12.810 --> 00:03:15.510
不应该去比它的通用推理得分，

00:03:15.510 --> 00:03:17.320
而应该找一个需要 Thinker、

00:03:17.320 --> 00:03:20.080
Worker、Verifier 三个角色协作的复

00:03:20.080 --> 00:03:21.720
杂代码修复任务

00:03:21.720 --> 00:03:24.930
跑一遍 Fugu。重点验证它的协调逻

00:03:24.930 --> 00:03:27.800
辑是否能有效避免逻辑错误和

00:03:27.800 --> 00:03:28.200
幻觉。

00:03:28.720 --> 00:03:31.080
这是一个从“模型能力”到“系统架

00:03:31.080 --> 00:03:32.280
构”的思维转变。

00:03:32.280 --> 00:03:34.740
在你的项目中，最难协调、最

00:03:34.740 --> 00:03:37.500
容易出现逻辑错误的 AI 任务是

00:03:37.500 --> 00:03:38.080
什么？