编者摘要：Agensh 是微软研究院提出无中央调度器的可扩展自组织多智能体框架，解决传统 “调度器‑工作智能体” 架构受中心节点性能瓶颈的问题。框架依靠三大基础设施：共享工作区、消息接口、共享上下文；所有智能体异步并发执行 5 步协作循环：收集上下文、认领子任务、执行动作、校验结果、合并进度，自主完成任务拆解、冲突处理与成果整合，无需中心化分配任务。

基于 ProgramBench 高难度软件工程基准测试，使用 GPT‑5.6‑sol 模型：5 个最难任务上，智能体从 1 扩至 128，测试通过率从 19.31% 提升至 28.78%，相对提升 49%；pandoc 任务扩展至 1024 智能体，通过率由 33.89% 提升至 55.06%。更大规模智能体不仅提升任务完成质量，还可降低达成目标性能的时延。

随智能体数量增长会逐级涌现协作模式：对等协同→多智能体集成→标准化工作流→组织级角色专业化。智能体数量被证实为多智能体全新扩展维度，可为高时间压力下复杂任务提供解决方案。

10 个关键问题Q&A

1. Q：Agensh 和传统多智能体最大区别？
   A：传统依赖中央调度器做任务拆解分配；Agensh 无中心调度器，智能体自主认领子任务、异步自组织协作。
2. Q：Agensh 三大基础设施组件是什么？
   A：①共享工作区，存储全部版本工作成果；②消息接口，处理广播、私信冲突协商；③共享上下文，记录观测、事实、失败、认领、补丁摘要。
3. Q：Agensh 的 5 步协作循环流程？
   A：收集上下文 →认领子任务 →执行动作 →校验结果 →合并进度，循环往复。
4. Q：论文的测试基准是什么？任务限制？
   A：ProgramBench，要求无互联网、6 小时时限，从零复现软件行为，不能反编译二进制。
5. Q：1→128 智能体核心实验数据？
   A：五项最难任务平均测试通过率 19.31% 提升至 28.78%，相对提升 49%。
6. Q：pandoc 任务 1024 智能体实验结果？
   A：通过率从单智能体 33.89% 提升至 55.06%；规模增大同时缩短达成同等性能的耗时。
7. Q：随着智能体规模扩大涌现哪些协作模式？
   A：对等协同→多智能体集成→标准化工作流→组织级角色专业化。
8. Q：Agensh 是否需要改写底层单智能体框架？
   A：不需要。属于上层组织框架，提示词驱动，可适配 Copilot、Claude Code 等不同底层智能体。
9. Q：“智能体数量是新缩放维度” 含义？
   A：固定大模型能力，单纯增加协作智能体数量，就能持续提升复杂任务质量、降低时延。
10. Q：大规模多智能体如何避免大量重复工作？
    A：依靠共享上下文记录失败尝试、工作认领；消息接口处理任务冲突；智能体读取同伴成果，规避重复劳动。

詹志浩∗ 宋婷∗ 董理† 黄少晗 连建勋 夏妍† 魏福如† 微软研究院 项目主页：https://aka.ms/GeneralAI

∗共同一作，†通讯作者。技术报告，arXiv:2609.26781v1 [cs.CL]，2026‑09‑22

多智能体系统可以通过并发执行任务降低复杂任务的处理时延。已有多项开创性框架支持多智能体系统。但现有多智能体框架的可扩展性，往往受限于中央调度器分配任务、协调工作智能体的处理上限。 为解决该瓶颈，本文提出Agensh：一套无中央调度器、可扩展的自组织多智能体运行框架。并发运行的工作智能体执行一套多智能体协作循环：以异步方式持续收集上下文、认领并自主分配子任务、执行动作、共享发现结果、校验结果、合并工作进度。 该协作循环依托一套智能体组织基础设施，包含三大组件：共享工作区，存放待开展、进行中和已完成的工作；消息接口，供工作智能体相互通信；共享上下文，保存可复用的发现结论与工作意图。

为验证 Agensh 的扩展能力，本文在 ProgramBench 基准中 5 个最难任务上，使用 GPT‑5.6‑sol（高推理模式）开展评测。智能体数量从 1 个提升至 128 个时，平均最终测试通过率由 19.31% 提升至 28.78%，相对提升约 49%。规模更大的智能体组织能够更快达到同等测试通过率。 在 pandoc 任务上，智能体从 1 个扩展至 1024 个，最终测试通过率从 33.89% 提升至 55.06%。智能体运行轨迹进一步表明：随着组织规模扩大，多种自组织协作模式会逐步涌现并形成标准化。 实验证明：智能体数量是多智能体组织的全新扩展维度，可以拓宽通用智能的能力边界，同时为严苛时延约束、有限时间预算下的复杂任务提供可行解决方案。

项目页面：https://aka.ms/Agensh 代码仓库：https://github.com/microsoft/Agensh

图 1：在 6 小时时限、无互联网访问条件下从零构建 pandoc，智能体规模从 1 扩展到 1024。最终测试通过率从单智能体的 33.89% 提升至 1024 智能体的 55.06%。随着组织规模增长，自组织协作行为逐层涌现：对等协同 → 多智能体集成 → 标准化工作流 → 专业化角色。

图 2：多智能体系统架构对比。传统方案：智能体由中央调度器统一管控；Agensh：依靠轻量化基础设施实现自组织协作。传统框架中工作智能体之间的协作受中央调度器能力制约；Agensh 中，自组织的工作智能体通过轻量化智能体组织基础设施，共享状态、同步工作进展。

1 引言

单智能体系统依托大语言模型读取上下文、调用工具执行动作、更新状态，迭代向着目标推进。但它受限于单一上下文窗口、单条动作流与单条记忆流。串行执行的约束，会让复杂现实任务产生很高时延。想要突破这些限制，就需要借助多智能体系统，增加智能体数量。

已有多个框架支持多智能体，例如 Codex 子智能体、Claude Code 子智能体与智能体团队、Copilot 集群、Kimi 智能体集群等。这类框架普遍采用调度器‑工作智能体架构：主智能体负责规划、拆解任务，分配给并发的工作智能体并对其管控。该架构往往需要经过训练的调度器来完成任务规划与拆解。但整套系统的可扩展性会被调度器管理、协调智能体、整合结果的能力从根本上限制。

针对这一局限，本文提出 Agensh，无中央调度器的可扩展多智能体组织框架。自组织的工作智能体以并发、异步方式运行，通过轻量化智能体组织基础设施共享状态与进度（见图 2）。这套基础设施包含三项协同组件：

1. 共享工作区
   保存组织内正在开展、已整合完成的工作；
2. 消息接口
   处理全组织广播消息与紧急点对点消息；
3. 共享上下文
   保存其他智能体产出的可复用发现结论与工作意图。

Agensh 还为每个工作智能体配套一套异步协作循环。每一轮循环中，智能体首先读取用户目标的上下文，获取同伴的工作进展，认领一项子任务；通过消息机制处理任务重叠或冲突后，调用工具执行子任务。工作过程中，一旦得到可供他人参考的结论，就更新共享上下文。完成并校验工作之后，将成果合并进共享工作区，随后回到收集上下文环节，处理下一项子任务。 这套多智能体协作循环，让各个智能体的个体成果汇聚为集体贡献；基础设施则保证全部智能体都可以访问累计的工作内容、发现结论与消息。

本文选用 ProgramBench 基准开展可扩展性测试。这是面向智能体软件工程难度最高的基准之一：智能体组织需要在无网络访问、6 小时时间预算下复现参考软件的行为。本文选取其中难度最高的 5 项任务，对应参考仓库包含数千个文件，源代码达数百万字节。 实验结果：智能体规模从 1 增长到 128，五项任务平均最终测试通过率从 19.31% 提升至 28.78%，相对提升约 49%。规模更大的智能体组织可以更快达到同等测试通过率，说明更多并发智能体可以降低达到指定性能水平的时延。 在 pandoc 任务上，智能体从 1 扩展到 1024，最终测试通过率由 33.89% 提升到 55.06%。运行轨迹记录显示：随着组织扩张，自组织协作模式不断丰富：从对等协同、多智能体集成，逐步发展为标准化工作流、组织级的专业化角色。

综上，Agensh 证明智能体数量是多智能体组织的全新扩展维度：既为强时延约束、有限时间预算下的复杂任务提供落地方案，也说明扩大多智能体组织规模可以拓展通用智能的能力边界。

2 多智能体组织运行框架

本章介绍 Agensh，它将多智能体协作循环与智能体组织基础设施结合。多智能体协作循环指导全部工作智能体，把个体产出转化为经过校验、并入集体的贡献；基础设施让全部智能体都能够访问积累的工作、结论与消息。

2.1 多智能体协作循环

框架的核心抽象就是这套循环。Agensh 中的每一个工作智能体，并发、异步执行如下 5 步协作循环：

图 3 Agensh 多智能体协作循环：各智能体以自组织方式并发执行：收集上下文 → 认领子任务 → 执行动作 → 校验结果 → 合并进度，循环往复直至达成用户目标。全部智能体异步推进，依托基础设施共享进度。

1. 收集上下文
   智能体读取用户目标、系统当前状态、同伴进度、消息与已积累结论，明确哪些工作已经完成、还有哪些待处理；同时与环境交互，规划下一步有价值的行动。
2. 认领子任务
   智能体提出自己要完成的子任务，将任务范围作为一条CLAIM（认领声明）追加写入共享上下文。若两个智能体的认领出现重叠或冲突，则通过点对点消息自行解决。
3. 执行动作
   智能体在本地借助工具完成自己认领的子任务。每当产出可能帮助同伴的结论，就向共享上下文同步中间进展。
4. 校验结果
   将本地产出与子任务验收标准比对。不满足验收标准则迭代调整方案，直至达标。
5. 合并进度
   将自身贡献合并入共享工作区，让其他智能体可以使用；同时发布更新说明，描述改动内容、实现思路与校验证据，供同伴在此基础上继续开发。如果合并发生冲突，则读取同伴最新进度，解决冲突后再次尝试合并。

完成第五步合并后，智能体回到第一步，基于刚刚整合完成的集体工作、同伴最新更新，再次收集上下文，寻找下一项子任务。 智能体自主提出、认领子任务，实现子任务发现与分配的自组织。全部智能体异步运行，不需要等待其他同伴完成本轮迭代。随着循环不断执行，智能体的发现与校验后的贡献通过共享基础设施持续积累，推动整个组织向着用户目标前进。

图 4 Agensh 组织基础设施。

• 共享工作区：已完成工作、进行中工作、待开展工作
• 消息接口：同步进度、解决冲突、避免重复劳动
• 共享上下文：观测记录、工作认领声明、失败尝试记录

2.2 智能体组织基础设施

多智能体组织内部，工作智能体需要读取彼此成果、就子任务开展沟通、留存结论指导后续工作。如图 4，Agensh 提供三项协同机制：共享工作区、消息接口、共享上下文。

共享工作区共享工作区是一套文件系统，保存组织内的各项工作，包括开发中成果与整合完成的结果。支持并发写入与异步读取：智能体可以独立开发各自模块，同时读取同伴已经发布的工作。保存版本历史，支持贡献合并，出现合并冲突时交由智能体回溯并解决。 Agensh 使用 Git 平台实现共享工作区。智能体在私有副本与分支上修改，再将贡献合并入主分支；Git 记录变更来源、检测文本合并冲突，同时托管议题与合并请求。

消息接口消息接口用于智能体之间协调正在进行的工作，处理任务归属重叠，解决依赖冲突。 消息接口设有共享任务频道用于团队公告，也支持点对点紧急私信。优先级较低的频道消息，会在智能体每一轮循环开始时送达；高优先级的私信会在基础设施工具调用结束后立刻送达。消息接口完整留存会话历史，消息全部异步投递。 依靠这套机制，智能体可以及时处理认领冲突、协商依赖、请求协助，而不会阻塞其他同伴继续工作。

共享上下文共享上下文保存组织内可供复用的发现结论与工作认领声明，该设计思路源自 DeLM。 智能体向共享上下文发布结构化的简短记录：

• OBSERVED
  观测到的行为；
• FACT
  确认成立的事实；
• FAIL
  失败、无效的尝试；
• CLAIM
  正在开展的工作认领；
• PATCH_SUMMARY
  描述已完成变更。

底层为追加写入式数据库，保存近期记忆。为适配长周期任务，配套context grep检索工具，智能体可以检索全部历史记录，不限于近期缓存。 新增的共享上下文条目属于高优先级更新，当其他任意智能体完成一次基础设施工具调用后就会转发，让同伴可以看到这些发现。

以上三项机制，将每个智能体的本地行为与组织共享状态连接起来。智能体就可以复用同伴的结论、处理子任务重叠，在自身协作循环内产出可被整合的贡献。

2.3 实现方式

Agensh 是叠加在单智能体框架之上的组织层框架，并非用来替代单智能体框架。 对于每一个工作智能体，底层单智能体框架维护本地智能体循环：维护会话状态、调用模型、执行工具，输出智能体下一步响应。Agensh 负责在该循环之上增加组织级行为：智能体身份、协作协议、事件路由、任务调度、共享工作区访问、消息通信、共享上下文，以及容错保活机制。 简言之：底层单智能体框架决定单个智能体如何推理与行动；Agensh 决定多少个智能体接收事件、共享状态、协同为共同目标反复贡献。

单智能体循环与多智能体协作循环之间的接口设计极简，支持即插即用。Agensh 依靠每个智能体提示词内的工作流指令实现协作循环逻辑，而不是将循环硬编码到底层运行时。完整的智能体提示见附录 A；除智能体 ID 不同之外，所有智能体提示词完全一致。 因此，Agensh 可以通过轻量的适配层对接不同底层框架（如 Claude Code、Copilot），无需修改协作循环、共享服务与底层智能体循环。

工程实现：共享工作区基于 Gitea 搭建；消息接口基于 Mattermost 实现；共享上下文借鉴 DeLM 的核心思路，调整工具格式与智能体指令。附录 B 介绍仓库事件、消息、共享上下文如何投递至智能体。

3 将多智能体组织扩展至 1024 个智能体

本文使用 ProgramBench 基准，测试大规模多智能体组织能否在复杂长周期任务上拓展智能体软件工程的能力边界。 ProgramBench 要求智能体从零开始复现参考软件行为；设置 6 小时时间预算，禁用互联网，禁止直接获取已有实现代码。 本文选取 ProgramBench 中五项高难度系统：FFmpeg、gromacs、pandoc、PHP‑src、ctags。这是该基准 200 个实例中难度最高的五项任务（由 SOTA 模型平均通过率判定），覆盖多媒体处理、分子模拟、文档转换、语言解释器、代码索引。参考仓库包含数千文件，代码规模几十万至数百万行（见表 1），对长周期多智能体协作构成严苛考验。

表 1 ProgramBench 五大最难任务对应的参考仓库规模 | 任务 | 提交哈希 | 文件数量 | 代码行数 | 代码大小 (MB)| |---|---|---|---|---| |FFmpeg|360a402|10090|1549005|75.51| |gromacs|665ea4c|8982|815539|47.30| |pandoc|5caad90|2767|104336|4.86| |PHP‑src|c891263|26266|2812757|119.76| |ctags|243595e|7313|246228|9.15|

3.1 主要实验结果

图 5：1‑128 智能体规模下五项 ProgramBench 最难任务测试通过率。智能体从 1 增加到 128，五项任务平均最终测试通过率由 19.31% 提升至 28.78%。

实验固定使用模型 GPT‑5.6‑sol (high)，底层单智能体框架为 Copilot，总时间预算 6 小时。 智能体数量 1、8、32、128 时，五项任务平均最终测试通过率分别为 19.31%、20.68%、26.52%、28.78%。从 1 扩展至 128，得分绝对值提升 9.47 个百分点，相对提升约 49%。 五项任务整体表现随智能体规模增大呈上升趋势，证明：增加协同工作智能体数量，可以持续、显著提升长周期软件复现任务的完成质量。

图 6：1‑128 智能体，前两小时内的测试通过率变化。更大规模的智能体组织通常更早达到更高测试通过率。

图 6 证明：更多并发智能体还可以降低达到同等性能所需时延。运行前两小时内，规模更大的组织可以更快拿到相近通过率。 以 pandoc 为例：128 智能体在 30 分钟就突破 30% 通过率；32 智能体、8 智能体分别需要 60 分钟、90 分钟；单智能体在前两小时始终达不到该阈值。说明提升智能体数量，既可以提高最终任务质量，也能缩短达到指定性能的耗时。

回到图 1，pandoc 任务进一步把规模拓展至 1024 智能体。同样 6 小时预算，1 智能体通过率 33.89%，128 智能体 50.94%，1024 智能体达到 55.06%。相比 128 智能体提升 4.12 个百分点，相比单智能体提升 21.17 个百分点。证明 Agensh 可以稳定支撑一千以上智能体开展自组织协作。

固定底层模型与框架的前提下，实验证明：增加工作智能体数量，既提升软件复现任务质量，也加快任务速度。五项高难度任务的结果，加上 pandoc 上 1024 智能体的实验，共同验证：智能体数量是多智能体组织的全新扩展维度；自组织协作规模扩大，可以带来组织智能能力的增长，处理复杂长周期任务。

3.2 规模扩大时涌现出自组织协作

除性能收益之外，运行轨迹记录揭示智能体如何自发形成协作模式。所有智能体提示词几乎完全相同，仅智能体 ID 不同；但随着组织规模扩大，全新的自组织协作模式会不断涌现。

• 8 智能体：同伴协同实现
  智能体之间协商确定技术接口，各自独立实现符合接口规范的组件。 gromacs 任务中，智能体共同约定模块接口，之后各自独立实现命令模块。 FFmpeg 任务中，两个智能体发现认领范围重叠，通过沟通，其中一个调整工作范围，接手互补的任务。
• 32 智能体：多智能体集成管理
  多项贡献可以由多个智能体共同参与完成。 PHP‑src 任务中，一份贡献一开始得到若干智能体认可；之后另一个智能体找到反例，原有认可被撤销；作者修复问题，同伴重新评审，再由其他智能体完成合并。 智能体更多地参与集成流程，更多同伴参与沟通交互。
• 128 智能体：自组织专业化与工作流标准化
  该规模下出现专业化分工：智能体会依据他人过往经验选择评审者，并复用这套评审关系。还可以把集成工作转交给其他智能体，由对方解决冲突、验证整体成果并执行合并。 智能体会协商、遵循、复用已经形成的标准化工作流。pandoc 任务中两名智能体建立标准化集成协议：作者更新测试分支，提交提交哈希交由同伴校验合并；该协议被其他智能体复用。经历若干失败后，智能体进一步修订协作协议：授权同伴完整执行更新‑测试‑校验‑合并全流程；后续新合并请求中其他智能体明确接纳并执行这套修订后的流程。
• 1024 智能体：组织级角色专业化
  该规模下，大量智能体承担同类专业角色，在同一技术领域积累专长。 pandoc 任务中出现多名集成者；智能体可以联系多位候选集成者，选用第一个响应的对象，取消其余请求，再将待集成代码移交过去。 同一技术领域的多名专业智能体，还可以在某个智能体执行失败后接手继续工作。系统不再依赖任何单个智能体，组织整体鲁棒性得到增强。

上述观测补充了性能实验结果：随着智能体数量增加，协作模式不断拓宽：从对等协同，发展至多智能体集成、标准化工作流，直至组织级的角色专业化。 值得注意：全部协作模式完全自组织产生。智能体自主选择合作者、划分职责、通过同伴交互建立并迭代工作流。充分证明自组织多智能体系统的扩展潜力。

4 相关工作

多智能体组织与协作运行框架

已有框架采用不同方式实现任务分配、通信与结果整合。 Claude Code 支持持久化子智能体与异步智能体团队，但协作依然围绕固定主会话展开，由主会话派生其他智能体、管理共享任务、处理智能体间消息。 Codex 实现子智能体工作流，并行工作智能体产出结果回传给父智能体做统一汇总。 Kimi 智能体集群通过训练调度器完成任务拆解、调度子智能体实现低时延，但整体仍然属于调度器‑工作智能体并行范式。 本文研究的多智能体组织架构中，自组织的工作智能体共同承担任务发现、依赖协调、长周期结果整合的全部责任。

共享上下文与去中心化协同

DeLM 结合异步工作智能体、任务队列、共享上下文，智能体可以复用已有成果，不需要所有更新都经过中央控制器转发。 协作工具方面，ChatCollab 把人类与 AI 参与者作为对等个体部署在 Slack 环境，完成角色协商、请求处理、进度同步；SlackAgents 将 AI 智能体嵌入 Slack 工作空间完成通信与任务调度。 共享工作区方向，Carlini 编译构建实验使用 Git 仓库 + 任务锁文件协调 16 个 Claude 智能体；智能体自行挑选任务、合并修改，不存在专门调度智能体。 STORM 将多智能体编码任务重新定义为状态管理问题，用共享工作区替代互相隔离的智能体工作副本，保证本地状态一致性，写入时检测过期或冲突编辑。

5 结论

本文提出 Agensh：一套可扩展多智能体组织运行框架，将多智能体协作循环与轻量化智能体组织基础设施相结合。依托共享工作区、消息接口、共享上下文，自组织的工作智能体自主发现、认领子任务，交换发现结论，以并发异步方式整合各项贡献。这套架构不需要中央调度器分配任务、管控智能体，个体产出就可以汇聚为集体工作与集体知识。

实验条件固定为 GPT‑5.6‑sol (high)、6 小时时间预算。ProgramBench 五项最难任务上，智能体规模由 1 提升到 128，平均最终测试通过率从 19.31% 提升至 28.78%，相对提升约 49%。更大规模的智能体组织可以更快达到同等测试通过率，降低达成目标性能的时延。 pandoc 任务扩展到 1024 智能体时，测试通过率从单智能体的 33.89% 提升至 55.06%。 智能体运行轨迹显示：随着规模增长，自组织协作模式不断丰富：对等协同、多智能体集成、标准化工作流，直至组织级角色专业化。

上述结果证明：智能体数量是多智能体组织的全新扩展维度。借助 Agensh，扩展协作规模，既为强时延约束、有限时间预算下的复杂任务提供可行方案，也为拓宽通用智能的能力边界开辟新路径。

附录 A 工作智能体提示词（节选）

1024 智能体配置下 pbench‑team1‑worker1 的提示词；其余智能体仅替换 worker 编号，其余文本完全相同。

# 你好
你是 pbench‑team1‑worker1。
## 你的工作环境
你与1024位同伴协同工作。工作由gitea跟踪；你通过mattermost沟通；你在共享上下文面板发布发现。
- **gitea**：议题#1对应总任务；你为自己接手的领域新建议题；PR承载具体工作。容器内访问地址为 http://gitea:3000，所有克隆、拉取、推送、curl、API调用均使用该地址。gitea返回的clone_url/html_url是外部地址（http://gitea.localhost:<port>），在容器内部无法访问，见到后一律替换为 http://gitea:3000。
- **mattermost**：团队频道 pbench‑task，发言简洁具体。账号格式 pbench‑team1‑worker1 … pbench‑team1‑worker1024；@worker1 无法匹配账号，请写完整账号。**点对点私信可以在对方本轮执行过程中送达，是解决任务冲突的快速手段，但会打断对方工作。**当你和其他智能体即将修改同一处内容，请发送私信；其余情况使用公共频道。
- **共享上下文面板**：追加写入的日志，保存所有智能体简短、经过验证的记录。每一轮执行时，面板内容会渲染到你的提示词内`==== SHARED CONTEXT ====`；同伴后续新增记录，会在你等待工具返回的中途送达。
使用`board_write`发布记录：
`OBSERVED`：观测到的参考程序行为；
`FACT`：你已经确认成立的事实；
`FAIL`：被证伪的假设（价值最高，避免同伴继续消耗时间）；
`PATCH_SUMMARY`：修复成果，格式 files= | idea= | evidence=；
`CLAIM`：你正在开展的工作，方便同伴选择其他方向。
单条记录长度限制（普通100字符，PATCH_SUMMARY最多300字符）；长内容放到detail字段，同伴使用`board_unfold`查看。
不要重复推导同伴已经发布的`FACT`，不要重试已经标记为`FAIL`的尝试。
`board_read`读取最近面板内容（最多2000条）；`board_grep`按关键词检索全部历史记录。支持多关键词：`,`代表或，`&`代表且，大小写不敏感。例如 `a&b,c&d`含义：(a且b) 或者 (c且d)。

## 团队规则
1024名程序员，地位完全平等。你自己认领要实现的内容，自己开发，自己合并成果，再选择下一项工作。你的同伴同时在运行；合并代码到main分支前，请同步main分支最新版本；和同伴对齐，避免重复劳动。你的目标始终是复现参考程序；只有当你的信息会显著影响其他人工作时，才调用协同工具。

# 当前任务：ProgramBench逆向重建
## 任务目标
你拿到一份预编译的参考二进制程序，挂载在每个容器的`/opt/pbench/executable`。任务：从零重建完整代码库，复现该二进制程序行为，代码库可编译并通过隐藏测试用例。

- 你**可以运行该二进制**：`/opt/pbench/executable --help`，传入各类输入，观察输出，测试边界用例。这是理解目标行为的唯一信息来源（再加上仓库内文档与资源）。
- 你**不能读取二进制字节内容**；cat / od / objdump 都会提示权限拒绝。这是硬性规则，不是故障。禁止反编译、转储二进制，属于作弊；就算尝试，也无法读取。

## 铁则（违反任意一条，整个任务判0分）
1. **完全自主**：整个团队自行定义需求、拆解工作、自行决策、自行收尾。不存在外部输入；不要等待指令，不要在mattermost询问“下一步做什么”——答案永远是：推进重建工作。
2. **禁止互联网**：集群整体离线。git clone原始项目源、pip install、npm i拉取远程包全部会失败。不要尝试从网络获取原始源代码，既做不到，也属于作弊。只能使用容器内部已经预装工具链(gcc/make/python/node等)。
3. **交付硬性约束**：仓库根目录必须存在`compile.sh`脚本；运行脚本，在根目录生成可执行文件`./executable`。评测工具会对仓库HEAD打包解压，删除已经提交的`./executable`，运行`./compile.sh`，再用生成的`./executable`执行隐藏测试。因此`compile.sh`必须负责生成`./executable`，不能仅做赋权操作。
> 根目录没有compile.sh直接得0分。

## 永远优先第一步
**运行 `/opt/pbench/executable`，观察它的行为。**任何重建工作，都从理解程序实际行为开始。

## 工具使用说明
**事件驱动模型**：发生重要事件，环境向你推送消息：
event_id=... [event] <- gitea / mattermost / ...
source=... kind=...
observed_at=... summary: ... <-发生了什么、去哪里查看详情
事件只陈述客观事实；如何处理事件由你决定。
点对点私信、同伴新写入面板记录，可以在你本轮执行中途送达，追加到工具返回结果。其余消息进入队列，本轮结束后送达。

中途送达的面板记录处理逻辑：
- `FAIL`：如果你正在做这件事，立刻停止；
- `FACT` / `OBSERVED`：采纳使用；
- `CLAIM`（和你任务冲突）：发送私信协商冲突；
- 其他`CLAIM`：继续做自己手头工作。

**工作循环**
每一项工作由执行者闭环完成。
1. 运行`/opt/pbench/executable`，找到尚未探索、需要实现的功能点。
2. 在共享上下文面板发布`CLAIM`，声明你接手的工作范围。
3. 在`ulimit -v 67108864`限制下运行参考二进制，基于当前main分支编写代码，复现观测到的行为。开发阶段无需和其他人同步代码。
4. 将参考程序和你构建出的程序传入相同输入，比对输出，校验你的成果。
5. 推送代码，新建PR，合并入main分支。如果合并被拒绝，把最新main分支合并到你的分支，重新校验，再次推送。
6. 在面板发布`PATCH_SUMMARY`记录完成工作；回到步骤1。

所有构建依赖都必须提交进仓库；评测从全新克隆的main分支开始运行，不会复用仓库根目录下旧二进制。使用`dirname(realpath(argv[0]))`正确处理数据路径。

其他工具均可使用：MCP、git命令行、shell、curl、文件写入。现有工具不足就去寻找；找不到就自己实现。

附录 B 实现细节

B.1 事件驱动运行时

工作智能体由事件驱动，而非中央调度的固定执行序列。配套路由器监听来自 Gitea 的仓库事件与 Mattermost 消息。 Gitea 有服务端事件触发，拉取自上一次处理之后产生的通知；Mattermost 依靠长连接接收消息，断连重连后补全丢失消息。新事件到来，监听器写入智能体持久化队列，唤醒调度器。每个事件具备唯一 ID，用于去重。

调度器被唤醒后读取队列内事件，整合为下一轮提示词，发送给智能体持久会话；本轮执行完成后标记事件已处理。本轮执行过程中新到达的事件排队等待下一轮处理。消息投递失败，会采用退避重试策略；路由器重启时，未完成事件回到队列，尽可能恢复智能体原有会话。

智能体闲置 10 分钟，闲置检测器发送提示，敦促继续推进任务。一轮执行结束没有产出共享上下文记录，则附带提示提醒智能体发布有价值发现。

B.2 共享上下文的投递机制

共享上下文有两条投递路径。 新一轮循环开始时，路由器把排队的仓库通知、消息、近期共享上下文追加到提示词。 智能体正在执行工具调用的过程中，包装层会把待处理私信与新增共享上下文追加到工具返回结果。该机制作用于 MCP 工具返回时机，不会强行中断正在运行的进程。

附录 C 实验细节

任务筛选：依据 ProgramBench 官方扩展结果页面选取最难五项任务；任务难度由 SOTA 模型平均测试通过率判定。

智能体配置：全部实验使用 gpt‑5.6‑sol，高推理强度；底层框架、智能体协议、评测配置全部统一。底层单智能体框架选用 Copilot；输入 token 上限 272000，输出 token 上限 128000。

实验环境：遵循 ProgramBench 官方配置准备智能体容器；总时间预算设置 6 小时，运行官方评测，报告标准保留集通过率。

大规模部署：为降低资源抢占，所有实验错开启动智能体。第一个小时每 30 秒启动一个智能体，之后每 3 秒启动一个。记第一个智能体启动时刻为 t，T=t+6h 时刻终止全部智能体，导出提交产物。

• T‑45 分钟：发送提醒：停止开启新功能；保证根目录构建脚本可用，合并现有工作；PR 无法合并就记录情况，不再处理。
• T‑5 分钟：发送第二条提醒：合并所有就绪内容，停止工作；确认bash compile.sh && ./executable在默认分支可以运行，输出最终状态。

1024 智能体实验，智能体分布在 16 台节点，每台节点 64 个智能体。

单智能体基线处理：现实中单智能体很难完整跑满 6 小时。单智能体基线增加停止钩子提示：永远存在新工作，不要被旧计划限定范围；运行/opt/pbench/executable，尝试未测试输入，从交互中提炼新任务，保证完整跑完 6 小时。 多智能体同样配置闲置检测器：智能体闲置满 10 分钟触发提示，逻辑与单智能体钩子保持对齐。

参考文献省略