API

学习和理解 OpenAI的Responses：模型调用过程的原子事务？ Responses 的核心价值，不是把接口名称从 Chat Completions 换成了 responses，而是把模型调用从“返回一段文本”升级成了可组合、可追踪、可继续执行的结构化结果。一次调用可以同时产出最终消息、函数调用、内置工具调用和受控的推理摘要；应用不必再把所有信息塞进一段字符串里猜测和解析，而是可以按 item 类型决定下一步动作。 这个变化真正解决的是 Agent 工程里的三个问题：模型做了什么更容易追踪，工具调用怎么接续更清楚，失败后从哪里恢复更具体。最近和同事讨论 OpenAI 的 Responses API，我发现最容易混淆的不是请求怎么发，而是“一次 Response 到底装了什么”。我现在更愿意把它理解成：一次有结构的模型调用记录。它可以成为调试、审计和多轮协作的共同载体，但它不是数据库里的 ACID 事务，也不是默认把完整思维链交给用户。“原子事务”只是一种帮助理解的比喻：工程上真正要记录的是调用 ID、item 类型、工具结果、失败状态和业务幂等关系 ┌─────────────────────────────────────────────────────────┐ │ Responses 协议心智图 │ ├─────────────────────────────────────────────────────────┤ │ │ │ 你发起 ──→ 一次 Response（原子事务） │ │ │ │ │ ├── input （输入） │ │ ├── instructions （系统级设定） │ │ ├── tools （可选能力清单） │ │ │ ├── 内置工具 （web/file/code/MCP）│ │ │ └── 自定义函数 │ │ ├── previous_response_id （状态游标） │ │ └── stream / background （执行模式） │ │ │ │ 服务端返回 ──→ 一个 Response 对象 │ │ │ │ │ └── output[] （异构工件清单） │ │ ├── reasoning （思维证据） │ │ ├── tool_call （动作证据） │ │ │ ├── 入参 │ │ │ └── 结果 │ │ └── message （交付物） │ │ │ └─────────────────────────────────────────────────────────┘ ...