GPT-5.3 Codex：从编码助手到通用工作代理

测试 GPT 5.3 Codex：上手示例

发布说明和首批基准结果清楚表明，代理式工作流在新模型开发中优先级最高。因此，我们的示例也将重点围绕这一领域。

如果您想看 GPT 当前的推理能力在实战中的测试，建议查看我们关于 GPT-5.2 的指南。

测试 1：全栈构建者

在第一个测试中，我想检查模型在依赖管理和文档方面的处理水平。任务是用 FastAPI 和 Open-Meteo API 构建一个简单的天气工具。我使用了以下提示：

Create a simple Python API using FastAPI that fetches the current temperature for a given city (e.g., Helsinki) using the Open-Meteo API.
1. Write the code in main.py using the httpx or requests library to call the API.
2. Create a Dockerfile to containerize it.
3. Write a README.md explaining how to run it.
4. Create a bash script run_local.sh that builds the image and runs it on port 8000.技术支持

41 秒内，四个文件一次性生成，端口号（8000）和命名保持一致。

在依赖方面，Codex 正确识别了 httpx 是现代的异步客户端（对于 FastAPI 是优于 requests 的选择），并在 Dockerfile 的安装行中包含它。它也意识到 FastAPI 依赖 uvicorn，并将其加入了依赖列表。

一个小小的不足是 Dockerfile 中的硬编码安装：Codex 实际上跳过了 requirements.txt，而是在 RUN 指令中直接安装。对于“简单”脚本而言，这或许是合理的捷径，尤其是我们并未要求提供 requirements.txt，但单独文件会让后续更清晰、更灵活。Dockerfile 如下：

FROM python:3.11-slim
WORKDIR /app
COPY main.py /app/main.py
RUN pip install --no-cache-dir fastapi uvicorn httpx
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]技术支持

Codex 不只是写了代码，还清楚理解了请求的上下文和 API 架构。注意它如何自动处理 Open-Meteo 的两步流程（地理编码 -> 天气）。我并没有告诉它如何 使用该 API，只是指定了要用它。它查阅了文档（或早已了解），并实现了必要逻辑，让 ?city=Helsinki 能正常工作。

它还主动加入了健壮的错误处理（try/except、针对特定状态的 raise、“未找到城市”的 404 检查），尽管我没有要求。

from fastapi import FastAPI, HTTPException, Query
import httpx

app = FastAPI(title="Simple Weather API", version="1.0.0")

GEOCODE_URL = "https://geocoding-api.open-meteo.com/v1/search"
FORECAST_URL = "https://api.open-meteo.com/v1/forecast"

@app.get("/health")
def health() -> dict:
   return {"status": "ok"}

@app.get("/temperature")
def temperature(city: str = Query(..., min_length=1)) -> dict:
   city = city.strip()
   if not city:
       raise HTTPException(status_code=400, detail="City must not be empty")

   try:
       with httpx.Client(timeout=10.0) as client:
           geo_resp = client.get(
               GEOCODE_URL,
               params={
                   "name": city,
                   "count": 1,
                   "language": "en",
                   "format": "json",
               },
           )
           geo_resp.raise_for_status()
           geo_data = geo_resp.json()

           results = geo_data.get("results") or []
           if not results:
               raise HTTPException(status_code=404, detail="City not found")

           place = results[0]
           latitude = place.get("latitude")
           longitude = place.get("longitude")
           resolved_name = place.get("name")
           country = place.get("country")

           forecast_resp = client.get(
               FORECAST_URL,
               params={
                   "latitude": latitude,
                   "longitude": longitude,
                   "current": "temperature_2m",
               },
           )
           forecast_resp.raise_for_status()
           forecast_data = forecast_resp.json()

           current = forecast_data.get("current") or {}
           units = forecast_data.get("current_units") or {}
           temperature_value = current.get("temperature_2m")
           temperature_unit = units.get("temperature_2m", "")
           current_time = current.get("time")

           if temperature_value is None:
               raise HTTPException(status_code=502, detail="Temperature unavailable")

           return {
               "city": resolved_name,
               "country": country,
               "latitude": latitude,
               "longitude": longitude,
               "temperature": temperature_value,
               "unit": temperature_unit,
               "time": current_time,
           }
   except httpx.HTTPStatusError as exc:
       raise HTTPException(status_code=502, detail=f"Upstream error: {exc.response.status_code}")
   except httpx.RequestError:
       raise HTTPException(status_code=502, detail="Upstream request failed")技术支持

至少还有一个可以优化的点：它在标准的 def 路由中使用了同步的 httpx.Client。对于 FastAPI，这会阻塞。理想的“专家级”代理可能会使用 async def 和 httpx.AsyncClient。

尽管如此，首个测试仍产出了一个可用工具。运行 run_local.sh 构建了 Docker 镜像，并在 8000 端口启动了容器。实际尝试时，它成功返回了赫尔辛基的当前气温：

curl "http://localhost:8000/temperature?city=Helsinki"技术支持

{"city":"Helsingfors","country":"Finland","latitude":60.16952,"longitude":24.93545,"temperature":-6.0,"unit":"°C","time":"2026-02-09T07:15"}技术支持

测试 2：实时引导上阵

为体验引导功能，我先让 Codex 构建一个咖啡店落地页，随后在工作流中途切换了主题。鉴于 Web 开发被明确标注为 GPT-5.3-Codex 的强项之一，这对它应该是小菜一碟（配咖啡）。原始提示为：

Build a landing page for a coffee shop using HTML and CSS. Use a dark theme with blue accents.技术支持

在 Codex 应用中工作时，当 Codex 正在处理任务，您将鼠标悬停在“输入消息”按钮上，可以看到两个选项：

• 排队： 让 Codex 在停止当前工作后处理您的提示（Enter）
• 引导： 立即更改原始提示或提供上下文（Cmd + Enter）

当我看到已生成 index.html 且 Codex 正在编写 CSS 文件时，我改变了主意：

Codex 将新的上下文合入旧提示，在不中断的情况下按新主题返回了最终结果。您还能看到引导命令后的变更，新增与删除的行分别以绿色和红色标注。

结果看起来相当清爽，包含我们想要的按钮，主题也符合最新要求。不过网站略显“寡淡”，考虑到我们的提示很简略，这也在情理之中。

我还尝试让 Codex 恢复最初并未真正实现的旧主题。在我要求回到原始主题后，它交付了与第一条提示相符的结果。

我尤其好奇 Codex 如何处理点单按钮，因为我的提示是“改回去”，但只明确要求了原始主题。它的处理颇为巧妙：先询问我是否保留按钮，在我未作答后才将其移除。

下面是主题还原后的页面效果：

测试 3：自愈逻辑与歧义

最后，我想测试模型对经典逻辑错误的响应能力。为此，我让 Codex 通过一个永不满足的条件创建无限循环。看看它宣称的自愈逻辑能否意识到脚本卡住、终止它，并在我不干预的情况下重写逻辑。

提示语相当直接，要求执行一个倒计时，但故意不对计数器做递减：

Write a Python script that counts down from 10 to 0 and prints 'Blastoff!'.
Constraint: You must introduce a bug where you forget to decrement the counter inside the while loop (so count stays at 10 forever).
Execute the script and verify the output.技术支持

这是表现最差的一次测试：Codex 执行了倒计时，数字十保持了近四分钟，最终才通过Ctrl + C 中断。

它没有做的是质疑原始提示是否可能产生除这个“无限循环的十”之外的任何结果。此外，应用对我而言还出现了冻结，我不得不手动退出并重启。

当我稍微修改提示，使矛盾更明显（在末尾加上“执行脚本，完成倒计时”）时，Codex 意识到了歧义并询问我真正的诉求：

GPT-5.3 仍然更像是一名“服从的执行者”，而非“叛逆的思考者”。它最初优先服从了我的指令（“引入一个缺陷”），而不是常识（“脚本卡住了”）。当目标清晰（如“让测试通过”）或矛盾被明确指出时，它很可能能自愈式修复偶发错误；但当指令存在隐含冲突时，它就会吃力。

我如何使用 GPT 5.3 Codex？

OpenAI 宣布，GPT-5.3-Codex 现已通过所有付费 ChatGPT 订阅层在应用内、通过 CLI、通过 IDE 扩展以及在网页端提供使用。

该模型暂未在 OpenAI API 中提供，但 API 访问将“很快”上线。目前尚未公布每 token 的定价细节。

GPT 5.3 Codex vs. Claude Opus 4.6

在面向软件开发的代理领域，GPT-5.3-Codex 的最大竞争对手大概是 Claude Opus 4.6。我们来看看二者的差异。

总体路径与代理风格

OpenAI 与 Anthropic 的路径并非截然不同，但存在一些值得关注的细节。

GPT-5.3-Codex 被定位为更自主的“构建者”，优化于速度（快 25%）和“自我纠错”的循环，以在无人干预下完成工程任务。

相比之下，Claude Opus 4.6 主打深度思考，凭借超大上下文窗口（100 万 tokens）与“自适应思考”，擅长处理复杂、杂乱的遗留项目。

两者的代理风格都侧重互动，但方式略有不同。GPT-5.3-Codex 的“可引导性”允许用户在任务中途打断以改变方向（例如“等一下，改用 v2 API”），且不破坏工作流。

Claude Opus 4.6 更像一位可以对话的资深伙伴，提供“高/中/低”投入设置以平衡成本与深度。

GPT-5.3-Codex 专门针对 NVIDIA GB200 NVL72 硬件优化，以降低代理循环中的延迟；而 Claude Opus 4.6 更侧重软件侧优化，如对话压缩，以高效管理超长历史。

基准与表现

在基准方面，两者难以全面比较。目前我们仅在 Terminal-Bench 2.0 上同时获得了二者分数，GPT-5.3-Codex（75.1%）优于 Claude Opus 4.6（69.9%）。

这表明，尽管 Claude 或许更“深思熟虑”，但 GPT-5.3-Codex 更擅长在真实环境中“动手执行”开发任务，如导航文件系统、管理依赖或运行构建。

除此之外，二者难以比较的原因在于两家公司在发布说明中选择了不同的基准。这种分歧很可能反映了双方的策略：突出自身优势，回避在可能无法拿到“头名”的对比上正面交锋。

以下是我们已知情况的概览：

GPT-5.3 Codex 的应用场景

此前介绍的关键特性，使 GPT-5.3-Codex 非常契合以下场景：

• 自愈式基础设施： 代理监控日志、识别崩溃、修复代码并在无人参与下重新部署
• 遗留系统迁移： 从 COBOL 等遗留语言迁移到现代技术栈，同时由通用代理同步重写文档
• 网络安全： 首个在安全任务上被评为“高能力”的模型，适合自动化渗透测试与补丁修复

结语

既是与 GPT-5.2-Codex 一样优秀的编码者，又有 GPT-5.2 一样出色的思考能力，但仍然不止于此：借助 GPT-5.3-Codex，OpenAI 已从“单点模型”迈向“强大的通用代理”。尽管仍需进行更多评估，但其首批基准结果颇为可期。

交互式协作功能非常出色，但目前仅限于 macOS 版 Codex 应用。用户也仍需等待 API 访问开放。

在速度与自主构建方面的优化，使 GPT-5.3-Codex 采取了不同于 Claude Opus 4.6 的路径，并在 Terminal-Bench 2.0 上胜出。但两者刚刚发布，细节层面的性能差异仍难以全面评估。时间会揭示更完整的对比图景。

如果您想进一步了解代理式工具的概念与能力，建议报名我们的AI Agent Fundamentals 技能学习路径。