GPT-5.5 发布5天，我用它的 Responses API 跑了一遍 Agentic Coding

4月24日 OpenAI 发布了 GPT-5.5，代号 Spud。这是 GPT-4.5 之后第一个从头训练的底座模型，不是 GPT-5.x 系列的微调版本。

我比较关注两点：一是它在 Codex 里消耗的 token 少了不少，二是 agentic 工作流的自主性明显提高------给一个模糊任务，它能自己规划、调工具、检查结果、出错后自动修正。

这篇文章不讲"GPT-5.5 有多厉害"，讲怎么用。从 API 接入到参数调优，带完整代码。

GPT-5.5 和之前的 GPT-5.x 有什么不同

先说结论：底座换了。

GPT-5.0 到 5.4 都是在同一个底座上做微调。5.2 加深了推理，5.3 集成 Codex，5.4 加了 computer use。但底子没变。GPT-5.5 重新训练了底座，所以性能上限提高了。

几个对开发者有用的变化：

• 原生多模态：文本、图片、音频、视频在同一个模型里处理，不是拼接的 pipeline。以前用 GPT-5.4 分析一张截图再生成代码，中间有信息损耗。5.5 里这个损耗小了。
• token 效率：同样的编码任务，token 消耗比 5.4 低。OpenAI 没给具体数字，但我跑了几个项目，大概省 20-30%。
• agentic 自主性：给一个含糊的多步任务，它会自己拆步骤、选工具、验证结果。不用像以前那样写很长的 prompt 手把手教。

三个模型怎么选

GPT-5.5 家族有三个尺寸。选错了要么浪费钱，要么质量不够。

模型	适合干什么	每百万输入 token 价格
gpt-5.5	复杂编码、多步 agent 循环、架构决策	$12
gpt-5.5-mini	日常编码辅助、一般工具调用	$3
gpt-5.5-nano	分类、路由、提取、低延迟场景	$0.5

我自己的用法：写代码用 gpt-5.5，做 PR review 用 gpt-5.5-mini，前置的意图分类用 nano。别把所有请求都打到最大模型上，没必要。

两个关键参数：verbosity 和 reasoning_effort

GPT-5 系列引入了两个控制参数，5.5 继续沿用。很多人没注意到，但这两个参数对输出质量和成本影响很大。

verbosity：控制输出的详细程度。设低了，回复简短紧凑。设高了，会输出详细的解释。

reasoning_effort：控制模型在回答前"想多久"。设高了，模型会花更多推理 token 来思考，适合复杂任务。设低了，响应快但容易漏掉边界情况。

from openai import OpenAI

client = OpenAI()

# 场景1：快速分类，不需要深度思考
response = client.responses.create(
    model="gpt-5.5-nano",
    input="这段代码是 bug fix 还是 feature？\n\n" + code_diff,
    verbosity="low",
    reasoning={"effort": "low"},
)

# 场景2：复杂调试，需要深度推理
response = client.responses.create(
    model="gpt-5.5",
    input="这个 Flask 应用在并发 > 100 时偶尔返回 500，帮我定位原因",
    verbosity="high",
    reasoning={"effort": "high"},
    tools=[
        {"type": "code_interpreter"},
        {
            "type": "function",
            "function": {
                "name": "read_file",
                "description": "读取项目文件",
                "parameters": {
                    "type": "object",
                    "properties": {
                        "path": {"type": "string"}
                    },
                    "required": ["path"]
                }
            }
        }
    ],
)

踩坑提醒：verbosity 和 reasoning_effort 都设 high 的时候，token 消耗会翻倍。我有一个任务单次跑了 8 万 token，排查后发现是参数没调，改成 medium 后降到 3 万。

用 Responses API 构建 Agentic Coding 工作流

Responses API 是 OpenAI 在 GPT-5 时代推的新接口，比 Chat Completions API 更适合 agent 场景。区别在于 Responses API 原生支持工具调用的循环------模型调工具，拿到结果，继续推理，再调下一个工具。不用自己写循环。

下面是一个完整的例子：给 GPT-5.5 一个 GitHub Issue，让它自动分析代码、定位问题、生成修复方案。

from openai import OpenAI
import json

client = OpenAI()

# 定义工具
tools = [
    {
        "type": "function",
        "function": {
            "name": "search_codebase",
            "description": "在代码库中搜索相关文件和函数",
            "parameters": {
                "type": "object",
                "properties": {
                    "query": {"type": "string", "description": "搜索关键词"},
                    "file_pattern": {"type": "string", "description": "文件名匹配模式，如 *.py"}
                },
                "required": ["query"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "读取指定文件内容",
            "parameters": {
                "type": "object",
                "properties": {
                    "path": {"type": "string"},
                    "start_line": {"type": "integer"},
                    "end_line": {"type": "integer"}
                },
                "required": ["path"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "write_patch",
            "description": "生成代码补丁",
            "parameters": {
                "type": "object",
                "properties": {
                    "file_path": {"type": "string"},
                    "original": {"type": "string"},
                    "replacement": {"type": "string"},
                    "explanation": {"type": "string"}
                },
                "required": ["file_path", "original", "replacement"]
            }
        }
    }
]

# 启动 agentic 任务
response = client.responses.create(
    model="gpt-5.5",
    input=[
        {
            "role": "developer",
            "content": "你是一个代码调试助手。分析 issue 描述，搜索相关代码，找到根因，生成修复补丁。"
        },
        {
            "role": "user",
            "content": """
GitHub Issue #342: 用户上传 CSV 文件时，如果文件名包含中文，
服务端返回 400 Bad Request。复现步骤：上传名为"销售数据.csv"的文件。
日志显示 UnicodeDecodeError。
"""
        }
    ],
    tools=tools,
    reasoning={"effort": "high"},
    verbosity="medium",
)

# 处理工具调用循环
while response.output:
    tool_calls = [item for item in response.output if item.type == "function_call"]
    if not tool_calls:
        break

    # 执行工具调用
    tool_results = []
    for call in tool_calls:
        args = json.loads(call.arguments)
        result = execute_tool(call.name, args)  # 你的工具执行函数
        tool_results.append({
            "type": "function_call_output",
            "call_id": call.call_id,
            "output": json.dumps(result, ensure_ascii=False)
        })

    # 把工具结果送回模型，继续推理
    response = client.responses.create(
        model="gpt-5.5",
        input=tool_results,
        previous_response_id=response.id,
        tools=tools,
        reasoning={"effort": "high"},
    )

# 输出最终结果
for item in response.output:
    if item.type == "message":
        print(item.content[0].text)

这段代码的关键在 previous_response_id。通过这个参数，Responses API 自动维护上下文，不需要你手动拼接消息历史。每一轮工具调用的结果都会被追加到对话里，模型能看到之前做了什么。

实测数据

我用上面的工作流跑了 30 个真实 GitHub Issue（来自 3 个 Python 项目），统计结果：

指标	GPT-5.4	GPT-5.5
正确定位根因	19/30 (63%)	24/30 (80%)
生成可用补丁	14/30 (47%)	20/30 (67%)
平均 token 消耗	45,200	32,800
平均耗时	28s	22s

几个观察：

1. GPT-5.5 在多文件跳转上进步明显。5.4 经常在第二个文件就丢失上下文，5.5 能连续跟踪 4-5 个文件。
2. token 消耗降了 27%，和 OpenAI 说的"significantly fewer"基本吻合。
3. 失败的 case 主要集中在需要理解业务逻辑的 bug，纯技术 bug 的修复率到了 85%。

Responses API vs Chat Completions API

两个 API 都能用 GPT-5.5，但适用场景不一样。

用 Responses API 的场景：需要多轮工具调用、流式输出、agent 循环的新项目。API 自己管理对话状态，代码量少。

用 Chat Completions API 的场景：已有项目不想迁移，或者只需要简单的问答，不涉及工具调用。

# Chat Completions API 写法（兼容旧项目）
response = client.chat.completions.create(
    model="gpt-5.5",
    messages=[
        {"role": "system", "content": "你是代码审查助手"},
        {"role": "user", "content": "审查这段代码的安全性：\n" + code}
    ],
    temperature=0.2,
)
print(response.choices[0].message.content)

新项目建议直接用 Responses API。它支持 previous_response_id 自动追踪上下文，内置 code_interpreter 和 web_search 工具，对 agent 工作流友好得多。

成本控制的几个实操建议

开启 Prompt Caching。如果 system prompt 固定，缓存命中后只收 50% 费用。我的项目 system prompt 有 2000 token，一天调 500 次，每天省 $6。

用 nano 做前置分类。先判断这个问题是 bug 还是 feature request，只把 bug 类请求发给 gpt-5.5 做深度分析。能省 60% 以上的成本。

非实时任务走 Batch API，价格五折。我每天晚上把白天积攒的 code review 请求批量提交，第二天早上拿结果。

别乱设 reasoning_effort。默认 medium 够用，只有复杂调试和架构决策才用 high。有人把所有请求都设 high，月账单翻了三倍。

# 分层调用示例
def process_issue(issue_text):
    # 第一层：nano 分类
    classify = client.responses.create(
        model="gpt-5.5-nano",
        input=f"判断这个 issue 是 bug、feature 还是 question：\n{issue_text}",
        verbosity="low",
        reasoning={"effort": "low"},
    )
    category = classify.output_text.strip().lower()

    # 第二层：根据类别选模型
    if category == "bug":
        return debug_with_gpt55(issue_text)  # 用 gpt-5.5
    elif category == "feature":
        return plan_with_mini(issue_text)     # 用 gpt-5.5-mini
    else:
        return answer_with_nano(issue_text)   # 继续用 nano

几个坑

坑1：上下文窗口不是越大越好。 GPT-5.5 支持 1.1M token 的上下文。但塞太多进去，推理质量反而下降。我把整个项目的代码都塞进去，修复准确率反而比只塞相关文件低了 15%。信噪比很重要。

坑2：工具定义要写清楚。 工具的 description 和参数说明直接影响模型调用工具的准确率。我有个工具 description 写了一句"搜索代码"，模型经常传错参数。改成"在代码库中按关键词搜索文件，返回匹配的文件路径和相关代码片段"后，调用准确率从 70% 到了 95%。

坑3：Responses API 的 previous_response_id 有过期时间。 默认保留 1 小时。如果你的 agent 循环跑得慢（比如等人工审批），可能会过期。处理方式是在中间步骤把对话状态存下来，过期后重新构建。

值不值得从 5.4 升级

如果你用 Chat Completions API 做简单问答，区别不大。

如果你在做 agent 工具链、多步编码任务、需要跨文件理解的代码分析，值得升。token 消耗降了，多文件追踪能力变强了，agentic 自主性也好了。

我自己的项目已经全切到 5.5 了。5.4 可能还会维护一段时间，但新功能肯定是优先在 5.5 上迭代的。

---

测试环境：Python 3.12 + openai SDK 1.82.0，测试时间 2026年4月25-28日