第 2.6.2 节：区分工具生态和 MCP 协议各自负责什么
先从整体看工具生态和 MCP 协议，梳理组成模块和各自职责。完成本节后，你应该能够用对比表判断工具生态和 MCP 协议的适用条件、职责边界和取舍理由。
核心概念
这一节用“四层解释法”讲 MCP（模型上下文协议）的关键概念。每个概念都按 4 层理解：人话解释、项目位置、工程动作、面试说法。
MCP（模型上下文协议）
| 层级 | 解释 |
|---|---|
| 人话解释 | MCP 是一套让 AI（人工智能）应用连接外部工具、资源和上下文的开放协议。它不是让模型“凭空更聪明”，而是让模型应用更标准地接入外部系统。 |
| 项目位置 | 在客服工作台中，MCP 位于 Agent（智能体）应用和企业系统之间。客服 Agent 通过 MCP 发现订单查询、工单创建、知识库读取等能力。 |
| 工程动作 | 你要设计哪些能力作为 MCP Server（模型上下文协议服务端）暴露，哪些客户端可以连接，工具描述怎么写，资源如何读取，权限和日志如何记录。 |
| 面试说法 | MCP 解决的是 Agent 工具生态标准化问题。它让不同 AI 应用用一致方式发现和调用工具，但权限、审批、审计仍然要由工程系统保证。 |
MCP 最容易被误解成“插件市场”。这个理解不够准确。插件市场强调分发，MCP 强调连接协议和上下文暴露方式。它可以支撑工具生态，但它本身不是业务规则、权限系统或审计平台的替代品。
MCP（模型上下文协议）与 Tool Calling（工具调用）
| 层级 | 解释 |
|---|---|
| 人话解释 | Tool Calling（工具调用）像是“模型要使用工具时如何提出请求”；MCP 像是“工具如何被统一摆到模型应用面前”。 |
| 项目位置 | 第 1.6 章的客服工具可以先直接接入 Agent。当这些工具要被多个工作台复用时，就可以把它们整理成 MCP Server（模型上下文协议服务端）。 |
| 工程动作 | 先把工具调用的字段、权限、错误和日志设计好，再决定哪些工具适合通过 MCP 暴露。不要反过来为了 MCP 而制造工具。 |
| 面试说法 | Tool Calling 和 MCP 不是二选一。MCP 发现和暴露工具，模型侧仍然可能通过工具调用机制发起具体调用。 |
可以用一个客服例子理解：
| 问题 | Tool Calling 关心什么 | MCP 关心什么 |
|---|---|---|
| 用户问“我的订单到哪里了？” | 模型是否需要调用查订单工具、参数是否完整、工具结果如何回到回答里 | 查订单工具由哪个 MCP Server（模型上下文协议服务端）提供、客户端如何发现它、当前用户是否有权看到它 |
| 用户说“帮我建投诉工单” | 是否需要用户确认、是否幂等、返回工单号 | 工单工具如何被多个 Agent 复用，哪些客户端能调用写入工具，调用日志如何统一 |
| 主管问“本周投诉高频问题是什么？” | 是否调用统计工具或读取报表 | 报表资源和质检资源如何作为标准资源暴露给主管工作台 |
一句话总结：Tool Calling 是动作发生的机制，MCP 是工具和上下文进入生态的标准入口。
MCP Client（模型上下文协议客户端）
| 层级 | 解释 |
|---|---|
| 人话解释 | MCP Client（模型上下文协议客户端）是 AI 应用里负责连接 MCP Server（模型上下文协议服务端）的一侧。它不是用户看到的聊天框，也不是模型本身，而是连接协议的客户端组件。 |
| 项目位置 | 客服工作台、主管工作台、售后审批工作台都可以内置 MCP Client（模型上下文协议客户端）。它们根据当前用户角色连接允许访问的 MCP Server（模型上下文协议服务端）。 |
| 工程动作 | MCP Client（模型上下文协议客户端）要完成连接、工具发现、资源读取、调用发起、超时处理、权限上下文传递和日志关联。 |
| 面试说法 | 我会把 MCP Client（模型上下文协议客户端）看成 Agent 应用的工具连接层，它负责把服务端暴露的工具转成当前 Agent 可用的受控能力。 |
在客服工作台里，MCP Client（模型上下文协议客户端）至少要知道：
- 当前用户是谁。
- 当前用户是普通客户、客服、主管还是运营。
- 当前对话属于哪个租户、店铺或业务线。
- 当前场景允许看到哪些工具。
- 哪些工具需要用户确认或人工审批。
- 每次工具调用要绑定哪个 trace_id（追踪编号）。
如果这些上下文没有传递清楚，MCP Client（模型上下文协议客户端）就可能发现过多工具，或者把没有权限的请求发给服务端。
MCP Server（模型上下文协议服务端）
| 层级 | 解释 |
|---|---|
| 人话解释 | MCP Server（模型上下文协议服务端）是把外部工具、资源和上下文暴露给 AI 应用的一侧。它后面可以连接数据库、业务 API（应用程序接口）、文件系统、知识库或内部服务。 |
| 项目位置 | 客服项目可以拆出订单 MCP Server（模型上下文协议服务端）、工单 MCP Server（模型上下文协议服务端）、知识库 MCP Server（模型上下文协议服务端）和报表 MCP Server（模型上下文协议服务端）。 |
| 工程动作 | MCP Server（模型上下文协议服务端）要定义可发现工具、资源读取方式、输入输出契约、权限校验、错误返回、调用日志和版本说明。 |
| 面试说法 | MCP Server（模型上下文协议服务端）不是把业务系统裸露给模型，而是在业务系统外面加一层面向 Agent 的安全适配层。 |
不要把 MCP Server（模型上下文协议服务端）设计成“万能服务端”。企业里更推荐按业务域拆分：
| 服务端 | 负责能力 | 不应该负责什么 |
|---|---|---|
| 知识库 MCP Server（模型上下文协议服务端） | 检索政策、读取文档、返回来源 | 不直接修改订单或创建工单。 |
| 订单 MCP Server（模型上下文协议服务端） | 查询订单状态、物流、售后资格 | 不直接退款，不暴露他人订单。 |
| 工单 MCP Server（模型上下文协议服务端） | 创建工单、查询工单、追加备注 | 不绕过用户确认，不自动关闭投诉。 |
| 审批 MCP Server（模型上下文协议服务端） | 发起审批、查询审批状态 | 不直接执行资金动作。 |
| 报表 MCP Server（模型上下文协议服务端） | 读取统计报表、质检结果 | 不暴露单个用户敏感资料。 |
这种拆分会让权限、日志和验收更清晰。
Tools（工具）
| 层级 | 解释 |
|---|---|
| 人话解释 | Tools（工具）是 MCP Server（模型上下文协议服务端）暴露出来的可执行动作，例如查询订单、创建工单、发起审批。 |
| 项目位置 | 客服 Agent 发现“查询订单状态”工具后，才能在用户询问订单时申请调用它。 |
| 工程动作 | 每个工具要有名称、用途说明、输入字段、输出字段、风险等级、权限条件、错误状态和审计字段。 |
| 面试说法 | MCP 里的工具不是普通接口清单，而是面向模型应用的受控动作，需要清晰描述和治理。 |
工具应该按业务动作拆小，而不是做成一个“客服万能工具”。原因很简单：工具越大，权限越难控，日志越难解释，测试越难覆盖。
Resources（资源）
| 层级 | 解释 |
|---|---|
| 人话解释 | Resources（资源）是 MCP Server（模型上下文协议服务端）提供给客户端读取的上下文资料，例如政策文档、知识库片段、数据库记录、报表页面或配置说明。 |
| 项目位置 | 客服工作台可以通过资源读取售后政策文档、质检规则、工单分类说明和知识库资料来源。 |
| 工程动作 | 资源要定义唯一标识、可读范围、更新版本、敏感级别、缓存策略和引用方式。 |
| 面试说法 | 工具偏动作，资源偏上下文。企业 Agent 既需要会做事，也需要读到可信资料来源。 |
资源不是“随便把文件丢给模型”。在客服工作台里，资源至少要回答：
- 这个资源属于哪个业务域。
- 当前用户是否有权读取。
- 它是不是最新版本。
- 它能不能被模型引用给用户。
- 它是否包含敏感信息。
- 读取记录是否需要进入审计日志。
Prompts（提示模板）
| 层级 | 解释 |
|---|---|
| 人话解释 | Prompts（提示模板）是服务端提供的可复用提示或任务模板，帮助客户端按统一方式使用某类工具或资源。 |
| 项目位置 | 工单 MCP Server（模型上下文协议服务端）可以提供“投诉摘要模板”，知识库 MCP Server（模型上下文协议服务端）可以提供“政策解释模板”。 |
| 工程动作 | 提示模板要说明适用场景、输入变量、输出要求、风险提醒和版本。 |
| 面试说法 | Prompts（提示模板）让企业经验可以被复用，但不能代替工具权限和业务规则。 |
本章重点是工具和资源，提示模板只要先知道它是 MCP 生态的一部分即可。
工具发现
| 层级 | 解释 |
|---|---|
| 人话解释 | 工具发现就是 MCP Client（模型上下文协议客户端）连接服务端后，知道“这里有哪些工具、每个工具做什么、需要什么输入、当前能不能用”。 |
| 项目位置 | 客服 Agent 登录后，只应该发现自己有权使用的客服工具。主管工作台可以发现统计报表工具，但普通客户不应该看到内部质检工具。 |
| 工程动作 | 工具发现要结合角色、租户、场景、风险等级和开关状态，不能把所有工具无差别暴露给所有客户端。 |
| 面试说法 | 工具发现是 MCP 的关键价值之一，但它必须和权限白名单、工具说明质量、版本控制和审计绑定。 |
工具发现不是“把所有工具列出来”。真正的企业工具发现要回答 4 个问题：
- 发现给谁：当前客户端、角色、租户是谁。
- 发现什么：哪些工具、资源、提示模板可见。
- 如何描述：工具用途、输入字段、输出结果、风险等级是否清楚。
- 如何追踪：客户端看到的工具版本和后续调用是否能关联。
权限边界与审计
| 层级 | 解释 |
|---|---|
| 人话解释 | 权限边界决定谁能看到和调用哪些工具，审计决定每次发现、调用、失败和审批都能被追踪。 |
| 项目位置 | 客服工作台必须保证客户只能查自己的订单，客服只能处理授权队列，主管才能看汇总报表，资金动作必须进入审批。 |
| 工程动作 | 要设计身份校验、对象归属校验、工具白名单、风险分级、审批状态、调用日志、错误日志和 trace_id（追踪编号）。 |
| 面试说法 | MCP 提高了工具复用能力，也会放大越权风险，所以工程重点是最小权限、可审计和高风险人工确认。 |
一个成熟回答应该强调：MCP 不是安全魔法。它让工具更容易被连接，也意味着错误暴露会影响更多客户端。越是标准化，越要重视权限和审计。
本章在客服 Agent（智能体）工作台中的位置
把客服工作台拆成 7 层，本章关注第 4 层和第 5 层的连接关系。
| 层级 | 作用 | 本章关注点 |
|---|---|---|
| 用户入口层 | 客户、客服、主管发起问题或操作 | 判断当前用户、角色和业务场景。 |
| Agent 决策层 | 判断是否需要回答、检索、工具、审批或人工 | 决定是否需要可用工具和资源。 |
| Tool Calling 层 | 把模型意图转成受控工具调用 | 第 1.6 章重点，本章继续复用。 |
| MCP Client（模型上下文协议客户端）层 | 连接服务端、发现工具、发起调用 | 本章核心。 |
| MCP Server（模型上下文协议服务端）层 | 暴露工具、资源和提示模板 | 本章核心。 |
| 企业系统层 | 订单、工单、知识库、CRM（客户关系管理系统）、审批、报表 | 被 MCP Server（模型上下文协议服务端）安全适配。 |
| 治理与审计层 | 权限、状态、日志、告警、人工确认 | 本章核心。 |
在这个位置上，MCP 不是替代 Agent 决策层，也不是替代业务系统。它更像一个企业工具生态连接层：
- 上接 Agent 应用。
- 下接企业系统。
- 横向统一工具描述、发现、权限和审计。
如果没有 MCP 或类似的工具生态层，每个 Agent 都要重复对接底层系统，后期会越来越难维护。
系统流程图
下面的流程图展示客服工作台使用 MCP 的完整链路。
读图重点：先看上组的需求判断：本地工具能处理就走 Tool Calling；否则进入下组的 MCP 发现与会话过滤。只读资源、只读工具和写入动作分流处理，最终都留下 trace_id 后再回答。
这个流程图里最重要的不是“连接成功”，而是 4 个治理节点：
- 工具发现前要知道用户身份、角色、租户和场景。
- 工具发现后要过滤可见能力，不是所有工具都给模型看。
- 工具调用前要校验权限、风险、审批和幂等。
- 工具结果必须进入审计日志，再交给 Agent 组织回答。
模块拆分
客服工作台接入 MCP 后，可以按下面方式拆模块。
| 模块 | 主要职责 | 关键设计点 |
|---|---|---|
| MCP Client（模型上下文协议客户端） Adapter（适配器） | 在客服工作台内连接 MCP Server（模型上下文协议服务端） | 连接管理、超时、重试、工具发现缓存、上下文传递。 |
| Tool（工具） Discovery Filter（工具发现过滤器） | 决定当前用户能看到哪些工具 | 角色、租户、业务线、场景、风险等级、开关状态。 |
| Tool（工具） Registry View（工具注册视图） | 展示客户端可用工具清单 | 工具名称、说明、版本、风险、是否需要审批。 |
| Resource Access Adapter（适配器） | 读取知识库、政策、报表等资源 | 资源权限、版本、引用、缓存、敏感信息过滤。 |
| Order MCP Server（模型上下文协议服务端） | 暴露订单查询、物流查询、售后资格判断 | 订单归属校验、只读限制、异常状态。 |
| Ticket MCP Server（模型上下文协议服务端） | 暴露工单创建、查询、追加备注 | 用户确认、幂等、分派队列、写入审计。 |
| Knowledge MCP Server（模型上下文协议服务端） | 暴露政策检索、知识资源读取 | 文档版本、引用来源、过期提示。 |
| Approval MCP Server（模型上下文协议服务端） | 暴露发起审批、查询审批状态 | 高风险动作只发起审批，不直接执行资金变化。 |
| Audit Logger（审计日志模块） | 记录发现、调用、返回、失败、审批 | trace_id（追踪编号）、工具版本、输入摘要、输出摘要。 |
| Fallback Router（兜底路由） | 处理失败、超时、无权限和人工接管 | 追问、重试、转人工、降级回答。 |
这个拆法不是让读者现在就实现所有模块，而是建立模块边界。面试或项目说明里，你能讲清这些模块，就比只说“我接了 MCP”更有说服力。
第一批推荐 MCP Server（模型上下文协议服务端）
| MCP Server（模型上下文协议服务端） | 推荐优先级 | 原因 | 风险等级 |
|---|---|---|---|
| 知识库 MCP Server（模型上下文协议服务端） | 高 | 只读为主，复用价值高，适合多个 Agent 使用 | 中 |
| 订单 MCP Server（模型上下文协议服务端） | 高 | 客服高频需求，字段稳定 | 中 |
| 工单 MCP Server（模型上下文协议服务端） | 高 | 连接真实业务动作，作品集价值强 | 中高 |
| 报表 MCP Server（模型上下文协议服务端） | 中 | 主管场景明显，但要控制数据范围 | 中 |
| 审批 MCP Server（模型上下文协议服务端） | 中 | 能体现高风险治理，但不能直接执行资金动作 | 高 |
| 客户标签 MCP Server（模型上下文协议服务端） | 低 | 容易涉及隐私和画像误用，后置处理 | 高 |
先做只读和中风险工具，再做写入和审批工具，是更稳的路线。