一句话结论拿掉编排器之后协作的重担落到了共享状态层上——Gitea 管工作区、Mattermost 管消息、一块上下文板管声明与发现。一、事件与数据微软研究院在 2026 年 10 月 24 日把 Agensh 以 MIT 许可开源GitHub 上 v1.0 标签为 10 月 23 日 UTCREADME 标注 10 月 24 日随代码一起发布的还有实验启动脚本与复现指南。相关预印本《Agensh: Scaling Organizational Intelligence to 1,024 Agents》于 9 月 22 日发布在 arXiv10 月 25 日修订作者包括 Zhihao Zhan、Ting Song、Li Dong、Shaohan Huang、Jianxun Lian、Yan Xia 与 Furu Wei。说明口径以下数字来自项目 README 与公开发布的复现材料经 MarkTechPost 等媒体转述微软方面明确表示公开版本不能精确复现论文中的数字。ProgramBench 上五项最难任务FFmpeg、GROMACS、pandoc、PHP-src、ctags要求从可观察行为重建程序可跑原二进制但读不到源码六小时预算、无网络访问、GPT-5.6-sol 高推理强度下的平均最终测试通过率智能体数量平均通过率相对提升119.31%—820.68%7.1%3226.52%37.3%12828.78%约 49%pandoc 单项最能体现规模效应1 个智能体 33.89%128 个 50.94%1024 个 55.06%都在同样的六小时预算内。换成 GPT-6.1-sol 后pandoc 从 1 个智能体的 56.19% 提升到 32 个的 79.59%相对 41.64%。二、技术拆解2.1 五步循环协调逻辑写在提示里不在运行时里每个 worker 跑的是同一段循环收集上下文 → 认领子任务 → 执行动作 → 验证结果 → 合并进展。所有 worker 异步推进没有谁在下发工单。关键在于协调过程被嵌进提示本身而不是硬编码进运行时。每个 worker 拿到的提示相同唯一的差别是各自的标识符。这个设计选择很直接既然要验证的是「组织能不能自组织」那组织规则就不能写死在框架里否则测的是框架而非组织。认领冲突怎么处理靠通信。worker 发出认领声明有重叠时通过对等通信自行消解。2.2 三件套基础设施都是现成的开发工具组件承担什么备注Gitea共享工作区分支、PR、合并冲突自托管Mattermost团队频道广播 紧急问题直发消息自托管上下文板board存放分类笔记OBSERVED、FAILS、CLAIMS、PATCH_SUMMARY改编自开源项目 DeLM单个 worker 的循环来自 GitHub Copilot CLI通过 Agent Client ProtocolACP会话驱动。此外还有一个 router 服务中继事件与消息一个空闲看门狗在 worker 十分钟无动作时推它一把。实验配置里的安全边界也值得看每个 worker 跑在容器里内存上限 64 GiB以非特权用户运行网络访问只允许到模型网关PR 需要零个审批直接推 main 分支被禁止实验期间关掉了 CI 合并闸门。单节点默认 8 个 worker1024 个智能体的实验用了 16 个节点、每节点 64 个。2.3 涌现出来的不是混乱是分工README 里的表述是随着团队变大「自组织的对等协调、集成工作流与专业化角色逐渐涌现」尽管所有智能体起步时都是同一个对等角色。这条最值得琢磨。它意味着角色不是被分配的是在协作压力下分化出来的——有人专做集成、有人专做验证。对企业里想落地多智能体的团队这是个提醒与其精心设计角色拓扑不如把共享状态层做扎实让角色自己长出来。三、对开发者的三个影响其一共享状态层会先于模型能力成为瓶颈。给一个具体动作在设计多智能体系统时先确定「谁持有一致状态」——是 Git 仓库、消息总线还是一块共享黑板把它当作基础设施来配置容量与备份而不是当作日志。其二可复现的门槛比想象中高。公开版本只在单机运行要求 Linux cgroup v2 systemd、Docker 免密 sudo、ProgramBench 单独 checkout 到指定 commit、每任务独立容器镜像模型网关自备自付。给一个具体动作想评估这类 harness先跑 8 worker 的单节点基线与官方复现脚本对齐再谈扩容。其三智能体数量与效果不是线性关系。1→8 只涨 1.37 个百分点32→128 涨 2.26 个百分点且 pandoc 的收益明显好于其他任务。给一个具体动作别按「加机器就涨点」的思路申请预算先用 8 个智能体的基线测自己业务上的任务确认有正收益再扩。四、我的判断与前提以下是判断不是事实「编排器天花板」真实存在但只在任务可高度拆分时才明显。依据是 ProgramBench 这类「按行为重建程序」的任务天然可切分换成强耦合的业务流程去掉编排器可能换来的是反复返工。规模收益主要来自并行搜索空间而非协作质量。依据是 pandoc 涨得最多而它的子任务相互依赖相对少mean 曲线在 32→128 之间明显变平。这套架构对企业内部落地的启发在基础设施层不在智能体层。依据是三件套Gitea/Mattermost/board全部是成熟开源组件——企业里本来就有一套等价物缺的是把它们打通成智能体可用的状态层。五、结语与产业坐标Agensh 给出的不是一个可以直接搬用的产品而是一份可核对的实验报告在可拆分任务上去掉中心编排器、把协调下沉到共享状态层规模确实还能带来收益——代价是需要 16 个节点、1024 个容器和一整套可复现的工程配置。把视角拉到企业内部多智能体真正落地时最难的不是让智能体变聪明而是让几十个进程在同一份状态上工作而不互相覆盖。这件事在企业里其实有现成答案——事件驱动的消息总线、版本化的工作区、可回放的操作日志。智能体只是把并发量从几个人提到了几百个对状态层的要求从「够用」变成了「要能承压、能回放、能审计」。这类状态层在国产化环境里还有一层约束部署要落在内网组件要能在信创软硬件栈上运行存量系统也要能接进来。金蝶天燕 Apusic 这条线上ADMQ 分布式消息队列承担的就是这类事件与状态的承载把每个 worker 的认领、发现与合并动作变成可订阅、可回放的事件流让「谁在做什么」有据可查。这不是让智能体跑得更快的组件而是让它在出问题后能被复盘清楚的基础设施。具体吞吐与部署形态以官方文档为准。问一句如果你的团队明天要上 50 个智能体干活你们现在的共享状态层顶得住吗顶不住的话先补状态层别先加智能体。
