CORAL: Towards Autonomous Multi-Agent Evolution for Open-Ended Discovery

Paper: arXiv:2604.01658 Code: Human-Agent-Society/CORAL Code reference: main @ 3d002bfd (2026-05-22)

1. Motivation (研究动机)

现有 LLM-based evolution 的瓶颈：外层搜索仍然是固定算法

这篇论文关注的不是“让 LLM 一次性写出答案”，而是更接近 FunSearch / AlphaEvolve / OpenEvolve / ShinkaEvolve 这类 evaluator-guided evolutionary search：LLM 反复提出 candidate program，外部 evaluator 给分，系统再根据历史高分解继续搜索。问题在于，已有方法虽然把 LLM 放进了演化循环，但很多真正决定搜索质量的动作仍由硬编码规则控制：检索哪些父解、怎样构造 prompt、什么时候评估、怎样更新 population / memory、失败后何时换方向。

论文把这类固定流程拆成四步：给定任务描述 $x$ 和 evaluator $E$ ，候选解 $y$ 的评估为 $E (x, y) := (s, f),$ 其中 $s$ 是 numeric score， $f$ 是辅助反馈。第 $t$ 步共享记忆为 $M_{t}$ ，系统先从中构造工作上下文 $\hat{M}_{t}$ ，再执行 Retrieve $\to$ Propose $\to$ Evaluate $\to$ Update。传统固定演化搜索的问题是： $\hat{M}_{t}$ 的选择、评估触发、失败处理、知识外化等关键控制权在外层算法，而不是在 agent 自己手里。

多智能体系统的另一类刚性：角色与通信结构预设

很多 multi-agent LLM 系统采用“vertical scaling”：人先拆任务、分配角色、定义通信拓扑，再让 agents 按剧本协作。论文认为这对 open-ended discovery 也有限制，因为开放问题的有效分解方式、哪些中间发现值得保存、哪些 agent 应该借鉴谁的路线，往往也是搜索过程的一部分，而不是一开始就能知道的固定结构。

CORAL 要解决的具体问题

CORAL 试图回答两个问题：第一，若把 Retrieve / Propose / Evaluate / Update 中更大部分的控制权交给长期运行的 autonomous agent，是否能比固定演化搜索更有效？第二，若多个长期运行 agent 不通过预设对话协议，而是通过共享持久记忆异步协作，是否能比单 agent 或“best-of-4 独立运行”扩展更好？这个问题值得研究，因为很多科学、系统和算法优化任务只有 evaluator，没有 ground-truth answer；系统必须长期积累经验、复用失败教训和局部技巧，才能持续推进 frontier。

Figure 1 解读：图中把三种范式并排比较。Fixed evolutionary search 中，LLM 基本只负责 Propose，Retrieve / Evaluate / Update 由固定 search algorithm 控制；autonomous single-agent evolution 把“看什么、何时测试、写回什么”交给单个 agent；autonomous multi-agent evolution 则让多个 agent 各自执行完整循环，并通过 shared memory 读写彼此成果。CORAL 的核心定位就是从中间范式进一步走到右侧范式。

2. Idea (核心思想)

CORAL 的核心 insight 是：open-ended discovery 中，搜索策略本身应当成为 agent 的可自主决策对象，而不是固定外层算法的一组超参数。如果 agent 能像工程师一样浏览历史尝试、局部测试、保存笔记、提炼 skills，并且多个 agent 能通过共享记忆异步“相互感染”有效技巧，那么系统可以在长时间搜索中自然形成知识积累与探索分工。

关键创新可以概括为三点：CORAL 用 file-system-based shared persistent memory 替代固定 population 数据结构；用 asynchronous multi-agent organization 替代预设角色/对话拓扑；用 heartbeat-based interventions 在不接管 agent 全部决策的前提下，周期性推动 reflection、consolidation 和 pivot，防止长期运行 agent 只做局部微调或忘记写入共享知识。

与 AlphaEvolve / OpenEvolve / ShinkaEvolve 相比，CORAL 的根本差异不是“也用了 LLM 生成候选”，而是把很多外层演化控制权从 algorithm 转移给 agent：agent 自己决定检索哪些 attempts / notes / skills，何时执行 local test，何时调用 evaluator，以及哪些发现值得写回共享库。与常见 multi-agent collaboration 相比，CORAL 不要求人类预设通信结构；agents 主要通过 attempts、notes、skills 等持久 artifact 间接协调。

Figure 2 解读：这是 CORAL 的整体框架图。左侧每个 agent 在私有 worktree 中独立循环：读取 leaderboard / notes / skills，计划并修改代码，运行 grader.py 评估，最后把 notes 与 skills 写回。右侧 heartbeat monitor 不直接给出新算法，而是在反思、整理和停滞时重定向三个节点插入 prompt。底部 shared persistent memory 是 agents 之间真正的通信介质：attempts 记录得分轨迹，notes 记录分析，skills 存可复用程序和流程。

3. Method (方法)

3.1 问题形式化：从候选解评估到四阶段循环

论文把 open-ended discovery 表述为：任务由描述 $x$ 和 evaluator $E$ 指定，candidate solution $y$ 经 evaluator 返回 $(s, f)$ 。共享持久记忆 $M_{t}$ 包含已有候选解、评估结果、文字反馈、笔记和可复用技能；一次改进步骤可抽象为： $\hat{M}_{t} = Retrieve (M_{t}), y_{t + 1} = Propose (x, \hat{M}_{t}), (s_{t + 1}, f_{t + 1}) = E (x, y_{t + 1}), M_{t + 1} = Update (M_{t}, y_{t + 1}, s_{t + 1}, f_{t + 1}) .$ 在 fixed evolutionary search 中，这四个算子大多是外部固定规则；CORAL 的目标是让 agent 自己执行这些动作，并允许动作的时机、粒度和内容随任务进展改变。直觉上，这更接近人类研究者做长期优化：不是每次都按同一模板 mutate，而是先看失败样例、局部复现实验、记录假设，再决定下一步是否值得提交 evaluator。

3.2 Shared Persistent Memory：把演化 population 扩展成可读写知识库

CORAL 的共享记忆 $M$ 是 .coral/public/ 下的文件系统，并通过 symlink 暴露到每个 agent 的 runtime 目录。论文给出三类 root folder：

attempts/：保存历史评估、candidate solution、score、status、feedback 和 commit hash；agent 可以看 leaderboard、比较高分解、checkout 父解。
notes/：保存 agents 写下的观察、失败原因、局部规律、开放问题和 synthesis；agent 可按主题组织子目录。
skills/：保存可复用过程、脚本、工具和 implementation pattern，例如一个自动 benchmark batch size 的 skill。

这个设计的重点不是“把所有上下文塞进 prompt”，而是让 agent 以 progressive disclosure 方式主动读取需要的 artifact。对长程任务而言，notes / skills 提供了比 prompt history 更稳定的跨回合记忆；对 multi-agent 而言，它又是一个弱耦合的通信总线。

3.3 Asynchronous Multi-Agent Organization：水平扩展探索，而不是硬编码角色

在 multi-agent 版本中，第 $i$ 个 agent 有自己的局部上下文 $C_{t}^{(i)}$ 和独立 worktree，同时通过 symlink 共享同一个 $M$ 。当 agent $i$ 写入 artifact $W_{t}^{(i)}$ 后，agent $j$ 之后可以把它作为 $\hat{M}_{t}^{(j)}$ 的一部分检索： $W_{t}^{(i)} \to M \to \hat{M}_{t}^{(j)} .$ 因此，信息转移不是通过固定消息协议发生，而是通过“可被后续 agent 检索的持久证据”发生。这使得不同 agent 可以并行探索不同方向，同时仍能通过 code parent、notes、skills、leaderboard 等方式共享突破。

3.4 Heartbeat：轻量干预长期 agent 的反思、整理与换方向

因为 CORAL 不再强制固定搜索循环，agent 可能陷入局部最优、过度微调、忘记查共享记忆、或忘记把新知识写回。heartbeat 的作用是提供最低限度的行为约束，而不是替代 agent 搜索。论文定义 heartbeat 触发后会把 agent 的本地上下文从 $C_{t}^{(i)}$ 修改为 $C_{t}^{' (i)}$ ，从而影响后续行为： $C_{t}^{(i)} \to C_{t}^{' (i)} .$ 当前 CORAL 实现包含三类默认 heartbeat：reflect 每次 eval 后要求基于近期结果写 note；consolidate 每 10 次全局 eval 后要求整理 shared notes、建立 connections / open questions、抽取 skills；pivot 在连续 5 次无提升后触发，要求 agent 诊断停滞、查看 top attempts、换一个“different mountain to climb”。released code 中 coral/config.py 的默认 AgentConfig.heartbeat 对应 reflect every=1、consolidate every=10 is_global=True、pivot every=5 trigger="plateau"；coral/agent/heartbeat.py 中 HeartbeatRunner.check() 根据 local/global eval count 与 plateau streak 返回触发 actions。

3.5 Grader isolation 与 execution safeguards：让 agent 能优化但不能偷看 evaluator

CORAL 保留 evaluator 作为 API，而不是把 grader 细节暴露给 agent。coral eval -m "..." 的流程是：在 agent worktree 中 stage / commit，动态加载 .coral/private/eval/grader.py，在 child process 中带 timeout 运行 grader，生成 ScoreBundle，将结果写回 attempts，并把反馈递送回 agent。Appendix C.7 还列出若干 safeguards：grader 被复制到 .coral/private/eval/ 并对 agent 隐藏；.gitignore 防止 .coral/ 被提交；manager 记录 PID 并按 SIGINT $\to$ SIGTERM $\to$ SIGKILL 优雅停止；grader timeout 默认在任务配置中设定，超时记为 timeout 且 score 为 null。

Figure 4 解读：这张图对应 released code 的模块边界。Configuration 解析 YAML 为 CoralConfig；Agent System 的 AgentManager 负责 start / monitor / stop / resume 与 heartbeat；Workspace Setup 创建 run dir、repo clone、agent worktree 和 symlink；Hub 管理 attempts / notes / skills / checkpoint；Grader Hierarchy 把不同任务的 evaluator 统一成 ScoreBundle；Core Types 存放 Task / Score / Attempt 等数据结构。图中箭头也解释了为什么 evaluator isolation 与 shared memory 可以同时存在：agent 读写 .coral/public/，grader 在私有路径执行。

3.6 Pseudocode：基于 released code 的关键组件流程

下面伪代码是对 main@3d002bfd released code 的结构化改写，重点反映真实模块边界，而不是逐行复刻实现。

from pathlib import Path
 
class CoralEvolutionLoop:
    def run_agent_step(self, task, agent_workspace, shared_memory, grader):
        context = self.retrieve(shared_memory, task)
        candidate_patch = self.propose_and_edit(task, context, agent_workspace)
        local_ok = self.run_optional_local_tests(agent_workspace)
        if self.agent_decides_to_submit(local_ok, context):
            score_bundle = grader.grade_sync(agent_workspace, task.tasks)
            attempt = self.make_attempt(candidate_patch.commit_hash, score_bundle)
            shared_memory.write_attempt(attempt)
        note_or_skill = self.decide_what_to_externalize(context, score_bundle)
        shared_memory.write(note_or_skill)
        return score_bundle

class SharedPersistentMemory:
    def __init__(self, coral_dir: Path):
        self.public = coral_dir / "public"
        self.attempts = self.public / "attempts"
        self.notes = self.public / "notes"
        self.skills = self.public / "skills"
 
    def expose_to_agent(self, worktree: Path, runtime_dir: str = ".claude"):
        shared_dir = worktree / runtime_dir
        shared_dir.mkdir(exist_ok=True)
        for name in ["attempts", "notes", "skills", "logs", "heartbeat"]:
            (shared_dir / name).symlink_to(self.public / name)
 
    def write_attempt(self, attempt):
        path = self.attempts / f"{attempt.commit_hash}.json"
        atomic_write_json(path, attempt.to_dict())

class HeartbeatRunner:
    def check(self, *, local_eval_count, global_eval_count, score_history, minimize=False):
        triggered = []
        for action in self.actions:
            if action.trigger == "interval":
                counter = global_eval_count if action.is_global else local_eval_count
                if counter > 0 and counter % action.every == 0:
                    triggered.append(action)
            elif action.trigger == "plateau":
                stall = plateau_streak(score_history, minimize=minimize)
                last = self._plateau_fired_at.get(action.name, -10**9)
                if stall >= action.every and local_eval_count - last >= action.every:
                    self._plateau_fired_at[action.name] = local_eval_count
                    triggered.append(action)
        return triggered

class AgentManager:
    def start_all(self):
        self.paths = create_project(self.config, config_dir=self.config_dir)
        self._start_gateway_if_enabled()
        self._start_grader_daemon()
        seed_default_global_heartbeat_if_needed(self.paths.coral_dir)
        handles = []
        for spec in self.specs:
            worktree = create_agent_worktree(self.paths.repo_dir, spec.agent_id, self.paths.agents_dir)
            setup_shared_state(worktree, self.paths.coral_dir, runtime_shared_dir(spec.runtime))
            instruction = render_agent_instruction(spec, self.config, self.paths)
            handles.append(self._runtime_for(spec).start(worktree, instruction))
        return handles
 
    def monitor_loop(self, check_interval=5):
        while self._running:
            for attempt in read_new_scored_attempts(self.paths.coral_dir):
                runner = self._get_heartbeat_runner(attempt.agent_id)
                actions = runner.check(local_eval_count=local_count(attempt.agent_id),
                                       global_eval_count=global_count(),
                                       score_history=history(attempt.agent_id),
                                       minimize=self.config.grader.direction == "minimize")
                if actions:
                    self._interrupt_and_resume_agent(attempt.agent_id, actions, attempt.feedback)
            self._restart_dead_agents_if_needed()
            sleep(check_interval)

class EvaluationPipeline:
    def coral_eval(self, message, worktree, coral_dir, config):
        commit_hash = git_stage_and_commit(worktree, message)
        parent_hash = find_parent_attempt(worktree)
        pending = Attempt(commit_hash=commit_hash, status="pending", parent_hash=parent_hash)
        write_attempt(coral_dir, pending)
        return pending
 
    def grader_daemon_step(self, pending_attempt, config, coral_dir):
        grader = load_grader(config, coral_dir)
        isolated = checkout_attempt_into_isolated_worktree(pending_attempt.commit_hash)
        bundle = run_with_timeout(lambda: grader.grade_sync(isolated, config.tasks),
                                  seconds=config.grader.timeout)
        scored = pending_attempt.with_score_bundle(bundle)
        write_attempt(coral_dir, scored)
        increment_eval_count(coral_dir)
        return scored

3.7 Code-to-paper mapping

Code reference: main @ 3d002bfd (2026-05-22) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
YAML task / agent / grader / workspace configuration	`coral/config.py`	`TaskConfig`, `GraderConfig`, `AgentConfig`, `SharingConfig`, `WorkspaceConfig`, `RunConfig`, `CoralConfig.from_yaml()`
Agent lifecycle, start, resume, monitoring, restart	`coral/agent/manager.py`	`AgentManager.start_all()`, `resume_all()`, `monitor_loop()`
Heartbeat triggers and plateau logic	`coral/agent/heartbeat.py`	`HeartbeatAction`, `HeartbeatRunner.check()`
Runtime adapters	`coral/agent/builtin/*.py`, `coral/agent/runtime.py`	Claude Code / Codex / Cursor / OpenCode adapters
Worktree isolation and symlinked shared state	`coral/workspace/worktree.py`	`create_project()`, `create_agent_worktree()`, `setup_shared_state()`
Attempts / leaderboard memory	`coral/hub/attempts.py`	`write_attempt()`, `read_attempts()`, `get_leaderboard()`
Notes / skills memory	`coral/hub/notes.py`, `coral/hub/skills.py`	`list_notes()`, `search_notes()`, `list_skills()`, `read_skill()`
Grader abstraction and task-specific evaluator	`coral/grader/base.py`, `coral/grader/task_grader.py`, `coral/grader/loader.py`	`BaseGrader`, `TaskGrader`, `load_grader()`
Evaluation daemon	`coral/grader/daemon.py`	pending-attempt watcher, timeout grading, eval-count increment
CLI interface exposed to agents	`coral/cli/*.py`	`start`, `eval`, `query/log/show`, `heartbeat`, `ui` commands
Data model	`coral/types.py`	`Task`, `Score`, `ScoreBundle`, `Attempt`

论文公式与 released code 实现差异：核心公式 $E (x, y) = (s, f)$ 、 $M_{t} \to \hat{M}_{t}$ 、 $C_{t}^{(i)} \to C_{t}^{' (i)}$ 是抽象框架，released code 对应的是文件系统、CLI、worktree、daemon 与 dataclass，而不是一个单独的训练 loss。更重要的差异在实验配置：论文 Table 2 / Appendix B.1 报告 Polyominoes stress test 使用 Claude Opus 4.6 + Claude Code，但当前 examples/frontier_cs_algo/0/task.yaml 在 main@3d002bfd 中是 model=claude-sonnet-4-6, count=1, max_turns=200, grader.timeout=340；论文 Appendix D.2 写 Kernel Builder grader timeout 为 600s，而当前 examples/kernel_builder/task.yaml 是 timeout=120, model=claude-opus-4-6, count=1。因此本文实验数字按 paper reported results 记录，复现实验配置需以相应 commit 的 task YAML 为准，不能把当前 example defaults 直接当作论文所有 run 的 launch config。

Figure 5 解读：这组 UI 图展示了 CORAL 的两个实际观测面板：overview 页显示 attempts 轨迹、分数、状态、时间戳和 per-agent activity；knowledge 页显示 notes 与 skills。它说明论文中的 shared persistent memory 不只是概念，而是系统可视化和调试的一等对象。

4. Experimental Setup (实验设置)

任务与数据规模

论文评估覆盖两类 benchmark suite 和两个 stress-test problem。第一类是 6 个 mathematical optimization tasks，例如 Circle Packing、Signal Processing、Erdős Minimum Overlap、MMD-16-2、MMD-14-3、Third Autocorrelation Inequality；第二类是 5 个 systems optimization tasks，例如 Expert Parallelism Load Balancing (EPLB)、PRISM、LLM-SQL、Transaction Scheduling、Cloudcast。两个 stress test 是 Anthropic Kernel Engineering 和 Frontier-CS Polyominoes Packing；Polyominoes 来自 Frontier-CS benchmark，是 172 个问题中最难的一个，released code examples/frontier_cs_algo/0/task.yaml 中该任务 grader 使用 70 test cases、2s/test、256MB memory。

Baselines, models, and budget

单 agent 实验把 CORAL 与 OpenEvolve (OE)、ShinkaEvolve (SE)、EvoX 比较；所有方法使用相同 seed programs、evaluators 和 budgets。数学/系统 suite 的所有 run 使用 3-hour wall-clock budget 或 baseline 100 iterations 中更长者，结果平均 4 independent trials。single-agent 与 stress-test multi-agent 实验使用 Claude Code + Claude Opus 4.6；数学/系统 suite 的 multi-agent 实验使用开源栈 MiniMax M2.5 + OpenCode 且无 internet access，用于验证 co-evolution 不依赖专有 agent。

stress-test 在论文主文中按收敛运行；Appendix E.1 进一步说明 stress-test problems 在连续 100 evaluations 无提升或 2 hours 后停止，以先发生者为准，multi-agent 使用 4 agents 并匹配 wall-clock time。released code 配置示例包括：examples/kernel_builder/task.yaml（Kernel Builder: count=1, runtime=claude_code, model=claude-opus-4-6, grader.timeout=120, direction=minimize）；examples/ADRS/txn_scheduling/task.yaml（Transaction Scheduling: model=claude-opus-4-6, research=false, grader.timeout=600, direction=maximize）；examples/ADRS/eplb/task.yaml（EPLB: timeout=360）；examples/ADRS/cloudcast/task.yaml（Cloudcast: timeout=600）。当前 repo 的 AgentConfig 默认 heartbeat 为 reflect every 1、consolidate every 10、pivot plateau every 5，但论文 run 中的具体 task YAML / appendix 配置应优先于 defaults。

Metrics

Final score：budget 内达到的最佳分数；对 $↑$ 任务越高越好，对 $↓$ 任务越低越好。
Improvement rate：所有 evaluator submissions 中刷新 best score 的比例，衡量每次 eval 的有效性。
# Evals：达到最终 best score 所需评估次数，衡量 sample / evaluation efficiency。
Trajectory statistics：Local Test、Test $\to$ Impr.、Attempt Inspect、Knowledge Created、Knowledge Access、Read $\to$ Impr.，用于解释 autonomous evolution 和 shared memory 的作用。

5. Experimental Results (实验结果)

5.1 Single-agent CORAL 显著超过固定演化搜索

Table 1 显示，single-agent CORAL 在 11 个数学/系统优化任务上全部取得最佳 final score，并在 8/11 个任务上建立新 SOTA。关键数字如下：

Task	SOTA	OpenEvolve	ShinkaEvolve	EvoX	CORAL	CORAL Impr. Rate	CORAL Evals
Circle-Pack. $↑$	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
Erdős Over. $↓$	0.38088	0.38188	0.38156	0.38125	0.38089	36.8	19
MMD-16-2 $↓$	12.89	12.92	12.89	12.96	12.89	83.3	6
MMD-14-3 $↓$	4.16	4.21	4.46	4.46	4.16	75.0	8
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
PRISM $↑$	26.26	26.26	26.26	26.26	26.26	100.0	3
LLM-SQL $↑$	0.730	0.716	0.724	0.726	0.731	53.3	15
Txn Sched. $↑$	4348	3774	3802	3984	4566	27.3	22
Cloudcast $↓$	632.7	627.2	627.8	623.5	618.4	33.3	9

论文总结为 CORAL 的 improvement rate 比固定演化搜索高 3–10×，通常 5–20 次 eval 内收敛，而固定方法常需 60–100 次 eval。解释上，CORAL 不是盲目 mutation：agent 会根据 prior attempts 和 feedback 决定改哪里、何时 pivot、何时提交，因而少浪费 evaluator calls。

5.2 Multi-agent co-evolution 进一步扩展 frontier

Table 2 比较 1-agent 与 4-agent CORAL。stress-test 上提升最大：Kernel Engineering 从 1350 cycles 降到 1103 cycles，Gain 18.30%；Polyominoes 从 80.2 提到 84.2，Gain 4.99%。在开源栈 MiniMax M2.5 + OpenCode 的 math / system suite 上，4-agent 也大多优于 1-agent，例如 Signal Processing 0.7174 $\to$ 0.7383，LLM-SQL 0.693 $\to$ 0.730，Cloudcast 849.4 $\to$ 672.8。

Figure 0 解读：首页结果图聚焦 Anthropic Kernel Engineering。OpenEvolve 用 363 eval 达到 2740 cycles / 53.9×；single-agent CORAL 用 56 eval 达到 1350 cycles / 109.4×；4-agent CORAL 用 596 eval 达到 1103 cycles / 133.9×，超过 1363 cycles best-known baseline。注意 4-agent 的 improvement rate 是 9% (54/596)，低于 single-agent 的 43% (24/56)，但它探索范围更广，最终 frontier 更高。

Figure 3 解读：Polyominoes Packing 的目标是把所有 polyominoes 尽量紧密塞进网格、减少 unused area。Claude Opus 4.6 single attempt 只有 56.0% coverage；CORAL 4-agent + Claude Code + web search 在 Appendix B.1 达到 89.4%，超过先前 87% SOTA。图中右侧几乎填满网格，说明 CORAL 不只是提升代码 benchmark，也能在组合优化/启发式设计任务中积累有效策略。

5.3 机制分析：local verification、knowledge accumulation 与 cross-agent transfer

论文的 trajectory analysis 说明 gains 来自可解释行为，而不是只有更多 compute。

Task Type	Task	Impr. Rate	Local Test	Test $\to$ Impr.	Attempt Inspect	Know. Created	Know. Access	Read $\to$ Impr.
Standard	Average	24%	24%	37%	25%	0.05	7%	26%
Advanced	Polyominoes	30%	11%	40%	17%	0.55	30%	38%
Advanced	Kernel Eng.	43%	57%	47%	47%	0.68	17%	55%

Local verification 在 compiled-code tasks 中特别重要：Transaction 的 local test rate 为 61%，Kernel Engineering 为 57%，能在消耗外部 evaluation 前捕获编译或正确性错误。Knowledge accumulation 在 advanced tasks 中更明显：standard tasks 每次 attempt 只产生 0.05 个 knowledge artifacts，而 Polyominoes / Kernel Engineering 分别为 0.55 / 0.68；Kernel Engineering 中访问知识的 attempts 有 55% improvement rate。

multi-agent transfer 也有定量证据。Kernel Engineering 中 36% attempts 使用其他 agent commit 作为 parent，这类 attempts 的 improvement rate 为 17%，高于全体平均 9%；66% new records 来自 cross-agent parent。Polyominoes 中直接 code transfer 只有 12%，但 improvement rate 达 50%，且 87% rounds 引用了其他 agents 写入的 knowledge。策略关键词的 pairwise Jaccard similarity 在 Kernel Engineering 为 0.43、Polyominoes 为 0.31，说明每个 agent 都保留大量 unique strategy vocabulary。

5.4 Ablation：知识积累和 co-evolution 都不是装饰项

Table 3 对两个核心组件做消融。禁用 note / skill creation 会让 Kernel Engineering 从 1350 cycles 退化到 1601 cycles（18.6% regression），Polyominoes 从 80.2 降到 77.3，Transaction Scheduling 从 4566 降到 4444。co-evolution 与 4 个独立 single-agent runs 的 best-of-4 相比也有优势：Kernel Engineering 1103 vs 1180，Polyominoes 84.2 vs 80.8，Transaction Scheduling 4694 vs 4629。这说明 multi-agent gains 不是简单多跑几份 compute，而来自 agents 之间共享 attempt/code/notes/skills 后形成的耦合搜索。

5.5 局限与结论

作者明确列出三点限制。第一，当前 CORAL 仍依赖能处理复杂 coding-agent workflow 的 frontier foundation models，完整本地部署困难；未来可能需要针对 CORAL 训练小模型。第二，multi-agent evolution 目前缺少 bootstrapped heterogeneity：agents 初始相同、信息相同；未来可加入不同 personality、role 或 private information 来提高行为多样性。第三，当前假设存在 reasonably well-specified evaluator；但很多真正开放问题的 evaluator 本身不完整或有歧义，未来可能需要 solution 与 evaluator 一起 co-evolve。

总体而言，CORAL 的实验证据支持一个清晰结论：在 open-ended discovery 中，把更多搜索控制权交给长期运行 agent，并让多个 agent 通过共享持久记忆异步协作，可以比固定演化搜索更高效地积累知识、复用突破并推进 frontier。

Paper Notes

探索

CORAL: Towards Autonomous Multi-Agent Evolution for Open-Ended Discovery

CORAL: Towards Autonomous Multi-Agent Evolution for Open-Ended Discovery

1. Motivation (研究动机)

现有 LLM-based evolution 的瓶颈：外层搜索仍然是固定算法

多智能体系统的另一类刚性：角色与通信结构预设

CORAL 要解决的具体问题

2. Idea (核心思想)

3. Method (方法)

3.1 问题形式化：从候选解评估到四阶段循环

3.2 Shared Persistent Memory：把演化 population 扩展成可读写知识库

3.3 Asynchronous Multi-Agent Organization：水平扩展探索，而不是硬编码角色

3.4 Heartbeat：轻量干预长期 agent 的反思、整理与换方向

3.5 Grader isolation 与 execution safeguards：让 agent 能优化但不能偷看 evaluator

3.6 Pseudocode：基于 released code 的关键组件流程

3.7 Code-to-paper mapping

4. Experimental Setup (实验设置)

任务与数据规模

Baselines, models, and budget

Metrics

5. Experimental Results (实验结果)

5.1 Single-agent CORAL 显著超过固定演化搜索

5.2 Multi-agent co-evolution 进一步扩展 frontier

5.3 机制分析：local verification、knowledge accumulation 与 cross-agent transfer

5.4 Ablation：知识积累和 co-evolution 都不是装饰项

5.5 局限与结论

目录