Laguna M.1

1. 它不是代码聊天机器人，而是要自己把任务跑完

Laguna M.1 的设计重点不是帮你补几行代码，而是让 Agent 接到任务以后继续往下做。

比如给它一个终端任务，它可以先分析需求，再修改代码、执行命令、检查结果、修 bug，然后继续迭代。

真正耗钱和耗时间的地方也在这里。

普通代码助手可能只调用一次模型。Agent 跑一个完整任务，后台很可能调用很多轮，还要不断接收终端结果。

这也是为什么 Laguna M.1 的长上下文和工具调用能力，比普通聊天能力更重要。

Poolside 还配套提供了终端编程 Agent “pool”，以及云端开发环境 “Shimmer”。

他们不是只做一个模型，而是在尝试把模型直接放进完整的编程执行链路里。

2. 编程成绩不错，但不是榜单第一

Laguna M.1 在主流编程基准上的表现，已经属于开源模型里比较强的一档。

SWE-bench Verified 得分 74.6%，SWE-bench Multilingual 是 63.1%，SWE-bench Pro 为 49.2%，Terminal-Bench 2.0 则是 45.8%。

拿 DeepSeek-V4 Flash 做参照，对方在这四项上的成绩分别是 79.0%、73.3%、52.6% 和 56.9%。

所以 Laguna M.1 的位置其实很清楚：已经很强，但还不是所有编程 benchmark 都能压过头部模型。

对实际开发来说，我反而不太在意这几分差距。

如果模型放进你自己的代码库后，能少失败一次完整任务、少让工程师人工接管一次，价值往往比 benchmark 高 3 个点更直接。

更何况 Laguna M.1 现在还能免费试，没必要只看榜单做判断。直接拿真实 issue、真实仓库和终端任务跑一遍，答案会更有参考价值。

3. 256K 上下文，省下的是“代码到底给它看哪些”

256K 对编程 Agent 的价值，不是“能塞很多字”这么简单。

真正麻烦的是大型代码库。

上下文小的时候，一个 Agent 不可能一次看到所有相关文件。你得先检索，再判断哪些文件值得送进去；改完一个模块以后，又可能发现依赖藏在另一个目录。

最后经常变成：模型还没开始真正解决问题，外面已经写了一堆代码，专门负责挑文件、切上下文、补历史。

256K 不能让这些问题全部消失，但至少能让 Agent 同时看到更多相关代码。

跨文件重构、追调用链、理解配置和测试之间的关系时，这个差别很实际。

少漏一个关键文件，就可能少跑一轮错误修改。

Laguna M.1 最值得注意的其实不是 2250 亿参数，而是两个更现实的点：

它是专门为编程 Agent 做的，而且现阶段免费。

编程能力已经处在开源模型的第一梯队，256K 上下文也很适合大型代码仓库。MoE 让单次推理只激活约 230 亿参数，不需要每次都跑满整个 2250 亿。

更关键的是，你可以几乎零 API 成本地拿真实任务测试。

一个编程模型到底好不好，最难回答的问题从来不是“榜单多少分”，而是“它能不能把我仓库里的这个 bug 真修掉”。

免费阶段正好把这个验证成本压到了最低。

限制也很明确。

它只处理文本，不认图片、视频和音频；用途集中在编程 Agent，不适合拿来做通用聊天。正式收费标准还没有出来，免费能维持多久也没人知道。

本地部署也不是低门槛。

BF16 完整模型约 452GB，就算有 FP8 版本，对 GPU 和显存依然有要求。

如果你在做 AI 编程 Agent，或者正在评估自动修 bug、终端执行、代码库级任务，这个模型很适合直接拉进测试列表。

原因很简单：现在试它几乎没有 API 成本。

如果只是做普通文本问答，没必要搬这么大的模型。

需要视觉输入的项目也可以直接排除。

至于想在个人电脑上本地跑 M.1 的开发者，先看硬件，再看模型。452GB 的权重，不是换张显卡就能解决的问题。