跳到主要内容

第 2.7.3 节：区分 Tool、Resource 和 Prompt Card 的职责

Tool、Resource 和 Prompt Card不能只停留在口头约定，还需要落实为字段、校验和失败处理。完成本节后，你应该能够用对比表判断 Tool、Resource 和 Prompt Card 的适用条件、职责边界和取舍理由。

实现步骤或决策流程​

推荐技术流​

制作 MCP Server（模型上下文协议服务端）和 MCP Client（模型上下文协议客户端）时，不建议从“先写一个能连上的 demo（演示）”开始。对学习可以，但对作品集和企业项目不够。更推荐按下面的技术流推进。

步骤做什么为什么
1盘点客服业务动作从业务问题出发，避免为了 MCP（模型上下文协议）而造工具。
2判断哪些能力适合服务端暴露稳定、复用、边界清楚的能力更适合 MCP Server（模型上下文协议服务端）。
3按业务域拆服务端政策、订单、工单、客户资料分开，权限和日志更清楚。
4为每个工具写 tool card（工具卡）让模型、客户端和审计都知道工具边界。
5为资源写 resource card（资源卡）防止把敏感资料当普通上下文暴露。
6设计 prompt template（提示模板）复用业务表达和确认流程，但不替代权限。
7设计客户端发现和筛选策略落实“Server 暴露工具，Client 决定当前会话可用工具”。
8设计 auth（认证授权）和 approval（审批）防止越权、误调和高风险自动执行。
9设计 audit（审计）和 trace（追踪）支持排查、质检、复盘和面试说明。
10准备失败样例和验收清单验证工具不仅能成功，也能安全失败。

这条技术流的核心理由是：MCP 制作不是连接工程，而是企业工具能力的产品化。产品化意味着命名、契约、权限、状态、日志和兜底都要能交代清楚。

字段契约​

字段契约是本章最重要的交付物之一。它的作用不是教语法，而是让读者知道 MCP 制作时必须约定哪些字段。

统一字段契约​

下表覆盖本章要求掌握的核心字段。后面的工具卡、资源卡、提示模板和审计表都会复用它们。

字段中文含义应该由谁提供用在哪里设计要点
server_id服务端编号MCP Server（模型上下文协议服务端）服务端登记、发现、调用、审计要稳定、可识别业务域，例如政策、订单、工单。
client_id客户端编号MCP Client（模型上下文协议客户端）连接、发现、调用、审计标识客服工作台、主管工作台或运营工作台。
tool_name工具名称服务端工具卡工具发现和调用使用稳定英文标识，例如 search_policy。
tool_description工具描述服务端工具卡给模型和客户端判断用途说明什么时候用、不能做什么、风险是什么。
input_contract输入契约服务端定义，客户端校验工具调用前说明必填字段、来源、校验规则和缺失处理。
output_contract输出契约服务端定义，客户端处理工具返回后说明成功、失败、无权限、需审批等状态。
resource_uri资源地址服务端资源卡资源读取和引用不一定是公网地址，要能唯一定位资源。
prompt_name提示模板名称服务端提示模板客户端复用业务提示要说明适用场景、版本和禁止事项。
permission_scope权限范围服务端和客户端共同定义发现、筛选、调用说明谁能看、谁能调、能访问哪些对象。
auth_context认证上下文客户端生成，服务端校验工具调用和资源读取包含身份、角色、租户、会话、对象归属等摘要。
risk_level风险等级服务端工具卡，客户端策略使用工具筛选和审批区分只读、写入、高风险、敏感资料。
approval_required是否需要审批服务端声明，客户端执行调用前和调用中可以是无需审批、用户确认、客服确认、主管审批。
audit_trace_id审计追踪编号客户端生成或平台生成全链路日志串联发现、筛选、调用、结果、回答和人工操作。
transport_mode传输模式服务端登记，客户端连接部署和连接标明 stdio、HTTP（超文本传输协议）或企业内网连接方式。

如果一个 MCP 设计文档没有这些字段，通常说明它还停留在“能调工具”的阶段，没有进入“可治理工具生态”的阶段。

tool card（工具卡）契约​

工具卡是服务端暴露工具时最核心的说明。以下是客服项目第一批工具卡。

字段search_policyget_ordercreate_ticketget_customer_profile
工具类型只读检索工具只读业务查询工具写入工具敏感只读工具
tool_description（工具描述）根据用户问题搜索售后政策、退换货规则和服务条款查询当前授权范围内的订单、物流和售后状态在用户确认问题摘要后创建客服工单查看当前处理范围内的客户资料摘要和历史工单摘要
input_contract（输入契约）问题摘要、商品类别、问题类型、地区、政策版本偏好当前用户、订单编号或订单选择、查询原因用户编号、问题摘要、问题类型、关联订单、用户确认状态客户编号、查看原因、当前工单编号、客服角色
output_contract（输出契约）政策摘要、依据来源、适用条件、是否需人工确认订单状态、物流摘要、是否可售后、风险提示工单编号、当前状态、预计处理时间、下一步动作客户等级、历史工单摘要、风险标签、可展示范围
permission_scope（权限范围）已登录用户可查公开政策；内部政策限客服只能查当前用户或当前授权工单相关订单只能为当前用户或当前处理客户创建只允许有处理关系的客服或主管查看摘要
risk_level（风险等级）中，政策错误会误导用户中高，涉及订单隐私中高，写入业务系统高，涉及客户隐私
approval_required（是否需要审批）通常不需要，高争议政策转人工不需要审批，但必须校验对象归属需要用户确认；投诉和赔付类可需客服确认通常不审批，但必须有处理关系和审计
审计重点政策版本、引用来源、搜索条件用户身份、订单归属、查询原因用户确认、幂等编号、工单结果查看原因、角色、脱敏范围

工具卡里最容易被忽略的是“不能做什么”。例如：

  • search_policy 不能承诺人工未审批的退款结果。
  • get_order 不能查询他人订单，不能修改订单。
  • create_ticket 不能绕过用户确认，不能重复创建同一问题工单。
  • get_customer_profile 不能返回完整身份证、手机号、地址等敏感原文。

这些禁止事项要进入工具描述和权限策略，而不是只写在团队口头约定里。

resource card（资源卡）契约​

资源卡用于说明可读取的上下文资料。它比“文件路径”多得多。

资源resource_uri（资源地址）示例业务用途permission_scope（权限范围）风险与处理
售后政策主文档policy://after-sales/main支持 search_policy 和政策解释客户可读取公开摘要，客服可读取内部处理说明必须记录版本和更新时间，避免引用过期政策。
退换货例外规则policy://after-sales/exceptions判断特殊商品、地区和时间规则仅客服和主管可读取不直接展示内部判定细节给客户。
工单分类说明ticket://taxonomy/current支持创建工单时选择分类客户端可读，客户只看到简化分类分类变更要版本化。
客户资料摘要customer://profile/summary支持客服理解客户历史仅处理当前工单的客服或主管可读必须脱敏，记录查看原因。
历史工单摘要ticket://history/summary支持判断是否重复投诉客服和主管可读，客户只能看本人相关进度不能暴露其他客户信息。

资源卡要回答 6 个问题：

  • 资源能否被发现。
  • 谁能读取。
  • 读取的是原文、摘要还是脱敏结果。
  • 资源是否可以被引用给用户。
  • 资源版本如何记录。
  • 读取行为是否进入审计。

在客服项目里，政策资源可以较多地进入回答引用；客户资料资源则应该尽量只作为内部上下文，不能原样展示给客户。

prompt template（提示模板）契约​

提示模板不是必须全部放到 MCP Server（模型上下文协议服务端），但当某个业务域有稳定表达规范时，服务端提供模板很有价值。

prompt_name（提示模板名称）适用场景输入输出要求禁止事项
policy_answer_template根据政策搜索结果解释售后规则用户问题、政策摘要、依据来源、风险提示说明适用条件、引用依据、下一步建议不承诺未审批结果，不编造政策来源。
ticket_confirmation_template创建工单前让用户确认诉求问题摘要、分类、关联订单、证据材料用简洁语言让用户确认是否提交不在未确认时调用 create_ticket。
complaint_summary_template客服或主管复盘投诉用户原话摘要、订单状态、历史工单区分事实、诉求、证据、待确认点不把推测写成事实。
profile_safe_summary_template使用客户资料摘要辅助回答客户等级、历史工单摘要、风险标签只输出服务建议和需注意事项不输出完整隐私资料。

提示模板的价值是让不同客户端使用同一套业务表达标准。例如政策解释必须引用来源，工单创建必须先确认，投诉摘要必须区分事实和推测。它不能替代工具调用前的系统校验。

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

字段示例说明
server_id（服务端编号）ticket-server稳定标识服务端。
业务域工单说明服务端负责什么业务。
transport_mode（传输模式）远程 HTTP（超文本传输协议）企业工作台多人共享，适合远程服务。
暴露工具create_ticket只暴露当前业务域内工具。
暴露资源工单分类、处理时效、历史工单摘要资源要有权限范围。
暴露提示模板ticket_confirmation_template创建前确认用户诉求。
默认 risk_level（风险等级）中高因为会写入工单系统。
approval_required（是否需要审批）用户确认，特定类型客服确认写入动作不能静默执行。
审计要求必须记录 audit_trace_id（审计追踪编号）便于复盘重复建单和投诉处理。
版本2026-07便于契约变更和回滚。

MCP Client（模型上下文协议客户端）会话卡​

字段示例说明
client_id（客户端编号）customer-service-workbench标识客服工作台客户端。
当前角色一线客服决定可见工具和资源。
当前会话售后投诉处理决定工具白名单。
auth_context（认证上下文）已登录客服、当前租户、当前客户、当前工单传给服务端做二次校验。
可连接 server_id（服务端编号）policy-server、order-server、ticket-server、customer-server来自客户端配置和角色策略。
当前可用工具search_policy、get_order、create_ticket、受限的 get_customer_profile筛选后的会话工具列表。
被隐藏工具退款执行、客户完整资料导出服务端可能有或其他系统有，但本会话不可用。
audit_trace_id（审计追踪编号）本次会话追踪编号串联发现、调用和回答。

会话卡体现了本章最关键的边界：服务端暴露的是候选能力，客户端会话卡决定当前到底能用什么。

制作步骤​

第 1 步：先列业务动作，不先写服务端​

先写出客服工作台到底需要哪些动作。

业务动作推荐 MCP 形态原因
搜索售后政策工具 search_policy + 政策资源可复用，边界清晰，需要来源和版本。
查询订单状态工具 get_order需要身份和对象归属校验。
创建客服工单工具 create_ticket写入业务系统，需要确认和幂等。
查看客户资料摘要工具 get_customer_profile + 客户资料摘要资源高敏感，只能摘要化和最小可见。
直接退款不建议暴露自动执行工具资金高风险，应只暴露发起审批或转人工。

判断标准是：动作是否稳定、是否复用、是否边界清楚、是否能审计、是否有失败兜底。不能因为 MCP 很热门，就把所有内部接口都暴露出去。

第 2 步：按业务域拆 MCP Server（模型上下文协议服务端）​

把不同业务域拆开，而不是做万能服务端。

业务域server_id（服务端编号）第一批能力
政策policy-serversearch_policy，政策资源，政策解释模板
订单order-serverget_order，订单状态说明资源
工单ticket-servercreate_ticket，工单分类资源，确认模板
客户资料customer-serverget_customer_profile，客户资料摘要资源

拆分时要问一个问题：如果这个服务端出问题，会影响哪些业务？按业务域拆，可以把影响范围、权限策略和审计责任都变清楚。

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

登记卡至少写清：

  • server_id（服务端编号）。
  • 业务域。
  • transport_mode（传输模式）。
  • 暴露哪些工具、资源、提示模板。
  • 默认权限范围。
  • 风险等级。
  • 是否需要审批。
  • 审计要求。
  • 负责人或维护团队。
  • 版本和过期策略。

没有登记卡的服务端，很容易变成“谁也不知道这个工具从哪里来、谁负责、出了问题找谁”的黑箱。

第 4 步：为每个工具写 tool card（工具卡）​

工具卡不要只写一句“查询订单”。最少要写清：

  • tool_name（工具名称）。
  • tool_description（工具描述）。
  • 使用场景。
  • 不适用场景。
  • input_contract（输入契约）。
  • output_contract（输出契约）。
  • permission_scope（权限范围）。
  • risk_level（风险等级）。
  • approval_required（是否需要审批）。
  • 错误状态。
  • 审计字段。

例如 create_ticket 的工具卡必须强调：只有用户确认问题摘要后才能创建；同一订单同一问题不能重复创建；工具返回的工单编号必须来自工单系统，不能由模型生成。

第 5 步：为资源写 resource card（资源卡）​

资源卡要写清：

  • resource_uri（资源地址）。
  • 资源名称。
  • 业务域。
  • 资源版本。
  • 可读角色。
  • 是否包含敏感信息。
  • 是否允许引用给用户。
  • 缓存和过期策略。
  • 审计要求。

例如售后政策资源可以被引用给用户，但内部退换货例外规则可能只能给客服查看摘要；客户资料摘要可以辅助客服服务，但不能原样输出给客户。

第 6 步：设计 prompt template（提示模板）​

提示模板要服务于稳定业务流程，而不是把所有逻辑写进 Prompt（提示词）。

推荐先做 3 个模板：

模板作用验收重点
政策解释模板根据 search_policy 结果解释政策必须引用依据，不夸大承诺。
工单确认模板创建工单前确认用户诉求必须让用户确认，不能直接提交。
投诉摘要模板帮客服整理投诉材料区分事实、诉求和待确认点。

模板的版本要记录。政策和流程变更后，旧模板不能长期继续使用。

第 7 步：设计 MCP Client（模型上下文协议客户端）发现策略​

客户端连接服务端后，不要把发现结果原样给模型。它要做三次筛选：

筛选判断问题例子
客户端级筛选这个工作台是否允许连接这个服务端？普通客户工作台不能连接内部报表服务端。
角色级筛选当前用户角色能否看到这个工具或资源？客户看不到 get_customer_profile。
会话级筛选当前问题是否需要这个工具？单纯解释政策时，不开放 create_ticket。

这一步就是本章核心原则的落地：Server 暴露工具，Client 决定哪些工具在当前会话可用。

第 8 步：设计 auth_context（认证上下文）​

auth_context（认证上下文）至少要包含：

  • 当前用户身份。
  • 当前角色。
  • 当前租户或业务线。
  • 当前会话编号。
  • 当前客户或订单或工单范围。
  • 授权来源。
  • 权限有效期。
  • 是否已完成用户确认或人工审批。

客户端生成 auth_context（认证上下文），服务端必须校验。任何高风险工具都不能只因为客户端传了字段就执行。

第 9 步：设计调用结果处理​

工具返回结果后，客户端要先处理，再交给 Agent（智能体）。

工具结果客户端处理Agent 回答
成功提取可展示字段，隐藏敏感字段基于真实结果回答。
无权限不泄露内部对象信息说明当前账号无法处理。
缺输入生成追问或让用户选择要求补充必要信息。
需审批进入确认或审批流程说明可以提交审批，不承诺结果。
超时有限重试或降级不编造业务状态。
写入疑似成功但返回失败查询幂等状态避免重复创建或重复提交。

客户端不是简单转发层，它要把工具结果变成安全、可解释、可继续执行的状态。

第 10 步：设计验收样例​

每个工具至少准备 6 类样例：

  • 成功调用。
  • 输入缺失。
  • 无权限。
  • 对象越权。
  • 工具超时。
  • 审批或确认缺失。
  • 写入重复。
  • 输出异常。

不要只验收“能成功查到订单”。能安全失败，才是企业系统能上线的前提。

和后续章节的关系​

后续章节和本章的关系
LangGraph（智能体状态图框架）章节MCP Client（模型上下文协议客户端）筛选出的工具会成为状态图中的执行节点。
多智能体章节多个 Agent 共享 MCP Server（模型上下文协议服务端）时，需要更严格的工具发现和权限边界。
安全权限章节本章的 auth_context（认证上下文）、permission_scope（权限范围）、approval_required（是否需要审批）会进一步展开。
可观测性章节本章的 audit_trace_id（审计追踪编号）会进入链路追踪、告警、质检和成本分析。
部署章节本地 stdio（标准输入输出）和远程 HTTP（超文本传输协议）的部署、鉴权、限流和高可用会详细讨论。
作品集项目章节本章的服务端登记卡、工具卡、资源卡和客户端会话卡可以直接成为作品集文档。

本章是从“知道 MCP 是什么”到“能做出可交付 MCP 接入方案”的桥梁。

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

第 2.6 章偏工具生态边界，本章偏制作方法。面试官会关注你是否能把 MCP 做成受控工程能力，而不是只连通几个工具。

JD（职位描述）常见要求本章对应能力面试证据
开发或集成 MCP Server（模型上下文协议服务端）能按业务域设计 server_id（服务端编号）、tool card（工具卡）、resource card（资源卡）和 prompt template（提示模板）展示政策、订单、工单、客户资料服务端拆分。
在 Agent 应用中集成 MCP Client（模型上下文协议客户端）能按客户端、角色、会话筛选工具，并处理调用结果说明“Server 暴露工具，Client 决定当前会话可用工具”。
设计认证、授权、审批和审计能定义 auth_context（认证上下文）、permission_scope（权限范围）、approval_required（是否需要审批）和 audit_trace_id（审计追踪编号）用写入工具和客户资料工具讲清越权防护。
支撑本地与企业远程部署能区分 stdio（标准输入输出）和 HTTP（超文本传输协议）的风险和运维要求说明远程工具为什么必须有鉴权、限流、超时和审计。

版本与资料来源​

本文是面向学习和作品集的工程教程，不提供完整源码，不讲 Python（编程语言）、TypeScript（类型化脚本语言）、JavaScript（脚本语言）或 JSON（结构化数据格式）语法。岗位相关说法来自对 AI Agent、MCP、RAG（检索增强生成）、Tool Calling（工具调用）和企业客服工具治理岗位需求的归纳，不代表任何招聘平台或机构的官方统计。

参考资料：

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

继续学习​