我们让编码智能体使用至少100个智能体来更新自身文档，它其实不需要100个。框架依然运作良好。

我们本周开源了编码智能体框架，并希望进行一次既真实又具有压力的测试。因此我们给它一个指令：为本次发布更新文档，并使用至少100个智能体来完成。以下是协调者（GPT-6 Astra）根据该指令构建的方案：一个规划器将我们的24页文档拆分为100个审查任务——每页4个（核对Rust源码的声明、检查发布变更内容、验证示例和参数是否与代码匹配、检查链接和限制说明），外加4项全站范围检查。 所有100个审查员（基于GPT-6 Luna）同时运行，指令是阅读并报告，但不能编辑。25个编辑员（基于GPT-6 Sol）各自负责一个文件，确保彼此操作不冲突。另外还有两个Sol智能体在最后将编辑内容与代码进行比对。 老实说，24页文档不需要100个智能体，十几个就够了。我们想验证框架在如此大规模并行下是否依然稳定——结果证明它确实可以：全部100个智能体都返回了报告，最慢的耗时仅略超两分钟。并行分发耗时4分55秒，智能体累计运行时间为1小时57分钟。从指令发出到代码提交仅用了不到10分钟：涉及29个文件，增加276行，删除90行。 我们发现的问题都是真实的。文档中的SDK错误示例无法编译（它返回了String类型，而工具要求ToolError）。某页声称子智能体深度限制为5，但代码中并无此限制。支持的提供商列表缺少了三个服务商。最终检查发现两个页面关于MCP超时的描述存在矛盾。它还记录了我们的TypeScript REPL工具在最新版Bun上无法正常运行——这确实是个问题，而且在自家文档里读到并不令人愉快。 **成本计算** 我们通过OpenRouter运行此测试，以便清晰查看各模型成本：Astra花费2.94美元，Sol花费2.08美元，全部100个Luna审查员共花费0.73美元，总计约5.75美元。这三种模型也都可通过ChatGPT订阅使用，如果你已有订阅，同样的运行不会产生额外费用。 如果按令牌付费，经济型套餐足以承载负载：100个审查员每个花费不到一分钱。无论哪种方式，成本从设计上就得到控制：每个审查员只处理一页文档、一个视角，最多查看6轮并提交至多4个发现。不会将整个代码库塞入上下文，也不会进行编译。发现结果写入文件，审查员用不到100个词向协调者回复。整个并行分发完成后，Astra的上下文占用仅为1.05M中的75K（7%）。 模型列表是强制执行而非建议性的。你在 `/subagents` 中设定每个层级可使用的模型，任何其他调用都会在启动前被拒绝，因此规划器不会悄悄使用大型模型。工作智能体默认有执行限制（24步或5分钟），卡住的智能体会终止运行而非持续消耗资源。 整个流程在一个6.5MB的Rust二进制文件内作为任务运行，而非一百份命令行副本的拷贝。 如果你运行类似的并行任务，你会如何划分审查员与编辑员的界限？还是让工作智能体直接进行编辑？