主题
MiniMax M2.7：当"自我进化"撞上"现实墙"——一个技术老兵的深度吐槽
一台"拉屎超快的机器"，产出速度惊人，但你需要花大量时间去清理它留下的烂摊子。
3月18日，MiniMax发布了新一代旗舰模型M2.7，宣称实现了**"模型自我进化"**——能连续执行100轮"分析-改进-验证"循环，在内部评测中提升30%效果。
听起来很美好，但对于像我这样被M2.5坑得怀疑人生的人来说，这些宣传词就像相亲网站上的照片：看的时候很心动，见面的时候想报警。
一、MoE架构：看似聪明，实则"装聪明"
MiniMax 2.5采用了稀疏混合专家（MoE）架构，总参数2300亿，听起来吓人，但每次推理只激活100亿参数。
这就像一个号称"懂八国语言"的翻译，实际上每次只动用一个脑区。
问题来了：
为了那"快"，你得把所有专家都装进显存里——VRAM占用跟一个230B的稠密模型差不多。你花钱买了个"豪车"，结果发现它只跑得快，拐不了弯。
更致命的是**"专家坍缩"问题**。MoE的路由机制天生不稳定，训练时容易出现某些专家被疯狂调用，另一些专家在摸鱼甚至彻底失业的现象。
这导致模型整体表达能力受限——你以为你有230B的知识储备，实际上可能只有50B在真正干活。
二、工具调用：Agent场景的灾难现场
作为Agent开发者，我需要模型能稳定地调用工具。但MiniMax的表现在这里简直是车祸现场：
- API错误报告
native_tool_calling: true，导致Agent发送OpenAI风格的工具JSON，结果MiniMax API直接返回500内部错误 - 这就像你明明说的是普通话，对方非要理解成方言，然后怪你没说清楚
更离谱的是工具调用ID不匹配问题——通常与会话上下文损坏有关。
在多轮对话的Agent任务中，这种问题会像病毒一样扩散：一个工具调用失败，整个状态机就废了。你在Claude Code或OpenCode里跑复杂任务，MiniMax经常在第三轮就突然"失忆"，开始胡言乱语。
三、速度的代价：快，但是错得也快
MiniMax号称100 token/秒的生成速度，确实快。
但快有什么用？
- 用户反馈M2.5生成飞行棋游戏，棋子能飘出格子
- 写复杂后端逻辑，Java并发锁的处理一塌糊涂
- 我的实际体验：它生成代码的速度确实令人惊艳，但调试它生成的代码所花的时间，比我自己写还长
这本质上是MoE架构的**"训练-推理差异"问题**。训练时受限于专家容量，不是所有token都能分配到最优专家，导致后面的token可能被"放弃"。
推理时这种"前缀偏差"会放大——模型对开头的内容记得很清楚，越往后越放飞自我。
四、知识容量的硬伤
有用户直接指出：MiniMax 2.5的"知识容量相对有限"。这不是错觉。
MoE架构虽然总参数大，但每个token只接触一小部分专家。如果某个领域的知识恰好分布在那些"摸鱼专家"身上，模型就会表现得像个门外汉。
这就像一个图书馆号称藏书百万，但你每次只能进入一个阅览室——而且还不一定是对的那个。
五、M2.7的自我进化：听起来像PPT工程
M2.7宣称的"自我进化"听起来很科幻：模型能参与自身训练、优化和迭代。
但仔细想想，一个基础能力都不稳定的模型，如何保证"进化"方向是对的？
这就像让一个不会开车的人自己改装汽车——可能改出个变形金刚，更可能改出个废铁。
SWE-Pro基准56.22%的成绩，确实接近领先模型了。但跑分和实战是两回事。就像驾校考试满分的人，上路可能还是不会倒车入库。
结语：不是所有MoE都叫Claude
MiniMax的核心问题在于：它试图用架构创新（MoE）来弥补基础能力的不足。
MoE确实是提升效率的好工具，但它不是万能药。
Claude Opus 4.6和GPT-5.4之所以强，不是因为它们跑得快，而是因为它们**"想得深"**。
MiniMax给我的感觉，就是一台**"拉屎超快的机器"**——产出速度惊人，但你需要花大量时间去清理它留下的烂摊子。
对于需要稳定输出的Agent开发者来说，这种"快但不可靠"的模型，还不如"慢但靠谱"的 alternatives。
M2.7会不会改变这一切？也许会。
但在它真正在实战中证明自己之前，我选择保持谨慎——毕竟，被同一块石头绊倒两次，是智障；被同一块石头绊倒三次，那就是真爱了。