Agent Skill、工具协议与Prompt的区别：三层架构原理解析

一、原理概述

本文要解释的核心问题是：在智能体系统中，Prompt、Function Calling（函数调用）、统一工具接入协议、Agent Skill（智能体技能）这几类机制分别解决什么问题、处于什么层级、如何协作。

先给出结论：它们不是同一层面的竞争方案，而是一条自底向上的能力栈——

• Function Calling 是最底层的调用协议，解决“模型如何发起一次结构化调用”；
• 统一工具接入协议 在其之上做工具标准化，解决“外部能力如何以统一方式暴露给模型”；
• Agent Skill 在最上层做知识与流程封装，解决“拿到工具之后，按什么流程、什么标准完成任务”；
• Prompt 则是贯穿所有层的表达载体，意图、约束、工具描述、技能说明最终都以文本形式进入模型上下文。

一个直观的类比：Function Calling 是“语言”，统一工具协议是“工具箱”，Agent Skill 是“操作手册”，Prompt 是把三者串起来的“说明书正文”。理解了每层的输入、输出与依赖关系，三者的区别就一目了然。

二、背景问题：这些概念为什么会出现

大语言模型的本质是文本生成：给定上下文，输出下一段文本。它本身不能连接数据库、不能发起网络请求、不能执行脚本。要让模型“动手”，工程上必须依次解决三个递进的问题：

第一，模型如何表达“我要调用某个操作”。 早期做法是把约定写进提示词，让模型输出特定格式的文本，再用解析器提取，脆弱且不可靠。后来主流模型厂商在训练层面支持了结构化函数调用，即 Function Calling：模型直接输出结构化数据（通常是 JSON）声明函数名与参数，程序可以稳定解析。

第二，成百上千的外部能力如何统一接入。 工具多了之后，新的问题出现：每个工具的数据格式、鉴权方式、描述规范都不同，每换一个智能体框架就要重写一遍适配代码。于是业界出现了统一的工具接入协议，把数据库、API、文件系统等能力封装成标准化服务，实现“一次接入、处处可用”。

第三，有了工具之后，模型如何知道“怎么用”。 实践中发现，模型“有工具”不等于“会用工具”：它不知道业务口径、执行顺序、异常处理方式和输出规范。于是出现了 Agent Skill 这类机制，把完成某类任务的经验——步骤、规范、脚本、模板——打包成可复用模块，按需注入。

可以看到，这些概念不是同一时期对同一个问题的不同答案，而是对三个递进问题的分层回答。

三、核心概念：层级定位与视角差异

层级	机制	回答的核心问题	一句话视角
表达层	Prompt	模型如何理解意图、约束与上下文	“我按这些指令思考”
调用层	Function Calling	模型如何发起一次结构化调用	“我要调这个函数”
工具层	统一工具接入协议	外部能力如何标准化暴露与执行	“我能提供这些能力”
知识层	Agent Skill	任务按什么流程与标准完成	“按这个手册做”

这四句话的主语不同：Function Calling 的主语是模型，工具协议的主语是工具服务，Agent Skill 的主语是沉淀下来的操作知识，Prompt 的主语是系统与使用者。主语不同、粒度不同、服务的对象不同，这正是它们不能互相替代、只能分层协作的根本原因。

四、各层工作机制详解

4.1 Prompt：贯穿各层的指令载体

Prompt 的本质是由自然语言构成的结构化上下文，通常包括系统指令、工具描述、技能说明、历史对话与用户输入。它之所以是“载体”而非“竞争方案”，是因为下层机制的能力都要通过它生效：Function Calling 的工具 schema 要以文本形式注入上下文，Agent Skill 的流程说明也要以文本形式注入上下文，模型才能“看见”它们。

这意味着 Prompt 的质量直接决定上层机制的实际效果：工具描述含糊，模型就会误选工具；技能说明含糊，模型就会跳过关键步骤。工程实践中，“工具为什么总被误调用”这类问题，很多时候根源不在调用层，而在描述文本写得不够精确。

4.2 Function Calling：最底层的结构化调用协议

它是什么： 模型在生成过程中输出结构化数据，声明要调用的函数名与参数，由外部程序解析并执行。关键在于：模型只负责“说”，程序负责“做”，执行永远发生在模型外部。

它为什么能实现： 模型在训练阶段学习过“根据工具描述生成合法调用”的模式。推理时，运行时把工具的名称、功能描述、参数 schema 注入上下文，模型据此生成符合格式的调用意图；再配合 schema 校验或受约束解码，保证输出可以被程序稳定解析。

完整链路：

1. 开发者向运行时注册工具及其参数 schema；
2. 运行时把 schema 注入模型上下文；
3. 模型推理后输出调用意图（函数名 + 参数）；
4. 程序校验参数（类型、必填项、取值范围）；
5. 校验通过则执行真实函数，失败则拒绝并把错误信息回填；
6. 执行结果回填上下文，模型继续推理，决定是否发起下一次调用。

注意点： 模型可能生成幻觉参数，必须校验；超时、重试、幂等、鉴权都由调用方程序负责，协议本身不解决这些问题。

4.3 统一工具接入协议：工具标准化层

它是什么： 把数据库、内部 API、文件系统、检索服务等外部能力封装成标准化服务：用统一格式描述能力，用统一握手方式建立连接，用统一消息结构交换数据。

它为什么需要： 没有标准时，M 个智能体框架对接 N 个工具需要 M×N 份适配代码；标准化之后，工具方按协议实现一次服务端，框架方按协议实现一次客户端，复杂度降为 M+N。这是典型的“协议换复用”。

通用组成： 宿主应用（智能体运行时）、协议客户端、协议服务端、能力清单（工具与资源的元数据）、实际后端资源。

关键机制：

• 能力发现： 客户端连接后动态拉取工具列表与 schema，工具可以热插拔，无需修改模型代码；
• 统一消息格式： 请求、响应、错误、进度通知都有标准结构，跨语言、跨进程可用；
• 隔离与安全： 服务端通常以独立进程或沙箱运行，配合鉴权与最小权限，避免工具直接暴露底层系统。

与调用层的关系： 协议服务端暴露的工具，最终仍要转换成 Function Calling 的 schema 注入模型。工具协议不替代调用语言，而是为调用语言供给标准化的“弹药”。

agent-skill-">4.4 Agent Skill：知识与流程封装层

它是什么： 把完成某类任务所需的显性知识——执行步骤、领域规范、参考文档、辅助脚本、输出模板——打包成可复用模块。一个典型的技能包包含一份说明文档（描述何时使用、如何执行）和配套资源。

它为什么需要： 工具回答“能做什么”，Skill 回答“应该怎么做”。例如同样是“查询经营数据”，不同场景的指标口径、查询顺序、异常处理、输出格式各不相同。这些经验不写进上下文，模型只能凭概率“猜”，结果质量不稳定。

关键机制——按需加载（渐进式披露）： 运行时平时只加载技能的名称与简介（几十个 token），当请求匹配到某个技能时，才把完整说明注入上下文。这样既扩展了能力边界，又不会把有限的上下文窗口塞满，是 Skill 机制在工程上成立的关键。

与下层的关系： Skill 不执行任何调用，它通过改变模型“读到的指令”来影响模型决策，最终仍由 Function Calling 与工具协议落地执行。可以理解为：Skill 是导演，模型是演员，工具是道具。

五、端到端工作流程

把四层串起来，一次典型的任务执行过程如下：

1. 用户输入请求；
2. 运行时匹配技能，把技能说明与当前可用工具清单（含 schema）组装进 Prompt；
3. 模型基于上下文推理，输出结构化调用意图（Function Calling）；
4. 运行时校验参数，经工具协议路由到对应服务端；
5. 服务端执行真实操作（查库、调 API、跑脚本），返回结果；
6. 结果回填上下文，模型判断是否继续调用下一工具，循环往复；
7. 任务完成后，模型按技能规定的输出规范生成最终答复。

对应的通用伪代码：

# 工具层：统一协议服务端暴露的工具清单（运行时自动发现）
tools = tool_client.list_tools()
# 知识层：按需加载技能说明（步骤、口径、模板）
skill = skill_registry.match("月度经营分析")
# 表达层：组装上下文
messages = [
    system("你是经营分析助手，严格遵循技能说明执行"),
    skill.instructions,              # Skill 注入的操作手册
    tool_schemas(tools),             # Function Calling 所需的工具 schema
    user("分析上个月华东区的订单情况")
]
# 调用层：推理-调用循环
while True:
    resp = model.generate(messages)
    if resp.tool_calls:
        for call in resp.tool_calls:
            validate(call.arguments, call.schema)            # 参数校验
            result = tool_client.call(call.name, call.args)  # 经协议路由执行
            messages.append(result)                          # 结果回填
    else:
        final_answer = format_by_skill(resp.text)            # 按技能规范输出
        break

六、关键技术机制

1. schema 驱动的结构化输出。 这是调用层可靠性的根基：训练对齐让模型“愿意”按格式输出，schema 校验保证“格式错误能被拦截”，两者叠加才使模型输出可以被程序稳定消费。

2. 能力发现与解耦。 工具层通过动态发现机制把“工具注册”与“模型使用”解耦，新增工具不需要重新训练模型或修改框架代码，这是“一次实现、到处复用”的来源。

3. 上下文预算管理。 上下文窗口是稀缺资源：工具描述、技能说明、历史结果都在争夺空间。按需加载、分组暴露、结果摘要压缩，都是为了让有限窗口承载最有效的信息。

4. 安全与容错。 工具调用涉及真实系统，通常需要：最小权限与鉴权、参数白名单、沙箱执行、审计日志；链路上还要有超时控制、失败重试与降级策略，避免单个工具故障拖垮整个任务。

七、技术优势与边界

优势：

• 分层解耦： 每层独立演进——调用协议保持稳定，工具可以跨智能体复用，业务知识可以持续沉淀；
• 复用性： 一份工具服务可被多个智能体共享，一份技能可被多个场景复用；
• 可维护性： 业务流程变化时只需修改技能说明，不必改动模型或工具实现。

边界：

• 链路变长，端到端延迟增加，每一层都可能失败，需要统一的观测与追踪；
• 上下文窗口有限，工具与技能过多会互相干扰，需要检索与筛选机制配合；
• 技能质量依赖人工沉淀，缺乏流程知识时模型表现会明显退化；
• 跨层问题定位复杂：模型选错工具多为知识层或表达层问题，工具执行失败多为工具层问题，需要分层排查。

八、常见误区

误区一：三者是竞争方案，选一个就行。 实际上缺任何一层系统都会退化：没有调用层，模型无法可靠发起调用；没有工具层，能力无法标准化复用；没有知识层，任务质量不稳定。

误区二：上层会取代下层。 Agent Skill 不执行调用，工具协议不替代调用语言。它们是依赖关系，不是替代关系。

误区三：Prompt 无关紧要。 恰恰相反，所有层的指令都以 Prompt 形式进入模型，工具描述与技能说明的质量直接决定模型的决策质量。

误区四：工具越多越好。 工具过多会稀释模型注意力、提高误选概率，应按场景分组暴露、按需加载。

误区五：把 Skill 写成功能说明书。 Skill 的价值在流程与规范（何时用、按什么顺序、什么口径、如何输出），而不是重复描述工具本身的功能。

九、总结

回到最初的问题：Agent Skill、工具协议与 Prompt 的区别是什么？答案不是“谁取代谁”，而是一条自底向上的能力栈：Function Calling 是模型发起调用的“语言”，统一工具接入协议是标准化供给能力的“工具箱”，Agent Skill 是规定如何用好工具的“操作手册”，Prompt 是把意图、工具与流程传达给模型的“表达载体”。在工程实践中，百度智能云等大模型服务平台也普遍将函数调用、工具接入与智能体编排作为基础能力开放。开发者理解了这套分层机制，就能在选型、排障与架构设计时迅速判断：一个问题属于哪一层、应该在哪一层解决——这正是理解原理带来的实际价值。