Laguna XS 2.1: Poolside's Local Coding Agent Tested - Nine Languages

模型背景与基准测试数据概览

Poolside推出的Laguna系列模型此前表现良好，最新发布的Laguna Access 2.1是一个拥有330亿总参数的混合专家（MoE）模型，但每个令牌仅激活30亿参数。该模型原生支持推理功能，具备工具调用间的交错思考能力，拥有256k上下文窗口，并专为代理式长周期编码工作设计。博主Fad Miraza在测试前指出，虽然官方基准测试数据有趣，但应保持审慎态度，因为测试结果的可信度往往难以完全验证。

"I always by the way take them with a grain of salt because you never know."

在SwissBench Verified测试中，Laguna Access 2.1的表现落后于Qwen 3.6和Claude Haiku 4.5，尽管其激活参数量仅为后者的零头，但它优于其前身Access 2.0。在多语言编程能力方面，该模型相比Access 2.0有显著提升，这是Poolside重点宣传的改进点。然而，在Terminal Bench测试中，该模型表现不佳，落后于Qwen 3.6、GPT-4o Nano等多个模型，这使得后续的代理测试显得尤为关键，因为终端自主性正是Hermes智能体所要求的。

技术架构与训练细节解析

Laguna Access 2.1并非简单的微调或LoRA叠加，而是从头构建的代理式编码模型。Poolside利用其内部平台“Model Factory”进行训练，该平台涵盖从合成数据生成到异步策略强化学习的全过程。优化器采用了MoE架构而非AdamW，这在生产环境模型训练中仍相对罕见。模型架构包含40层混合专家层，滑动窗口注意力与全局注意力的比例为3:1，并采用Sigmoid激活函数和每层旋转位置编码（RoPE）。

"The optimizer they used is Moan, not ADMW, which is still relatively rare in production model training."

为了提升本地推理速度，KV缓存使用FP8精度，并训练了配套的开放权重蒸馏投机模型（Speculator Models）。在测试中，该投机模型将本地推理的每秒令牌数（Tokens per second）提高了两倍。运行该模型需要至少280GB的H100或A100显存。模型以Open MDM 1.1许可证发布，这是一种针对模型工件而非软件的新兴宽松许可证。这些技术细节构成了其高性能的基础，但也限制了其在普通硬件上的直接运行能力。

测试一：全栈应用Bug修复实战

博主使用Hermes智能体对Laguna Access 2.1进行首次测试，目标是一个存在多个Bug的全栈呼叫中心仪表板应用。该应用在前端和后端散布了四个主要Bug，包括前端搜索功能报错导致其他功能失效等问题。博主向智能体提供了一个通用的高层提示，要求它查找并修复所有Bug，而未提供具体代码位置或详细指导。

"I'm just going to give it a very generic highle prompt in Hermes agent to find and fix these bugs."

智能体在运行过程中展示了其思考过程，最终报告称已修复所有四个Bug。博主随后在浏览器中验证了应用功能。首先测试搜索功能，输入"ls"或任意客户名，查询成功解析且无报错。接着测试“记录通话”功能，后台使用SQLite数据库，随机选择值并记录通话后，仪表板正确显示了新记录的通话信息。此外，不同智能体的可见性也正常。这表明在常规全栈应用调试场景下，Laguna Access 2.1表现良好，能够准确理解代码结构并修复逻辑错误。

测试二：复杂HTML物理模拟生成

第二次测试旨在挑战模型的创意编程和物理模拟能力。博主要求生成一个自包含的HTML文件，模拟一个电影场景：从空中俯瞰平静的深海表面，各种球体从天空落下，入水后产生彩虹效果。这需要模型同时处理物理引擎逻辑、视觉效果渲染以及软件工程结构，是一个高难度的生成任务。

"There should be some software engineering and lot of other things happening."

模型生成了代码并尝试实现上述场景，但结果完全失败。生成的HTML文件中没有海洋波纹效果，球体下落动画缺失，物理模拟极其糟糕。模型仅生成了一些随机的彩虹圆圈，未能实现球体入水、物理碰撞或彩虹折射等核心需求。博主评价其表现“彻底失败”（failed miserably），指出模型在处理复杂物理交互和视觉特效生成方面存在明显短板，无法胜任高要求的创意编码任务。

测试三：多语言并发代码转换

第三次测试聚焦于模型的多语言编程能力，特别是针对Go语言特有的并发机制（Goroutines和Channels）进行跨语言转换。博主提供了一段使用切片语义、容量提示和尾部展开操作符的Go代码，要求将其转换为C、C++、Java、Rust、Ruby、PHP等八种语言。由于大多数目标语言没有直接的并发等价物，且涉及复杂的内存管理和类型系统，翻译难度极高。

"Most target languages don't have go routines channels as a direct equivalent."

模型成功生成了所有八种语言的代码，并保存至result.txt。博主逐一审查了结果： - C语言：代码冗长，正确使用了malloc分配内存并手动释放，处理得当。 - C++：代码简洁，被视为最干净的系统语言版本。 - Java：使用List<Integer>而非基本类型int，存在隐藏开销，但逻辑正确。 - JavaScript/TypeScript：转换简单，TypeScript仅添加了类型注解。 - Rust：最难的部分，模型正确处理了切片引用、借用语义和容量提示，表现优异。 - Ruby/PHP：代码可读性强，逻辑正确，PHP中虽有小效率问题但符合惯用法。

多语言测试深度分析与结论

在多语言转换测试中，Rust和C语言被视为真正的验证标准，因为它们要求模型深入理解语义而非仅仅语法。博主指出，如果模型能正确转换Rust和C，说明其真正理解了代码的语义逻辑。测试结果显示，所有八种语言的代码均可运行且逻辑正确。Rust的借用检查和C的手动内存管理均被准确实现，证明了Laguna Access 2.1在底层系统编程和多语言语义映射方面的强大能力。

"If a model gets those right, I think understands the semantic, not just the syntax."

综合三次测试，Laguna Access 2.1在常规Bug修复和多语言代码转换方面表现卓越，特别是在处理复杂系统语言（如Rust、C）时展现了深厚的语义理解能力。然而，在创意物理模拟生成方面表现糟糕，显示出其在非结构化、高创意要求任务上的局限性。博主总结认为，官方模型卡中关于多语言能力的描述是准确的，该模型在代理式编码工作中具有特定优势，但并非全能。读者可根据自身需求，判断其是否适合长周期、多语言支持的编码代理场景。