多 Agent 忙了六小时，最后交付了什么？

大家都说完成了，用户拿到的是哪一份？#

设想让一组 Agent 在下午交出一个可以演示的软件。有的负责功能，有的修错误，有的补测试。临近截止时，聊天记录里不断出现“已完成”，共享代码却还在变化。

这是假设场景，不是本文的项目实测。它提出的问题很具体：验收时看哪一个版本？还在某个 Agent 工作区里的改动算不算？测试通过的是刚合并的代码，还是十分钟前的旧版本？

我认为，多 Agent 产品需要先定义一份可打开、可检查、版本明确的最终成果，再讨论增加多少执行者。否则，系统显示的忙碌程度很容易超过用户实际拿到的进展。

Agensh 新开放了什么，实验说明了什么？#

微软官方仓库在 2026 年 10 月 24 日宣布开放 Agensh 的协作框架、实验脚本和复现指南。论文已于 9 月 22 日发布，这次的新进展是代码开放，不是新论文。

它让 Agent 自己认领子任务、交流发现，并把修改合入共享代码。原实验用 GPT-5.6-sol 的 high 推理档位，在不能联网、限时六小时的条件下，重建 ProgramBench 中五个最难任务的参考程序。五项任务的平均最终测试通过率，从单 Agent 的 19.31% 上升到 128 个 Agent 的 28.78%。

这是提高了 9.47 个百分点，不是多了 49 个百分点，也不是完整项目交付率。它说明这组实验中更多执行者带来了更高的最终测试通过比例，却没有证明相同费用下更划算，更不能代表任意业务都适合并行。本文未运行该框架。

对产品团队来说，比照搬实验规模更重要的问题是：这些分散的工作，最后怎样成为同一份可以验收的结果？

共享记录有用，但不能把记录当成验证#

Agensh 的共享上下文服务保存任务认领和可复用发现，帮助其他 Agent 了解进度。这里有一个值得注意的边界：服务会检查提交的文本，但不会替 Agent 执行它声称运行过的验证命令。

这不等于实验没有测试，而是说明“交流进度”和“检查成果”是不同环节。

我的产品建议是，界面可以显示“某个 Agent 报告已经完成”，但只有具体产物通过约定检查，才能进入可交付状态。检查结果还要指向被检查的版本。代码又变了，旧结果就不能不加说明地继续显示为绿色。

比如，负责导出的 Agent 说文件可以下载，负责权限的 Agent 随后改了访问规则。两个局部结论都可能真实，却不能保证合并后的下载流程仍然能用。最终检查应该打开那份合并结果，再走一次用户真正要完成的路径。

截止时，先固定一份结果#

复现指南记录了一个很实际的比较限制：团队运行会先导出已提交的代码版本，再停止各执行者；单 Agent 基线在停止过程中还会保存剩余改动，最终结果可能包含取消时产生的工作。两种结束流程并不完全相同。

因此，“都跑了六小时”仍不足以保证比较条件完全一致。这里不是据此否定实验，而是提醒复现者记录最终产物的形成方式。

如果我设计类似产品，会在到达截止时间时保存一份候选结果，之后的检查只针对它。尚未合并的工作单独列为未完成，不能混进交付统计。若检查失败，保留失败原因与原版本；需要继续修改时，就形成下一份候选结果，而不是悄悄替换正在被验收的内容。

这会让进度看起来保守一些，却能回答用户最关心的问题：现在到底有什么可以用，剩下什么还不可靠？

比较团队规模时，别只统一时钟#

我会用范围相近的任务，固定模型、工具、输入材料和验收要求，分别记录三类结果：

• 可用程度： 最终固定版本通过了哪些检查，哪些关键流程仍失败。不要把通过的小测试数量直接当成业务完成率。
• 时间： 从开始到拿到可用结果花多久，等待合并、检查与返工分别用了多久。没有合格结果的任务也保留，不能只统计成功样本。
• 总投入： 模型调用、运行环境、重试和人工复核花了多少。相同截止时间的两组任务，费用可能不同。

这些是本文提出的验证方法，并非原实验已公开验证的业务收益。

如果增加 Agent 后，各自的进度更快，但最终版本没有改善，就应先查重复工作、合并等待或检查瓶颈。如果质量提高了、成本也明显上涨，则需要回到用户需求：任务是否值得为截止时间或更高完成度付费？不能只用一个平均分替团队做决定。

开放代码，也不等于可以照着历史分数验收#

复现指南还明确指出，公开版本的工具和参考运行环境有更新，部分内容与历史实验不同；新运行应该记录自己的版本，不能声称精确复现历史结果。指南也提醒，评测程序正常退出，仍可能存在不完整的评测分支，需要检查结果文件。

这对产品落地同样重要：脚本结束、Agent 停止、界面显示完成，都只是过程信号。用户真正需要的是一份边界清楚、可以继续使用的成果。

Agensh 的新代码值得研究，但我的起点不会是“最多能开多少个”。我会先问：最后那一份成果在哪里，检查对应哪个版本，失败的部分有没有如实留下？

来源与边界#

• 主要一手来源： 微软 Agensh 官方仓库，公告标注 2026 年 10 月 24 日开放代码；作者列表包括 Zhihao Zhan、Ting Song、Li Dong 等。原论文日期为 9 月 22 日，公告未给出发布时刻和时区。
• 实验对象与设置： 五个最难 ProgramBench 程序重建任务、GPT-5.6-sol high、六小时、不能联网；单 Agent 与 128 个 Agent 的平均最终测试通过率见上文。没有据此计算商业成本或延迟收益，也没有把不同模型的结果混排。
• 实现与复现证据： 共享上下文说明用于区分进度文本和实际验证；复现指南披露截止导出、评测异常与版本差异。
• 原文限制： 同一墙钟时间不等于相同总资源预算；发布版与历史实验存在差异，结束和导出流程也需记录。本文没有获得可直接推算业务收益的统一成本对照，未复现实验。
• 本文判断： 固定候选版本、区分未合并工作、按可用程度与总投入决定团队规模，是产品设计建议，不是已测得的效果，也不替代实际业务的权限与发布审核。