作者 ｜ 木子

OpenAI 和 Anthropic，这回真是贴脸对打。

Claude Opus 4.6 发布还不到半小时，GPT-5.3-Codex 直接上线，没有铺垫，没有预热。

这不是小修小补，而是 OpenAI 目前最强的 Agent 化编程模型。

对此，网友又搬出了一张经典的图：

有意思的是，OpenAI 自己承认：Codex 团队在开发 GPT-5.3 的过程中，使用早期版本，来调试自己的训练、管理自己部署、诊断测试结果和评估——简而言之，就是 AI 自己参与开发了自己。

如果说过去的 Codex 更像一个高效的编码助手，那 GPT-5.3-Codex，可谓“能在电脑上完成几乎全部专业工作”的通用 Agent。

有多通用？——它不只是写代码，还能长期运行任务、调用工具、操作终端、管理部署流程；也就是说，从研发到上线，几乎整条链路都能自己接住。

用 OpenAI 联创兼总裁 Greg Brockman 的话来说，就是 软件开发正在经历一次复兴，而 Agent 成为了“第一入口”。

他们定了一个挺激进的目标：对任何技术任务，人类第一反应应该是“和 Agent 交互”，而不是打开编辑器或终端。

1夺多项 SOTA，网友实测长联路稳定性超过 Opus 4.5

那么，GPT-5.3-Codex 到底好用吗，有多好用？

先拿最直观的 Benchmark 跑分说话。

最明显变化，是它 在终端环境的实际执行能力变强了。在 Terminal-Bench 2.0 上，GPT-5.3-Codex 拿到 77.3%，相比 GPT-5.2-Codex 直接抬高了将近 13 个百分点。

Terminal-Bench 2.0 测的不是“会不会写代码”，而是专门衡量 Agent 能否真的在终端环境完成真实工程任务：敲命令、调工具、多步骤执行、出错再修。

换句话说，这个指标考的是工程现场表现，而不是像 SWE-Bench 那样的单纯刷题表现。

有意思的是，Claude Opus 4.6 也跑了 Terminal-Bench 2.0，成绩是 65.4%，GPT-5.3-Codex 的得分比它高出了 12%。

除此之外，GPT-5.3-Codex 的提升主要还有：

• 计算机操作能力，翻倍级提升。它在 OSWorld 得分 64.7%，而上一代 GPT-5.2-Codex 得分才 38.2%。

• 大家现在很关心的 网络安全能力，它在 Cybersecurity CTF 得分 77.6%，比上一代 GPT-5.2-Codex 提升了约 10%。

• 输出准确率上，GPT-5.3-Codex 对于不同输出 token 数量，准确率始终高于 GPT-5.2-Codex 和 GPT-5.2

有网友问 GPT-5.3-Codex 和 Claude Code 谁更好用，Gork 是这样的回答的（Doge）：

一位叫 Matt Shumer 的小哥（下文简称 Matt 哥）也迅速亲测了一把 GPT-5.3-Codex，他也是 Github for prompts 的创建者。

Matt 哥看起来对测评结果还挺满意的，他甚至还给这篇 Blog 起了个霸气的标题：《完全自主时代已到来》。

他在 Blog 中兴奋地写到：这是他第一次敢把任务丢给模型，然后他真的走开几个小时（甚至 8+ 小时），模型都不会中途崩溃、漂移或降智。

Matt 哥指出，GPT-5.3-Codex 不只是写代码，它还会自己补全模糊信息、自己做架构判断、自己修 Bug、自己部署、自己看日志，然后一直改到测试全绿。只要给它清晰的验证标准，它可以连续跑几个小时都不跑偏。

而让他最欣喜的，不是模型“更聪明”，而是判断力：当指令有歧义时，这个 AI 模型选的路径，往往就是他本人也会选的那条，而不是那种看起来最快、但后患无穷的“捷径”。

你只要把 pass/fail 讲清楚，它就能一直迭代、一直修，直到测试全绿才停。另外，你告诉它怎么判定对错，讲得越明确，它就越能自己闭环，不需要人在中途不停纠偏。

而且它是真能把闭环跑完整：改代码、push、部署、打开线上链接、tail 日志——哪里出错就继续修到能用为止。

Matt 哥举了个例子，他给了 Railway CLI 这类部署工具的权限，让模型自己把“上线”这一步做完，然后用线上反馈继续修，直到真的可用。

除此之外，GPT-5.3-Codex 还挺会利用等待时间：命令在跑着，它就去补文档、补上下文、顺手修点边角问题，但又不会乱改一堆你没让它碰的东西。

也就是说，这个模型解决了跟多人在用 Agent 去 Vibe Coding 时的 “心腹大患”：它非常“懂分寸”，会做有帮助的事，但不越界、不乱改。

Matt 哥指出，关于长链路任务稳定性，GPT-5.3-Codex 的表现明显好于 Opus 4.5。虽然它比 Opus 4.5 慢，但也更稳。

另外，多 Agent 也终于不再像聊天表演了：Matt 哥认为，GPT-5.3-Codex 真的能把任务切成几个并行工作流，每个 Agent 各盯一块，整体推进更快、也更不容易漏东西。

不过，GPT-5.3-Codex 的缺点，或者说为了“稳”而付出的代价，也很明显：它真的慢。而且过程播报偶尔会断掉、更不适合拿来设计 prompt/agent 架构。

但如果你要的是“别出错、别跑偏、别让我盯着”，那终于像那么回事了。更确切地说：它不一定是“最好玩”的那种模型，但在“复杂、长时间、约束多、最好一次做对”的活上，它能让使用者足够安心。

2OpenAI 总裁：Agent 正重构软件开发

前文提到，OpenAI 联合创始人兼总裁 Greg Brockman 发了一条帖子，说软件开发正在经历一次“复兴”，而 Agent 正在变成工程师的“第一入口”。

在他看来，像 GPT-5.3-Codex 这样的模型，已经强到可以在长时间、复杂约束下，独立把一整条工程链路跑完：从写代码到调试、部署，再到持续迭代。

当模型能力已经到这个程度，问题就不再只是“要不要用”，而是公司是否准备好把流程、代码结构甚至团队协作方式一起改掉。

这条帖子更像是一份内部转型说明书，里面讲的不只是模型变强了，而是当默认入口变成 Agent 之后，工程组织该怎么自处。完整内容如下：

软件开发正在我们眼前经历一次复兴。

如果你最近还没有用这些工具，你很可能低估了自己错过了什么。自去年 12 月以来，像 Codex 这样的工具能力出现了阶跃式提升。

昨天有几位 OpenAI 的优秀工程师告诉我，自 12 月以来，他们的工作方式已经发生了根本变化。此前，他们只能用 Codex 写单元测试；而现在，它几乎写了全部代码，还承担了大量运维和调试工作。并不是每个人都完成了这种转变，但通常阻碍他们的并不是模型能力本身。

现在，每家公司都面临同样的机会。而要驾驭它，就像当年面对云计算或互联网一样，需要认真思考。这篇文章分享了 OpenAI 当前如何将团队重构为“Agent 化软件开发”的实践。我们仍在学习和迭代，但这是我们目前的思路：

第一步，我们希望在 3 月 31 日前做到：

1）对于任何技术任务，人类的第一选择工具是与 Agent 交互，而不是打开编辑器或终端。

2）人类默认使用 Agent 的方式必须经过明确的安全评估，同时足够高效，使大多数工作流程无需额外审批。

为了实现这一目标，我们几周前向团队提出了以下建议：

1、花时间真正去尝试这些工具。很多人已经在 Codex 5.2 上有了惊艳体验，但也有不少人因为忙碌还没尝试，或者陷入“它真的能做 X 吗”的怀疑，而不是直接试一试。

• 为团队指定一名“Agent 负责人”，专门思考如何把 Agent 融入团队工作流。

• 在内部渠道分享经验和问题。

• 举办一次公司范围内的 Codex Hackathon。

2、创建 skills 和 AGENTS.md 文件。

• 为每个项目维护一个 AGENTS.md，当 Agent 出错或卡住时及时更新。

• 把你让 Codex 执行的能力抽象为 skills，并提交到共享仓库。

3、盘点并开放内部工具。

• 列出团队依赖的工具，并确保有人负责将其改造成 Agent 可访问（例如提供 CLI 或 MCP Server 接口）。

4、让代码库结构“Agent 优先”。

• 写运行快速的测试。

• 构建高质量的组件接口。

5、拒绝“垃圾代码”。

• 大规模管理 AI 生成代码是一个新问题，需要新的流程与规范。

• 确保每一段合并代码都有明确的人工负责人。

• 审查标准至少与人类写的代码一样严格。

6、建设基础设施。

• 不仅要记录最终提交的代码，还要记录 Agent 的执行轨迹。

• 建立可观测性系统与统一工具管理机制。

参考链接：

https://openai.com/index/introducing-gpt-5-3-codex/

https://shumer.dev/gpt53-codex-review

声明：本文为 AI 前线整理，不代表平台观点，未经许可禁止转载。