Inherit-MAS:通过工作流与执行继承实现多智能体系统的测试时演化
基于大语言模型构建的多智能体系统（MAS）通过协调专用 agent 处理复杂任务，但有效的工作流难以预先设计。测试时演化 可利用执行反馈改进工作流，然而大范围修改会破坏有用组件，重复执行未变化的请求又会带来冗余计算。 受生物演化中继承与选择相互作用的启发，本文提出 Inherit-MAS，在工作流与执行两个层面将继承显式化。一个 meta-model 先合成由 worker agents 组成的工作流，并声明其角色、通信输入与工具权限；另一个独立 prompt 的 judge 对每个已执行候选打分并诊断其缺陷。在常规精炼轮次中，工作流继承从最近完成的候选出发，可丢弃被判定为无用的可移除节点，并施加经过验证的编辑以修复诊断出的缺陷。 当新候选执行时，执行继承仅在完整解析后的请求与执行上下文匹配时，才继承符合条件的已存储结果，从而避免冗余的模型与工具调用。 实验中，使用 GPT-4o-mini workers 时，Inherit-MAS 在 WorkBench 上取得 55.4% completion，在 HotpotQA FullWiki 上取得 49.7% joint F1，优于 EvoAgent、EvoMAS 与 TacoMAS；使用 Qwen3-32B workers 时，在两个基准上也超过这些 evolving-MAS 基线。与禁用执行继承、重跑同一 controller 相比，执行继承使 worker token 用量在 WorkBench 上减少 29.1%、在 HotpotQA 上减少 34.6%，总 token 用量分别减少 5.3% 与 18.1%。
论文精读
TL;DR Inherit-MAS 将生物进化的继承与选择机制用于多智能体系统测试时优化：工作流继承保留有效节点、丢弃无用节点并定向修复缺陷，执行继承复用匹配结果，在 WorkBench 和 HotpotQA 上超越现有进化基线，同时显著降低 token 消耗。
问题
问题背景
多智能体系统（MAS）利用大语言模型（LLM）驱动多个专用智能体协作解决复杂任务，但预先设计有效的工作流十分困难。测试时演化（test-time evolution）通过执行反馈迭代优化工作流，成为近期热门方向。
现有方法局限
现有演化方法如 EvoAgent / EvoMAS / TacoMAS 通常在每轮对工作流进行较大幅度的重写，缺乏对历史候选结构中有效组件的显式保留机制，导致有用节点被破坏。同时，新候选执行时，未变化的子请求仍会被重新执行，造成大量冗余的模型调用和工具调用，增加 token 成本和延迟。这些方法没有区分“可继承”与“需重新探索”的部分，演化效率较低。
为什么难/重要
工作流搜索空间离散且庞大，每个候选工作流的执行成本高，如何平衡探索新结构与利用已有反馈是核心挑战。显式继承机制需要解决两个技术难点：一是工作流层面判断哪些节点可安全保留、哪些应丢弃；二是执行层面精确匹配请求和上下文，避免错误继承导致结果污染。业界对多智能体系统的部署成本和稳定性高度关注，减少重复计算、加速迭代是生产落地的关键需求。
行业类比
类似 AI 客服多智能体系统的线上优化：每次用户反馈不应触发全流程重新生成和所有工具重新调用，而应像增量构建流水线一样，只更新受影响的步骤并复用未变化的中间结果。
核心洞察
- 工作流继承将测试时演化限定为“从最新完成候选继承结构 + 丢弃无用节点 + 应用经过验证的编辑”，避免全量重写破坏已经有效的协调模式。相比 EvoMAS / TacoMAS 更倾向于整体变异或重新生成工作流，Inherit-MAS 的显式选择与保留机制让搜索更聚焦于诊断出的局部缺陷，减少无效探索，同时保持对有用组件的稳定继承。
- 执行继承以“完整已解析请求 + 执行上下文”匹配为条件复用存储结果，消除演化循环中跨候选的冗余模型与工具调用，而不是简单缓存相同请求。实验显示，在 WorkBench 和 HotpotQA 上，执行继承使 worker-token 使用分别下降 29.1% 和 34.6%，total token 下降 5.3% 和 18.1%，为测试时演化提供了可落地的算力优化路径。
方法
Inherit-MAS 的输入为自然语言任务请求，输出为最终工作流及对应执行结果。其核心流程如下：
初始合成与判断：由元模型一次性合成一张由多个 Worker Agent 组成的工作流，每个 Agent 显式声明角色、通信输入和工具权限。同时，一个独立提示的 Judge 对每次执行的候选工作流进行评分，并诊断其具体缺陷（如某节点冗余或某步推理不足）。
工作流继承：在每轮细化中，新候选从上一轮完成的候选出发，而非从零设计。首先执行节点继承：丢弃被 Judge 判定为无用的可移除节点，保留有效结构；随后进行编辑继承：针对诊断出的缺陷提出一个编辑操作（如增删节点、修改依赖），并经过验证后应用到工作流上。
执行继承：当新候选实际执行时，对每个需要调用模型的步骤，先检查是否已有可复用的历史结果。只有当“完整已解析请求”和“执行上下文”完全匹配时，才继承存储结果；否则重新执行。这避免了相同子请求的重复模型或工具调用。
排名与返回：所有候选按 Judge 评分排序，选择最优工作流及其输出作为最终结果。
与 EvoAgent、EvoMAS、TacoMAS 等同类演化方法的差异在于：Inherit-MAS 将继承显式区分为工作流级与执行级，通过节点级丢弃和条件结果复用，既减少了无差别大改对有效组件的扰动，也大幅降低了冗余计算成本。
实验
实验设计叙述：在 WorkBench 和 HotpotQA FullWiki 上评估 Inherit-MAS，使用 GPT-4o-mini 与 Qwen3-32B 作为 worker，对比 EvoAgent、EvoMAS、TacoMAS 等演化式多智能体基线，评估任务完成率、联合 F1 及 token 成本，并消融执行继承。
关键发现：Inherit-MAS 在 GPT-4o-mini 达到 55.4% WorkBench completion 与 49.7% HotpotQA joint F1，Qwen3-32B 同样超越基线；执行继承使 worker-token 减少 29.1% 于 WorkBench 与 34.6% 于 HotpotQA，total token 减少 5.3% 与 18.1%，且随 refinement 轮次持续提升。
对比解读：相比基线采用全局工作流修订，Inherit-MAS 显式继承工作流与执行结果，能够保留有效组件、复用匹配请求的执行，避免冗余计算，这是性能超越基线的关键。
行业影响
落地场景
Inherit-MAS 适合动态工作流 的测试时优化：如电商智能客服（订单查询、退换货、物流跟踪等多步骤 Agent 协作）、企业知识库检索增强问答、金融研报自动生成 等。在 workflow 需根据反馈快速调整的场景，不用每次从头合成，通过继承上一轮工作流和可复用执行结果，加速迭代。
商业价值
主要降本线：execution inheritance 在 WorkBench 和 HotpotQA 分别减少 worker-token 29.1% 和 34.6%，总 token 成本下降 5.3% 和 18.1%，直接降低 LLM 调用成本。同时 completion/F1 提升带来任务完成率提高，减少人工兜底，间接增收。对需频繁跑演化搜索的产品，能显著减少重复推理。
与现有产品/工作流的接口
可嵌入已有 multi-agent framework（如 LangGraph、AutoGen）作为 controller 层：工作流被建模为节点图，Inherit-MAS 的 meta-model 作为演化控制器，judge 输出结构化评分与诊断。执行层增加结果缓存与条件继承，需存储“完整解析请求 + 执行上下文”，匹配成功才复用，避免错误继承。
具体 use case：电商售后 Agent 中，退换货流程遇到新政策时，workflow inheritance 保留大部分节点只改政策判断节点；execution inheritance 复用用户信息查询结果，避免重复调用 CRM 工具。
局限
- **基准覆盖有限**：实验仅在 WorkBench 和 HotpotQA FullWiki 两个基准上进行，任务类型分别偏向软件工作流编排和多跳问答。对于更复杂的开放域推理、多轮交互或需要实时工具调用的场景，继承机制的有效性未得到验证。此外，两个基准均以静态离线评分为主，缺少对在线环境或动态反馈的测试，泛化能力存疑。
- **继承条件严格，可能限制收益**：执行继承要求完整的 resolved request 与 execution context 完全匹配，这一严格条件可能导致存储结果命中率偏低，尤其是在任务请求存在细微变化时。工作流继承中节点丢弃和编辑验证依赖于 judge 的评分与诊断，若 judge 本身存在偏差或错误，可能误导继承方向，造成性能波动。
- **系统复杂度与调参成本较高**：相比 EvoAgent、EvoMAS 等单一进化策略，Inherit-MAS 引入工作流继承和执行继承两套机制，涉及节点选择、编辑家系、继承资格判定等多个超参数和提示设计。论文未报道对这些超参数的敏感度分析，实际部署时可能需要额外调参工作，且 meta-model 和 judge 的额外 LLM 调用也会增加一定的延迟与成本。