技术 · 熟练
1024 个 Agent，没有总调度
不是「让它更聪明」，是「让它们自己领活、互相验收」
多数人做多 Agent，第一反应是加一个总调度：一个 planner 拆任务，其余按序执行。但 2026-10 微软研究院开源的 Agensh 走了反方向：最多 1,024 个 agent、没有中心协调器，靠三样底座自组织 —— 共用工作区（谁做了什么，人人可读）· 消息层（发现与质询）· 认领与互验规则（谁领哪块、谁验谁）。结果在五个最难的 ProgramBench 任务上，平均通过率从 19.31%（1 个 agent）升到 28.78%（128 个）。关键动作只有一个：把任务切成「有完成判据的小块」扔进池子，让 agent 自己领、互相验 —— 而不是由你排好顺序再派下去。
方法 · 一图看懂
1
先分清两种组织形态 — 有编排者（图 / 流水线：节点固定、边固定）vs 无编排者（认领制：任务进池、谁来领不定）；前者适合步骤稳定的活，后者适合「拆不准、边做边发现」的活
2
无编排者要三样底座 — 共用工作区（一块所有人可读可写的白板：任务池 / 进度 / 产出）· 消息层（谁能找到谁、怎么质询）· 认领与验收规则（怎么领、领了多久算失效、谁来验）
3
任务写成「可认领的小块」 — 每块只写两样：要交付什么 + 怎么算完成；⛔ 不写做法 —— 写做法就退回了编排制，认领者只剩执行
4
让 agent 互相验收 — 至少一个非作者来验，验不过退回池子并注明缺什么；作者不能自签
5
盯规模拐点，而不是追数量 — 从 1 到 128 收益明显，再往上要靠任务本身可并行；先量「同一块被重复领了几次」，重复率高说明任务切得不够清
原理 · 为什么有效
三条机制：1. 协调成本随人数上升得更快 —— 中心调度者要维护所有人的状态，人数一多它自己就成了瓶颈；认领制把这份状态外化成一块人人可读的白板，读的人多、维护的人少。2. 白板让「谁在做什么」变成可读状态 —— 争抢与重复都被看见；看不见的状态只能靠调度者记，一崩就全丢。3. 互验把质量从「个人水平」变成「制度」 —— 一个 agent 的自评永远偏向自己；换一个没参与写的人按完成判据验，才拦得住「看起来很完成」的产出。
适用场景
适用：任务能被切成有明确完成判据的小块（改一批文件、跑一批测试、核一批条目）；你能提供一块共用工作区与一条消息通道；你接受「顺序不确定、总时长可能更长，但单点崩溃不拖死整批」。⛔ 不适用：步骤强依赖、后一步必须等前一步结果的流水线（那用图/编排更省）；预算极紧的场合（并行会放大 token 消耗）。
自测 · 5 问
每一块任务都写了「怎么算完成」，而不是「怎么做」
白板上能一眼看出：哪些块没人领、哪些在验、哪些被退回
验收者不是作者（有没有一条规则挡住自签）
有没有「领了不动」的超时回收规则
上线前量过一次重复认领率（同一块被两个 agent 各做一遍的比例）
怎么上手 · 验证步骤
上手顺序：先拿一件你手上「拆不准」的活（例如给 200 个文件补同一类注释），把它切成 10 块、每块写一句完成判据 → 建一张纯文本任务池（一行一块：编号 / 判据 / 状态 / 认领人）→ 放 3 个 agent 进去领，规则只有三条：领了要写名字、做完写产出位置、由没写过的人验 → 跑完统计重复认领率与被退回率，再决定要不要加到 10 个。
自检动作：把任务池交给你之外的人看一眼，问他「现在哪一块最可能拖住整体」—— 他指不出来的话，说明白板上的状态还不够可读，先补状态字段，别急着加 agent。