Skip to content

同步管道

同步管道端到端处理非流式 Requests API 调用。它是 GodeX 两条执行路径中较简单的一条:向上游提供者发送单个请求,将响应重建为 OpenAI Responses 格式,验证输出契约,持久化会话,并返回完整的 ResponseObject。理解同步管道是理解更复杂的流式管道的基础。

概览

关注点组件关键文件
管道编排器SyncRequestPipelinesync-request-pipeline.ts:28
上游调用 + 重建 + web search 循环HostedWebSearchSyncRunnerweb-search/sync-runner.ts:31
提供者交换ProviderExchangeprovider-exchange.ts:39
桥接接口ResponsesBridgebridge.ts:7
运行时装配ResponsesBridgeRuntimeruntime.ts:19
会话持久化saveResponseSessionresponse-session-persistence.ts:5

管道步骤

SyncRequestPipeline.request (sync-request-pipeline.ts:34) 将上游调用、重建和 web search 循环委托给 HostedWebSearchSyncRunner,然后对结果 ResponseObject 运行五个后处理步骤:

步骤操作关键代码
1上游调用 + 重建 + web search 循环new HostedWebSearchSyncRunner(exchange).request(ctx)
2验证输出契约validateResponseOutputContract(...)
3记录追踪使用量recordTraceUsage(ctx, response.usage)
4记录完成日志ctx.logger.info("responses.request.completed")
5记录诊断日志logDiagnostics(ctx, ...)
6保存响应会话saveResponseSession(...)

上游调用与 Web 搜索循环

HostedWebSearchSyncRunner (web-search/sync-runner.ts:31) 拥有以前是管道直接关注的一切:上游交换、重建和托管 web search 续接循环。其 request(ctx) 方法 (web-search/sync-runner.ts:34) 最多迭代 config.max_iterations 次:

  1. 调用 exchange.request(ctx) 构建提供者请求并调用上游。
  2. 通过 reconstructResponseObject(...) (web-search/sync-runner.ts:43) 重建响应。
  3. 检查是否存在托管的 web_search 函数调用。如果不存在,返回响应(前缀为先前的 hostedItems)。如果存在,执行搜索,记录 web_search_call 项,并构建续接请求进行下一轮。

提供者交换

ProviderExchange (provider-exchange.ts:39) 封装了与上游提供者的交互。对于同步请求:

  1. 构建请求buildProviderRequest(ctx, false) 构建提供者特定的聊天补全请求,包括工具规划和输出契约设置 (provider-exchange.ts:103)
  2. Patch 并追踪请求:provider edge 应用 patchRequest,随后 onPatchedRequest 将最终 patched provider 请求写入 trace_requests,并记录一个不携带 body 的 provider.request.prepared 生命周期事件
  3. 调用上游:等待 ctx.provider.request(providerRequest) -- patch 之后的实际 HTTP 调用
  4. 追踪响应:记录同步 provider 响应体
  5. 返回:同时提供原始响应和构建的请求元数据

交换还记录工具决策诊断 (provider-exchange.ts:146) 并在上下文中设置输出契约槽 (provider-exchange.ts:131)。

响应重建

在 runner 内部,reconstructResponseObject (web-search/sync-runner.ts:43) 使用以下参数调用:

参数来源
requestIdctx.requestId
responseIdctx.responseId
createdAtctx.createdAt
completedAtMath.floor(Date.now() / 1000)
providerctx.provider.name
modelctx.resolved.model
providerResponse原始提供者响应
accessorctx.provider.spec.response
toolIdentity构建的工具声明
outputContract构建的输出契约计划
echo来自 responseRequestEchoFields 的请求回显字段

回显字段 (response-request-echo.ts:4) 将选定的请求参数镜像回响应对象,包括 instructionstemperaturetoolstool_choice 等许多其他参数。

输出契约验证

重建后,validateResponseOutputContract 检查输出是否满足规划的契约。这在 json_schema 被降级为 json_object 时尤为重要:requiresValidJson 标志会触发对输出文本的 JSON.parse。完整的验证逻辑请参见 Output Contracts

会话持久化

saveResponseSession (response-session-persistence.ts:5) 在 ctx.request.store !== false 时存储响应会话。存储的会话包括:

部分字段
会话元数据idprevious_response_idcreated_atcompleted_atstatus
请求快照inputinstructionsmodeltoolstool_choicereasoningtexttruncation
响应快照idoutputoutput_textusageerrorincomplete_details

会话保存错误会被捕获并以 warn 级别记录,永远不会导致请求失败 (sync-request-pipeline.ts:53)。

运行时装配

ResponsesBridgeRuntime (runtime.ts:19) 创建一个共享的 ProviderExchange 实例,并将其连接到 SyncRequestPipelineStreamPipeline。它实现了 ResponsesBridge 接口:

日志与可观测性

同步管道在关键节点发出结构化日志事件:

事件级别上下文
provider.request.sendingdebugprovider, model, stream=false
provider.response.receiveddebugprovider, model, upstreamDurationMillis
responses.request.completedinfostatus, model, outputCount, durationMillis, usage, cacheHitRatio
session.save.errorwarnrequest_id, response_id, error

追踪记录会把最终 patched 请求体写入 trace_requests,把不携带 body 的 provider.request.prepared 生命周期事件写入 trace_events,通过 provider.response.body 记录同步响应体,并通过 recordTraceUsage 记录使用量指标。

交叉引用

参考