Skywork AI函数调用教程：实战案例与最佳实践

Skywork AI 的 Function Calling 要实现起来，其实就四个步骤：注册工具、构造请求、解析响应、回传结果，缺一不可。整个过程就像你给模型提前准备好一套工具，它自己判断什么时候该用哪一把，然后你把命令拆出来、执行好、再还回去。

这个闭环一旦跑通，模型就能主动去调用天气 API、查数据库、算个数学题——不再是只跟你聊天的聊天机器人，而是能动手干活的智能体了。

定义可被调用的函数

第一步，告诉 Skywork AI 你有哪些函数能调用。这不是写 Ja va 方法，而是要给它一个结构化的 JSON Schema，把函数名、用途和参数要求写清楚。

具体做法是：在请求体里的 tools 字段中填入一个数组，每个元素包含三个字段：name、description、parameters。其中 parameters 必须遵循 OpenAPI 3.0 的规范，是一个 object 类型的定义，type、properties、required 一个都不能少。

举个例子，一个查库存的函数长这样：

{"name": "get_inventory", "description": "查询指定商品的实时库存数量", "parameters": {"type": "object", "properties": {"product_id": {"type": "string", "description": "商品唯一编码，如 SKU100293"}}, "required": ["product_id"]}}

这里有个容易踩的坑：parameters 里的 property 名称必须跟后端函数实际接收的参数名完全一致，差一个字都不行。你注册的是 product_id，函数里也得叫 product_id，不然解析出来再映射过去时就对不上了。

发起带工具能力的对话请求

调用 Skywork AI 的 chat/completions 接口时，必须在 messages 数组后面附加上 tools 字段，而且 model 参数要明确指定支持 Function Calling 的版本，比如 skywork-2.5-func。

用户的消息还是正常的自然语言，比如“A0045号商品还有多少库存？”——模型看了，会自己去判断该不该调用工具。

这里的关键是：千万不能漏掉 tools 字段。如果你忘了写，那模型永远看不到你提供的工具列表。它不会主动猜测你有什么函数，更不会自己编一个出来。你注册的是武器，不是装饰品。

另外，model 名称写错也会导致后续所有步骤白费功夫。所以这一步操作虽然简单——只需要把数组贴进去——但错一个字段就是全局失效。

解析模型返回的函数调用指令

当模型决定需要调用函数时，它不会正常输出自然语言回答，而是返回一个 tool_calls 字段，里面包含 name 和 arguments 这两个关键信息。

解析分四步走：

第一步：检查响应里有没有 tool_calls 数组。如果没有，说明模型觉得不需要调用工具，那直接把 content 内容作为最终回复即可。

第二步：如果有，遍历每一项，提取出 name，和之前注册的函数名做匹配。

第三步：用 JSON 解析器解析 arguments 这个字符串，把它转成结构化的参数对象。这里有个硬规则：必须做类型校验。比如 product_id 要求是 string 类型，如果解析出来的是 null 或者 number，那就必须拒绝执行并报错，不能强行转成字符串糊弄过去。出错了比瞎执行更安全。

第四步：把校验通过的参数传给对应的函数去执行。这个过程随时可能抛异常，比如网络超时、数据库连接失败，所以必须捕获异常，把错误信息格式化成字符串留着备用。

将执行结果回传给模型生成终稿

执行完函数后，结果要怎么告诉模型呢？有两种方式。

方法一：构造一个新请求，把原来的 messages 全部保留，再加上一条 role=tool 的消息，content 里填入函数的执行结果。注意，content 必须是纯字符串，别把整个 JSON 对象放进去。

方法二：如果用的是 Skywork AI 的 streaming 模式，那就先用初始请求拿到 tool_calls，立即执行函数，然后把结果以 tool_response 的形式追加到流式上下文里，模型会自动续写一个 final answer。

无论用哪种方式，第二次请求的 messages 都必须包含完整的对话历史：第一次的 user 消息、assistant 消息（包含 tool_calls）、以及新加的 tool 消息。少一个上下文，模型就没法把结果和之前的意图关联起来。