Inherit-MAS让多智能体系统继承经验：进化型方案为何输给单智能体

多个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 个任务里它能比 TacoMAS 多做对一个。

把工作智能体换成 Qwen3-32B 这个开源模型，结论照样成立。Inherit-MAS 在 WorkBench 上拿到 46.2%，与 Single ReAct 打平，但仍比最好的进化型基线高出 11.5 个百分点；HotpotQA 上它比 Single ReAct 高 5.6 个百分点，比 TacoMAS 高 2.8 个百分点。

这些成绩也不是靠猛堆算力砸出来的。论文算过一笔账：WorkBench 上 EvoMAS 和 TacoMAS 的总 token 用量分别是 Inherit-MAS 的 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是什么？

Inherit-MAS 给多智能体系统提供了一条测试时进化的路子。它的做法是：让这支 AI 工作团队在每一轮改进时，把上一轮中被认定有用的部分接着用下去；诊断出毛病的地方，只动一处，而且这处改动得经过验证；至于那些没发生变化的计算结果，直接拿来复用，不再算一遍。

Q2：Inherit-MAS相比其他进化型多智能体系统有什么优势？

A：在WorkBench和HotpotQA两个测试集上，Inherit-MAS的完成率和联合F1分数都超过了EvoAgent、EvoMAS、TacoMAS，而且消耗的token远少于后两者，同时执行继承机制能节省29.1%到34.6%的工作智能体token消耗。

Q3：执行继承会不会影响最终任务的完成质量？

不会。论文里专门做了对照实验：把执行继承关掉，让每个节点都从头重新执行，WorkBench 的最终完成率还是 55.4%，跟开着继承时一模一样。可见省掉的只是重复计算，结果质量并没有因此打折扣。