OpenAI 推出 Responses API 与 Agents SDK
工具、追踪和多 Agent 交接进入统一开发栈
OpenAI 发布 Responses API、内置网页搜索、文件搜索和计算机使用工具,并开源 Agents SDK 管理工具、交接、护栏和追踪。
一个 Agent 演示通常从问题开始,以答案结束。生产系统却活在中间:模型要求搜索,应用执行搜索,把结果送回去;模型再要求读文件,应用检查权限;某一步超时,循环要重试;任务转交给另一个 Agent,日志要说明上下文去了哪里。回答只有几行,支撑回答的胶水代码却可能长成整个后端。
2025 年 3 月 11 日,OpenAI 发布 Responses API,并开源 Agents SDK。Responses API 把文本响应与工具调用放进统一接口,同时提供网页搜索、文件搜索和计算机使用等内置工具。Agents SDK 位于应用侧,把 Agent、Handoff、Guardrail 与 Tracing 做成可组合的开发原语。两者一起出现,但职责不同:一个是平台接口,一个是编排库。这组发布最值得注意的地方,不是又多了几个“智能体”,而是那些过去被称为胶水的工作第一次成为正式产品表面。交接不再只是把一段文本塞进另一个提示;它有了可命名的对象。追踪不再是出事故后临时补日志;它被放进默认开发栈。护栏也不再只是一句“请不要做危险操作”,而要在工具调用前后决定哪些输入和输出可以继续流动。
正式命名并不会自动带来可靠性。Handoff 传太少,接手者会失忆;传太多,敏感信息和无关上下文一起扩散。Guardrail 写得过窄会漏,写得过宽会让任务无法完成。Tracing 可以记录调用,却不能替团队决定谁有权限看日志、日志保留多久、一次失败应该由模型、工具还是应用负责。多 Agent 的拓扑越热闹,这些问题越容易被藏在箭头下面。
发布同时指向从 Assistants API 迁移的新路线。先前被 Assistant、Thread 与 Run 承担的托管状态,需要在 Responses 和应用编排中重新分配。迁移提醒开发者:平台愿意替应用托管多少状态,并不是永远固定的技术常数,而会随着产品方向改变。抽象层提供便利,也会在词汇和对象变化时留下改造成本。
Responses API 与 Agents SDK 因而记录了一次重心移动。模型能力仍然重要,但一个 Agent 产品能否连续运行,越来越取决于工具失败时怎样恢复、交接是否可追踪、权限是否能收紧。发布标题把胶水代码请上了台;真正的考验,是事故发生时,这套运行时能不能把人带回那一处断点。
An agent demo usually begins with a request and ends with an answer. A production system lives in between. The model asks for a search; the application performs it and returns the result. The model asks to read a file; the application checks permission. One step times out and the loop must recover. Work moves to another agent and the logs must explain which context crossed the boundary. The visible answer may be a few lines. The glue behind it can become the backend.
On 11 March 2025, OpenAI released the Responses API and open-sourced the Agents SDK. The Responses API placed text and tool calls in a unified interface and offered built-in tools including web search, file search, and computer use. The Agents SDK operated on the application side, turning agents, handoffs, guardrails, and tracing into composable primitives. The two arrived together but served different jobs: one was a platform interface; the other was an orchestration library. The notable change was not simply that developers could draw more agents. Work previously dismissed as glue became a formal product surface. A handoff no longer had to mean stuffing a string into another prompt; it had a named abstraction. Tracing was presented as part of the stack rather than an emergency logging project after an incident. A guardrail could no longer be reduced to “please do nothing dangerous”; it had to decide what input or output was allowed to continue around a tool call.
Names do not create reliability. A handoff that carries too little context produces amnesia; one that carries too much spreads secrets and noise. A narrow guardrail misses danger, while an over-broad one prevents useful work. Tracing can record calls but cannot decide who may inspect the trace, how long it should remain, or whether a failure belongs to the model, the tool, or the application. The busier a multi-agent diagram becomes, the easier it is to bury those decisions beneath arrows.
The release also set a migration direction away from the Assistants API. State previously organized around Assistants, Threads, and Runs had to be placed again across Responses and application orchestration. That migration made a larger point: how much state a platform chooses to host is not a permanent technical constant. It moves with product strategy. An abstraction delivers convenience and later creates work when its nouns and object boundaries change.
The Responses API and Agents SDK therefore mark a shift in where engineering attention lands. Model ability still matters, but an agent product's continuity increasingly depends on recovery after tool failure, traceable handoffs, and permissions that can be narrowed. The launch brought glue code onto the stage. Its real test begins when an incident occurs and the runtime either leads an engineer to the broken step—or leaves another fluent answer with no accountable path behind it.
展开完整事件档案人物、主题、模型与产品
- 人物
- —
- 模型
- —
- 产品
- responses-apiagents-sdk