OpenAI Responses API 推理结果怎么续接：encrypted_content、include 与手动历史回传

用 OpenAI Responses API 对接推理类大模型时，第一轮能正常返回答案，不代表第二轮多轮续接还能稳定运行。真正容易被中间层逻辑误删的是 reasoning item：如果应用手动管理上下文，需要按官方规则保留完整推理项；需要加密内容时，再通过 include 请求 reasoning.encrypted_content。

把 Responses API 的推理 item 当成上下文的一部分保存和回传，不要只抽取可见文本或工具参数。encrypted_content 是供 API 续接使用的加密字段，不是给用户展示的思维正文。

先分清 output_text 和 reasoning item

Responses API 的顶层响应里，开发者常用 output_text 直接拿最终展示文本。但这个便捷字段只是面向用户的阅读结果，不等于完整的模型输出历史。推理模型可能返回 reasoning、function_call、message 等不同类型的 item，后续续接请求需要的是这些 item 组成的完整上下文结构。

reasoning item 可能包含摘要、内容和加密内容字段。加密内容用于模型继续处理上下文，不能当成可读的思维链，也不应该写入前端日志或对外展示的页面。

为什么只保存最终文本会让第二轮续接变脆弱

很多中间层封装的常见做法是：

type ConversationTurn struct {
    UserText      string
    AssistantText string
}

它适合只做单轮问答展示的场景，却无法还原模型在上一轮产生的 reasoning 或工具调用全链路数据。如果第二轮需要继续调用函数、引用先前的推理状态，服务端收到的历史就缺了一段关键 item。

更稳妥的做法是把 API 返回的 output item 作为受控的原始结构保存，业务层做用户展示时再从中提取需要的文本。日志可以记录 item 类型、数量和 request ID，但不要打印 encrypted_content 的明文内容。

include 参数解决什么问题

官方 API Reference 将 reasoning.encrypted_content列为可通过 include 请求的字段。它的作用是让接口响应中带上加密推理内容；是否需要开启它，取决于你的应用是否要在手动续接、工具调用或跨请求上下文中保留这份内容。

{
  "model": "your-reasoning-model",
  "input": "检查这份订单是否需要人工复核",
  "include": ["reasoning.encrypted_content"]
}

不要把 include 当成“打开思维链展示”的开关。它返回的是加密字段，应用的职责是按原样保留和回传，不能解密、改写或拼接成面向用户的解释文本。

函数调用续接要保留哪几段

当模型先发出函数调用请求时，应用通常要先执行对应工具逻辑，再发起下一次 Responses 请求。续接链路至少要包含三部分：用户输入、模型原始输出 item、工具返回结果。模型原始输出里如果存在 reasoning item 或 function_call item，就要整体保留，不能只提取函数名和参数做单独存储。

{
  "input": [
    {"role": "user", "content": "查订单 10086 的风控状态"},
    {"type": "reasoning", "id": "rs_example", "encrypted_content": "", "summary": []},
    {"type": "function_call", "call_id": "call_1", "name": "get_order_risk", "arguments": "{\"order_id\":\"10086\"}"},
    {"type": "function_call_output", "call_id": "call_1", "output": "{\"risk\":\"review\"}"}
  ]
}

三种验收场景要分开跑

只有文本输出

检查响应是否存在完整 output item，同时确认展示层仍能正常读取 output_text。这个场景用来发现序列化层是否把未知类型的 item 直接丢弃了。

推理加工具调用

让模型调用一个返回固定 JSON 的测试函数。检查下一次请求是否同时包含原始模型 item 和 function_call_output，且 call_id 没有被转换层改写。

连续两次工具调用

让第一轮工具结果触发第二个工具调用。每轮都保存并回传模型输出，直到最终 message 出现。不要只在最后一轮保存历史，否则中间的 reasoning 和调用对应关系已经丢失。

日志与数据保留怎么做边界

生产日志建议记录 response.id、item 类型列表、是否包含 encrypted_content、输入输出 token 统计和工具调用数量。加密字段的明文值本身不必写入普通日志；需要排查问题时，将脱敏后的原始响应放到受控样本文件夹，并设置自动过期策略。

OpenAI 官方数据控制说明还区分了 Responses API 的应用状态保留和具体请求行为。不要根据一篇旧示例推断所有项目都采用同一保留策略，部署前应结合当前组织设置、模型和 endpoint 文档复核。

常见问题

encrypted_content 可以解码后展示给用户吗？

不可以把它当成可读推理文本来处理。它是供模型上下文续接的加密内容，业务侧应原样保存或回传，不应尝试解密或据此生成“模型思考过程”。

只使用官方 SDK 还需要手动保存 reasoning 吗？

SDK 可以减少上下文管理工作，但应用仍要理解 response item 的生命周期。只要代码做了自定义持久化、跨服务转发、历史裁剪或工具循环，就应该测试完整 item 是否被保留。

include 没有返回 encrypted_content 是接口失败吗？

不能只凭字段缺失下结论。先确认模型、请求参数和响应 item 是否支持该字段，再检查是否使用了正确的 Responses API endpoint，以及中间层是否过滤了未知字段。

把上下文完整性放进发布门禁

这类问题最适合用 JSON fixture 做回归：一份包含 reasoning 的响应、一份包含函数调用的响应，再加一份连续工具调用响应。转换前后分别断言 item 类型、顺序、call_id 和 encrypted_content 是否保持不变，最后才检查用户看到的文本。这样换模型、升级 SDK 或调整网关字段白名单时，错误会在测试里暴露，而不是等第二轮线上请求才出现。