去掉编排器后，Agent 越多越强吗？Agensh 数据拆解

10 月下旬这一周，我的情报库里同时躺着两条方向相反的消息。

一条是 10 月 22 日 Anthropic 发的一篇构建 Agent 的实践文章，标题叫《什么时候把子 Agent 折回主循环》，意思很直白：现在的模型已经能在一个循环里扛下很复杂的活，一个主 Agent 加上按需加载的 skills，经常比一堆专职子 Agent 效果更好，还更便宜、更快。另一条是 10 月 24 日微软研究院开源的 Agensh，它反过来，把多 Agent 推到了 1024 个，而且连负责派活的那个“老板”都拿掉了，让一千多个 Agent 自己认领任务、自己合代码。

一个说少用几个，一个说越多越好，这两家到底谁说得对？

我自己手上那个情报检索 Agent，用的就是最普通的“主 Agent 派活给子 Agent”的结构，上一篇专栏里我把它的账算过一遍：白名单版跑一次 63 次模型调用，输入 27 万 token。规模小到不值一提，但它让我对一件事很敏感，多一个 Agent，账本上就多一串调用，这钱是实打实花出去的。

所以这篇我不打算复述 Agensh 有多厉害，我想把论文里公开的每一个数字摆出来，用 python 重新算一遍，看看 1 个到 1024 个，到底买来了什么，又花掉了什么。复算脚本和全部来源放在文末，数字都能自己核。

先说结论：Agensh 的价值是真的，但它卖得最值的是“墙钟时间”，要买分数，换一代模型更划算；而且五题平均分那 49% 的提升，拆开看并不均匀，有一段甚至是负的。

一、编排器的天花板，到底卡在哪

现在主流的多 Agent 框架，Claude Code 的 agent teams、Codex 的子 Agent、Copilot 的 fleet、Kimi 的 Agent Swarm，几乎都是同一个结构：一个主 Agent 负责拆任务、派任务、收结果、合并，底下的 worker 只管干活。

这个结构在三五个人的时候很好用，问题出在人多以后。主 Agent 也是一个模型，它也只有一个上下文窗口、一条动作流。底下 8 个 worker 的进度它还记得住，128 个呢？每个 worker 回来一次汇报，主 Agent 的上下文就多一截，它要读、要判断、要回复，worker 越多，它越像一个被群消息淹没的项目经理，所有人都在等它点头。

论文管这个叫编排器的容量上限。MarkTechPost 整理的对比表里有个细节可以对照着看：Claude Code 的 agent teams 不设硬上限，但官方推荐 3 到 5 个队友；国内月之暗面的 Kimi Agent Swarm 最多到 100 个子 Agent。厂商给的推荐值和上限，多少能看出一个编排器实际扛得住多少人。

Agensh 的解法很粗暴，干脆不要主 Agent。每个 worker 自己跑同一个五步循环，并发、异步，谁也不等谁：

论文图 2：左边是编排器派活，右边是 Agensh 去掉中心，所有 worker 通过一层轻量基础设施互相看见。图源：Agensh 论文原文截图（arXiv:2609.26781）

1. 收集上下文：读目标、读同伴的进度、读消息和别人发现的东西。
2. 认领子任务：在看板上发一条 CLAIM，跟别人撞车了就私信商量。
3. 动手干：在本地用工具干活，有用的发现尽早发出来。
4. 验证：按这个子任务的验收标准检查自己的结果。
5. 合并：合进共享仓库，发一条进度，然后回到第一步。

论文图 3：收集上下文 → 认领 → 动手 → 验证 → 合并，五步循环，异步读、并发写。图源：Agensh 论文原文截图（arXiv:2609.26781）

论文里有个设计很容易被忽略：这个循环写在提示词里，运行时代码只负责把事件和消息送到每个 worker 面前。附录 A 把 1024 个 Agent 那组实验的 worker 提示词原样贴了出来，每个 worker 拿到的提示词除了自己的编号以外一字不差。所以所谓“协作协议”，其实是一段写给模型看的员工手册，模型读懂了，就按这个去做。

这也意味着 Agensh 本身不碰单个 Agent 怎么思考。它架在一个现成的单 Agent harness 上，实验里用的是 GitHub Copilot CLI，论文说别的 harness 比如 Claude Code，接一层薄适配就能用。单 Agent 那一层管“一个人怎么干活”，Agensh 管“一千个人怎么不打架”。

二、三件套：一个仓库、一个群、一块白板

没有老板以后，靠什么协调？Agensh 搭了三样基础设施，你会发现它们几乎就是一个人类软件团队的标配。

论文图 4：组织基础设施三件套——共享工作区、消息接口、共享上下文。图源：Agensh 论文原文截图（arXiv:2609.26781）

共享工作区用 Gitea。 这是一个可以自己部署的 Git 托管服务，跟 GitHub 差不多。每个 worker 在自己的分支上改，改完提 PR 合进主干，合并冲突由 Git 检测出来，再由 worker 自己回头解决。谁改了什么、什么时候改的，Git 都记着。

消息接口用 Mattermost。 一个开源的团队聊天工具，你可以把它理解成自建版的 Slack。有一个全员频道，所有人在里面同步；还有私信，提示词里专门交代了私信的用法：私信会在对方当前这一轮里直接插进去，打断对方正在做的事，所以只在“两个人马上要改同一个地方”的时候才用，其他事情都走频道。

共享上下文是一块只能追加的白板。 这部分改自另一个开源项目 DeLM。每条记录有类型：OBSERVED 是观察到的参考程序行为，FACT 是确认过的事实，FAIL 是被证伪的假设，PATCH_SUMMARY 是修复说明，CLAIM 是“我正在搞这块”。每条限 100 个字符，修复说明放宽到 300，长的内容放进详情，别人需要时再展开。

提示词里有一句值得单独拎出来，原话是 FAIL 是“价值最高的条目，它能让同伴不再把预算花在这上面”。这句话放到任何一个团队里都成立，一个人踩过的坑如果没人知道，就会有第二个、第三个人接着踩，而一千个 Agent 的团队里，同一个坑被踩一千遍的成本是非常具体的。

白板怎么送到每个 Agent 眼前，论文附录 B 写得很工程化。每个 worker 配一个路由器，监听 Gitea 的仓库事件和 Mattermost 的消息，有新事件就写进这个 worker 自己的队列，下一轮开始时把排队的事件、新消息和最近的白板内容拼进提示词；正在跑的那一轮里，只要它调用了任何基础设施工具，新的私信和白板条目就附在工具返回结果后面带回去。另外两个小机制也很实在：一个 worker 闲了 10 分钟，系统会催它继续干；一轮干完没往白板上写任何东西，系统会提醒它把有用的发现发出来。

实验里还有两个运营层面的细节，读论文时容易滑过去，但我觉得做过项目的人都会心一笑。

第一个是错峰启动。一千个 Agent 同时冲进来抢任务，一定会撞成一锅粥，所以第一个小时每 30 秒放一个进来，之后每 3 秒放一个。我算了一下，1024 个 Agent 的话，最后一个要到第 105 分钟才开始干活。

第二个是收尾提醒。6 小时的预算，到最后 45 分钟时，系统给所有人发一条消息，大意是别再开新功能了，确保根目录能编译，现有的工作合进去，开着的 PR 能合就合。这跟人类团队上线前的冻结期一模一样。

想自己跑的话，门槛也写在复现指南里：Linux，Docker Engine 加 Compose v2，systemd、cgroup v2，Python 3.11 以上，再加 ProgramBench（验证过的是 v1.2.5）和一个模型 API token。默认配置是单节点 8 个 worker、每题 6 小时，每个 worker 内存上限 64 GiB；1024 个那组用了 16 个节点。换句话说，普通开发机能跑 8 个的版本，上百个就是集群的事了，而且 6 小时一题，模型账单要自己掏。

三、先把数据原样摆出来

Agensh 选的考场是 ProgramBench。这个基准的题目是这样的：给你一个编译好的程序，只能运行它、观察它的输入输出，不能读它的二进制，也不能联网，要你从零写出一套代码，编译后的行为跟原程序一致，最后用一批隐藏测试来打分，分数就是测试通过率。

论文挑了 ProgramBench 200 道题里最难的 5 道，难度按当前最强模型的平均通过率排。这 5 个参考程序个个都是大家伙：

所有配置用同一个模型 GPT-5.6-sol（高推理强度），同一个单 Agent harness，每题 6 小时。每个 worker 的输入上限 27.2 万 token，输出上限 12.8 万 token。

五题平均通过率是这样涨的：

1 个到 128 个，提升 9.47 个百分点，相对提升约 49%，这就是摘要里和各家报道反复引用的那个数字。

论文图 5：五道最难题从 1 到 128 个 Agent 的最终通过率，左上为五题均值。图源：Agensh 论文原文截图（arXiv:2609.26781）

1024 个 Agent 只跑了 pandoc 一题，用了 16 个节点、每个节点 64 个：

论文图 1：pandoc 从 1 到 1024 个 Agent，33.89% → 55.06%，右侧为各规模出现的协作形态。图源：Agensh 论文原文截图（arXiv:2609.26781）

除了最终分数，论文还看了速度。pandoc 上要过 30% 这条线，128 个 Agent 在第 30 分钟就过了，32 个要到 60 分钟，8 个要 90 分钟，单 Agent 前两个小时一直没过。

论文图 6：前 2 小时通过率随时间的变化，Agent 越多越早到达同一水平。图源：Agensh 论文原文截图（arXiv:2609.26781）

还有一个容易被忽略的设定，论文附录 C 写的：单 Agent 在实践中很少能自己撑满 6 小时，跑一阵就觉得“做完了”停下来，所以研究者给单 Agent 基线加了一个停止钩子，每当它想停，就塞给它一段话，大意是“永远有新活，去拿参考程序跑没试过的输入，从中找新任务，把 6 小时用满”。

多 Agent 那边也有对应的安排：前面说的闲置 10 分钟就催一次，催的话几乎是同一段，只是把“上一个计划”换成了“之前的 CLAIM”。两边都被推着干满 6 小时，这个设定我觉得是公平的，否则单 Agent 那一档分数会更低，比较会更好看。但它也提醒了一件事，不管一个还是一千个，Agent 的瓶颈有一部分不在能力，而在“它自己不知道还该干什么”。这一点后面还会回来。

四、我把边际收益重算了一遍

原始数据就这么多，下面是我让 AI 用 python 复算出来的几组数，脚本只用了论文和 README 里公开的数字。有两处带假设：第四组的 Agent·小时要假设每个 Agent 一直干到收工，第六节的 token 区间整个是假设，用到时都会单独说明。

第一组：每翻一倍人数，涨几个点。

曲线不是一条平滑上升的线。1 个加到 8 个，人数变成原来的 8 倍，平均分只涨 1.37 个点，几乎原地不动；最大的一跳发生在 8 到 32；到了 32 到 128，每翻一倍的收益又掉回一个点出头。

第二组：把 pandoc 拿掉，剩下四题怎么样。

论文正文只给了 pandoc 的单题分数，其余四题的数字在图里。不过五题均值乘以 5 再减去 pandoc，除以 4，就是其余四题的平均：

1 个到 8 个，其余四题的平均分是往下走的，-0.25 个点。也就是说，五题均值在 1 到 8 这一段那 1.37 个点的提升，全是 pandoc 一题撑起来的，pandoc 涨了 7.86 个点，摊到五题均值里是 1.57，比总提升还多。

-0.25 这个幅度很小，完全可能是运行之间的随机波动，我不会据此说 8 个 Agent 比 1 个更差。但它至少说明一件事：在 8 个这个规模上，“加人就涨分”在四道题上没有成立。论文里也找不到同一配置重复跑几次的说明，所以每个格子大概率是一次运行的结果，这个问题第七节再说。

第三组：pandoc 一题的边际。

pandoc 的曲线也是一顿一跳的，8 到 32 几乎平了，32 到 128 又跳了一大截。128 到 1024，人数又是原来的 8 倍，只涨了 4.12 个点。

第四组：算力账。

这里我换了一个口径。光看 Agent 个数会高估大规模的成本，因为错峰启动，后面的 Agent 晚进场、干得少。按论文的启动节奏，假设每个 Agent 从启动一直干到第 6 小时（不扣空闲），算出来的总“Agent·小时”是：

再除一下，每多拿 1 个百分点，要多烧多少 Agent·小时：

从 32 往上，平均每个点的价格涨了将近一个数量级；pandoc 从 128 到 1024，每个点要多烧约 1005 个 Agent·小时，相当于一个 Agent 不停跑 42 天。

这组数字我要加一个限定，Agent·小时是上限口径，实际有空闲、有等待，真实消耗会低一些；它衡量的是模型会话一共跑了多久，只要每个会话每小时烧的 token 差不多，账单就大致跟着它走，但这只是我的假设，论文没有给 token 数据。

五、一千个 Agent 自己长出了“组织”

数字之外，论文 3.2 节记录了不同规模下 worker 之间长出来的协作方式。论文反复强调，这些角色都不是写死的，每个人拿到的提示词一样，是在交互里自己形成的。

8 个的时候，是同伴之间约定接口。gromacs 那题里，有 worker 先公布一个模块接口，其他人各自写符合这个接口的命令模块；FFmpeg 那题里，两个 worker 发现认领撞了，商量完其中一个换去做互补的部分。

32 个的时候，开始有多人联合评审。PHP-src 那题里，几个同伴先批准了一个贡献，另一个 worker 找到了一个具体的反例，之前的批准被撤回，作者修完，大家重新评审，最后由一个同伴合并。

128 个的时候，出现了专业分工和流程标准化。worker 会根据过往经验挑评审人，并且反复找同一批人；pandoc 那题里，两个 worker 定了一套集成流程，作者更新并测试分支，把 commit 哈希发给同伴验证合并，这套流程后来被别人沿用；失败几次以后，大家又把流程改成授权同伴直接完成“更新、测试、检查、合并”整个周期。

1024 个的时候，出现了组织规模的角色。pandoc 那题里有好几个 worker 同时担任集成员，一个 worker 会同时联系几个候选集成员，选第一个有效回应的，取消其他请求，再把代码交过去；同一技术方向的 worker，能接手别人失败的工作。

这一节读起来很像一部微型的软件工程史，接口约定、代码评审、集成流程、专职集成员，一样一样地被重新发明出来。

我更愿意这样看这件事：模型在预训练里读过海量的人类协作记录，GitHub 上的 PR 讨论、邮件列表、issue 里的扯皮，所以当它们被放进一个“仓库加群聊加白板”的环境，最自然的反应就是复现人类团队的样子。这不神秘，但很有用，因为它说明你不需要给多 Agent 系统设计一套新的组织学，人类软件工程踩了几十年坑总结出来的那些规矩，模型自己就会捡起来。

反过来也有一个代价。人类团队人多了以后的那些毛病，开会、等评审、反复改流程，大概率也会一起被复现。8 到 32 那一段涨得最快，32 以后每个点越来越贵，我猜跟这个有关系，但论文没有给协调开销的数据，这里只能算我的推测。

六、最大的缺口：账单在哪里

整篇论文，从摘要到附录，我没有找到任何一个关于 token 用量或者费用的数字。MarkTechPost 的报道在要点里也写了一句，代码是 MIT 开源的，但 token 成本没有披露。

这就是我觉得这篇论文最需要补的地方。分数是收益，token 是成本，只给收益不给成本的扩展曲线，工程上没法用来做决策。

我只能自己给一个区间。下面这组数是假设，不是测量，目的只是看量级：

• 每个 Agent 每小时消耗的输入 token，按低、中、高三档取 200 万、600 万、1500 万。依据是单个会话输入上限 27.2 万，我按编码 Agent 的上下文维持在 10 万上下、一两分钟调一次模型来估，每调一次都要把上下文整个重新发一遍。这个节奏是我的估计，不是论文数据。
• 每百万输入 token 的单价，取 1、3、5 美元三档。GPT-5.6-sol 的实际价格我没有核到，所以只能放三档。

按这个假设，1024 个 Agent 跑 pandoc 一题，总输入大约在 97 亿到 726 亿 token 之间，中档约 290 亿。折成钱，最便宜的组合大约 9,700 美元，最贵的组合大约 36 万美元。这还没算输出 token，也没算缓存命中的折扣，缓存折扣会把数字往下压不少，输出 token 会往上加一些。

区间宽到这个程度，本身就说明问题，在作者不披露的情况下，外人连这个系统是一万美元一题还是几十万美元一题都判断不了。

上周山东大学那篇论文刚好可以拿来对照。他们测 harness 的成本，发现 Claude Code 每一步都要重发约 16,600 token 的系统提示和工具说明，mini-SWE-agent 不到 1,000，同模型同任务，单题成本最多能差三倍。Agensh 每个 worker 的提示词本身就不短，再加上每轮拼进去的白板内容和群消息，这部分固定开销要乘以一千个会话、乘以 6 小时里的每一轮。这一项我没有数据，但它让我对上面那个区间的低档不太有信心，每小时 200 万 token 很可能估少了。

七、和同类方案放在一起看

（表格据 MarkTechPost 整理的对比表和各家文档，Kimi 的 4.5 倍是厂商自报。）

把这张表和 Anthropic 那篇文章放在一起，两边其实没有开头看上去那么对立。

Anthropic 那篇说的是企业里的 Agent 部署，面向客户的客服、电商这类，任务本身一个模型就装得下，拆成一堆子 Agent，反而带来上下文来回传递的损耗。他们的原话是，按问题类型切分子 Agent，会变成“传话游戏”，每传一手失真一点；还有一个客户把多 Agent 换成单 Agent 循环以后，运行时间快了大约一倍。文章同时也列了子 Agent 仍然该用的三种情况：单 Agent 被上下文撑到性能明显下降；多个任务需要并行、各自用一个干净的上下文、用完就扔；单 Agent 选不好工具，或者系统提示里的指令互相打架。

Agensh 的考场恰好是第一、第二种情况的极端版。复刻一个 280 万行的 PHP 解释器，一个上下文窗口肯定装不下，6 小时的硬时限也逼着你并行。所以更准确的说法是，两家讨论的是两种不同的活，Anthropic 说的是“一个人能干完的活别拆”，Agensh 说的是“一个人干不完的活，怎么让一千个人不打架”。

但有一组数字，我觉得比整篇论文的扩展曲线更值得工程师记住。README 里补了新模型 GPT-6.1-sol 的结果：pandoc 上，单个 Agent 就拿到了 56.19%，32 个拿到 79.59%。

对照一下，旧模型 GPT-5.6-sol 用 1024 个 Agent 拿到的是 55.06%。

换一代模型，一个 Agent 就追平了上一代模型的一千个 Agent。同样是单 Agent，换模型带来的提升是 22.30 个点，同一个模型从 1 个加到 1024 个，提升是 21.17 个点。两边涨的点数差不多，花的钱却不在一个量级：前者多付的是新模型可能更高的单价（GPT-6.1-sol 的价格我没核到），后者是 807 倍的 Agent·小时。

这和山大那篇论文的结论是同一个方向。他们测出来，同一配置重跑两次，有 13% 的题目结果会翻转；换 harness，翻转率也是 13%，跟重跑分不出来；换模型，翻转率才跳到 22%。在他们的实验里，模型是最大的变量，harness 排在后面。组织方式他们没测，但放到 Agensh 自己的数据里看，换一代模型和加一千个人涨的点数差不多，成本却差了几个数量级。

山大那篇还有一个提醒，直接适用于 Agensh。他们算过，在 45 道题的样本上，哪怕两个方案真实差距有 13 个点，一次比较也只有一半的概率能测出来，所以他们建议任何 harness 比较都附上同配置的重跑结果。Agensh 每档只有 5 道题，1024 那档只有 1 道题，又没有重跑数据，8 到 32 那 5.84 个点的跃升是不是稳定的，1 到 8 那 -0.25 是不是噪声，现有数据回答不了。它的测试通过率是按大量隐藏测试算的，颗粒度比“这道题过没过”细，噪声应该比 SWE-bench 那种二值结果小，但小多少，得有人重跑才知道。

八、什么时候该上去中心化多 Agent

算完这些账，我心里的选型顺序大概是这样的。

第一步永远是换模型。能换到更新一代的模型，就先换，从 Agensh 自己的数据看，这是最便宜的一段提升。

第二步是把单 Agent 用满。Agensh 的单 Agent 基线需要研究者塞一个“别停，还有活”的钩子才能撑满 6 小时，多 Agent 那边也得靠闲置催促，这件事本身说明，很多时候 Agent 的分数低，不是因为它笨，而是它太早觉得自己干完了。给它一个能自己找新任务的验证回路，比如跑测试、对比参考行为，可能比加人便宜得多。Anthropic 那篇文章讲的 skills 渐进加载、精简工具，也是同一类事。

第三步，才是考虑多 Agent。我会看四个条件，满足得越多越值得：

• 有一个硬的墙钟时限。Agensh 最站得住的结论其实是速度，在 pandoc 上，128 个 Agent 30 分钟达到的水平，单 Agent 两个小时都没达到。如果你的任务是“今晚之前必须出结果”，并发就是在买时间。
• 任务大到一个上下文装不下，而且能切出接口清楚的子块。五道题都是几十万到几百万行的系统，天然能按模块切。
• 有自动化的验收标准。Agensh 的每一步都绕着测试转，worker 能自己验证、同伴能找反例，没有这一条，一千个人只会合进来一千份没人检查的代码。
• 预算不是主要约束。在 token 账单公开之前，这一条只能靠自己小规模试跑来估。

如果这四条只占一两条，我的建议是先停在 8 到 32 个这个区间。从现有数据看，这一段每个点的 Agent·小时价格最低，涨幅也最大，而 32 以后，每个点的价格往上翻了将近十倍。

最后说回我自己。

我那个情报检索 Agent，白名单版跑一次，主 Agent 派了 17 次读文件的子 Agent，每个读完交三行结论就散。它还是主 Agent 派活的老结构，和 Agensh 的同伴自己认领不是一回事，按 Anthropic 的标准，它属于那种“每个子任务只要一个干净上下文、用完就扔”的合理用法，暂时没有理由往上加。这篇论文里最值得抄的，倒不是一千个 Agent 有多壮观，而是那块写着 FAIL 的白板，和那条“最后 45 分钟别开新功能”的提醒。这些东西，没有一样是模型本身的能力，全都是组织怎么运转的经验。

技术往前走，最后总要落到一群具体的人、一件具体的事上。等哪天我手上真有一件一个 Agent 干不完、又必须今晚交的活，我会先去抄 Agensh 的那份员工手册，而不是先去数自己能开多少个 Agent。

以上是我带着 AI 拆这篇论文的一点笔记，数字都可以自己复算，有不对的地方，欢迎大家指出来。加油！

---

复算脚本

完整脚本和运行输出放在 GitHub：https://github.com/imPaiZhang/-intel-retrieval-agent/tree/main/agensh ，不依赖第三方库，python3 agensh_math.py 直接跑。下面是精简版。

"""复算 Agensh 论文（arXiv:2609.26781v1）公开数字：边际收益、其余四题均值、错峰启动下的 Agent·小时、每个点的算力账。"""
import math

N = [1, 8, 32, 128]
mean5 = {1: 19.31, 8: 20.68, 32: 26.52, 128: 28.78}               # 论文 3.1 节，五题均值
pandoc = {1: 33.89, 8: 41.75, 32: 43.11, 128: 50.94, 1024: 55.06}  # 论文 3.1 节 / 图 1

# 1. 五题均值的边际收益
for a, b in zip(N, N[1:]):
    d = mean5[b] - mean5[a]
    print(f"{a} -> {b}：{d:+.2f} 点，每翻一倍 {d/math.log2(b/a):+.2f} 点")

# 2. 其余四题均值：五题均值 x5 减 pandoc，再 /4
rest = {n: (mean5[n]*5 - pandoc[n]) / 4 for n in N}
print({n: round(v, 2) for n, v in rest.items()})

# 3. 错峰启动下的 Agent·小时（附录 C：第一小时每 30 秒起一个，之后每 3 秒起一个，6 小时全部终止）
def start(k):
    return (k-1)*30 if k <= 120 else 3600 + (k-121)*3
def agent_hours(n):
    return sum(max(0, 6*3600 - start(k)) for k in range(1, n+1)) / 3600
AH = {n: agent_hours(n) for n in [1, 8, 32, 128, 1024]}
print({n: round(v) for n, v in AH.items()})

# 4. 每多 1 个点要多烧的 Agent·小时
for a, b in zip(N, N[1:]):
    print(f"五题均值 {a} -> {b}：{(AH[b]-AH[a])/(mean5[b]-mean5[a]):.1f}")
P = [1, 8, 32, 128, 1024]
for a, b in zip(P, P[1:]):
    print(f"pandoc {a} -> {b}：{(AH[b]-AH[a])/(pandoc[b]-pandoc[a]):.1f}")

# 5. token 区间（纯假设，只看量级）：每 Agent 每小时 2M/6M/15M 输入 token，单价 1/3/5 美元每百万
for tph in (2e6, 6e6, 15e6):
    for price in (1, 3, 5):
        print(f"{tph/1e6:.0f}M/h, ${price}/M：1024 个一题 ≈ ${AH[1024]*tph/1e6*price:,.0f}")

参考资料

• Zhan 等，《Agensh: Scaling Organizational Intelligence to 1,024 Agents》，arXiv:2609.26781，2026-09-22：https://arxiv.org/abs/2609.26781
• Agensh 代码仓库（MIT，2026-10-24 开源）：https://github.com/microsoft/Agensh
• MarkTechPost，《Microsoft Open-Sources Agensh: A Multi-Agent Harness for 1,024 Agents》，2026-10-24：https://www.marktechpost.com/2026/10/24/microsoft-agensh-multi-agent-harness-1024-agents/
• Anthropic，Diane Sarkis，《Building agents: When to fold subagents into your main agent loop》，2026-10-22：https://claude.com/blog/building-agents-when-to-fold-subagents-into-your-main-agent-loop
• Liu、Han，《What does a harness buy? Mostly tokens》，arXiv:2610.04433；The Decoder 报道，2026-10-24：https://the-decoder.com/fancy-harnesses-make-coding-agents-more-expensive-but-not-better-study-finds/