← 返回概念解读

Concept Fable精修版

OpenAI 响应 API

OpenAI Responses API · Managed model and agent API

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

新柜台把文字、图片、工具和格式都接到一张回执上

城中有个总柜台,过去客人要办事,得分别去问书吏、画师、查卷人和跑腿。每个窗口说法不同,回执也不同。简单差事还能忍,连环差事就容易散。

掌柜们最怕这类请求:先读信,再查旧卷,再画草图,再请跑腿送出。客人要在窗口间来回搬话,一处漏了,上一步的结果就接不上下一步。最后没人说得清哪一步失败。

新总柜台把各路手艺接到同一张办事单上。客人只交一次请求,柜台按需要请书吏、查卷人、画师或跑腿参与;每一步结果都留在同一份回执里。

最初有人担心总柜台太复杂。第一版也确实乱过:画师拿到的说明缺了尺寸,跑腿收到半截地址,查卷人不知道前一步为什么要查那卷。管事便规定每次办事要写清用了哪些手艺、哪步失败、还能不能继续、是否需要客人补材料。

后来连环差事不再散成一堆零碎纸条。柜台可以接文字、图样和其他材料,也能把结果按约定格式交回。需要外部手艺时,它会记录调用和回执;不能继续时,也能说明卡在何处。

有个客人带来破损货物画像、投诉信和合同页。过去要跑三处窗口,现在总柜台先读信,再查合同,再比画像,最后生成一张可追踪的处理单。客人不必反复重讲。

总柜台的价值,不在替代所有工匠,而在给多种能力一个统一入口和连续上下文。复杂请求从此能被组织成一条可追踪的办事流。

后来总柜台还统一了回执样式。无论请了书吏、画师还是跑腿,客人都能看到同一条办事线:收了什么、做了什么、产出什么、缺了什么。过去散落的窗口,终于变成一张能追踪的桌面。后来管事还规定,回执不能只写成功,也要写清哪些材料参与了结果。

揭示

这个故事讲的是:OpenAI 响应 API

OpenAI Responses API 是统一的模型与 Agent 式工作流接口,支持模型响应、工具调用、多模态输入、结构化输出和内置工具等能力。它减少了开发者在 chat、tools、vision、JSON 输出之间拼接的成本,但企业仍需要处理权限、评测、重试、成本和数据治理。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 许多柜台:分散的 chat、vision、tools、structured output 接口
  • 混合请求:多模态输入、工具调用和格式约束共存的企业任务
  • 胶水规矩:应用层脆弱的接口拼接代码
  • 统一回执柜台:Responses API
  • 输入项目和输出格式:input items、response、structured outputs
  • 工具在同一链里声明:built-in tools 与 tool calling
  • 仍要设计流程:权限、错误处理、校验、预算和评测
  • 最后洞察:Responses API 把模型、工具、多模态和结构化响应收敛到更统一的执行接口

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

responseinput itemstool callingstructured outputsmultimodalbuilt-in tools