先看证据
把机制串起来
多智能体 harness 不等于模型本身：它规定多个独立 agent 如何分工、交流和整合结果。中央编排式架构由一个主 agent 分派任务；Agensh 去掉的是这个主 agent，而不是共享服务或协调规则。异步协作能并行推进工作，但也会带来重复劳动、冲突和整合成本。
所有 worker 执行相同的五步循环：读取目标与团队进展、认领子任务、行动并分享发现、按验收标准验证、合并进展后再循环；循环写在提示词中，运行时不设主 agent 派活。Gitea 提供分支、PR 和共享代码库，让任务进展落到可检查的代码变更上，冲突也会显式暴露；Mattermost 用频道和私信处理公告及认领碰撞。共享上下文板保存事实、失败、认领和补丁摘要等短记录，并支持检索，让新发现能被队友复用。这样设计减少了单一协调者的负载，但把秩序维护转移给共享状态、消息和 wor
['适合可拆分、可验证且预算或时限明确的复杂编程任务', '任务需提供可独立验收的子目标，减少重复认领', '小团队可用单节点 Docker Compose；1024人实验用了16节点', '不宜把五项任务结果外推到所有任务或模型']
撤掉主控，不是撤掉协调
Microsoft Research于2026年10月24日开源了Agensh，这是一个面向大型编码 agent 团队的去中心化 harness，目标是缓解传统多智能体系统对中央编排器的依赖。常见的 orchestrator-worker 设计由一个主 agent 规划任务、分派工作并整合结果；Agensh则让每个 worker 自己寻找子任务，并通过共享空间与其他 worker 协作。
这个变化值得技术负责人读，不是因为“没有主控”天然更先进，而是因为协调责任被重新分配了。原先由主 agent 承担的规划与冲突处理，转而落在团队约定、共享状态和执行基础设施上。Agensh展示的核心问题因此不是能不能并行启动很多模型，而是一个没有统一调度者的团队，能否形成足够可靠的协作秩序。
协作规则写在循环里，状态留在共享设施中
Agensh让每个 worker 异步重复同一套五步循环：读取目标和同伴进度，认领子任务，动手并尽早分享发现，按验收条件验证，再把进展合并回共享仓库。发生认领重叠时，worker可以直接联系对方处理，而不是等待主 agent 裁决。循环主要写在 prompt 中，每个 worker 收到的提示基本相同，只在身份标识上有区别。
这套做法并非没有中心化设施。Gitea承载共享仓库、分支和合并请求，Mattermost用于团队消息与私信，另有一个保存短记录的共享上下文板，记录观察、事实、失败、认领和补丁摘要等信息。换句话说，Agensh去掉的是统一指挥的主 agent，不是支撑协作的服务层，也不是底层单 agent 执行框架。公开仓库说明，实验是在Copilot harness的单 agent 循环之上集成Agensh，其他 harness 需要通过适配器接入。
成绩上升，但“扩到1024”不是全套基准结论
主实验使用ProgramBench中五个最难的程序重建任务，分别涉及FFmpeg、Gromacs、Pandoc、PHP-src和ctags。系统需要根据观察到的行为和随附文档，在离线环境下重建程序，预算为六小时。使用GPT-5.6-sol、high reasoning effort时，五项任务的平均最终测试通过率从1个 agent 的19.31%升到128个的28.78%，提高9.47个百分点，约为49%的相对提升。
但1024这个规模对应的是Pandoc单项，不是五项任务均值。GPT-5.6-sol在Pandoc上的通过率由1个 agent 的33.89%升至128个的50.94%，在1024个时为55.06%；速度也有改善，128个 agent 在30分钟时通过率达到30%，32个和8个分别要到60分钟和90分钟。仓库另报的GPT-6.1-sol结果是另一组配置：Pandoc从1个 agent 的56.19%升至32个的79.59%，不能与GPT-5.6-sol的数据混算，而且这组数字不在v1论文中。
扩容的收益来自并行，也来自工作可见
这些结果支持一个有限但有用的判断：在这类复杂重建任务上，增加 worker 可以提高最终得分，也能让部分目标更早达到。但收益不是“agent 数量乘上去，能力就等比例增加”。五项任务均值从1个到8个只增加1.37个百分点，随后才继续上升；而公开材料没有证明所有编程任务都具备同样的可拆分性，也没有给出与其他多智能体 harness 在相同模型、任务和预算下的定量对照。
架构上的关键，是让并行工作足够可见、可复用、可校验。认领信息减少重复投入，短发现让别的 worker 能接续已有探索，验收条件约束局部成果，Git合并则把接口和冲突暴露出来。这些机制不是额外装饰：没有共同工作区和可检索的进展记录，更多 worker 也可能意味着更多重复劳动与彼此不兼容的补丁。Agensh把这类协调规则放进共享协议，而不是寄托在一个主 agent 的判断上。
把规模当成实验变量，而不是部署目标
实际部署的门槛也不能被“开源”或单机默认配置掩盖。仓库默认是Linux与Docker Compose上的单节点配置，8个 worker；报道中的1024-agent Pandoc运行则使用16个节点、每节点64个 agent，worker内存上限为64 GiB，每个 worker 还有输入与输出 token 限制。单节点复现指南不等于完整复现这次分布式大规模运行，因而两者的基础设施条件不能直接画等号。
对技术团队来说，更稳妥的做法是先用代表性任务测出扩容曲线，同时记录最终质量、达到目标的时间、模型调用与基础设施消耗，以及认领冲突和合并失败带来的返工。公开材料证明了Agensh在特定基准和模型配置下能把团队扩得很大，并展示了部分收益；它没有证明规模本身就是质量，也没有给出足以判断单位成本或普遍优势的对照数据。值得移植的首先是显式协作协议，至于开多少个 agent，应由任务的可分解程度和实测收益决定。