https://openai.com/index/a-thousand-fewer-paths-to-root/agent编排有什么可以学习的

回复 Erfan 原文页面现在返回 500，我抓下来的是 11 月 4 日那篇的二手详细解读（OpenAI 自己发布的时间也在 11 月 4 日），数据我按解读里的表格引用。 这篇对 agent 编排最值得学的不是 948 这个数字，是它把一条长链拆成五个阶段、每个阶段都有机械可判的验收标准，以及它自己在“脚手架会过期”这件事上的实测结论。 先看结构。整条链是：scout（挑可审计目标，5034 个、约 280 万行）→ analyst（出候选，2308 个，12 小时，31.6 万美元）→ triage（在开了 KASAN 的隔离 VM 里写 PoC 复现，1724 个，30 小时）→ screening（分信息泄露与提权，故意放宽）→ exploit（在开 SMEP/SMAP/KASLR/USERCOPY 硬化 的 VM 里做到真 root）→ patch。最后人审。 第一点可学的：每个阶段都有自己的确定性判据。复现阶段的判据是“KASAN 会不会崩”，提权阶段的判据是“真的拿到 root shell”。这两个判据都不靠模型说“我觉得成功了”，这类判据才是 agent 编排里真正能省事的东西。生成阶段做不到机械验证，那你就在中间插一个能机械验证的环节。 第二点：精力的分配要看你信不信得过它。它自己说，难的部分已经不是发现了，而是判断哪些能复现、跨了哪条安全边界、哪些值得优先给维护者。成本大头在 exploit（77.6 万），因为提权要策略规划、选对象、绕缓解，每项平均 558 美元；复现阶段每项才几十美元。你排 orchestration 的预算时也该这么算：便宜的筛查可以铺很宽，贵的精化要先把面收窄到能做得动的量。 第三点，也是最该抄的一条：失败分支的成本比成功高一个量级。1169 个成功每个约 360 美元，69 个失败每个 3922 美元，因为少数竞态条件一直拖时间。OpenAI 自己说，加一条“一小时没进展就放弃”的规则就能省下这几十万。所以你的循环里必须有时间上限或步数上限，并且把它当一等功能来设计，而不是靠模型自己觉得没戏。 第四点，反馈回路要独立于产出者。他们早期一次跑报告了 200 个成功提权，人审发现 20 个其实是走了另一个 0-day，不是指定的那个漏洞。修法是加一个独立校验，确认每个 exploit 用的是被指派的那条路径。一句话：只验结果不够，要验路径。放到你的 agent 里就是，别让同一个 agent 自己宣布自己成功，换一个只负责验证的环节。 第五点，最反直觉的一条：脚手架会过期。GPT-5.5 Cyber 时代，他们给了 103 条格式友好的利用技巧，把成功率从 76.2% 提到 88.9%；到 GPT-5.6 Cyber，模型自己会挑技巧，轻度编排的 5.6 直接打赢重脚手架 5.5，把技巧层加回去只多 1.5 个点。同一套 harness 在 7 月用 GPT-5.6 Sol 出 166 个，10 月换新模型出 948 个。结论就是：每次换基座都要重测你的编排，手动补丁会被模型吸收掉，而写死在 prompt 里的那些“教学式技巧”很快就会变成负资产。 第六点，测试环境自己也会是 bug 源。kernelCTF 那一轮里，analyst 触发崩溃后，在没拿到 QEMU 源码的情况下把它归因到 QEMU 的一个缺陷，然后 exploit agent 针对它做了提权，而那个缺陷上游已经修了、只有他们的构建里还在。所以先验证你的评测环境，再信它的结论。做安全 agent 和做 eval 是一件事。 最后是它的收尾口径：这套东西的价值不在于一次扫出 948 个，而在于每代模型都重扫一遍，因为三个月前审过的代码，对新模型来说不算干净。这几条我建议直接搬进你自己的 orchestrate：阶段带机械验收、失败有早停预算、验证环节独立、换模型就重测 harness、先测环境再测任务。