第5篇Skill的工具集成——调用外部能力的艺术适用人群基础→进阶 | 字数约25,000字 | 预计阅读时间60分钟前言在前四篇中我们创作的 Skill 都是纯文本型的——基于 AI 自身的语言理解和生成能力对用户输入的信息进行处理和加工。但纯文本型 Skill 有一个根本性的局限它只能处理「用户已经提供」的信息。这意味着如果用户问今天的新闻而用户没有在输入中粘贴新闻——Skill 无法获取新闻如果用户问我的数据库里有多少用户而用户没有提供数据——Skill 无法查询如果用户说把结果发到群里——Skill 无法发送消息突破这个局限的关键就是工具集成。工具是 Skill 的手脚——它让 AI 不再只是一个会说话的大脑而是一个能行动的智能体。这一篇我们系统性地讲解工具集成——从工具的基本概念、配置方法到高级的调用策略和安全设计。第一章为什么需要工具1.1 LLM 的能力边界大语言模型确实很强大但它有三个固定的能力边界边界一知识边界LLM 的知识截止于训练数据的时间点。如果你问昨天发生了什么新闻LLM 如果不知道具体日期或者训练数据不包含昨天的信息——它无法回答。没有工具 → 我无法获取实时信息我的知识截止于…… 有搜索工具 → 调用搜索API → 根据最新消息昨天发生了……边界二信息边界LLM 只能访问你在对话中提供给它的信息。它无法看到你的数据库、你的文件系统、你的企业内部系统。没有工具 → 我无法查询您的账户信息请提供…… 有数据库工具 → 调用数据库查询 → 您的账户余额是……边界三操作边界LLM 只能在对话框里生成文字。它无法操作任何外部系统——不能发邮件、不能创建文档、不能发送消息。没有工具 → 您可以按照以下步骤操作…… 有消息工具 → 调用发送消息 → 已经为您发送了通知工具就是用来突破这三个边界的。1.2 工具给 Skill 带来的三个新能力当 Skill 集成了工具它会获得三种之前不具备的能力能力一实时信息获取Skill 可以主动获取用户没有提供、但任务需要的信息。场景用户问今天适合去公园玩吗 无工具的 Skill请提供您所在城市的天气信息。 有工具的 Skill自动调用天气查询 → 北京今天25°C晴非常适合外出能力二私有数据访问Skill 可以访问企业的内部数据和系统。场景用户问我的项目进度如何 无工具的 Skill请提供您的项目进度信息。 有工具的 Skill自动调用项目管理系统 → 您的项目A目前进度65%本周完成了……能力三真实世界操作Skill 可以执行真实世界中的操作——而不再只是说说而已。场景用户说把会议纪要让张三和李四都看看 无工具的 Skill好的建议您把会议纪要分享给张三和李四。 有工具的 Skill自动调用消息发送工具 → 已将会议纪要发送给张三和李四。1.3 没有工具的 Skill vs 有工具的 Skill场景没有工具有工具用户说查一下今天的新闻“请提供关键词”自动搜索→返回新闻用户说把结果发到群里“好的复制这份内容去发吧”自动发送到指定群聊用户说帮我查这个股票“请提供股票代码”自动查询实时行情用户说设置一个明天3点的提醒“好的记得明天3点……”自动创建日历事件用户说分析这份PDF“请粘贴PDF内容”自动读取PDF→分析内容有工具的 Skill 和没有工具的 Skill体验差距是代际的。第二章工具的基础概念2.1 什么是工具在 Skill 系统中工具Tool是一个可以被 AI 调用的外部函数或 API。每个工具包含四个要素名称工具的唯一标识 → web_search、query_weather、send_message 描述告诉 AI 这个工具是干什么的、什么时候该用 → 搜索互联网获取最新信息。当用户问实时信息、新闻、最新动态时使用。 参数调用这个工具需要提供什么信息 → query搜索关键词 → count返回结果数量 规则什么情况下可以调用什么情况下不能 → 只在用户明确需要时调用 → 不用于数学计算2.2 工具的分类按功能可以把工具分为四大类型第一类信息获取型工具功能从外部获取信息扩展 AI 的知识范围。搜索工具web_search → 搜索互联网获取实时信息 → 参数关键词、结果数量 → 适用新闻查询、知识问答、资料检索 天气工具query_weather → 查询指定城市的天气 → 参数城市名称、日期 → 适用出行建议、活动规划 数据库查询工具query_database → 查询数据库中的记录 → 参数查询语句 → 适用内部数据查询 文档读取工具read_document → 读取指定文档的内容 → 参数文档路径、页码 → 适用文档分析、内容提取第二类操作执行型工具功能在外部系统中执行操作。消息发送工具send_message → 发送消息到指定渠道 → 参数接收人、内容、渠道 → 适用通知、分享、推送 文档创建工具create_document → 创建新的文档 → 参数标题、内容、格式 → 适用自动生成报告、保存纪要 日历管理工具manage_calendar → 创建/修改/查询日程 → 参数时间、标题、参与人 → 适用会议安排、日程管理 任务管理工具manage_task → 创建/更新待办事项 → 参数任务内容、负责人、截止日期 → 适用自动创建待办第三类计算处理型工具功能执行需要精确计算或特定处理的任务。代码执行工具execute_code → 执行指定的代码并返回结果 → 参数代码内容、语言 → 适用数学计算、数据处理、算法验证 数据转换工具transform_data → 在不同格式间转换数据 → 参数源数据、目标格式 → 适用CSV转JSON、文本转表格 图像处理工具process_image → 对图像进行处理 → 参数图片、操作类型 → 适用图片分析、格式转换第四类复合工具功能组合多个基础操作完成更复杂的任务。汇报生成工具generate_report → 查询数据 → 分析数据 → 生成报告 → 保存报告 → 分享报告 → 这实际上是多个工具的组合调用 审批流程工具approval_flow → 提交审批 → 通知审批人 → 记录审批结果 → 通知申请人 → 涉及多个步骤和多个参与者2.3 工具的描述——最重要的配置工具描述的质量直接决定了 AI 能不能在正确的时机调用工具。来看一个对比❌ 差的描述 搜索工具。 AI 的困惑 - 什么时候该用——不知道 - 能干什么——不知道 - 用了之后能得到什么——不知道 ✅ 好的描述 搜索互联网获取最新信息。当用户询问新闻、最新动态、实时数据、某个具体知识点时使用。 不要用这个工具做数学计算或查询天气有其他工具负责。 参数 query 应该简洁只包含核心关键词不要使用完整的问句。 AI 的理解 - 什么时候用用户问新闻/实时信息时 - 什么时候不用做计算、查天气时 - 参数怎么填只用关键词不用完整句子写工具描述的三段式法则第一段功能说明——这个工具是做什么的 搜索互联网获取最新信息。 第二段使用场景——什么情况下应该调用 当用户询问新闻、最新动态、实时数据、某人或某事的最新情况时使用。 第三段使用注意事项——怎么用效果最好、什么时候不能用 参数 query 应该简洁只包含核心关键词。 不要用这个工具做数学计算。 如果搜索结果为空如实告知用户。2.4 工具的参数定义每个工具的入参都需要明确定义。参数定义的质量决定了 AI 能不能正确调用工具。一个完整的参数定义 参数名query 类型string 必填是 说明搜索关键词。应该简洁只包含核心词语不要使用完整问句。 示例 ✅ 2026年A股市场走势 ❌ 我想知道2026年A股市场的走势情况你能帮我查一下吗 参数名count 类型number 必填否 默认值5 说明返回的搜索结果数量。范围 1-20。参数定义的关键原则参数名要有意义——query比q好city_name比c好说明要具体——简洁的关键词比搜索词好给出示例——✅的写法和❌的写法比请正确填写好默认值要合理——用户不填的情况下也能正常工作第三章工具调用的流程3.1 从用户请求到工具调用——完整路径当一个集成了工具的 Skill 被触发时工具调用的完整流程如下用户请求 今天北京的天气怎么样适合跑步吗 Step 1Skill 引擎接收请求 → 加载 Skill 配置和工具列表 → 组装 Prompt Step 2LLM 分析请求 → 理解意图用户想知道北京天气 跑步建议 → 判断需要信息需要北京的天气数据 → 决定调用工具query_weather(北京, 2026-05-21) Step 3系统执行工具 → 执行 query_weather 函数 → 获取天气 API 返回的数据 → 将结果返回给 LLM Step 4LLM 基于工具结果继续推理 → 天气数据{temperature: 25, condition: 晴, aqi: 良} → 结合跑步场景进行推理 → 生成最终建议 Step 5输出最终回答 → 北京今天25°C晴朗空气质量良非常适合户外跑步 建议清晨或傍晚时段跑步避开中午高温。3.2 工具调用的触发条件工具不是任何时候都应该被调用的。AI 需要判断是否真的需要调用工具。需要调用工具的情况情况一用户明确要求 帮我查一下…… → 触发搜索/查询工具 把结果发到…… → 触发消息工具 情况二任务天然需要外部信息 用户问天气 → 不需要用户说帮我查直接触发天气工具 用户问新闻 → 直接触发搜索工具 情况三可以提升输出质量 用户说分析一下市场趋势 → 可以不调用工具直接分析但可能泛泛而谈 → 也可以调用搜索工具获取最新数据后再分析更精准不需要调用工具的情况情况一AI 自身知识足够 用户问什么是机器学习 → 不需要搜索直接回答 情况二用户没有要求外部信息 用户说帮我改写这段文字 → 不需要调用工具 情况三工具调用可能不合适 用户问11等于几 → 不需要调用计算器如何让 AI 做出正确的判断关键在于工具描述的使用场景部分写得够不够清晰。3.3 多工具调用的顺序当任务需要调用多个工具时AI 需要决定先调哪个、后调哪个。场景用户说查一下北京的天气然后把结果发给张三。 工具调用顺序 第1步query_weather(北京) → 获取天气数据 第2步send_message(张三, 北京今天天气……) → 发送结果 为什么第1步必须是天气查询 因为发送消息需要发送什么内容——这个内容要来自天气查询的结果。 多工具调用的黄金法则 先获取信息再使用信息。 工具调用的顺序由信息的依赖关系决定。3.4 工具调用结果的整合工具返回的结果通常是结构化的数据JSON需要被整合到自然语言输出中。工具返回结果 { city: 北京, date: 2026-05-21, temperature: 25, condition: 晴, humidity: 30, wind: 3级 } 整合到回答中 北京明天5月21日天气晴朗气温25°C湿度30%微风。 天气条件非常适合户外活动整合的关键原则不要直接输出原始 JSON——用户看不懂提取关键信息去掉冗余字段用自然语言组织——让用户读起来自然标注数据来源——“根据天气预报……”第四章工具的安全设计4.1 为什么安全特别重要工具是 Skill 的手脚——这意味着 Skill 可以真正地影响外部世界。如果工具调用出错或被人恶意利用搜索工具用错了 → 得到错误信息消息工具用错了 → 发消息给了错误的人文档工具用错了 → 创建或删除了错误的文件普通提示词的错误后果是回答错了。工具调用的错误后果可能是事情做错了。所以工具集成的安全设计不是锦上添花而是必须有的护栏。4.2 工具调用的权限分级根据操作的风险等级把工具调用分为三个权限级别第一级自动执行无风险 这类工具只会读取信息不会修改任何数据或发送任何通知。 例子 - 搜索互联网 - 查询天气 - 读取文档 规则AI 可以根据需要自动调用无需用户确认。 第二级通知后执行低风险 这类工具会执行操作但操作是可逆的或影响较小。 例子 - 发送消息可以先告诉用户我要发了 - 创建草稿文档 - 设置个人提醒 规则AI 可以先告知用户我要做这件事了如果用户没有阻止再执行。 第三级用户确认后执行中高风险 这类工具执行的操作不可逆或有较大影响。 例子 - 删除文件 - 发送正式邮件 - 修改系统配置 - 涉及费用的操作 规则必须等用户明确确认可以执行后才能调用工具。4.3 在指令中定义工具的使用规则在 Skill 的约束条件中明确定义工具的使用规则【工具使用规则】 1. 搜索工具web_search - 自动调用条件用户询问实时信息、新闻、最新动态 - 调用前检查确认参数 query 是否简洁明确 - 调用后处理将搜索结果用自己的话总结后回答 2. 消息工具send_message - 自动调用条件用户明确要求发送、分享、通知 - 调用前检查确认收件人和发送内容无误 - 特别规则如果收件人不明确先询问用户发给谁 3. 所有工具通用的规则 - 每次只能调用一个工具 - 工具调用失败时告知用户并提供替代方案 - 不确定参数时先问用户再调用 - 不要连续重复调用同一个工具可能陷入死循环4.4 工具调用的审计对于生产环境中的 Skill每个工具调用都应该被记录工具调用审计日志 [2026-05-21 08:00:00] Skill「每日简报」触发 [2026-05-21 08:00:01] 工具调用web_search({query: 科技行业新闻 2026-05-20}) [2026-05-21 08:00:03] 工具返回10条结果 [2026-05-21 08:00:05] 工具调用send_message({to: 团队群, content: 今日简报…}) [2026-05-21 08:00:06] 工具返回发送成功 [2026-05-21 08:00:07] Skill 执行完成总耗时 7 秒审计日志的作用回溯问题——如果工具调用的结果有问题可以追溯到具体是哪次调用安全监控——检测异常调用模式如短时间内大量调用成本分析——统计每个工具的使用频率和成本第五章工具集成的常见场景与实战案例5.1 场景一信息获取 Skill——“财经资讯”功能用户输入关键词Skill 自动搜索最新相关新闻并汇总。工具配置{tool:web_search,description:搜索互联网获取最新财经新闻,parameters:{query:{type:string,description:搜索关键词应该简洁}}}指令系统中的工具使用引导【工具使用说明】 你有一个可用的搜索工具web_search。 使用场景 1. 用户询问最近的财经新闻、今天的股市动态、XX公司的消息 2. 用户输入关键词要求你查找相关信息 使用规则 1. 从用户输入中提取核心关键词作为搜索参数 2. 搜索结果返回后筛选出与用户需求最相关的 3-5 条 3. 用自己的话总结每条新闻的核心内容 4. 标注每条新闻的来源和时间 输出格式 # 财经资讯摘要 生成时间{当前时间} ## 【标题1】 100字以内的内容摘要 来源{来源} | {时间} ## 【标题2】 ……5.2 场景二消息推送 Skill——“每日简报”功能每天定时获取信息处理后推送到指定渠道。工具配置[{tool:web_search,description:搜索获取最新信息},{tool:send_message,description:发送消息到指定群聊或个人}]指令系统中的流程定义【执行流程】 这是一个定时触发的 Skill每天早上 08:00 自动执行。 Step 1搜索最新信息 使用搜索工具搜索以下关键词 - 科技行业新闻 - 今日财经要闻 - 行业动态 Step 2整理简报 从搜索结果中筛选出最重要的 3-5 条新闻 每条用 50-100 字总结核心内容 Step 3发送简报 将整理好的简报通过消息工具发送到目标群聊 【注意事项】 1. 搜索结果必须是今天的定时任务触发当天 2. 如果搜索结果不足 3 条据实输出已有结果 3. 发送前确认内容格式正确5.3 场景三数据处理 Skill——“数据查询助手”功能用户用自然语言查询数据Skill 自动查询数据库并返回结果。工具配置{tool:query_database,description:查询业务数据库。可查询用户信息、订单数据、产品数据等。,parameters:{sql:{type:string,description:SQL 查询语句}}}指令系统中的安全约束【工具使用规则】 你有一个数据库查询工具。使用规则如下 可以查询的数据表 - users用户信息 - orders订单数据 - products产品信息 禁止执行的查询 - 涉及密码、Token 等敏感字段 - 涉及其他用户的数据除非有明确权限 - 写操作INSERT、UPDATE、DELETE、DROP、ALTER 等 查询生成规则 1. 从用户输入中理解需要什么数据 2. 生成对应的 SQL 查询语句 3. 只查询必要的字段不 SELECT * 4. 如果用户的需求不明确先问清楚再查询5.4 场景四多工具协作 Skill——“会议安排助手”功能用户说安排一个会议Skill 自动查询参会人忙闲、建议时间、创建日程、通知参会人。指令系统的流程定义【执行流程】 Step 1收集会议信息 询问用户会议主题、预计时长、参会人、期望日期 Step 2查询忙闲 使用日历查询工具查询所有参会人在期望日期的忙闲状态 Step 3推荐时间 基于忙闲数据推荐所有参会人都空闲的时间段 Step 4创建日程 用户确认时间后使用日历创建工具创建会议日程 Step 5通知参会人 使用消息工具发送会议邀请通知给所有参会人第六章工具集成的常见问题问题1工具调用时机不对表现AI 在不该调用工具的时候调用了或者在该调用的时候没调用。原因工具描述中的使用场景写得不清楚。解决方案在工具描述中明确写出应该调用和不应该调用的场景搜索互联网获取最新信息。 ✅ 应该调用的场景 - 用户询问新闻、最新动态、实时数据 - 用户提及某个具体事件的最新进展 - 当前时间{{current_time}}之后发生的事 ❌ 不应该调用的场景 - 用户问的是常见知识如什么是人工智能 - 用户要求的是创意内容如写一首诗 - 数学计算问题2工具参数提取不准确表现AI 从用户输入中提取的参数不对——搜索关键词太长、城市名错了等。原因参数说明不够详细。解决方案参数说明中给出正确写法和错误写法的示例参数query 说明搜索关键词。应该简洁只包含核心词语。 ✅ A股 2026 走势 ✅ 特斯拉 新车 发布 ❌ 我想知道2026年A股市场的走势情况你能帮我详细查一下吗 ❌ 帮我搜索一下关于特斯拉最近有没有发布新车的相关信息问题3工具调用失败后的处理表现工具调用失败了AI 不知道该怎么办——可能直接告诉用户失败了也可能假装成功。解决方案在指令中加入失败处理规则【工具调用失败处理】 如果工具调用失败 1. 自动重试 1 次 2. 如果重试仍然失败 - 告知用户暂时无法获取该信息 - 解释失败的可能原因网络问题、参数不正确等 - 提供替代方案您可以尝试换一个关键词 如果工具返回结果为空 1. 告知用户没有找到相关结果 2. 建议用户调整搜索词或换个角度提问 3. 不要编造不存在的结果问题4工具的幻觉——AI 假装调用了工具表现AI 没有实际调用工具但输出中声称已为您查询到……——内容实际上是 AI 编造的。原因约束条件不够明确。解决方案在约束条件中明确【重要工具调用诚实规则】 1. 每次声称已查询或已搜索时后台必须有真实的工具调用记录 2. 如果信息来自 AI 自身知识而非工具调用必须注明根据已有知识 3. 严禁编造工具调用的结果 4. 不确定是否有工具调用时宁愿承认我无法访问实时信息第七章从单工具到多工具系统7.1 多工具 Skill 的设计原则当一个 Skill 需要集成多个工具时设计复杂度显著增加。以下是核心设计原则原则一职责明确 每个工具有清晰的职责边界避免功能重叠。 重叠的例子 tool_a: 搜索新闻 tool_b: 获取最新资讯 → AI 困惑查新闻该用哪个 清晰的例子 tool_a: 搜索互联网获取信息包括新闻、百科、论坛等 tool_b: 查询特定数据库的记录 → 各司其职AI 清楚选择 原则二触发条件互斥 任何用户输入至多只能触发一个工具——避免冲突。 如果两个工具的触发条件重叠合并或重新划分。 原则三按依赖关系排序 如果工具 B 需要工具 A 的输出结果确保 AI 先调用 A 再调用 B。 在流程中明确标注依赖关系。 原则四有无需工具的选项 不是每个请求都需要调用工具。AI 应该有不需要工具也能回答的能力。 在指令中加入如果用户的问题不需要实时信息直接回答即可。7.2 工具的选择策略当一个 Skill 有多个可用工具时AI 需要决定用哪一个。在指令中定义选择策略【工具选择策略】 当用户提出请求后按以下顺序判断是否需要调用工具 第1步判断是否需要外部信息 - 用户问的是事实性问题如什么是……→ 不需要工具直接回答 - 用户问的是实时信息如今天的……→ 需要工具 第2步判断需要什么类型的工具 - 用户问的是新闻、最新消息、动态 → 使用搜索工具 - 用户问的是天气、气温 → 使用天气工具 - 用户要求发送、分享、通知 → 使用消息工具 - 用户要求查询数据、看报表 → 使用数据查询工具 第3步如果判断不清 - 先用搜索工具尝试获取 - 如果搜索结果不理想告知用户并建议换一种问法第八章工具的反模式——常见错误反模式1过度依赖工具表现即使不需要调用工具的任务也去调用工具。用户问11等于几AI 调用了计算器用户问什么是AIAI 调用了搜索。后果响应变慢、浪费资源、用户体验下降。解决方案在工具描述中明确不需要调用工具的场景。反模式2工具配置过于复杂表现一个 Skill 配置了 10 个工具。AI 在选择用哪个工具上就花了很多时间而且经常选错。后果AI “选择困难”输出质量下降。解决方案每个 Skill 的工具数量控制在 1-3 个。如果需要更多工具考虑拆分成多个 Skill。反模式3忽略工具调用成本表现每次调用都搜索 20 条结果、每次都用最贵的 API。不考虑工具调用的成本和效率。后果使用成本高、响应速度慢。解决方案在参数中使用合理的默认值如搜索只返回 5 条结果避免不必要的工具调用使用缓存相同查询不重复调用反模式4安全约束不到位表现工具可以在没有安全约束的情况下自由调用——AI 可以随意发送消息、查询敏感数据。后果安全风险极高。解决方案每个工具都要有明确的安全边界和使用规则。高风险操作需要用户确认。第九章工具调用的调试与优化9.1 工具调用日志分析当工具调用出现问题时第一步是查看调用日志日志示例 [10:00:00] 用户输入帮我查一下今天的新闻 [10:00:01] 工具调用web_search({query: 帮我查一下今天的新闻}) [10:00:01] 问题参数 query 包含了完整问句不是简洁关键词 → 应该改成 {query: 今日新闻}通过日志分析可以识别出常见的工具调用问题常见问题1参数提取错误 AI 没有从用户输入中提取关键词而是把整句话当成了参数。 解决方案在参数说明中增加示例 常见问题2工具选择错误 AI 用错了工具如用天气工具查新闻。 解决方案检查工具描述是否清晰区分了使用场景 常见问题3不必要的调用 AI 在不该调用工具的时候调用了。 解决方案在指令中加入判断逻辑如果……才调用 常见问题4调用时序错误 多工具调用时顺序搞错了先发消息才查数据。 解决方案在流程中明确定义依赖关系9.2 工具参数的预填优化有时候 AI 从用户输入中提取的参数不够准确。可以通过预填来引导方式一在指令中定义参数提取规则 从用户输入中提取城市名称。如果用户输入是北京今天天气提取北京。 如果用户输入是上海呢注意对话历史中已经提到的城市。 如果用户没有提到任何城市使用默认城市从用户配置中获取。 方式二给参数提取的示例 参数提取示例 用户说北京今天天气怎么样 → city北京 用户说上海下雨吗 → city上海 用户说明天冷吗 → city默认城市从上下文获取 用户说查天气 → 反问用户请问您查哪个城市 方式三提供候选值列表 城市参数只能使用以下值北京、上海、广州、深圳、杭州、成都 如果用户提到的城市不在列表中告知用户暂不支持该城市。9.3 工具调用的降级策略当工具不可用时API 故障、网络问题、权限不足Skill 需要有降级策略一级降级自动重试 工具调用失败 → 自动重试 1 次 适用场景临时性网络波动 二级降级使用缓存 重试仍然失败 → 检查是否有历史缓存数据 如果有缓存 → 使用缓存数据 标注数据可能不是最新的 适用场景查询类工具 三级降级告知用户 缓存也没有 → 告知用户暂时无法获取实时信息 提供替代方案 适用场景所有工具 四级降级人工介入 如果工具调用连续失败 3 次以上 记录错误日志 通知系统管理员 适用场景生产环境9.4 工具调用的效率优化工具调用通常比纯 AI 推理慢得多API 调用需要网络往返。优化效率的几种方法优化方法1减少不必要的调用 在调用前先判断这个信息真的是必须的吗 如果 AI 自身知识足够就不调用工具。 优化方法2合并调用 如果两个工具调用没有依赖关系可以同时调用。 例如查天气 查新闻 可以同时进行。 优化方法3精简参数 查询数据库时只查需要的字段不 SELECT *。 搜索时用5条结果而不是20条结果。 优化方法4使用缓存 对于相同的查询缓存结果避免重复调用。 缓存有效期根据信息的时效性设定 - 实时信息新闻、股价几分钟 - 日更信息天气几小时 - 静态信息百科天/周第十章从工具集成到能力生态10.1 工具的平台化当组织中的工具越来越多时需要对工具进行平台化管理工具注册中心 ┌─────────────────────────────────────────────┐ │ 工具名称 │ 用途 │ 状态 │ │ ├─────────────────────────────────────────────┤ │ web_search │ 搜索互联网 │ ✅ 可用 │ │ │ query_db │ 查询数据库 │ ✅ 可用 │ │ │ send_msg │ 发送消息 │ ⚠️ 维护中│ │ │ create_doc │ 创建文档 │ ✅ 可用 │ │ │ query_weather│ 查询天气 │ ✅ 可用 │ │ └─────────────────────────────────────────────┘平台化管理的好处工具复用——同一个工具可以被多个 Skill 共享统一维护——工具更新一次所有使用它的 Skill 自动受益权限管理——集中控制工具的访问权限监控和统计——统一监控所有工具的使用情况10.2 工具的组合创新当工具足够多时通过组合创新可以创造出全新的能力基础工具搜索 文档 消息 组合创新1搜索 文档 自动调研报告 搜索信息 → 整理结构 → 保存为文档 组合创新2文档 消息 内容分发系统 读取文档内容 → 生成摘要 → 推送到多个渠道 组合创新3搜索 消息 实时监控系统 定时搜索 → 检测变化 → 推送告警10.3 工具集成的未来趋势趋势1工具的零配置 未来的工具将不再需要手动配置——AI 自动发现、自动接入、自动使用。 趋势2工具的自描述 工具会自带使用说明书AI 可以通过读取工具的自我描述来学会使用。 趋势3工具的组合推荐 系统会自动推荐哪些工具可以组合使用——就像手机 App 建议你用这两个 App 可以联动。 趋势4工具的安全自治 工具会自己判断当前调用是否安全不需要完全依赖外部的安全规则。第十一章实战——为 Skill 添加工具调用的完整步骤当你准备好为自己的 Skill 添加工具能力时按以下步骤操作11.1 步骤一明确工具需求问自己三个问题 ① 我的 Skill 缺少什么信息→ 需要信息获取型工具 ② 我的 Skill 需要做什么操作→ 需要操作执行型工具 ③ 我的 Skill 需要什么计算能力→ 需要计算处理型工具 示例 会议纪要 Skill 目前只处理用户粘贴的内容。 用户问这个项目之前的背景是什么 → 缺少背景信息 → 需要搜索工具11.2 步骤二选择并配置工具① 从工具库中选择合适的工具 ② 编写工具描述三段式功能场景注意事项 ③ 定义参数名称类型说明示例默认值 ④ 设定使用规则什么情况下用、什么情况下不用 配置示例 { tool: web_search, description: 搜索互联网获取信息。用于补充会议中提到的专有名词或项目背景。, parameters: { query: 搜索关键词 }, rule: 只在会议内容中提到不明术语时调用 }11.3 步骤三在指令系统中整合工具在角色设定中加入工具的使用意识 当你发现会议内容中提到了你不熟悉的专有名词、项目名称或缩写 可以使用搜索工具获取背景信息。搜索到的信息以参考资料形式附在纪要末尾。 在处理流程中加入工具的调用节点 Step 2.5识别不明术语 检查会议内容中是否有需要搜索补充的专有名词 如果有调用搜索工具获取背景信息11.4 步骤四测试工具调用测试清单 □ 工具是否在正确的时机被调用 □ 工具参数是否提取正确 □ 工具返回的结果是否被正确整合到输出中 □ 如果工具调用失败是否按预期降级处理 □ 多次运行是否稳定11.5 步骤五持续监控发布后关注 - 工具调用的频率是否合理 - 工具调用的成功率失败率是否过高 - 工具调用的参数质量是否经常提取错误 - 用户对工具增强后的反馈是否有帮助写在最后工具集成是 Skill 从会说到会做的关键一步。回顾本章的核心要点工具突破 LLM 的三边界知识边界、信息边界、操作边界工具的四个要素名称、描述、参数、规则工具描述的质量决定调用准确率——写清楚什么时候用、什么时候不用安全是工具集成的生命线——权限分级、使用规则、审计日志1-3 个工具最合适——太多工具会让 AI 选择困难当你的 Skill 有了工具调用能力它就不再只是一个会聊天的 AI而是一个能帮你做事的 AI 助手。课后练习设计练习为你的会议纪要整理 Skill增加一个搜索工具——当会议内容中提到某个不熟悉的专有名词时自动搜索补充背景信息。安全设计练习为上述场景设计安全规则——什么情况下可以自动搜索搜索的结果怎么整合到纪要中怎么避免搜索无关内容多工具练习设计一个每日工作简报 Skill需要调用搜索工具、文档工具和消息工具——描述它们的协作流程。下一篇预告《第6篇Skill的状态管理与上下文控制》当 Skill 需要多轮对话、需要记住前面说了什么、需要在多次使用之间保持状态——就需要状态管理。下一篇讲解让 Skill 拥有记忆的技术。没有工具的 Skill 是纸上谈兵。有了工具的 Skill 是真刀真枪。