Poolside 凭借他们的 Laguna 系列模型起步良好。他们刚刚发布了最新开源权重编码代理 Access 2.1，这是一个拥有 330 亿总参数的混合专家模型，但每个令牌仅激活 30 亿参数。它原生支持推理能力，在工具调用之间进行思维链思考，拥有 256k 上下文窗口，并专为代理式长周期编码工作而设计，而这正是我们在这段视频中要测试的内容。我是 Fad Miraza，欢迎订阅我的频道。我最近还启动了一个免费的每周 AI 通讯，您可以在 fadm.substack.com 订阅。让我们直接进入正题。我将使用 Hermes 代理，在第一个测试中，我将简单地设置一个新配置文件，然后将模型提供商设置为自定义。
我要首先处理的应用程序是一个有缺陷的全栈应用，它使用呼叫中心仪表板。例如，如果我在这里用 ls 搜索，它会报错，导致其他所有功能都无法工作。我在前端和后端散布了各种错误。这三个错误在前端，前端也有一个错误。我将删除这里的注释，然后给 Hermes 代理一个非常通用的提示，让它查找并修复这些错误。这是我的模型正在运行。现在让我给出提示，这是一个需要通过查找并修复所有错误来实现的目标。
在它处理代码的同时，让我们谈谈他们发布的基准测试，看起来很有趣。顺便说一句，我总是对这些数据持保留态度，因为你永远不知道真相。在 SweetBench 验证中，Laguna Access 2.1 落后于 Cohere 3.6 和 Claude Haiku 4.5，尽管它的激活参数数量只是它们的一小部分，但它击败了前代产品 Access 2.0。更大的故事在于多语言支持，它相比 Access 2.0 有了显著飞跃，Poolside 特别指出这是头条改进。
在 TerminalBench 上它表现挣扎，远远落后于 3.6 和各种其他模型，甚至落后于 GPT-5.4 Nano，这使得这个代理测试变得有趣，因为终端自主性正是 Hermes 现在要求它具备的能力。基准测试在某种意义上很有趣，看起来相当诚实。它说它修复了所有这四个错误，从外观上看相当不错。但现在让我们去浏览器中验证该应用程序。
我只是在这里用 ls 或任何客户进行搜索。我按下回车键，现在它工作了，查询已解决。让我们快速检查一下记录呼叫，幕后实际上运行着一个数据库，顺便说一句，如果你对 SQLite 感兴趣的话。我只是随机选择一些值，然后记录一个呼叫。呼叫已记录，对象是 David，让我们看看仪表板。现在看起来相当不错。
你还可以在这里尝试不同类型的代理。你可以看到其他代理现在可见了。所以我认为第一个测试它做得相当好。对于第二个测试，让我们在 HTML 文件中进行模拟。这是一个难题。我要求你为我创建一个单一的自包含 HTML 文件，模拟以下电影场景：从空中无人机视角垂直俯瞰平静的深海洋面，然后各种球体从天空落下，在水中形成彩虹。
这里应该有物理效果，应该有软件工程，还有许多其他事情发生，然后它应该生成这个 index.html。让我们看看它生成什么。在它运行时，让我们再多谈谈这个模型，因为他们也发布了这篇非常精心撰写的博客。如果你仔细阅读，Poolside 完全在内部训练了这个新模型，使用他们自己的模型工厂，这是一个内部平台，处理从合成数据生成到异步自身策略强化学习的所有事情，都在他们自己的代理工具包中完成。
他们使用的优化器是 Moan，而不是 AdamW，这在生产模型训练中仍然相对罕见。架构本身是 40 层混合专家，滑动窗口与全局注意力层的比例为 3:1，Sigmoid 门控和每层旋转位置编码，KV 缓存以 FP8 运行，这也是它在本地上保持快速的原因之一。他们还训练了一个开放权重的 Deflash 推测器模型，与主权重一起，小型草稿模型在他们的测试中将本地推理的每秒令牌数加倍。
顺便说一句，你需要至少 280GB 的 H100 或 A100 来运行这个模型。但这个模型不仅仅是一个微调或简单的补丁。它是一个从头开始的代理编码模型，拥有自己的推测器生态系统，在他們自己的强化学习基础设施上训练，并以 Open Moan 1.1 发布，这是一种新的宽松许可证，专为模型工件而非软件设计。所以我认为这相当有趣。
无论如何，让我们回到我们的终端，模型已经返回了响应。它正在讨论所有关键元素和技术实现，我将向上滚动以查看它是否还做了其他事情。就文字而言，它试图匹配我的提示，这是它生成的文件。让我在你面前打开它，我们一起检查一下。好了。我认为它彻底失败了。没有海洋涟漪效果，没有球体从天空落下。物理效果非常糟糕。它只是生成一些随机的彩虹圆圈。
所以我不认为它在这里做得好。最后让我们检查多语言能力。当我们说多语言能力时，他们指的是不同的编程语言，而不是实际的人类语言。所以我在最终测试中要做的是，给它这段 Go 代码块，这有点难，因为它使用了太特定的 Go 并发机制，然后我要求它将其翻译成它在模型卡上发布的所有支持语言。
大多数目标语言没有 Go 例程和通道作为直接等价物。所以翻译可能会变得混乱。让我们看看它是如何进行的。它不仅……它真的没有那种与并发相关的难点，虽然其他模型不会使用，但仍然很难，因为它使用了带有容量提示的切片语义，而且 Java 和 C++ 需要一些泛型。所以这就是我们要在这个测试中做的。
好了，这是整个内容。我要求它将其翻译成 C、C++、Java、Rust、Ruby、PHP。让我们看看模型在这里做什么。然后它应该将结果保存到 result.txt 中。
模型返回了响应并生成了结果，我已在 VS Code 中打开。首先，Go 语言中带有容量提示的原始切片以及用于尾部的展开运算符是惯用写法，这很好。接下来是 C 语言，最为冗长且没有动态数组，因此需要 malloc，调用者必须手动释放内存。我认为模型对此处理得非常正确，所以这一项通过。
我再次滚动浏览，C++ 增加了额外负担，但模型处理得正确且干净。顺便说一句，在我看来这是最简洁的系统语言版本，不过如果你们是这些语言的程序员，我也愿意听取你们的意见。C 和 C++ 的表现相当不错。Java 方面，我认为它可行，但带有大多数人所忽略的隐藏开销，因为它被迫使用 List
但这已经是非常不错的努力了。JavaScript 的情况类似，如你所见，它相当简短。Ruby 中动态类型意味着没有容量限制，这是正确的，但与其他语言相比过于简单。TypeScript 这里也没有意外，因为它与 JS 非常相似，只是附加了类型注解。接下来是 Rust，这是最难处理正确的部分。
模型做对了，这才是真正的考验，因为它使用了切片引用、借用语义以及带有容量的 Vec，所有这些都需要精确无误。所以表现非常出色。Ruby 代码相当可读，我很喜欢它的写法，结果也是正确的。然后是 PHP，while 条件内的 count 是一个微小的效率问题，但符合 PHP 的惯用写法，相当正确。
所以我会说，所有八种语言都是正确且可运行的。Rust 和 C 是真正的验证者。如果模型能把这些做对，我认为它理解的是语义，而不仅仅是语法。所以在我看来，他们模型卡片上所说的内容相当准确。就这样。请告诉我你们对这个新模型的看法。
如果你想帮助这个频道，请成为会员。感谢大家的支持。