核心观点 MiniMax核心工程负责人阿岛（缪宇航）离职，其负责的M3、Agent、Audio、海螺AI等关键研发线出现关键人物空缺，公司正处于重押Coding和Agent的战略阶段 离职事件 - MiniMax Agent工程部主管阿岛（缪宇航）飞书状态显示离职，下一站未公开[2] - 阿岛在X上的个人认证信息尚未更新，简介仍为Head of Engineering[4] - 其负责业务横跨MiniMax当前最关键的几条研发线：M3.x、Code、Audio以及海螺AI[4] - 阿岛多次代表团队对外解释技术路线，是MiniMax技术团队里辨识度很高的一张面孔[6] 阿岛职业背景 - 本科毕业于北京邮电大学，2009年加入百度担任Team Lead & Senior Engineer，负责广告反作弊后端架构[12] - 2014年转投贝壳，先后担任大数据架构师、研发总监[13] - 2018年加入字节跳动，担任西瓜视频技术负责人[13] - 2023年7月加入MiniMax，Title为Head of Engineering（工程研发负责人）[17][20] 阿岛在MiniMax的职责范围 - 负责和参与的方向覆盖MiniMax M3.x、Agent、Audio和海螺AI[21] - 从模型工程、Harness到Agent Infra，横跨基础模型、Agent工程系统和多模态应用[5][22] - 从M2开始，其角色越来越明显地向Agent工程侧靠近[27] - 在M2系列技术报告作者名单中能找到其名字Yuhang Miao[29] - 负责将研究团队能力组织成Agent系统，塞进复杂工程环境，再推向可用产品[30] MiniMax当前战略阶段 - MiniMax定位为多模态基础模型+Agent+AI原生产品[25] - 模型侧覆盖文本、音频、图像、视频和音乐，产品侧包括MiniMax Code、MiniMax Hub、MiniMax Audio、Talkie等[26] - 5月底升级Agent Team，把复杂任务拆给多个Agent并行协作[31] - 6月初发布旗舰模型M3，主打Coding、Agent和100万Token长上下文，同时推出MiniMax Code[32] - 7月底发布第一款通用视频模型MiniMax H3[33] - 从M2.x到H3，从单Agent到Agent Team，MiniMax正把模型能力与Agent产品越绑越紧[34] 阿岛的技术观点与对外沟通 - 今年4月在量子位圆桌活动上提出：Agent时代真正需要卷的已从模型本身转向Harness[38] - 将模型比作F1赛车，同一赛车由不同人开结果相差很大[39] - 同样的模型搭配不同Harness，完成任务的Token消耗可能差出数倍[40] - 认为今天被当作Agent产品壁垒的Skill、Workflow和Harness能力，未来可能被模型内化[42] - 将工程师搭建Harness形容为一种“蒸馏”——把工作方法、经验和判断蒸馏成Skill和代码交给Agent重复执行[43] - 去年5月在小红书发布AMA问答笔记，收到近400条留言、1000多个点赞[46][49]

核心观点 - 行业正从评估单一模型转向评估复杂AI系统，需要一种全新的评测范式，即从静态指标（Metric）转向可执行的评测系统（Harness）[3][6][35] - MirroS联合清北、Berkeley、MIT、xbench、英伟达等机构发布HarnessEval，旨在为评测系统本身建立一套可规划、可调用、可验证的工作流[3][4][35] - 评测系统应具备理解、规划、调查和验证的能力，最终输出可追溯的证据树（evidence tree），而不仅仅是分数[10][19][28] 为什么需要Harness - Agent的最终能力不等于底层模型能力，还包括上下文管理、工具调用、记忆、任务拆解、执行环境、权限管理和结果验证等组件[2] - 决定Agent能否稳定完成复杂任务的是这些组件能否被组织成一套稳定、可执行的工作流系统[2] - Harness描述的正是这一层负责规划、协调与验证的系统层能力[3] 传统评测的局限性 - 传统benchmark依赖固定评测流程：一组测试数据、一套固定rubric、若干指标和聚合分数[9] - 不同案例真正需要检查的问题不同，统一Rubric要么覆盖过全面包含无关检查，要么简化后遗漏关键判断[9] - 传统评测方式适合边界清晰、答案确定的任务，但Agent与交互式生成系统不再是一次性的输入输出映射[8] - Agent可能读取文件、检索网络、执行代码、传递状态、拆解长期任务、调度多个sub-agent[8] HarnessEval的核心机制 - 评测智能体首先理解案例上下文与评测意图，再从可复用的Skill Library中选择适用技能[14] - 每个高层问题被拆解为可测量的子问题，交给不同的sub-agent或诊断工具执行[14] - 主智能体验证返回证据是否充分、各项判断是否真正回答了原问题，最后完成聚合与评分[14] - 整个过程分为四个阶段：Plan（先理解案例再决定测什么）、Route（选择适用技能而非跑完所有指标）、Decompose（把抽象判断拆成可验证证据）、Verify（先审计证据再交付分数）[16][17][18] - 最终输出一棵完整的evidence tree，记录测了什么、为什么要测、调用了什么工具、找到了什么证据，以及这些证据如何支持最终结论[19] HarnessEval-W：世界模型试验场 - HarnessEval首先落地于交互式世界模型，因为评估生成世界比判断文本正确性困难得多[25] - 一段视频可能画面精美却执行错误动作，完成眼前变化却遗忘整个场景，产生合理运动却违反接触关系、速度变化或因果顺序[25] - 现有自动化评测往往只能粗粒度衡量画面质量、运动流畅度或文本匹配度，难以回答涉及交互、时序与因果的问题[25] - Mirros开源HarnessEval-w，从观测质量、状态转移正确性和世界持续性三个维度组织评测[25] - 每个Skill被拆解成一系列更容易被验证、被解释的子问题，例如检查目标是否真实存在且清晰可见、变化是否发生在正确对象上、预期状态是否最终成立、关键场景锚点是否保持、过程中是否出现无关变化[27] - 面对物理碰撞，系统可能调用目标追踪、时间交叠验证、速度估计与因果顺序检查[27] 评测形态的升级意义 - Benchmark的核心资产将从数据与指标扩展到技能路由、工具调用、证据验证和持续生长的Skill Library[32] - 模型可以通过test-time scaling提升能力，评测器也应投入更多计算进行更深入的搜索与验证[32] - 不同任务需要不同的评测Skill，通过按需组合专业能力，Eval才能覆盖代码、搜索、机器人、世界模型等复杂场景[32] - 评测结果将从单一score走向可追溯的evidence，当系统遇到能力边界之外的问题时，应主动暴露自身的技能与证据缺口[32] - Benchmark不再是一套固定规则，而成为能够持续扩展和自我完善的living system[32] 通向RSI（递归式自我改进） - 当AI逐步走向RSI，评测就不再只是模型之外的一把尺子，而会成为自我改进闭环中的关键反馈[34] - 评测关注什么，模型就会朝什么方向优化；评测忽略什么，系统也可能在反复迭代中放大什么[34] - 没有可靠的Eval，RSI就可能失去方向[34] - 世界模型是MirroS选择的第一块试验场，也是迈向Physical RSI的重要一步[34] - 未来Eval不仅要理解上下文、规划评测、组合技能、调度工具和验证证据，还要审视自身、发现能力缺口，并与被评模型共同进化[34]