Open Responses 的 agent loop 为什么不等于 Chat Completions：输入输出对象的迁移边界

把一个问答接口接进智能体后，最先暴露的问题通常不是模型回答得好不好，而是客户端只会读取一段文本。模型一旦发出工具调用，应用还要回传工具结果、保留中间状态，再接住最终回答，原来的消息数组就不够用了。

Open Responses 的变化，正是在 Responses API 的方向上把这些对象和事件纳入一个更适合代理循环的共享约定。它不是把 Chat Completions 换一个路径，而是把“模型说了一句话”扩展成“模型和工具共同完成了一次响应”。

Open Responses 把一次调用扩成什么

旧式聊天接口把一次调用想象成一组消息：用户发问，模型返回 assistant 消息。这个模型很适合单轮或固定多轮对话，却很难表达“先查数据，再调用外部工具，最后继续回答”的完整记录。

Open Responses 把响应拆成可识别的 items，并把流式输出建模为语义事件。于是同一请求里可以出现文本、工具调用、工具结果以及推理相关条目。对路由服务来说，共享 schema 还可以减少不同模型提供方之间的字段翻译。

为什么 agent loop 需要不同的响应对象

关键差别不在于 JSON 是否更复杂，而在于对象的职责不同。messages 描述聊天输入，ChatCompletion 更像一次选择结果；代理循环则要持续容纳 tool_calls、response.items、工具结果 和 agent loop 自身的状态。

因此，不能把 Open Responses 简化成“Chat Completions 的新字段”。它把工具和中间响应变成可观察对象，客户端才有机会显示正在调用什么、等待哪个结果，以及最终文本来自哪些条目。

旧 Chat Completions 代码会在哪个边界卡住

典型旧客户端只做三件事：提交 messages，读取 choices[0].message.content，把字符串交给页面。如果返回的是工具调用，content 可能为空；如果是流式响应，delta 也不等于一个完整的语义事件。

{
  "choices": [{
    "message": {
      "role": "assistant",
      "tool_calls": [{"id": "call_7", "type": "function"}]
    },
    "finish_reason": "tool_calls"
  }]
}

这段结果说明模型提出了调用请求，并不说明工具已经得到结果。若适配层看到 finish_reason=tool_calls 仍直接返回空文本，应用就会把“需要外部信息”误判成“模型没有回答”。另一方面，直接把每个流式片段拼成字符串，会丢失条目类型和调用身份。

迁移时先保留什么，再替换什么

迁移不必重写业务工具。可以继续使用原有的函数注册、参数校验和结果格式化，把变化集中在一个协议适配层：入口把消息转换成 input，出口把响应条目归一成内部事件，再由业务层决定展示文本、工具状态和审计记录。

多轮状态也不要只保存最后一段文本。若提供方返回可复用的响应标识，例如 previous_response_id，适配层应保存它；若没有，就保存足以重建上下文的条目摘要。这样下一次请求不会把已经产生的工具结果重复当成用户输入。

一个稳妥的内部事件模型至少区分 text、tool_call、tool_result 和 state。外部接口再怎么变化，页面和日志只依赖这组稳定语义，回滚也更容易。

用最小请求验证兼容边界

验证迁移时先别追求完整智能体。准备一个只会查询固定信息的工具，检查四个结果：请求里有 input 和 tools，响应里能识别调用条目，工具结果能回传，最后还能拿到文本条目。

{
  "model": "your-model",
  "input": "查询订单状态",
  "tools": [{"type": "function", "name": "lookup_order"}],
  "tool_choice": "auto"
}

测试记录最好保留调用身份、参数校验结果、工具返回值和最终文本四列。只看到最终文本，不能证明代理循环兼容；只看到工具调用，也不能证明结果回传成功。

最后检查流式分派：文本事件交给渲染器，工具调用交给工具层，工具结果进入下一轮上下文，状态事件进入日志。四类记录都存在，才说明适配层没有把多对象响应压扁成一个字符串。

相关问题

Open Responses 能直接替换所有 Chat Completions 客户端吗？

不能直接替换。只读最终文本的简单客户端改动较少；依赖 choices、delta 或自定义工具回传格式的客户端仍需要适配层。

迁移后还要重写工具函数吗？

通常不用。工具的参数校验、业务逻辑和返回结构可以保留，重点是把协议层的调用身份与工具结果正确对应起来。

为什么不能只保存最后一条 assistant 消息？

因为代理循环的中间条目包含调用请求和外部结果。只保存最后文本会让排查、重试和多轮续接失去必要上下文。