你有没有想过，一个由多个AI组成的团队，第一次合作完成任务的方案，往往漏洞百出？
这不是悲观，是现实。想象一下，公司新来了几个各有专长的员工，第一天就要配合完成一个复杂项目。谁负责查资料，谁负责整合信息，谁负责最后把关，这些分工在没有实际跑过一遍之前，谁也说不准合不合理。等真正干起来才发现，查资料的那个人收集的东西用不上,整合的人又漏看了关键线索。
大语言模型驱动的多智能体系统，也面临完全一样的问题。
多智能体系统*：由多个各自承担不同角色的大语言模型智能体组成的协作系统，这些智能体之间通过交流信息、分工执行子任务来共同完成一个复杂任务。
研究者们给这类系统起了个名字,叫MAS（Multi-Agent System）。它跟AutoGen、MetaGPT这些你可能听过的框架是同一个思路，用不同角色的AI分担任务，而不是让一个AI从头扛到尾。但问题来了,这些系统的工作流程,一开始是靠一个"元模型"凭空设计出来的,设计得好不好,只有真正跑一遍才知道。而跑完发现问题之后呢？
这就是今天要讲的这篇论文,Inherit-MAS,要解决的核心矛盾。
发现问题容易,但怎么改?
论文一开篇就点出了一个尴尬的事实:现在已经有不少"进化型"多智能体系统,会根据执行结果去修改自己的工作流程,听起来很美好,但实际操作起来有两个大坑。
第一个坑是改得太猛。假设一个工作流在收集证据这一步表现不错,但在整合答案这一步翻车了。如果你为了修整合步骤,把检索策略也一起改了,很可能把本来表现良好的检索部分也带崩了。这就好比修车的时候,发现刹车有点问题,结果师傅把整个底盘都给拆了重装,顺手还把好好的变速箱也动了一刀。等装回去,刹车是修好了,变速箱却出了新毛病。
第二个坑是算得太重复。每次改动之后,要不要把整个系统从头跑一遍？如果每次微调都要重新执行所有步骤,那些没有被改动过的部分,其实是在白白浪费计算资源,就像你修改了一篇论文的某一段话,结果Word非要把全文每个字都重新渲染一遍。
论文作者从达尔文的进化论里找到了灵感。生物进化靠两个机制撑着,一个是遗传,把有用的特征传下去;一个是选择,把不利的变异淘汰掉。遗传给了进化"记忆",选择替进化"筛选方向"。这个洞察被直接搬进了多智能体系统的设计里,于是就有了Inherit-MAS这个名字,直译就是"继承式多智能体系统"。
那在2024年之前,这个领域里表现最好的几个方案是什么水平？论文选取了四个对照系统做基准测试,其中EvoAgent靠进化算法从一个专家智能体扩展出整个团队,EvoMAS靠突变和交叉保留优秀配置,TacoMAS把快速能力更新和慢速结构进化结合起来。而在WorkBench这个模拟真实办公场景的测试集上,这三个进化型系统的完成率全部低于一个最朴素的单智能体ReAct方案(41.5%)。EvoAgent只有33.8%,EvoMAS只有30.8%,TacoMAS也只有34.6%。换句话说,这些号称"会进化"的系统,反而比不进化的单打独斗选手还差了将近10个百分点。这不是反直觉的噱头,这是论文里实打实的实验数据。
ReAct*：一种让语言模型在推理和行动之间交替进行的智能体范式,模型先思考下一步该做什么,再调用工具去做,再根据结果继续思考,这里作为没有元模型、没有进化、没有执行继承的参照系统。
Inherit-MAS到底是怎么运作的
整个系统的运转可以拆成五个步骤,论文里给出了一张清晰的流程图,我把它翻译成人话讲一遍。
### 第一步,先搭个初始班子
系统接到任务后,会先调用一个"元模型"(论文中用的是GPT-5.4-mini),根据任务的具体要求,设计出第一版工作流程。这个流程被表示成一张有向图,图上的每个节点就是一个具体的工作智能体,节点之间的连线代表信息怎么传递。
元模型*：负责设计和修改工作流程本身的大语言模型,它不去直接完成任务,而是去安排哪个智能体做什么、谁给谁传递什么信息、谁能用什么工具。
这第一版方案执行完之后,会产生输出结果、完整的执行轨迹（谁说了什么、调用了什么工具）、以及一份token消耗账单。
### 第二步,找个裁判打分
接下来登场的是一个"判官"角色，同样由大模型担任（论文用的也是GPT-5.4-mini,但用的是单独的提示词,和设计流程的那个角色区分开）。这个判官看着执行轨迹和最终输出,打出四项分数:完成可能性、需求覆盖度、证据扎实程度、整体质量,同时写一段文字点评,指出哪些节点干了实事,哪些节点在打水漂。
这里有个设计很巧妙,判官能看到每个节点具体产出了什么,所以它的点评可以精确到"某个具体节点没有贡献有效证据",而不是笼统地说"这次做得不好"。这就像老板不是简单给你的团队打个总分,而是逐个点名,告诉你张三的方案很扎实,但李四那部分内容压根没用上。
### 第三步,工作流继承:选择留谁,改哪一处
这是整篇论文最核心的机制。从第二轮开始,系统不会从零设计新方案,而是以上一轮完成的最新候选方案作为"起点"（论文里称之为incumbent，也就是"现任者"）。
这个起点经过两个阶段的操作。第一阶段叫Select,元模型会根据裁判的点评,判断哪些节点是可以拿掉的,但有一条硬规矩,只有那些拿掉之后整个工作流依然合法有效的节点,才允许被列入拿掉的候选名单。而且元模型被明确要求,只有当证据表明某个节点毫无贡献甚至在拖后腿的时候,才可以把它删掉,其他节点一律原样保留,角色、提示词、工具权限、输入接口统统不变。
第二阶段叫Edit,系统会从一个预先设定好的编辑菜单里,选出一处改动,针对裁判诊断出的具体问题。这个菜单包括修改某个节点的提示词、修改它负责的子任务、调整它能用的工具、增删节点或连线、调整输入顺序,或者在两个已经连接的节点之间插入一个新节点。关键的限制是,每一轮只允许做一次经过验证的改动,而且这个改动必须落在"保留下来的那部分工作流"之内。
论文里举的例子特别形象。假设工作流里有四个节点,一个判官发现其中一个"干了无用功",于是先把它拿掉,再发现原本两个节点之间缺了一步证据整合,于是在它们中间插入一个新节点。整个过程像是公司调整部门结构,先裁掉一个确实没干活的岗位,再根据业务需要加一个新岗位,而不是把整个部门推翻重建。
如果你把这个过程类比成装修房子,会更容易理解它的分量。假如你家厨房的水管漏了,正常的做法是把漏水的那一段管子换掉,其他已经装好的瓷砖、橱柜、电路都不动。但如果采用"大改"的思路,一旦发现漏水就把整个厨房全部砸了重装,代价是什么？不仅瓷砖白贴了,橱柜白装了,连带原本好好的电路也可能在施工中被碰坏。工作流继承的Select加Edit机制,本质上就是坚持"只换漏水的那一段管子"。
### 第四步,执行继承:别把没变的部分再算一遍
修改完工作流之后,新方案要重新执行一遍。但这里有个讲究,不是每个节点都要重新算。
执行继承的核心逻辑是,先判断某个节点有没有被这次改动直接或间接影响到。论文里把直接被改动的节点,以及它们下游所有能够通过有向边到达的节点,划归为"受影响区域"。而剩下的节点,结构上完全没动。
但光是结构没动,还不够资格直接偷懒复用上次的结果。系统还要做一次更严格的核对,把这个节点当前要执行的"完整请求"算出来,这包括它自己的具体指令、它所有上游输入的完整记录、以及执行环境的指纹(涵盖运行时版本、初始环境状态、工具服务版本等)。只有当这个完整请求通过哈希校验,和之前存储的某条记录一字不差地匹配上,系统才会直接把存好的结果拿来用,而不去重新调用模型或工具。
哈希校验*：把一段内容通过固定算法(论文中用的是SHA-256)转换成一串独一无二的数字指纹,只要内容有任何微小差异,算出来的指纹就完全不同,因此可以用来快速判断两段内容是否完全一致。
这个设计有个很重要的细节,受影响区域里的节点也不是必然要重新执行。如果某个节点虽然处在受影响区域内,但巧的是它这次要处理的请求,跟之前某次存下来的请求刚好完全一样,系统依然会直接复用那次的结果。反过来,结构上没动的节点,如果它的输入因为上游变化而发生了改变,系统也绝不会偷懒,会乖乖重新执行。
这套机制如果换成生活场景来理解,很像你每天通勤路上会不会重新规划路线。假设你平时上班走固定路线,某天得知某个路口在修路,正常思路是重新规划那段绕路的路线,前面和后面没受影响的路段完全不用动。但如果你是个特别谨慎的人,哪怕只是某一个路口施工,也坚持把整条路线从家门口到公司重新算一遍,这样做唯一的后果就是浪费时间,因为大部分路段根本没变。执行继承要解决的,正是这种"该省的地方别浪费"的问题。而且更严谨的地方在于,它不是简单地说"这段路没动过就直接用老结果",而是去验证"这段路现在走起来的具体情况,跟我上次记录的情况是否完全一致",这避免了表面上没动,实际上条件已经变了却被误判为可以复用的风险。
有一类操作是绝对不允许偷懒复用的,那就是会改变外部环境状态的操作,比如发邮件、写数据库。论文里专门设计了一个"只读节点可以继承,写入节点必须每次都活跃执行"的规则,整个系统里只有一个指定的"执行节点"被允许做这种状态改变的动作,其他节点都只能读取环境,不能修改。这个安排也很好理解,存档复用的前提是复用这个结果不会产生副作用,一旦涉及真实世界里不可逆的动作,就必须每次都认真对待,不能图省事。
### 第五步,从所有候选方案里挑一个最好的交卷
系统设定了总共K次候选方案的尝试上限(论文实验里是5次,一次初始生成加四次改良)。每次改良出来的新方案,只要成功跑完并拿到了有效的判官打分,就被归入"已完成候选池"。
最后,系统不会简单地认为"最后一次改的肯定最好",而是从所有已完成的候选方案里,按照一套明确的排序规则挑出最优的一个:先看谁的执行错误最少,再看谁的输出格式有效,再比谁的总体质量分、需求覆盖分、证据扎实度分更高,如果还打平,就选更早生成的那个。
这个设计的好处是,万一第四轮改坏了,系统也不会因为"按时间顺序排到最后"就强行采用它,而是能退回去用第二轮或第三轮那个表现更好的版本。论文专门用数据验证了这点,如果直接返回"最后生成的那个候选方案",在WorkBench上完成率是50.0%,但用这套排序规则挑选之后能提升到55.4%。这说明候选方案本身不是单调变好的,排序机制起到了实实在在的补救作用。
实验结果:到底好在哪儿
论文在两个基准测试集上验证了Inherit-MAS,一个是WorkBench(模拟邮件、日历、项目管理、客户关系管理、数据分析这些真实办公场景,按最终环境状态打分),另一个是HotpotQA的FullWiki版本(需要跨多篇文档进行推理,还要给出支撑证据的具体句子)。
workbench*：一个模拟真实职场环境的测试集,衡量AI智能体能不能真正把邮件发对、日程排对、数据库改对,而不只是说得好听。
HotpotQA*：一个要求跨多篇维基百科文章进行推理问答的测试集,FullWiki版本意味着模型要自己从海量文档里检索证据,而不是直接给出相关段落。
以下是两个基准测试在GPT-4o-mini作为工作智能体时的核心表现对比:
| 系统 | WorkBench完成率 | HotpotQA联合F1 |
|---|---|---|
| Single ReAct(参照) | 41.5% | 46.0% |
| EvoAgent | 33.8% | 34.8% |
| EvoMAS | 30.8% | 39.2% |
| TacoMAS | 34.6% | 47.8% |
| **Inherit-MAS** | **55.4%** | **49.7%** |
这个表格里最扎眼的地方是,除了Inherit-MAS,其他三个"进化型"系统在WorkBench上全部跑输了什么都不改的Single ReAct。这不是说进化这个思路本身错了,而是说明"怎么进化"远比"要不要进化"更重要。Inherit-MAS比表现最好的TacoMAS高出整整20.8个百分点,这意味着每5个任务里,Inherit-MAS能比TacoMAS多做对一个。
换成Qwen3-32B这个开源模型做工作智能体,结论依然成立。Inherit-MAS在WorkBench上拿到46.2%,和Single ReAct打平,但依然比最好的进化型基线高出11.5个百分点;在HotpotQA上更是比Single ReAct高5.6个百分点,比TacoMAS高2.8个百分点。
而且这些成绩不是靠疯狂堆算力换来的。论文算过一笔账,EvoMAS和TacoMAS在WorkBench上分别用了Inherit-MAS总token量的16.8倍和22.9倍,在HotpotQA上则是13.7倍和2.1倍。也就是说,Inherit-MAS是在花更少钱的情况下,干出了更好的活。
进化真的在变好吗?不是单调上升的
论文还做了一件挺实诚的事,它没有只报喜不报忧,而是把每一轮改良之后的真实表现画成了曲线图。结果显示,WorkBench上原始候选方案(初始方案、第一轮、第二轮、第三轮、第四轮)的完成率依次是46.2%、51.5%、48.5%、42.3%、50.0%,根本不是一路涨上去的,第三轮甚至还跌了。HotpotQA上也是类似的起伏,44.7%、46.2%、47.4%、45.9%、44.4%。
这组数据其实揭示了一个很朴素的道理,工作流进化更像是依赖历史的搜索过程,不是教科书里那种稳步爬坡的"梯度下降"。有的改动方向是对的,有的改动可能用力过猛反而退步了,这跟公司调整组织架构一样,有时候一次改革反而把事情搞复杂了,得靠后面几轮再修正回来。
正因为单次改动不保证一定变好,排序机制挑选最优候选方案这件事才显得格外重要。论文把这套排序规则应用到每个前缀(只看前1轮、前2轮……前5轮里最好的那个)之后,返回的候选方案得分从来没有下降过,最终在WorkBench和HotpotQA上分别达到55.4%和49.7%。而如果有一个全知全能的"上帝视角"去挑选候选池里理论上最好的那个(论文称为oracle),WorkBench上限其实能到63.1%,HotpotQA能到56.3%。这个差距说明,现在这套靠大模型充当的判官,还不能百分百精准识别出哪个候选方案才是真正最优的,这是留给未来改进的空间。
省下来的计算资源,到底省了多少
执行继承到底值不值得搞得这么复杂？论文专门做了一个对照实验来回答这个问题,把执行继承功能关掉,让每个节点都强制重新执行一遍,其他一切(判官、编辑菜单、检索预算)全部保持不变,看看结果会差多少。
数据相当直观。在WorkBench上,关闭执行继承之后,工作智能体消耗的token从144万涨到203万,涨幅41%(反过来说,开着继承功能省了29.1%)。在HotpotQA上更明显,从360万涨到550万,省了34.6%。
如果你把总的token消耗(包括元模型和判官的部分)也算进去,WorkBench的整体节省幅度是5.3%,HotpotQA是18.1%,看起来不如工作智能体那部分省得多,这是因为元模型和判官这部分计算,不管继承功能开不开,都得照常跑,它只能省掉工作智能体那部分的重复劳动。
更有意思的是,关闭执行继承、让每个节点全部重新跑一遍之后,WorkBench的最终完成率依然是55.4%,跟开着继承功能时一模一样。这个结果其实验证了执行继承这套机制的设计初衷,它只是在省钱,不会牺牲最终质量,因为复用的前提是请求内容和执行环境完全一致,这意味着复用出来的结果和重新算一遍得到的结果,理论上应该是等价的。
论文团队为了验证"存起来的旧结果"真的能够取代"重新算一遍",还专门在一个完全可控的本地环境(用Qwen3-14B模型跑LiveCodeBench编程题,这个环境的计算过程是完全确定可重复的)里做了测试。结果是,完全重新执行、带结果仓库的全量校验、以及改动定位加结果仓库这三种方式,产出的每一个节点的输出和打分,逐字节完全一样,而后两种方式的token消耗只有完全重新执行的17.7%。这个专门设计的对照实验给执行继承的可靠性提供了实打实的证据支撑。
从哪里省下来的钱,论文也拆解得很细。改动最集中发生在"修改提示词"这类编辑上,这类改动在WorkBench和HotpotQA里分别能继承47.3%和75.0%的token等价量。这很符合直觉,如果你只是改了某个节点说话的方式,那上游传给它的信息完全没变,只要这个节点自己重新算一次就够了,它上游那些节点压根不用重新跑。
这就像一个翻译团队,如果你只是让其中一个翻译员换一种更正式的措辞风格重新翻译某一段,原文内容不需要重新审阅,前面负责校对原文的同事完全不用重复劳动。但假如你连翻译团队的分工都重新打乱了,那基本上大家都得从头再来一遍。
这个方法目前还有哪些没解决的问题
论文也相当诚实地披露了几个局限。
有一类叫"重启"的操作,也就是当连续几轮改良都没能让质量分明显提升时,系统会放弃渐进式修改,让元模型基于历史最佳方案和反馈重新生成一个完全不同的工作流。这类重启占到WorkBench已完成改良轮次的15.7%,HotpotQA的15.6%。重启虽然能带来较大的改进空间,但代价是几乎没法复用之前存下来的任何结果,因为整个结构都变了。论文的数据显示,在重启轮次里,平均要消耗4000多个工作智能体token,而局部编辑的平均消耗只有几百到一千多token。
另外论文还做了个很细致的统计分析,想看看"改动范围局部"和"改动质量好"这两件事是不是正相关。结果发现并不是。真正带来效果提升的改动里,只有大约三成是严格局部的改动,剩下七成改动其实波及了很大一部分工作流结构。这说明省钱的局部性和改得好不好,其实是两件相对独立的事,局部编辑是省钱的保证,但不是质量的保证。
写在后面
读完这篇论文,最触动我的其实不是那些完成率数字,而是作者选择"达尔文式"的隐喻来命名整个系统这件事本身。遗传和选择不是对立的两种机制,而是互相配合的,遗传负责不丢掉已经验证过的好东西,选择负责决定哪些变异值得保留下来。这种思路放在AI系统设计上,其实是在提醒我们一件容易被忽视的事:进化不等于推翻重来,真正的进化往往是克制的,是在大部分东西不变的前提下,小心翼翼地改一处。
论文里那个"候选方案完成率并非单调上升"的数据,其实挺值得单独拿出来咂摸一下。很多人对"迭代优化"的直觉想象是一条稳步爬升的曲线,但现实中的改良轮次里,第三轮反而比第二轮差了6个百分点。这提醒我们,任何靠反馈驱动的自我修正系统,都得搭配一套"记住历史最佳,不被最新结果绑架"的机制,否则很容易在某一步走偏之后,一路偏下去都没发现。这不只是AI系统设计的问题，人在做任何需要持续迭代改进的事情时，大概都适用同一个道理。
论文还留了一个没细说但挺耐人寻味的空白,判官给出的四项打分,到底能不能真正代表任务做得好不好,这件事本身其实没有一个客观标准去验证。判官自己也是一个大语言模型,它打出来的分数本身也可能带着偏差。这个"用AI评判AI"的套娃结构,会不会在某些场景下系统性地偏向某一类错误,这个问题论文没有展开,留给了后续研究。
Q&A
Q1：Inherit-MAS是什么？
A：Inherit-MAS是一种多智能体系统的测试时进化方法，核心思路是让AI工作团队在每次改进时继承上一轮里被判定有用的部分，只对诊断出问题的地方做一处验证过的修改，同时对没有变化的计算结果直接复用，避免重复计算。
Q2：Inherit-MAS相比其他进化型多智能体系统有什么优势？
A：在WorkBench和HotpotQA两个测试集上，Inherit-MAS的完成率和联合F1分数都超过了EvoAgent、EvoMAS、TacoMAS，而且消耗的token远少于后两者，同时执行继承机制能节省29.1%到34.6%的工作智能体token消耗。
Q3：执行继承会不会影响最终任务的完成质量？
A：不会。论文做了对照实验，关闭执行继承让每个节点全部重新执行后，WorkBench最终完成率依然是55.4%，和开启继承功能时完全一致，说明省下来的只是重复计算，不牺牲结果质量。
