1024 个 AI Agent 同时干活，没人指挥：Agensh 把多 Agent 协作从"公司管理"变成"蜂群协议"

  • 关联论文：2609.26781

一句话故事

arXiv 2609.26781（Agensh，2026-09-24 更新）做了一件反主流的事——把多 Agent 编排里那个"中心调度员"彻底干掉。 主流的 AutoGen / CrewAI / MetaGPT 都是"一个老板 + 一群小弟"的架构，所有任务派发、上下文传递、结果汇总都流经中心节点，于是规模上限被中心节点的 QPS 和上下文窗口锁死。Agensh 让 1024 个 Agent 直接共享一个"工作区 + 消息接口 + 共享上下文"，每个 worker 自己抢活、自己验证、自己合并——实证上把 ProgramBench 5 个最难任务的最终通过率从单 Agent 的 19.31% 拉到 128 Agent 的 28.78%（+49%），单任务（pandoc 文档格式转换）从 33.89% 拉到 55.06%（+62%），证明"Agent 数量"本身就是一条独立的 scaling 轴。

为什么这件事重要

如果你做过 multi-agent 系统——AutoGen、CrewAI、MetaGPT、LangGraph multi-agent，或者哪怕只是用 OpenAI Agents SDK / Claude Agent SDK 写过带 supervisor 的工作流——你大概率都被同一个问题反复卡住：

Agent 越多越慢，最后卡在"老板"节点上。

主流 multi-agent harness 的架构都长这样：

[Orchestrator / Manager Agent]
       │
       ├── Worker 1
       ├── Worker 2
       ├── Worker 3
       └── ...

老板节点负责三件事：① 把复杂任务拆成子任务；② 把子任务分给 worker；③ 把 worker 的结果汇总 + 决策下一步。

这条架构有三个明显的工程痛点：

  1. 调度瓶颈：所有 worker 的请求都汇入单一节点，单点 QPS 与上下文窗口成为系统上限；任务越复杂，编排器推理时间越长，wall-clock latency 反而被拖慢。
  2. 上下文瓶颈：worker 之间通过编排器中转，编排器自身的上下文窗口很快被全局任务计划与中间结果塞满，长任务下出现"中心忘了派活"的现象。
  3. 角色僵化：编排器一旦定义好 worker 角色与拓扑，扩展或重组织就需要改 prompt、改拓扑 schema，无法动态适配新负载。

Agensh 的回应是"让 worker 自己找活干"——去掉中央编排器，让所有并发 worker 在一个共享 workspace + message interface + shared context 的三件套上跑同一个合作循环，不断 gather context、claim 子任务、执行、分享、verify、merge。

这件事为什么重要？因为它直接回答了 multi-agent 系统最大的悬而未决问题——规模上限到底由谁决定：

老板节点 QPS 决定上限 → 主流架构 共享工作区的原子操作 IO 决定上限 → Agensh 架构

两条架构选择决定了"Agent 团队"到底是 8 个人小作坊、还是 1024 人蜂群工厂。

Agensh 做了什么

第一件：搭一套"蜂群协议"基础设施

Agensh 的 harness 由三个共享基础设施组件支撑一个 worker 内部的"cooperation loop"：

Agentic Organization Infrastructure
  ┌─────────────────────────────┐
  │ Shared Workspace            │  ← proposed / ongoing / completed work
  │ Message Interface           │  ← 异步 worker↔worker / worker↔workspace
  │ Shared Context (reusable)   │  ← findings、work intentions
  └─────────────────────────────┘
            │
            ▼
   per-worker Cooperation Loop
   ┌────────────────────────────────────┐
   │ gather context → claim/self-assign │
  │   → act → share findings           │
  │   → verify → merge progress        │
  └─────────────────────────────────────┘
  • Shared Workspace：唯一可信任务源，存放"提议中 / 进行中 / 已完成"三态任务，支持原子 claim 操作避免重复派发。
  • Message Interface：异步消息总线，worker 通过它声明意图、广播结果或申请协调；不依赖同步 RPC。
  • Shared Context：可复用的中间结论与子任务意图池，相当于 worker 之间的"外脑"，避免每个 worker 重复推理已发现的子结论。

⚠️ 没有开源 reference impl：论文没有 release reference implementation，工程落地需要自行搭建，下面 §"对工程落地的启发"会展开最小可行实现路径。

第二件：worker 内部跑 cooperation loop

关键点：loop 在每个 worker 内独立运行，没有任何"协调者"决定谁先 claim；冲突由 Shared Workspace 的原子 claim 语义解决，验证由 peer worker 异步完成。

伪代码：

while not workspace.all_done():
    ctx = workspace.gather_context()          # 拉取共享上下文 + 工作区状态
    intents = llm.plan_next_actions(ctx)      # LLM 决策下一步动作
    for action in intents:
        if action == "claim":
            workspace.atomic_claim(subtask)   # 抢占式认领，失败则跳过
        elif action == "act":
            result = execute(subtask)         # 调用工具 / 写代码 / 跑测试
        elif action == "share":
            workspace.publish(findings)        # 写入 Shared Context
        elif action == "verify":
            ok = check_peer(subtask)          # 读 peer 提交的中间结果做交叉验证
        elif action == "merge":
            workspace.commit(subtask)          # 把 verified 子任务写回工作区

第三件：用 ProgramBench 5 个最难任务 + pandoc 长链路验证 scaling

评测基准：

  • ProgramBench 5 hardest 任务：选择该 benchmark 中难度最高的 5 个子任务（编码类），覆盖 spec→实现→测试全流程。
  • pandoc 任务：单任务长链路（文档格式转换 pipeline），用于验证 1k+ agent 规模的扩展性。
  • 模型：GPT-5.6-sol（high reasoning effort），全部 worker 共用同款模型（避免引入"模型异质性"变量）。
  • 指标：最终测试通过率（mean final test-pass rate）。

关键数字：4 个 verbatim 已核实

指标 数值
ProgramBench 5 hardest（1 agent） 19.31% 通过率
ProgramBench 5 hardest（128 agents） 28.78% 通过率（相对 +49%）
pandoc（1 agent） 33.89% 通过率
pandoc（1,024 agents） 55.06% 通过率（相对 +62%）

⚠️ 以上所有数字均来自论文摘要。

⚠️ 存疑：128 agents vs 1,024 agents 曲线是否在同一任务上测得——ProgramBench 5 hardest 只给了 128 agents 数字；1,024 agents 仅 pandoc 任务。两者混用"组织规模提升"叙事，但基线任务不同，不能直接对比规模收益。

⚠️ 存疑：所有数字依赖 GPT-5.6-sol（闭源、商用、API rate-limit），第三方难以完整复现 1,024 agents 的曲线；开源替代（Qwen / DeepSeek / Llama）下的 scaling 行为是空白。

⚠️ 存疑：abstract 强调"hard latency constraints 或 time budget"，但实际论文只给"最终通过率"一项指标，没有报告 wall-clock time、token 消耗、API cost 三件套——这对"工程落地"决策同样关键。

跟同类工作的关系

相关工作 与 Agensh 的关系
AutoGen / CrewAI / MetaGPT 中心编排器派单，Agensh 是"去中心化"版本——可以理解为 anti-thesis
ChatDev / Anthropic multi-agent research 仍是 manager-worker 拓扑，与 Agensh 共享部分观察（多 agent 对复杂任务有益）但治理思路相反
OpenAI o1/o3 / Anthropic Claude reasoning 系列 单模型内化 long-horizon reasoning，Agensh 走"多模型同 reasoning + 协作"外部路径——单模型推理越强，多 agent 的边际收益越值得被重新审视
DSPy / textual feedback loops 在单 agent 内做 self-refine，与 Agensh 的 peer-verify 共享思想（外部 verifier），但 Agensh 把 verifier 推到 worker 池里做并发
Self-Consistency / Best-of-N / Majority Voting 单模型多采样叠加，Agensh 与之对照——"vs 中心编排器""vs 单模型采样叠加"的对照表缺失 ⚠️

Agensh 的核心贡献在于：它首次把"agent 数量"建模成一条独立的 scaling 轴，并给出实证曲线；但缺 self-consistency 对照、缺开源模型复现、缺 wall-clock + token 消耗报告，是论文的三块明显短板。

对工程落地的启发

启发 1：把 Shared Workspace + Message Interface 抽象为独立微服务

不要把 Agensh 当成"一个 multi-agent 框架"，把它当成"三个微服务 + 一个 loop 模板"：

组件 推荐选型 替代方案 主要坑点
Shared Workspace Redis Streams + Lua 原子脚本 SQLite WAL / PostgreSQL advisory lock claim 竞争时需 Lua 脚本保证原子性；Redis 持久化 vs 内存需按可用性要求权衡
Message Interface NATS JetStream（持久化 + 消费组） Redis Pub/Sub（无持久化）/ Kafka（运维重） consumer group 重平衡期间 claim 可能短暂重复；需额外 idempotency key
Shared Context PostgreSQL JSONB + pgvector 近似检索 ChromaDB / Qdrant（引入额外服务） JSONB 写入 QPS 受限于 PostgreSQL 单节点；多 worker 并发写需 MVCC 调参

Cooperation Loop 可作为 system prompt 模板工程化：「先 gather context、再 claim、若 claim 失败则重新 plan」三段式是普适的多 agent 协作骨架，可挂在 OpenAI Agents SDK、Claude Agent SDK、LangGraph 任意 harness 上。

启发 2：监控 claim 冲突率——这是工程落地最关键的指标

论文完全没有报告 claim 冲突率，但这是 harness 工程落地最需要关注的指标。建议埋点：

# 在 workspace.atomic_claim() 外层包装
claim_attempts += 1
try:
    ok = workspace.atomic_claim(subtask)
    if not ok:
        claim_conflicts += 1  # 竞争失败
        logger.warning(f"claim conflict on subtask={subtask.id}")
except Exception as e:
    logger.error(f"claim error: {e}")
    claim_errors += 1

# 每轮 loop 结束时打点
metrics.emit({
    "claim_attempts": claim_attempts,
    "claim_conflicts": claim_conflicts,
    "conflict_rate": claim_conflicts / claim_attempts,
    "worker_id": worker_id,
    "round": round_num
})

实战经验值（估算）： - 8–16 agents、低耦合任务（subtask 拆分粒度粗）：冲突率 < 5% - 64–128 agents、中等粒度：冲突率 10–20%（可接受） - 256+ agents、细粒度任务（subtask 数量 < agent 数）：冲突率 > 30%，此时 shared workspace 的锁开销会侵蚀并发收益

拐点判断：若 conflict_rate > 15% 且扩大 agent 数不带来通过率提升，说明已经到了边际收益递减点。

启发 3：分阶段替代现有编排器——不要全量替换

生产落地不建议直接抛弃现有 AutoGen/CrewAI 编排器，推荐渐进式：

阶段 1（不改 harness）：给现有 harness 加 Shared Workspace 日志
  → 观察现有编排器的任务分配模式，识别高频瓶颈任务

阶段 2（局部自治）：对高频瓶颈子任务，用 Agensh 协议跑 8–16 agents 独立 pool
  → 编排器仍负责任务拆分，但子任务内部自组织

阶段 3（全量替换）：仅在 swe-bench 类复杂长任务上全量切换
  → 简单任务仍走原 harness，避免引入不必要的协调复杂度

⚠️ 边界坑（落地前必须看）

  1. 闭源模型锁定：所有数字依赖 GPT-5.6-sol（闭源、商用、API rate-limit），第三方难以完整复现 1,024 agents 曲线；开源替代下的 scaling 行为是空白。
  2. 冲突率未量化：worker 在 atomic claim 之前的"intent 推理"阶段就已经消耗了 LLM 调用与上下文，若多个 worker 同时决定 claim 同一子任务，会形成"先做再 cancel"的浪费；论文未给出冲突率与重做率的统计。
  3. 延迟与成本 trade-off 未量化：abstract 强调"hard latency constraints"，但论文只给"最终通过率"一项指标，没有报告 wall-clock time、token 消耗、API cost 三件套。
  4. token 消耗被 abstract 掩盖：以 ProgramBench 5 hardest + GPT-5.6-sol(high) 估算，128 agents 单轮可能消耗 128 × 若干轮 × 6K tokens，实际落地成本可能高达单 agent 的 100×+，需用 budget mode + finding 摘要压缩控制。
  5. 缺少 baseline 对照：self-consistency（k=8/32）、best-of-N、majority voting 三类基线缺失；majority voting 在单模型下可能拉到 28%，论文未给对照表，"组织规模收益"叙事不能完全成立。
  6. 同质可信假设：自组织协议假设 worker 都是"同质可信"的，引入人类专家或外部审计时需要额外 trust layer。
  7. 边际收益拐点未给：在没有 reasoning effort 较低或异构模型的实验下，shared workspace 的争抢与上下文噪声可能让 1,024 agents 收益归零甚至下降；论文没有给出"边际收益拐点"的定量分析。
  8. ProgramBench 闭源：ProgramBench 5 hardest 任务是闭源隐藏测试集，无法独立复现，工程团队在选型前必须在自己业务数据集上重跑基线。
  9. "emerging role"是涌现还是 prompt 注入：论文通过 worker trajectories 观察到"擅长验证的 worker""擅长 merge 的 worker"等隐式分工，但这些角色是否被显式 prompt 注入、是否在关闭/开启 role hint 后仍存在 ablation 实验——原文未明确。

🎯 你能立即做的事

  • multi-agent 系统工程师：把 Shared Workspace + Message Interface 抽象为两个独立微服务（Redis Streams / NATS JetStream），与 LLM 框架解耦；Cooperation Loop 作为 system prompt 模板工程化。
  • AI 基础设施 / 平台架构师：评估在 K8s 上横向扩展 agent worker 的上限与运维成本——把 claim 冲突率作为可观测性指标加入 dashboard。
  • research engineer：在 swe-bench / ProgramBench 上做 self-consistency、best-of-N 与 multi-agent 三类的对比研究，先补足 Agensh 缺失的 baseline 对照表。
  • 不适合：刚入门 LLM agent 的读者（应先读 ReAct / Reflexion 类单 agent 基础工作）。

📌 一句话总结：Agensh 干掉多 Agent 系统的中心编排器，让 1024 个 worker 在共享 workspace + message interface + shared context 上自组织抢活——ProgramBench 5 hardest 通过率从 19.31%（1 agent）拉到 28.78%（128 agents，+49%），pandoc 单任务从 33.89% 拉到 55.06%（1024 agents，+62%），证明"Agent 数量"本身可以是一条独立 scaling 轴；但闭源模型锁定、claim 冲突率未量化、wall-clock + token 消耗未报告、缺少 self-consistency 对照四块短板必须在选型前用自己业务数据集补完。

🔔 评论区聊聊：你团队做 multi-agent 系统时，编排器节点是当前最大瓶颈吗？把 Shared Workspace + Message Interface 拆成独立微服务后，预计能把 Agent 数量上限从多少拉到多少？

MultiAgent #Agensh #LLM #Agent #SelfOrganization #蜂群协议 #arXiv2609.26781 #论文科普 #AI工程 #ScalingLaws #去中心化协作

三个标题变体

  1. 反直觉版：1024 个 AI Agent 同时干活，没人指挥——Agensh 把多 Agent 协作从"公司管理"变成"蜂群协议"
  2. 数字钩子版：19.31% → 28.78%（+49%）→ 55.06%（+62%）——Agensh 用 ProgramBench + pandoc 实证"Agent 数量"是独立 scaling 轴
  3. 类比版：相当于把公司里的"老板"全部干掉，让 1024 个员工自己抢活、自己验证、自己合并——Agensh 多 Agent 系统的去中心化实验

📱 小红书风格卡片文案（直接可用）

🐝 1024 个 AI Agent 同时干活，没人指挥——这篇论文把多 Agent 协作从"公司管理"变成"蜂群协议"！

姐妹们！👀 你有没有想过：multi-agent 系统里的"老板节点"其实是个隐形瓶颈？🤔

主流 AutoGen / CrewAI / MetaGPT 都是"一个老板 + 一群小弟"架构，所有任务派发、上下文传递、结果汇总都流经中心节点，于是规模上限被老板节点的 QPS 和上下文窗口锁死。😵

🆕 arXiv 2609.26781（Agensh）做了一件反主流的事——把多 Agent 编排里那个"中心调度员"彻底干掉！

📊 核心数字（已 verbatim 核对 abstract）：

任务 Agent 数 通过率
ProgramBench 5 hardest 1 agent 19.31%
ProgramBench 5 hardest 128 agents 28.78%（+49%）
pandoc 单任务 1 agent 33.89%
pandoc 单任务 1,024 agents 55.06%（+62%）

🎯 蜂群协议三件套：

1️⃣ Shared Workspace（共享工作区）：唯一可信任务源，存放"提议中 / 进行中 / 已完成"三态任务，支持原子 claim 操作避免重复派发

2️⃣ Message Interface（消息接口）：异步消息总线，worker 通过它声明意图、广播结果或申请协调；不依赖同步 RPC

3️⃣ Shared Context（共享上下文）：可复用的中间结论与子任务意图池，相当于 worker 之间的"外脑"，避免每个 worker 重复推理已发现的子结论

🔄 每个 worker 内部跑 cooperation loop：

while not workspace.all_done():
    ctx = workspace.gather_context()          # 拉取共享上下文
    intents = llm.plan_next_actions(ctx)      # LLM 决策下一步
    for action in intents:
        if action == "claim": workspace.atomic_claim(subtask)   # 抢占式认领
        elif action == "act": result = execute(subtask)         # 调用工具 / 写代码
        elif action == "share": workspace.publish(findings)      # 写入 Shared Context
        elif action == "verify": ok = check_peer(subtask)        # peer 交叉验证
        elif action == "merge": workspace.commit(subtask)        # 合并 verified 子任务

关键点：loop 在每个 worker 内独立运行，没有任何"协调者"决定谁先 claim；冲突由 Shared Workspace 的原子 claim 语义解决。

🧠 跟同类工作的关系：

  • AutoGen / CrewAI / MetaGPT：中心编排器派单，Agensh 是"去中心化"版本——anti-thesis
  • ChatDev / Anthropic multi-agent research：manager-worker 拓扑，治理思路相反
  • OpenAI o1/o3 / Claude reasoning 系列：单模型内化 long-horizon reasoning，Agensh 走"多模型同 reasoning + 协作"外部路径
  • DSPy / textual feedback loops：单 agent 内 self-refine，Agensh 把 verifier 推到 worker 池里做并发
  • Self-Consistency / Best-of-N / Majority Voting：⚠️ 论文没给对照表——majority voting 在单模型下可能拉到 28%，"组织规模收益"叙事不能完全成立

💡 三大工程启发：

1️⃣ 把 Shared Workspace + Message Interface 抽象为独立微服务：Redis Streams + Lua 原子脚本当 workspace，NATS JetStream 当 message interface，PostgreSQL JSONB + pgvector 当 shared context——与 LLM 框架解耦，OpenAI Agents SDK / Claude Agent SDK / LangGraph 都能挂上来

2️⃣ 监控 claim 冲突率——这是工程落地最关键指标：8–16 agents 低耦合任务冲突率 < 5%，64–128 agents 中等粒度 10–20%，256+ agents 细粒度任务 > 30% 则并发收益被锁开销侵蚀。拐点判断：若 conflict_rate > 15% 且扩大 agent 数不带来通过率提升，已到边际收益递减点

3️⃣ 分阶段替代现有编排器——不要全量替换：阶段 1 给现有 harness 加 Shared Workspace 日志识别瓶颈；阶段 2 对高频瓶颈子任务用 Agensh 协议跑 8–16 agents 独立 pool；阶段 3 仅在 swe-bench 类复杂长任务上全量切换

⚠️ 十个边界坑（落地前必看）：

  1. 闭源模型锁定：所有数字依赖 GPT-5.6-sol，第三方难完整复现 1,024 agents 曲线
  2. 冲突率未量化：worker atomic claim 前的 intent 推理消耗 LLM 调用与上下文，若多 worker 同时决定 claim 同一子任务会形成"先做再 cancel"浪费
  3. 延迟与成本 trade-off 未量化：abstract 强调"hard latency constraints"，但论文只给最终通过率一项指标，没报 wall-clock time、token 消耗、API cost 三件套
  4. token 消耗被 abstract 掩盖：128 agents 单轮可能消耗 128 × 若干轮 × 6K tokens，实际落地成本可能高达单 agent 的 100×+，需用 budget mode + finding 摘要压缩控制
  5. 缺少 baseline 对照：self-consistency（k=8/32）、best-of-N、majority voting 三类基线缺失
  6. 同质可信假设：自组织协议假设 worker 都是"同质可信"的，引入人类专家或外部审计时需要额外 trust layer
  7. 边际收益拐点未给：在没有 reasoning effort 较低或异构模型实验下，1,024 agents 收益可能归零甚至下降
  8. ProgramBench 闭源：5 hardest 任务是闭源隐藏测试集，无法独立复现，工程团队选型前必须在自己业务数据集上重跑基线
  9. "emerging role"是涌现还是 prompt 注入：擅长验证的 worker / 擅长 merge 的 worker 是否被显式 prompt 注入、是否在关闭/开启 role hint 后仍存在 ablation 实验——原文未明确
  10. 共享工作区的持久化与恢复：Redis Streams 默认内存，生产环境需开 RDB+AOF 持久化；worker crash 后重启需从 Shared Workspace 恢复"进行中"状态任务——建议 claim 时给任务加 worker_id + claimed_at TTL，crash 超时后自动释放回池

🎯 适合谁：

  • multi-agent 系统工程师：把 Shared Workspace + Message Interface 抽象为独立微服务，Cooperation Loop 作为 system prompt 模板工程化
  • AI 基础设施 / 平台架构师：评估在 K8s 上横向扩展 agent worker 的上限与运维成本，把 claim 冲突率加入 dashboard
  • research engineer：在 swe-bench / ProgramBench 上做 self-consistency、best-of-N 与 multi-agent 三类对比研究，先补足 Agensh 缺失的 baseline 对照表
  • 不适合：刚入门 LLM agent 的读者（应先读 ReAct / Reflexion 类单 agent 基础工作）

📌 一句话总结：Agensh 干掉多 Agent 系统的中心编排器，让 1024 个 worker 在共享 workspace + message interface + shared context 上自组织抢活——ProgramBench 5 hardest 通过率从 19.31%（1 agent）拉到 28.78%（128 agents，+49%），pandoc 单任务从 33.89% 拉到 55.06%（1024 agents，+62%），证明"Agent 数量"本身可以是一条独立 scaling 轴；但闭源模型锁定、claim 冲突率未量化、wall-clock + token 消耗未报告、缺少 self-consistency 对照四块短板必须在选型前用自己业务数据集补完。

🔔 评论区聊聊：你团队做 multi-agent 系统时，编排器节点是当前最大瓶颈吗？把 Shared Workspace + Message Interface 拆成独立微服务后，预计能把 Agent 数量上限从多少拉到多少？

MultiAgent #Agensh #LLM #Agent #SelfOrganization #蜂群协议 #arXiv2609.26781 #论文科普 #AI工程 #ScalingLaws #去中心化协作