Agora: Git as Shared Memory for Collective AutoResearch

• 关联论文：2609.18094
• 作者：Tom
• 更新：2026-09-17

一句话结论

Agora 是一个让多个 LLM Agent 共享研究状态的协作系统：将每个研究贡献（发现、假设、验证、报告）建模为 Git commit，构成一条可溯源的 DAG（有向无环图），使多个 Agent 在无需中央调度的情况下实现去中心化的集体科学研究。

解决什么真问题

AutoResearch 等自主研究框架证明单个 LLM coding agent 可以独立改进训练配置（如超参数调优）。但当多个 Agent 同时运行时，每个 Agent 都从零开始，导致一个残酷的问题——Agent 越多，重复劳动越多，而不是发现更多。计算资源线性增长，但研究质量呈边际递减。

根本矛盾在于：缺乏共享研究状态。每个 Agent 的中间发现、验证结果、失败教训都存储在各自的 context window 中，既不可被其他 Agent 复用，也无法跨 session 持久化，更无法追溯"这个结论是谁在什么基础上得出的"。

Agora 的目标是：把 Git 版本控制的思路移植到 AI 集体研究场景，让多个 Agent 像开源社区协作开发代码一样协作推进科学研究。

核心方法

用 Git DAG 做共享记忆

Agora 的核心抽象是：每个研究贡献都是一条 Git commit，而 commit 之间的关系（有向无环图，DAG）记录了研究思路的演化路径。

研究贡献的 commit 类型：
- hypothesis（假设）: 提出新解释或方向
- verification（验证）: 验证某个假设或结果
- insight（洞察）: 分析实验结果后的解读
- result（结果）: 具体的实验数据或发现
- report（报告）: 阶段性总结

每个 commit 包含： - 内容：贡献的具体描述 - parent edges（父边）：指明该贡献建立在哪些已有贡献之上 - 不可变性：commit 一旦写入不可修改，保证研究历史的真实性

派生索引（Derived Index）

Git DAG 本身是底层存储，Agora 在其上构建了派生索引来暴露关键信息：

1. Frontier（研究前沿）：当前还没有后续验证或反驳的最前沿假设
2. Neglected branches（被忽视的分支）：有贡献但无人跟进的思路
3. Verification status（验证状态）：每个 claim（声明）是否已被独立验证

多样性感知选择规则（Diversity-Aware Selection）

如果让所有 Agent 都去跟进最热门的方向，会造成信息同质化（ monoculture problem）。Agora 引入多样性感知规则：Agent 在选择下一个研究目标时，倾向于选择那些与当前主流方向不同、但有潜力的分支，防止群体思维。

单次中后期人类干预

实验中出现了一个值得注意的案例：研究社区在某一时刻出现了 monoculture（所有 Agent 都朝同一方向蜂拥），此时有一次人类干预将社区拉回了多样化方向。这个案例说明即使有机制设计，AI 群体仍可能在局部极小化，需要人类在关键节点做方向性纠偏。

关键实验设置

参数	值
Agent 数量	13 个语言模型 workers
任务类型	weight-transfer 问题（无训练数据、无梯度更新）
目标模型	119.6M 参数的 attention-SSM hybrid（维度与任何 donor 模型不匹配）
Donor 模型池	141 个预训练模型
初始 evaluator	3.39 bits per byte
最终 evaluator	1.899 bits per byte
gap 关闭比例	62%（相对于已训练 GPT-2 124M）
获胜方案 commit 数	145 commits
独立复现数量	165 次，且无一失败

获胜方案的技术细节

最终胜出的解决方案将 donor 模型的 next-token 统计信息压缩到目标模型的 embedding 和 output head 中，通过稀疏编辑（sparse edits）向 attention、feed-forward 和 state-space 模块注入短程上下文信号。这说明在极端约束下（无梯度、无训练数据），将知识从大模型压缩到小模型是可行的，代价是 commit 链路极长（145 commits / 15 个账户）。

亮点与局限

亮点：

1. 去中心化、无中央调度：13 个 Agent 没有任何分配任务，无中央规划者，但自发形成了有效协作，说明共享记忆+贡献追溯足以支撑分布式研究
2. 研究历史的不可篡改性：Git commit 的不可变特性天然适合科学研究的可复现性要求——任何人都可以 git checkout 到任意历史状态并重跑
3. 验证状态追踪：每个 claim 的"是否被独立复现"直接嵌入 DAG，区别于传统知识库的全量存储——只存储"争议点"而非"共识"
4. 165 次独立复现无一失败：这一数据为"共享研究状态是否真的有效"提供了强验证（但实验设计本身是受控的）

局限：

1. 任务特殊性：weight-transfer 问题相对结构化（清晰的 evaluator 指标 bits-per-byte），真实科学研究问题往往没有如此明确的评估函数
2. 人类干预依赖：实验中出现了一次 monoculture 危机需要人类介入，说明机制设计尚不能完全避免群体思维
3. 可扩展性存疑：13 个 Agent + 141 个 donor 模型产出了 1,703 条 contributions，165 次复现——这个数据量级对于 Git DAG 来说管理难度尚可，但扩展到数百 Agent、数万条贡献时，索引效率和 Agent 的检索成本会显著上升
4. "受控比较"尚未完成：作者在文中坦承，controlled comparison（共享研究状态 vs 各自独立研究）尚未进行，目前的数据无法直接证明共享状态带来的边际收益

对工程落地的启发

1. Multi-Agent RAG 系统：多个 Agent 协作搜索知识库时，可以用 DAG 结构记录每条证据的来源和验证状态，而不是让所有 Agent 都独立检索同一份向量数据库
2. Agent 记忆的版本化管理：借鉴 Git 的分支/合并模型，Agent 的长期记忆可以建模为一系列 commit，新的经验建立在旧经验之上，支持回滚和分支探索
3. 去中心化代码生成流水线：在代码生成场景，多个 Agent 可以像 Agora 一样分别负责不同模块，通过 commit DAG 追踪依赖关系，避免重复生成相似代码
4. 科学研究 AI Agent 基础设施：Agora 验证了"LLM Agent 协作 = Git DAG + diversity-aware selection + 派生索引"这一范式的可行性，为 AI-for-Science 平台提供了基础设施参考

与同方向工作的关系

工作	协调方式	记忆持久化	验证机制
AutoResearch (Karpathy)	单 Agent 递归循环	无	无
AgentMemory (RohitG)	BM25 + 向量	有（本地文件）	无
Memoria	Git-like 版本控制	有	无
Agora	Git DAG + diversity-aware	有	有（verification status）
EvolveMem	AutoResearch 扩展	有	无

Agora 与其他 Agent 记忆系统的核心区别在于引入了研究验证状态的追踪：不是简单存储"Agent 知道什么"，而是存储"每个 claim 是否被独立验证过"，这对于科学知识管理至关重要。

适合谁读

• Multi-Agent 系统架构师：了解去中心化 Agent 协作的共享记忆设计范式
• AI-for-Science 平台开发者：探索如何用版本控制思路管理 AI 科学研究过程
• LLM Agent 开发者：关注 Agent 长期记忆、经验积累与可复现性
• 自动化研究工程团队：想了解如何构建多 Agent 协作的科学研究流水线

⚠️ 存疑：Controlled comparison（共享状态 vs 独立研究）的具体数据和实验设计原文未完整披露，建议阅读 PDF §4 和 §5 获取完整的对比实验数据和消融分析。

---

Tom · 2026-09-17 · 主稿基于 arXiv 2609.18094 abstract;具体实验数据与 controlled comparison 设计待 PDF §4–§5 核验。

工程落地与核查（Jay）

落地路径：如何在真实 Multi-Agent 系统里实现 Agora 范式

第一步：Commit Schema 设计

以下是工程可用的最小 commit schema，保留核心字段、去掉过于理想化的冗余：

@dataclass
class ResearchCommit:
    commit_type: str          # hypothesis / verification / insight / result / report
    content: str               # 贡献内容（自然语言）
    parent_ids: list[str]     # 父 commit IDs（DAG 边）
    author_agent: str          # Agent ID
    timestamp: str             # ISO 8601
    verification_status: str  # unverified / partially_verified / independently_verified / disputed
    verification_refs: list[str]  # 指向验证该 claim 的 commit IDs
    tags: list[str]           # 关键词标签，用于检索

⚠️ 坑 1（commit 膨胀）：每次 agent 执行都写 commit → 100 个 agent × 每天 100 次执行 = 每天 10K 条 commits。需要在 client 侧做批量合并（把 5 分钟内的同类型 commit 合并成一条）+ 定期归档（超过 7 天的 commits 移到冷存储）。

第二步：DAG 存储选型

存储方案	适用规模	优点	缺点
SQLite + adjacency list	< 100K commits	零依赖，单文件	并发写入差
PostgreSQL + recursive CTE	100K–10M commits	成熟，DAG 查询高效	需要运维
Neo4j / Amazon Neptune	10M+ commits	原生 DAG 支持，查询语言强	运维成本高
Git native（如 gitdir）	小团队（< 10 agents）	完全复用 Git 生态	多人协作时 merge conflict 复杂

推荐首发方案：PostgreSQL + adjacency list，batch insert 支持高并发写入，recursive CTE 支持 DAG 查询（找 frontier、找 verified claims）。

第三步：Diversity-Aware Selection 实现

def diversity_aware_select(available_commits, agent_state, diversity_weight=0.3):
    """
    在 exploration（探索新方向）和 exploitation（跟进已有线索）之间平衡
    diversity_weight ∈ [0, 1]，越高越强制选不同方向的 commit
    """
    # 1. 计算每个候选 commit 与当前 agent 主流方向的主题距离
    candidate_scores = []
    for commit in available_commits:
        # 主题 embedding
        commit_emb = embed(commit.content)
        agent_emb = embed(agent_state.current_focus)

        # 主题相似度
        topic_sim = cosine_similarity(commit_emb, agent_emb)

        # 价值分（基于 verification_status 和 recency）
        value_score = 1.0 if commit.verification_status == 'independently_verified' else 0.5

        # 综合分 = (1-diversity_weight) * value_score + diversity_weight * (1 - topic_sim)
        combined = (1 - diversity_weight) * value_score + diversity_weight * (1 - topic_sim)
        candidate_scores.append((commit.id, combined))

    # 2. 加权采样（不是贪心选最高，避免总是选同一个）
    return weighted_sample(candidate_scores, top_k=3)

⚠️ 坑 2（diversity_weight 调参）：weight 太高 → 所有 agent 都在探索无人问津的死路；weight 太低 → 退化成贪心，跟标准 RAG 没什么区别。建议从 diversity_weight=0.3 开始，每 500 commits 跑一次 diversity 指标（branch spread）做 adaptive 调整。

第四步：Verification Status 的工程实现

这是 Agora 区别于普通知识库的核心，也是最容易形式主义失效的地方：

def verify_claim(claim_commit_id, verifier_agent_id, verification_result):
    """
    verification_result: 'confirmed' / 'refuted' / 'inconclusive' / 'partial'
    """
    # 1. 独立验证要求：verifier 不能与 original author 是同一 agent
    original_author = get_commit(claim_commit_id).author_agent
    if verifier_agent_id == original_author:
        return {"error": "Same-agent verification not counted as independent"}

    # 2. 验证结果写入（不可篡改，append-only）
    verification_record = {
        "claim_id": claim_commit_id,
        "verifier": verifier_agent_id,
        "result": verification_result,
        "evidence_commit_ids": [],  # 验证过程引用的 commits
        "timestamp": now()
    }
    append_verification_record(verification_record)

    # 3. 更新 claim 的 verification_status
    update_verification_status(claim_commit_id)

    return {"status": "recorded", "verification_count": get_verification_count(claim_commit_id)}

⚠️ 坑 3（verification 刷分）：同一 agent 多次验证同一 claim 不应累加计数，但系统需要检测和拒绝同 agent 的重复验证。建议在 verification record 里加 agent_id 唯一约束。

第五步：Human-in-the-loop 触发条件

文中提到出现一次 monoculture 后人类介入，以下是工程化的触发条件：

MONOCULTURE_THRESHOLD = {
    "top_branch_coverage": 0.70,      # 最热门方向占比 > 70% 触发警报
    "stagnation_rounds": 5,            # 连续 5 轮无新验证状态更新触发警报
    "human_review_interval_hours": 48  # 至少每 48 小时做一次人类审计
}

def check_monoculture(commit_log):
    top_branch = get_top_branch_coverage(commit_log)
    if top_branch > MONOCULTURE_THRESHOLD["top_branch_coverage"]:
        return {"alert": "monoculture", "action": "require_human_review"}
    return {"alert": None}

⚠️ 坑 4（人类介入的有效性）：文中提到"一次人类干预将社区拉回多样化方向"，但没有量化干预方式。工程上需要设计低摩擦的人类介入界面（不能要求人类 review 所有 commits），建议用「人类点一个方向 → 所有 agent 强制扩展该方向 ≥ 3 层」而非直接编辑 DAG。

⚠️ 已知未解决问题 / 待 PDF 核验

1. GitHub / 代码开源：abstract 未提及开源仓库。若无代码，工程实现需自行从零设计 DAG 存储 + diversity selection + verification 逻辑，成本显著增加。
2. Controlled comparison 数据：作者承认尚未完成（共享状态 vs 独立研究的受控对比），当前证据强度有限。62% gap closure 是 weight-transfer 任务专属数字，不能泛化到其他任务类型。
3. 13 agents 的协作策略：abstract 未说明 13 个 agent 之间的通信协议、commit 写入冲突解决机制，也未说明 diversity-aware selection 的具体参数。
4. Bits-per-byte 1.899 的意义：119.6M 参数 attention-SSM hybrid 上从 3.39 → 1.899 bits/byte 的改善是压缩效率指标，与 LLM 生成质量（困惑度、BLEU 等）没有直接对应关系，不宜直接解读为「模型性能」。
5. 165 次复现：weight-transfer 任务的数学性质决定了复现确定性高（evaluator 是确定性的 bits-per-byte），这不代表其他任务上也能做到零失败复现。

事实核查笔记（Jay 审校）

• arXiv ID 2609.18094：文件名对应正确（2609-18094.md）
• 13 agents / 141 donor models / 119.6M target：abstract 数据，weight-transfer 任务的典型配置，具体合理性依赖 PDF 核验
• 3.39 → 1.899 bits per byte：abstract 原话，gap closure 62% 由此推算而来。⚠️ bits-per-byte 是压缩/建模指标，不是直接性能指标，不等同于困惑度或生成质量
• 165 次独立复现无一失败：weight-transfer 任务（evaluator = 确定性的 bits-per-byte 计算）上，复现天然确定性高，不能外推到其他有随机性的任务
• 145 commits / 15 个账户：abstract 原文，145 条 commit 链路的复杂度在 13-agent 协作规模下合理
• Controlled comparison 未完成：原文作者自己承认，是本文可信度的最大限制因素，⚠️ 标注「原文未完整披露」准确
• 与 AutoResearch / AgentMemory / Memoria 的对比：表格内容为解读推断，abstract 中未给出具体 comparison table，⚠️「原文未完整披露」标注必要