Agent Skill、MCP 与 Prompt 的区别及分层实践教程

作者：KAKAKA2026.11.04 11:42浏览量：0

简介：本文从 Prompt、Function Call、Agent、Skill、MCP 五个概念的分层关系入手，重点讲解它们之间的区别、演进逻辑与落地方式。读者将能理解如何从简单提示词逐步构建可调用工具、可规划任务、可复用技能、可标准化接入外部能力的 AI 应用，并掌握通用配置思路、验证手段与排查方法。

一、教程目标

本教程要帮助开发者、技术负责人以及企业应用设计者完成一件事：把 Prompt、Function Call、Agent、Skill、MCP 这几个容易混淆的概念彻底分清，并理解它们如何从“让 AI 说话”逐步演进到“让 AI 干活、规划、复用技能、标准化接入外部系统”。

读完本文后，你将能够：

  1. 用一句话说明每个概念的核心作用；
  2. 理解它们之间的层级递进关系；
  3. 在工程实现中判断当前场景适合使用哪一层能力；
  4. 掌握与每层能力对应的通用实现思路，而不是只停留在概念层面；
  5. 具备基本的结果验证、问题排查和优化意识。

本文适合以下读者：

  • 正在构建智能助手、智能问答、智能客服、研发效能工具或企业知识库应用的开发者；
  • 需要向团队解释 AI 应用分层设计的技术负责人；
  • 希望从“会写提示词”进阶到“会设计可扩展 AI 能力体系”的工程师；
  • 对工具调用、任务规划、技能复用和外部能力接入有实际需求的企业用户。

二、适用场景

这些概念并不是彼此替代关系，而是面向不同复杂度的能力层级。理解后，你可以在以下场景中做出更合适的设计选择：

  • 简单内容生成、问答、总结、翻译：通常使用 Prompt 即可完成；
  • 让 AI 查询天气、读取数据库、调用内部接口、执行计算：需要 Function Call；
  • 多步骤任务、需要先判断再调用工具、动态决定执行路径：需要 Agent；
  • 把某类固定能力沉淀为团队可复用模板，例如“生成标准周报”“生成符合规范的接口测试用例”：适合抽象为 Skill；
  • 让 AI 连接多种异构外部系统，例如浏览器、代码仓库、办公系统、业务数据库、第三方 API：适合使用 MCP 思路做标准化接入。

三、前置准备

在开始学习与实践之前，建议你具备以下基础知识与环境：

  1. 基础的编程能力：至少熟悉一门主流后端语言，例如 Java、Python 或 Go。本文使用 Java 风格的通用示例说明思路，但示例均为中性逻辑，不依赖特定框架。
  2. 对 AI 模型调用方式的基本理解：知道如何向大模型发送请求、设置系统身份提示、获取文本回复。
  3. 对 HTTP、JSON、接口调用、回调机制的基本认识：因为 Function Call、Agent、MCP 都涉及与外部系统交互。
  4. 一个可用的 AI 模型接入环境：可以是企业内部部署的模型服务，也可以是合规的云端模型 API。本文不绑定任何具体厂商。
  5. 一个可以运行示例代码的开发环境：例如包含 JDK 17 及以上版本的工程，或任意支持 HTTP 请求与 JSON 处理的运行环境。

如果上述条件暂时不完全具备，也可以先理解概念和设计思路，再结合自身项目逐步实操。

四、五个概念的整体分层关系

为了不陷入局部细节，先用一个总览图建立认知框架。这五个概念可以按照能力维度由浅入深排列：

  1. Prompt：你与 AI 之间的文本契约。它决定 AI 扮演什么角色、接收什么信息、输出什么风格。
  2. Function Call：让 AI 不仅仅是生成文本，而是能识别用户意图并请求调用一个真实函数或接口。
  3. Agent：让 AI 拥有“计划—执行—观察—调整”的循环能力。它可以使用多个工具，根据中间结果决定下一步。
  4. Skill：把某个可复用的能力封装成结构化模板，包含提示词、工具、参数说明和输出规范。它让 AI 在不同任务中重用专业方法。
  5. MCP：一种标准化的接入思想，让 AI 应用与外部数据源、工具、系统之间形成“即插即用”的连接关系。

可以用一句话概括：

  • Prompt 是“你对 AI 说的话”；
  • Function Call 是“给 AI 可用的手和脚”；
  • Agent 是“给 AI 一套决策循环”；
  • Skill 是“给 AI 一本可复用的职业技能手册”；
  • MCP 是“给 AI 一个通用接口插座”。

下面逐层拆解。

五、第一层：Prompt——先学会说清楚

5.1 Prompt 的本质

Prompt 是调用大模型时传入的文本指令。它通常包含：

  • 系统提示：定义 AI 的身份、语气、边界、输出格式；
  • 用户提示：描述具体任务或问题；
  • 上下文信息：提供背景材料，例如知识片段、历史对话、业务数据等。

Prompt 设计的好坏，直接影响回答质量。它是所有上层能力的基础，因为无论 Function Call、Agent 还是 Skill，内部都仍然依赖 Prompt 来传递意图和约束。

5.2 通用实现思路

在一个 Java 风格的示例中，可以把 Prompt 看作一个组合对象。示例如下：

  1. public class PromptService {
  3.     private final ModelGateway modelGateway;
  5.     public PromptService(ModelGateway modelGateway) {
  6.         this.modelGateway = modelGateway;
  7.     }
  9.     public String generateTechnicalExplanation(String question) {
  10.         String systemPrompt = "你是一名资深技术讲解员，擅长用通俗语言解释复杂概念。";
  11.         String userPrompt = "请解释：" + question;
  13.         String fullPrompt = buildPrompt(systemPrompt, userPrompt);
  14.         return modelGateway.complete(fullPrompt);
  15.     }
  17.     private String buildPrompt(String system, String user) {
  18.         return "【系统指令】\n" + system + "\n\n【用户问题】\n" + user;
  19.     }
  20. }

该示例中的 ModelGateway 是抽象接口，你可以替换为任何支持大模型推理的服务。这样设计的目的是让 Prompt 构造逻辑与底层模型解耦。

5.3 设计注意事项

  • 不要把 Prompt 写成“万能长文”。应优先使用结构化方式：系统角色、输入、约束、输出格式。
  • 对输出格式要求严格时，可在 Prompt 中要求模型返回 JSON、Markdown 或固定字段结构。
  • 如果需要高稳定性，可引入“少样本示例”，让模型模仿给定格式。

六、第二层：Function Call——让 AI 能动作业

6.1 为什么需要 Function Call

纯 Prompt 只能让 AI 生成文本。如果业务需要 AI 查询最新库存、创建工单、检索内部文档或执行计算，仅靠文本输出不够。Function Call 的核心思路是：

模型不直接执行函数，而是根据上下文返回“函数调用请求”，由应用侧负责真实执行，再把执行结果回传给模型。

这种方式避免了模型直接操作生产系统的风险，也便于做权限控制、审计和异常处理。

6.2 通用流程

一个典型的 Function Call 流程如下：

  1. 定义可用函数及其参数 schema；
  2. 将用户问题、系统提示和函数列表一并传给模型；
  3. 模型返回“调用函数名 + 参数 JSON”；
  4. 应用代码根据函数名执行本地函数；
  5. 将执行结果作为新消息回传给模型；
  6. 模型基于执行结果生成最终答复。

示意代码：

  1. public class FunctionCallService {
  3.     private final ModelGateway modelGateway;
  5.     public String handleUserRequest(String userMessage) {
  6.         List<FunctionDefinition> functions = List.of(
  7.             new FunctionDefinition(
  8.                 "queryInventory",
  9.                 "查询指定商品的当前库存",
  10.                 Map.of(
  11.                     "sku", "商品编码，字符串类型",
  12.                     "warehouse", "仓库编码，字符串类型，可选"
  13.                 )
  14.             )
  15.         );
  17.         ModelResponse response = modelGateway.completeWithFunctions(
  18.             buildSystemPrompt(),
  19.             userMessage,
  20.             functions
  21.         );
  23.         if (response.hasFunctionCall()) {
  24.             FunctionCall call = response.getFunctionCall();
  25.             if ("queryInventory".equals(call.getName())) {
  26.                 String sku = call.getArgument("sku");
  27.                 String warehouse = call.getArgument("warehouse");
  28.                 int stock = inventoryService.query(sku, warehouse);
  30.                 return modelGateway.completeWithFunctionResult(
  31.                     buildSystemPrompt(),
  32.                     userMessage,
  33.                     call,
  34.                     stock
  35.                 );
  36.             }
  37.         }
  39.         return response.getText();
  40.     }
  41. }

以上代码仅为通用逻辑演示，不代表任何特定框架 API。

6.3 结果验证

验证 Function Call 是否正常，可以准备如下测试用例：

  • 用户直接询问天气：应触发天气查询函数；
  • 用户要求查询库存：应返回函数调用请求；
  • 函数执行失败：模型应收到错误信息并给出友好回复；
  • 函数参数缺失：模型应尝试与用户确认或使用默认值。

agent-ai-">七、第三层：Agent——让 AI 学会思考和规划

7.1 Agent 与 Function Call 的区别

Function Call 是“一次性”的：模型判断要调用某个函数，应用执行后返回结果。但当任务需要多步骤推理、多次工具调用、根据中间结果调整策略时，就需要 Agent。

Agent 的关键特征如下：

  1. 任务分解能力：把复杂目标拆成多个子步骤；
  2. 工具选择能力：根据当前状态选择合适的工具；
  3. 循环执行能力：执行、观察、判断、再执行；
  4. 终止条件判断：知道何时可以给出最终答案。

7.2 通用实现结构

一个简单的 Agent 可以这样设计：

  1. public class SimpleAgent {
  3.     private final ModelGateway modelGateway;
  4.     private final ToolRegistry toolRegistry;
  5.     private final int maxIterations;
  7.     public String run(String userTask) {
  8.         List<Message> messages = new ArrayList<>();
  9.         messages.add(new Message("system", buildAgentSystemPrompt()));
  10.         messages.add(new Message("user", userTask));
  12.         for (int i = 0; i < maxIterations; i++) {
  13.             AgentDecision decision = modelGateway.planNextStep(messages, toolRegistry.listTools());
  15.             if (decision.shouldFinish()) {
  16.                 return decision.getFinalAnswer();
  17.             }
  19.             ToolResult result = toolRegistry.execute(decision.getToolName(), decision.getArguments());
  20.             messages.add(new Message("tool", result.toJSON()));
  21.             messages.add(new Message("assistant", "工具执行完成，继续判断下一步。"));
  22.         }
  24.         return "任务超过最大执行轮次，已停止。";
  25.     }
  26. }

7.3 生产实践建议

  • 设置最大循环次数，避免死循环；
  • 对每次工具调用记录结构化日志，便于审计与排查；
  • 对危险工具增加人工确认步骤，例如删除操作、发布操作；
  • 使用明确的状态字段区分“思考”“调用工具”“输出结果”等状态。

八、第四层：Skill——把能力沉淀为可复用资产

8.1 Skill 与 Agent 的差异

Agent 解决的是“如何执行某个任务”，而 Skill 解决的是“如何让某个专项能力被稳定复用”。一个 Skill 通常包含以下内容：

  • 技能名称与描述；
  • 适用场景；
  • 必需的输入参数；
  • Prompt 模板；
  • 可选工具或函数；
  • 输出格式规范；
  • 示例与边界说明。

8.2 设计一个 Skill 的通用步骤

以“生成标准周报”为例：

  1. 明确目标：根据用户提供的本周工作要点，生成结构清晰、语言简练的周报。
  2. 定义输入：本周完成事项、进行中事项、风险与阻塞、下周计划。
  3. 定义输出格式：标题、摘要、进展详情、风险说明、下周计划。
  4. 编写 Prompt 模板：约束结构、语气和字数。
  5. 补充示例：给出一个标准周报样例，帮助模型模仿。
  6. 配置工具：如果周报数据来自某系统，可增加一个数据查询函数，例如“获取本周任务列表”。

示意配置如下：

  1. {
  2.   "skillName": "weekly_report_generator",
  3.   "description": "根据工作要点生成标准周报",
  4.   "inputSchema": {
  5.     "completed": "string",
  6.     "inProgress": "string",
  7.     "risks": "string",
  8.     "nextWeekPlan": "string"
  9.   },
  10.   "outputFormat": "markdown",
  11.   "promptTemplate": "你是一名项目管理助手，请根据以下信息生成周报……",
  12.   "tools": ["queryProjectTasks"]
  13. }

8.3 Skill 的价值

  • 降低团队成员编写提示词的门槛；
  • 保证同类任务输出风格一致；
  • 便于在多个 AI 应用或 Agent 中复用；
  • 可以版本化管理和评审。

九、第五层：MCP——让 AI 能力接入走向标准化

9.1 MCP 的定位

MCP 不是某种具体工具，而是一种标准化连接思路。它试图解决一个常见问题：每个外部系统都有不同接口格式，导致 AI 应用需要为每个系统写适配器。MCP 的思路类似于 USB：

  • 外部系统提供一个标准描述接口；
  • AI 应用通过统一协议发现能力；
  • 应用无需关心系统内部实现；
  • 同一套交互协议可连接多个系统。

9.2 通用接入模型

为了实现“AI 世界的 USB 接口”，通常会抽象以下角色：

  • 宿主应用：例如智能助手、开发工具、企业知识平台；
  • 能力提供方：数据库、代码库、办公系统、浏览器、消息队列等；
  • 标准化能力描述：包含工具列表、参数 schema、调用方式。

通用通信流程如下：

  1. 外部系统发布能力描述；
  2. 宿主应用加载并注册这些能力；
  3. Agent 或模型根据用户意图选择能力；
  4. 宿主应用按标准协议调用外部系统；
  5. 外部系统返回结构化结果。

示意伪代码：

  1. 能力注册中心
  2.   ├── 工具名称：searchDocuments
  3.   ├── 描述：在企业知识库中搜索文档
  4.   ├── 参数：query, topK, filter
  5.   └── 返回：文档列表
  7. 宿主应用启动时：
  8.   加载所有可用能力描述
  9.   将能力转换为模型可理解的工具定义
  11. 用户请求到达时：
  12.   模型判断是否需要调用工具
  13.   宿主应用按统一协议调用外部系统
  14.   返回结果并继续生成回答

9.3 MCP 与 Function Call、Skill 的关系

  • Function Call 是单次工具调用的基础机制；
  • Agent 负责多步调用和决策；
  • Skill 封装了某类任务的完整方法；
  • MCP 则让外部工具与宿主应用之间的连接更标准化，减少集成成本。

十、配置说明与常见风险

在实际工程中，除了代码实现，还需要关注配置管理。

10.1 工具权限配置

每个工具或能力都应配置：

  • 是否启用；
  • 允许的调用者角色；
  • 是否需要人工确认；
  • 单位时间调用上限；
  • 超时时间。

10.2 模型配置

不同层面对模型能力要求不同：

  • Prompt 层：中等上下文理解能力即可；
  • Function Call 层：需支持函数调用协议；
  • Agent 层：需要更强的推理与规划能力；
  • Skill 层：对指令遵循和输出格式稳定性要求较高。

10.3 安全配置

  • 避免把敏感密钥写入 Prompt；
  • 工具返回数据应脱敏后再传给模型；
  • 外部系统接入时必须做身份认证与权限校验；
  • 对模型产生的工具调用请求做白名单校验，防止越权调用。

十一、示例说明：从查询库存到自动处理缺货

下面用一个完整场景串联五个概念。

11.1 需求

用户向企业助手提问：“华东仓的 SKU 1001 库存还够发本周订单吗？如果不够，请给出补货建议。”

11.2 各层作用

  1. Prompt：定义助手身份为“供应链运营助手”，输出语言为中文，回答风格简洁；
  2. Function Call：让模型调用“查询库存”“查询未发货订单量”“查询历史销量”等函数；
  3. Agent：根据库存与订单量计算缺口，如果缺口大于零，继续调用“生成补货建议”工具；
  4. Skill：将“库存健康诊断与补货建议”沉淀为固定技能，包含完整输入、输出模板、异常判断规则；
  5. MCP：将库存系统、订单系统、销量系统按统一协议接入，减少重复适配。

11.3 结果验证

可通过以下方式验证效果：

  • 输入标准库存充足场景，助手应直接回答“库存充足”；
  • 输入缺货场景，助手应返回缺货数量和建议补货量；
  • 输入异常 SKU，助手应提示“未找到该商品”；
  • 连续询问多个仓库，助手应能正确区分仓库维度。

十二、常见问题与排查

12.1 模型不调用函数

可能原因：

  • 函数描述不清晰；
  • 参数定义缺少可选值或示例；
  • 系统提示未说明“优先使用工具”；
  • 模型本身不具备函数调用能力。

排查思路：

  • 检查工具 schema 是否完整；
  • 在系统提示中加入调用要求；
  • 使用最简单场景测试，例如“请查询北京天气”，观察是否返回调用请求。

12.2 Agent 陷入死循环

可能原因：

  • 没有设置最大轮次；
  • 工具返回格式与模型预期不一致；
  • 任务目标过模糊，模型无法判断是否完成。

排查思路：

  • 增加最大执行轮次；
  • 规范工具返回值，明确“成功”“失败”“需要用户补充信息”等字段；
  • 在系统提示中明确终止条件。

12.3 外部系统接入后身份认证失败

可能原因：

  • 权限未开通；
  • 接口地址或密钥配置错误；
  • 网络策略限制。

排查思路：

  • 先使用最基础的健康检查接口验证连通性；
  • 检查角色权限是否包含所需操作；
  • 查看统一接入层日志，确认请求是否到达外部系统。

十三、优化建议

13.1 性能优化

  • 对工具调用做缓存，例如库存查询结果可缓存 30 秒；
  • 对 Agent 轮次设置合理上限，避免无意义循环；
  • 将大段上下文拆分为结构化输入，减少无效 Token 消耗。

13.2 安全加固

  • 敏感操作使用“人工确认”模式；
  • 对函数参数做严格校验；
  • 对工具返回内容做脱敏处理；
  • 为每个能力设置独立密钥或最小权限账号。

13.3 可维护性提升

  • 将 Prompt 模板、函数 schema、Skill 定义都做成版本化管理；
  • 使用“技能商店”或内部目录统一管理 Skill；
  • 对每次 Agent 执行保存结构化轨迹，便于复现问题。

13.4 成本控制

  • 将简单任务分配给轻量模型，只在复杂推理时使用高级模型；
  • 减少不必要的历史消息携带条数；
  • 对高频工具调用设置本地缓存，减少模型推理与外部请求次数。

十四、总结

本文围绕 Prompt、Function Call、Agent、Skill、MCP 五个概念展开，重点不是简单区分定义，而是帮助读者理解它们在不同复杂度场景下的分层价值：

  • Prompt 是基础，决定 AI 如何理解你的要求；
  • Function Call 让 AI 具备“执行动作”的入口；
  • Agent 让 AI 学会分解任务、选择工具、循环判断；
  • Skill 把常用能力沉淀为可复用资产；
  • MCP 则让外部系统与 AI 应用之间的连接更标准化、可扩展。

如果你正在设计企业级 AI 应用，不建议一开始就追求完整 Agent 或全面 MCP 接入。更务实的路径是：先做好 Prompt 与 Function Call，再逐步引入 Agent 循环，把高频场景沉淀为 Skill，最后用标准化思路整合多个外部系统。这样可以在可控复杂度下获得稳定收益，同时为后续扩展留出空间。

最热文章