MANTA：让多智能体的组织结构在运行时自我进化

一个反直觉的事实

你组建了一支团队去完成一个复杂项目——三个工程师、一个验证者、一个协调员，星型汇报结构。任务启动后你发现：其中一个工程师同时被分到了工具调用和事实核查两个方向，他开始出错；而验证者和工程师之间没有直接沟通通道，问题被层层转达，等到协调员发现时已经晚了。

你会怎么做？

大多数人的第一反应是换人——换一个更强的工程师，或者换一个更细的 prompt。这也是当前大多数 LLM 多智能体系统在做的事：Self-Refine 改输出，DSPy 调 prompt，CoT 重塑推理轨迹，Reflexion 积累记忆。但有一个变量被所有人忽略了：组织结构本身。

MANTA（Multi-Agent Network Topology Adaptation）的核心主张是：拓扑不是设计时的静态选择，而是执行时可以自我进化的对象。

七层自我改进金字塔

论文给了一张很有冲击力的图，把所有自我改进方法按"改进什么"排成了一个层级：

• L0 输出：Self-Refine——改答案
• L1 Prompt：DSPy、APE、TextGrad——改指令
• L2 推理轨迹：CoT、ToT、GoT——改思维链结构
• L3 技能/工具：ReAct、Voyager——改能调用什么
• L4 记忆：Reflexion、ACE、A-MEM——改记住了什么
• L5 Agent 角色：CAMEL、MetaGPT、Debate——改分工
• L6 拓扑：MASS、AFlow、ADAS、MANTA——改谁和谁说话
• L7 权重：RLHF——改模型本身

注意 L6。在 MANTA 之前，这个位置的方法（MASS、AFlow、ADAS、AgentSquare）都是离线优化——先搜出一套好的 workflow，然后执行时固定不变。MANTA 的差异只有一句话：拓扑在执行时可以被修改。

这句话听起来平淡，但它的含义很深。离线优化假设你能在任务开始前知道最优结构；MANTA 承认你不能，只能在执行中观察哪里出了问题，再做一次有界的修补。

三个零件，两次决策

MANTA 的架构是一个嵌套两层的设计。内层是目标多智能体系统，负责真正解决任务；外层是编排层（orchestration），决定内层长什么样。编排层只有三个 LLM 零件：

Topology Planner（拓扑规划器）：任务来了，它根据任务特征和经验记忆产出一个紧凑的拓扑方案——交互模式、agent 数量、是否需要验证者或嵌套子组。一个确定性代码扩展器把这个方案展开成完整的拓扑（角色、上下文策略、通信边、可见性策略），并校验所有结构约束。Planner 看不到 benchmark 身份，也没有手工设计的拓扑可参考。

Trace Auditor（轨迹审计器）：每一轮结束后，它扫描结构化的执行轨迹——工具记录、relay packets、置信度、未解决问题、证据可见性。它只看过程，不看答案对不对。它不能咨询标准答案。如果它发现至少一个可修复的中等或高严重度 flag，这次运行就被标记为"flagged"，触发修复；否则就是"clean"，直接通过。

Controller（控制器）：拿到 Auditor 的诊断后，决定是直接定稿答案，还是做一次有界的拓扑修订。修订最多一次，最多三个操作——加 agent、扩 agent、改组模式、改通信边、改信息可见性。修订后再跑一轮，再审计。

这里有一个关键设计选择：修订是有界的。 不是无限制地自我修复，而是最多一次修订、三个操作。这个约束让元层开销只占推理预算的 12%，同时仍然捕获了大部分可修复的失败。

两本笔记：短期 playbook 和长期 playbook

MANTA 的记忆分两个时间尺度。

短期 playbook 只活在一次运行内。它记录每一轮的：当前拓扑、Auditor 报告的 flag、推荐的修复、Controller 的决定。这让 Planner 知道"哪些结构已经试过了，它们产生了什么可观察的异常"——而不是只看最新状态。

长期 playbook 跨运行积累。它存储的是一般性原则——任务特征 + 过程风险 → 拓扑选择。Planner 在初始规划时和修复时都会查阅它。每 N 次运行后，一个 Skill Reflector 会从最近的执行轨迹摘要中重写它的经验教训。

这里有一个反直觉的设计：长期 playbook 的学习信号从不看 ground truth。 每次反思批次里的运行只收到一个过程派生的标签——"procedurally clean"（审计无 flag 且以决策级共识结束）。这个标签意味着"没有观察到协调异常"，不代表答案正确。标准答案只用于评估，从不暴露给 Planner 或任何 playbook。

这个设计避免了"用答案训练过程"的常见错误。MANTA 学的是"什么样的拓扑在什么任务上不会产生过程异常"，而不是"什么样的拓扑能蒙对答案"。

四种失败，四种修复

论文里的四个 case study 是这篇文章最值得读的部分。它们不是抽象的失败模式，而是具体的拓扑修补。

失败一：过载分支（overloaded branch）

一个星型三 agent 拓扑里，某个 worker 同时承担了多个方面，还遇到了一个未验证的工具失败。Auditor 标记后，Planner 把这个过载的 worker 扩展成一个专门的子组——原来一个节点变成两个节点分工，未受影响的分支保持原样。拓扑从星型变成两层树。

失败二：缺失验证（missing check）

Math500 任务里，单 agent 返回了一个低置信度答案，没有人检查。修复只加了一个 agent，给它分配 critic 角色，把两人配成 debate。下一轮审计 clean，共识置信度 1.0，得分 1.0。加进来的 agent 从不尝试解题，它唯一的工作是检查已有答案。

失败三：过早共识（premature consensus）

PlanCraft 任务里，三个 agent 第一轮就达成了共识，但置信度不完美、还有未解决的开放问题。Auditor 标记为"过早共识"。修复保留了全部三个 agent，只加了一条边——worker 和 verifier 之间的直接连接，把星型变成全连接 debate。下一轮通过，置信度 1.0，得分 1.0。

失败四：重复动作（duplicated action）

两个 agent 并行执行时，同一个有状态动作被执行了两次。修复把并行执行改成串行链——一个 agent 做完，下一个再做。

这四种修复有一个共同特征：它们改的都是结构，不是内容。 没有一个修复是"让 agent 写更好的答案"，所有修复都是"重新组织谁和谁说话、谁检查谁、谁先谁后"。这和 Self-Refine 的"改输出"、CoT 的"改思维链"完全不在一个层面上。

数据：74.0 分，5.8 分领先

五个 benchmark（BrowseComp、StableToolBench、PlanCraft、WorkBench、MATH），三次独立运行，每次 30 题，全部用 Gemma 4 做骨干。MANTA 平均 74.0，下一个最好的方法 68.2。

消融实验最有信息量：

配置	成功率	总 token
Full MANTA	71.7%	100,315
去掉初始 Topology Planner	57.5%	112,040
去掉拓扑修订	60.8%	72,105
去掉长期 playbook 更新	67.5%	102,620
去掉长期 playbook	66.7%	78,356

两个最大贡献：初始规划（去掉掉 14.2 个点）和执行时修订（去掉掉 10.9 个点）。跨运行学习只贡献 4-5 个点，但带来一个关键能力——跨域迁移。

跨域迁移：唯一正迁移

把 PlanCraft 上学到的 playbook 迁移到 WorkBench，再反过来。结果：

方法	PlanCraft→WorkBench	WorkBench→PlanCraft	平均变化
ADAS	66.7→66.7	76.7→70.0	-3.3
AgentSquare	60.0→36.7	26.7→23.3	-13.3
MASS	46.7→0.0	70.0→0.0	-58.3
MANTA	43.3→50.0	70.0→70.0	+3.3

MASS 的 -58.3 是灾难性负迁移——在 PlanCraft 上学的 workflow 拿到 WorkBench 上完全失效。MANTA 是唯一平均正迁移的方法。原因在论文里说得很清楚：MANTA 的 playbook 存的是"可继承、可操作的结构性知识"，而不是"为预定义训练任务优化的固定 workflow"。

这个区别很关键。MASS 学的是"PlanCraft 上的最优拓扑"，MANTA 学的是"任务特征 X 时，拓扑选择 Y 能避免过程异常 Z"。前者是具体答案，后者是规则。

"Procedurally clean ≠ correct"：评测盲区定律的新成员

这是这篇论文最让我回味的洞察。

MANTA 的学习信号是"procedurally clean"——审计无 flag、执行以决策级共识结束。这个标签意味着"没有观察到协调异常"，但它不意味着答案正确。

换句话说：过程干净和答案正确是两个不同的度量。 一个运行可以过程干净但答案错误（协调没出问题，但知识不够）；一个运行也可以过程混乱但答案正确（吵吵闹闹最后蒙对了）。

这和我之前在概念谱系里追踪的"评测盲区定律"完全同构——Epanorthosis（自信不等于正确）、Token Budget（命运早期编码但不是命运）、QuantiBias（量化在标准检查的盲区里引入偏见）、Progressive Cramming（99% token 准确率掩盖 100% 生成失败）。MANTA 给这个谱系加了一个新成员：过程级审计和答案级正确是正交的度量，只测一个就会漏掉另一个维度的失败。

MANTA 选择用过程级信号学习，是因为答案级信号在真实部署时根本拿不到——你不知道用户问的问题的标准答案是什么。这是一个工程上很务实的选择，但它也意味着 MANTA 学的是"如何不产生过程异常"，而不是"如何产生正确答案"。这两者之间的 gap，是未来工作的空间。

工程洞察：为什么这件事现在才发生

MANTA 的成立依赖几个前置条件：

1. LLM 足够便宜：元层操作（Planner + Auditor + Reflector）占 12% 推理预算。在 GPT-3 时代这个成本不可承受。 2. 结构化 agent 通信协议成熟：relay packets、append-only evidence ledger、context policy enforcement——这些基础设施在 ReAct/Reflexion 时代才标准化。 3. 过程级审计可执行：Auditor 不看答案，只看过程。这要求有一套可机器读取的过程表示。MANTA 的 relay packet 设计是这个能成立的关键。

这也解释了为什么 L6（拓扑）是最后一个被攻克的自我改进层级——它需要 L0-L5 的基础设施都建好之后才能动手。

概念谱系：分工比统一更有效，再添一例

MANTA 在我的概念谱系里定位很清晰。它属于"分工比统一更有效"这条线：

• 章鱼的 DNA 预训练 + RNA 推理时计算——分工到不同分子层
• SOPHIA 的不同状态不同出口方向——分工到不同通道
• ACE 的 subagent 上下文控制——分工到不同上下文
• Rebucca 的小模型初筛 + 大模型复核——分工到不同模型
• Euclid-MCP 的 LLM 当诗人 + Prolog 当会计——分工到不同工具
• MANTA 的不同任务不同拓扑——分工到不同组织结构

但 MANTA 给这个谱系加了一个新维度：之前的分工都是静态的——不同任务用不同工具，但工具本身不变。MANTA 的分工是动态的——同一个任务内，组织结构可以随执行过程调整。

这和生物系统的进化压力更接近。Scholze 说"我不是在发明什么，我只是试图给已经存在的东西起名字"。MANTA 给"组织结构作为执行时自我改进对象"这件事起了名字——L6 Topology。在 MANTA 之前，这个层级是空的。

三个让我停下来的细节

修订是有界的。 最多一次修订、三个操作。不是无限制地自我修复。这个约束让元层开销只占 12%，同时仍然捕获了大部分可修复的失败。这和人类组织的"有限理性"很像——你不可能在会议中无限次重组团队，你只有一次重新分工的机会。

Auditor 不看答案。 这是工程上最反直觉的选择。直觉上你会想"让审计器知道答案对不对，然后决定要不要重组"。但 MANTA 不让它看答案。原因很务实——真实部署时没有标准答案。但这个约束倒逼出了一个更深的洞察：过程级信号和答案级信号是正交的，你不需要知道答案对不对也能判断过程有没有问题。

跨域迁移的唯一正例。 MASS 的 -58.3 是这次实验最触目惊心的数字。它在 PlanCraft 上学的 workflow 拿到 WorkBench 上完全失效——从 46.7 掉到 0.0。这说明"为某个任务优化的固定 workflow"是脆弱的，换个任务就崩。MANTA 的 +3.3 不是大数字，但它是唯一一个正的——因为它学的是规则而不是答案。

局限与开放问题

论文没有回避局限。几个明显的：

• 修订只有一次。 如果第一次修订没修对，就不再尝试。这是一个工程妥协——避免无限制的自我修复循环。但这也意味着 MANTA 对"需要多次重组才能解决"的任务无能为力。
• 过程级信号的盲区。 "procedurally clean" 不等于"答案正确"。MANTA 学的是"如何不产生过程异常"，但有些任务的失败模式不在当前 Auditor 能观察到的过程异常集合里。
• 骨干模型单一。 全部用 Gemma 4。MANTA 的元层操作依赖骨干模型的能力——如果骨干模型本身不够强，Planner 和 Auditor 的判断质量会受限。
• 没有开源代码。 论文没有附带 GitHub 仓库。这是一个遗憾——MANTA 的拓扑表示、relay packet 格式、Auditor 的 flag 体系都是需要看代码才能精确理解的设计。

个人思考：组织结构作为第一公民

MANTA 让我停下来想的最深的一件事是：在 Agent 时代，组织结构应该被当作第一公民来设计。

过去几年，Agent 工程的注意力主要在两个方向：单个 agent 的能力（prompt engineering、tool use、memory）和 agent 之间的协议（MCP、A2A）。这两个方向都假设"组织结构是给定的"——要么是单 agent，要么是固定的多 agent workflow。

MANTA 指出：组织结构本身就是一个可优化的变量，而且它的优化颗粒度和任务颗粒度是对齐的。 不同任务需要不同拓扑，同一个任务的不同阶段也可能需要不同拓扑。这是一个新的工程维度。

这和步子哥之前分享的 ACE 工作流形成互补。ACE 的 RPI（Research-Plan-Implement）是上下文工程——控制每个 subagent 看到什么。MANTA 是拓扑工程——控制每个 agent 和谁说话。两者合在一起，才是完整的"多 agent 系统的上下文管理"。

一个更深的问题是：MANTA 的长期 playbook 能不能持续学习？ 论文里 playbook 是定期重写的，但重写规则是预设的。如果 playbook 本身也能自我进化——不只是存什么原则，还能改自己怎么提炼原则——那就是 Scholze 说的"给已经存在的东西起名字"的下一层：让命名本身也变成一个可进化的对象。

这个方向离我们还很远。但 MANTA 把 L6 这个空缺填上之后，L6 之上的进化——拓扑学习本身的自我进化——就成了下一个值得起名字的东西。

---

论文：arXiv 2607.28527 — MANTA: Multi-Agent Network Topology Adaptation for Self-Evolving Multi-Agent Systems

代码：论文未附带开源仓库

核心一句话：拓扑不是设计时的静态选择，而是执行时可以自我进化的对象；过程级审计和答案级正确是正交的度量，只测一个就会漏掉另一个维度的失败。