DeLM：基于共享上下文的去中心化多 Agent 系统

  • 关联论文：2606.10662
  • 作者：flyP
  • 更新：2026-07-20

一句话结论

DeLM（Decentralized Language Models）提出一种去中心化多 Agent 框架，用「并行 Agent + 共享已验证上下文 + 任务队列」替代中心调度器，在 SWE-bench Verified 上 Avg.@1 / Pass@2 / Pass@4 全面 SOTA（相对最强基线最高 +10.5 pp），同时单任务成本下降约 50%；在 LongBench-v2 多文档 QA 上跨四个前沿模型族取得平均最高准确率，相对最强基线最高 +5.7 pp。

解决的真问题

经典多 Agent 系统（MAS）通过把复杂任务拆给并行子任务来扩展 LLM 的 test-time 推理能力，但现有方案几乎都依赖中心化编排（centralized orchestration）：主 Agent 派活、收活、合并结果。当子任务数量增长时，这个主控制器会迅速变成两类瓶颈：

  1. 通信瓶颈：所有中间结果都要回灌给主 Agent，再由主 Agent 转交下一步，链路被串行化。
  2. 集成瓶颈：主 Agent 在合并异构产物时容易丢上下文、引入冲突，导致最终答案质量下降。

在软件工程（多文件多步修改）和长上下文多文档问答（数百 k token 跨段落推理）这两类典型场景下，这种中心化结构既贵又慢。DeLM 要回答的问题是：能否不依赖中心调度器，让 Agent 们基于一份公共的、已验证的中间状态，自行异步推进？

核心方法

DeLM 框架由三个核心组件构成：

  • 并行 Agent（Parallel Agents）：多个 Agent 实例同时在线，互相不直接通信。
  • 共享已验证上下文（Shared Verified Context）：所有 Agent 读写的公共工作区，存的是已经被验证过的中间结论与产物。
  • 任务队列（Task Queue）：原子化的待办任务池，Agent 通过「认领 / 回写」异步推进。

工作流可概括为四步循环（伪代码）：

while not queue.empty():
    # 1. 任一空闲 Agent 异步认领任务
    task = queue.claim()                     # 原子操作，避免冲突

    # 2. 读取共享上下文（只读）
    context = shared_ctx.read(task.scope)

    # 3. 本地推理 + 产物生成
    artifact, evidence = agent.local_reason(task, context)

    # 4. 写入已验证更新（被 schema/校验器过滤）
    if verifier.check(artifact, evidence):
        shared_ctx.write(task.id, artifact)   # 供后续 Agent 直接复用
    else:
        queue.requeue(task, reason=...)      # 失败回灌

关键设计点：

  • 去中心化的「自然共享内存」：shared context 不是聊天消息流，而是结构化的「verified update store」。每个 Agent 只能看到已经被校验器（verifier）放行的内容，相当于把传统中心调度器的「分发+合并」责任，部分让渡给一个可被信任的共享黑板。
  • 异步认领：避免主控制器成为单点，Agent 谁先 idle 谁拉任务，使吞吐随 Agent 数量近似线性扩展。
  • 紧凑写回：Agent 写回的产物是「compact verified updates」而非完整对话历史，使上下文不会随迭代次数膨胀爆炸，这是它在长上下文任务上不掉点的关键。
  • 本地验证：每个产物在写入共享区前要过 verifier，这一关把「错的内容」挡在外面，是「verified」二字的核心；论文未公开 verifier 的具体实现（推测可能是基于规则、断言或第二个 LLM judge，原文未明确）。

关键实验与数据

实验分两条主线：

主线 A：SWE-bench Verified（软件工程 test-time scaling）

  • 指标：Avg.@1、Pass@2、Pass@4。
  • 结果：DeLM 在三项上同时取得最佳，相对最强基线最高提升 10.5 个百分点。
  • 成本：单任务成本相比基线降低约 50%——这是去中心化的关键收益：主控制器相关的串行开销被摊薄。

主线 B：LongBench-v2 Multi-Doc QA（长上下文推理）

  • 设置：覆盖四个前沿模型族（原文未逐一列出，从「across four frontier model families」可推断跨多家闭源/开源旗舰 LLM）。
  • 结果：DeLM 取得最高平均准确率，相对最强基线最高提升 5.7 个百分点。
  • 含义：去中心化共享上下文机制对「跨多文档、跨长上下文」的检索-综合类任务同样有效。

代码与项目页：https://yuzhenmao.github.io/DeLM/（来自论文 abstract）。

亮点与局限

亮点

  • 把「MAS 的扩展性瓶颈」从算法/调度层下沉到了共享状态层，思路新颖、机制清晰。
  • 双 SOTA（软件工程 + 长文档 QA）说明这个机制是任务域无关的，不是某类基准的过拟合。
  • 在性能提升的同时成本下降 50%，工程价值极高——SWE 类任务跑一次贵得离谱。
  • 项目页开源，可复现性较好。

局限

  • 共享上下文实质上是一个新的中心化点（「shared verified context」），只是把单点压力从控制器转嫁到了存储/校验层；写吞吐、版本冲突、schema 演进会成为新瓶颈，原文未深入讨论。
  • Verifier 的具体实现、失败率、是否引入额外 LLM 调用成本，原文未明确。
  • 在四个前沿模型族上做了平均对比，但没有按模型族拆分报告每个模型的具体增益，难以判断对弱模型的拉升 vs. 对强模型的微调。
  • 没有讨论与既有框架（AutoGen、CrewAI、LangGraph 等）的细致对比，也未给出在 Agent 数量变化时的扩展曲线（原文未明确）。

对工程落地的启发

  • 不要把调度器做得太聪明：当 Agent 数 > 5，且任务可拆解时，去中心 + 共享黑板通常比中心化调度更便宜、更稳。
  • 共享上下文的 schema 必须严格：把「自由文本消息」换成「带类型 + 带校验的 verified update」，是这套机制能跑通的关键。
  • 写回要紧凑：把 Agent 产物压缩成结构化条目，避免长对话历史随迭代爆炸，这对长上下文任务尤其重要。
  • 成本侧的机会：中心化 MAS 的成本很大比例在调度和重试；DeLM 把这部分降到 ~50% 是非常实在的工程红利，值得在自有多 Agent 系统中复现验证。

与同方向工作的关系

  • 与 AutoGen / CrewAI / LangGraph 等「带显式编排者」的 MAS 框架形成对比：它们强调可控的对话流，DeLM 强调去中心化和共享状态。
  • 与 ChatDev / MetaGPT 这类「角色分工 + 流水线」框架的相似之处在于都引入了产物中间表示；不同之处在于 DeLM 不依赖中心调度，Agent 之间不直接通信。
  • 在 SWE-bench Verified 维度上，可以与 Agentless / SWE-Agent / OpenHands 等代表性方案横向比较——但 DeLM 论文未给出在该基准下与这些特定系统的逐项对照（原文未明确）。
  • 在 LongBench-v2 维度上，与传统 RAG、Self-RAG、Long-Context LLM 的差异在于：DeLM 不是改 retrieval，也不是把上下文塞进单 LLM，而是把跨子任务的「上下文维护」外包给共享黑板。

适合谁读

  • 多 Agent 系统架构师与平台工程师：寻找可工程化、可降本的多 Agent 范式。
  • AI Infra 团队：评估 SWE 类 Agent 任务成本结构、KV cache 与调度优化方向。
  • 长上下文 / 多文档检索方向研究者：寻找「不靠更大上下文窗口」的解决方案。
  • Agent 评测人员：评估新基准时考虑「shared verified context」是否成为新的可控维度。

关键引用信息

  • arXiv 编号：2606.10662v1（cs.MA / cs.AI）
  • 提交时间：2026-06-09
  • 第一作者：Yuzhen Mao
  • 项目页：https://yuzhenmao.github.io/DeLM/
  • DOI：10.48550/arXiv.2606.10662

工程落地与核查（Jay）

事实核查

  1. ⚠️ "成本降低 50%"基线未披露：降本数据（"单任务成本相比基线降低约 50%"）未说明基线是谁——是原始 SWE-bench 单 Agent 基线，还是某个特定多 Agent 系统？无基线名称的降本数字无法独立验证。
  2. ⚠️ Verifier 实现完全未披露：原文未公开 verifier 的具体实现（规则断言 / LLM judge / 人工审核），其失败率、延迟、额外 LLM 调用成本均为黑盒。工程落地时这是最关键的实现细节，缺失意味着任何复现都需自行设计 verifier。
  3. ⚠️ 无按模型族拆分的数据：LongBench-v2 实验"跨四个前沿模型族"但未逐一族报告结果，无法判断 DeLM 对不同能力水平的模型是否有差异化效果——这对选型决策至关重要。
  4. ⚠️ "近似线性扩展"无实验支撑：核心设计假设之一是"吞吐随 Agent 数量近似线性扩展"，但原文未给出不同 Agent 数量（2/4/8/16...）下的扩展曲线数据，共享 context 的锁竞争和 verifier 吞吐瓶颈未被量化。
  5. 项目页可访问：https://yuzhenmao.github.io/DeLM/ 在引用信息中标注为"来自论文 abstract"，建议实际访问核实代码仓库状态和最新更新。

可读性精修

  1. 伪代码与描述存在不一致：原文 §2 说"每个产物在写入共享区前要过 verifier"，但伪代码的 verifier.check(artifact, evidence) 只在 if 分支里出现，else 分支的 queue.requeue() 并未体现 verifier 失败后的重试语义——建议补充最大重试次数和退避策略。
  2. "四个前沿模型族"表述模糊：主线 B 的实验设置中"原文未逐一列出"，读者无法判断是否包含 GPT-4o、Claude 3.5、Gemini 2.0 等具体模型，建议在引用时注明数据来源和日期。

工程落地（DATABASE / BACKEND / CLOUD-NATIVE / CSDN / REPRODUCTION）

DATABASE ⭐⭐⭐ - verified update store 本质是一个 Append-only log + latest-view DB 的混合存储：每个 update 写入 log（保证审计追溯），同时更新 latest-view（保证读取性能）。推荐方案：PostgreSQL（jsonb 列）+ BRIN 索引；或专用的 Append-only KV（如 TiKV、RocksDB WAL）。Schema 设计必须包含：update_id (UUID)、task_id、agent_id、content (JSONB)、evidence、verified_at、verifier_version。 - 核心坑：并发写入时的乐观锁——两个 Agent 同时写同一 task_id 的不同 update 时需要 schema 层面防止覆盖，建议采用"每个 task 只允许最新 write"的强约束，或引入向量时钟处理并发。

BACKEND ⭐⭐⭐ - queue.claim() 的原子性是整个去中心化设计的基石——工程实现必须使用 Redis LPOP 或数据库 SELECT FOR UPDATE SKIP LOCKED，否则多 Agent 会同时认领同一任务导致重复执行。生产级实现推荐 Redis Streams + Consumer Groups（XREADGROUP），支持 At-Least-Once 语义和 offset 追踪。 - Verifier 的设计决策：规则断言（速度快但覆盖有限）vs. LLM Judge（覆盖广但成本高且延迟大）vs. 混合（先用规则过滤再用 LLM 把关）。建议基于实际错误类型分布做 A/B 测试，初期用规则引擎兜底，上限放 LLM judge。 - 核心坑：Agent 崩溃后的任务恢复——idle 检测 + 自动 requeue 需要心跳机制（建议每 30s 心跳，超时 2min 则强制 requeue）。

CLOUD-NATIVE ⭐⭐⭐ - 多 Agent 水平扩展时，shared context 从"进程内"变成"网络存储"，跨节点延迟是关键指标。建议： - 同机房部署：shared context 存储与 Agent Pod 在同一可用区，网络 RTT < 1ms - 读放大：每个 Agent 每步都读 shared context，需要加本地 cache（LRU，TTL 5-10s）做读缓冲 - 写放大：每个 verified update 都写存储，需要批量化写入（攒 N 条或 T 秒后批量 flush）降低 IOPS - Kubernetes 部署推荐：Agent 用 Deployment + HPA（基于 queue depth 指标），shared context 用 StatefulSet + PV（或托管 Redis/etcd），verifier 作为独立 Sidecar 或独立 Service。 - 核心坑：shared context 的数据一致性与 CAP 取舍——强一致性（每次读取看到最新写入）需要跨 Agent 同步，牺牲可用性；最终一致性（允许短暂 stale read）提升吞吐但需要上层应用容忍"读到旧版本"。

CSDN ⭐⭐ - DeLM 的核心工程价值在于"降本 50%"的实感数字 + 去中心化设计的直观伪代码，适合以「多 Agent 系统架构重构实战」角度在 CSDN/知乎传播，潜在受众是 Agent 平台工程师和 AI Infra 开发者。 - 本日 CSDN 维度无新增具体代码实现。

REPRODUCTION ⭐⭐⭐ - 复现路径（按优先级）： 1. 访问 https://yuzhenmao.github.io/DeLM/ 下载代码，验证环境依赖（Python / CUDA 版本 / 特定 LLM API） 2. 在 SWE-bench Lite（而非完整 SWE-bench，Lite 体量更小）上跑 baseline 数字，记录 Avg.@1 3. 实现简化版 verifier（建议先用规则引擎：断言格式 + 长度阈值 + JSON schema 校验），测失败率和召回率 4. 用 2 Agent vs. 4 Agent 验证 claim() 的原子性是否正确实现，是否出现重复认领 5. 记录单任务 cost 和 latency，与 baseline 对比，标注基线名称和模型版本 6. 补全"四个前沿模型族"的逐族数据，无法获取闭源模型 API 时需显式标注