Agensh:将组织智能扩展到 1,024 个智能体

TL;DR Agensh 提出去中心化自组织多智能体框架，无需中央协调器即可扩展至 1024 个 agent；实验显示 agent 数量成为新的缩放维度，显著提升 ProgramBench 与 pandoc 的任务通过率。

问题

多智能体系统（MAS）通过在复杂任务上并发执行多个 worker 来降低延迟，近期已有多个框架（如 AutoGen、CrewAI）尝试规模化 agent 组织，但多数仍依赖中心编排器。

现有方法局限

主流 harness 中，一个中心 orchestrator 负责分解任务、分配子任务并协调所有 worker。这种架构存在三个关键瓶颈：

• 中心通信瓶颈：中心节点需要与每个 worker 逐一交互，状态同步和消息轮次随 agent 数量线性甚至超线性增长。
• 推理容量瓶颈：中心编排器自身的 LLM 上下文窗口和推理带宽有限，难以实时处理上百个并发子任务的分配与冲突仲裁。
• 单点故障：中心节点一旦丢失上下文或产生错误规划，整个多智能体组织无法继续推进任务。

实测中，当 agent 数量从数十扩展到数百时，部分框架的任务完成时间反而上升，最终 test-pass rate 提升停滞。

为什么难且重要

无中心编排的自组织 MAS 需要解决任务发现、冲突避免、结果合并和共享状态一致性等分布式系统经典难题，同时要避免引入新的同步开销。Agensh 采用共享工作空间、消息接口和共享上下文三组件，让 concurrent workers 异步执行合作循环，这要求基础设施既高效又鲁棒。

业界对可水平扩展到上千 agent 的 harness 有现实需求：复杂代码重构、多模块系统测试、大型文档转换等任务在硬延迟约束或时间预算下必须大规模并行。

类比：类似分布式计算从 master-slave 演进到 peer-to-peer，LLM 驱动的 agent 组织也需要从中心化调度走向自组织协同，才能支撑生产级高并发任务。

核心洞察

• 去中心化自组织架构是多智能体系统扩展到上千规模的关键路径：通过 **共享工作区**、**消息接口** 和 **共享上下文**，每个 worker 自主认领子任务、异步协作，无需中央 orchestrator 调度。与 AutoGen、MetaGPT 等依赖中央协调器的 harness 不同，Agensh 消除了任务分配和 worker 协调的容量瓶颈，使 1,024 个并发 agent 的协作成为可能，更适合硬延迟约束下的复杂任务。
• 智能体数量本身是提升多智能体组织任务成功率的新缩放维度：在 **ProgramBench** 五个最难任务上，从 1 到 128 个 agent 将平均最终 test-pass rate 从 19.31% 提高到 28.78%（相对提升约 49%）；在 **pandoc** 上从 33.89% 提升到 55.06%（1,024 agents）。相比单 agent 或小规模组织，更大组织更早达到同等通过率，说明增加并发 worker 可以在时间预算内扩展通用智能边界，类似模型参数缩放，但作用于组织层。

方法

输入

Agensh 接收一个复杂任务（如 ProgramBench 中的编程任务），任务被分解为可并发的子任务。

关键模块

Agensh 的核心是自组织多智能体合作循环（multi-agent cooperation loop），无需中央协调器，每个 worker 并发执行以下异步步骤：

1. 收集上下文（gathering context）：从共享工作空间和消息接口获取最新状态；
2. 声明子任务（claiming and self-assigning sub-tasks）：worker 自主认领尚未完成的子任务；
3. 执行动作（taking action）：执行具体工作（如编写代码）；
4. 共享发现（sharing findings）：将中间结果发布到共享工作空间；
5. 验证结果（verifying results）：检查工作正确性；
6. 合并进度（merging progress）：将完成的工作整合到总体任务中。

该循环由三部分基础设施支撑：

• 共享工作空间（shared workspace）：维护提议、进行中和已完成的工作状态；
• 消息接口（message interface）：支持 worker 之间的点对点或广播通信；
• 共享上下文（shared context）：存储可复用的发现和工作意图，减少重复探索。

这三者共同构成了一个无中心节点的协作环境，为水平扩展至上千个 agent 提供了工程基础。

输出

最终输出为合并后的任务解决方案（如通过测试的代码），整体通过率随 agent 数量增加而提升（在 ProgramBench 上，1→128 个 agent 使通过率从 19.31% 提升至 28.78%）。

与同类中心化编排框架（如 AutoGen、MetaGPT 等）相比，Agensh 消除了 orchestrator 的单点容量瓶颈，通过去中心化自组织实现水平扩展。

实验

实验设计

Agensh 在五个最难的 ProgramBench 任务上评估多智能体扩展性，使用 GPT-5.6-sol (high) 作为 agent 后端。从 1 个 agent 逐步扩展至 128 个 agent，并额外在 pandoc 任务上扩展至 1,024 个 agent。系统采用无中心编排器的自组织合作循环：worker 异步执行“收集上下文→认领子任务→执行→分享结果→验证→合并”流程，通过共享工作区、消息接口和共享上下文通信。主要指标为最终测试通过率，并记录达到特定通过率所需的时间成本。

关键发现

• ProgramBench 五任务平均最终测试通过率从 1 agent 的 19.31% 提升至 128 agents 的 28.78%，相对提升约 49%。
• pandoc 任务上，扩展至 1,024 agents 将最终测试通过率从 33.89% 提升至 55.06%，提升 21.17 个百分点。
• 规模越大，达到同等通过率的时间越早，表明并发执行带来显著的延迟收益。
• 轨迹分析显示自组织合作形式随规模递进：8 agents 出现实现协调；32 agents 出现跨 worker 集成管理；128 agents 出现专业化分工与工作流标准化；1,024 agents 出现组织级角色分工。

与基线对比深度解读

基线为单 agent（1 agent），部分现有框架使用中心编排器。Agensh 相比单 agent 在多任务上获得 49% 相对提升；相比中心化编排，其去中心化共享基础设施避免了中心节点成为扩展瓶颈，使 1,024 agents 规模可行。这验证了 agent 数量作为新的扩展维度，为复杂任务在硬延迟约束下提供了一条不同于增大单模型或中心化调度的路径。

行业影响

落地场景

Agensh 的去中心化多智能体架构适用于长时程、可并行分解的复杂任务，典型场景包括：

• 代码生成与重构：大型代码库的模块化改写、测试生成、文档同步，可让多个 worker 并行处理不同子模块。
• 数据处理与格式转换：类似 pandoc 的任务，如批量文档格式迁移、多语言内容转换、ETL 流水线并行化。
• 企业级自动化工作流：多步骤报告生成、合规审查、数据标注等需要分工与合并的任务。

商业价值

主要价值体现在延迟降低与任务成功率提升。论文显示在 ProgramBench 最难任务上，从 1 到 128 agents 通过率相对提升约 49%；pandoc 任务从 1 到 1024 agents 通过率从 33.89% 升至 55.06%。

• 降本：无需人工分配任务，自动协调减少管理开销。
• 增收：更高的一次性通过率减少重试与人工修复成本。
• 体验提升：硬延迟约束下（如实时代码补全、批量文档处理）可更快返回结果。

与现有产品/工作流的接口

Agensh 提供共享工作区 + 消息接口 + 共享上下文，可作为微服务部署在现有 agent 平台之后：

• 通过 API 接入现有 CI/CD 流水线或云函数，将子任务下发到 Agensh 集群。
• 与 LangChain / AutoGen 等框架兼容，替换其中心化 orchestrator，仅需实现 worker 的 loop 逻辑。
• 使用事件驱动运行时（详见论文附录）支持异步并发，适合 Kubernetes 等容器编排环境。

具体落地 use case

1. 电商内容生成：批量生成商品描述、多语言翻译、SEO 优化，每个 SKU 由一个或多个 agent 并行处理，显著缩短上架时间。
2. 金融报告自动化：同时解析多个财报、提取指标、生成摘要并交叉验证，Agensh 可在硬时间窗口内完成多文件处理。

局限

• 论文只在 **ProgramBench** 的五个最难任务和 **pandoc** 一个任务上验证了 **Agensh**，任务类型以编程为主，缺乏对推理、知识问答、开放域任务等的评估。实验仅使用 **GPT-5.6-sol (high)** 单一模型，未验证该方法在其他模型（如开源模型或不同能力等级模型）上的表现。这种受限的任务和模型选择使得结论的可推广性存疑，无法确认从 1 到 1024 agents 的性能提升是否普遍适用于其他任务或模型组合，未来需要在更多样化的基准和模型上系统验证。
• 论文强调无中心 orchestrator 解决了可扩展性瓶颈，但实验并未与具有集中式 orchestrator 的框架（如 **AutoGen**、**MetaGPT**、**CAMEL** 等）在相同任务和相同 agent 数量下进行直接比较。因此无法量化 **Agensh** 相对于传统架构在吞吐量、延迟或成功率上的具体优势，也无法证明去除中心节点是否真的避免了瓶颈，还是只是将瓶颈转移到了共享 workspace 或消息接口。缺少 baseline 对比削弱了“新 scaling 维度”的论证力度。
• 论文主要报告 test-pass rate 随 agent 数量提升，但未报告计算成本、token 消耗或通信开销。增加 1024 个 agents 可能带来巨大的资源消耗，如果性能提升的收益无法覆盖成本，该方法在实践中的价值会大打折扣。此外，轨迹分析虽然展示了 self-organized cooperation 的涌现，但缺乏量化指标来衡量合作效率（如任务重复率、冲突次数、合并质量等），使得合作行为与性能提升之间的因果关系尚不清晰。