Responses API（Python）导读
如果你的后端或 worker 主要跑在 Python，可以先把 Responses 作为主要入口跑顺。
Python 团队常见的情况，是先把老的 chat 路径封成一层，再不断往里补 tools、schema、 streaming 和重试逻辑。这样短期能跑，但长期维护会变复杂。用 Python SDK 的client.responses 起步，能更早把输出契约和流式行为统一下来。
最值得先记住的 3 个方法
| Name | Type | Required | Description |
|---|---|---|---|
client.responses.create | function | Required | 非流式请求。最适合后台任务、同步总结和结构化返回。 |
client.responses.stream | function | 流式请求。适合逐 token 输出、CLI 和 agent 交互。 | |
client.responses.retrieve | function | 按 response ID 拉回结果，适合异步工作流和故障排查。 |
最小请求
create
response = client.responses.create(
model="openai/gpt-4.1-mini",
input="把今天的 incident report 总结成 3 条 bullet。",
)
print(response.output_text)先看这几个参数
| Name | Type | Required | Description |
|---|---|---|---|
model | string | Required | 目标模型标识。建议先从稳定默认模型开始。 |
input | string | list | Required | 最小可用输入。多模态和分段 item 也走这个字段。 |
tools | list | 工具定义。要接 tools、search、schema 的时候，这条路径更合理。 | |
stream | bool | 是否使用流式事件。只有真正需要实时消费时才打开。 | |
previous_response_id | string | 多轮续写时引用上一条 response，不必每轮都手工重组上下文。 |
Python 团队的常见选择
如果你已经知道后面会接工具、结构化输出或长生命周期 agent，不要再把 chat 路径越封越厚。 直接从 Responses 起步，反而能减少未来重写成本。
最容易犯的错
text
1. 继续沿用只适用于 chat 的用法，忽略 Responses 的事件与 output 契约。
2. 流式输出只盯着文本，不理解 response.output_item / completed 事件。
3. 一上来就做复杂 agent loop，却没先跑通最小 create 请求。
4. 明明需要稳定机器消费输出，却还在手写脆弱解析。