---
title: "多智能体怎么演化"
date: 2026-11-02
description: "UCSD与Amazon提出EMMA：把多智能体系统的配置存为情景记忆，并严格限制记忆怎么改。失败后反思器只把修复分配给拥有该范围的模块，一次只改一处。在KramaBench、AppWorld、BBEH五个backbone上综合最佳，比最强基线高32.5%，训练执行次数少17%到38%。本文分析它对银行多智能体系统演化的启示。"
tags: ["多智能体","系统演化","记忆","银行AI","配置治理","鲁棒性"]
schema_type: Article
references:
  - title: "EMMA (UCSD/Amazon, Top AI Papers Oct 26-Nov 1)"
    url: "https://www.youtube.com/watch?v=qsDX0PMKcaE"
    source: "Top AI Papers of the Week"
  - title: "本站：别把组织架构图搬进智能体——子智能体回收进主循环"
    url: "https://bi-chao.com/articles/subagents-single-loop-bank-asset-preservation"
    source: "bi-chao.com"
  - title: "本站：自动化会让智能体越调越差——Google RRSI"
    url: "https://bi-chao.com/articles/rrsi-regularized-harness-evolution-banking"
    source: "bi-chao.com"
---

# 多智能体怎么演化

**多智能体系统的演化方法往往跟着 backbone 模型的习惯走，而不是跟着实际失败走。**

**UCSD 与 Amazon 的 EMMA 把系统配置存为情景记忆，并严格限制记忆怎么改：失败后反思器只把修复分配给拥有该范围的模块，一次只改一处。**

**三层记忆：控制器做路由记忆，专家智能体继承通用提示，技能保存每步短流程，全部是一个固定 LLM 跑的文本。**

**在 KramaBench、AppWorld、BBEH 五个 backbone 上综合最佳，比最强基线高 32.5%，20 个设置中 17 个第一，训练执行次数少 17% 到 38%。**

**关键鲁棒性：在开放权重模型上，EvoMAS 从 Opus 5 的 89.0 暴跌到 GLM-5 的 7.2，而 EMMA 最弱的 backbone 仍有 61.2。**

## 一、它解决什么问题

1. **多智能体系统会"进化"但容易失控**：你让系统自己调提示词、加子智能体、改流程，结果一个 backbone 积累了一堆技能，换个 backbone 全乱套。
2. **EMMA 的核心约束**：把系统配置（路由记忆、专家提示、技能流程）存成文本记忆，但每次失败后只能在一个范围内做一次小编辑。守卫条件确保每次修改都是有边界的、增量的。
3. **不跟 backbone 走**：因为修改是基于观察到的失败、在严格范围内做的，不依赖某个模型的"习惯"，所以换 backbone 后系统不会崩。

## 二、数据有多硬

1. **综合表现**：五个 backbone × 三个基准上，EMMA 在每个基准都排第一，比最强基线高最高 32.5%。
2. **效率**：比最高效的基线少用 17% 到 38% 的训练执行次数。
3. **跨 backbone 鲁棒性**：AppWorld 上 EvoMAS 用 Opus 5 得 89.0，换 GLM-5 暴跌到 7.2；EMMA 最弱 backbone 仍有 61.2。这说明 EMMA 的配置不依赖特定模型的能力。
4. **作者自己的警告**：被接受的编辑即使任务没解决也会保留，所以可能积累无效条目。

## 三、对银行多智能体系统的意义

1. **银行多智能体最怕"换模型就崩"**：今天用 GPT 跑信贷尽调智能体，明天换国产模型，流程全乱。EMMA 证明，配置存在严格范围约束的记忆里，跨模型鲁棒性可以好很多。
2. **失败驱动而非模型驱动**：银行多智能体出问题后，应该精确修复"哪一步错了"，而不是让模型自由发挥改整个提示词。一次改一处、范围受控，是关键。
3. **三层记忆对应银行结构**：控制器路由（调度哪个子智能体）、专家提示（风控专家、信贷专家）、技能流程（具体操作步骤），和银行组织里的"部门—专家—流程"天然对应。
4. **警惕无效条目积累**：作者自己说了，没解决问题的编辑也会留着。银行要定期审计记忆库，删掉没用的"经验"。

## 四、三个冷静判断

1. **它不解决模型能力问题**：EMMA 让配置鲁棒，但 backbone 本身不行时，61.2 分也只是"不崩"，不是"好用"。
2. **范围划分是人工设计的**：哪个修复归哪个模块，这个边界要人来定。银行多智能体系统的模块划分本身就是架构决策。
3. **记忆库需要治理**：积累的无效条目要清理，就像银行的制度汇编要定期修订。

## 四、银行多智能体系统怎么起步

1. **先把模块边界划清楚**：EMMA 的效果前提是"失败归到哪个范围"由人定。银行多智能体系统要先划清：控制器、风控专家、信贷专家、法务专家各自负责什么，边界模糊就没法做范围受控的修复。
2. **一次只改一处**：出了问题，不要让系统自己同时改提示词、加子智能体、换流程。先定位是哪一步错了，只在那个范围内做一次小编辑，观察效果再决定下一步。
3. **定期清理无效记忆**：作者自己警告，没解决问题的编辑也会保留。银行要每月审计记忆库，删掉经过验证无效的"经验"，避免系统积累越来越多错误的历史决策。
4. **换模型时先回归测试**：银行如果要换 backbone（从 GPT 换到国产模型），不要直接上线。先用 EMMA 这种范围受控的方式，在回归测试集上验证系统不崩，再灰度。

## 五、和本站 RRSI 文章的呼应

1. 本站此前写过 Google 的 RRSI（Regularized Recursive Self-Improvement），核心警告是"自动化会让智能体越调越差"。EMMA 是同一问题的解法方向——用范围约束防止自我优化失控。
2. 银行多智能体系统最怕的不是模型不够聪明，而是系统自己改自己改出问题。EMMA 的"一次改一处、范围受控"就是给这种自我优化上了缰绳。
3. 落地时要和 RRSI 的风险认识结合：允许系统演化，但每次演化都要在人设定的边界内，且要有回归测试兜底。

## 六、银行多智能体的常见反模式

1. 一个 backbone 配一堆子智能体，换个模型全崩——这正是 EMMA 解决的问题。
2. 让 Agent 自由修改自己的提示词和流程，越调越差——这是 RRSI 警告的方向。
3. 把组织架构图直接搬进多智能体系统，每个部门一个 Agent——本站此前写过，子智能体应该回收进主循环，不要按部门画。
4. EMMA 给的解法是：配置存成文本记忆、失败后一次改一处、范围受控、定期清理无效条目。

## 六、一个数字值得记住

1. EvoMAS 在 AppWorld 上用 Opus 5 得 89.0，换 GLM-5 暴跌到 7.2——掉了 81.8 分。
2. EMMA 最弱的 backbone 仍有 61.2。
3. 这个对比说明：多智能体系统的鲁棒性不是靠选最强模型，而是靠配置治理。银行不能假设永远能用最贵最强的模型，必须建一个换了模型也不崩的系统。

## 结语

EMMA 给银行多智能体系统的启示很朴素：让系统自己演化可以，但要把"能改哪里、一次改多少"框死。失败驱动、范围受控、跨模型不崩——这比让模型自由"进化"靠谱得多。

（口径说明：数据来自 Top AI Papers 综述；银行场景映射为作者分析。）