【AI前沿】对话 MiniMax 择因：Agent 终会超过人类，我们又将何去何从？

Agent 的世界，四月还是山雨欲来。五月尚未结束，已然血雨腥风。整个行业的加速快到不讲道理。Vibe Coding 已经不再是新名词，编程这条赛道也从未如此拥挤：Claude Code、Codex、Cursor 贴身肉搏，Trae、Qoder、CodeBuddy 杀成一团。黑话一个接一个流行起来，支配所有人的注意力。去年还是 skill（技能）的天下，如今 harness（脚手架）站上了王座。热词之下，模型已经卷到几近一条平直的线：不同的基准测试会给不同的答案，但总体来说，无论是 Opus、GPT，还是 Qwen、GLM、Kimi 和 MiniMax 们，无论是写代码还是执行越来越复杂的任务，都已不在话下。模型之间仍然存在差距，但拉开模型公司之间真正差距的，早已不再是模型本身，而是套在外面的那层壳。之前一份研究报告拆解了 Claude Code 泄露的代码，发现真正属于模型决策的代码只有 1.6%，剩下 98.4%，全是管权限、管上下文、兜错的 harness。为了进一步发挥模型的优势，全新一代的 agent 产品如排山倒海而来。Grok Build、Qoder 1.0、TRAE SOLO 纷纷推出。连一直以来低调沉默的 DeepSeek 都挂出多岗位招聘，组建 agent 开发队伍。早于业界布局 agent 的 MiniMax，在混战中落下自己的子。桌面端产品先是在 5 月中推出主打全新多 agent 编排架构的 Agent Team 功能。而随着 M3 旗舰模型，MiniMax 桌面端全面升级为 MiniMax Code，再次搅动了大厂、小龙云集的 agent 市场。Agent Team 的内核是一套 Leader-Worker-Verifier（领导-执行-验证）的「对抗式」架构。负责干活和负责挑错的职责，被拆成不同的 agent，受到经过代码逻辑固化的状态机去管理，彼此之间上下文隔离。这味药，治的是长程 agent 任务中那些出了名的顽疾：上下文污染、上下文焦虑、agent 之间的「共谋」。有趣的是，正如前述 MiniMax 并没有等 M3 发布，而是率先在 M2.7 上就将 Agent Team 推了出来。M2 这一代，被 MiniMax 称为「大巧若拙」，模型和脚手架之间的共融共生已经看到了黎明前的曙光。预料之中，M3 只会更强。近日 APPSO 与 MiniMax Agent  研发工程师择因（周淳辅）做了一场对谈。我们聊了  Agent Team 的设计原则及其所体现的 MiniMax 认知，探索了 Agent Team 的技术内核，浅析其它玩家对于 agentic 模型如何约束与放任。业界有一种观点正盛：Anthropic 拥有最好的模型和最烂的工程。在择因看来，Anthropic 骨子里不信任模型，预设模型会作弊、耍小聪明，于是到处加以约束。OpenAI 的 harness 核心却是一个极简的 agentic loop。一个极简框架养出了遵循度极好的模型，一个约束极强的框架却养出了「黑天鹅」。MiniMax 做 agent 的思路，既将两者融合，又不完全相同：要相信模型，给它和人一样的操作权限，但也要在脚手架中加入合理的约束。这些思路在业界独树一帜，但业界追赶新东西并将之确立为共识的节奏，早已快过于新思想诞生的速度。在 agent 上，MiniMax 没有壁垒——没有任何人有。择因发给我一篇 71 页的论文，告诉APPSO：「关于 agent 的所有东西，都在这篇论文里了。如果一篇就能说清楚，还有什么壁垒？」但 MiniMax 仍有绝活。他们力求以最快的速度不断向整个行业输出新的认知，做共识的领导者、执行者、验证者——这也是为什么 Agent Team 及其背后架构没等 M3，就公之于众了。究其根本，中国模型公司的「开源」玩法不会一直持续下去。但这并不代表，优秀的认知不应该及时与世界分享。就像一个 agent 的工作会有它的停止条件，开发 agent 的人们也有停止的那一刻。对于择因，可能会是当 agent 可以实现真正的自进化，并且在几乎任何数字或物理世界的任务上效率和成本优于人类。从站在第一线的他的视角来看，我们离那个未来并不遥远。以下是 APPSO与 MiniMax Agent 研发工程师择因的对话。卖个关子：在最后我们提出了一个开放性的问题，并获得了意想不到的答案。架构即认知APPSO：Agent Team 为什么没等 M3，直接在 M2.7 上就发布了？择因：不用非等到和新模型一起发，是我们的意愿，也是自己的节奏，就是希望不停地把最新的认知传达给外界，这件事情很值得做。以及它在我们内部已经使用很久了，一个月的时间，我们觉得可以对外发布了。APPSO：今天一切的周期都变得很快，一个月已经很久了。择因：发布时我们模型还没迭代，但是有一批核心用户对我们的 agent 的运行范式感兴趣，所以我们提前发出去吸引他们。核心用户的建设对我们来说非常必要。后面我们也会考虑把我们的 Agent Team 架构开源出来。APPSO：MiniMax Code 到目前为止的反馈如何？择因：这次把订阅逻辑理顺了，订了 token plan 就能用 agent。一个多月下来，下载和订阅量有一个比较可观的增长。这其实很有意思，因为如果只是提供 API 的话，用户用模型的门槛高，使用效果也不是最佳。MiniMax Code 能让大家直接感受到模型的完全体，这也是我们一直以来的思路，这一次被验证了，我觉得很好。在 M3 上只会更好。用户方面有个比较有意思的点，因为我们是全模态，发现很多用户拿 Agent Team 去做长视频生成，有古文爱好者用它来生成大量的诗朗诵音频。这些偏 C 端、兴趣向的使用案例，其实我们没有预料。很多用户也告诉我们，当 Agent Team 被整个拉起来开始干活的感觉，给他们带来很大情绪价值。APPSO：真的像是有了几个员工给自己打工的这种感觉？择因：对。总体上看最近两个月的多 agent 产品，已经是血雨腥风。腾讯那个 (Marvis)「打工」感更强。很明显，在 Agent Team 的共识和落地方面，大家跟的都很紧。APPSO：你说有人用 MiniMax Code 做视频，会不会以后可以不用专业视频生成工具，不用懂脚本、分镜、首尾帧，直接用 agent 调用全模态模型就能做视频了？择因：首先明确一下，我说的是偏个人用户、爱好的角度做视频，我觉得是可行的。专业的视频制作，其实让一个 Agent Team 去做， 跑通打个样可以，但如果真的投入工业生产，还是需要分工。比如编导负责 idea、分镜、首尾帧这些关键的东西。给到另一帮人负责丢给海螺或 Seedance 抽卡。但我认为随着模型能力提升，抽卡这部分的成本，以及后续剪辑的成本，会降得非常低。我们调研了一下，发现今天让剪辑师剪视频其实比 AI 便宜。甚至市面上有一种服务，他把抽卡和剪辑都打包了，但价格主要是抽卡的成本，剪辑反倒不花钱。实际上他们找了一堆大学生上课学剪辑，交学费，课程任务就是给我把视频剪了。APPSO：如果更强的模型出来，比如 M3，能比人工剪辑还便宜吗？择因：我们的模型在能力上可以。但是你要算账的话，还是我刚说的套路，人的成本也会越来越低。APPSO：MiniMax Code 的 Agent Team 架构，也就是 Leader-Worker-Verifier，听上去很合理，你们先做出来，然后 Claude Code 也跟进了。择因：我们是从三月开始做的，一开始我和边上同事讨论，一个 agent，它一旦做错了，在上一轮轨迹里面它永远会记得自己做错了这件事。但转念一想，它如果接下来按对的方向去做，其实这段做错了的记忆它是完全不需要的，对不对？基于这个想法，我们设计了这个新的架构：让干活的和负责验证的 agent 之间分开。验证的时候要有打回的机制，并且要让一个新的「脑子」去打回。当月我们就把这套架构搭出来了，不过目前那个时候是主要内部使用，大家用得非常不亦乐乎。APPSO：你们内部用的爽点具体是什么？是解决了之前的痛点，还是效率高、更不容易出错？择因：我举个最简单的例子，比如你睡觉前给它派个任务，哪怕是极度复杂的工作，只要你卡控的够严格，你的准出标准可量化、可观测，而不是模型自己觉得可以就可以了——只要你做好这些门禁，这群 worker 和 verifier 就能在你睡觉的时候一直跑，睡醒之后就干完了。可以说三月开始，这种新的开发节奏、新工作方式，就在我们内部出现了。APPSO：这和传统依赖提示词的多 agent 编排的本质区别是什么？择因：本质区别是我们的 Agent Team 架构做了一套复杂的自由度限制。首先运行层面它是一个状态机，是确定性的代码，有严格的限制，它不能跳出这套规范，你可以把它理解为一个更严格的工作流 (workflow）。在 agent 基建的层面，我们又给了极大的自由度。所有的 agent 之间都可以互相通讯，这和传统的 agentic workflow，有方向的流程图是完全不同的。当然，以前的 workflow 里面也可以带循环，但是核心还是这步走完了下一步。我举个例子，比方说你用 agent 做开发，环境里少了某个包导致开发受阻，过去的 workflow 上可能就卡住了，而我们的 worker 或 verifier 发现了之后，它可以通过多种健全的机制通知其它 agent 别踩坑。再比如一个研究类的任务，一开始的研究计划需要 leader 做些初步研究，过去 leader 分配完任务就停止了。但在我们架构下，如果用户有新点子、补充想法可以直接说，leader 能随时启动、去打断当前的 agent team、加一个新编排进去。Agent 工作流可以随时调整，剩下的重活都交给模型就行了。以及大家知道强化学习逻辑下会出现「上下文焦虑」，当上下文过长模型就不想干活了——不干活就不犯错嘛。而我们这套逻辑让它更严格遵循编排，持续工作直到达到准出标准。APPSO：你们如何让模型同源的 agent 实现对抗，避免共谋？择因：答案很简单，还是提示词。2026 年的大多数模型遵循能力足够强，提示词变得更可用。我们也会做一些提示词上的「雕花」行为，更重要的是给模型可观测的停止条件，让 worker 和 verifier 分别管理一些事情，比如 worker 的停止条件就是把活干完了，verifier 的停止条件是在干完的活里找到 bug。APPSO：我的使用体验，有时候觉得可以交付了，但 agent 还在打过来打回去。你们怎么定义 agent 之间的对抗强度？太宽松肯定不好，太严格会无限循环。择因：我们不会假定所有的用户生产场景，所以先把这套框架抛出来，用户可以自己去定停止条件。至于怎么定，可以通过 Skill，让 agent 根据用户对停止条件的倾向主动总结成 skill，下次运行任务就可以作为判断标准。这个 skill 肯定是千人千面的，不是我们来概括。随着用户长期使用，agent 会越来越懂用户。我们在 M3 训练中也加入了类似数据，让模型具备主动性，去总结之前的轨迹，根据用户的反馈去提炼 skill，让工作更加可观测。随着模型能力提高，我们可以做得越来越多。APPSO：MiniMax Code 的一大特点就是 agent 之间上下文隔离，很反直觉，你们是怎么想的？择因：agent 上下文分为三部分：用户请求、环境里的生产资料、模型执行轨迹。比如当 agent 执行出了错，会把犯的错记下来，但这个记录对另一个 agent 可能是有害的。当上下文变得臃肿，这些轨迹一定会污染别的 agent。长程 agent 任务跑出几个小时后，几乎全部的上下文都是执行轨迹，所以我们要隔离这一部分上下文。做这个设计就是因为我们预期 agent 会运行很久，既然大部分的信息都是不需要的，为什么不隔离？APPSO：同时执行几个任务，通过微信、飞书跟 MiniMax Code 查询也不会「串台」，这个体验很独特，是怎么做到的。择因：你