wait4xandGLM-5.3
a761cf8129
Agensh（arXiv 2609.26781）在线研读页：/papers/agensh/ 双轨薄壳
_PaperView 共享视图+六词条；信息条含标题/作者/abs 链接/授权声明
（arXiv nonexclusive-distrib 1.0，非本站托管）/下载钮。
合规红线：许可证禁第三方再分发→仓内零 PDF 副本，iframe 直嵌
arxiv（实测无 X-Frame-Options）；微信 webview 前置 UA 检测加
is-wechat 类、iframe 不挂 src 零无用请求、兜底卡指引右上角浏览
器打开；非微信 data-src 懒挂载+9s 弱兜底+noscript 兜底。正文
入口卡双轨已渲染。
车道：op-gitea（专项四断言+E2E 34/34）；收编复验六断言全过
（iframe/授权/微信降级/en/入口卡/零 PDF）
验证: E2E 34/34；微信 UA 模拟 is-wechat=true src 空 提示在；
git status 零 .pdf
Spec: none (论文阅读页，车道级交付)
Co-authored-by: GLM-5.3
55 lines
5.8 KiB
Markdown
55 lines
5.8 KiB
Markdown
---
|
||
title: "Agensh：把组织智能扩展到 1,024 个智能体"
|
||
pubDate: 2026-11-01
|
||
category: tech
|
||
tags: [论文笔记, AI 协作]
|
||
---
|
||
|
||
多智能体系统能靠并发压缩复杂任务的时延，但主流框架有一个共同的天花板：中心编排器。任务分配、进度汇总、结果裁决全部挤过同一个上下文，规模越大，编排器先死。2026 年 10 月，微软研究院开源了 [Agensh](https://github.com/microsoft/Agensh)——一个**没有中心编排器**的自组织多智能体 harness，论文[《Scaling Organizational Intelligence to 1,024 Agents》](https://arxiv.org/abs/2609.26781)把它推到了一千零二十四个 agent 的规模。
|
||
|
||
它的答案出人意料地朴素：与其造一个更聪明的调度大脑，不如把一个人类组织的协同基建原样搬给 agent 们。
|
||
|
||
> 📄 **[在线研读全文 PDF →](/papers/agensh/)** · arXiv 2609.26781 · 微软研究院
|
||
|
||
## 一、三支柱：组织的协同基建
|
||
|
||
|
||
|
||
Agensh 只给三样基础设施，其余全部自组织：
|
||
|
||
- **共享工作区**：git 平台承载组织的进行中工作与集成结果，分支、PR、合并冲突这些人类用了二十年的机制原样复用；
|
||
- **消息接口**：团队频道加私信，带优先级送达——组织级广播与紧急碰撞调解各走各的道；
|
||
- **共享上下文**：一块类型化条目板，存组织的发现与工作意图。
|
||
|
||
开源参考实现用的是 Gitea 承载工作区、Mattermost 承载频道与私信——一套完全开源自接的“办公室”，没有任何私有服务。没有编排器分配任务：worker 自己从工作区和上下文里找活、认领、验证、合并。规模化时天生的瓶颈（那个越来越忙的中枢）根本不存在。
|
||
|
||
## 二、协作环：每个 worker 各跑一圈
|
||
|
||
|
||
|
||
每个 worker 并发、异步地执行同一个协作环：**收集上下文 → 认领子任务 → 执行 → 验证 → 合并进度**。收集上下文时读共享工作区和条目板的存量知识；认领靠 CLAIM 声明，撞车了私聊解决；验证自己跑测试，证据说话；合并走 PR。
|
||
|
||
最有意思的设计在共享上下文的**经济学**：条目刻意短小（约 100 字符，PATCH_SUMMARY 放宽到 300），长版本放 `detail` 字段按需展开；`board_read` 只服务最近 2000 条，更早的历史只能靠布尔检索（`,` = OR，`&` = AND）翻出来——近期记忆保持小，长尾靠搜索。论文称 **FAIL 是价值最高的条目**：一条被证伪的路径写下来，就能止住全队在同一个死胡同里重复烧预算。新条目会作为较高优先级的更新，在同伴的下一个工具调用边界推送过去。
|
||
|
||
这套共享上下文不是 Agensh 的发明——论文 §2.3 明说“共享上下文遵循 DeLM 的核心思想”。[DeLM](https://github.com/yuzhenmao/DeLM)（[arXiv:2606.10662](https://arxiv.org/abs/2606.10662)）用共享上下文加任务队列跑去中心化多智能体：它的板是一张 append-only 事件日志（条目、认领、完成、FACT/FAIL 笔记、状态），正文存在日志旁的独立数据库，带硬上限（≤40 个文件、≤400KB 总量），还有一个阻塞式的 `read --wait`——同伴发帖即唤醒等待者。在 Terminal-Bench 4.0 的 10 项子集上，两个 agent 通过共享上下文协同，平均提升 12.5 个百分点准确率、1.78 倍加速。Agensh 把这条线索放大到了千级规模。
|
||
|
||
## 三、数字：扩容真的有用吗
|
||
|
||
|
||
|
||
两组数据回答"加 agent 到底加不加得动"：ProgramBench 最难 5 题，1 → 128 个 agent，通过率 19.31% → 28.78%（相对提升约 49%）；从零构建 pandoc（6 小时预算、无外网），1 → 1,024 个 agent，通过率 33.89% → 55.06%。对纯堆算力已经边际递减的难题，**组织化的边际收益还在**。
|
||
|
||
工程可用性也到位了：v1.0 于 2026-10-23 发布，六天后的 v1.0.1 已支持 Copilot、Codex、Claude Code、Pi 作为底层单智能体 harness——单 agent 侧你可以用任何顺手的主力模型。开源版是单节点 harness，v1.0 发布包里就带着复现指南、论文与演示——从论文到可跑的仓库，中间没有隔着一句“敬请期待”。
|
||
|
||
## 四、从论文到桌面：一个 issue 的故事
|
||
|
||
这篇论文对我们不只在纸上。把它读透之后，2026-10-23 我在 pi-mesh 仓库提了[第 13 号 issue](https://github.com/cgarrot/pi-mesh/issues/13)：pi-mesh 已有消息接口（`mesh_send`/房间/优先级）和共享工作区（git + `mesh_reserve` 预约），独缺第三支柱共享上下文——提议按 Agensh/DeLM 的形状加 `board_write / board_read / board_grep`。
|
||
|
||
维护者 cgarrot 的回复是整个故事里最值得学的一课：方向对，但**hash-only 台账让 pi-mesh 结构上当不了这块板**——把持久化塞进 broker 等于把路由器改造成数据库。正确的形状是独立包：以普通 peer 入房、自有存储、mesh 继续只做路由。于是有了 [pi-board](https://github.com/wait4xx/pi-board)：一天内出 v0.1，55 个测试零失败、真实 broker 上九步冒烟，issue 最终关闭时官方指针就落在它身上。上一篇文章介绍的[四件套](/archives/pi-mesh-stack/)，其记忆层就是从这篇论文长出来的。
|
||
|
||
## 五、结语
|
||
|
||
Agensh 的启示不是"1024"这个数字，而是它对"组织智能"的拆解：工作区、消息、共享上下文——三根支柱撑起自组织，任何一根都不需要一个更聪明的大脑。这个拆解在千级规模成立，在单机四件套成立，在单人加几个 agent 终端的小作坊同样成立。规模会变，支柱不变。
|
||
|
||
相关阅读：[Spec Harness 详解](/archives/spec-harness/) · [pi-mesh 全家桶详解](/archives/pi-mesh-stack/)
|