面经策

MCP 的工作流程是什么？ ​

  • 标签：大模型、AI、MCP、协议原理

🏛 业务架构师 ​

MCP 一次完整的工具调用流程：

  1. 连接初始化：Host 应用启动 MCP Client，与 Server 建立连接（本地 stdio 或远程 HTTP），双方交换 initialize 消息完成版本与能力协商。
  2. 能力发现：Client 请求 tools/list，Server 返回工具清单——名称、描述、参数 JSON Schema。这些描述会被注入模型上下文。
  3. 模型决策：用户提问后，模型结合工具描述判断是否需要调用工具，输出结构化的调用意图（工具名+参数）。
  4. 执行调用：Client 把请求发给 Server 的 tools/call；Server 执行真实操作（查库、发请求），期间可通过流式消息上报进度。鉴权在此环节强制执行。
  5. 结果回传：Server 返回结果（文本、结构化数据或资源引用），Client 把结果回填给模型作为"观察"，模型决定继续调用还是生成最终回答。

业务视角看关键控制点：第 3 步的"工具描述质量"直接决定模型选对工具的准确率——描述要写给模型看，像写产品说明书写清楚"什么时候用我"；第 4 步是企业加权限管控、审计埋点、限流的唯一闸口。做 MCP 治理时，这两处的投入回报最高。

🏗 系统架构师 ​

MCP 一次完整的工具调用闭环，我按消息序列讲：

  • 初始化握手：Host 启动/连接 Server（stdio 拉起子进程或 HTTP 连接）→ Client 发 initialize 请求（自己的协议版本与能力）→ Server 回应其能力 → Client 发 initialized 通知，协商完成；
  • 能力发现：Client 调 tools/list，拿到工具清单（name、description、inputSchema）→ Host 把这些工具定义注入 LLM 的请求上下文（与 System Prompt 一起），模型由此"知道有哪些能力"；
  • 推理决策：用户提问 → LLM 结合工具描述判断需要调用 → 输出结构化调用意图（toolUse: name + arguments）——这一步是模型层 Function Calling；
  • 执行：Host（可能弹用户授权确认）→ Client 发 tools/call 给 Server → Server 执行真实动作（查库/调 API）→ 返回 content（文本、JSON、图片）或 isError；
  • 结果回填：结果作为 tool message 回到 LLM 上下文 → 模型基于结果继续推理，可能再发起下一轮调用，直到产出最终回答。

架构师视角：这是一个 request/response 与流式混合的会话式协议——长任务有 progress 通知、可取消；生产要在两处加防护：授权确认（高危工具）与结果大小控制（超大返回先摘要再回填，否则上下文被打爆）。

💻 全栈开发专家 ​

以「用户在 Agent 里问数据库里有多少待发货订单」为例，完整流程：

  1. 初始化：Host 启动时与 MCP Server 握手（initialize），获取能力清单和工具列表（tools/list：query_orders、update_order…），工具的 JSON Schema 被缓存。
  2. 上下文组装：用户提问进来，Host 把系统提示 + 历史 + 工具定义（转成该模型的 FC 格式）发给 LLM。
  3. 模型决策：LLM 判断需要查库，返回结构化 tool call：query_orders(status="待发货", agg="count")——这一步模型只输出意图，不执行。
  4. 授权与执行：Host 按策略弹窗/静默放行，然后通过 MCP Client 调 Server 的 tools/call；Server 校验参数、执行 SQL、返回结构化结果。
  5. 结果回填：Host 把结果作为 tool result 消息追加进对话，再调 LLM。
  6. 循环终止：LLM 给出自然语言答案（或发起下一个 tool call），循环结束。
用户 → Host(LLM) --tool_call--> MCP Client --> MCP Server --> DB
用户 <--最终答案-- Host(LLM) <--tool_result-- MCP Client <-- MCP Server

排查经验：问题多出在第 3、4 步——工具描述含糊导致模型选错工具（改 docstring）；Server 报错信息直接透传给模型，好的错误消息能让模型自纠，别吞异常。