跳到主要内容

第 2.6.3 节：把 MCP 工具调用放进权限和授权流程

MCP 工具调用只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够设计 MCP 工具调用的角色权限、审批条件、审计记录和越权处理。

实现步骤或决策流程​

推荐技术流​

学习 MCP（模型上下文协议）时，不建议从“怎么写一个 MCP Server（模型上下文协议服务端）”开始。更稳的技术流是从工具治理升级到工具生态。

步骤做什么为什么
1先复盘已有 Tool Calling（工具调用）工具没有清晰工具契约，就不应该急着 MCP 化。
2找出跨 Agent（智能体）复用的能力MCP 最适合复用型工具和资源。
3按业务域拆 MCP Server（模型上下文协议服务端）订单、工单、知识库、报表分开，权限和日志更清晰。
4设计工具发现清单让客户端知道工具名称、用途、输入、输出、风险和版本。
5设计资源读取边界明确哪些文档、报表、记录可以作为资源读取。
6设计 MCP Client（模型上下文协议客户端）过滤策略不同角色、场景、租户看到不同工具。
7设计权限、状态和日志防止越权、重复执行、失败不可查。
8设计失败兜底和人工审批工具失败或高风险动作不能让模型自由发挥。
9用验收样例测试工具生态覆盖发现、调用、无权限、超时、审批、日志。
10再进入具体服务端和客户端实现先有契约和治理，再写代码。

这条技术流的核心是：MCP 不是用来跳过工程设计的，而是把工程设计标准化。

字段契约​

本章不写代码，但必须写字段契约。字段契约的作用是让产品、前端、后端、Agent 设计和审计对齐。

契约 1：MCP Server（模型上下文协议服务端）登记卡​

字段含义客服项目示例验收要求
服务端名称给客户端识别的名称订单 MCP Server（模型上下文协议服务端）名称稳定，不能随意变化。
业务域服务端负责的业务范围订单与物流不能跨域暴露无关能力。
负责人业务和技术负责人售后系统团队出问题能找到责任人。
可用工具数暴露的工具数量3 个只读工具工具数量不宜膨胀。
可用资源数暴露的资源数量订单状态说明、物流异常规则资源必须有版本。
风险等级服务端整体风险中决定审批和监控强度。
适用客户端哪些应用可连接客服工作台、售后审批工作台不能默认所有客户端可见。
数据范围可访问哪些数据当前用户订单、授权客服队列订单必须有租户和归属边界。
审计要求记录哪些日志发现日志、调用日志、错误日志每次调用可追踪。
版本当前服务端契约版本订单工具契约 v1修改字段要有变更记录。

契约 2：工具发现结果​

MCP Client（模型上下文协议客户端）连接服务端后，工具发现结果不能只包含工具名，还要包含治理信息。

字段含义客服项目示例为什么需要
工具名称可被客户端识别的工具查询订单状态用于工具选择和日志。
工具说明说明什么时候使用查询当前用户或授权队列内订单的支付、发货和物流状态降低模型误选工具风险。
工具类型只读、写入、审批、通知只读决定是否需要确认。
输入字段摘要工具需要哪些输入用户编号、订单编号、查询原因、trace_id（追踪编号）让客户端判断参数是否完整。
输出字段摘要工具会返回什么订单状态、物流摘要、是否可售后、错误状态让 Agent 知道如何组织回答。
风险等级低、中、高中决定权限和审计强度。
是否需要人工确认调用前是否需要人确认否写入和高风险工具必须明确。
可见角色哪些角色能发现该工具客户本人、授权客服、售后主管防止工具过度暴露。
版本工具契约版本v1方便变更追踪。
当前状态可用、禁用、维护中、灰度中可用防止调用维护中的工具。

契约 3：查询订单状态工具​

输入契约：

字段含义来源是否必填权限说明
用户编号当前登录用户或被授权服务对象会话系统是不能只信用户输入。
订单编号被查询订单用户选择、订单列表或客服授权队列是必须校验订单归属。
查询场景为什么查询对话意图或客服操作否用于质检和统计。
客户端编号发起调用的工作台MCP Client（模型上下文协议客户端）是区分客服端、主管端、审批端。
trace_id（追踪编号）串联整次请求系统生成是审计和排查必需。

输出契约：

字段含义给谁使用验收要求
订单状态已支付、已发货、运输中、已签收等Agent 和前端只能来自订单系统。
物流摘要最近物流节点用户和客服不完整时要标记。
是否可售后是否具备售后入口Agent 和售后流程不能代替最终审批。
异常提示无权限、无数据、订单异常系统和人工客服不泄露内部敏感细节。
工具结果状态成功、失败、超时、无权限Agent 和日志必须稳定枚举。

契约 4：创建客服工单工具​

输入契约：

字段含义来源是否必填风险说明
用户编号当前用户身份会话系统是防止替他人建单。
问题摘要用户诉求总结Agent 生成，用户确认是未确认不能写入。
问题类型售后、物流、投诉、退款咨询等意图识别或客服选择是影响分派队列。
关联订单相关订单编号订单工具结果或用户选择否必须校验归属。
用户确认状态用户是否确认提交前端确认是写入动作必需。
幂等编号防止重复创建系统生成是同一请求不能重复建单。
trace_id（追踪编号）串联本次对话和工具调用系统生成是审计必需。

输出契约：

字段含义验收要求
工单编号工单系统返回的真实编号不能由模型生成。
当前状态已创建、待分派、需补资料等必须来自工单系统。
预计处理时间工单系统规则返回不能随口承诺。
下一步动作等待处理、补充材料、转人工必须可执行。
重复提交提示已存在同类进行中工单不重复创建。

契约 5：资源读取契约​

字段含义客服项目示例验收要求
资源标识资源的唯一入口售后政策文档、物流异常说明稳定可追踪。
资源类型文档、表格、报表、数据库记录政策文档影响读取和展示方式。
资源版本当前资料版本售后政策 2026-06 版回答必须能追溯版本。
可读角色谁能读取客服、主管、知识库管理员普通客户不能读取内部规则。
敏感级别是否含个人信息或内部信息内部质检规则为敏感决定是否脱敏。
引用方式回答中如何引用来源文档标题、段落、更新时间防止无来源回答。
缓存策略是否可缓存政策文档可短期缓存，订单记录不缓存防止旧数据误用。

契约 6：审计日志​

日志字段含义示例为什么需要
trace_id（追踪编号）串联用户问题、工具发现、工具调用和回答一次客服会话的唯一追踪排查和复盘。
会话编号多轮对话标识同一用户咨询流程判断上下文。
用户编号发起请求的人当前客户或客服责任归属。
客户端编号哪个 MCP Client（模型上下文协议客户端）发起客服工作台区分不同应用。
服务端名称哪个 MCP Server（模型上下文协议服务端）响应工单服务端定位服务端问题。
工具名称或资源标识使用了什么能力创建客服工单审计工具选择。
工具版本当时使用的契约版本v1复盘变更影响。
输入摘要关键输入字段摘要订单编号尾号、问题类型不记录完整敏感原文。
输出摘要关键返回结果摘要已创建工单、无权限、超时质检和排查。
执行状态成功、失败、无权限、超时、待审批成功监控和告警。
审批状态是否经过用户或人工确认用户已确认高风险审计。
错误原因失败时的原因订单不属于当前用户兜底和修复。

日志的目标是可复盘，不是复制全部数据。敏感信息、密钥、完整身份证号、完整手机号、完整对话隐私都不应该原样写入日志。

制作步骤​

下面是一套不写代码也能执行的 MCP 设计步骤，适合做课程作业、作品集设计文档和面试准备。

读图重点：沿“可见—认证—对象归属—风险”向下读：只读工具可放行，写入先确认并查幂等，高风险先审批；越权、超时、拒绝和异常都不会交给模型编造结果，而是统一留痕。

第 1 步：盘点已有客服工具​

先从第 1.6 章的 Tool Calling 工具开始盘点：

已有工具是否稳定是否复用是否适合 MCP 化
查询订单状态稳定高适合。
查询售后政策稳定高适合，也可以作为资源读取。
创建客服工单较稳定高适合，但要用户确认和幂等。
发起退款审批规则复杂中可后置，必须人工审批。
直接退款高风险低不适合自动 MCP 工具化。

判断标准不是“能不能做”，而是“是否稳定、是否复用、是否有权限和日志”。

第 2 步：按业务域拆服务端​

不要把所有工具塞进一个 MCP Server（模型上下文协议服务端）。推荐按业务域拆：

  • 知识库 MCP Server（模型上下文协议服务端）。
  • 订单 MCP Server（模型上下文协议服务端）。
  • 工单 MCP Server（模型上下文协议服务端）。
  • 审批 MCP Server（模型上下文协议服务端）。
  • 报表 MCP Server（模型上下文协议服务端）。

拆分后，每个服务端都能有自己的负责人、权限策略、日志指标和版本节奏。

第 3 步：写服务端登记卡​

每个 MCP Server（模型上下文协议服务端）上线前都要有登记卡，至少说明：

  • 服务端名称。
  • 业务域。
  • 负责人。
  • 可用工具。
  • 可用资源。
  • 风险等级。
  • 适用客户端。
  • 数据范围。
  • 审计要求。
  • 当前版本。

这一步看起来像文档工作，但它能避免后期“没人知道这个工具是谁暴露的”。

第 4 步：设计工具发现结果​

每个工具发现结果都要说明：

  • 工具做什么。
  • 什么时候应该用。
  • 什么时候不应该用。
  • 需要哪些输入。
  • 返回哪些输出。
  • 当前风险等级。
  • 是否需要用户确认或人工审批。
  • 哪些角色可见。

工具说明写得越模糊，模型越容易误选工具。一个合格工具说明应该包含边界，例如：

工具好的说明不好的说明
查询订单状态查询当前用户或授权客服队列内订单的支付、发货、物流和售后入口状态；不修改订单。查询订单。
创建客服工单在用户确认问题摘要后创建客服处理单；同一诉求重复提交时返回已有工单。帮用户处理问题。
发起退款审批收集材料并创建退款审批申请；不直接退款，不承诺审批结果。处理退款。

第 5 步：设计 MCP Client（模型上下文协议客户端）过滤策略​

客户端不能把服务端暴露的所有工具都直接交给模型。过滤策略至少要考虑：

  • 当前用户角色。
  • 当前租户或店铺。
  • 当前业务线。
  • 当前会话场景。
  • 工具风险等级。
  • 工具是否维护中。
  • 是否启用灰度。

例如：

当前角色可发现工具不可发现工具
普通客户查询本人订单、读取公开政策、创建本人咨询工单内部质检报表、客服备注、批量导出。
一线客服查询授权队列订单、创建工单、追加处理备注资金补偿、跨团队报表、系统配置。
主管查看汇总报表、查询团队工单、读取质检规则直接修改客户资金、绕过审批。
知识库管理员读取和维护政策资源查询客户隐私订单。

第 6 步：设计资源边界​

资源读取经常被低估。客服 Agent 读取的政策、报表和规则可能包含内部信息。

资源边界要回答：

  • 哪些资源可以被普通客服读取。
  • 哪些资源只能给主管读取。
  • 哪些资源可以引用给客户。
  • 哪些资源只能用于内部判断，不能直接展示。
  • 资源过期时如何提示。
  • 资源读取是否进入日志。

第 7 步：设计写入和审批​

MCP 工具生态里，写入工具必须特别谨慎。

写入动作推荐策略
创建普通咨询工单用户确认问题摘要后自动创建。
创建投诉工单用户确认，记录证据和敏感字段。
追加客服备注仅客服角色可用，记录操作者。
发起退款审批只创建审批，不直接退款。
发放补偿不自动执行，必须人工审批。
关闭投诉不建议由 Agent 自动执行。

写入工具上线前，要先验证幂等、重复提交、撤销方式和人工接管。

第 8 步：设计验收样例​

每个 MCP Server（模型上下文协议服务端）至少准备这些样例：

样例类型期望验证
正常发现合法客户端能发现正确工具。
无权限发现普通用户看不到内部工具。
正常调用工具返回真实业务结果。
参数缺失系统追问或拒绝调用。
对象越权不返回敏感数据。
工具超时有清晰降级回答。
重复写入不重复创建工单。
高风险审批进入人工审批而不是直接执行。
日志复盘能用 trace_id（追踪编号）串起全链路。

第 9 步：准备面试讲法​

完成设计后，读者应该能用 1 分钟说明：

我在客服 Agent 工作台里把 MCP 放在 Agent 应用和企业系统之间。Tool Calling 负责模型如何申请调用工具，MCP 负责工具和资源如何被统一发现、连接和复用。我会把订单、工单、知识库、审批按业务域拆成不同 MCP Server（模型上下文协议服务端），客服工作台作为 MCP Client（模型上下文协议客户端）根据用户角色和场景发现可用工具。只读工具可以自动调用，写入工具要用户确认，高风险动作进入人工审批。所有发现和调用都会记录 trace_id（追踪编号）、工具版本、输入摘要、输出状态和审批结果，这样才能防止越权、重复执行和不可追溯的问题。

和后续章节的关系​

本章是第 2 卷后续工程章节的连接点。

后续章节和本章的关系
MCP Server（模型上下文协议服务端）制作章节本章讲服务端应该暴露什么、怎么治理；后续会讲如何制作具体服务端。
MCP Client（模型上下文协议客户端）集成章节本章讲客户端职责；后续会讲如何在工作台里连接、发现和调用。
RAG（检索增强生成）章节知识库检索能力可以通过 MCP 作为工具或资源暴露。
LangGraph（智能体状态图框架）章节多步骤客服流程会把 MCP 工具调用放进状态节点。
安全权限章节MCP 会放大权限设计的重要性，尤其是工具发现和高风险动作。
可观测性章节MCP 的连接、发现、调用和审批都要进入追踪和告警。
多智能体章节多个 Agent 共享企业工具生态时，MCP 能降低重复接入成本。

可以把本章看成“企业工具生态”的总入口。后续章节会把其中的服务端、客户端、安全和流程编排拆开讲。

岗位 JD（职位描述） 能力映射​

MCP 相关岗位要求往往会写成“Agent 工具生态”“企业工具集成”“工具调用平台”。本章把这些要求拆成可面试表达的能力。

JD（职位描述）常见要求本章对应能力面试证据
设计 Agent 工具生态能区分 Tool Calling 和 MCP 的职责用客服工作台说明工具如何被发现、过滤、调用和审计。
封装企业工具和资源能按知识库、订单、工单、审批、报表拆分 MCP Server（模型上下文协议服务端）展示服务端登记卡、工具发现结果和资源读取契约。
控制工具权限和高风险动作能设计角色过滤、风险等级、用户确认和人工审批说明退款、补偿、关闭投诉为什么只能发起审批。
建设可观测工具调用链路能记录 trace_id（追踪编号）、工具版本、输入摘要、输出状态和失败原因用审计日志契约复盘一次工具调用。

版本与资料来源​

本文是面向学习和作品集的工程教程，不提供完整源码，不讲代码语法。岗位相关说法来自对 AI Agent、RAG、MCP 和企业工具调用岗位描述的样本归纳，不代表任何招聘平台或机构的官方统计。

参考资料：

过时风险：MCP 规范、模型供应商工具调用接口、Agents SDK（智能体软件开发工具包）和客户端支持能力会持续变化。进入真实项目开发或正式出版前，必须重新核对官方文档、当前协议版本、SDK（软件开发工具包）版本和企业安全要求。

继续学习​