Prompt、Agent Skill与MCP有何区别

一、教程目标与读者定位

在构建大模型应用时，开发者经常遇到三个相近却容易混淆的概念：提示词（Prompt）、智能体技能（Agent Skill）和模型上下文协议（MCP）。三者名称都指向”让模型更好地完成任务”，但所处的抽象层次、承担职责与落地方式差异明显。概念混淆会直接导致架构设计失当：有人把本应通过协议接入的外部能力硬塞进提示词，造成上下文膨胀；也有人把简单的角色设定上升到协议层，徒增运维复杂度。

本教程的目标是帮助读者完成三件事：第一，厘清三者的定义边界与职责分工；第二，理解它们在一次完整请求链路中的协作顺序；第三，掌握在Java服务中组合使用它们的通用工程做法，并具备验证与排查能力。

适合阅读本教程的读者包括：正在为大模型应用做架构设计的后端开发者、负责平台能力建设的运维与平台工程师、需要评估技术选型的技术负责人，以及希望把智能体能力落地到企业业务场景的架构师。读者应具备基本的Java开发经验，了解HTTP接口调用与依赖注入的常见用法，并对大模型对话接口有初步认识。

二、适用场景说明

理解三者区别的价值主要体现在以下场景：

• 单轮问答与角色设定：只需通过提示词约束模型身份、输出格式与语气，无需引入额外机制。
• 多步骤任务编排：模型需要按既定流程调用多个内部工具、访问外部数据源，此时需要技能层来封装可复用的操作单元。
• 跨系统能力接入：企业已有多个内部服务与数据平台，希望以统一方式向模型暴露工具与资源，此时需要协议层来标准化上下文与工具描述。
• 多智能体协作：不同智能体之间需要共享工具、资源与上下文，协议层的标准化价值更加突出。

需要强调的是，三者并非替代关系，而是分层协作关系。提示词解决”如何表达意图”，技能解决”能做什么动作”，协议解决”如何标准化地发现与调用这些动作和资源”。

三、前置准备

在动手实践前，建议确认以下基础条件：

1. 运行环境：可运行Java服务的开发环境，具备依赖管理与构建能力；如需调用远程模型服务，需具备网络连通性与相应访问凭证。
2. 基础知识：熟悉对话式接口的基本请求结构，理解系统消息与用户消息的区别；了解JSON序列化与反序列化；对工具调用（函数调用）的基本机制有概念性认识。
3. 工程约定：明确业务中哪些能力属于”只读查询”、哪些属于”有副作用的写操作”，以便后续在设计技能与工具时划分权限边界。
4. 数据与权限准备：梳理需要暴露给模型的内部接口清单，确认调用凭证的存放方式与最小权限原则。

四、概念辨析：三者的定义与边界

4.1 提示词：意图表达层

提示词是输入给模型的文本指令，包括系统消息与用户消息。系统消息用于设定模型的身份、行为规范与输出约束，用户消息承载具体任务。它的本质是”自然语言契约”，优点是灵活、零额外基础设施，缺点是缺乏结构化约束、难以复用、无法直接触达外部系统。

在Java服务中，构造提示词通常是最小可用实现的第一步。示意性代码如下：

@Service
public class AssistantService {
    private final ChatClient chatClient;
    public AssistantService(ChatClient chatClient) {
        this.chatClient = chatClient;
    }
    public String ask(String question) {
        Prompt prompt = new Prompt(
            new SystemPrompt("你是一名资深后端架构师，回答需结构化，先给结论再给理由。"),
            new UserPrompt(question)
        );
        return chatClient.call(prompt).getResult().getOutput().getContent();
    }
}

这段代码体现了提示词的两个关键组成：身份约束与任务输入。它适合轻量场景，但当任务需要访问实时数据或执行动作时，仅靠提示词无法完成。

4.2 智能体技能：能力封装层

技能是对一类可复用能力的封装，通常包含名称、描述、输入参数定义、执行逻辑与结果格式。它解决的问题是”把某个动作标准化成模型可以理解和触发的能力单元”。与提示词相比，技能具备三个特征：可被模型按需选择、有明确的输入输出契约、执行逻辑与模型推理解耦。

技能的设计要点包括：描述必须清晰到模型能判断何时使用；参数定义要收敛，避免开放式字符串导致歧义；执行逻辑要具备幂等性与超时控制；返回结果要做裁剪，避免把大段原始数据直接塞回上下文。

示意性伪代码如下：

技能定义：
  名称：queryOrderStatus
  描述：根据订单号查询订单当前状态，仅用于只读查询
  输入：orderId（字符串，必填）
  输出：状态枚举与更新时间
  执行：调用内部订单服务，超时3秒，失败返回结构化错误

技能层的价值在于复用与治理：同一技能可被多个智能体引用，权限与审计可集中管理。

4.3 模型上下文协议：标准化接入层

协议层定义的是”模型如何发现工具、如何描述资源、如何传递上下文”的通用规范。它把工具、资源与提示模板以标准化方式暴露给模型客户端，使不同来源的能力可以按统一格式被检索和调用。协议层解决的是跨系统、跨实现的互操作问题，而非单个能力的实现细节。

协议层的典型组成包括：工具列表与调用约定、资源读取接口、上下文传递格式、错误码与版本协商机制。它的引入会带来额外的基础设施成本，因此适合能力来源多样、需要多方协作的场景。

4.4 三者关系小结

可以用一句话概括分层：协议层负责”能力的发现与标准化接入”，技能层负责”能力的封装与治理”，提示词层负责”意图的表达与约束”。请求链路通常是：提示词驱动模型推理，模型依据技能或协议暴露的工具描述选择动作，运行时执行动作并把结果回填上下文，再由模型生成最终答复。

五、实施步骤：在Java服务中组合使用

步骤一：明确任务边界，决定分层粒度

先判断任务是否需要触达外部系统。若仅需文本生成与格式约束，停留在提示词层即可；若需要查询数据或触发动作，进入技能层设计；若能力来源超过两个且需要跨团队复用，考虑引入协议层。这一步的作用是避免过度设计，也是后续所有配置的前提。

步骤二：编写系统提示词，固化行为约束

系统提示词应包含角色定位、输出格式要求、拒答边界与工具使用原则。注意不要把大段业务数据写入系统提示词，否则会挤占上下文预算。建议将系统提示词版本化管理，便于回滚与对比效果。

步骤三：定义技能清单与参数契约

为每个内部能力定义技能描述与参数结构，描述中明确”何时使用”与”何时不要使用”。参数尽量使用枚举或受限格式，减少模型自由发挥空间。对写操作类技能单独标记风险等级，并在执行前增加二次确认或权限校验。

步骤四：通过协议层注册与发现能力

若采用协议层，将技能与资源按规范注册到服务端，客户端通过标准接口拉取工具列表与资源描述。注册时注意版本标识与描述一致性，避免模型看到过期描述而做出错误选择。协议层不负责业务逻辑，业务逻辑仍在技能实现内部。

步骤五：编排调用链路并设置兜底

在服务端组织”构造提示词—模型推理—工具选择—执行—结果回填—生成答复”的链路。为每一步设置超时与重试上限，为工具执行失败准备结构化错误返回，并让模型在收到错误后能给出可读的降级说明。兜底策略包括：工具不可用时回退到纯提示词回答、对高风险操作强制人工确认。

步骤六：结果验证

验证可从三个层面展开：功能层面，构造典型问题确认模型能选中正确技能并传对参数；契约层面，检查工具返回结构是否符合定义、错误码是否可识别；体验层面，评估答复是否满足系统提示词中的格式与语气要求。建议建立一组固定测试用例，覆盖”该调用工具””不该调用工具””工具失败”三类情形。

六、常见问题与排查思路

• 模型不调用技能：优先检查技能描述是否过于笼统或与用户问法不匹配；其次确认工具列表是否成功下发；最后检查系统提示词中是否存在抑制工具使用的表述。
• 参数传错或缺失：检查参数定义是否使用了开放式字符串；确认描述中是否给出取值示例；必要时在系统提示词中补充参数填写规则。
• 上下文膨胀导致响应变慢：排查是否把大段原始数据回填到上下文；应对工具返回做字段裁剪与摘要化处理。
• 协议层工具列表不一致：检查注册版本与客户端缓存；确认服务端与客户端的时间同步与重连机制。
• 写操作误触发：复核技能风险标记与权限校验是否生效；对高风险技能增加显式确认环节。

七、优化建议

从性能角度，控制回填上下文的体积，对工具结果做结构化裁剪，并为高频技能增加结果缓存。从安全角度，遵循最小权限原则，对写操作技能做独立鉴权与审计日志，避免把敏感凭证写入提示词。从稳定性角度，为每类工具设置超时与熔断，准备降级路径。从可维护性角度，将提示词、技能定义与协议注册信息纳入版本管理，建立变更评审流程。从成本角度，评估技能调用频次与模型推理轮次，减少不必要的多轮工具调用。

八、总结

提示词、智能体技能与模型上下文协议分别处于意图表达、能力封装与标准化接入三个层次，三者协作而非互斥。落地时的关键判断是：先明确任务是否需要触达外部系统，再决定是否引入技能层；当能力来源多样且需要跨团队复用时，再考虑协议层。工程实践中应重视契约定义、上下文体积控制、超时兜底与权限治理。后续可继续关注的方向包括工具描述的自动校验、调用链路的可观测性建设，以及多智能体场景下的上下文共享规范。