SkillClaw：大模型工具调用框架，让LLM从对话到实干

1. 项目概述当大模型学会“使用”工具最近在折腾大语言模型LLM应用落地的朋友估计都绕不开一个核心问题如何让模型从“能说会道”的聊天高手变成一个能“动手做事”的实干家比如你问它“帮我查一下明天北京的天气”一个纯粹的对话模型可能会给你一段关于如何查询天气的文字描述但它不会真的去调用一个天气API把实时的温度、湿度、风速数据摆在你面前。这个从“知道”到“做到”的鸿沟就是工具调用Tool Calling或函数调用Function Calling要解决的核心问题。而今天要聊的这个项目——SkillClaw正是为解决这个问题而生的一套精巧“脚手架”。它不是一个全新的模型而是一个构建在开源大模型如 Llama、Qwen、ChatGLM 等之上的工具调用框架。你可以把它想象成一个给大模型配备的“多功能瑞士军刀套”和“使用说明书生成器”。SkillClaw 的核心目标是让开发者能够以一种标准化、可扩展的方式教会大模型理解并调用外部工具比如搜索引擎、计算器、数据库、业务API等从而极大地扩展模型的能力边界使其能够完成复杂的、需要多步骤交互的任务。简单来说如果你正在构建一个智能助手希望它不仅能回答问题还能帮你订餐、查物流、分析数据图表那么 SkillClaw 提供了一套从工具定义、模型适配到任务编排的完整解决方案。它试图将工具调用的复杂性封装起来让开发者更专注于业务逻辑和工具本身而不是反复纠结于如何让模型“理解”该在什么时候、以什么格式去调用哪个工具。2. 核心设计思路标准化接口与动态技能编排SkillClaw 的设计哲学非常清晰标准化和动态化。这听起来有点抽象我们拆开来看。2.1 为什么需要标准化在工具调用的早期实践中一个很头疼的问题是“格式战争”。不同的模型、不同的框架对于“工具”的描述格式、调用请求的格式、返回结果的格式往往各有各的一套。比如模型A可能期望工具描述是JSON Schema模型B可能偏好自然语言描述调用时有的需要{“name”: “tool_name”, “arguments”: {...}}有的则是function_call(tool_name, args)。这种不统一导致开发者每换一个模型或对接一个新工具就要重写一遍适配层效率极低也容易出错。SkillClaw 的做法是定义一套中间表示Intermediate Representation, IR。开发者只需要按照 SkillClaw 的规范通常是一个清晰的Python类或配置文件来定义你的工具SkillClaw 里称之为“Skill”或“工具”。这个定义包含了工具的名称、描述、输入参数类型、说明、是否必需和输出说明。然后SkillClaw 的“适配器Adapter”层会负责在运行时将这套标准化的工具描述动态地转换成后端大模型所能理解的格式。举个例子你定义了一个get_weather工具参数是city字符串和date字符串格式YYYY-MM-DD。当使用 OpenAI 的 GPT 系列时SkillClaw 的 OpenAI Adapter 会把这个工具定义转换成 OpenAI Function Calling 要求的 JSON 格式当切换到开源的 Llama 3 时Llama Adapter 则会将其转换成 Llama 所能理解的特定提示词模板或 API 格式。这样一来开发者定义一次工具就可以在多个模型后端上使用实现了“一次定义到处运行”。2.2 动态技能编排的魅力“动态化”体现在 SkillClaw 对工具调用流程的控制上。传统的有些方案可能会采用硬编码的流程先调用工具A拿到结果后再调用工具B。但现实世界的任务往往是复杂的、分支众多的。比如用户说“帮我规划一个周末旅行预算有限喜欢自然风光”这可能需要依次或并行调用1) 搜索目的地推荐2) 查询天气3) 查找交通方式和价格4) 筛选符合预算的酒店。而且中间任何一步的结果都可能影响后续步骤的选择。SkillClaw 通常将任务规划和工具调用的决策权交还给大模型本身。它通过精心设计的系统提示词System Prompt让模型理解当前可用的工具集并根据与用户的对话历史自主决定下一步该调用哪个工具、传入什么参数。这个过程是动态的、基于上下文的。更高级的是SkillClaw 支持技能的复合Skill Composition。你可以将几个基础工具组合成一个更复杂的“宏工具”或“工作流”。例如定义一个plan_trip技能它内部按逻辑顺序封装了search_destination,check_weather,book_transport等子技能的调用。对于用户来说他只需要触发plan_trip对于模型来说它可能需要分步执行对于 SkillClaw 框架来说它需要管理这个复合技能内部的状态流转和错误处理。这种设计使得构建复杂智能体Agent变得模块化和清晰。3. 核心细节解析从工具定义到模型响应理解了宏观设计我们深入到代码和配置层面看看 SkillClaw 是如何运作的。这里我会结合常见的实现模式进行讲解因为 SkillClaw 的具体API可能迭代但核心概念是相通的。3.1 技能工具的定义规范定义一个技能就像为一个函数编写一份机器和人都能读懂的说明书。在 SkillClaw 中这份说明书通常包含以下几个关键部分技能名称name唯一标识符如calculate,web_search。要求清晰、无歧义。技能描述description用自然语言清晰说明这个技能是做什么的。这部分至关重要因为大模型主要靠这段描述来理解何时该调用此工具。描述应简洁包含意图和关键参数信息。例如“根据提供的数学表达式进行计算并返回结果。”参数模式parameters定义输入参数的JSON Schema。包括type: 参数类型如string,number,integer,boolean,array,object。description: 对参数的详细解释同样是模型理解的关键。required: 布尔值指示参数是否必需。可能还有enum枚举值等约束。执行函数function实际的Python函数或可调用对象包含具体的业务逻辑。当模型决定调用该技能时SkillClaw 框架会执行这个函数并传入模型解析好的参数。一个典型的技能定义代码结构可能如下所示以伪代码/概念展示from skillclaw import Skill class CalculatorSkill(Skill): name “calculate” description “执行数学运算。支持加()、减(-)、乘(*)、除(/)、乘方(**)等运算符。” parameters { “type”: “object”, “properties”: { “expression”: { “type”: “string”, “description”: “数学表达式例如 ‘(2 3) * 4’ 或 ‘10 / 2’。” } }, “required”: [“expression”] } async def execute(self, expression: str) - str: # 安全考虑在实际生产中这里必须进行严格的表达式安全检查和沙箱计算 # 此处仅为示例使用 eval 极其危险。 try: result eval(expression) return f“计算结果{result}” except Exception as e: return f“计算失败{str(e)}”注意上面的eval用法是极度危险的示例仅用于说明概念。真实场景中计算器技能必须使用安全的表达式解析库如ast.literal_eval配合自定义操作符处理或使用numexpr、pandas.eval等受限环境否则将造成严重的代码注入安全漏洞。这是工具调用框架实践中必须高度警惕的“坑”。3.2 模型适配器Adapter的工作原理适配器是 SkillClaw 的“翻译官”。它的核心工作有两个工具描述翻译在对话开始或工具集变化时将 SkillClaw 内部的标准工具描述转换成特定模型所需的格式并注入到系统提示词或特定的API参数中。响应解析解析模型返回的消息识别出其中“意图调用工具”的部分并将其提取、标准化为 SkillClaw 内部统一的调用请求格式。例如对于 OpenAI 的gpt-3.5-turbo或gpt-4适配器会将工具定义列表转换成tools参数OpenAI API 的标准格式。当模型返回一个包含tool_calls的响应时适配器会解析出tool_call_id,name,arguments并封装好交给 SkillClaw 的核心调度器。而对于一些开源模型它们可能不支持原生的 function calling适配器就需要采用“提示词工程”的方法。比如在用户消息后追加一段指令“你可以使用以下工具… 如果你需要使用工具请严格按照以下JSON格式回复…” 然后适配器需要从模型的自由文本回复中通过正则表达式或JSON解析器提取出工具调用信息。这个过程相对更复杂也更考验适配器的鲁棒性。3.3 对话与执行循环SkillClaw 驱动的智能体其与用户的一次完整交互通常遵循一个清晰的循环初始化加载所有已注册的技能通过适配器生成模型特定的提示词。接收用户输入获取用户的问题或指令。调用模型将对话历史包含之前的工具调用和结果和当前用户输入发送给大模型。解析模型响应情况A模型返回普通文本。直接将其作为回复返回给用户循环可能结束或等待下一轮输入。情况B模型返回工具调用请求。适配器解析出要调用的技能名称和参数。执行技能SkillClaw 根据名称找到对应的技能并执行其execute函数传入参数。处理执行结果将技能执行的结果成功或失败格式化作为“工具调用结果”添加到对话历史中。再次调用模型将包含工具调用结果的更新后的对话历史再次发送给模型让模型基于工具返回的结果生成面向用户的最终回答或决定下一步行动可能继续调用其他工具。返回最终结果当模型不再调用工具而是生成最终答案时将这个答案返回给用户。这个循环实现了“模型思考 - 调用工具 - 观察结果 - 继续思考”的自主过程是构建智能体的基础范式。4. 实操过程从零构建一个天气查询智能体理论说了这么多我们来动手实现一个最简单的例子一个能查询真实天气的智能体。我们会用到 SkillClaw这里以假设的类似框架结构来演示一个开源大模型例如通过 Ollama 本地运行的qwen2.5:7b以及一个真实的天气 API。4.1 环境准备与依赖安装首先确保你的 Python 环境建议 3.9。然后安装核心依赖。由于 SkillClaw 本身可能还在迭代这里我们阐述一般性步骤。# 1. 创建虚拟环境可选但推荐 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 2. 安装假设的 skillclaw 库这里以 pip 从 git 安装举例 # 实际请参考 SkillClaw 官方文档 pip install “skillclaw” # 或 pip install githttps://github.com/AMAP-ML/SkillClaw.git # 3. 安装模型调用库例如 openai用于兼容 OpenAI API 协议的服务或 ollama pip install openai # 或者如果你用 Ollama 本地运行模型 # pip install ollama # 4. 安装 requests用于调用天气 API pip install requests4.2 定义天气查询技能我们使用一个免费的天气 API例如wttr.in这是一个基于命令行和Web的天气服务简单易用。创建一个文件weather_skill.py。import requests from typing import Dict, Any # 假设 SkillClaw 的基类导入方式 from skillclaw import Skill class WeatherQuerySkill(Skill): “”“查询指定城市的当前天气情况。”“” name “get_weather” description “获取某个城市的当前天气信息包括温度、天气状况、湿度和风速。” parameters { “type”: “object”, “properties”: { “city”: { “type”: “string”, “description”: “城市名称例如 ‘Beijing’、‘New York’。支持中英文。” } }, “required”: [“city”] } async def execute(self, city: str) - str: “”“执行天气查询。”“” # 构建请求 URLwttr.in 支持格式化的 JSON 输出 url f“https://wttr.in/{city}?formatj1” try: response requests.get(url, timeout10) response.raise_for_status() # 检查 HTTP 错误 data response.json() # 解析返回的 JSON 数据wttr.in 的格式 current_condition data[‘current_condition’][0] temp_c current_condition[‘temp_C’] weather_desc current_condition[‘weatherDesc’][0][‘value’] humidity current_condition[‘humidity’] wind_speed_kph current_condition[‘windspeedKmph’] result ( f“{city}的当前天气\n” f“- 温度{temp_c}°C\n” f“- 状况{weather_desc}\n” f“- 湿度{humidity}%\n” f“- 风速{wind_speed_kph} km/h” ) return result except requests.exceptions.RequestException as e: return f“网络请求失败无法获取{city}的天气{str(e)}” except (KeyError, IndexError) as e: return f“解析天气数据时出错API返回格式可能已更改{str(e)}”实操心得错误处理必须完备网络请求可能超时、失败API返回格式可能变化。技能执行函数的异常捕获要全面并返回对模型和用户友好的错误信息而不是抛出未处理的异常导致整个智能体崩溃。参数描述要精准city参数的描述说明了支持中英文这能帮助模型更好地理解输入范围。如果API只支持拼音或特定编码也需要在描述中明确。异步执行execute方法定义为async是因为网络I/O是阻塞操作异步化可以提高智能体在并发处理多个请求时的性能。确保你的框架和运行时环境支持异步。4.3 配置模型与创建智能体接下来我们创建一个主程序文件main.py来组装智能体。import asyncio from skillclaw import Agent, SkillRegistry from weather_skill import WeatherQuerySkill # 假设使用 OpenAI 兼容的 API这里以 Ollama 为例 from openai import AsyncOpenAI # 1. 初始化模型客户端 (以本地 Ollama 为例) # 确保你已经用 ollama pull qwen2.5:7b 拉取了模型 client AsyncOpenAI( base_url“http://localhost:11434/v1”, # Ollama 的 OpenAI 兼容端点 api_key“ollama”, # Ollama 不需要真 key但需提供 ) # 2. 创建技能注册表并添加技能 registry SkillRegistry() registry.register(WeatherQuerySkill()) # 3. 创建智能体指定模型客户端和技能注册表 # 这里需要传入模型名称对于 Ollama就是你在 ollama run 时用的名字 agent Agent( model_clientclient, model_name“qwen2.5:7b”, # 你本地运行的模型名 skill_registryregistry, system_prompt“你是一个乐于助人的智能助手可以查询天气。请根据用户的问题判断是否需要使用工具。如果需要请精确地调用工具。工具调用结果返回后请用自然语言总结并回答用户。” ) # 4. 运行一个简单的对话循环 async def main(): print(“天气查询智能体已启动。输入 ‘退出’ 或 ‘quit’ 结束。”) while True: try: user_input input(“\n你 “).strip() if user_input.lower() in [“退出”, “quit”, “exit”]: print(“再见”) break if not user_input: continue print(“助手”, end“”, flushTrue) # 流式输出响应 async for chunk in agent.stream_chat(user_input): print(chunk, end“”, flushTrue) print() # 换行 except KeyboardInterrupt: print(“\n程序被中断。”) break except Exception as e: print(f“\n发生错误{e}”) if __name__ “__main__”: asyncio.run(main())关键配置解析model_client这是与模型API交互的客户端。SkillClaw 通过适配器抽象通常要求传入一个符合特定接口如 OpenAI SDK 接口的客户端对象。这使得它可以灵活对接 OpenAI、Azure OpenAI、以及任何提供兼容API的服务如 Ollama、vLLM、Together AI 等。system_prompt系统提示词是引导模型行为的关键。在这里我们明确告诉模型它的角色、它能做什么使用工具以及它应该如何与工具交互精确调用用自然语言总结。一个好的系统提示词能显著提升工具调用的准确性和回复的友好度。stream_chat这个方法实现了流式响应对于生成较长文本的模型能提升用户体验感觉响应更快。4.4 运行与测试确保 Ollama 服务正在运行并且qwen2.5:7b模型已下载。ollama serve ollama pull qwen2.5:7b运行你的智能体python main.py进行测试对话你 今天北京天气怎么样 助手 模型思考后调用 get_weather 工具获取结果再生成回复北京当前天气晴朗温度25°C湿度40%风速10km/h是个好天气。 你 那上海呢 助手 模型能结合上下文知道“上海”指的是天气查询再次调用工具上海今天多云温度28°C湿度75%风速15km/h感觉比较闷热。通过这个简单的例子你已经完成了一个具备真实工具调用能力的智能体雏形。SkillClaw 框架帮你处理了最复杂的部分让模型理解工具、生成正确的调用格式、管理调用流程。5. 进阶应用与架构思考掌握了基础用法后我们可以探讨更复杂的场景这也是 SkillClaw 这类框架真正发挥威力的地方。5.1 技能依赖与组合现实任务很少只靠一个工具完成。比如“帮我将这篇中文新闻翻译成英文并总结大意”。这可能需要1) 一个网页抓取技能获取新闻正文2) 一个翻译技能3) 一个文本摘要技能。在 SkillClaw 中你可以通过几种方式实现顺序调用在智能体的对话循环中模型可以自主决定依次调用多个技能。这要求模型有较好的任务分解能力。复合技能定义一个高级技能如translate_and_summarize_news在其execute方法内部编程式地按顺序调用底层的fetch_webpage、translate_text、summarize_text等技能并处理它们之间的数据传递。这样对模型来说它只调用了一个“大”技能复杂性被封装在内部。工作流引擎对于极其复杂的流程可以集成外部的流程编排引擎如 Airflow、Prefect 的轻量级任务SkillClaw 的智能体只负责触发这个工作流并等待其返回最终结果。选择哪种方式取决于任务的复杂性、对可控性的要求以及模型的规划能力。简单的、模型能很好分解的任务用顺序调用更灵活复杂的、有固定业务逻辑的用复合技能更可靠。5.2 技能的动态注册与发现在微服务或插件化架构中技能可能不是静态定义的。SkillClaw 通常支持动态注册技能。这意味着你可以在智能体运行时根据配置、数据库或服务发现机制动态地添加或移除技能。例如你可以有一个技能注册中心Skill Registry Service。当一个新的微服务上线它自动向注册中心注册自己提供的技能描述。智能体定期从注册中心拉取最新的技能列表并通过适配器更新给模型。这就实现了能力的“热插拔”系统扩展性大大增强。实现动态注册时要注意技能描述的版本管理和兼容性。模型一旦学习了旧的技能描述如果新版本的描述发生重大变化如参数改名、含义改变可能导致模型调用错误。需要有平滑的升级和回滚策略。5.3 验证、授权与安全性当智能体能够调用外部工具时安全就成了头等大事。输入验证与净化每个技能的execute方法必须对其输入参数进行严格的验证。例如数据库查询技能要防止SQL注入文件操作技能要限制路径访问范围。SkillClaw 框架层面也应提供基础的参数验证机制基于JSON Schema。权限控制不是所有用户都能调用所有技能。需要在智能体调用技能前加入一层授权检查。可以根据用户身份、会话上下文等动态过滤掉用户无权使用的技能列表再提供给模型。或者在技能执行时进行权限校验。沙箱环境对于执行不确定代码如计算表达式或处理不可信数据的技能应考虑在沙箱环境中运行以隔离潜在风险。用量与审计记录每一次工具调用包括调用者、参数、结果、耗时。这对于监控、计费、问题排查和后续的模型行为优化都至关重要。5.4 与现有系统的集成SkillClaw 智能体很少是孤立的。它需要被集成到更大的应用系统中。作为API服务将 SkillClaw 智能体封装成 RESTful API 或 gRPC 服务供前端、移动端或其他后端服务调用。这时需要考虑并发、负载均衡、会话管理保持多轮对话的上下文等问题。作为消息机器人集成到 Slack、Discord、钉钉、飞书、微信等即时通讯平台。需要处理各平台不同的消息格式和回调机制。嵌入业务流水线在自动化业务流程中作为决策节点或执行节点。例如在客服工单系统中智能体根据工单内容自动调用知识库查询、客户信息检索等技能为人工客服提供建议。6. 常见问题、排查技巧与优化实录在实际部署和开发中你会遇到各种各样的问题。下面是一些典型问题及其解决思路。6.1 模型不调用工具或调用错误这是最常见的问题。症状用户的问题明显需要工具但模型只生成文本回答不触发工具调用。排查检查系统提示词系统提示词是否清晰、强硬地指示模型使用工具尝试强化提示例如“你必须使用提供的工具来回答问题。在回答前先思考是否需要使用工具。如果需要请输出工具调用不要直接回答。”检查工具描述工具的名称和描述是否清晰、无歧义描述是否准确反映了工具的功能模型是通过描述来理解工具用途的。尝试用更简单、更直接的语言重写描述。检查参数描述参数描述是否足够详细模型需要知道每个参数期望输入什么。例如date参数描述为“日期格式为 YYYY-MM-DD”就比“日期”要好得多。提供少量示例Few-shot在系统提示词或初始对话中提供一两个用户查询和正确调用工具的示例。这对于引导开源模型特别有效。调整模型温度Temperature过高的温度如 0.8会增加随机性可能导致模型“创造性”地忽略工具调用。尝试降低温度如 0.1-0.3让模型输出更确定性、更遵循指令。检查适配器确认你使用的模型适配器是否正确对于不支持原生 function calling 的模型是否使用了正确的提示词模板适配器6.2 工具调用参数解析失败症状模型试图调用工具但传入了错误的参数格式或值导致技能执行失败。排查启用详细日志查看 SkillClaw 框架和模型API的详细日志确认模型原始返回的调用格式是什么适配器解析后得到了什么。这能帮你定位是模型生成格式不对还是适配器解析有误。参数类型约束在工具定义的 JSON Schema 中充分利用type,enum,pattern(正则表达式) 等字段来约束参数。这能给模型更明确的指导。后处理与修正在适配器解析后、技能执行前可以加入一个参数后处理环节。例如如果city参数可能包含多余的空格或标点可以在这里进行清洗和标准化。模型微调如果某个工具的调用格式特别复杂或容易出错可以考虑收集一批正确调用该工具的对话数据对模型进行少量参数的微调LoRA专门提升其调用该工具的准确性。6.3 多轮对话中上下文混乱症状在长对话中模型可能忘记之前用过的工具结果或者混淆不同工具调用的上下文。排查与优化管理对话历史长度大模型有上下文窗口限制。需要设计一个策略来修剪或总结过长的对话历史。常见的做法是保留最近的 N 轮交互或者将早期不重要内容进行摘要。清晰的消息角色确保在传递给模型的 messages 列表中严格区分system,user,assistant,tool等角色。特别是tool角色的消息要清晰表明是哪个工具调用tool_call_id返回的结果。结构化工具结果工具返回的结果尽量结构化、简洁。避免返回大段的、噪音多的文本。可以在技能内部对原始API结果进行提取和格式化只保留模型生成回答所需的关键信息。6.4 性能瓶颈症状智能体响应慢尤其是需要连续调用多个工具时。优化并行工具调用如果多个工具调用之间没有依赖关系可以尝试让模型一次性生成多个工具调用请求然后并行执行它们。这需要模型和框架都支持并行工具调用Parallel Tool Calling。技能执行异步化确保所有技能的execute方法都是异步的并且内部涉及 I/O 的操作网络请求、数据库查询使用异步库如aiohttp,asyncpg避免阻塞事件循环。缓存对于结果变化不频繁的工具调用如某些配置查询、静态数据获取可以引入缓存机制在短时间内相同的请求直接返回缓存结果减少对模型和外部服务的调用。模型推理优化使用量化模型、更高效的推理引擎如 vLLM, TensorRT-LLM来加速模型本身的响应速度。6.5 技能执行失败的处理症状工具调用成功但执行时出错如网络超时、API返回错误。最佳实践技能内部重试对于暂时的网络故障可以在技能内部实现简单的重试逻辑如最多3次指数退避。向模型反馈清晰的错误技能execute方法捕获异常后返回的错误信息应该对模型友好。例如“获取天气数据失败网络连接超时。请稍后再试。” 而不是一堆 Python 异常栈信息。模型可以根据这个信息生成对用户友好的回复。设置超时为所有外部调用设置合理的超时时间防止一个慢速工具拖垮整个智能体响应。熔断与降级对于频繁失败的工具可以引入熔断器机制暂时将其禁用并通知模型该工具暂时不可用或许可以尝试替代方案。开发基于 SkillClaw 这类框架的智能体应用是一个不断迭代和调优的过程。从定义好工具开始通过观察模型在实际对话中的表现反复优化提示词、工具描述、错误处理逻辑才能打磨出一个既聪明又可靠的智能助手。它不仅仅是技术的堆砌更是对业务逻辑、用户体验和系统稳定性的深度思考。