一、引言：AI为什么需要“技能”？

2026年，大模型的能力边界正在被重新定义。

过去，企业对AI的期待停留在“能回答问题”——查资料、写文案、生成图片。但今天，企业需要的AI已经升级了：它不仅要“会说”，还要“会做” 。

“帮我查一下上个月华东区各产品的销售额，生成图表发给销售总监。”

这是一个典型的业务指令。它包含多个步骤：连接CRM查数据→按产品维度汇总→生成可视化图表→调用邮件系统发送。传统的大模型能做到哪一步？最多帮你生成一段文字描述，剩下的全要手动完成。

AI技能调用（Skills） 要解决的，正是“从理解到执行”的断层问题——让AI不仅能听懂指令，还能调用业务系统API，把任务真正做完。

本文将深入拆解AI技能调用的技术原理、架构设计与工程实现。

二、核心概念：Skill与Function Call的关系

在展开技术实现之前，需要先厘清两个容易混淆的概念：Skill（技能） 和 Function Call（函数调用） 。

Skill（技能） 是“能力定义”——它告诉系统“能做什么”。一个Skill是一个标准化、可复用的任务模板，包含任务描述、输入参数、执行逻辑和输出格式四个核心要素。比如“查询天气”“计算成本”“生成报表”，每个Skill对应一类特定任务。

Function Call（函数调用） 是“能力执行”——它解决“怎么调用”的问题。它是大模型执行Skill的桥梁机制：大模型根据用户指令识别需要调用的Skill对应的函数，按照预设格式生成函数调用指令，交由外部系统执行。

两者关系：Skill定义了“能做什么”，Function Call实现了“如何调用”。打个通俗的比方：大模型本身像一个只会聊天的大脑，而Skill就是给它配备的“工具手册”，手册里写清楚“计算器工具怎么用”“查快递工具怎么用”；Function Call则是大脑按照手册操作的具体动作。

在沈管家AI数字员工的架构中，Skill被设计为“可复用的任务模板”——它将一个具体的业务操作流程封装为可被自然语言触发的技能。用户说出“帮我算一下上个月的成本”，对应的“成本计算Skill”就会被触发，经过Function Call机制完成实际的API调用和数据计算。

三、技术原理：Function Calling的工作机制

3.1 从自然语言到结构化调用

Function Calling是大模型的一项关键受控输出能力。它的核心作用是将自然语言形式的用户需求，映射为结构化的函数调用意图。

用户说“帮我查一下深圳南山店今天的营业额”，模型返回的不是自然语言回答，而是一段结构化JSON：

json

{
  "name": "get_store_revenue",
  "arguments": {
    "store_name": "深圳南山店",
    "date": "2026-08-19"
  }
}

程序拿到这段意图后，自己去调用对应的函数，再把结果回传给大模型，模型再给出最终回答。

关键设计原则：模型只负责“提出计划”，真正的执行权在程序手上。模型可以返回类似上面的结构化调用请求，但应用层必须再次验证工具名、字段类型、字段范围和用户权限。只有通过校验，才允许调用后端服务。

3.2 Function Calling的完整工作流

一个完整的Function Calling流程包含五个步骤：

第一步：注册函数列表

开发者将可用的函数（名称、描述、参数结构）提前告知大模型。

第二步：用户发起请求

用户发送自然语言指令，可能隐含需要调用外部操作的需求。

第三步：模型决策与结构化输出

大模型理解用户意图，判断是否需要调用函数。如果需要，输出一个标准的JSON对象，包含function_call信息（函数名和符合参数定义的JSON字符串）。

第四步：开发者执行函数

开发者解析大模型输出的JSON，找到对应的函数实现，传入参数执行，并将执行结果（通常是JSON）反馈给大模型。

第五步：模型生成最终回复

大模型结合上下文和函数执行结果，生成自然语言回复给用户。

3.3 模型只负责“建议”，系统负责“执行”

一个核心安全原则必须被理解：大模型本身不会调用任何函数。模型只能“请求”调用工具并提供输入参数，而应用程序负责从输入参数执行工具调用并返回结果。模型永远无法访问作为工具提供的任何API，这是一个关键的安全设计。

在沈管家的实现中，这一安全原则被进一步强化：模型负责生成调用意图，系统负责权限校验、参数验证和实际执行，并记录完整的审计日志。

四、技术架构：AI技能调用的四层设计

基于Function Calling的原理，一个完整的企业级AI技能调用系统通常包含以下四层：

4.1 工具注册层——让模型“知道”有哪些技能

模型调用工具的前提是知道哪些工具可用、每个工具怎么用。

每个工具都需要明确的“契约”，包括：

• 名称：唯一标识

• 描述：告诉模型这个工具是干什么的

• 输入Schema：参数类型、是否必填、取值范围

• 权限要求：调用这个工具需要什么权限

• 副作用标记：是只读查询，还是会产生数据变更的写操作

代码示例：工具契约定义（Python）

python

# 工具契约示例 - 查询订单
TOOLS = {
    "get_order": {
        "description": "查询当前用户可访问的订单摘要",
        "schema": {
            "type": "object",
            "properties": {
                "order_id": {
                    "type": "string",
                    "minLength": 1,
                    "maxLength": 40
                }
            },
            "required": ["order_id"]
        },
        "permission": "order:read",
        "side_effect": False  # 只读操作，可自动执行
    },
    "create_ticket": {
        "description": "创建售后工单，需要用户确认",
        "schema": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string"},
                "reason": {"type": "string", "maxLength": 200}
            },
            "required": ["order_id", "reason"]
        },
        "permission": "ticket:write",
        "side_effect": True  # 写操作，需人工确认
    }
}

4.2 意图识别与参数提取层——让模型“听懂”要做什么

当用户输入自然语言指令后，大模型需要完成三件事：

1. 意图识别：判断用户是否需要调用外部函数

2. 参数提取：从文本中解析出函数所需的参数

3. 结构化输出：生成符合函数签名要求的JSON格式调用请求

以“帮我查一下上个月北京地区各门店的销售额排名”为例，模型需要输出：

json

{
  "function_name": "query_sales",
  "parameters": {
    "region": "北京",
    "time_range": "last_month",
    "group_by": "store",
    "sort_by": "sales_desc"
  }
}

4.3 校验与安全层——不能让模型“为所欲为”

这是企业级应用与Demo的本质区别。在生产环境中，必须建立多层校验机制：

权限校验：模型可以决定“想调用什么”，但系统必须决定“能不能调用”。权限应在工具层校验，而非依赖模型自觉。

参数校验：模型提取的参数可能不完整、类型错误或超出范围。系统必须使用JSON Schema进行严格校验。

副作用分级：查询类操作可自动执行；创建工单、退款、删除数据等写操作，应增加人工确认或二次鉴权。

审计日志：一次智能体请求至少应关联trace_id、用户标识、模型请求摘要、工具名称、参数摘要、执行结果和耗时。

4.4 执行与反馈层——把“计划”变成“结果”

执行层是技能调用的最后一公里。它负责：

• 调用真实API：根据校验后的参数，调用对应的业务系统接口

• 处理异常：API超时、返回错误时的重试和降级策略

• 结果返回：将执行结果（成功或失败）返回给大模型

• 闭环反馈：大模型将结果转化为自然语言告知用户

五、工程实践：一个完整的技能调用示例

以下是一个简化但完整的企业级技能调用实现示例，展示从用户指令到API调用的全链路：

python

import json
from typing import Dict, Any

class SkillEngine:
    """技能调用引擎 - 从自然语言到API调用的完整链路"""
    
    def __init__(self, llm_client, tool_registry):
        self.llm = llm_client          # 大模型客户端
        self.tools = tool_registry     # 工具注册表
        self.audit_log = []            # 审计日志
    
    def process(self, user_input: str, user_id: str) -> str:
        # Step 1: 将可用工具列表告知模型
        tools_description = self._build_tools_prompt()
        
        # Step 2: 模型决策 - 判断是否需要调用工具
        model_response = self.llm.chat(
            system_prompt=f"你有以下工具可用：{tools_description}",
            user_message=user_input
        )
        
        # Step 3: 解析模型返回的结构化调用请求
        if model_response.get("function_call"):
            tool_name = model_response["function_call"]["name"]
            arguments = json.loads(
                model_response["function_call"]["arguments"]
            )
            
            # Step 4: 权限校验
            if not self._check_permission(user_id, tool_name):
                return "您没有调用此工具的权限，请联系管理员"
            
            # Step 5: 参数校验
            if not self._validate_args(tool_name, arguments):
                return f"参数校验失败，请检查输入是否正确"
            
            # Step 6: 执行工具调用（区分读写操作）
            tool = self.tools[tool_name]
            if tool.get("side_effect"):  # 写操作需人工确认
                if not self._request_confirmation(user_id, tool_name, arguments):
                    return "操作已取消，请确认后重试"
            
            # Step 7: 执行并记录审计日志
            result = self._execute_tool(tool_name, arguments)
            self._log_audit(user_id, tool_name, arguments, result)
            
            # Step 8: 将执行结果返回给模型生成最终回复
            final_response = self.llm.chat(
                system_prompt="根据以下工具执行结果，生成对用户的自然语言回复",
                user_message=f"工具执行结果：{result}"
            )
            return final_response
        
        # 无需调用工具，直接返回模型回复
        return model_response.get("content", "")
    
    def _check_permission(self, user_id: str, tool_name: str) -> bool:
        """权限校验 - 在工具层而非提示词层"""
        # 查询用户角色，校验是否有权调用该工具
        pass
    
    def _validate_args(self, tool_name: str, args: Dict) -> bool:
        """参数校验 - 使用JSON Schema"""
        schema = self.tools[tool_name]["schema"]
        # 校验参数类型、必填项、取值范围
        pass
    
    def _execute_tool(self, tool_name: str, args: Dict) -> Any:
        """执行真实的API调用"""
        # 调用业务系统API、查询数据库或操作软件界面
        pass

六、沈管家AI数字员工中的Skills执行实践

在沈管家AI数字员工的架构中，Skills执行是区分其与对话式AI的核心能力。其技术实现具有以下特点：

Skill即任务模板：每个Skill内部定义了完成某项业务任务所需的一系列操作步骤、系统调用和异常处理逻辑。用户说出一句指令，对应的Skill即被触发。

技能插件生态：沈管家采用技能插件设计——不同部门可按需安装专属能力。人事部门安装考勤插件，财务部门安装核算插件，避免为冗余功能付费。这种模块化设计支持插件热加载，可随业务增长灵活扩展能力。

预置高频场景Skills：沈管家将销售、财务、人事等高频场景预置为Skills模板。据其公开数据，90%的用户可在15分钟内完成首次任务执行。

完整的调用链路：从用户自然语言指令出发，经过意图识别→任务拆解→Skill匹配→参数提取→系统API调用→结果交付的完整闭环。

七、总结

AI技能调用的本质，是给大模型装上一双“能干活的手”。

从Function Calling的原理解析到企业级Skill引擎的工程实现，核心逻辑始终清晰：模型负责“理解”和“建议”，系统负责“校验”和“执行” 。两者边界分明，各司其职，才能让AI从“只会说”进化为“能干活”。

对于技术决策者来说，评估一个AI平台的技能调用能力，可以从三个问题入手：

1. 工具注册是否标准化？ ——是否支持统一的工具契约和JSON Schema定义？

2. 安全校验是否完善？ ——权限校验是在工具层还是依赖模型自觉？写操作是否有确认机制？

3. 审计日志是否完整？ ——每一次工具调用是否可追溯、可回滚？

FAQ

Q：Skill和Function Call的核心区别是什么？
A：Skill是“能力定义”——告诉系统“能做什么”；Function Call是“能力执行”——实现“怎么调用”。Skill是标准化的任务模板，Function Call是连接大模型与Skill的桥梁机制。

Q：大模型能直接调用API吗？
A：不能。大模型只能“请求”调用工具并提供输入参数，应用程序负责从输入参数执行工具调用并返回结果。模型永远无法直接访问任何API，这是一个关键的安全设计。

Q：如何防止AI调用不该调用的工具？
A：权限校验应在工具层而非提示词层执行。模型可以决定“想调用什么”，但系统必须校验“能不能调用”。每个工具都应声明所需权限，系统在执行前进行权限校验。

Q：写操作（如创建工单、退款）如何处理？
A：写操作应增加人工确认或二次鉴权机制。模型生成调用请求后，系统先校验权限和参数，再向用户发送确认请求，用户确认后才实际执行。