为什么多 Agent 系统需要一个「共享黑板」而不是一个总指挥
- 关联论文：2606.10662
现在的多 Agent 系统几乎长一个样：有一个主 Agent 派活、收活、合并结果。这套「中心编排」在任务少时很顺手，但一旦你把任务拆成几十个并行子任务，主 Agent 就同时变成两件事——通信的收费站和合并的流水线。所有中间结果都得先回灌给它，它再转交下一步，链路被强行串行化；而它在合并异构产物时又容易丢上下文、撞出冲突。软件工程那种「改十几个文件」的任务、长文档那种「跨几十万 token 找证据」的任务，撞上这个结构就是又贵又慢。
arXiv:2606.10662（Yuzhen Mao 等，2026-06-09）提出的 DeLM 给了一个很直接的回答：干脆不要总指挥。让多个 Agent 同时在线、彼此不直接通信，大家共用一份已验证的共享上下文，再配一个原子化任务队列，靠「认领—推理—写回」四步循环自己往前推。
核心机制：谁有资格往黑板上写字
DeLM 的关键设计不是「共享」本身，而是「共享什么」。共享区不是聊天消息流，而是一个 verified update store——Agent 读到的每一份内容，都已经过了校验器（verifier）这一关，没通过检查的产物会被打回队列重排。所以原本属于中心调度器的「分发 + 合并」责任，被部分让渡给了一个可信的共享黑板。
这里有两个容易被忽略但决定成败的点。第一是认领的原子性：谁先空闲谁拉任务，靠数据库层的 SELECT ... FOR UPDATE SKIP LOCKED 或 Redis Streams 这类原语保证不会重复执行，一旦这条不严谨，整套去中心化就会退化成多人重复劳动。第二是写回要紧凑：Agent 提交的是结构化的小条目，不是完整对话历史，否则上下文会随迭代轮数膨胀——这正是它在长上下文任务上不掉点的原因。
为什么值得看：成绩和成本同时动
数据在两条主线上：SWE-bench Verified 上 Avg.@1 / Pass@2 / Pass@4 三项同时拿到最佳，相对最强基线最高 +10.5 个百分点；LongBench-v2 多文档 QA 上跨四个前沿模型族取得最高平均准确率，最高 +5.7 个百分点。更实在的是单任务成本下降约 50%——SWE 类任务跑一次贵得惊人，调度与重试的开销被摊薄掉一半，是可以直接兑现的工程红利。双线同时 SOTA 也说明这套机制不挑任务域，不像是某个基准上过拟合。
证据边界与工程局限
需要清醒的部分不少。降本 50% 的基线没有披露——是对比原始单 Agent 基线还是某个特定多 Agent 系统？没说。Verifier 的实现完全是个黑盒：是规则断言、LLM judge 还是人工审核？原文未明确，更关键的是它的失败率、延迟和额外 LLM 调用成本都没交代——而这恰恰是落地时最关键的一环，任何复现都得自己设计。另外 LongBench-v2 只说了「跨四个前沿模型族」，没有逐族拆分报告，你无法判断它对弱模型的拉升和对强模型的微调各占多少。还有一个「近似线性扩展」的核心假设，没有任何 Agent 数量（2/4/8/16）的扩展曲线数据支撑，共享区的锁竞争和 verifier 吞吐瓶颈也没被量化。
最后一点结构性的：共享上下文本身就成了一个新的中心化点，只是把单点压力从调度器转嫁到了存储与校验层，写吞吐、版本冲突、schema 演进会变成新瓶颈，论文对此未深入。
落地建议
如果 Agent 数已经超过 5、任务又可拆解，去中心 + 共享黑板大概率比中心化编排更便宜也更稳。落地时优先做三件事：把共享上下文的 schema 定死（带类型、带校验的 verified update，而不是自由文本消息）；把产物压缩成结构化条目防上下文膨胀；用 Redis Streams 或 SKIP LOCKED 兜住认领的原子性，并配 30 秒心跳、2 分钟超时强制 requeue 来处理 Agent 崩溃。
一句话 takeaway：多 Agent 的扩展性瓶颈不只在调度层，还在「共享状态长什么样」——把共享状态做成带校验的、紧凑的、可信的黑板，比把调度器做得更聪明更管用。
📣 推广卡片 · 小红书版
标题变体（3 选 1）
A（反常识型）
多 Agent 越并行越慢？问题不在 Agent，在那个「总指挥」
B（实用型）
让 10 个 AI 一起干活却便宜一半：把总指挥换成一块共享黑板
C（悬念型）
一篇论文证明：Agent 之间根本不用说话，也能协作得很好
小红书卡片文案
📌 为什么你的多 Agent 系统一并行就变慢？
因为有个「总指挥」在中间收活、派活、合并结果—— 它既是通信收费站，又是合并流水线 😵
🔧 arXiv:2606.10662 的解法：DeLM 不要总指挥，改成「共享黑板」
并行 Agent → 各自在线，互不直接通信 已验证共享上下文 → 只有过了校验器的内容才能写进黑板 任务队列 → 谁先空闲谁原子认领，失败自动回灌
📊 成绩单： SWE-bench Verified 三项同时 SOTA，最高 +10.5 pp LongBench-v2 多文档 QA 最高 +5.7 pp 单任务成本 ↓约 50%
⚠️ 但别急着抄： 降本基线没披露，Verifier 实现是黑盒， 「线性扩展」没有扩展曲线数据， 共享黑板本身就是新的中心化点。
💎 takeaway：多 Agent 的瓶颈不只在调度，还在共享状态长什么样。
📎 论文 ID：2606.10662 💬 评论区聊聊：你们的多 Agent 系统里，主 Agent 是哪一环最卡？