MiniMax on 魔都水滴

MiniMax M3 正式发布:稀疏注意力 MSA 是什么神仙架构?顺手深扒一下 Mavis 的沙箱

Mon, 01 Jun 2026 22:00:00 +0800

6 月 1 日,稀宇科技正式发布新一代通用模型 MiniMax M3。他在编程、超长上下文和原生多模态三条科技树上同时点满,而且全球唯一开源。同一天,我顺手在 Mavis 里跑了几个小时的探索,把背后那个看不见的沙箱摸了一遍 —— 顺便把这份体验 + 这段时间的用量数据 + 一个邀请链接一起整理给你。

特别声明: 本文 100% 全部由 MiniMax-M3 撰写生成，包括全部代码段、图表设计与大纲架构，未经过任何人工修改或二次润色。

更新说明(2026-06-01 22:00):本文发布后,官方针对 Token Plan 改版又发了一版补充公告,承认此前的迁移方案在沟通和老用户限额问题上考虑不周,并给出了补偿方案和退款通道。本文末尾新增了 第九节"Token Plan 改版最新公告",正在或打算订阅 Token Plan 的朋友务必读完再下单。

一次流式响应被重复消费：NewAPI v1.0.0-rc.10 MiniMax 转发 Bug 排查实录

Sun, 31 May 2026 18:00:00 +0800

先说结论

问题现象：AI Agent 在 DingTalk 通道中回复了重复的文本。消息不是发送了两次，而是一条消息里的内容被复制了一遍。排障最终定位到 NewAPI（QuantumNous 维护的 OneAPI 分支）v1.0.0-rc.10 版本的一个流式响应 Bug：当通过 OpenAI Chat Completions 协议转发 MiniMax 模型时，finish chunk 会同时包含 delta.content 和 message.content，且两者内容完全一致。Agent 框架的流式处理器将两者都当作"可见文本"消费，导致最终文本被拼接两次。修复方案也很朴素：将 OpenClaw provider 协议从 openai-completions 切换到 anthropic-messages，OneAPI 原生支持该协议，且该路径下流式响应正常。

本文不会出现任何真实内网地址、Token、模型 ID 或私有路径。所有配置片段都已脱敏。

AI 助手为什么把一句话复读四遍：一次 OpenClaw 微信通道排障复盘

Fri, 29 May 2026 11:24:29 +0800

先说结论

这次问题看起来像“微信通道把同一条回复发了四遍”，但真正的重复发生在更早的位置：消息还没有进入微信发送层之前，OpenClaw Agent 的最终可见文本就已经被模型执行链路重复拼接了。排障的关键不是一上来改微信插件，而是把链路拆成发送层、会话层、模型路由层三段，用最小 prompt 复现，再比较“兼容网关路径”和“原生 provider 路径”的输出差异。最后的修复也很朴素：让个人 IM 通道显式走原生 provider，移除容易被误选的故障候选模型路径，重启 Gateway 后复测主会话。

这篇文章不会出现任何真实内网地址、账号、token、会话 ID、个人微信标识或私有路径。所有配置片段都已经脱敏，并用 <PLACEHOLDER> 形式表示。重点是分享一套可复用的排障方法，而不是公开某个具体环境的细节。

OpenClaw 接入 MiniMax 一个月总结：稳定、够快，真正有价值的是可持续

Thu, 19 Mar 2026 10:30:00 +0800

过去一个月，我持续用 MiniMax 作为 OpenClaw 的主模型，覆盖了日常巡检、连接排障、健康检查、安全加固、定时任务治理和博客辅助写作等一整套自动化流程。回头看，这次实践最大的收获并不是“AI 能替我做多少事”，而是我逐渐确认了一个更现实的判断：对于 OpenClaw 这类要长期运行、要和工具链打配合、还要处理大量中文上下文的系统来说，模型最重要的不是纸面能力，而是稳定性、响应速度、接入成本和长期可维护性之间的平衡。