自组织多智能体
无编排器的自组织多智能体（Agensh）
现有 Coding 多智能体框架（Codex sub-agents、Claude Code agent teams、Copilot fleet、Kimi Agent Swarm）都采用 编排器-工人结构：主 agent 规划、拆分、派活、整合，系统能扩到多大，天花板是编排器的管理脑容量，且编排器往往需要专门训练。 微软 Agensh（arXiv 2609.26781，2026-09）把编排器砍掉：1024 个工人 agent 平权，prompt 完全相同只差 worker ID， 任务发现与分配由群体自组织完成。每个 worker 循环执行五步协作循环（Cooperation Loop）： 收集上下文 → 认领子任务（往共享板写 CLAIM，撞车用直消息私聊）→ 执行并广播有用发现 → 对照验收标准自查 → 合并进度（PR 合主干，冲突则同步后重合），全程异步，谁也不等谁。
循环的地基是三件现成开源件：共享工作区用 Gitea（私有分支干活、PR 合主干，冲突检测与版本历史免费拿到）， 消息接口用 Mattermost（频道公告 + 直消息），共享上下文（Shared Context）是借鉴 DeLM（arXiv 2606.10662）的 append-only 记事板：OBSERVED、FACT、FAIL、CLAIM、PATCH_SUMMARY 五种短条目，配 board_grep 翻全量历史。
关键实现决策（也是最容易答错的点）：协作循环写在每个 worker 的 prompt 里，而非硬编码进运行时。 自组织能力因此是提示词工程而非运行时工程，换底层 harness（Copilot 换 Claude Code）只需轻量适配器， 循环、协议、共享服务全部不动。底层单 agent harness 只管一个 worker 怎么思考行动， Agensh 这一层只管 N 个 worker 怎么收到事件、共享状态、协调贡献。
实验（GPT-5.6-sol high + Copilot harness，断网 6 小时从零重建）：pandoc 通过率 33.89%（1 agent）→ 55.06%（1024 agents）； ProgramBench 五道最难题（含 FFmpeg 155 万行、PHP-src 281 万行）平均 19.31% → 28.78%（1→128）。 数量还买到速度：pandoc 30% 通过率线，128 个 agent 30 分钟跨过，单 agent 2 小时未到。 组织扩大时合作形态涌现升级：8 个约定模块接口各自实现，32 个多人集成复审（批准可被反例撤回）， 128 个出现按经验选审阅者与可复用的标准化工作流，1024 个出现待命的集成者角色与同领域失败接管。 但 agent 并非同时在场：为减少认领撞车采取交错激活（第一小时每 30 秒上线一个、之后每 3 秒一个）， 头一小时组织仅约 120 人，涌现层级混叠了规模效应与组织年龄效应，不宜全部归因于人数。 边界：适合目标明确、验收客观（隐藏测试）、子任务天然可并行的长程工程任务；开放式、验收主观、强串行依赖的任务未必受益。
见：Agensh: Scaling Organizational Intelligence to 1,024 Agents
「全自主」实验两端都靠人工注入
论文正文把 Fully autonomous 定为铁律，附录 C 却显示 6 小时时限前 45 分钟和 5 分钟各有一条调度员提醒发向全组织： 先「停止派发新功能、确保主干可构建、合并开放的 PR」，再「合并一切就绪的、跑通 compile.sh、发布最终状态」。 运转端同样有外部触发：空闲 10 分钟由 idle detector 发提醒，某回合未产出共享板条目则追发一条催发布发现； 单 agent 对照组更明显，不加 stop hook 提醒根本撑不满 6 小时，中途即停。 自主组织负责发现和推进工作，「别停下来」与「何时转入收尾」两个方向的判断都靠外部注入； 套用这套架构时，这类保活与收尾协议是与协作循环、组织基础设施并列的第三种机制，必须独立设计。
FAIL 是共享上下文板上最值钱的条目
共享板五种条目中，worker prompt 只给 FAIL（证伪的方案）标注了价值判断：阻止同伴把预算花在同一弯路上。 价值兑现靠两条配套设计：板子 append-only 且 board_grep 可搜全量历史（最近记忆只保留 2000 条，更早的靠 grep 捞回）， 新条目会在其他 worker 下一次工具调用返回时 mid-turn 注入，一条 FAIL 写出后，正在做同一件事的 worker 当前回合中途即可收到并止损。设计共享上下文时，「什么路走不通」的防重复价值高于「完成了什么」的状态同步， 值得为失败记录单独设计条目类型与传播优先级。
见：Agensh 论文全文（附录 A worker prompt）
规模收益存在陡峭拐点，数量买时间不买上限
pandoc 上通过率 1→128 涨 17.05 个百分点（33.89%→50.94%），128→1024 只涨 4.12 个百分点（→55.06%）， 最后 8 倍规模买到的增益陡降；五任务均值（19.31%→20.68%→26.52%→28.78%）同构，增长集中在 8→32 段（+5.84 点）。反方向看，大组织更早到达同等水平（128 个 30 分钟跨过 30% 线，单 agent 2 小时未到）， 数量的正确买法是买时间而非买上限。硬时限任务（如 CI 卡 1 小时出结果）才值得堆大规模， 时限宽松时把规模停在拐点前（几十个）是数量级的成本节约。
直消息与频道消息是两种投递时机语义
Mattermost 上频道公告排队到 worker 下一回合开头送达，直消息由工具调用包装层直接插进当前正在等待的工具返回结果里 mid-turn 到达（附录 B 注明该路径只作用于 MCP 工具返回，不打断任意运行中的进程，打断的边界是工具调用间隙）。prompt 明说直消息「会打断对方正在做的事」，规矩因此是：只有两人即将编辑同一处才发直消息，其余一律走频道。 配套的容器内踩坑：Gitea API 返回的 clone_url/html_url 是外部地址（gitea.localhost:端口），worker 容器内不可达， 必须替换成 http://gitea:3000，prompt 专门用一段讲这条替换规则。可迁移的设计点：协作系统的消息优先级 不该只是加急标记，而应是「注入时机」的语义差异（打断式 vs 排队式），并把使用规矩写进协议而非依赖 agent 自觉。