Mavis：让两个Agent“互掐”，比一个聪明Agent靠谱

前几天看姚顺宇在张小珺最近那期4小时访谈里说，他在Google DeepMind主要做ML Coding和Long Horizon（长程任务）。后者就是让模型能够连续干好几个小时甚至好几天才能完成的复杂活。他说的是让单个AI变得更聪明。

但同样的事情，另一条路径上也在发生。这件事现在像个隐秘的共识，所有头部大模型公司都在做。

OpenAI从去年起推了让开发者搭多AI协作的工具集，又补上了让AI跑长任务的能力。Anthropic做了两套独立的产品，一套在他们的对话产品里、一套在Claude Code里的Agent Teams，都是让一个AI带一堆AI干活的架构。Google也推了开发框架，还和一百多家公司一起搞了让不同厂商的AI能互相通讯的协议。

这些公司不约而同地造同一个东西，试图回答同一个问题：长程任务该怎么靠谱地交付。

昨天MiniMax发布了Mavis（MiniMax as a Jarvis），同步出了一份相当详尽的技术报告。读完发现他们在这个问题上走得很远，有了相当成熟的解法。

所以今天想聊聊这事。

写的不审，审的不写

先讲一条我最近一个月为了让我的AI写作工作流更加Harness而调整的一条流程规则。

在我的AI写作工作流了内容写完之后一直有要求按规则审校的流程存在。但我最近改的规则是：审校必须启动一个独立的Agent，写内容的AI不审自己的内容。这条规矩贴在我所有写作项目的CLAUDE.md里。原因是踩过太多次坑。同一个AI写完一篇文章，紧接着让它自己检查，它会诚恳地告诉你「我又通读了一遍，没问题」。但它检查的对象，就是它自己刚刚构造出来的现场。

我后来把审校AI单独拎出来，写的不审，审的不写。

上面这张是我每次写完稿启动三审三校时的截图。两个审校AI被丢到后台并行跑，各自只看产出文件，看不到我和写作AI之间的过程对话；它们出意见之后由一个编辑AI合稿。整个过程从头到尾，写内容的AI不参与任何一轮审校。

读到MiniMax官方对Mavis的描述时我笑了一下。这家公司花了一整份技术报告论证一件事：别让AI当自己的裁判。他们的判断是「多Agent系统是runtime，不是prompt编排」。意思是让多个AI一起干活，关键不是给它们写更好的指令，而是给它们搭一个能长期运行、能管它们的底座。

这个底座的核心机制叫Worker和Verifier的对抗循环。一个AI干活，另一个AI找茬，两个AI心思完全相反。

我从公众号写作里踩坑摸出来的一条朴素规则，跟一家头部大模型公司从工程严谨性推出的状态机设计，落点完全一样。他们做的事比我深得多，把流程纪律做成了由程序自动调度的对抗循环。

Agent干长活，都是怎么烂尾的

要看懂为什么需要让两个AI互掐，得先看单个AI干长活的时候是怎么坏掉的。

第一个症状是「上下文焦虑」。

举我熟的场景。我用AI辅助写一篇文章时，整个流程不是一步：读brief、做多源调研、列大纲、写初稿、跑独立审校、按反馈改稿、生成配图、写小标题、做封面图、最后排版发布，前后十几步。

任何一步只要交给AI接着上一步往下走，大概率出现两种情况。要么它把十几步压成两三步草草交付；要么它每做一步就停下来问你「123已完成，要不要继续做4」。你说「继续」。它又做了两步停下来。一个晚上下来，你有一半时间在打「继续」、「继续」、「继续」。

AI对一个任务什么时候算「做完」的判断是模糊的。它不知道你的真实预期，所以干一半就停下来确认，宁可啰嗦也不冒险。

姚顺宇在访谈里讲过一个挺贴的哲学，原话是「用短的context去训练，但让它能做长的context的事」。意思是让AI在长任务里不漂移、不停下，关键不在上下文窗口做多大，而在它会不会自己管理上下文：该存的存起来、该扔的扔掉。

第二个症状更隐蔽。AI干长任务的时候，会逐步漂移。

我做橙皮书的时候踩过这个坑。让一个agent帮我写一整章AI技术解读，开头是技术分析的语气，写到第三节能不知不觉变成营销文案的口吻；让它列参考资料，它会把自己之前搜过的二手缓存当成一手来源贴上去。这时候你追问它，它会诚恳地回头自检，但它检查的对象，就是它自己刚刚漂移生成的现场。一个被自己污染过的记忆里，做不出真正的纠偏。

第三个症状是长任务期间没法快速响应你。在微信、飞书这种IM场景下，你发一条消息就期待几秒内有反馈。但很多任务天然需要几分钟甚至更久。AI要么给一个浅答案应付，要么让你盯着对话框等十几分钟。MiniMax官方文章里说，「我的Agent怎么不回我了」是他们收到的大量用户反馈。我估计很多人不管是用OpenClaw还是Hermes都感受过这种痛苦。Mavis的解法是把「秒回用户」和「执行任务」拆开：主AI收到消息先快速应一声「收到，5件事我去拆，完成后回来找你」，然后把任务派到后台并行跑，关键节点主动汇报。整个体验更接近一个能秒回微信、同时后台还在帮你干活的同事。

第四个症状最容易被忽视，是角色分工这件事其实没真正发生。

举我自己的例子。我有几十个公众号写作相关的skill：选题、调研、初稿、审校、配图。看起来分工挺细。但它们全部跑在同一个Claude里，用同一套记忆，看同一组文件。本质上还是一个AI在轮班。每「换」一次角色，前面那个角色的影子都还在。

官方公众号里有句话点得很准：「角色扮演不等于角色分工」。真正的分工得让每个AI从一开始就只做一件事，连工具集都不一样。会计用Excel，设计师用Figma，他们的工具不重叠，能力边界清晰，长期跑下来才有复利。

这四个症状加起来导致的结果就是：单AI干长任务越长越不靠谱。倒不是AI不够聪明，是结构上就出了问题。

姚顺宇还说过一句话挺到位：「Coding是AI使用工具和环境交互的一个很好的抽象。它的回馈信号清晰（运行成功或失败）、数据充分。」反过来读这句话我就明白了，写代码这种事最容易让「互相挑刺」机制跑通。因为有外部的、确定性的对错信号：代码能不能跑、测试过没过，机器说了算。在写作、研究、办公文档这些靠主观判断的场景里，光靠AI自己说「我检查过了」根本不算数。

得有个外部的东西来兜底。MiniMax选的兜底方式，就是让另一个AI来挑毛病。

Mavis较真的两件事

MiniMax在公众号文章里把Mavis和OpenAI、Google、Claude Code的同类方案做了对比。Mavis的整体架构是Owner拆任务、Worker干活、Verifier挑刺三角，但他们觉得做得最不一样的，落在两件事上。

第一件：让两个AI心思相反

Mavis架构里，Worker的目标是把活儿赶紧干完；Verifier的目标是把活儿挑回去重做。两个AI都以「结束」为目标，但一方结束会触发另一方启动。Worker觉得自己干完了，Verifier立刻开始挑刺。Verifier挑出问题，Worker被自动叫回来修。修完Verifier再检查，过了才算真的完成。

我自己写过一个叫darwin-skill的工具，就是干Verifier的活。它会读一个SKILL.md文件，从结构和效果两个维度8个指标打分，挑问题、给优化建议。但我把它做成了一个事后跑的独立工具，跟skill的生产过程是脱离的。darwin能告诉我「这个skill哪里写得糙」，但写skill的过程本身没有挑刺嵌在里面。Mavis的Verifier是嵌在生产状态机里的，每一步产出立刻挑，挑不过就自动叫回来。这一步差距很关键。

官方原话里有一句我蛮认同：「很多框架里的验证环节是可选的附加步骤，在我们这里它是架构的核心。」

这话是Mavis的设计宣言。对比一下，Anthropic在Multi-Agent Research System博客里讲的方案，是Lead Agent给Subagent分发任务并基于outcome评分，质量主要靠Lead的判断；OpenAI Agents SDK的Handoff是接力式的，A把任务交给B，B再交给C，每一棒都不回头。Mavis选了一条不一样的路：不要单中心评审，让Worker和Verifier直接对掐。

第二件：调度靠程序，不靠AI拍板

想象一个工厂流水线。工人在工位上做完一件活，按一下绿灯，活就传到检验员那里。检验员要么贴「通过」标签放行，要么贴「打回」标签让工人重做。整个流水线是机器在调度。传送带的速度、检验的时机、什么时候停下叫主管来，都不靠工人自己判断。

Mavis就是这种流水线。每个「工人」是一个AI，每个「检验员」是另一个AI，但两个AI之间不直接说话，全程靠一个叫Team Engine的程序在中间调度。这个程序不是AI，是确定性的代码。这件事很关键：它意味着系统的可靠性不依赖某个AI那一刻清醒不清醒，而是写死在程序里。

我读这张架构图的时候，觉得最关键的不是流程图本身，是几个被低估的细节：

• 任务被切成一批一批跑。同一批里的活儿真的并行，各干各的，互不打扰。下一批要不要启动，看上一批是不是全部通过验证。

• 两个AI之间不直接通讯，全程靠程序中转。Worker完成产出，程序自动把产出推给Verifier；Verifier说有问题，程序自动叫Worker重做，而且让它从上次失败的状态继续，不用从头来。这点我蛮有共鸣。我做橙皮书pipeline时这件事是手动的：哪一章审校没过，我得自己把反馈贴回去跟写章节的agent讲「之前哪里有问题、应该怎么改」。每本书十几章，手动衔接的次数不少。MiniMax把这步做成了Engine自动完成的事。

• 有重试上限。两个AI万一陷入「改改改改不完」的死循环，程序会自动把决策升级，必要时叫人类来拍板。我的darwin-skill里也做过同样的事：自动优化迭代有上限，连续几轮分数不涨就主动停下，不会让agent无限消耗token。区别是darwin的上限是给skill事后优化兜底的，Mavis把上限内建到了生产任务的运行时调度里。 ## 对照着看，我自己的skill漏在哪

写到这里我想到了不少我之前做skill设计时一些零碎思考的影子。Mavis文章里点到的几个组件，我自己各做了一两个，但没有一个像他们那样把全套打通。

第一个是开头讲的写作三审三校。写作AI写完，我自动起两个独立审校AI看产出文件，加一个编辑AI合稿。Worker-Verifier的雏形，但是流程纪律，每次手动触发，不是runtime。

第二个是huashu-book-pdf，前面讲过的橙皮书电子书skill，已经出版7本。每本书都跑了多Agent并行写章节加三审三校的流程，再构建EPUB/PDF上架微信读书。多Agent并行加挑刺这两件事我都做了，但调度是手动的，不是Engine在跑。

第三个是darwin-skill。前面讲过它干的就是Verifier的活，区别是跟生产过程脱离。它额外做了一件事，是hill-climbing（山丘攀登）式的优化：改一版、跑测试，分数涨了就保留，跌了就回滚。这是「挑刺加自动迭代」的闭环，但它的对象是skill本身，不是任务产出。

第四个是huashu-data-pro，我做数据分析的skill。收到数据先做一遍理解，然后选3到5个不同领域的专家角色并行分析，结果汇总后生成报告。我自己用的时候挺爽。但看完Mavis我意识到它有结构性缺口：我只做了拆任务和分头干，没有挑刺。多个专家各自的结论谁来核对？我设计的时候默认是用户。这意味着我把质量门禁丢给了人，没丢给系统。

把这四个放一起看，Mavis做的事就清晰了。我手里有审校的纪律、有橙皮书的并行加挑刺pipeline、有专门给skill挑刺的darwin、有多专家分头干的data-pro。每个都做对了一两件事，但全是单点。Mavis把这些拧成了同一套底座：挑刺嵌进生产过程、调度靠程序、每个AI有持续身份。

而且Mavis把每个AI做成有持续身份的「同事」。下次再开这个AI，它能记得上次干到哪里、犯过什么错。这跟我那些零散skill的差别本质上是「同事」和「工具箱」的差别。

这种「我设计漏了一环、看别人补上了」的体感，比任何架构对比都更让我信服多AI协作的核心从来不是「开几个进程」，是结构。

Agent协作的下半场，是从工具到同事

读完技术报告我自己有个判断：AI协作的下一个阶段，是把AI从「工具」变成「同事」。

工具是单次的，用完即弃，下次重新交代一遍背景。我那些零散skill大多是工具，能办事，但每次都得手动起来、手动收尾、手动衔接。

同事是有持续身份的：它知道你之前让它干过什么、犯过什么错，下一次任务能记着上次的反馈接着干。这才是Mavis做「每个AI自带身份、笔记本、记忆、交付物」这件事的本质，把AI拉进一个有历史、有积累的关系里。

跟「同事」配套的不只是记忆，还得有验收标准、可调度的流水线、可复盘的操作日志。这就是Mavis那一整套Worker-Verifier-Engine的存在意义。给AI协作搭底座比写Prompt重得多，但只有这条路才能让AI真正进入长期同事的形态。一个有记忆、有技能、有验收标准、能在长任务里复用经验的AI团队，比一个无所不能的超级指令更有用。

MiniMax官方在文末也补了一句：「Team不是默认选项，是策略选项。任务越短、越低风险、越确定，单Agent甚至脚本就够了。」

MiniMax这次顺带把订阅做了合并：TokenPlan和Agent Plan合一份，CLI、API、Agent都打通，M2.7模型、音乐、视频、语音都包含在内。Credits额度在Agent和API之间可以共享，之前同时订阅了两个Plan的用户额外送一个月会员。背后逻辑和Mavis的整体设计一致：一份用户记忆、一组技能、一套额度，在不同入口都能用。

回到开头那个观察。四家AI实验室都在朝同一个方向走，但每家路径不一样。没有谁的方案是定论，但都在补同一块基础设施。

我猜接下来一年，会看到更多人发现自己手里那些零散的「AI协作小窍门」，被一个个写进产品。

这件事我挺乐意看到。

MiniMax Mavis桌面端下载：agent.minimaxi.com/download

参考资料：

• MiniMax官方tech blog《MiniMax Agent Team - 为长程任务，持续进化而生》：https://zhuanlan.zhihu.com/p/2037877345634276836

• MiniMax官方公众号文章《一个 AI 还是不够》（Agent Team自己采访自己的Q&A版）：https://mp.weixin.qq.com/s/TIL7o92f71DsPPLWT4_37A

• Anthropic《How we built our multi-agent research system》：https://www.anthropic.com/engineering/multi-agent-research-system

• Anthropic《Managed Agents》（原话「session is not Claude's context window」）：https://www.anthropic.com/engineering/managed-agents

• Anthropic《Claude Code on Team and Enterprise》（含Claude Code Teams机制）：https://www.anthropic.com/news/claude-code-on-team-and-enterprise

• Google Agent Development Kit (ADK)官方文档：https://google.github.io/adk-docs/

• Google A2A协议规范：https://a2a-protocol.org/latest/specification/

• 张小珺访谈姚顺宇《对姚顺宇的4小时访谈：请允许我小疯一下！》（B站）：https://www.bilibili.com/video/BV1YR5E6EE9o/