Agent能力分层教程：技能、协议与提示词如何协同工作

作者：新兰2026.11.04 11:34浏览量：0

简介：本文从技术演进与工程落地角度，系统梳理Agent Skill、MCP、Function Calling、Tool Calling与Prompt之间的关系。读者将理解各层能力的定位、调用链路与适用边界，并掌握在智能体应用中组合使用这些能力的通用方法、配置思路与排查策略。

一、教程目标

本教程要帮助开发者、技术负责人和智能体应用搭建者完成一件事：理清 Agent Skill、MCP、Function Calling、Tool Calling 与 Prompt 在智能体系统中的层级关系，并能够根据实际业务场景正确组合使用这些能力。

很多人在接触智能体开发时会被这些概念绕晕。它们有的偏学术范式，有的偏协议标准，有的偏模型原生能力，有的偏工程执行链路。如果不从“能力分层”和“调用时序”两个角度去拆解，很容易出现设计混乱、重复建设、上下文浪费或执行成功率低等问题。

完成本教程后，你将能够：

  • 明确每个概念解决什么问题、位于智能体架构的哪一层；
  • 理解一次完整的智能体任务执行中，这些能力是如何先后协作的；
  • 掌握在设计智能体应用时，什么情况下该用 Prompt、什么情况下该用工具协议、什么情况下该引入技能编排；
  • 建立一套通用的排查思路，当智能体“不调用工具”“调用错工具”或“执行流程混乱”时知道从哪里入手分析。

本教程不依赖任何特定云平台或商业智能体框架，所有描述均采用通用技术概念。文中的配置示例以伪代码和通用 JSON 结构为主，便于读者映射到自己熟悉的技术栈中。

二、适用场景

以下场景中，理解这些概念的差异与协作关系尤其重要：

  1. 从零搭建智能体应用：需要规划模型调用、工具接入、流程编排与记忆管理的整体架构。
  2. 已有智能体应用但工具调用成功率低：需要判断是模型指令设计问题、结构化输出问题，还是工具协议与执行链路问题。
  3. 希望减少上下文消耗、提升复杂任务完成率：需要引入技能化、标准作业流程式的编排能力。
  4. 团队内部需要统一智能体接入规范：需要向不同角色解释协议层、能力层与执行层的边界，避免各业务方自建碎片化工具。
  5. 技术选型与架构评审：需要评估在什么阶段引入标准化协议、什么阶段引入技能编排更合适，而不是一次性堆叠所有能力。

如果你正处于上述任一场景，建议按照本教程的顺序完整阅读，尤其是“能力分层模型”和“实施步骤”两部分。

三、前置准备

在开始理解和实践之前，建议具备以下基础：

3.1 基础知识

  • 了解大语言模型的基本工作方式，包括输入输出结构、上下文窗口、指令跟随能力；
  • 了解智能体的基本组成：规划、记忆、工具使用；
  • 理解 JSON 与 Schema 的基本概念，因为工具调用通常涉及结构化参数定义；
  • 对“推理—行动—观察”循环有初步认知。

3.2 环境准备

如果你打算边学边做，需要准备：

  • 一个可以调用大语言模型 API 的开发环境，或一个支持智能体编排的通用平台；
  • 至少一个可被调用的外部接口或本地函数，例如查询天气、执行计算、查询数据库；
  • 一个可以记录和查看调用日志的调试工具或日志系统。

3.3 概念准备

在继续之前，请先接受一个核心判断：这些概念不是同一层级的东西，因此不能简单问“谁替代谁”，而应该问“谁在哪一层解决什么问题”。

如果一开始就把它们当成并列关系，后续的理解会非常困难。建议带着“分层”的视角阅读全文。

四、能力分层与概念定义

4.1 从历史演进看能力分层的必然性

智能体执行能力的演进不是跳跃式的，而是沿着“学术范式—模型能力—工程标准化—执行效率优化”的路径逐步推进。

早期研究提出了“推理与行动结合”的范式，让模型不再一次输出完整答案，而是在推理过程中逐步调用外部能力并根据反馈调整下一步。这一思想解决了两个问题：一是模型缺乏外部信息反馈导致的“空想式推理”，二是传统决策框架缺乏高层规划能力的问题。

随后，模型底座能力增强，能够理解复杂指令并完成逻辑推理。接着，研究者证明了模型可以学会何时调用什么接口来增强自身能力。产品层面开始出现插件机制，让模型访问实时信息、执行计算或使用第三方服务。

但插件和工具定义长期处于碎片化状态，不同框架有不同描述方式。于是出现了用于统一工具发现与调用方式的开放标准，把工具和数据从特定框架中解耦出来。再之后，为了进一步提升复杂任务的成功率并降低上下文消耗，出现了技能标准，让推理框架能更有效地执行标准作业流程。

从这一演进可以看出：能力标准化是工程化落地过程中的自然结果，而不是某一家厂商的独创。

4.2 五个核心概念的定位

为了理清关系，我们将这些概念分为三个层级：模型原生能力层、工程执行链路层、任务编排标准层。

层级一：模型原生能力层

Prompt 是使用者与大语言模型之间的指令界面。它通过自然语言或结构化模板告诉模型“你是谁、你要做什么、有什么约束、输出什么格式”。Prompt 本身不具备调用外部工具的能力，但它可以诱导模型生成符合特定格式的文本，进而被外部程序解析。

Function Calling 是模型经过训练后具备的一种结构化输出能力。模型可以理解 JSON Schema，并在需要时生成一个符合该 Schema 的工具调用请求。注意，Function Calling 本身只负责“生成调用意图和参数”，真正执行是由外部程序完成的。

层级二：工程执行链路层

Tool Calling 是应用层执行工具并获取反馈的完整过程。它包含几个环节：定义工具及参数 Schema、将工具信息注入模型上下文、模型生成函数调用请求、应用解析请求并执行实际函数、把执行结果返回给模型。Function Calling 只是 Tool Calling 链条中的“生成调用请求”环节。

Agent 是具备规划、记忆和工具使用能力的更高层抽象。Agent 不只调用单个工具，它会根据模糊目标自主拆解任务、决定调用哪些工具、观察反馈并调整策略，直到完成目标或达到终止条件。

层级三：任务编排标准层

MCP（Model Context Protocol，模型上下文协议） 是用于统一工具发现与调用方式的开放标准。它解决的是“工具定义碎片化”问题：不同框架、不同服务提供方可以按照同一套协议暴露工具和数据，Agent 侧则按照同一套协议发现和调用。MCP 位于工程执行链路层之上，抽象的是“工具如何被描述、发现和调用”。

Agent Skill 是面向任务成功率和上下文效率的标准。它解决的是“复杂任务如何可靠执行”的问题：把一个反复出现的复杂任务沉淀为可复用的标准作业流程，其中包含执行步骤、所需工具、输入输出约定和质量校验规则。Skill 并非替代 MCP，而是建立在模型推理能力与工具协议之上，让 Agent 在遇到该类任务时更稳定地执行。

4.3 一张分层表理清关系

概念 层级 解决的问题 不负责的事情
Prompt 模型交互层 如何向模型表达任务和约束 不直接执行外部动作
Function Calling 模型原生能力层 如何让模型输出结构化工具调用请求 不执行工具本身
Tool Calling 工程执行链路层 如何完成“生成调用—执行—返回结果”的闭环 不解决多工具编排策略
Agent 应用抽象层 如何围绕目标自主规划与执行 不规定工具发现和调用的具体标准
MCP 工具协议标准层 如何统一工具的发现、描述与调用方式 不解决复杂任务流程编排效率
Agent Skill 任务编排标准层 如何让复杂任务按标准流程稳定执行并降低上下文消耗 不替代模型推理能力，也不替代工具协议

五、一次完整调用的时序拆解

为了真正理解这些能力如何协同工作，我们拆解一个通用场景：用户向智能体提出“帮我把这份数据按照规则清洗并生成分析报告”。

5.1 任务理解与规划

用户请求首先进入 Agent。Agent 的规划模块分析目标：任务不是一个简单工具调用，而是需要多个步骤。它可能拆解为：读取数据、检查字段完整性、清洗异常值、统计分析、生成报告。

这一阶段主要依赖 Prompt 工程和模型推理能力。Prompt 需要清晰描述 Agent 的角色、可用的能力边界、输出格式以及安全约束。

5.2 工具发现

Agent 需要知道有哪些工具可用。在标准化体系中，Agent 通过协议客户端连接到一个或多个工具提供方。工具提供方通过 MCP 或类似协议暴露工具列表、参数 Schema、权限范围和调用方式。

此时 Agent 不需要事先硬编码所有工具定义。它通过协议动态发现可用能力，并根据当前子任务选择合适工具。

5.3 生成工具调用请求

Agent 确定需要调用“数据读取工具”后，模型基于工具的参数 Schema 生成一个结构化调用请求。这就是 Function Calling 能力发挥作用的地方。

例如，模型生成如下 JSON：

  1. {
  2.   "tool": "data_reader",
  3.   "parameters": {
  4.     "source": "s3://bucket/dataset.csv",
  5.     "format": "csv",
  6.     "limit": 1000
  7.   }
  8. }

参数 Schema 由工具提供方在工具描述中定义。模型必须按照该 Schema 填充参数，字段类型、枚举值、必填项都要符合约定。

5.4 执行工具与返回结果

应用层解析模型生成的调用请求，实际执行 data_reader 函数，并把结果以模型可读的形式返回。这一步就是 Tool Calling 的后半段。执行结果可能包含数据片段、错误信息或状态码。

5.5 观察与调整

模型根据工具返回结果判断下一步。如果数据读取成功，继续规划清洗逻辑；如果读取失败，模型可能调整参数或选择备用方案。这是“推理—行动—观察”循环在工程上的具体体现。

5.6 触发技能流程

如果“数据清洗与报告生成”已经被沉淀为一个 Agent Skill，Agent 在识别到这是一个重复性复杂任务时，会加载该技能定义。技能定义中可能包含标准步骤、每一步的验收条件、可用工具清单和异常处理策略。

此时 Agent 不再临时规划每一步，而是按照技能中的流程执行。这既提升了稳定性，也减少了重复推理带来的上下文消耗。

六、实施步骤：如何在实际项目中组合使用

下面给出一个通用实施流程。你可以基于自己的技术栈调整具体实现，但分层思路保持一致。

步骤一：明确任务复杂度与重复性

在动手设计前，先回答两个问题：

  1. 这个任务是一次性简单调用，还是需要多步推理与多工具协作？
  2. 这个任务是否会在业务中反复出现，且步骤相对固定？

判断结果影响后续设计：

  • 简单一次性调用：直接在 Prompt 中说明工具用法，配合 Function Calling 即可，不必引入协议层或技能层。
  • 复杂但低频任务：使用 Agent 的规划能力，按需发现和调用工具，不急于沉淀技能。
  • 复杂且高频任务：优先考虑将其定义为 Skill，提炼标准流程。
  • 多业务方、多工具源环境：尽早引入统一工具协议，避免碎片化。

步骤二：设计工具层

工具层设计是基础。每个工具需要明确：

  • 工具名称与用途描述；
  • 输入参数 Schema（类型、必填、默认值、枚举范围）；
  • 输出结构；
  • 权限层级与安全边界；
  • 超时与重试策略。

在标准化协议下，这些元信息由工具提供方统一暴露。消费者无需关心工具的具体实现，只需按照协议发现与调用。

步骤三：设计提示词与结构化输出

Prompt 设计和 Function Calling 配置是相互配合的。Prompt 负责高层意图和约束，Function Calling 负责精确参数生成。

建议采用“角色—任务—工具—约束—输出格式”的结构化 Prompt 模板。在工具调用场景下，需要明确告知模型“当需要外部信息时，必须生成工具调用请求，而不是编造结果”。

同时，为每个工具定义清晰的描述文本。模型对工具的理解很大程度取决于这段描述。描述应包含：工具的作用、适用场景、不适用场景、参数含义和返回内容说明。

步骤四：接入统一工具协议

当工具源较多或需要跨团队复用时，应引入统一协议层。协议层的主要工作是：

  • 定义工具发现的统一入口；
  • 规范工具描述的数据结构；
  • 规范调用请求与响应的传输格式；
  • 处理鉴权、会话绑定和错误传递。

接入后，Agent 侧的集成代码可以显著简化。新增工具源时，无需修改 Agent 核心逻辑，只需按照协议注册即可。

步骤五：抽取技能流程

对于高频复杂任务，在工具层稳定后，进行技能抽取。抽取过程如下：

第一步，记录真实执行过程。 观察熟练操作者或现有 Agent 完成该类任务时的关键步骤、判断分支和常见失败点。

第二步，提炼标准作业流程。 将过程固化为有序步骤序列，每一步包含：触发条件、输入、操作、预期输出、质量校验方法。

第三步，定义异常处理策略。 对每一步可能出现的失败场景给出重试、降级或人工介入规则。

第四步，打包为可复用技能。 技能定义中引用工具层能力，但不重复定义工具。技能关注的是“先做什么、再做什么、什么情况算完成”。

第五步，在 Agent 中注册并测试。 通过一批真实样例验证技能触发是否准确、执行是否稳定、上下文消耗是否下降。

步骤六：上线与监控

上线后需要关注几个指标：

  • 工具调用成功率；
  • 参数生成准确率；
  • 任务端到端完成率；
  • 平均上下文消耗量；
  • 异常终止原因分布。

根据监控数据，持续优化 Prompt、工具描述、技能流程和协议配置。

七、配置说明与通用示例

7.1 工具定义的通用结构

下面是一个中立的工具定义示例，展示协议层通用的元信息结构：

  1. {
  2.   "name": "query_order_status",
  3.   "description": "根据订单号查询订单当前状态。适用于用户询问订单进度时。",
  4.   "parameters": {
  5.     "type": "object",
  6.     "properties": {
  7.       "order_id": {
  8.         "type": "string",
  9.         "description": "订单唯一标识，长度 16 位"
  10.       }
  11.     },
  12.     "required": ["order_id"]
  13.   },
  14.   "returns": {
  15.     "type": "object",
  16.     "properties": {
  17.       "status": {
  18.         "type": "string",
  19.         "enum": ["pending", "shipping", "delivered", "cancelled"]
  20.       },
  21.       "updated_at": {
  22.         "type": "string",
  23.         "description": "最后更新时间"
  24.       }
  25.     }
  26.   }
  27. }

这个结构的关键是描述清晰、参数约束完整、枚举值穷尽。模型生成调用请求时，依赖这些信息。

7.2 技能定义的通用结构

技能定义通常包含元信息、输入输出约定、步骤流程和依赖工具：

  1. skill:
  2.   name: "data_cleaning_and_report"
  3.   description: "对指定数据集执行标准清洗并生成分析报告"
  4.   triggers:
  5.     - "清洗数据"
  6.     - "生成数据分析报告"
  7.   inputs:
  8.     - name: "data_source"
  9.       type: "string"
  10.       required: true
  11.   steps:
  12.     - step: 1
  13.       action: "read_data"
  14.       tool: "data_reader"
  15.       validate: "data_schema_check"
  16.     - step: 2
  17.       action: "clean_outliers"
  18.       tool: "data_cleaner"
  19.       validate: "outlier_removed"
  20.     - step: 3
  21.       action: "generate_report"
  22.       tool: "report_builder"
  23.       validate: "report_format_check"
  24.   failure_policy:
  25.     retry: 2
  26.     fallback: "human_review"

技能定义的重点在于“标准流程”和“质量校验”，它让 Agent 不必每次重新规划步骤，而是按照验证过的路径执行。

7.3 配置风险提示

  • 工具描述过于简略：模型无法准确判断何时使用该工具，容易导致不调用或误调用。
  • 参数 Schema 过于宽泛：增加模型生成非法参数的概率。
  • 技能步骤过于僵化：某些任务需要根据中间结果灵活调整，过度标准化反而降低成功率。
  • 上下文注入过多工具信息：会浪费上下文窗口并干扰模型判断，应按照任务相关性动态筛选工具描述。

八、结果验证

完成接入或配置后，需要从以下维度验证效果：

8.1 工具层验证

设计一组覆盖正常参数、边界参数和异常参数的测试用例。验证标准：

  • 模型能否在需要时稳定触发工具调用；
  • 参数填充是否符合 Schema；
  • 工具返回结果后，模型能否正确理解并继续推理。

8.2 协议层验证

若引入了统一协议，需要验证：

  • 新工具源注册后，Agent 能否自动发现；
  • 不同工具提供方的调用方式是否一致；
  • 权限与鉴权是否正确生效。

8.3 技能层验证

使用一批真实业务样例，对比“使用技能前”和“使用技能后”的差异，主要观察：

  • 端到端完成率是否提升；
  • 推理步数是否减少；
  • 上下文消耗是否下降；
  • 结果一致性是否改善。

建议在测试集上建立基线指标，再引入技能或协议层后量化对比。

九、常见问题与排查

问题一：模型不调用工具，而是直接回答

可能原因：

  1. Prompt 中没有明确要求“需要外部信息时必须调用工具”；
  2. 工具描述不清楚，模型不知道有可用工具；
  3. 模型认为不调用工具也能回答，或认为调用工具风险更高。

排查思路：

  • 检查工具信息是否正确注入上下文；
  • 检查工具描述是否包含“使用场景”和“不适用场景”；
  • 在 Prompt 中增加约束，例如“如果该信息无法从你的参数知识中确定，必须调用工具获取”。

问题二：模型调用工具但参数错误

可能原因：

  1. 参数 Schema 不够明确，缺少类型约束或取值示例；
  2. 工具描述与参数 Schema 不一致；
  3. 输入信息不足，模型只能猜测参数值。

排查思路：

  • 为每个参数增加描述和示例；
  • 缩小枚举值范围，避免开放式自由文本；
  • 在 Prompt 中要求模型“如果参数信息缺失，先向用户询问确认”。

问题三：复杂任务执行到一半中断

可能原因：

  1. 缺少统一的任务状态管理；
  2. 某一步失败后没有重试或降级策略；
  3. 上下文超长导致早期信息被截断。

排查思路：

  • 将复杂任务拆分为可独立执行的子任务；
  • 为每一步定义失败策略；
  • 使用摘要机制压缩中间结果，避免上下文无限增长。

问题四：引入 Skill 后任务更慢或更容易失败

可能原因：

  1. 技能触发条件过于宽泛，不适用的任务也触发了技能；
  2. 技能步骤与实际需求不匹配，过度标准化；
  3. 技能内引用的工具已变更但技能定义未同步更新。

排查思路：

  • 收紧技能触发条件，明确适用边界；
  • 定期回顾技能执行记录，修正与实际情况不符的步骤；
  • 在技能定义中增加版本号，与工具版本联动管理。

十、优化建议

10.1 上下文效率优化

  • 动态筛选工具描述，不要把所有工具信息一次性注入；
  • 对长会话采用“渐进式摘要”，保留关键状态而非完整历史；
  • 技能触发后只加载该技能需要的工具信息，减少冗余。

10.2 安全与权限

  • 工具层需要做鉴权与权限隔离，不同 Agent 实例使用独立凭证；
  • 涉及写操作或数据导出的工具，必须增加人工确认或审计日志；
  • 技能的异常分支应优先考虑“安全失败”，避免越权执行。

10.3 可维护性

  • 工具定义、技能定义与 Agent 核心逻辑解耦；
  • 为工具和技能建立版本管理，修改时保留回滚能力；
  • 建立测试集，在变更后自动回归验证。

10.4 成本控制

  • 对于简单任务，避免引入过重的协议层或多步编排；
  • 对于高频复杂任务，优先沉淀技能，减少每次重新推理的成本；
  • 合理设置最大推理步数，防止模型无限循环调用工具。

十一、总结

Agent Skill、MCP、Function Calling、Tool Calling 与 Prompt 不是同一层级的替代关系，而是智能体系统中不同层面的协作组件。

  • Prompt 负责表达任务与约束，是模型的交互界面；
  • Function Calling 是模型结构化输出的原生能力，解决“生成调用请求”问题；
  • Tool Calling 是完整的执行链路，覆盖“生成—执行—反馈”；
  • Agent 是具备规划、记忆和工具使用能力的应用抽象；
  • MCP 或同类协议统一工具的发现与调用方式，解决碎片化问题；
  • Agent Skill 将高频复杂任务沉淀为标准流程，提升完成率并降低上下文消耗。

在实际落地时，建议按照“先理清任务复杂度与重复性，再分层设计工具、协议与技能”的顺序推进。不要一开始就堆叠全部能力，而是根据真实痛点逐步引入。

掌握这些概念的关键，不是记住定义，而是理解它们各自在一条完整任务执行链路中的位置。当你能够画出一次任务从用户请求到最终结果的完整时序图，并清楚每一层在哪里介入、为什么介入时，就已经真正理解了这些能力的区别与协作方式。

最热文章