架构

使用 OpenAI Responses API 构建有状态智能体：实用指南

作者：IdeaBosque最后更新：2026年9月5日

关键要点

Responses API 是 OpenAI 推荐的所有新项目的 API 原语，Assistants API 已于 2026 年 8 月 26 日下线 — 迁移窗口已关闭；Chat Completions 仍然受支持，但新的代理能力不会先在这里落地。
OpenAI 内部评测显示，通过 Responses API 使用 GPT-6 Astra 等推理模型时，SWE-bench 提升 3%，缓存利用率提高 40–80% — 代理循环不仅是便利，它可衡量地提升了输出质量。
远程 MCP 服务器是 Responses API 中的一等工具类型 — 你只需用 server_url 和 server_label 连接任意 MCP 服务器，模型就会在同一请求内发现并调用其工具，无需自定义编排。
GPT-6 Astra 的失准监控器在检测到未授权行为时会直接停止 API 任务 — 没有恢复路径；工作流必须能从持久状态恢复，这是生产级采用中最重要的架构约束。
有状态模式比无状态 Chat Completions 大约慢 2 倍，据多位开发者报告 — previous_response_id 的便利性伴随着延迟代价，对延迟敏感的面向用户流程影响显著。

OpenAI Responses API 是公司推荐用于所有新开发的 API 原语，Assistants API 已于 2026 年 8 月 26 日正式下线。Chat Completions 仍然受支持，但 Responses API 是新代理能力——内置工具、有状态对话、远程 MCP、后台模式、中途引导——首先落地的地方。对于在 GPT-6 Astra 上构建生产级代理的团队，问题不再是是否迁移，而是如何围绕 API 的状态模型、其延迟特征和 Astra 运行时监控器施加的治理约束进行架构设计。本指南梳理了五项关键能力、三个决定采用的决策，以及保持你的代理跨提供商可移植的架构模式。

Responses API 改变了什么

Chat Completions API 是无状态的：你每次请求都发送完整的对话历史，API 返回单条消息。Responses API 引入了三个结构性变化，影响你构建代理的方式。

用 Item 代替消息。 Chat Completions 返回 choices 数组，每个包含一个 message。Responses API 返回 output Item 数组，每个 Item 是一个类型化联合体——message、function_call、function_call_output、推理摘要或工具调用。这不是装饰性的：这意味着工具调用、推理和文本是响应中的一等对象，而非附加在消息上的字段。当你用 previous_response_id 链接响应时，API 跨轮次保留所有 Item 类型——包括加密推理——这正是让多轮代理工作流无需手动上下文重放即可运作的原因。

一个请求中的代理循环。 Responses API 被设计为代理循环：模型可以在单次 API 调用中调用多个工具——web_search、file_search、computer_use、code_interpreter、image_generation、远程 MCP 服务器和自定义函数——迭代直到达到停止条件。用 Chat Completions 时，你需要自己实现这个循环：调用模型、解析工具调用、执行它、附加结果、再次调用。Responses API 在服务端运行循环。OpenAI 内部评测显示，通过 Responses API 使用推理模型时 SWE-bench 提升 3%，缓存利用率提高 40–80%——服务端循环受益于手动循环无法复制的缓存命中。

通过 previous_response_id 实现有状态上下文。 你不再每次请求发送完整历史，而是传递前一个响应的 ID 和新的用户输入。API 在服务端重建上下文，包括推理 Item。响应默认存储 30 天；附加到对话的任何响应持久化其 Item 且无 TTL。你可以用 store: false 禁用存储来实现零数据保留工作流，但那样你必须手动重放完整的 Item 历史——包括加密推理 Item——以跨轮次保留推理上下文。

五项关键能力

Responses API 的能力映射到五个架构决策，每个都有具体的权衡：

1. previous_response_id：有状态链式调用

最简单的有状态模式通过 ID 链接响应：

from openai import OpenAI
client = OpenAI()

first = client.responses.create(
    model="gpt-6-astra",
    input="What is the capital of France?",
    store=True,
)

second = client.responses.create(
    model="gpt-6-astra",
    previous_response_id=first.id,
    input="And its population?",
    store=True,
)

第二次调用不会重新发送第一个问题或答案。API 从存储的响应中重建完整上下文，包括模型执行的任何推理。这是对话代理、研究助手和任何后续取决于前序轮次的工作流的模式。

权衡是延迟。OpenAI 社区论坛和 Microsoft Q&A 上的多位开发者报告表明，有状态路径比无状态 Chat Completions 大约慢 2 倍——典型情况下 1 秒对 0.5 秒，负载下最多慢 9 倍（2.9 秒对 0.3 秒）。对于运行数分钟的后台研究代理，这无关紧要。对于必须在 500ms 内响应的面向用户聊天，延迟代价可能证明继续使用带手动上下文管理的 Chat Completions 是合理的。

2. 远程 MCP 服务器作为内置工具

Responses API 支持远程 MCP 服务器作为一等工具类型。你通过 URL 注册服务器，模型在代理循环中发现其工具并调用：

response = client.responses.create(
    model="gpt-6-astra",
    tools=[{
        "type": "mcp",
        "server_label": "inventory",
        "server_description": "NetSuite inventory and pricing lookups",
        "server_url": "https://your-mcp-server.example.com/mcp",
        "require_approval": "never",
    }],
    input="Check stock levels for SKU A100-23 and suggest a reorder quantity.",
)

require_approval 字段控制模型在调用服务器工具前是否需要人工审批。对于生产部署，MCP 工具过滤选项——allowed_tools 白名单特定工具名称，以及按工具的自定义审批策略——是防止模型在未获明确授权时调用破坏性操作的治理层。

这是与 IdeaBosque 集成模式最相关的能力。一个封装 NetSuite、HubSpot 或 BigCommerce API 的自定义 MCP 模块可以注册为 Responses API 调用中的远程 MCP 服务器，模型使用它的方式与使用 web_search 或 code_interpreter 相同。语义层——类型化 schema、审计日志、速率限制处理——存在于 MCP 模块中，而非 prompt 中。Responses API 不解决语义层问题；它使 MCP 模块成为自然的集成点。关于该模式的深入探讨，参见 MCP Module Code Standard。

3. 后台模式用于长时间运行任务

后台模式将模型调用与客户端连接解耦。API 接受请求，立即返回响应 ID，异步运行模型工作。你轮询状态或流式接收结果：

resp = client.responses.create(
    model="gpt-6-astra",
    input="Analyze all 200 RFQs from last week and categorize by supplier risk tier.",
    background=True,
)

while resp.status in {"queued", "in_progress"}:
    sleep(2)
    resp = client.responses.retrieve(resp.id)

print(resp.output_text)

对于长时序代理——研究综合、批量文档分析、多步采购工作流——后台模式是能在网络中断和客户端超时中存活的模式。一个耗时六分钟的后台响应不依赖活跃的 HTTP 连接；如果客户端断开，工作继续，你使用最后的序列号通过流式恢复重新连接。

运维上的问题是后台模式不是作业队列。正如一篇分析所述：API 运行模型调用，但你的应用仍然拥有作业状态——UI 显示什么、如何避免重复处理 webhook、何时取消不再需要的工作。对于生产环境，你需要在后台响应周围有一个持久作业系统，而不仅仅是响应 ID。这与 Long-running Agent Patterns 中描述的模式相同：代理运行时，而非模型 API，才是可靠性层。

4. 加密推理用于零数据保留工作流

当 store: false 时，API 不持久化响应，但在输出中返回加密推理 Item。你在下一个请求的输入中传回这些 Item，以跨轮次保留推理上下文，而不会在 OpenAI 服务器上存储任何内容。这是禁止数据保留的受监管环境的模式——EU AI Act 高风险系统、HIPAA 下的医疗工作流、ITAR 下的国防工作流。

权衡是你成为了状态存储方。你必须在每个轮次序列化、存储和重放完整的 Item 数组——包括不透明的加密推理 blob。如果你丢失了加密推理 Item，模型就会失去推理上下文，输出质量会下降。这与 Chat Completions 相同的状态管理负担，但多了一个需要处理的 Item 类型。

5. Astra 任务停止监控器

GPT-6 Astra 在每个使用工具的请求上都配备了失准监控。当监控器标记潜在未授权行为时，模型的响应包含停止信号。在 ChatGPT 和 Codex 中，用户看到暂停的任务以供审查。在 API 中，任务直接停止——没有恢复路径。

对于在 Responses API 上构建的生产代理，这是最重要的架构约束。一个通过 previous_response_id 链或后台模式运行数小时的任务可能被分类器中途终止。你的工作流必须能从持久状态恢复——每次工具调用、每个中间结果、每个部分输出必须在下一次 API 调用前持久化到你自己的存储中。如果监控器在第 47 步（共 50 步）停止任务，你需要能从第 47 步恢复，而非从零重启。

OpenAI 首席科学家 Jakub Pachocki 在 An Alien Mind（2026 年 9 月 6 日）中透露，公司依赖思维链监控的能力正在"逐步减弱"——模型更擅长推理和操纵自己的推理过程，改进的预训练使模型即使没有言语化推理也更聪明。停止你任务的监控器是当前最好的运行时执行层，但其供应商已表示它依赖的信号正在退化。关于不读取模型推理的执行层的深入探讨，参见 GPT-6 Astra Ships the Runtime Kill Switch。

三个采用决策

决策 1：有状态还是无状态？

当你的工作流是对话式、多轮次且延迟容忍时，使用 store: true 配合 previous_response_id。当你的工作流要求零数据保留或你需要完全控制上下文管理时，使用 store: false 配合手动 Item 重放。延迟差异大约 2 倍——对后台代理可接受，对面向用户的聊天可能不可接受。

决策 2：内置工具还是自定义函数？

内置工具（web_search、file_search、code_interpreter、computer_use、image_generation、远程 MCP）在服务端运行并受益于代理循环的缓存优化。自定义函数需要你自己实现工具调用循环。实践规则：对于 OpenAI 提供得比你更好的能力（网络搜索、代码执行）使用内置工具，对于你自己的系统集成（NetSuite、HubSpot、BigCommerce）使用远程 MCP 服务器。仅对无法暴露为 MCP 服务器的能力使用自定义函数。

决策 3：仅 OpenAI 还是模型灵活？

Responses API 是 OpenAI 的原语。如果你完全基于 previous_response_id 和内置工具构建代理，你就被锁定在 OpenAI 的状态存储和工具生态中。如果你的生产需求包括模型灵活性——将敏感成本的任务路由到 Qwen3.8-27B 等开放权重模型，或路由到 Claude 的特定能力——你需要一个抽象层，在 Responses API 的 Item 模型和其他供应商使用的 Chat Completions 消息格式之间转换。

这是决定 Responses API 是你整个代理运行时还是多个后端之一的架构决策。模型灵活的构建将代理循环保留在你自己的运行时中，在 Responses API 的能力值得其延迟和锁定代价时使用它，在不值得时回退到 Chat Completions 或开放权重推理。推理经济学很明确：29% 的生产 token 用量已经在开放权重模型上运行，支出不到 4%。路由纪律是生产现实，而非未来计划。

迁移清单

OpenAI 的迁移指南提供了完整清单。影响架构而非仅代码的决策：

确定你的状态模型。 previous_response_id、手动 Item 重放或 Conversations API。这决定了你的延迟特征和数据保留姿态。
审计你的函数定义。 自定义函数原样迁移，但函数调用输出必须包含正确的 call_id。在手动传递上下文时丢弃推理或函数调用 Item 是最常见的迁移错误。
将 Structured Outputs schema 从 response_format 移至 text.format — 字段名已更改。
为任何运行超过几秒的工作流添加持久状态持久化。 Astra 任务停止监控器可以在没有恢复路径的情况下终止长任务；你的状态存储是恢复机制。
在路由生产流量之前比较延迟、token 使用量和错误率。 3% SWE-bench 提升和 40–80% 缓存改善是平均值；你的工作负载可能不同。
保留 Chat Completions 回退，如果模型灵活性很重要。Responses API 仅限 OpenAI；其他供应商使用 Chat Completions。