第 2.7.2 节：让 MCP Client 稳定发现、调用和兜底工具
MCP Client只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够按顺序说明 MCP Client 的触发、处理、复核、记录和兜底步骤。
核心概念四层解释法
这一节继续使用“四层解释法”：人话解释、项目位置、工程动作、面试说法。它不是为了背概念，而是让读者能把概念放回真实项目。
MCP Server（模型上下文协议服务端）
| 层级 | 解释 |
|---|---|
| 人话解释 | MCP Server（模型上下文协议服务端）是把某个业务域的工具、资源和提示模板整理出来，按协议提供给 AI（人工智能）应用的一侧。它不是模型，也不是完整业务系统，而是面向 Agent（智能体）的能力适配层。 |
| 项目位置 | 在客服工作台里，政策、订单、工单、客户资料都可以分别做成 MCP Server（模型上下文协议服务端）。例如订单服务端暴露 get_order，工单服务端暴露 create_ticket。 |
| 工程动作 | 服务端要定义 server_id（服务端编号）、工具卡、资源卡、提示模板、输入输出契约、权限范围、传输模式、错误状态、版本和审计字段。 |
| 面试说法 | MCP Server（模型上下文协议服务端）负责暴露能力，但不意味着所有客户端或所有会话都能使用这些能力。它要把工具暴露得清楚、安全、可追踪。 |
一个好的 MCP Server（模型上下文协议服务端）不是“把接口包装一层”。它要把底层业务能力改造成适合 Agent 理解和调用的形式。例如 get_order 不应该返回数据库原始字段，而应该返回“订单状态、物流摘要、是否可售后、数据来源、风险提示、工具执行状态”等 Agent 能安全使用的结果。
MCP Client（模型上下文协议客户端）
| 层级 | 解释 |
|---|---|
| 人话解释 | MCP Client（模型上下文协议客户端）是 AI 应用里负责连接服务端、发现能力、筛选工具、发起调用和处理结果的一侧。它不是聊天界面，也不是大模型本身，而是工作台里的协议连接和治理组件。 |
| 项目位置 | 客服 Agent 工作台内置 MCP Client（模型上下文协议客户端）。它根据当前登录用户、角色、会话状态和任务类型，连接政策、订单、工单、客户资料服务端。 |
| 工程动作 | 客户端要维护 client_id（客户端编号）、允许连接的服务端、工具白名单、会话级工具列表、auth_context（认证上下文）、超时、重试、审批、结果回传和审计日志。 |
| 面试说法 | MCP Client（模型上下文协议客户端）不是被动转发工具调用。它要决定当前会话哪些工具可见、哪些需要确认、哪些必须拒绝，并把工具结果安全交回 Agent。 |
本章反复强调：Server 暴露工具，Client 决定哪些工具在当前会话可用。
举个例子：客户 MCP Server（模型上下文协议服务端）可能暴露 get_customer_profile。但当前会话如果是普通客户自助咨询，MCP Client（模型上下文协议客户端）不一定把这个工具交给模型；如果是一线客服处理已登录客户工单，客户端可以给出“客户资料摘要”级别的只读工具；如果是主管复盘，客户端可能只允许读取聚合数据，而不是单个客户隐私。
tool card（工具卡）
| 层级 | 解释 |
|---|---|
| 人话解释 | tool card（工具卡）是一个工具的说明书。它告诉客户端和模型：工具叫什么、解决什么问题、需要什么输入、会返回什么、风险是什么、是否需要审批。 |
| 项目位置 | search_policy、get_order、create_ticket、get_customer_profile 都需要工具卡。工具卡由服务端提供，客户端再按当前会话筛选。 |
| 工程动作 | 工具卡至少包含 tool_name（工具名称）、tool_description（工具描述）、input_contract（输入契约）、output_contract（输出契约）、permission_scope（权限范围）、risk_level（风险等级）、approval_required（是否需要审批）和审计要求。 |
| 面试说法 | 工具卡不是展示文案，而是工具治理契约。描述写不好，模型容易误选工具；风险和权限写不清，企业系统就不可控。 |
工具卡要写给两类对象看：一类是模型和 Agent 编排层，用来判断什么时候申请工具；另一类是工程系统和审计人员，用来判断这个工具是否被正确暴露和调用。
resource card（资源卡）
| 层级 | 解释 |
|---|---|
| 人话解释 | resource card（资源卡）是资源的说明书。它说明某个资源在哪里、代表什么、谁能读取、是否敏感、能不能被引用给用户。 |
| 项目位置 | 售后政策文档、工单分类说明、客户资料摘要、质检规则、处理时效说明都可以用资源卡描述。 |
| 工程动作 | 资源卡至少包含 resource_uri（资源地址）、资源名称、业务域、版本、权限范围、敏感级别、缓存策略、引用规则和审计要求。 |
| 面试说法 | MCP（模型上下文协议）不只暴露工具，也暴露资源。资源卡能让 Agent 读取可信上下文，但资源读取必须受权限和审计控制。 |
资源和工具的区别很重要。工具偏动作，资源偏上下文。search_policy 是工具，因为它执行搜索；“售后政策 2026 版”是资源，因为它是被读取和引用的资料。一个服务端可以同时提供工具和资源，但权限策略可能不同。
prompt template（提示模板）
| 层级 | 解释 |
|---|---|
| 人话解释 | prompt template（提示模板）是可复用的任务提示结构，用来约束 Agent 如何解释政策、总结投诉、创建工单前确认用户诉求。 |
| 项目位置 | 工单 MCP Server（模型上下文协议服务端）可以提供“工单摘要模板”，政策 MCP Server（模型上下文协议服务端）可以提供“政策解释模板”，客户 MCP Server（模型上下文协议服务端）可以提供“敏感信息脱敏提示模板”。 |
| 工程动作 | 提示模板要定义 prompt_name（提示模板名称）、适用场景、输入变量、输出要求、禁止事项、版本、风险提醒和审计策略。 |
| 面试说法 | 提示模板复用的是业务表达经验，不是安全边界。它可以降低不同客户端输出风格不一致的问题，但不能替代工具权限和人工审批。 |
提示模板适合放在服务端的一种情况是：某个业务域有稳定的表达规范。例如政策解释必须引用资料来源、投诉摘要必须包含事实和诉求、创建工单前必须让用户确认。这些模板放在服务端，可以让多个客户端复用同一套业务表达。
auth（认证授权）
| 层级 | 解释 |
|---|---|
| 人话解释 | auth（认证授权）解决“你是谁、你能看什么、你能做什么”。 |
| 项目位置 | 客服工作台调用 get_order 前，要确认当前用户身份、订单归属、客户端权限和工具权限。客服查看 get_customer_profile 前，还要确认客服是否正在处理该客户工单。 |
| 工程动作 | 设计 auth_context（认证上下文），包含用户身份、角色、租户、会话、业务对象、授权来源、过期时间和权限范围。服务端和客户端都要参与校验。 |
| 面试说法 | MCP 接入不能只靠提示词约束。客户端要传递认证上下文，服务端要校验权限，模型只能看到过滤后的工具和资源。 |
认证和授权要分开理解。认证回答“这个请求来自谁”；授权回答“这个人或客户端能不能做这件事”。一个已登录客户可以查自己的订单，但不能查别人订单；一个客服可以查看正在处理客户的资料摘要，但不能随意搜索所有客户隐私。
audit（审计）
| 层级 | 解释 |
|---|---|
| 人话解释 | audit（审计）是把关键动作记录下来，出问题时能回答“谁在什么时候看到了什么工具、调用了什么、结果如何”。 |
| 项目位置 | 客服工作台每次工具发现、工具筛选、调用成功、调用失败、权限拒绝、人工审批都应该生成或关联 audit_trace_id（审计追踪编号）。 |
| 工程动作 | 审计日志要记录 client_id（客户端编号）、server_id（服务端编号）、工具名称、资源地址、认证上下文摘要、输入摘要、输出摘要、风险等级、审批状态、耗时和错误原因。 |
| 面试说法 | 企业 MCP 不是只要能调用成功，还要能复盘。没有审计，越权、误调、重复写入和模型编造都很难追责。 |
审计不是把所有敏感数据复制一份。审计日志要记录可复盘的摘要，避免写入完整隐私、密钥、API Key（接口密钥）和客户敏感原文。
transport_mode（传输模式）
| 层级 | 解释 |
|---|---|
| 人话解释 | transport_mode（传输模式）说明客户端和服务端怎么连接。常见选择包括本地 stdio（标准输入输出）和远程 HTTP（超文本传输协议）。 |
| 项目位置 | 本地开发或桌面自动化可以用 stdio；企业客服工作台多人共享订单、工单、客户资料服务时，更常见的是远程 HTTP（超文本传输协议）或企业内网服务。 |
| 工程动作 | 传输模式会影响鉴权、部署、超时、限流、审计、网络安全和故障兜底。不能只看“哪个更容易跑起来”。 |
| 面试说法 | 本地 stdio 适合个人工具和开发环境，远程 HTTP（超文本传输协议）适合团队共享和企业服务，但远程模式必须补鉴权、限流、审计和高可用设计。 |
传输模式不是实现细节，而是架构边界。一个只在本机读取文件的小工具，和一个远程查询客户资料的企业工具，风险完全不同。
本章在客服工作台中的位置
把客服 Agent 工作台拆开看，本章位于“工具生态制作层”。
| 层级 | 作用 | 本章关注点 |
|---|---|---|
| 用户入口层 | 客户、客服、主管在工作台里发起问题 | 提供当前用户、角色和会话信息 |
| Agent 决策层 | 判断需要回答、检索、调用工具还是转人工 | 只看到客户端筛选后的工具 |
| MCP Client（模型上下文协议客户端）层 | 连接服务端、发现工具、筛选、授权、调用、处理结果 | 本章核心 |
| MCP Server（模型上下文协议服务端）层 | 暴露工具、资源、提示模板，适配业务系统 | 本章核心 |
| 业务系统层 | 订单、工单、知识库、客户资料、CRM（客户关系管理系统） | 被服务端封装，不直接裸露给模型 |
| 权限审计层 | 身份、角色、对象归属、审批、日志 | 贯穿客户端和服务端 |
| 人工协作层 | 用户确认、客服确认、主管审批、质检复盘 | 高风险和失败兜底 |
这一层做好后，客服 Agent 就不再是“单个应用里硬编码几个工具”。它会变成一个可以连接多个服务端、按会话选择工具、按权限执行动作、按日志复盘问题的工作台。
系统流程图
这张图有 4 个重点：
读图重点：先读上组：Server 只暴露候选能力，Client 按角色、租户、会话和风险生成可用列表；再读下组：Agent 申请后经过拒绝或审批分支、Server 校验、业务执行、结果处理与审计。
- MCP Server（模型上下文协议服务端）暴露的是候选工具、资源和提示模板。
- MCP Client（模型上下文协议客户端）把候选能力变成当前会话可用能力。
- 服务端和客户端都要做权限相关工作，但位置不同：客户端先筛选，服务端再校验。
- 工具结果必须经过客户端处理和审计记录，再交给 Agent 组织回答。
模块拆分
MCP Server（模型上下文协议服务端）模块
一个服务端至少可以拆成 7 个模块。
| 模块 | 负责什么 | 客服项目例子 |
|---|---|---|
| 服务端登记模块 | 定义 server_id（服务端编号）、业务域、版本、负责人、传输模式 | policy-server、order-server、ticket-server |
| 工具注册模块 | 暴露 tool card（工具卡） | 注册 search_policy、get_order、create_ticket |
| 资源注册模块 | 暴露 resource card（资源卡） | 注册政策文档、工单分类说明、客户资料摘要 |
| 提示模板模块 | 暴露 prompt template（提示模板） | 政策解释模板、工单确认模板、投诉摘要模板 |
| 权限校验模块 | 校验 auth_context（认证上下文）和 permission_scope（权限范围） | 判断订单是否属于当前用户，客服是否有权查看客户资料 |
| 业务适配模块 | 调用底层订单、工单、知识库、客户资料系统 | 把业务系统结果转成工具输出契约 |
| 审计日志模块 | 记录发现、调用、失败、拒绝和审批 | 写入 audit_trace_id、工具名称、状态和错误摘要 |
服务端的关键原则是：暴露能力时要足够清楚，执行能力时要足够保守。 服务端不能因为客户端传来了工具请求，就默认它合法。它仍然要校验身份、对象归属、输入契约和风险策略。
MCP Client（模型上下文协议客户端）模块
客户端至少可以拆成 8 个模块。
| 模块 | 负责什么 | 客服项目例子 |
|---|---|---|
| 连接管理模块 | 管理可连接的服务端和 transport_mode（传输模式） | 连接政策、订单、工单、客户资料服务端 |
| 发现模块 | 拉取 tools（工具模块）/resources/prompts（工具/资源/提示模板） | 获取工具卡、资源卡、提示模板列表 |
| 会话策略模块 | 根据当前用户、角色、场景裁剪能力 | 普通客户只看到本人订单查询和创建工单 |
| 工具白名单模块 | 控制哪些工具可以进入 Agent 上下文 | 本轮只开放 search_policy 和 get_order |
| 授权上下文模块 | 生成和传递 auth_context（认证上下文） | 用户编号、客服编号、租户、订单归属 |
| 调用编排模块 | 发起工具调用、处理超时、重试和审批 | create_ticket 前要求用户确认摘要 |
| 结果处理模块 | 把输出契约转成模型可观察结果和前端状态 | 成功、无权限、无数据、需人工 |
| 审计关联模块 | 记录工具发现、筛选、调用和回答的 trace（追踪） | 同一个 audit_trace_id 串联全链路 |
客户端的关键原则是：不要把服务端暴露的所有能力都交给模型。 模型越靠近真实业务系统，越需要客户端把可用工具收窄到“本会话真正需要、真正有权、真正可审计”的范围。
业务域拆分建议
本章建议起步版本不要做一个“客服万能 MCP Server（模型上下文协议服务端）”。更清晰的拆分如下：
| 服务端 | 第一批工具 | 第一批资源 | 风险特点 |
|---|---|---|---|
| 政策 MCP Server（模型上下文协议服务端） | search_policy | 售后政策、退换货规则、服务条款 | 主要是资料准确性和版本风险 |
| 订单 MCP Server（模型上下文协议服务端） | get_order | 订单状态说明、物流状态说明 | 涉及用户隐私和对象归属 |
| 工单 MCP Server（模型上下文协议服务端） | create_ticket | 工单分类、处理时效、投诉规则 | 涉及写入、重复提交和用户确认 |
| 客户资料 MCP Server（模型上下文协议服务端） | get_customer_profile | 客户资料摘要、历史工单摘要 | 涉及隐私、角色权限和最小可见 |
这种拆分的好处是：权限策略更容易写清楚，失败影响范围更小，面试时也更容易说明“我按业务域治理工具生态，而不是把所有工具塞进一个服务端”。