OpenAI Responses API 如何组合远程 MCP 工具：审批边界与错误处理

把远程 MCP 工具接进 Responses API 后，最容易出问题的地方不是工具列表能不能显示，而是模型提出工具调用时，应用是否仍然握着审批权，以及拒绝、超时、服务端错误能不能被分开处理。下面用一个最小的 Go 调用骨架说明这条边界。

远程 MCP 只负责提供工具能力，是否允许本次调用、把什么结果交回模型，应该由应用自己的审批策略决定；不要把“工具已声明”当成“工具可直接执行”。

先看清 Responses API 与远程 MCP 的边界

OpenAI 将 Responses API 设计成可以组合内置工具、函数调用和远程 MCP 服务器的统一接口。对应用来说，至少有三层对象：请求侧的 Responses API、提供工具描述与执行入口的远程 MCP 服务器，以及最终拥有业务权限的审批策略。

这三层不要揉成一个“智能代理”对象。工具描述解决“能做什么”，审批策略解决“这一次能不能做”，错误归属则回答“失败发生在哪一层”。分开后，日志和回滚才有落点。

工具声明不应越过业务审批

下面的示例只展示请求结构与决策位置，不执行真实远程工具。实际项目中，服务器地址、授权方式和允许的工具名应从服务端配置注入，不能从用户输入直接拼接。

type ApprovalDecision string

const (
    Allow ApprovalDecision = "allow"
    Deny  ApprovalDecision = "deny"
    Ask   ApprovalDecision = "ask"
)

type ApprovalPolicy interface {
    Decide(toolName string, args map[string]any) ApprovalDecision
}

// 请求中声明远程 MCP；工具是否真正执行，仍由应用审批层决定。
response, err := client.Responses.New(ctx, responses.ResponseNewParams{
    Model: "gpt-5",
    Tools: []responses.ToolParamUnion{
        responses.ToolParamOfMcp("https://mcp.example.com/server"),
    },
    Input: "查询本周的库存异常",
})

这里的关键不是某个 SDK 方法名，而是数据归属：模型输出工具调用请求后，应用先读取工具名和参数，再交给 ApprovalPolicy。允许才进入执行适配器，拒绝则返回可解释的拒绝信息，等待确认则保持业务会话状态。

用结果类型区分允许、拒绝和服务端失败

把所有异常都写成“调用失败”会让排查失去方向。审批拒绝是业务决定，远程 MCP 返回错误是依赖失败，Responses API 自身的错误则属于模型接口层；三者的处理动作并不一样。

decision := policy.Decide(toolName, args)
switch decision {
case Allow:
    result, err := mcpClient.Call(ctx, toolName, args)
    if err != nil {
        return fmt.Errorf("mcp tool %s failed: %w", toolName, err)
    }
    return result, nil
case Deny:
    return ToolResult{Kind: "denied", Message: "当前操作未获业务授权"}, nil
case Ask:
    return ToolResult{Kind: "approval_required", Message: "需要人工确认后继续"}, nil
default:
    return ToolResult{Kind: "invalid_policy", Message: "审批策略返回未知结果"}, nil
}

日志至少保留工具名、请求关联 ID、审批结果和错误类型；参数要按敏感字段规则脱敏。不要把远程服务器返回的原始错误直接当成用户提示，也不要在重试时绕过审批层。

性能检查放在边界内，而不是盲目重试

如果一次请求包含多个远程工具，延迟通常来自网络往返、服务器排队和结果回传。先分别记录这些边界的耗时，再决定是否缓存只读数据、缩短工具输出，或改用后台任务。对于写操作，重试前必须确认工具是否幂等；不确定时宁可返回待确认状态。

• Responses API 错误：检查请求参数、模型可用性和 response_id。
• 远程 MCP 错误：检查服务器健康、工具名和授权范围。
• 审批拒绝：回到业务规则，不要把它当作网络问题重试。

常见问题

远程 MCP 工具出现在请求里，就一定会被模型调用吗？

不一定。工具只是可用能力，模型可能不选择它；即使产生工具调用，也应经过应用自己的审批和执行边界。

审批拒绝后应该重新发送同一个请求吗？

通常不应自动重发。先把拒绝原因转成会话可理解的结果，等业务状态或人工确认发生变化后再创建新的受控请求。

远程 MCP 超时可以直接重试吗？

只读、幂等且仍在授权范围内的调用可以按退避策略重试；写操作要先确认远端是否已经接收，避免重复变更。

把边界写进代码评审清单

评审这类集成时，重点看四件事：工具来源是否固定且可审计，审批策略是否独立，错误是否按层分类，敏感结果是否经过过滤。只要这四点能在代码和日志中找到对应位置，远程 MCP 才算真正接入了应用，而不是把一个外部入口直接交给模型。