简介：本文从工程源码视角出发，深入对比AI Agent中技能（Skills）机制与函数调用（Function Calling）的底层实现差异。通过拆解工具注册、调用管线和消息流，揭示技能本质上是“注入指令的提示词封装”，而函数调用是“严格的请求-响应执行单元”。文章将帮助开发者理解两者的架构逻辑、适用场景与设计取舍，并为编写自定义技能、构建Agent系统提供可落地的选型建议。
在构建AI Agent应用时，开发者常常面临一个核心困惑：为什么有些能力封装成“技能”后，模型的表现和直接调用函数完全不同？同样的工具，为什么用技能方式调用时，模型似乎更“听话”，甚至会自行规划多步操作？
这背后的根源在于：技能（Skills）与函数调用（Function Calling）虽然在用户侧看起来都是“给模型增加能力”，但在代码层面走的是完全不同的执行路径。函数调用是一个严格的“模型发起-系统执行-结果返回”循环；而技能则更像是一段被包装成工具的提示词脚本，通过注入指令来引导模型行为。理解这两者在源码层面的实现差异，是决定你如何设计Agent功能、如何编写自定义技能、以及如何排查复杂问题的基础。
函数调用（Function Calling） 是指模型在推理过程中，根据用户的请求和工具描述，输出一个结构化的调用指令（如工具名称和参数），由外部系统执行该指令并将结果返回给模型继续推理。它是一种标准化的“模型-系统”协作协议。
技能（Skills） 是一种更高层次的能力封装。从外部看，技能也是一个可以被模型调用的工具，但它内部并不仅仅包含一个执行函数。技能通常包含一段精心设计的指令文本（即提示词）、可选的示例数据和参数定义。当模型触发一个技能时，它拿到的不是“执行结果”，而是一份“行动指南”——告诉模型接下来应该如何思考、如何拆解任务、以及按什么顺序调用其他基础工具。
在正式分析差异前，有必要先指出二者在几个基础层面是相同的：
这些相同点容易造成一种错觉：技能就是函数调用的一个“包装壳”，只是把多个函数组合在一起而已。但事实远非如此。
在Agent系统的源码中，工具都实现了一个统一的接口，核心字段包括名称、输入参数定义（通常使用Zod Schema验证）、执行函数和权限检查函数。所有工具通过一个中心化的构建函数统一装配，最终序列化成模型API能识别的JSON Schema格式。
函数调用的注册路径非常直接：开发者定义一个执行函数，声明参数类型，注册后即完成。模型的请求会直接触发这个函数的执行。
技能的注册则不同。技能在构建时，除了定义名称和参数外，还封装了一段“指令脚本”和可选的示例数据。当模型调用技能时，执行函数并不直接执行具体的业务逻辑（比如查数据库、调API），而是将这段指令脚本作为消息注入到对话上下文中。
这是二者最核心的区别。在标准的函数调用流程中，系统执行完工具函数后，会将结果以tool_result的形式返回给模型，模型读取结果后继续推理。整个流程是干净的一问一答：模型问，系统答。
而技能的执行路径完全不同。当模型调用一个技能时，系统执行后返回的内容中包含一个新的消息字段，该字段是一条带有元数据标记的用户消息。本质上，这条消息是一份“指令书”——它告诉模型：“你现在应该按照以下步骤去完成任务：第一步做什么，第二步做什么……”。模型收到这份指令后，并不会直接得到最终答案，而是会继续调用其他基础工具（如搜索工具、计算工具等）去逐步执行。
示意性代码展示（伪代码）：
# 函数调用路径def call_function(function_name, arguments):result = execute(function_name, arguments) # 直接执行return append_to_dialogue("tool_result", result)# 技能调用路径def call_skill(skill_name, arguments):instruction = load_skill_instruction(skill_name) # 加载指令脚本return append_to_dialogue("user_message",instruction + format(arguments),is_meta=True) # 注入指令书
技能在设计上通常支持两种执行模式，进一步区别于函数调用：
内联模式（Inline Mode）：技能的指令脚本被直接注入到当前对话上下文中，模型在原有上下文中继续推理。这意味着技能不仅影响当前一步，还会改变模型后续所有的推理方向。相当于给模型“洗脑”了一份任务规划书，让它在后续所有工具调用中都遵循这份规划。
分叉模式（Fork Mode）：系统为技能创建一个独立的子对话（或副线程），技能在这个子上下文中执行，执行完毕后只将最终结果返回给主对话。这种方式隔离了技能的中间推理过程，避免干扰主对话的上下文，适合执行有明确输出、但过程较长的任务。
函数调用则没有这种模式差异。它的执行永远是原子的、瞬时的——调用就是执行，执行完毕就返回，不涉及上下文引导或模式分叉。
函数调用的结果是确定性的：函数的返回值是明确的，模型读取后只能基于该结果继续推理。如果结果不满足要求，模型可能需要多次调整参数重新查询。
技能的影响则是不确定的：模型收到的是指令书，它可能完全按照指令执行，也可能在指令基础上结合自己的理解做出额外决策。技能真正的价值在于“引导”而非“执行”——它在模型内部建立一个临时的任务执行框架，让模型自主地调用其他工具来完成任务。
在大型Agent系统中，工具数量可能非常多。为了避免模型在每次请求时都扫描所有工具的描述（造成Token浪费和性能下降），系统引入了动态工具发现和预算控制机制。
函数调用通常采用静态注册的方式，所有工具始终对模型可见（或根据输入关键词做简单的子集过滤）。
技能则引入了更精细的动态可见性控制。系统会根据当前对话的上下文、用户的意图，动态决定哪些技能对模型可见。如果一个技能与当前任务无关，系统会将其从模型的可见工具列表中移除，从而节省上下文空间、降低误调用的概率。这种机制在技能数量众多的大型Agent中尤为重要。
函数调用的工具描述通常较为简洁，包含名称、描述和参数Schema，占用的Token数相对固定。即便有100个工具，只要启用子集过滤，每次请求的额外Token负担也有限。
技能的描述则往往更长，因为它包含了指令脚本、示例数据、使用约束等。一个完整的技能定义可能占数百甚至上千Token。如果技能设计不当，频繁将技能注入到上下文中会显著消耗模型的处理窗口，影响对话质量和响应速度。
| 对比维度 | 函数调用 | 技能（Skills） |
|---|---|---|
| 本质内容 | 可执行代码（具体函数） | 指令脚本 + 可选示例（提示词封装） |
| 执行结果 | 返回tool_result（确定性结果） |
返回带元标记的用户消息（指令书） |
| 模型后续行为 | 基于结果继续推理，行为相对可控 | 被指令引导，可能执行多步后续调用 |
| 执行模式 | 单一请求-响应循环 | 支持内联注入与分叉独立执行 |
| 上下文影响 | 低，工具描述简短 | 高，指令脚本可能占用较多Token |
| 动态可见性 | 静态注册，简单子集过滤 | 动态发现，基于上下文预算控制 |
| 适用场景 | 单步、确定性的操作（查天气、算数） | 多步、需要任务规划的复杂流程 |
| 开发复杂度 | 低，定义函数即可 | 较高，需设计指令文本与调用策略 |
| 调试难度 | 易，结果可预期 | 难，模型行为受指令措辞影响较大 |
在实际Agent系统设计中，技能与函数调用往往不是对立关系，而是协作关系。一个技能被触发后，它的指令脚本通常会指导模型依次调用多个基础函数来完成具体操作。
例如，一个“客服问题处理”技能被触发后，指令书会告诉模型：第一步调用“用户身份查询”函数，第二步调用“订单状态查询”函数，第三步调用“知识库检索”函数……技能负责规划，函数负责执行，各司其职。
在决定使用技能还是函数调用时，建议从以下维度综合考虑：
如果任务本身就是单步操作，不需要推理和规划——使用函数调用。不要为简单的查询操作包装成技能，这只会增加Token消耗和调试复杂度。
如果任务需要模型自主规划、分步执行——使用技能。但需要精心设计指令文本，并在实际测试中反复调优指令措辞。
如果对上下文长度敏感（如模型窗口有限、对话轮次多）——优先使用函数调用，或设计精简的技能指令，避免过长技能文本占用上下文。
如果技能数量多，且相互之间有边界——需要设计技能发现与动态可见性机制，避免无关注入。
如果团队有较强的提示词工程能力——可以从函数调用逐步向技能演进，通过技能封装复杂流程。反之，若团队工程能力有限，应多用函数调用保持简单。
如果已经习惯了函数调用的开发模式，转向技能开发时需要注意以下几点：
上下文管理风险：技能注入的指令会一直保留在上下文中，直到对话结束或上下文被清理。如果技能使用不当，可能污染后续对话的推理方向。建议在技能执行完毕后，考虑在上下文中清除或压缩技能指令的影响。
调试复杂度提升：函数调用可以设断点、查看单次返回值；技能则需要观察模型在收到指令后的完整推理轨迹。建议为技能设计时内置“执行记录”机制，记录指令注入时的完整上下文快照，便于回溯问题。
版本管理与指令迭代：技能本质上是一段文本指令，它的“代码”就是描述性文本。这意味着技能的变更和迭代需要走提示词管理的流程（如版本对比、A/B测试），而不是普通的代码部署流程。团队需要建立相应的提示词评审和上线机制。
权限边界设计：技能执行后引导模型调用其他工具，但这些工具可能具有不同的权限等级。需要在技能设计时明确其调用的工具范围，避免技能“越权”触发高权限操作。建议在系统层面将技能的权限设置为“只能调用授权工具集中的工具”。
回到本文的核心问题：技能与函数调用的本质区别是什么？
从代码层面看，函数调用是一个可执行函数的封装，调用即执行，返回确定结果；技能则是一个提示词注入器，它以工具的外观隐藏了一段指令脚本，通过改写模型的思考方式来影响最终输出。函数调用解决的是“如何让模型使用外部工具”的问题，技能解决的是“如何让模型按照既定策略完成任务”的问题。
理解这一区别后，你自然会明白：一个合理的Agent架构，既需要函数调用作为执行基础，也需要技能作为规划层。函数调用保证了确定性的能力供给，技能则赋予了模型自主规划的灵活空间。在设计你的Agent系统时，不妨从最简单的函数调用起步，待业务需求复杂度上升、需要约束模型的推理路径时，再逐步引入技能机制，并持续打磨指令文本的质量。最终的目标不是“二选一”，而是建立一套“技能规划-函数执行”的分层协作架构，让两者发挥各自的优势。