CORAL：当多个 AI Agent 学会自己搞进化，效率碾压传统搜索 3-10 倍
你有没有想过一个问题：为什么现在大模型这么强了，但做"开放式发现"（比如优化一个 GPU kernel、找一个数学猜想的更优解）的时候，我们还在用人类写死的进化规则去驱动搜索？
说实话，这事儿我一直觉得很矛盾。一边是越来越聪明的 LLM，一边是死板的 if score > best: keep 这种硬编码逻辑。模型明明有能力自己判断"该探索什么方向"、"该复用哪个旧方案"，结果你非要用固定的锦标赛选择、固定的变异策略去约束它。
MIT 联合新加坡国立大学、MiniMax、Meta、Stanford 等机构的一篇新工作 CORAL，给出了一个让我觉得"对，就该这么做"的方案：把进化搜索的控制权彻底交给 Agent 自己。四个自主 Agent 协同进化，在 Anthropic 的 kernel engineering 任务上把最优纪录从 1363 cycles 干到了 1103 cycles，提升 20%。而且在 11 个任务上全部拿到最优，改进率是传统方法的 3-10 倍。
📖 核心摘要
痛点：现有的 LLM-based 进化搜索（如 OpenEvolve、AlphaEvolve）虽然用 LLM 生成候选方案，但"选谁留、选谁变、什么时候停"这些关键决策仍然靠人类写死的启发式规则，Agent 的自主性被严重限制。
方案：CORAL 提出 自主多智能体进化框架，让多个 long-running Agent 自己决定检索什么、怎么改、何时反思，通过共享持久化记忆 + 异步执行 + 心跳干预机制实现协作。
效果：11 个数学/算法/系统优化任务上全部 SOTA，改进率 3-10 倍于 baseline，评估次数仅需 5-56 次（对手动辄 60-100 次）。四 Agent 协同在 kernel engineering 上刷新纪录：1363 -> 1103 cycles。
判断：这不是又一篇"我也做了 multi-agent"的凑数论文。它的核心贡献在于把进化搜索范式从"LLM 当工具人"推进到"LLM 当决策者"，并用扎实的实验证明了自主性带来的效率提升不是幻觉。
📖 论文信息
- 标题：CORAL: Towards Autonomous Multi-Agent Evolution for Open-Ended Discovery
- 作者：Ao Qu, Han Zheng, Zijian Zhou, Yihao Yan, Yihong Tang, Shao Yong Ong, Fenglu Hong, Kaichen Zhou, Chonghe Jiang, Minwei Kong, Jiacheng Zhu, Xuan Jiang, Sirui Li, Cathy Wu, Bryan Kian Hsiang Low, Jinhua Zhao, Paul Pu Liang
- 机构：MIT, NUS, MiniMax, McGill, Stanford, SambaNova, SMART, Meta, Amazon, Microsoft
- 日期：2026 年 4 月 2 日
- 论文链接：https://arxiv.org/abs/2604.01658
🎯 问题动机：进化搜索的"自主性瓶颈"
先聊聊背景。LLM-based 进化搜索这条线，从 DeepMind 的 FunSearch（2023）到后来的 AlphaEvolve（2025），核心思路都是一样的：用 LLM 生成代码候选方案，丢给评估器打分，然后按某种策略选优、变异、迭代。
问题在哪？问题在于LLM 只负责"生成"这一步，其他所有决策都是人类写死的。
你想想看： - 检索：固定规则选 top-k 历史方案喂给模型 - 评估：固定的 loop 触发评估 - 更新：固定的 population 淘汰策略
这就好比你雇了一个很聪明的程序员，但只让他写代码，不让他决定写什么、参考什么、什么时候该换个思路。
CORAL 的出发点很直接：既然 LLM 已经有了足够的推理和判断能力，为什么不把这些决策也一起交给它？
图1：三种进化搜索范式的对比。左边是传统的固定进化搜索（LLM只管提方案），中间是自主单Agent进化（Agent自己决定检索和存储），右边是CORAL的自主多Agent进化（多个Agent通过共享记忆异步协作）。注意蓝色深浅代表自主程度的递进。
这张图把三个阶段讲得很清楚：
| 维度 | 固定进化搜索 | 自主单Agent | 自主多Agent（CORAL） |
|---|---|---|---|
| 检索 | 固定规则选上下文 | Agent 自己选看什么 | Agent 从共享记忆中读取 |
| 提案 | 模型按给定上下文生成 | Agent 自行规划、实现、测试 | 多Agent并行提案 |
| 评估 | 固定循环触发 | Agent 自己决定何时评估 | 各Agent独立调度评估 |
| 更新 | 固定规则更新 | Agent 决定存什么 | Agent 写入共享记忆 |
🏗️ 方法核心：让 Agent 自己跑、自己想、互相学
整体架构
CORAL 的核心设计思路可以用一句话概括：把进化搜索的四个阶段（检索-提案-评估-更新）的控制权全部交给 Agent，多个 Agent 通过共享文件系统异步协作。
图2：CORAL的完整系统架构。左侧展示了单个Agent的自主工作循环：读取历史尝试、笔记和技能 -> 规划并编辑代码 -> 运行评估器获得分数和反馈 -> 将发现写成笔记和技能。右上方是心跳监控机制（反思、整合、重定向三种干预）。右下方是共享持久化记忆的三大分区：Attempts（历史尝试及分数）、Notes（观察和洞察）、Skills（可复用的脚本和工具）。
具体拆开来看：
共享持久化记忆
这是整个系统的"公共大脑"，用文件系统 + 符号链接实现，分三个目录：
- attempts/：所有历史评估记录，带分数和排行榜。Agent 可以查看谁的方案最优，直接把别人的代码拿来改
- notes/：Agent 的观察笔记，比如"batch_size=2 比 4 快，因为减少了依赖"。Markdown 格式，其他 Agent 可以直接读
- skills/：可复用的脚本和工具，比如 auto-batcher 脚本。每个 skill 有 SKILL.md 描述文件
实现上其实很朴素——就是文件系统。每个 Agent 有自己的独立工作区（git worktree），通过 symlink 访问共享目录。这种设计的好处是天然支持异步：不需要任何消息传递协议，Agent 只要读写文件就行。
心跳干预机制
这是我觉得挺精巧的一个设计。纯放手让 Agent 自己跑也不行——它可能陷入局部最优反复试同一个方向，也可能忘了把发现写下来。
CORAL 的解决办法是 三级心跳干预：
- 每轮反思（per-iteration）：提醒 Agent "写个笔记，方便其他 Agent 借鉴"
- 定期整合（每 10 次评估）：让 Agent 回顾所有笔记，合并重复发现，提炼可复用 skill
- 停滞重定向（连续 5 次无改进）：直接告诉 Agent "你当前策略卡住了，换个方向试试"
注意，这些干预不是替 Agent 做决策，而是提醒它该做什么。具体怎么做，仍然是 Agent 自己决定。这个分寸拿捏得不错——不干预会失控，干预太多又失去自主性。
安全防护
系统层面，CORAL 做了比较完善的隔离： - 每个 Agent 独立的 git worktree，互不干扰 - 评估器与 Agent 分离（Agent 不能作弊改分数） - 资源限制和健康监控 - Agent session 管理（崩了能重启，不丢状态）
🧪 实验结果：11 个任务全部最优
单 Agent 对比（Table 1）
这张实验主表信息量很大，我挑几个关键数据聊：
| 任务类别 | 任务 | SOTA | OpenEvolve | ShinkaEvolve | EvoX | CORAL | CORAL 改进率 | CORAL 评估次数 |
|---|---|---|---|---|---|---|---|---|
| 数学 | Circle Packing | 2.6359 | 2.6293 | 2.6001 | 2.6320 | 2.6360 | 100.0% | 11 |
| 数学 | Signal Proc. | 0.7429 | 0.6420 | 0.8171 | 0.7306 | 0.8229 | 30.3% | 56 |
| 数学 | 3rd-Autocorr. | 1.4557 | 1.4731 | 1.4812 | 1.5552 | 1.4557 | 60.0% | 5 |
| 系统 | EPLB | 0.145 | 0.127 | 0.129 | 0.146 | 0.149 | 78.9% | 19 |
| 系统 | Txn Sched. | 4348 | 3774 | 3802 | 3984 | 4566 | 27.3% | 22 |
| 系统 | Cloudcast | 632.7 | 627.2 | 627.8 | 623.5 | 618.4 | 33.3% | 9 |
几个让我印象深刻的点：
Circle Packing 任务：CORAL 的改进率 100%——也就是说，它每次提交的方案都在变好。只用了 11 次评估就达到最优。对比之下，OpenEvolve 跑了 100 次评估、改进率才 7%。这差距不是"显著"两个字能形容的。
评估效率：CORAL 在大多数任务上只需要 5-22 次评估，而 baseline 方法动辄 60-100 次。这说明 Agent 的自主决策确实让它"想清楚了再动手"，而不是盲目试错。
3rd-Autocorrelation：5 次评估就达到 SOTA，改进率 60%。EvoX 跑了 75 次，改进率才 12%。
不过坦率讲，有些任务的差距并没有那么夸张。比如 Signal Processing，ShinkaEvolve 拿到了 0.8171，CORAL 是 0.8229，差距不大。PRISM 任务上所有方法都达到了 SOTA（26.26），可能这个任务本身对 LLM 来说不够难。
多 Agent 协同进化（重头戏）
四个 Agent 一起跑会怎样？
图3：Anthropic Kernel Engineering 任务的性能曲线。绿线是CORAL单Agent（56次评估达到1350 cycles，109.4x加速），蓝线是CORAL四Agent（596次评估达到1103 cycles，133.9x加速），红线是OpenEvolve（363次评估只到2740 cycles，53.9x加速）。右侧小图展示了完整的改进轨迹。
这个图的数据让我愣了一下：
| 方法 | 模型 | 评估次数 | 最优 Cycles | 加速比 | 改进率 |
|---|---|---|---|---|---|
| Best Known | Anthropic | - | 1363 | 108.4x | - |
| OpenEvolve | Opus 4.6 | 363 | 2740 | 53.9x | 3% (12/363) |
| CORAL（1 agent） | Opus 4.6 | 56 | 1350 | 109.4x | 43%（24/56） |
| CORAL（4 agents） | Opus 4.6 | 596 | 1103 | 133.9x | 9%（54/596） |
CORAL 单个 Agent 只用 56 次评估就超过了 Anthropic 自己的最优纪录（1363 -> 1350）。四个 Agent 协同之后更是干到了 1103 cycles。OpenEvolve 跑了 363 次评估，结果还是 2740 cycles，连 CORAL 单 Agent 的一半性能都没到。
说实话，43% 的单 Agent 改进率让我有点怀疑——几乎每两次尝试就有一次能改进。但仔细想想，Agent 自主检索历史方案、自己写笔记总结规律、根据反馈决定下一步做什么，确实比"随机选 top-k 方案拼 prompt"的方式要智能得多。
Polyomino Packing 的直观对比
图4：Polyomino Packing任务的视觉对比。左边是Claude Opus 4.6直接单次生成的结果（56%填充率），右边是CORAL经过自主进化后的结果（89.4%填充率），超过了之前87%的最优纪录。差距一目了然。
这个对比很直观：同样的模型（Opus 4.6），单次生成只有 56% 的填充率，但经过 CORAL 的自主进化迭代之后达到了 89.4%。模型的能力没变，变的是怎么用模型。
消融实验
消融实验回答了两个关键问题：
知识积累有用吗？
| 配置 | Kernel Eng. | Polyominoes | Txn Sched. |
|---|---|---|---|
| 有知识积累 | 1,350 | 80.2 | 4,566 |
| 无知识积累 | 1,601 | 77.3 | 4,444 |
| 退化幅度 | 18.6% | 3.6% | 2.7% |
去掉 notes 和 skills 后，Kernel Engineering 退化了 18.6%。这个退化不小，说明知识积累在复杂任务上确实是关键。但在相对简单的 Txn Sched. 上，退化只有 2.7%——可能简单任务不需要太多"经验"。
多 Agent 协同比单干强多少？
| 配置 | Kernel Eng. | Polyominoes | Txn Sched. |
|---|---|---|---|
| 4 Agent 协同 | 1,103 | 84.2 | 4,694 |
| 4 Agent 独立最优 | 1,180 | 80.8 | 4,629 |
四个 Agent 协同进化的结果优于四个独立 Agent 各自最优取 max 的结果。这说明协同带来的增益不只是"多跑几次取最好"那么简单——Agent 之间确实在互相学习。
具体来看，Kernel Engineering 上 36% 的尝试用了其他 Agent 的代码作为起点，这些跨 Agent 改进的成功率是 17%，远高于整体的 9%。而且 66% 的新纪录来自跨 Agent 的方案继承。
🔧 机制分析：为什么 CORAL 能 work？
论文做了比较细致的机制分析，我觉得有几个发现特别值得关注：
本地验证是关键
Agent 在提交外部评估之前，会先在本地跑测试。统计数据显示：
| 指标 | 标准任务 | Kernel Eng. |
|---|---|---|
| 本地测试率 | 24% | 57% |
| 知识访问率 | 7% | 17% |
| 每次尝试产生的知识条目 | 0.05 | 0.68 |
| 访问知识时的改进率 | 26% | 55% |
在 Kernel Engineering 这种编译型任务上，Agent 57% 的时间会先在本地验证代码能跑通再提交。Transaction Scheduling 上这个数字更高，到了 61%。这个行为不是人告诉它的，是 Agent 自己学会的——"先在本地试试，别浪费评估配额"。
知识质量与任务难度正相关
标准任务上每次尝试只产生 0.05 条知识条目（笔记或技能），而 Kernel Engineering 上是 0.68 条——差了 13 倍。访问知识时的改进率也从 26% 跃升到 55%。
这说明 CORAL 的知识积累机制在难任务上才真正发挥作用。简单任务本身搜索空间不大，不需要太多经验积累；而复杂任务需要 Agent 不断总结规律、提炼技巧才能持续改进。
探索多样性
四个 Agent 之间策略关键词的 Jaccard 相似度平均只有 0.43（Kernel Eng.）和 0.31（Polyominoes），意味着每个 Agent 超过一半的策略词汇是独有的。这不是靠随机种子做到的，而是 Agent 在共享记忆的基础上自然分化出了不同的探索方向。
🔬 系统实现细节
CORAL 不只是一个 idea，它的工程实现也相当完整。
图5：CORAL的软件架构图。顶层是CoralConfig配置系统，中间左侧是Agent System（AgentManager管理多个AgentHandle，每个配备HeartbeatRunner），右侧是Grader Hierarchy（支持TaskGrader和FunctionGrader两种评估器）。底部左侧是Workspace Setup，右下是Hub共享状态（attempts/notes/skills/checkpoint）。
它还提供了一个 Web UI 来监控进化过程：
图6：CORAL Web UI 的 Overview 页面，展示了 Erdos minimum overlap 任务的运行情况。上方是分数曲线（实线为每次评分，虚线为当前最优），下方是所有尝试的详细列表，包含分数、Agent ID、状态（IMPROVED/REGRESSED）和时间戳。
图7：CORAL Web UI 的 Knowledge 页面。左侧展示了Agent产生的23条笔记（如"Van der Corput Low-Discrepancy Initialization Analysis"等），右侧展示了13个可复用技能（如 algorithm-comparison-analysis、cma-es-evolutionary-optimization 等）。这些知识在Agent之间共享。
🤔 批判性分析
亮点
-
范式推进而非增量改进：从"LLM 当工具人"到"LLM 当决策者"，这个抽象层次的提升是有意义的。不是在现有框架上加个模块，而是重新定义了进化搜索中 Agent 的角色。
-
实验设计公平：所有方法都用同一个基础模型 Claude Opus 4.6，同样的时间预算（3小时），基线方法的选择也覆盖了该领域的代表性工作。
-
机制分析扎实：不只给了 Table 1 的 SOTA 数字，还认真分析了"为什么 work"——知识复用、跨 Agent 继承、探索多样性这些分析让结果更可信。
我的疑虑
-
对基础模型的依赖太重。论文用的是 Claude Opus 4.6，这是当前最强的代码模型之一。换成开源模型（比如 Qwen-2.5-72B-Coder），CORAL 还能保持多大优势？论文自己也承认了这个局限——"CORAL depends on frontier foundation models"——但没有做任何降级实验。
-
Baseline 的选择值得推敲。OpenEvolve、ShinkaEvolve、EvoX 都是开源社区的方法，而 CORAL 用的是闭源的 Opus 4.6。虽然所有方法都用同一个基础模型，但论文没有和 DeepMind 的 AlphaEvolve（也是这个领域的重要工作）做对比。可能是因为 AlphaEvolve 没有开源，但至少应该在 paper 里讨论一下。
-
成本问题被回避了。四个 Agent 跑 596 次评估，每次都是 Opus 4.6 的长上下文调用。这个 token 消耗和 API 费用是多少？论文完全没提。对于工程落地来说，这是一个无法回避的问题。
-
心跳机制的参数敏感性。每 10 次评估整合一次、连续 5 次无改进就重定向——这些数字是怎么定的？有没有做过敏感性分析？如果换一组参数会怎样？论文没有给消融。
-
"自主性"的边界在哪？ 虽然说是"自主进化"，但 Agent 的 system prompt、心跳干预的文本内容、共享记忆的目录结构，这些都是人类精心设计的。这到底是"真自主"还是"把启发式规则从代码搬到了 prompt 里"？这个哲学问题论文没有正面回答。
💡 与同期工作的定位
把 CORAL 放在更大的图景里看：
| 工作 | 机构 | 核心思路 | Agent 自主性 | 多 Agent |
|---|---|---|---|---|
| FunSearch (2023) | DeepMind | LLM 生成 + 进化搜索 | 低（纯工具人） | 否 |
| AlphaEvolve (2025) | DeepMind | 进化整个代码库 | 中（部分自主） | 否 |
| OpenEvolve | 开源社区 | AlphaEvolve 开源复现 | 低 | 否 |
| CORAL（2026） | MIT 等 | 自主多Agent进化 | 高（Agent做决策） | 是 |
CORAL 的定位是在 AlphaEvolve 基础上做了两个推进：一是 Agent 自主性从部分提升到完全（Agent 控制检索、评估、知识管理全链路），二是从单 Agent 扩展到多 Agent 异步协作。从结果来看，这两个推进都被实验验证了。
但也要看到，AlphaEvolve 是 DeepMind 内部使用的系统，其在 Google 数据中心和 TPU 优化上的实战效果，可能比论文里能展示的更强。CORAL 目前更偏"研究范式"，离大规模工程部署还有距离。
💡 工程启发
如果你在做类似的"用 LLM 自动优化代码/算法"的项目，CORAL 有几个设计值得借鉴：
-
共享文件系统 > 消息传递：多 Agent 协作不一定需要复杂的通信协议。文件系统 + symlink 这种"最低技术含量"的方案，反而最稳定、最好调试。
-
心跳干预是个好模式：完全放手和过度控制之间，"定期提醒但不替你做决策"是一个值得尝试的平衡点。
-
知识的三层结构（attempts/notes/skills）：把"做过什么"（attempts）、"学到什么"（notes）、"能复用什么"（skills）分开管理，让 Agent 的经验可以被结构化地积累和共享。
-
本地验证前置：让 Agent 在提交昂贵的外部评估之前先自己测一下，这个习惯能省不少钱。
收尾
说实话，我觉得 CORAL 这篇工作的价值不在于刷了多少 SOTA（虽然确实刷了不少），而在于它验证了一个直觉：把更多控制权交给 Agent，搜索效率会提升，而不是下降。 这个结论其实不那么显然——你也可以合理地担心"Agent 自己做决策会乱来"。但至少在这些任务上，自主性带来的好处远大于风险。
当然，这条路还很长。基础模型的能力天花板、多 Agent 的成本开销、"自主性"边界的哲学问题，都是后续需要回答的。但方向是对的。
如果你也在做开放式搜索优化的工作，CORAL 的思路值得认真看看。不用照搬框架，但"让 Agent 自己管理搜索过程"这个 principle，可以试着在自己的项目里先小范围验证。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我