从提示词到产品：Responses 一周年

一年前，我们推出了 Responses API —— 一个供开发者和企业构建有用且可靠的智能体的基础。为模型配备一组托管工具，使 AI 从聊天助手演变为可以代表你采取行动的系统。如今，Responses API 支持多种工具来驱动智能体工作流，并提供了一套专为使用更强大模型构建而设计的新功能和原语。

如今，成千上万的开发者正在使用 Responses API 构建应用，以加速 客户支持、法律、生命科学、旅游 等各行各业的生产力提升。在分享了许多来自这些行业的成功故事之后，今天我们将庆祝五个较少被讲述的故事，讲述过去一年中在 Responses API 上构建应用的开发者们。

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

作者：Alexis Gauba 和 Ben Hylak，来自 Raindrop AI

工具：自定义构建的工具
模型：GPT-5.2（测试 GPT-5.4）

Raindrop 是全球最具雄心的 AI 公司背后的监控平台，用于在其智能体于生产环境中失控时及时发现。随着智能体变得越来越复杂，这些故障也变得越来越关键。

如果没有 Responses API，构建这类监控系统将会困难得多，可靠性也会差很多。

该系统使用 Responses API（通过 Vercel AI SDK）运行后台分析，以便在不同模型提供商之间共享工具，并使其系统在各种环境中保持可移植性。这些工作流会呈现异常行为。当出现问题时，系统会提醒开发者并协助诊断根本原因。

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

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

这些系统共同使团队能够在 AI 智能体影响生产系统之前发现、跟踪并修复问题。

监控架构

该架构使团队能够持续监控智能体行为，并在问题发生时快速响应。

1. 智能体行为监控

系统持续评估智能体行为，以确定智能体是否按预期运行。

开发者可以为不良结果设置条件，当满足这些条件时，平台可以发出警报。

2. 故障检测与告警

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

该平台提供以下工具：

• 跟踪不同智能体版本之间的行为变化
• 识别是哪个提示词或系统更改触发了故障
• 检查推理轨迹和工具调用

这使开发者能够快速识别故障的根本原因并部署修复。

3. 调查与调试工具

Raindrop 还提供帮助开发者诊断智能体工作流中问题的工具。这些功能使团队能够建立故障检测与系统改进之间的联系。

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

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

作者：Eric Provencher，来自 Repo Prompt

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

与其让推理模型在规划或审查时浪费其上下文窗口来导航上下文，我们利用一个单独的代理提前整理上下文，从而让我们的推理模型尽可能将其推理能力用于解决我们的任务。

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

Repo Prompt 专注于上下文工程——自动收集、组织和构建相关信息，以便推理模型能够有效地对其进行分析。

虽然许多代理系统专注于收集数据，但 Eric 的架构将上下文收集与深度推理分离开来。系统使用代理工作流来组装相关上下文，然后将这些整理好的信息交给专注于分析的推理模型。

该平台使用 OpenAI Responses API 来编排长时间运行的代理工作流和推理任务，包括：

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

该系统围绕三个核心组件构建：上下文构建代理工作流、深度推理模型（“Oracle”工作流）以及迭代研究和分析循环。

1. 上下文构建代理工作流

系统的第一阶段是上下文构建代理。该工作流分析大型数据仓库，以确定哪些信息与给定查询相关。

借助 Responses API 的工具和模型推理，代理识别相关文件、文档之间的关系以及关键信息部分。

该阶段的输出是一个结构化的上下文包，它成为推理阶段的输入。

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

与上下文构建代理不同，“Oracle”模型（深度推理模型）不执行工具调用或额外的信息检索。相反，它完全专注于分析提供给它的整理好的上下文。

通过将研究和推理分开，模型可以将其全部推理能力用于理解问题。在许多工作流中，推理阶段可以运行很长时间，分析所提供上下文中的复杂关系。

3. 迭代研究和分析循环

该系统还支持迭代推理循环。在推理模型产生输出后，另一个代理可以审查结果并确定是否需要进一步调查。

如果需要，系统会启动另一个上下文收集和推理周期。这个循环使得长时间的调查成为可能，系统在其中逐步完善其分析。

迭代工作流

该系统依赖于 Responses API 的多项功能：

• 后台作业：运行可执行数分钟或数小时的长时间推理任务
• 代理编排：协调用于上下文收集、推理和验证的代理循环
• 可观测性：在长时间运行的推理工作流执行时对其进行监控和管理

该平台使用 Codex 模型来收集和构建相关上下文，然后将这些整理好的上下文交给能力更强的推理模型进行更深入的分析。这些功能使该平台能够实现结合代理工作流与深度推理模型的混合架构。

一个面向黑胶唱片收藏家的对话式界面

作者：Ash Ryan Arnwine，来自 Collxn

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

与构建完整的检索增强生成（RAG）系统等替代方案相比，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 为 Collxn 用户提供了一个与黑胶唱片互动的聊天界面。

收藏者只需提问，即可获得基于实时 Discogs 数据并结合其个人唱片收藏上下文生成的答案。

这种方法将静态的唱片收藏转变为一种与更广泛音乐生态相连的对话式体验。

Daily Drop 与艺术家新闻

Collxn 还使用 OpenAI Agents SDK 为 Daily Drop 邮件中介绍的艺术家生成“近期新闻”板块。

OpenAI Agents SDK 为 Collxn Daily Drop 的艺术家新闻板块提供支持。

该功能部署了一个由网络搜索驱动的智能体，用于查找关于该艺术家的近期文章或动态，并将这些上下文添加到每日邮件中。在测试用户中，新闻功能很快成为该产品最受欢迎的部分之一，因为它以动态的方式将唱片收藏体验与外部世界联系起来。

最终，Ash 将 Collxn 迁移到 Responses API，以推出“Ask This Drop”。通过这种方式，应用能够在对话式工作流中支持多步推理以及内置和自定义的工具调用。Collxn 的 Responses API 实现除了使用 16 个自定义工具来处理 Discogs API、查询用户的 Collxn 账户等之外，还使用内置的网络搜索工具在聊天中进行艺术家新闻搜索。

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. 录制内容会连同 computer-use 工具一起发送到 OpenAI Responses API，该 API 分析视觉帧并推断出发生的交互。
5. 系统将这些推断出的操作转换为结构化步骤。
6. Arcade 生成叙述文本和交互热点，引导观众完成演示。

这些步骤会自动成为用户看到的交互式讲解。

随后，结构化操作被传递给 Chat Completions API，由其生成贯穿演示的标题和热点描述。用户可以使用内置的 AI 编辑工具调整生成的文案，例如缩短或重写文本。

将演示创建时间减半

自动化演示叙述显著减少了发布产品讲解所需的工作量。

在集成 API 驱动的工作流程后：

• 发布前所需操作的中位数下降了 50%
• P80 操作数从约 230 降至约 120
• 发布率和产品采用率均有所提升

通过消除演示创建过程中的障碍，Arcade 让团队能够更快地将原始录制内容转化为精美的交互式演示。

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

作者：Tunde Adeyinka 和 Ramon Silva，来自 Hexagon

所用工具： 网络搜索
所用模型： GPT-5.2 Chat

Tunde Adeyinka 和 Ramon Silva 创立了 Hexagon，旨在回答零售商面临的一个新问题：AI 助手如何谈论你的产品？

随着 AI 助手日益影响产品发现，Hexagon 帮助企业监测其品牌在 AI 生成答案中的呈现方式，并持续改进这些结果。

该平台使用 OpenAI Responses API 来驱动三个核心系统：

1. 响应模拟架构

Hexagon 运行每日模拟流程，以衡量 AI 助手如何回答产品相关问题。每天，系统会生成数千个真实的消费者提示、产品推荐提示和购物查询，然后通过 Responses API 发送。返回的输出会被分析，以追踪品牌在 AI 生成答案中的可见度。

零售客户随后可以看到其产品出现的频率，以及这些答案随时间的变化情况。

2. 多智能体内容生成流程

除了分析之外，Hexagon 还使用 Responses API 生成优化内容，以提升品牌在 AI 答案中的可见度。

该系统采用四智能体架构，每个智能体在流程中执行一个专门步骤，并将输出传递给下一阶段，直至最终内容生成并发布。智能体通过非确定性循环进行通信，以便在发布前进行迭代优化。

3. 仪表板和客户工具

该平台还包含“Hexi”，这是一个通过 Responses API 使用函数调用构建的聊天机器人。借助 Hexi，客户可以以对话方式探索分析数据，并以自助方式生成其 AI 可见性数据的摘要。Hexagon 通过一个零售商仪表板呈现其分析数据，该仪表板可追踪产品在 AI 生成答案中的呈现情况。

Hexagon 依赖 Responses API 的几项关键功能，使其模拟在其产品中既真实又实用：

• 网页搜索：复制类似 ChatGPT 的启用浏览功能的响应。
• 用户位置参数：模拟来自不同地区的查询，以测试地理差异。
• 推理力度：控制响应的深度和复杂性。
• 最大输出令牌：限制长篇输出的响应长度。
• 上下文持久性：在多次调用间保持上下文，支持多智能体工作流。

Responses API 提供了更好的响应质量和跨多次调用更强的上下文持久性，这对于驱动 Hexagon 平台的多步骤流程至关重要。

总结

一年过去了，Responses API 已成为开发者构建智能体软件的核心构建块。

这五个开发者故事展示了实际应用中的例子：多智能体系统协调工具、检测缺陷、运行工作流，以及发布由 AI 驱动的产品。

该平台本身正在快速发展——具备更好的编排能力和更丰富的工具生态系统，新增功能包括 OpenAI 托管容器（支持网络功能）和shell 工具。

更多工具。
更多能力。
更多开发者构建出我们其他人尚未想到的东西。

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