wait4xandGLM-5.3
8571acdc8b
用户直派车道交付：①Spec Harness 详解（任务包解剖+流水线图， boundary/verify 实例+12 命令+门禁）②pi-mesh 四件套（stack 图+ 合奏循环图+上手安装）③Agensh 论文笔记（三支柱/协作环/规模收 益图，DeLM 血统+issue#13→pi-board 诞生线）。七张自绘 SVG、双 语（en 手写直译 locked:true，禁 TMT 覆盖）。与既有 spec- workflow-and-mesh（实战复盘向）互补并存。 车道：worker-one（build/lint/外链 curl/视觉两轮 7/7 全绿）；收 编复验 E2E 34/34+lint 43 页 0/0/0 验证: pnpm astro build 39 文；E2E 34/34；content-lint 0/0/0 Spec: none (内容三篇，直派车道收编) Co-authored-by: GLM-5.3
53 lines
5.7 KiB
Markdown
53 lines
5.7 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 们。
|
||
|
||
## 一、三支柱：组织的协同基建
|
||
|
||
|
||
|
||
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/)
|