Theo 谈 Codex Ultra：推理强度、子代理与用量

GPT-5.6 推出时，Codex 还在推理强度选项旁展示了 Max 和 Ultra。我觉得 Ultra 容易令人困惑：在我测试的版本中，它不只是提高模型的推理强度，还会鼓励多代理工作流，从而影响用量和可控性。

我的批评反映的是 2026 年 7 月的实现和个人体验。界面、默认设置、模型路由和订阅限额都会变化，因此这里的细节不应被当成操作说明，也不能代表之后所有版本。

CLI 把 Ultra 放在从 low 到 max 的推理菜单中。我录制时观察到桌面界面发生变化：Ultra 从主滑块移到了高级强度菜单。我担心这种呈现方式掩盖了更多推理和更多委派工作之间的区别。

作为比较，我展示的 Claude Code 界面把 Ultra Code 标为 extra-high 强度加工作流。选择它会启用工作流行为，而不只是选择更高的推理级别。我认为两个产品都应该清楚地表达这一区别。

我把 Ultra 描述为一种增加指令、鼓励使用子代理的模式。模型仍需要推理设置，编排也取决于运行框架。我的解释基于所检查的版本和实现，并不是对未来行为的承诺。

在我的比较中，Claude Code 的 Ultra Code 选择 extra-high 强度并启用工作流，而 Codex 的 Ultra 配置使用最大推理强度。高强度主代理与多个高强度助手结合，可能成倍增加用量，尤其是代理继续派生工作时。

我引用了一些基准观察：max 使用两倍以上的 token，分数提升相对较小。这只是特定测试中的取舍，不是普遍比例；额外推理的价值取决于任务、设置和失败代价。

在我测试的配置中，通过当时可用的子代理接口，我无法轻松为子代理设置较低推理强度。我希望有独立控制，让主代理可以委派成本较低的工作，而不必让每个助手都继承最昂贵的设置。

一次 fast 模式下的 Ultra 运行约 20 分钟就耗尽了我的五小时额度；手动重置后，我又在约 40 分钟内触及限额。我还提高过代理并发上限。这是我的特定经历，并不能预测其他账户的消耗。

我担心临时调整短时间窗口限额，可能使用户更容易迅速耗尽每周额度。套餐限额和保护措施因情况而异，也会变化；评估运行时应查看当前用量和设置，而不是依赖这些历史数字。

为了理解行为，我让模型检查了 Codex 的两种子代理实现，称为 V1 和 V2。V1 类似调度者给临时助手派活；V2 把具名代理组织成一棵支持消息传递的树。展示的页面是模型生成的分析，应对照相关源码版本核实。

在一个简单例子中，主代理可以把三个 pull request 的审查分别交给三个助手，等待结果后汇总。每个助手有自己的上下文和明确任务。这样的分工可能很有价值，不必让每项任务都变成庞大的代理层级。

视频所述的 V2 设计增加了具名任务路径、嵌套代理和消息传递。Theo 说它当时仍在开发中，他测试的模型通过配置路由到了该实现。这些是对当时版本的观察，不是当前产品文档。

我最担心的是上下文共享默认值。分析称，默认会共享符合条件的主对话历史，也可以选择较少上下文。更多历史可能帮助助手理解任务，却也可能增加输入用量，并把无关假设带入工作。

我猜测这个默认值可能与缓存有关，但并不确定所有提示词差异如何影响缓存命中。实际要点是测量真实用量：共享上下文、缓存行为、代理数量和模型强度都会影响成本。

消息机制允许代理发送说明，或向已有助手分配后续任务。结果会交给直接上级；等待也可能因邮箱事件唤醒，而不意味着所有工作都已完成。这让协调更灵活，但我在实际使用中觉得更嘈杂。

报告描述了不受旧深度限制的嵌套子代理，而当时版本默认同时活跃四个代理，包括根代理。我曾修改并发设置，这也是用量很高的原因之一。并发限制和深度限制控制的是不同问题。

我在早期测试中没有广泛使用 V2，因此当时无法建立可靠的质量比较。之后我看到运行更久、更嘈杂、消耗更多 token，但结果没有好到让我觉得这些开销值得。这是主观评价，而不是受控基准。

如果你觉得必须立刻掌握每个新设置，我的建议是放慢一点。默认设置可能已经有用，实现也会快速变化；你不必复制我复杂的配置才能从工具中获益。

我更希望推理强度和编排明确分开，并能更好地配置助手。我更喜欢自己在 Claude Code 使用的工作流方式：模型可以编写程序，定义阶段、提示词和预期输出。

在示例中，工作流定义了元数据、输出 schema 和审查阶段。它并行启动不同模型的审查者，等待结构化结果，再把结果交给汇总阶段。这个结构是明确的，可以作为代码检查。

更大的例子包含研究、验证、汇总、批评和定稿阶段。代码可以过滤缺失回复，或决定是否需要再次审查。这样，工作流可以根据实际输出路由结果，而不只是依靠反复的对话式工具调用。

我把工作流看作固定预定义助手角色和完全临时委派之间的折中：模型可以针对任务生成角色和流程，再由程序处理执行顺序。生成的工作流仍需要审查、限制和适当权限。

有边界的阶段序列可以让停止条件比开放式代理对话更清楚，但它并不自动保证结束：循环、重试或大量并发任务仍可能消耗大量时间和资源。关键在于明确设置这些限制。

我认为界面借鉴了竞品体验中容易误导的部分，却没有体现我重视的工作流实现。我更喜欢在模型选择器旁提供独立、标注清楚的编排开关，而不是把所有东西放在一条强度刻度上。

最后我展示了 Maria 将两者分开的界面原型，并建议谨慎使用我测试的 Ultra 版本。这是 2026 年 7 月的评价；用户决定启用什么功能时，应查看当前界面、文档和限额。