⚡️GPT5-Codex-Max:以人格、工具与信任训练智能体——Brian Fioca + Bill Chen,OpenAI
摘要
Codex Max 被定位为兼具长时运行与更高速度的模型:它可以工作“24小时或更久”,在 Codex harness 内通过压缩自行管理上下文,有时还能在同类问题上更快得到正确答案。 Brian 曾让它在本地跨数日运行超过1天,期间笔记本合上、无人操作;“Max”指“速度与最大化,像 maximalist”,并不只是更慢、更审慎的推理。
OpenAI 的产品方向正越来越把性能视为“模型—harness”组合,而不是可以相互替换的裸模型。 Codex 针对终端形态的工具优化,主线 GPT-5 则更广泛、更易操控;Brian 表示 Codex 已开源,其模型也可通过 API 使用。合作伙伴发现,把搜索工具命名为“rg”而非“grep”,工具调用表现会“大幅跃升”。主持人认为,泛化仍是终点,并将 GPT-5 的通用性与 Codex 的编码专注视为两个阶段。
这里的“人格”指的是可靠的工程行为——规划、收集上下文、同步进展和检查工作——因为信任决定了人们愿意把多少任务交给智能体。 GPT-5.1 可以在工具调用前先说明动作,也可以通过提示词关闭闲聊;Codex 则依赖推理摘要器。24小时云端运行中,沟通 token 可能浪费,但它们能帮助工程师跟进、打断,或及早终止错误轨迹。
抽象层正从模型上移到可被其他产品调用的打包智能体,从而减少每次发布新模型都重新调校 harness 的必要。 Zed、GitHub 和 VS Code 都被列为可以调用完整智能体的界面。Codex Max 的上下文管理也支持智能体把工作交给子智能体或并行生成子智能体,不过这种模式仍在形成中。
应用型 evals 是信任、产品迭代和模型训练的操作系统,而不是排行榜旁边的附属品。 OpenAI 希望获取客户特定的失败案例和 evals,并通过轨迹、grader、guardrail 和 metaprompting 改进行为;Bill 的比喻是,一个“API里的博士”仍然需要工作说明、导师指导和绩效评估。Brian 表示,Codex 在 OpenAI 内部的初始采用率约为50%;Bill 说这些用户每天都在使用它。
编码智能体正从编码走向通用电脑自动化,但视觉能力和应用访问仍是瓶颈。 嘉宾将编码智能体描述为“面向终端的 computer-use agent”,它已经可以处理邮件、媒体片段、实验目录和桌面。Bill 点名 Devin 和 Cascade 是需要超越的目标,并表示正在打造一个面向非编码工作、尤其是邮件的 Devin;他们对2026年的期待包括更多 computer use、更广泛的子智能体系统、仅依赖 UI 的集成,以及足够的信任,让普通团队也能获得顶级公司所拥有的能力。
精读
1. Codex Max 将长时运行与速度结合起来
Brian 解释“Max”时说,Pro 可能暗示更慢、更深思熟虑的工作,而 Max 表示“速度与最大化,像 maximalist”。它可以运行“24小时或更久”,但面对同样的问题,也可能更快得到正确答案。
他见过最强的续航案例发生在本地:一次运行跨越数日、持续超过24小时,期间笔记本合上、无人操作。在 Codex harness 内,Max 会压缩并管理自己的上下文,使其可以“基本无限运行”,无需人工管理上下文窗口。
2. 信任被训练成行为,工具则暴露模型习惯
Brian 表示,GPT-5 训练期间他与训练团队关系密切。他对可信赖结对程序员的“人格”定义非常具体:说明正在做什么,在适当时规划,深入执行前先收集上下文,并检查自己的工作。这些“优秀的软件工程实践”被转化成可度量的行为特征。
主持人追问:如果是一个持续24小时、无人值守的“cron job”,人格是否还重要?Bill 的回答是,工程师目前仍希望看到进度更新,以便插话或停止智能体,至少也能避免让它在最终必须丢弃的 rollout 上浪费时间。
对 GPT-5.1,OpenAI 会使用“我准备去找这个”的前置说明,用户可以引导或关闭这类表达。Bill 说,他会给自己的个人智能体设定有趣的“buddy”人格,但也承认,这些闲聊会在长时间云端任务中消耗不必要的 token;Codex 则依赖推理摘要器同步进展。
Bill 对 harness 依赖最尖锐的例子是:Codex 围绕终端工具训练,但合作伙伴通过匹配终端式的名称以及输入输出形态,仍能保留其他工具。名为“rg”的搜索工具表现优于名为“grep”的工具,因为“Codex loves ripgrep”。主持人认为模型应该具备泛化能力,并称其为最终目标;他同时把通用 GPT-5 与专注编码的 Codex 视为两个阶段。
3. 产品边界正从模型转向智能体
Brian 描述道,“抽象层确实正在向上移动”,逐渐来到智能体层。开发者不必围绕每次模型和 API 发布重建系统,而可以嵌入一个打包好的 Codex 智能体,其模型、工具、沙箱和 harness 已被协同设计。Brian 还表示,Codex 已开源,其模型也可通过 API 使用。
Bill 点名 Zed、GitHub 和 VS Code 正在采用这种模式。编码工具开发者可以在打包智能体之上构建一层,避免每次模型或 API、harness、沙箱以及工具发生变化时,都维护一套相应团队。
Codex Max 的上下文管理也支持智能体调用智能体:它可以把上下文交给子智能体,生成并行任务,并在长时工作流中创建新的抽象。两位嘉宾都强调,这些基础能力才刚刚开始搭建,最终的运行模式仍未确定。
4. Evals 将自主性变成可检查的生产系统
信任方面的主张已经是行为层面的事实,而非假设。Bill 表示,自己几个月来没有亲手写过一行代码,还发布了一个开源 Codex 升级包,用于将 Completions 迁移至 Responses,代码全程无需手写。Brian 说,OpenAI 内部最初约有50%的人开始使用 Codex;Bill 表示,他们每天都在用。
Bill 认为,学术基准在“人们最关心的事情”周围留下了空白。应用型 evals 捕捉客户使用场景中那些会阻断部署的单项缺陷,让 OpenAI 可以通过模型和产品迭代,围绕这些具体不足“共同持续爬坡”。
Bill 的比喻是,把模型称为“API里的博士”并不完整,因为新员工仍然需要工作说明——也就是 prompt——以及导师指导、guardrail 和绩效评估。Agent trace、rollout trace、grader 和生产检查,使团队能够识别某种行为,让智能体改进自己的指令,再测试下一次运行。
多轮评估仍未形成定论。Bill 建议评估完整轨迹,回退到薄弱步骤,再用改进后的指令重新运行;他提出的“job interview eval”会奖励智能体在实施前澄清定义不清的任务。主持人提出的具体需求是批量多轮 evals:数千个不受时间约束的运行应尽可能低成本地在夜间执行;讨论显示,这项能力目前还不可用。
5. 编码智能体正在成为终端原生的电脑用户
被问到希望超越谁时,Bill 点名 Devin 和 Cascade,并表示自己正在打造一个面向非编码工作的 Devin,尤其聚焦邮件。Brian 称 Slack 是工作的“终极用户界面”;Bill 说,他通过 Slack 与自己的邮件智能体交互。
两位嘉宾更广泛的判断是,编码工具正在演变成个人自动化工具。Codex 可以借助终端工具整理邮件、生成视频片段、组织实验目录,或清理桌面。Bill 将其与自己在1990年代做系统管理时的经历联系起来:当时 Bash 脚本和定制软件已经能解决写代码之外的现实任务。
Bill 将编码智能体称为“面向终端的 computer-use agent”,但表示它们还没有足够强的原生视觉能力。许多遗留应用或封闭应用只提供 UI,而不是 API 或 MCP;要访问用户自己拥有的数据,computer use 因此非常重要。
他们对2026年的期待包括更多 computer use、可扩展的子智能体,以及能够处理更广泛工作的编码智能体。Brian 特别希望 Codex 能以新方式使用电脑,并变得更值得信任,让小型开发商和其他团队也能获得顶级公司所拥有的能力。