For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
主导航
2026年3月11日 API

从提示到产品:Responses 一周年

Responses API 推出第一年,开发者用它构建智能体产品的五个故事。

作者: Eva Sasson

从提示到产品:Responses 一周年

一年前,我们推出了 Responses API,为开发者和企业构建实用、可靠的智能体奠定基础。通过为模型配备一套托管工具,AI 从聊天助手发展为能够代表您执行操作的系统。如今,Responses API 支持多种工具来驱动智能体工作流,并提供一系列新功能和基础组件,专门用于基于能力更强的模型进行构建。

如今,数千名开发者正在使用 Responses API 构建产品,提升客户支持法律生命科学旅游等行业的生产力。我们已经分享了这些行业中的许多成功案例,今天则想介绍五个较少被提及的故事,致敬过去一年使用 Responses API 构建产品的开发者。

检测并修复 AI 智能体的故障

作者:Raindrop AI 的 Alexis Gauba 和 Ben Hylak

工具: 自建工具
模型: GPT-5.2(正在测试 GPT-5.4)

Raindrop 为全球最有雄心的 AI 公司提供监控平台,帮助它们发现智能体在生产环境中偏离预期的行为。随着智能体日益复杂,这些故障的影响也愈发严重。

如果没有 Responses API,构建这类监控系统会困难得多,可靠性也会大打折扣。

该系统通过 Vercel AI SDK 使用 Responses API 运行后台分析,让不同模型提供商的模型共用工具,并保持系统在不同环境之间的可移植性。这些工作流会发现异常行为。一旦出现问题,系统就会向开发者发出告警,并协助诊断背后的问题。

该平台专注于三个核心系统:

  1. 智能体行为监控
  2. 故障检测与告警
  3. 面向开发者的排查与调试工具

这些系统协同工作,让团队能够在 AI 智能体的问题影响生产系统之前发现、跟踪并修复它们。

监控架构

Raindrop 监控架构

这种架构让团队能够持续监控智能体行为,并在出现问题时迅速响应。

1. 智能体行为监控

系统持续评估智能体的行为,以判断其是否按预期运行。

开发者可以设置用于判定不良结果的条件,平台可在满足这些条件时发出告警。

2. 故障检测与告警

一旦检测到异常,Raindrop 就会通知开发者,并呈现排查问题所需的相关上下文。

该平台提供的工具可用于:

  • 跟踪智能体不同版本之间的行为变化
  • 确定哪些提示或系统变更引发了故障
  • 检查推理轨迹和工具调用

这让开发者能够快速找到故障的根本原因并部署修复。

3. 排查与调试工具

Raindrop 还提供工具,帮助开发者诊断智能体工作流中的问题。这些能力让团队能够将故障检测的结果用于系统改进。

Raindrop AI 使用 Responses API 驱动所有长时间运行的后台分析工作流。如果没有它,实现这些监控系统会困难得多。

面向复杂数据的深度推理工作流

作者:Repo Prompt 的 Eric Provencher

所用工具: Codex 配合 App Server + MCP、网页搜索
所用模型: GPT-5.3-Codex

我们使用一个独立的智能体提前筛选和整理上下文,避免推理模型在规划或审查时因查找上下文而浪费上下文窗口,让它尽可能将推理能力用于解决我们的任务。

Eric Provencher 构建了一个系统,帮助开发者和研究人员对大规模文档集合、代码库和数据集进行深入分析。

Repo Prompt 专注于上下文工程,即自动收集、整理相关信息并将其结构化,以便推理模型有效地进行分析。

许多智能体系统侧重于收集数据,而 Eric 的架构将上下文收集与深度推理分开。该系统使用智能体工作流汇集相关上下文,再将筛选整理后的信息交给专注于分析的推理模型。

该平台使用 OpenAI Responses API 编排长时间运行的智能体工作流和推理作业,支持的工作流包括:

  • 大型代码库分析与架构规划
  • 深度代码审查工作流
  • 对大规模文档集合进行研究分析
  • 医学与科学文档分析

该系统围绕三个核心组件构建:用于构建上下文的智能体工作流、深度推理模型(“Oracle”工作流),以及迭代式研究与分析循环。

1. 上下文构建智能体工作流

系统的第一阶段由上下文构建智能体负责。这一工作流会分析大规模数据资料库,确定哪些信息与给定查询相关。

该智能体通过 Responses API 使用工具和模型推理,识别相关文件、文档之间的关系以及关键信息片段。

这一阶段会输出一个结构化的上下文包,作为推理阶段的输入。

2. “Oracle”深度推理工作流

Repo Prompt Oracle 工作流图

与上下文构建智能体不同,“Oracle”模型(即深度推理模型)不调用工具,也不检索额外信息,而是专注于分析提供给它的、经过筛选整理的上下文。

将研究与推理分开后,模型就可以将全部推理能力用于理解问题。在许多工作流中,推理阶段可以持续运行较长时间,分析所提供上下文中的复杂关系。

3. 迭代式研究与分析循环

该系统还支持迭代式推理循环。推理模型生成输出后,另一个智能体可以审查结果,判断是否需要进一步研究。

如有需要,系统会启动新一轮上下文收集和推理。这种循环支持长时间运行的研究,让系统逐步完善分析。

迭代工作流

Repo Prompt 迭代工作流

该系统依赖 Responses API 的以下几项能力:

  • 后台作业:运行可持续数分钟或数小时的推理任务
  • 智能体编排:协调智能体循环,完成上下文收集、推理和验证
  • 可观测性:在长时间运行的推理工作流执行期间进行监控和管理

该平台使用 Codex 模型收集相关上下文并将其结构化,再把整理好的上下文交给能力更强的推理模型进行深入分析。这些能力支撑了平台将智能体工作流与深度推理模型相结合的混合架构。

面向黑胶唱片收藏者的对话界面

作者:Collxn 的 Ash Ryan Arnwine

工具: 网页搜索和 16 个自定义工具
模型: GPT-5.4、GPT-5 nano

相比搭建完整的检索增强生成系统等方案,Responses API 让我感觉省了不少工作。

Ash Ryan Arnwine 开发了 “Collxn”(名称让人联想到 collection,即“收藏”)。这是一个小巧的服务,却有着远大的目标:帮助黑胶唱片收藏者重新发现架子上已有的藏品,并与自己的唱片互动。

收藏者常在 Discogs 上管理庞大的唱片收藏,有时多达数千张。Collxn 接入这些收藏数据,每天发送一封名为“Daily Drop”的邮件,每次重点介绍一张不同的唱片及相关音乐人的详细信息,帮助收藏者重温自己已经拥有的音乐。

边翻看唱片边提问会更有乐趣,因此 Collxn 使用 OpenAI Responses API 构建了一个聊天界面,让用户真的可以与自己的唱片“对话”。

支持工具调用的对话界面

该应用使用 Responses API 提供名为“Ask This Drop”的聊天界面,用户可以在其中就 Daily Drop 介绍的唱片提问。

模型配置了 Discogs API 工具访问权限,可以在回答问题时直接从 Discogs 检索信息。

例如,用户可以这样提问:

  • 这张唱片目前的市场价格是多少?
  • 这位音乐人还发行过哪些专辑?
  • 这个压片版本有多稀有?

Ask This Drop 界面

Ask This Drop 为 Collxn 用户提供了与自己的黑胶唱片对话的聊天界面。

收藏者只需提问,就能获得结合 Discogs 实时数据与个人唱片收藏背景信息生成的回答。

这种方式将静态的唱片收藏变成了对话体验,并将其与更广阔的音乐生态连接起来。

Daily Drop 与音乐人新闻

Collxn 还使用 OpenAI Agents SDK,为 Daily Drop 邮件中介绍的音乐人生成“近期新闻”栏目。

Collxn Daily Drop 的音乐人新闻栏目

OpenAI Agents SDK 为 Collxn Daily Drop 的音乐人新闻栏目提供支持。

这项功能通过一个具备网页搜索能力的智能体,查找有关音乐人的近期文章或动态,并将这些背景信息加入每日邮件。新闻功能迅速成为测试版用户最喜爱的产品功能之一,因为它让唱片收藏体验与外界的最新动态保持联系。

最终,Ash 将 Collxn 迁移到了 Responses API,以推出“Ask This Drop”。这样一来,应用便能在对话工作流中支持多步推理,以及内置工具和自定义工具的调用。Collxn 在集成 Responses API 时,除了使用 16 个自定义工具来调用 Discogs API、查询用户的 Collxn 账户等,还使用内置的网页搜索工具在聊天中搜索音乐人新闻。

Collxn Daily Drop 的音乐人新闻栏目

Responses API 的网页搜索工具支持在 Collxn 的“Ask This Drop”中实时查询音乐人新闻。

Responses API 中的有状态对话也让多轮聊天交互的处理变得更简单、更快捷。总体而言,Ash 指出,相比搭建完整的检索增强生成(RAG)系统,使用 Responses API 简化了架构。

将屏幕录制转化为交互式产品演示

作者:Arcade 团队的 Nick Sorrentino 和 Pawel Wszola

工具: 计算机使用
模型: GPT-5.2、computer-use-preview

集成由 API 驱动的内容生成后,发布演示所需的步骤减少了 50%,显著提高了发布率和产品采用率。

Arcade 将大多数团队本就会做的屏幕录制,转化为精致的交互式产品演示。团队无需现场带人了解产品,也不必编写分步说明文档,只需录制一次工作流程,剩下的就交给 Arcade。

该平台会在后台分析录制内容,自动生成引导式演示,解释每一步正在进行的操作。

演示生成工作流程

录制过程中:

  1. 用户在执行工作流程的同时录制屏幕。
  2. 在桌面端或浏览器中,Arcade 会直接捕获点击、输入和滚动等结构化交互。
  3. 在移动端,由于 iOS 沙盒阻止应用捕获系统范围内的交互,用户改为录制应用的普通屏幕视频。
  4. 录制内容会发送到 OpenAI Responses API,由计算机使用工具分析视频画面,推断其中发生的交互。
  5. 系统将推断出的操作转换为结构化步骤。
  6. Arcade 生成解说文字和交互热点,引导观看者逐步体验演示。

这些步骤会自动转化为用户看到的交互式引导演示。

随后,结构化操作会传递给 Chat Completions API,由其生成演示各处的标题和热点说明。用户可以使用内置的 AI 编辑工具调整生成的文案,例如缩短或改写文本。

将演示制作工作量减半

自动生成演示解说,大幅减少了发布产品引导演示所需的工作量。

集成由 API 驱动的工作流程后:

  • 发布前所需操作次数的中位数下降了 50%
  • 操作次数的第 80 百分位数(P80)从约 230 次降至约 120 次
  • 发布率和产品采用率均有所提高

通过减少演示制作过程中的繁琐环节,Arcade 让团队能够更快地将原始录屏转化为精致的交互式演示。

衡量并提升品牌在 AI 输出中的可见度

作者:Hexagon 的 Tunde Adeyinka 和 Ramon Silva

使用的工具: 网页搜索
使用的模型: GPT-5.2 Chat

Tunde Adeyinka 和 Ramon Silva 创立了 Hexagon,旨在为零售商解答一个新问题: AI 助手如何介绍您的产品?

随着 AI 助手日益影响消费者发现产品的方式,Hexagon 帮助企业监测其品牌在 AI 生成的回答中的呈现情况,并持续改善表现。

该平台使用 OpenAI Responses API 为三大核心系统提供支持:

1. 回答模拟架构

Hexagon 每天运行模拟流水线,评估 AI 助手如何回答与产品相关的问题。系统每天生成数千条贴近真实场景的消费者提示、产品推荐提示和购物查询,然后将其发送至 Responses API。系统会分析返回的输出,追踪品牌在 AI 生成的回答中的曝光度。

零售商客户由此可以了解自己的产品出现的频率,以及这些回答随时间的变化。

Hexagon 回答模拟架构

2. 多智能体内容生成流水线

除了提供分析功能,Hexagon 还使用 Responses API 生成经过优化的内容,提升品牌在 AI 回答中的曝光度。

该系统采用四智能体架构,每个智能体负责流水线中的一个专门步骤,并将输出传递至下一阶段,直到最终内容生成并发布。智能体通过非确定性循环相互通信,在发布前对内容进行迭代优化。

Hexagon 多智能体内容生成流水线

3. 仪表板和客户工具

该平台还提供了“Hexi”,这是一个使用 Responses API 的函数调用功能构建的聊天机器人。客户可以通过与 Hexi 对话来探索分析结果,并自助生成其品牌在 AI 回答中曝光情况的数据摘要。Hexagon 通过面向零售商的仪表板展示分析结果,追踪产品在 AI 生成的回答中的呈现情况。

Hexagon 仪表板截图

Hexagon 利用 Responses API 的几项关键能力,让整个产品中的模拟更贴近真实情况、更具实用价值:

  • 网页搜索:模拟类似于 ChatGPT 启用浏览功能时生成的回答。
  • 用户位置参数:模拟来自不同地区的查询,以测试地域差异。
  • 推理强度:控制回答的深度和复杂度。
  • 最大输出 Token 数:限制长篇输出的回答长度。
  • 上下文持久化:在多次调用之间保留上下文,支持多智能体工作流。

Responses API 提供了更高的回答质量,以及更强的跨调用上下文持久化能力,这对支撑 Hexagon 平台的多步骤流水线至关重要。

结语

推出一年以来,Responses API 已成为开发者构建智能体软件的核心基础组件。

这五个开发者故事展示了它在实践中的应用:通过多智能体系统协调工具、检测缺陷、运行工作流,并交付由 AI 驱动的产品。

平台本身也在快速演进:编排能力不断提升,工具生态更加丰富,新增了支持网络访问的 OpenAI 托管容器和 Shell 工具等。

更多工具。
更多能力。
更多开发者正在打造我们其他人尚未想到的东西。

让我们看看开发者在第二年会打造出什么。