跳到主要内容

第 2.6.1 节：先判断哪些外部能力适合接入 MCP

进入实现之前，先围绕“先判断哪些外部能力适合接入 MCP”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出外部能力的适用场景、不适用场景、前置条件和进入工程实现的判断标准。

本章要解决什么问题​

第 1.6 章已经讲过 Tool Calling（工具调用）：模型在需要外部能力时，可以申请调用查订单、查政策、创建工单等工具。但真实企业项目很快会遇到第二个断层：工具越来越多，Agent（智能体）越来越多，团队不能为每个应用重复写一套工具接入方式。

在“企业客服知识库与工单 Agent 工作台”里，早期可能只有 3 个工具：

  • 查询订单状态。
  • 查询售后政策。
  • 创建客服工单。

但业务一扩展，工具数量会迅速增加：

  • 读取企业知识库。
  • 查询客户资料。
  • 查询历史工单。
  • 查询物流节点。
  • 创建投诉工单。
  • 发起退款审批。
  • 读取质检规则。
  • 生成客服主管复盘报表。
  • 对接 CRM（客户关系管理系统）、ERP（企业资源计划系统）、工单系统和数据看板。

如果每个 Agent 项目都自己维护工具列表、参数说明、权限规则、连接方式和日志格式，就会出现 5 个问题：

  • 重复开发：客服 Agent、质检 Agent、销售 Agent 都要重复接同一套系统。
  • 工具碎片化：同一个“查客户历史工单”能力在不同项目里名称、字段和返回格式都不一样。
  • 权限混乱：某些客户端能看到不该看到的工具，某些高风险动作没有审批。
  • 审计困难：出了问题之后，很难知道模型看到了哪些工具、调用了哪个服务、用了什么参数。
  • 生态难扩展：新增一个内部工具时，需要逐个改所有 Agent 应用。

MCP（模型上下文协议）要解决的不是“模型能不能调用一个工具”，而是：企业如何用一种更标准的方式，把工具、资源和上下文暴露给不同的 AI（人工智能）应用。

你可以先把它理解成一层“工具生态连接协议”：

  • Tool Calling 回答“模型如何申请使用工具”。
  • MCP 回答“工具如何被统一暴露、发现、连接和治理”。

本章不讲 MCP 的代码语法，不提供完整 MCP Server（模型上下文协议服务端）项目代码，也不写 Python（编程语言）、TypeScript（类型化脚本语言）或 JSON（结构化数据格式）代码块。本章要讲清：

  • MCP 和 Tool Calling 是什么关系。
  • MCP Server（模型上下文协议服务端）和 MCP Client（模型上下文协议客户端）分别负责什么。
  • 工具发现、资源暴露、权限边界和审计日志怎么设计。
  • 企业客服工作台里哪些能力适合进入 MCP 工具生态。
  • 哪些能力不适合使用 MCP。
  • 面试时如何把 MCP 讲成工程能力，而不是只背“AI 的 USB-C 接口”这个比喻。

学习目标​

学完本章后，读者应该能做到：

  • 用人话解释 MCP 解决什么问题。
  • 说清 MCP 与 Tool Calling 的关系和区别。
  • 区分 MCP Client（模型上下文协议客户端）、MCP Server（模型上下文协议服务端）、Tools（工具）、Resources（资源）和 Prompts（提示模板）的职责。
  • 画出客服 Agent 工作台接入 MCP 的系统流程图。
  • 判断哪些客服能力应该封装成 MCP Server（模型上下文协议服务端），哪些不应该。
  • 设计 MCP 工具发现结果、工具调用请求、工具返回结果和审计日志的字段契约。
  • 说明 MCP 项目里的权限边界、状态管理、审批和日志。
  • 识别 MCP 工具生态常见失败场景，并给出兜底方案。
  • 把本章内容连接到后续 MCP Server（模型上下文协议服务端）制作、MCP Client（模型上下文协议客户端）集成、安全权限、可观测性和作品集项目。
  • 回答面试官关于 MCP、企业工具生态、工具发现、越权调用和审计追踪的追问。

贯穿业务场景​

本章继续使用同一个贯穿项目：企业客服知识库与工单 Agent 工作台。

这个工作台面向客服、售后、运营和主管。它帮助团队完成 4 类任务：

任务类型用户问题或业务动作需要的能力MCP 的价值
知识问答“这类商品能退货吗？”读取售后政策、知识库、商品规则把知识库检索能力作为标准资源或工具暴露。
订单查询“我的订单什么时候发货？”查询订单、物流、支付状态让不同 Agent 复用同一个订单查询工具。
工单处理“帮我投诉物流。”创建工单、查询工单、更新状态统一工单工具的字段、权限、日志和审批。
管理复盘“本周有哪些高频投诉？”读取质检结果、聚合报表让主管工作台和分析 Agent 共享数据资源。

早期项目可以直接在客服 Agent 内部定义工具。但当系统变成企业工作台后，你会看到更复杂的连接关系：

  • 一个客服对话 Agent 要用订单工具、工单工具和知识库工具。
  • 一个客服主管 Agent 要用工单统计工具、质检规则资源和报表资源。
  • 一个售后审批 Agent 要用退款审批工具、订单校验工具和人工审批状态。
  • 一个内部运营 Agent 要用知识库编辑资源、公告发布流程和客户标签工具。

这些 Agent 不应该各自重复对接底层业务系统。更合理的做法是：

  • 把稳定、可复用、有清晰权限边界的能力封装到 MCP Server（模型上下文协议服务端）。
  • 由客服工作台、主管工作台或其他 AI 应用作为 MCP Client（模型上下文协议客户端）连接这些服务端。
  • 通过工具发现机制获得可用工具和资源说明。
  • 通过权限、审批和审计确保工具不会被滥用。

本章不是让你马上写出一个完整 MCP 平台，而是先建立工程判断：什么时候需要 MCP，MCP 在系统里放在哪里，它和原来的工具调用层如何协作。

新手为什么会卡住​

很多读者第一次听 MCP 时，会以为它只是“另一种调接口的方法”。这会导致理解偏差。

常见卡点问题在哪里正确理解
已经有 Tool Calling 了，为什么还要 MCP？把“调用工具”和“管理工具生态”混为一谈Tool Calling 偏调用机制，MCP 偏工具和上下文的标准连接方式。
MCP 是不是普通 API（应用程序接口）？只看到了工具背后的业务接口MCP 面向 AI 客户端，重点是工具发现、资源暴露、描述信息和上下文边界。
MCP Server（模型上下文协议服务端）是不是业务后端？误以为要把所有业务逻辑搬进去MCP Server（模型上下文协议服务端）通常是适配层和工具暴露层，底层仍然可以调用订单、工单、知识库等业务系统。
MCP Client（模型上下文协议客户端）是不是模型本身？混淆模型、Agent 应用和协议客户端MCP Client（模型上下文协议客户端）运行在 AI 应用侧，负责连接服务端、发现工具、发起调用。
工具发现是不是越多越好？模型看到太多工具会增加误用风险工具发现必须受权限、场景、角色和风险控制。
MCP 能不能自动解决安全问题？把协议当成安全产品MCP 提供连接标准，权限、审批、审计仍然要靠系统设计。
只要接入 MCP 就显得高级技术选型脱离业务单一应用、一次性工具、极高风险动作不一定适合 MCP。

本章的核心任务，就是把 MCP 从“热门名词”还原成可设计、可验收、可面试表达的工程层。

继续学习​