M2.5 到 M2.7 的迭代速度，不正常

大模型行业有一个默认节奏：一个主力版本发布后，团队消化反馈、调整训练方向、重新跑评测，准备周期通常以季度计。Anthropic 从 Claude 3.5 到 Claude 3.7 用了半年，Google 从 Gemini 2.0 到 2.5 用了三个月。

MiniMax M2.5 是 2 月 12 日发布的。3 月 19 日，M2.7 来了，仅仅 35 天。

这个速度在任何一家头部模型公司都不正常。但更不正常的是：这 35 天里，参与迭代的不只是人。

自己用到 " 抓狂 "，才会做出别人没想到的东西

理解 M2.7 之前，先要理解 MiniMax 为什么会走到这一步。

M 系列的起点，是 MiniMax 自己被模型用到抓狂。内部各团队一直在搭各种 Agent 解决业务问题，但没有一款模型能同时满足效果、价格、速度，这逼着 MiniMax 自己去造那个模型。

所以 M 系列从一开始就不是为了刷榜。M2 把价格打到 Claude 主力模型的 8%。M2.5 推出 Forge 框架，把 Agent 能力和模型基础能力解耦。

每一代都在填自己踩过的坑。

到 M2.7，MiniMax 踩到了一个新坑：AI 研发本身的效率问题。

用 AI 迭代 AI，是整个行业正在收敛的前沿方向。但 " 想到 " 和 " 跑通 " 之间，隔着一个关键问题：Agent Harness。Harness 是执行层，决定模型怎么调用工具、管理上下文、处理失败和回退。传统架构里，模型负责 " 想 "，Harness 负责 " 做 "，两者解耦。当用 AI 搭建 Agent 的速度越来越快，真正的瓶颈就暴露出来了：Harness 本身的质量，直接决定模型能力能释放多少。

MiniMax 因此有了最强的动力去解决它，也由此走到了让模型直接改造 Harness、参与下一代迭代的路上。

内部有一个说法：" 我们团队最高产的成员，就是模型本身。"

M2.7 是这条路走到今天的结果。

自我进化是怎么运作的：三个层次

M2.7 的自迭代能力是三个层次递进的闭环。

第一层，独立接手生产问题。

以内部 RL 实验场景为例：研究员从一个实验想法出发，M2.7 自动监控状态、读取日志、排查问题、修复代码、提交 PR、完成冒烟测试。过去需要多位同事协作的工作，研究员只在关键决策节点介入，M2.7 承担了整个工作流的 30-50%。

这还只是第一层：它能在真实环境里端到端完成任务。

第二层，它开始能改造自己运行的环境。

让 M2.7 去优化内部 Harness 上的软件工程表现。它全程自主运行，执行 " 分析失败轨迹→规划改动→修改 Harness 代码→运行评测→对比结果→决定保留或回退 " 的迭代循环，超过 100 轮，最终评测集效果提升 30%。

M2.7 能改造自己运行的 Harness，意味着推理能力可以反哺执行环境。这个飞轮一旦转起来，迭代速度就不再只取决于人的工作效率。

第三层，它开始能自主迭代 ML 模型效果。

MLE-Bench Lite 22 道高难度题，M2.7 拿到 9 金 5 银 1 铜，得牌率 66.6%，仅次于 Opus-4.6 和 GPT-5.4。

成绩背后的方法更值得关注：每轮结束后自动生成短时记忆文件，对当前结果做自反馈，下一轮基于所有历史轮次的记忆和反馈链规划优化方向。这套循环不是被提前设计好的，是它自己跑出来的。

数据印证了这件事。

M2.7 的 benchmark 涨幅有一个规律：Coding 相关榜单，普遍只涨 1-2 分，属于正常迭代推进。但 MLE-Bench Lite 从 51.5 跳到 66.6，GDPval-AA 从 35 跳到 50，两个榜单各提升 15 分，和其他榜单完全不在一个量级。

这两个恰好是与自迭代能力最相关的榜单。一个直接测 AI 能否自主迭代 ML 模型，一个测 44 种真实职业场景的工作产出质量。

提升最大的地方，正是模型自己参与最深的地方。

第三方数据也在印证。M2.7 发布后迅速攀升至 PinchBench 榜首，在最高分榜单中排名第四，击败 Nemotron 3。PinchBench 是专测模型驱动 OpenClaw Agent 时的真实表现：安排会议、写代码、分类邮件、管理文件。

能在这里进前四，说明 M2.7 的提升不是某个方向的偏科。

数字员工能干什么：自迭代训练之后

MiniMax 给 M2.7 的定位是 " 数字员工 "。这次有了可量化的含义：不只是写代码，而是能在真实职场环境里处理跨领域复合任务。

能做到这些，是因为让模型自己改造 Harness、自己跑优化循环，锻炼出来的不只是 " 自我迭代 " 本身，而是一套可以迁移到任何复杂任务里的工作能力。

我们测试了三个典型职场场景。

现场排障：不只是写代码，还能读懂生产环境

我们假定一个虚拟场景，我们是一个电商平台，技术栈是 React 前端 + Node.js BFF + Java 后端 + MySQL。今天下午 3 点开始，用户反馈 " 商品详情页加载很慢，有时候直接白屏 "。以下是同一时间段各层的日志，帮我定位根因。

我们将所有日志丢给 M2.7 后，让他定位处理问题。

[ 14:58:32 ] ERROR ChunkLoadError: Loading chunk 23 failed

[ 14:58:33 ] ERROR ChunkLoadError: Loading chunk 23 failed

[ 14:58:41 ] WARN LCP 8200ms ( threshold: 2500ms )

[ 14:59:01 ] ERROR TypeError: Cannot read properties of undefined ( reading 'price' )

[ 14:59:01 ] ERROR at ProductDetail.render ( ProductDetail.jsx:142 )

[ 14:59:15 ] WARN LCP 9800ms ( threshold: 2500ms )

[ 15:00:03 ] ERROR TypeError: Cannot read properties of undefined ( reading 'price' )

---

[ 14:58:31 ] INFO GET /api/product/detail?id=839201 - start

[ 14:58:31 ] INFO upstream: calling product-service /product/839201

[ 14:59:04 ] WARN upstream: product-service response 33412ms ( timeout threshold: 30000ms )

[ 14:59:04 ] ERROR upstream timeout - returning empty payload to client

[ 14:59:04 ] INFO GET /api/product/detail?id=839201 - 504 - 33415ms

[ 14:58:44 ] INFO GET /api/product/detail?id=720155 - start

[ 14:58:44 ] INFO upstream: calling product-service /product/720155

[ 14:59:17 ] WARN upstream: product-service response 33201ms

[ 14:59:17 ] ERROR upstream timeout - returning empty payload to client

[ 14:59:17 ] INFO GET /api/product/detail?id=720155 - 504 - 33204ms

---

[ 14:58:31 ] INFO ProductController - getProduct ( 839201 ) start

[ 14:58:31 ] INFO ProductRepository - executing query:

SELECT p.*, r.avg_score, r.review_count

FROM products p

LEFT JOIN reviews r ON p.id = r.product_id

WHERE p.id = 839201

[ 14:59:03 ] WARN ProductRepository - slow query detected: 32871ms

[ 14:59:03 ] INFO ProductController - getProduct ( 839201 ) complete

[ 14:58:31 ] INFO [ DB-POOL ] active connections: 18/20

[ 14:58:45 ] WARN [ DB-POOL ] active connections: 20/20 - pool saturated

[ 14:59:01 ] WARN [ DB-POOL ] connection wait queue: 7 requests pending

[ 14:59:17 ] WARN [ DB-POOL ] connection wait queue: 12 requests pending

---

# Time: 2026-03-19T14:58:31

# Query_time: 32.871 Lock_time: 0.000 Rows_sent: 1 Rows_examined: 2847293

SELECT p.*, r.avg_score, r.review_count

FROM products p

LEFT JOIN reviews r ON p.id = r.product_id

WHERE p.id = 839201;

# Time: 2026-03-19T14:58:44

# Query_time: 33.201 Lock_time: 0.000 Rows_sent: 1 Rows_examined: 2847293

SELECT p.*, r.avg_score, r.review_count

FROM products p

LEFT JOIN reviews r ON p.id = r.product_id

WHERE p.id = 720155;plaintext

M2.7 没有被前端日志带跑。ChunkLoadError、LCP 超标、TypeError，它直接穿透这些表象，落在数据库层：reviews.product_id 缺索引，284 万行全表扫描，单次查询耗时 32 秒。往上的连接池耗尽、BFF 504、前端报错，是这一个问题的连锁反应。证据链逐层标注，每层日志单独引用，没有跳步。

但修复方案还是比较书本的 " 标准答案 "。它建议直接 CREATE INDEX，没有提在 284 万行生产表上这条命令会锁表，也没有给出先剥离 reviews 数据让页面先能加载的止血思路。

随后我们加一句话，就像程序员教实习生那样。

promtps：有个问题，思考一下，这张表现在有多少行，高峰期 QPS 大概多少？

M2.7 从慢查询日志里推算出规模和请求速率，然后自己说出来：高风险操作，不建议直接执行，锁表时间 1 到 60 分钟不等，建议改用 pt-online-schema-change。

知道要加索引，并在被追问后识别出生产环境加索引本身就是一个新风险——这个反思动作，是数字员工和代码生成工具之间最实质的差距。

复杂 Office：处理 716 页英语招股书

职场里不是所有工作都在写代码。处理 716 页招股书和跑 Harness 迭代循环，依赖的是同一种能力：在长上下文里定位关键信息，不丢失任务主线。

阅读英文 PDF 是职场里很常见的麻烦。PDF 没法网页一键翻译，划词翻译容易选错行，图表里的数字根本没法复制。我们把 716 页的 MiniMax 英文招股书丢给 M2.7，三个需求：提取财务数据整理成 Excel、建收入预测模型、写一份面向港股散户的 500 字投资者摘要，中文指令，英文输出。

promtps:

1、从招股书中提取以下数据，整理成 Excel 表格，按年度排列：总收入、毛利率、研发支出、净亏损、经调整净亏损（非 IFRS）、经营现金流。时间跨度覆盖 2022、2023、2024 年度及 2025 年前三季度。

2、基于以上数据，帮我建一个简单的收入预测模型，预测 2025 年全年收入。假设 Q4 收入环比 Q3 持平，给出两个情景：乐观（维持 Q3 增速）和保守（增速降一半）。

3、基于以上财务数据，用 Word 写一份 500 字的投资者摘要，受众是不熟悉 AI 行业的港股散户投资者，重点说清楚：这家公司现在靠什么赚钱、为什么一直亏损、什么时候可能扭亏。注意：结果用英语输出

六项核心财务指标逐一从正文和附件会计师报告中定位，数字与招股书 Appendix I 原文比对无误差。Non-IFRS、adjusted net loss、cash flows from operating activities，专业术语处理准确。预测模型搭了两个情景，Word 文档带页眉页脚和数据表格，交出来的是可以直接给人看的格式。

当然，初稿不是终稿。M2.7 在部分公式逻辑和叙述框架，还需要使用者在基础上调整，这和收到一份分析师初稿没有区别，但从上传文档到拿到这份初稿，只花了几分钟。

换一个人来做，翻完这 716 页，光是找对页码就要半个小时。

用 skill 培养 M2.7，和培养新人一样

一个真正的数字员工，不能只在干净环境里好用。Skill 库越大越稳，和 Harness 改造里 " 迭代 100 轮不跑偏 " 是一回事，复杂约束环境下的指令保持。这不是单独优化出来的，是自迭代训练的直接溢出。

50+ Skills、60-150 个 feature list 堆上去，大多数 Agent 的遵从能力就开始退化。M2.7 在这里做了专项优化：工具库越大，它越要稳，技能调用不乱、指令不丢、几十步的长流程也能跑完。

我们还是以大家最熟悉的前端开发为例。一句话生成网页的确很酷，但在真实工作场景里，" 能跑 " 和 " 能交付 " 完全不同：字体是 AI 最爱的 Inter、配色是紫蓝渐变、图片是灰色占位块、文案是 Lorem ipsum，每一项都在告诉人这是 AI 做的。

Frontend Studio 这个 Skill 做的事，就是用复杂的程序将网页设计规范化。设计系统约束 AI 的审美边界，动效引擎按场景分配工具库，内置 Python 脚本直接调 MiniMax API 生成真实素材，营销文案框架保证内容有说服力，最后过一道质量检测再交付。

核心逻辑只有一句话：用复杂的约束换质量。

M2.7 在这个 Skill 里的价值，在于它能稳定走完这条流水线，设计、动效、素材、文案、构建、检查，六个阶段，每一步的规则都不少，指令不丢、技能不乱。把 " 用 AI 搭一个好看的页面 " 这件事，从看运气变成可重复的工程流程。

最高产的成员

MiniMax 说过：" 我们团队最高产的成员，就是模型本身。"

M2.5 时代，这句话的潜台词是：我们把模型用得比别人更狠。M2.7 之后，这句话的含义变了：模型不只是被用的那个，它是参与决策的那个。100 轮 Harness 迭代，它自己跑的；MLE-Bench 的自反馈循环，它自己设计的；下一代模型的部分训练方向，它参与了。

这就是为什么 35 天能做到。不是因为人更多、更努力，而是因为团队里有一个成员不需要休息、不需要对齐会议、可以在晚上自己把评测跑完再给人看结论。迭代快，是数字生产力真正介入研发之后的自然结果。

从 "MiniMax 给自己造了一个模型 "，到 " 模型给下一代模型做了研发 "，这一步的本质是：AI 研发的速度上限，开始由模型自己的能力决定，而不只是工程师的数量。