OGX Responses API 完全指南生产可用的 OpenAI 兼容服务端 Agent 编排【免费下载链接】ogxOpen GenAI Stack项目地址: https://gitcode.com/GitHub_Trending/ll/ogxOGXOpen GenAI Stack将 OpenAI 的 Responses API 作为最核心的 Agent 编排入口把模型调用 → 工具执行 → 结果回填 → 再次推理的 agentic 循环从客户端搬到服务端一次/v1/responses请求即可完成联网搜索、文件检索、函数调用与 MCP 工具接入。本文以仓库中标记为STABLE的 Responses API 稳定版说明 为主体结合 响应创建请求模型、Responses 协议定义、FastAPI 路由实现 与 OpenAI 兼容工具类型定义 等源码完整讲解其支持的四种工具、核心能力、完整端点与请求参数以及当前的已知限制与迁移路径。读完本文你将能够直接基于 OGX 的 Responses API 搭建支持 web search、file search、自定义函数与 MCP 服务器接入的生产级 Agent 服务。什么是 OGX 的 Responses APIOGX 采用 OpenAI-first 的设计取向主 API 面直接实现 OpenAI 规范任意 OpenAI 兼容客户端只需修改base_url即可接入见 OpenAI API 兼容性总览。Responses API 是其中最具特色的部分——它对应 OpenAI 的/v1/responses端点同时遵循 Open Responses 开放规范把 Agent 执行循环下沉到服务器端服务端执行工具调用模型决定调用哪个工具后由服务器执行并将结果自动回填给模型客户端无需编排循环服务端连接 MCP 服务器任意 Model Context Protocol 服务器都可以作为工具来源内置文件检索基于 Vector IO / vector store 的内置 RAG无需额外搭建检索管线服务端会话状态管理通过previous_response_id链式延续对话。在仓库的 API 状态分级中Responses API 被标记为✅ STABLE——production-ready with backward compatibility guarantees. Recommended for production applications生产可用、具备向后兼容保证、推荐用于生产应用。与之对应仓库中另有两份姊妹文档反映了 API 的演进脉络Agents API实验版处于预览阶段提供 agent 创建、会话threads、轮次turns、工具组与记忆等能力可能随反馈调整Deprecated APIs弃用版旧版 Agents / Responses API 仅作迁移参考将随版本移除官方迁移指引明确要求新项目一律迁移到稳定的 v1 Responses API。支持的四种工具类型STABLE 文档明确 Responses API 支持四类工具。这四种工具在 OpenAI 兼容工具类型定义 中均有对应的 Pydantic 模型并通过Field(discriminatortype)按type字段做联合类型判别。web_search联网搜索OpenAIResponseInputToolWebSearchsrc/ogx_api/openai_responses.py#L531-L544用于搜索互联网获取实时信息。type字段除web_search外还兼容多个 OpenAI 变体web_search_preview、web_search_preview_2025_03_11、web_search_2025_08_26并支持以下可选配置search_context_size搜索上下文规模取值为low/medium/highfilters.allowed_domains允许搜索的域名白名单WebSearchFiltersuser_location近似地理位置city、country、region、timezone用于按地域细化结果。在输出侧OGX 会为 web search 产生web_search_call类型的调用项并配套response.web_search_call.in_progress、response.web_search_call.searching、response.web_search_call.completed等流式事件同样定义于 openai_responses.py。file_search向量库文件检索OpenAIResponseInputToolFileSearchsrc/ogx_api/openai_responses.py#L565-L580用于在已上传的文件与 vector store 中检索核心特性vector_store_ids必填本次调用要检索的向量库 ID 列表支持每次调用动态指定无需预先绑定filters附加检索过滤条件max_num_results最大返回结果数默认10取值范围1-50ranking_options结果排序与评分选项FileSearchRankingOptions。输出侧对应file_search_call调用项与response.file_search_call.*系列流式事件openai_responses.py#L1521-L1559。这与 OpenAI 官方 file search 的使用模式保持一致一条请求即可完成上传文件 → 建库 → 检索问答的闭环例如response client.responses.create( modelllama-3.3-70b, input哪些文件提到了 Q4 业绩, tools[{ type: file_search, vector_store_ids: [vs_abc123], }], )functionJSON Schema 校验的自定义函数OpenAIResponseInputToolFunctionopenai_responses.py#L547-L562支持标准 function callingname函数名、description功能描述、parametersJSON Schema 参数定义、strict是否强制严格参数校验。其请求/响应模型与 OpenAI Chat Completions 的工具调用语义一致适合作为 Agent 与外部业务系统的对接点。mcp_toolModel Context Protocol 集成OpenAIResponseInputToolMCPopenai_responses.py#L603-L631是 OGX 的特色能力允许把任意 MCP 服务器直接作为工具源接入 Responses 请求。关键字段server_label必填标识该 MCP 服务器的标签connector_id或server_url二选一必填其一通过已注册的 connector 连接或直接指定 MCP 服务器 URL。模型校验器会强制要求二者至少提供一个否则抛出ValueErrorheaders连接服务器时的自定义 HTTP 头authorizationOAuth 访问令牌模型序列化时被排除不会泄露到输出require_approval工具调用的审批策略取always/never/ApprovalFilterApprovalFilter支持按always/never列出具体工具名默认neverallowed_tools限制本服务器上允许调用的工具清单tool_names。响应对象中的OpenAIResponseToolMCP只会回显server_label与allowed_tools避免暴露连接凭据——这也是输入工具与输出工具两类模型在 MCP 场景下的唯一差异见 openai_responses.py#L644-L665。核心字段与特性STABLE 文档概括了 Responses API 的四项核心能力以下结合请求模型源码逐一展开。动态配置按请求切换模型、向量库与工具CreateResponseRequestsrc/ogx_api/responses/models.py#L126-L272的model为必填字段tools为可选项每次请求都可以独立指定模型、工具列表与 vector store无需任何预先配置或注册流程。这种请求级装配让同一个服务实例可以同时服务多个业务场景。会话分支previous_response_idprevious_response_id字段允许基于某条历史响应继续对话从而在服务端维护会话状态客户端只需持有响应 ID 即可分叉出不同的对话路径。与之配合的字段还包括store默认true是否将响应持久化到数据库置为false时不落库conversation可选的会话 ID用于把响应挂载到既有会话context_management上下文管理配置type目前仅支持compaction配合compact_threshold触发压缩的 token 阈值可在上下文超限时自动压缩历史。富注解自动引用OGX 会自动为检索类结果生成引用注解annotations涵盖文件引用file citations、URL 引用与容器文件引用。include参数可以要求响应附带更多数据ResponseItemInclude枚举models.py#L33-L42例如web_search_call.action.sources、file_search_call.results、message.output_text.logprobs等不过注意据 Responses API 已知限制 记录部分 include 标志在底层尚未完全接线。状态跟踪工具调用状态与失败处理一次响应会经历多个状态阶段服务器通过 SSE 事件流把中间状态推送给客户端事件类型如response.created、response.in_progress、response.completed、response.output_item.added、response.output_item.done定义见 openai_responses.py#L914-L1032。工具调用的执行状态同样可追踪出现异常时可借助response.failed事件与流式错误事件OpenAIResponseObjectStreamError优雅处理而非让连接悬挂。端点与调用方式Responses API 的完整 REST 端点定义在 FastAPI 路由实现 中路由前缀为/v1OGX_API_V1协议接口本身定义在 Responses Protocol 中共七个方法方法与路径说明路由实现位置POST /v1/responses创建响应streamtrue时返回 SSE 流fastapi_routes.py#L389-L425GET /v1/responses/{response_id}按 ID 获取单条响应fastapi_routes.py#L378-L387GET /v1/responses分页列出响应after/limit/model/orderfastapi_routes.py#L427-L436GET /v1/responses/{response_id}/input_items列出某条响应的输入项支持分页与includefastapi_routes.py#L438-L450DELETE /v1/responses/{response_id}删除响应fastapi_routes.py#L452-L461POST /v1/responses/compact压缩会话历史alpha 状态fastapi_routes.py#L360-L376POST /v1/responses/{response_id}/cancel取消后台响应仅限backgroundtrue创建的任务fastapi_routes.py#L463-L479流式传输SSE 与 WebSocket尽管 STABLE 文档将完整的实时响应流式支持列为 WIP仓库源码实际上已经实现了两套流式通道反映该能力已进入落地阶段HTTP SSE 流POST /v1/responses中当实现返回AsyncIterator时路由会将其包装为media_typetext/event-stream的StreamingResponse。sse_generator负责把每个异步事件格式化为 SSE 帧并在中途出错时继续沿用递增的sequence_number发出error事件fastapi_routes.py#L113-L142WebSocket 通道WS /v1/responses逐帧接收response.create事件并把每个响应事件作为独立 JSON 文本帧回推。WebSocket 路径会剥离type/stream/stream_options/background字段并为storefalse的轮次维护连接级会话缓存使未落库的previous_response_id链路在同一条连接上仍然可以延续fastapi_routes.py#L229-L328。兼容 form-urlencoded路由类FormURLEncodedRoutefastapi_routes.py#L81-L110会在请求进入 FastAPI 解析前把application/x-www-form-urlencoded表单体转换为 JSON重复键聚合为列表从而让/v1/responses与/v1/responses/compact同时接受 JSON 与表单编码两种请求体便于 curl 等工具直接调试。创建响应请求的完整参数CreateResponseRequestmodels.py#L126-L272开放了extraallow允许携带规范之外的附加字段核心参数如下参数类型/默认值说明modelstr必填底层推理模型inputstr或list[OpenAIResponseInput]必填输入消息instructionsstr | None引导模型行为的系统指令skillslist[str] | None注入到上下文中的 SKILL.md 指令对应的技能 IDtoolslist[OpenAIResponseInputTool] | None可用工具上述四种类型tool_choiceOpenAIResponseInputToolChoice | None工具选择策略auto/required/none或强制指定某个 function / mcp / file_search / web_search对应 openai_responses.py#L668-L751 的多种 ToolChoice 模型parallel_tool_callsbool默认true是否允许并行工具调用previous_response_idstr | None基于历史响应延续/分支streambool默认false是否流式返回backgroundbool | None后台执行置true时立即返回statusqueued之后可通过 cancel 端点取消storebool默认true是否持久化响应temperaturefloat0.0-2.0采样温度top_pfloat0.0-1.0核采样参数frequency_penalty/presence_penaltyfloat-2.0-2.0频率/存在惩罚max_infer_itersint默认101最大推理迭代轮数服务端 agentic 循环上限max_tool_callsint | None1单次响应中内置工具可被调用的总次数上限max_output_tokensint | None16输出 token 上限reasoningOpenAIResponseReasoning | None推理强度配置部分 provider 可用见下文限制service_tierServiceTier | None服务层级metadatadict[str, str] | None附加到响应的元数据guardrailsbool | None是否通过配置的 moderation 端点启用内容审核附加字段memoryMemoryToolConfig | None基于 owner 维度的记忆检索enabled、owner_id、vector_store_id、max_num_results1-50、max_context_tokens、filters、ranking_optionsmodels.py#L80-L122safety_identifierstr | None与终端用户关联的稳定标识用于安全监控并随响应回显truncationResponseTruncation | None输入超过上下文窗口时的截断策略prompt_cache_keystr | None≤64 字符提示缓存读写键请求的input既可以是普通字符串也可以是结构化的输入项列表包含消息、函数调用、函数调用输出、检索调用等OpenAIResponseInput变体这与 OpenAI Responses 的输入语义保持一致。当前 WIP 清单与已知限制STABLE 文档明确列出以下尚未完全就绪的能力选择生产方案前应结合 Responses API 已知限制 与 一致性报告Responses 端点一致性约 96.4%综合评估完整实时流式支持如前所述SSE 与 WebSocket 通道在源码中已实现并可用但文档仍将其列为演进项使用时建议先在目标 provider 上验证tool_choice/max_tool_calls请求模型已支持这两个字段属于模型层已就绪、文档层仍标记 WIP的状态实际行为取决于底层 provider 实现内置工具code interpreter、containers API当前仅有 file search 与 web search 两类内置工具code interpreter 等尚缺失Moderation 与 guardrailsguardrails字段可传入请求但全局/用户级安全模型配置仍属功能请求阶段reasoning仅在输出 reasoning traces 的推理 provider如 vLLM上可用OpenAI 托管服务等其他 provider 不生效service_tier、logprobs、max_output_tokens、metadata、instructions、incomplete_details、background这些字段在请求模型中均已定义部分标注为 alpha 或兼容占位但完整语义仍在推进中。例如incomplete_details说明响应为何不完整如reasonmax_output_tokens目前尚未实现background字段已具备对应的后台创建与 cancel 端点能力。需要特别说明的是模型层已定义字段不等于所有 provider 均已完整实现。以reasoning为例其输出侧行为与推理 provider 强相关因此在选用上述 WIP 能力时建议以实际目标 provider 的验证结果为准。从旧版 Agents API 迁移仓库的 API 分层清晰地给出了迁移路径若你正在使用deprecated 版 Agents / Responses API弃用说明 要求迁移到stable v1 Responses API 端点即本文所述的/v1/responses若你在评估experimental Agents APIagent、threads、turns 语义请注意它仍在预览期、可能随反馈调整生产项目推荐优先采用稳定版 Responses API并关注仓库后续版本对 Agents API 稳定化的进展。迁移时只需保持base_url指向 OGX 服务如http://localhost:8321/v1并使用client.responses.create(...)风格调用即可享受服务端 agentic 循环、MCP 接入与内置文件检索等能力参考 OpenAI API 兼容性总览 中的示例。小结OGX Responses API 以 OpenAI 兼容规范为骨架把 agentic 执行循环、工具编排、会话状态与引用注解全部收敛到服务端四种工具类型web_search、file_search、function、mcp_tool覆盖了联网检索、向量库 RAG、自定义函数与 MCP 生态接入四类主流场景previous_response_id提供服务端会话分支SSE 与 WebSocket 双通道支持流式交互background与 cancel 端点支撑异步任务。对于追求生产稳定性的开发者STABLE 状态、96.4% 的一致性得分以及明确的 WIP 清单可以帮助你在能力与风险之间做出有依据的技术选型。若需进一步深入内部执行流程可参考 Responses API 内部流程文档 及 响应相关集成测试结合源码验证实际行为。【免费下载链接】ogxOpen GenAI Stack项目地址: https://gitcode.com/GitHub_Trending/ll/ogx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OGX Responses API 完全指南：生产可用的 OpenAI 兼容服务端 Agent 编排
OGX Responses API 完全指南生产可用的 OpenAI 兼容服务端 Agent 编排【免费下载链接】ogxOpen GenAI Stack项目地址: https://gitcode.com/GitHub_Trending/ll/ogxOGXOpen GenAI Stack将 OpenAI 的 Responses API 作为最核心的 Agent 编排入口把模型调用 → 工具执行 → 结果回填 → 再次推理的 agentic 循环从客户端搬到服务端一次/v1/responses请求即可完成联网搜索、文件检索、函数调用与 MCP 工具接入。本文以仓库中标记为STABLE的 Responses API 稳定版说明 为主体结合 响应创建请求模型、Responses 协议定义、FastAPI 路由实现 与 OpenAI 兼容工具类型定义 等源码完整讲解其支持的四种工具、核心能力、完整端点与请求参数以及当前的已知限制与迁移路径。读完本文你将能够直接基于 OGX 的 Responses API 搭建支持 web search、file search、自定义函数与 MCP 服务器接入的生产级 Agent 服务。什么是 OGX 的 Responses APIOGX 采用 OpenAI-first 的设计取向主 API 面直接实现 OpenAI 规范任意 OpenAI 兼容客户端只需修改base_url即可接入见 OpenAI API 兼容性总览。Responses API 是其中最具特色的部分——它对应 OpenAI 的/v1/responses端点同时遵循 Open Responses 开放规范把 Agent 执行循环下沉到服务器端服务端执行工具调用模型决定调用哪个工具后由服务器执行并将结果自动回填给模型客户端无需编排循环服务端连接 MCP 服务器任意 Model Context Protocol 服务器都可以作为工具来源内置文件检索基于 Vector IO / vector store 的内置 RAG无需额外搭建检索管线服务端会话状态管理通过previous_response_id链式延续对话。在仓库的 API 状态分级中Responses API 被标记为✅ STABLE——production-ready with backward compatibility guarantees. Recommended for production applications生产可用、具备向后兼容保证、推荐用于生产应用。与之对应仓库中另有两份姊妹文档反映了 API 的演进脉络Agents API实验版处于预览阶段提供 agent 创建、会话threads、轮次turns、工具组与记忆等能力可能随反馈调整Deprecated APIs弃用版旧版 Agents / Responses API 仅作迁移参考将随版本移除官方迁移指引明确要求新项目一律迁移到稳定的 v1 Responses API。支持的四种工具类型STABLE 文档明确 Responses API 支持四类工具。这四种工具在 OpenAI 兼容工具类型定义 中均有对应的 Pydantic 模型并通过Field(discriminatortype)按type字段做联合类型判别。web_search联网搜索OpenAIResponseInputToolWebSearchsrc/ogx_api/openai_responses.py#L531-L544用于搜索互联网获取实时信息。type字段除web_search外还兼容多个 OpenAI 变体web_search_preview、web_search_preview_2025_03_11、web_search_2025_08_26并支持以下可选配置search_context_size搜索上下文规模取值为low/medium/highfilters.allowed_domains允许搜索的域名白名单WebSearchFiltersuser_location近似地理位置city、country、region、timezone用于按地域细化结果。在输出侧OGX 会为 web search 产生web_search_call类型的调用项并配套response.web_search_call.in_progress、response.web_search_call.searching、response.web_search_call.completed等流式事件同样定义于 openai_responses.py。file_search向量库文件检索OpenAIResponseInputToolFileSearchsrc/ogx_api/openai_responses.py#L565-L580用于在已上传的文件与 vector store 中检索核心特性vector_store_ids必填本次调用要检索的向量库 ID 列表支持每次调用动态指定无需预先绑定filters附加检索过滤条件max_num_results最大返回结果数默认10取值范围1-50ranking_options结果排序与评分选项FileSearchRankingOptions。输出侧对应file_search_call调用项与response.file_search_call.*系列流式事件openai_responses.py#L1521-L1559。这与 OpenAI 官方 file search 的使用模式保持一致一条请求即可完成上传文件 → 建库 → 检索问答的闭环例如response client.responses.create( modelllama-3.3-70b, input哪些文件提到了 Q4 业绩, tools[{ type: file_search, vector_store_ids: [vs_abc123], }], )functionJSON Schema 校验的自定义函数OpenAIResponseInputToolFunctionopenai_responses.py#L547-L562支持标准 function callingname函数名、description功能描述、parametersJSON Schema 参数定义、strict是否强制严格参数校验。其请求/响应模型与 OpenAI Chat Completions 的工具调用语义一致适合作为 Agent 与外部业务系统的对接点。mcp_toolModel Context Protocol 集成OpenAIResponseInputToolMCPopenai_responses.py#L603-L631是 OGX 的特色能力允许把任意 MCP 服务器直接作为工具源接入 Responses 请求。关键字段server_label必填标识该 MCP 服务器的标签connector_id或server_url二选一必填其一通过已注册的 connector 连接或直接指定 MCP 服务器 URL。模型校验器会强制要求二者至少提供一个否则抛出ValueErrorheaders连接服务器时的自定义 HTTP 头authorizationOAuth 访问令牌模型序列化时被排除不会泄露到输出require_approval工具调用的审批策略取always/never/ApprovalFilterApprovalFilter支持按always/never列出具体工具名默认neverallowed_tools限制本服务器上允许调用的工具清单tool_names。响应对象中的OpenAIResponseToolMCP只会回显server_label与allowed_tools避免暴露连接凭据——这也是输入工具与输出工具两类模型在 MCP 场景下的唯一差异见 openai_responses.py#L644-L665。核心字段与特性STABLE 文档概括了 Responses API 的四项核心能力以下结合请求模型源码逐一展开。动态配置按请求切换模型、向量库与工具CreateResponseRequestsrc/ogx_api/responses/models.py#L126-L272的model为必填字段tools为可选项每次请求都可以独立指定模型、工具列表与 vector store无需任何预先配置或注册流程。这种请求级装配让同一个服务实例可以同时服务多个业务场景。会话分支previous_response_idprevious_response_id字段允许基于某条历史响应继续对话从而在服务端维护会话状态客户端只需持有响应 ID 即可分叉出不同的对话路径。与之配合的字段还包括store默认true是否将响应持久化到数据库置为false时不落库conversation可选的会话 ID用于把响应挂载到既有会话context_management上下文管理配置type目前仅支持compaction配合compact_threshold触发压缩的 token 阈值可在上下文超限时自动压缩历史。富注解自动引用OGX 会自动为检索类结果生成引用注解annotations涵盖文件引用file citations、URL 引用与容器文件引用。include参数可以要求响应附带更多数据ResponseItemInclude枚举models.py#L33-L42例如web_search_call.action.sources、file_search_call.results、message.output_text.logprobs等不过注意据 Responses API 已知限制 记录部分 include 标志在底层尚未完全接线。状态跟踪工具调用状态与失败处理一次响应会经历多个状态阶段服务器通过 SSE 事件流把中间状态推送给客户端事件类型如response.created、response.in_progress、response.completed、response.output_item.added、response.output_item.done定义见 openai_responses.py#L914-L1032。工具调用的执行状态同样可追踪出现异常时可借助response.failed事件与流式错误事件OpenAIResponseObjectStreamError优雅处理而非让连接悬挂。端点与调用方式Responses API 的完整 REST 端点定义在 FastAPI 路由实现 中路由前缀为/v1OGX_API_V1协议接口本身定义在 Responses Protocol 中共七个方法方法与路径说明路由实现位置POST /v1/responses创建响应streamtrue时返回 SSE 流fastapi_routes.py#L389-L425GET /v1/responses/{response_id}按 ID 获取单条响应fastapi_routes.py#L378-L387GET /v1/responses分页列出响应after/limit/model/orderfastapi_routes.py#L427-L436GET /v1/responses/{response_id}/input_items列出某条响应的输入项支持分页与includefastapi_routes.py#L438-L450DELETE /v1/responses/{response_id}删除响应fastapi_routes.py#L452-L461POST /v1/responses/compact压缩会话历史alpha 状态fastapi_routes.py#L360-L376POST /v1/responses/{response_id}/cancel取消后台响应仅限backgroundtrue创建的任务fastapi_routes.py#L463-L479流式传输SSE 与 WebSocket尽管 STABLE 文档将完整的实时响应流式支持列为 WIP仓库源码实际上已经实现了两套流式通道反映该能力已进入落地阶段HTTP SSE 流POST /v1/responses中当实现返回AsyncIterator时路由会将其包装为media_typetext/event-stream的StreamingResponse。sse_generator负责把每个异步事件格式化为 SSE 帧并在中途出错时继续沿用递增的sequence_number发出error事件fastapi_routes.py#L113-L142WebSocket 通道WS /v1/responses逐帧接收response.create事件并把每个响应事件作为独立 JSON 文本帧回推。WebSocket 路径会剥离type/stream/stream_options/background字段并为storefalse的轮次维护连接级会话缓存使未落库的previous_response_id链路在同一条连接上仍然可以延续fastapi_routes.py#L229-L328。兼容 form-urlencoded路由类FormURLEncodedRoutefastapi_routes.py#L81-L110会在请求进入 FastAPI 解析前把application/x-www-form-urlencoded表单体转换为 JSON重复键聚合为列表从而让/v1/responses与/v1/responses/compact同时接受 JSON 与表单编码两种请求体便于 curl 等工具直接调试。创建响应请求的完整参数CreateResponseRequestmodels.py#L126-L272开放了extraallow允许携带规范之外的附加字段核心参数如下参数类型/默认值说明modelstr必填底层推理模型inputstr或list[OpenAIResponseInput]必填输入消息instructionsstr | None引导模型行为的系统指令skillslist[str] | None注入到上下文中的 SKILL.md 指令对应的技能 IDtoolslist[OpenAIResponseInputTool] | None可用工具上述四种类型tool_choiceOpenAIResponseInputToolChoice | None工具选择策略auto/required/none或强制指定某个 function / mcp / file_search / web_search对应 openai_responses.py#L668-L751 的多种 ToolChoice 模型parallel_tool_callsbool默认true是否允许并行工具调用previous_response_idstr | None基于历史响应延续/分支streambool默认false是否流式返回backgroundbool | None后台执行置true时立即返回statusqueued之后可通过 cancel 端点取消storebool默认true是否持久化响应temperaturefloat0.0-2.0采样温度top_pfloat0.0-1.0核采样参数frequency_penalty/presence_penaltyfloat-2.0-2.0频率/存在惩罚max_infer_itersint默认101最大推理迭代轮数服务端 agentic 循环上限max_tool_callsint | None1单次响应中内置工具可被调用的总次数上限max_output_tokensint | None16输出 token 上限reasoningOpenAIResponseReasoning | None推理强度配置部分 provider 可用见下文限制service_tierServiceTier | None服务层级metadatadict[str, str] | None附加到响应的元数据guardrailsbool | None是否通过配置的 moderation 端点启用内容审核附加字段memoryMemoryToolConfig | None基于 owner 维度的记忆检索enabled、owner_id、vector_store_id、max_num_results1-50、max_context_tokens、filters、ranking_optionsmodels.py#L80-L122safety_identifierstr | None与终端用户关联的稳定标识用于安全监控并随响应回显truncationResponseTruncation | None输入超过上下文窗口时的截断策略prompt_cache_keystr | None≤64 字符提示缓存读写键请求的input既可以是普通字符串也可以是结构化的输入项列表包含消息、函数调用、函数调用输出、检索调用等OpenAIResponseInput变体这与 OpenAI Responses 的输入语义保持一致。当前 WIP 清单与已知限制STABLE 文档明确列出以下尚未完全就绪的能力选择生产方案前应结合 Responses API 已知限制 与 一致性报告Responses 端点一致性约 96.4%综合评估完整实时流式支持如前所述SSE 与 WebSocket 通道在源码中已实现并可用但文档仍将其列为演进项使用时建议先在目标 provider 上验证tool_choice/max_tool_calls请求模型已支持这两个字段属于模型层已就绪、文档层仍标记 WIP的状态实际行为取决于底层 provider 实现内置工具code interpreter、containers API当前仅有 file search 与 web search 两类内置工具code interpreter 等尚缺失Moderation 与 guardrailsguardrails字段可传入请求但全局/用户级安全模型配置仍属功能请求阶段reasoning仅在输出 reasoning traces 的推理 provider如 vLLM上可用OpenAI 托管服务等其他 provider 不生效service_tier、logprobs、max_output_tokens、metadata、instructions、incomplete_details、background这些字段在请求模型中均已定义部分标注为 alpha 或兼容占位但完整语义仍在推进中。例如incomplete_details说明响应为何不完整如reasonmax_output_tokens目前尚未实现background字段已具备对应的后台创建与 cancel 端点能力。需要特别说明的是模型层已定义字段不等于所有 provider 均已完整实现。以reasoning为例其输出侧行为与推理 provider 强相关因此在选用上述 WIP 能力时建议以实际目标 provider 的验证结果为准。从旧版 Agents API 迁移仓库的 API 分层清晰地给出了迁移路径若你正在使用deprecated 版 Agents / Responses API弃用说明 要求迁移到stable v1 Responses API 端点即本文所述的/v1/responses若你在评估experimental Agents APIagent、threads、turns 语义请注意它仍在预览期、可能随反馈调整生产项目推荐优先采用稳定版 Responses API并关注仓库后续版本对 Agents API 稳定化的进展。迁移时只需保持base_url指向 OGX 服务如http://localhost:8321/v1并使用client.responses.create(...)风格调用即可享受服务端 agentic 循环、MCP 接入与内置文件检索等能力参考 OpenAI API 兼容性总览 中的示例。小结OGX Responses API 以 OpenAI 兼容规范为骨架把 agentic 执行循环、工具编排、会话状态与引用注解全部收敛到服务端四种工具类型web_search、file_search、function、mcp_tool覆盖了联网检索、向量库 RAG、自定义函数与 MCP 生态接入四类主流场景previous_response_id提供服务端会话分支SSE 与 WebSocket 双通道支持流式交互background与 cancel 端点支撑异步任务。对于追求生产稳定性的开发者STABLE 状态、96.4% 的一致性得分以及明确的 WIP 清单可以帮助你在能力与风险之间做出有依据的技术选型。若需进一步深入内部执行流程可参考 Responses API 内部流程文档 及 响应相关集成测试结合源码验证实际行为。【免费下载链接】ogxOpen GenAI Stack项目地址: https://gitcode.com/GitHub_Trending/ll/ogx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考