如果你已经做过函数调用（function calling），但一上复杂流程就开始写一堆胶水代码，那你差不多到了该用 Responses API + MCP 的阶段。

这篇不讲空概念，直接给你一个可落地的路线：把“模型调用工具”升级成“可扩展 Agent 工作流”，让检索、执行、校验、回写变成标准流程。

一句话结论

  • Function Calling 适合单次工具调用。
  • Responses API + MCP 适合多工具、多步骤、有状态的任务编排。
  • 你真正需要的不是更强的 prompt，而是更稳定的“工具层协议 + 工作流结构”。

一、先把边界说清楚：Function Calling vs MCP

Function Calling 的典型问题

你会很快遇到这几个坑：

  1. 工具注册分散在业务代码里，项目一大就难维护。
  2. 跨工具协作（比如先查文档再改配置再回写）要自己手搓状态机。
  3. 工具权限和可观测性不统一，排障靠猜。

MCP 解决的核心点

MCP（Model Context Protocol）不是“又一个 SDK”，它本质上是工具层标准化：

  • 工具发现：模型知道有什么工具可用
  • 工具调用：统一输入输出结构
  • 工具隔离：权限边界更清晰
  • 可观测性：每一步调用可追踪

二、最小可用架构（MVP）

建议你从这个三层结构起步：

  1. Orchestrator：你的业务入口（比如一个任务执行器）
  2. Model Layer：Responses API 负责推理与决策
  3. Tool Layer：通过 MCP 暴露检索、读写、执行类工具

流程示意：

  • 用户任务进入 Orchestrator
  • 模型先拆解任务，再选择工具
  • MCP 工具返回结构化结果
  • 模型基于结果继续下一步或给结论

三、一个可复制的调用骨架

下面是简化版伪代码（重点看结构，不纠结 SDK 细节）：

from openai import OpenAI

client = OpenAI()

tools = [
  {
    "type": "mcp",
    "server_label": "docs",
    "server_url": "http://127.0.0.1:8080/mcp"
  },
  {
    "type": "mcp",
    "server_label": "ops",
    "server_url": "http://127.0.0.1:8081/mcp"
  }
]

resp = client.responses.create(
  model="gpt-5",
  input="定位昨晚部署失败原因，并给出修复步骤",
  tools=tools
)

print(resp.output_text)

一个更稳的做法是把“执行前确认”做成硬规则：

POLICY = {
  "dangerous_actions_require_approval": True,
  "readonly_tools_default": True,
  "max_tool_hops": 8
}

四、排障与质量控制（这部分最容易被忽略）

1) 让工具输出结构化 JSON

不要返回一坨自然语言，至少保证：

{
  "status": "ok",
  "data": {},
  "error": null,
  "trace_id": "..."
}

这样模型才能稳定地进行下一步决策，而不是“猜你的返回格式”。

2) 给每个工具加超时和重试

# 伪配置示例
TOOL_TIMEOUT_MS=8000
TOOL_MAX_RETRY=2
TOOL_RETRY_BACKOFF_MS=300

3) 记录可回放日志

至少记录：

  • 输入任务
  • 模型中间决策摘要
  • 每次 MCP 调用入参与出参
  • 最终输出

没有回放日志，线上问题基本等于玄学。

五、常见误区

误区 1：把 MCP 当“万能插件系统”

MCP 是协议层，不会替你做业务建模。工具设计烂，协议再标准也救不回来。

误区 2：工具越多越强

错。工具太多会拉低决策稳定性。先做 3-5 个高价值工具，跑顺再扩。

误区 3：只看首轮效果，不看长任务稳定性

你应该盯的是：

  • 多步任务完成率
  • 工具调用失败率
  • 平均调用 hops
  • 人工接管率

六、最小落地清单（可直接照着做）

  1. 先选一个单场景（例如“发布故障定位”）。
  2. 只接 3 个 MCP 工具：日志检索、配置读取、执行建议。
  3. Responses API 做任务拆解和工具路由。
  4. 加审批闸门（高风险动作必须人确认）。
  5. 跑 1 周日志，按失败路径迭代。

这套做完，你的 Agent 才算从“能演示”升级到“能上线”。

总结

Responses API 负责“脑子”，MCP 负责“手脚”，工作流负责“规矩”。

三者拆开你会很痛苦，组合起来才是生产可用的 Agent 架构。

如果你正在从 function calling 迁移，建议按“单场景 MVP → 指标化 → 扩工具”这条路径走，别一上来就全家桶。