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
5.8 KiB
title, pubDate, category, tags
| title | pubDate | category | tags | ||
|---|---|---|---|---|---|
| Agensh：把组织智能扩展到 1,024 个智能体 | 2026-11-01 | tech |
|
多智能体系统能靠并发压缩复杂任务的时延，但主流框架有一个共同的天花板：中心编排器。任务分配、进度汇总、结果裁决全部挤过同一个上下文，规模越大，编排器先死。2026 年 10 月，微软研究院开源了 Agensh——一个没有中心编排器的自组织多智能体 harness，论文《Scaling Organizational Intelligence to 1,024 Agents》把它推到了一千零二十四个 agent 的规模。
它的答案出人意料地朴素：与其造一个更聪明的调度大脑，不如把一个人类组织的协同基建原样搬给 agent 们。
📄 在线研读全文 PDF → · 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（arXiv: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：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：一天内出 v0.1，55 个测试零失败、真实 broker 上九步冒烟，issue 最终关闭时官方指针就落在它身上。上一篇文章介绍的四件套，其记忆层就是从这篇论文长出来的。
五、结语
Agensh 的启示不是"1024"这个数字，而是它对"组织智能"的拆解：工作区、消息、共享上下文——三根支柱撑起自组织，任何一根都不需要一个更聪明的大脑。这个拆解在千级规模成立，在单机四件套成立，在单人加几个 agent 终端的小作坊同样成立。规模会变，支柱不变。
相关阅读：Spec Harness 详解 · pi-mesh 全家桶详解