发布日期：2026-11-04 04:40 点击次数：172
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 研发的速率上限十大正规体育平台，驱动由模子我方的智商决定，而不单是工程师的数目。
