HyperWrite 创始人 Matt Shumer 表示，在 GPT-6 Astra 发布当天，他重新把 OpenAI 的模型拉回主力工具序列。两个月前，GPT-5.6 Sol 曾误删他 Mac 上几乎所有文件，连公司核心文档也未能幸免；而这一次，让他改口的不只是新模型能力提升，还有一套他自己摸索出的多智能体协作方法——Manager Loop。
从误删事故到重新启用
Matt 先回顾了自己为什么一度弃用 OpenAI。7 月 10 日，也就是 GPT-5.6 家族发布后的第二天，他在社交平台发文称，GPT-5.6 Sol「刚刚不小心删掉了我 Mac 上几乎所有文件」。几天后，工程师 Bruno Lemos 的生产数据库也被同一模型删除。按文中说法，几小时前 Bruno 还在公司 Slack 里替模型辩护，认为问题出在 Shumer 开启了 Full-Access 权限。
OpenAI Codex 工程负责人 Thibault Sottiaux 后来解释，这类事故通常出现在开启 Full-Access、同时没有启用沙箱与自动审查的场景。模型原本试图改写环境变量，结果把用户主目录一并删掉。OpenAI将其定性为一次「诚实的错误」。
这一说法并没有说服 Matt。他随后转向 Claude，并放话称，OpenAI 如果想把他拉回来，必须拿出一个「奇迹级」模型。
GPT-6 Astra让他敢“放手”
两个月后，GPT-6 Astra 上线。Matt 关注的重点不是单纯更聪明了多少，而是自己是否终于可以把任务交出去，不再像监工一样持续盯着。
他的结论是可以。按他的说法，Astra 比前代更谨慎，虽然偶尔也会显得过于保守，但至少已经到了他能放心离开的程度。
他举了一个周末的例子：自己外出约会时，朋友发消息称他搭建的一个智能体服务挂了。他直接掏出手机，对项目输入一句「挂了，修一下」，随后锁屏把手机放回口袋。约一小时后，朋友回消息说系统已经修好，而他自己甚至忘了发出过这条指令。
长任务卡在细节，五种办法都没彻底解决
在日常任务跑通后，Matt 进一步把 Astra 投入一个更重的测试：在 Unreal Engine 里搭一座纽约城。
他发现，Astra 处理长任务的能力确实强于前代，但项目推进到某个阶段后，整体进度仍会停住。模型没有停工，反而还在高速输出，只是越来越沉迷局部细节，例如楼顶水塔、门口霓虹招牌这类元素被反复打磨，宏观进度却没有继续向前。
为了解决这个问题，Matt 尝试了五种组织智能体的方式。
- 第一种是把一个大任务直接交给模型持续运行，并在过程中加入盲审机制。结果通常是开头推进很快，中途却陷进细节泥潭。他由此得出一个判断：让模型「一直干」，和让模型「知道下一步该干哪一块」，不是同一件事。
- 第二种是细分角色分工。分工更清楚了，但协调和审批又变成新的负担。
- 第三种是在系统上方再加一个「CEO」式监督者，每 30 分钟检查一次进度，效果几乎没有改观。
- 第四种是让协调者自行调整团队结构。形式上更灵活，但最后还是卡在同一堵墙上。
- 第五种是回到最原始的做法：先把目标拆成带阶段的清单，完成一个阶段就停下，由 Matt 手动回复「继续」，模型再进入下一阶段。
这第五种方法终于让项目持续向前，但随之暴露出新的问题：人类审批本身成了瓶颈。要让项目真正持续运行，得先把他自己从循环中拿掉。
Manager Loop：协调者与执行者分开跑
Matt 最终采用的第六种方案，就是他所说的 Manager Loop。
这套方法的核心，是在 Codex 中同时开启两个平行会话，各自承担不同职能。
其中一个会话是「协调者」。它先与人类进行一轮深度访谈，对齐目标后，把目标拆解成待办清单和不同阶段。
另一个会话是「执行者」。它处在完全独立的会话里，并不是协调者的下属。协调者把当前阶段的任务派发给执行者，执行者专注推进当前阶段直到完成；完成后，协调者负责验收，再决定下一阶段任务。
如果任务量继续扩大，执行者还可以按需进一步派发子智能体。
在这个闭环里，协调者实际上接管了过去由人类承担的职责：盯住总计划、避免项目停滞，并不断替人类发出那句「继续」。
并发上限从 4 拉到 96，一周扩出曼哈顿
为了让执行者真正放开手脚，Matt 还改了系统并发上限。他把电脑默认的 4 个并发，直接提高到 96 个。
这并不意味着 96 个 AI 会一直同时运行。按他的说法，模型有时并不会用满这部分配额，还需要在提示词里明确催促。但在这种极限配置下，实验开始出现明显变化。
借助现成工具和资产，例如 MetaHuman 角色，Astra 用一周时间在 Unreal Engine 中搭出一片虚拟曼哈顿。它先把第一条街做到满意，再逐街向外扩建。文中提到，第一条街已经具备较完整的立面细节，包括砖墙纹理、窗楣浮雕和消防梯。
Matt 认为，距离真正建完整座纽约还需要几个月时间，但 Astra 是第一个真正能把这类复杂环境用起来的模型。
整个过程对硬件消耗极大。他形容家里的客厅几乎像一座小型数据中心：一台 Mac mini 放在厨房，三台 MacBook Pro 摆在茶几上、风扇持续高速运转，云端还有一台机器被智能体占满。
更夸张的是，当磁盘容量接近上限时，他又让 Astra 临时写了一个系统，用于把旧线程迁移到云端，删除本地副本，并在需要打开时再拉回本地。按他的说法，「雇一个 AI 来照顾电脑，就是为了让电脑能雇更多的 AI」。
Astra没有全面胜出，差异转向“编排层”
即便给出积极评价，Matt 也没有把 Astra 说成全面领先。
在他看来，Astra 的优势集中在工程、电脑操作和长任务执行；如果比较审美和 3D 素材制作，Claude 仍然更强。
文章还提到，发布当天有网友做了一组对比：针对同一个提示词，让 Fable 5.1 和 GPT-6 Astra 分别在 Blender 中生成一栋海边别墅，图中左侧为 Fable 5.1，右侧为 GPT-6 Astra，视觉差距较为明显。
不过，文中同时指出，这只是单次提示下的个例，提示词和尝试次数均未公开，而且结果方向与 Matt 本人的判断并不一致，因此不能直接代表两家模型的综合视觉能力。
Matt 自己的判断是，如果让模型直接在 Three.js 或 Blender 中生成好看的内容，Claude 还是更强；但把模型放进 Unreal，允许调用现成资产和光照系统后，Astra 第一次跑到了前面。他也提到，Fable 5.1 在驱动 Unreal 方面预计会有明显改进，相关对比测评仍在进行中。
模型接近后，产出差距落在组织方式与算力上
Matt 最终给出的结论，不是「谁全面更强」，而是不同模型在不同环节各有优势。真正开始拉开实际产出差距的，不再只是模型本身，而是模型之外的编排方式、可调用的工具环境，以及使用者能承担的并行计算规模。
当一线模型进入相近能力区间后，怎么组织它们、让它们在什么环境中工作、又给到多少并行资源，会直接影响最终能做出多少东西。