尧图网页设计 
让AI从会分析到会动手AI工具集成实战指南3类模式5步构建智能工作流【免费下载链接】coursesAnthropics educational courses项目地址: https://gitcode.com/GitHub_Trending/cours/courses凌晨两点一个客户在工单里问我的订单怎么还没发货如果没有人工值守这句话就只能躺到天亮。大模型能读懂这句话也能写出一段漂亮的安抚话术但它不知道你的订单系统里发生了什么——它查不了库存、调不了接口、发不了通知。这就是很多团队把大模型接入生产后最先撞上的墙模型只会分析信息却不会动手执行操作。而AI工具集成Tool Use正是为了解决这件事给模型配上一组可调用的外部函数让它像人一样边思考、边操作把一次提问变成一条可自动跑完的智能工作流。本文基于 Anthropic 官方教学仓库cours/courses中的 tool_use 课程带你从零搭出一套能查订单、能取消订单、失败还会自己重试的工具调用系统。机制拆解AI是怎么用上工具的把整个系统拆开看只有三个角色在干活可以类比成一家小餐厅应用App服务员。负责接单用户的原始请求、跑腿执行工具、再把最终答复端上桌。模型Model主厨。负责看懂需求、决定要不要下厨调用工具、以及用什么食材、下多少料。工具函数Tool function后厨的设备和原料库。查数据库、发邮件、调支付接口都是它的具体实现。一次完整调用的数据流动是这样的应用把用户问题 一整套工具说明书一起交给模型模型判断需要动手后不直接执行而是回传一条我想用某工具、参数是这些的调用意图应用拿到意图后自己执行工具函数把执行结果再塞回给模型模型消化数据后才产出最终的自然语言回答。注意关键点模型从不直接碰工具它只发指令真正干活的是应用侧——这既是安全边界也让你可以在执行层做缓存、鉴权、审计。想一想你手头有没有那种查一下A再操作一下B最后通知一下C的固定动作那基本就是第一个值得自动化的工作流了。工具契约把工具描述给模型模型选不选对工具、填不填对参数几乎完全取决于你怎么描述它。每个工具本质上是一份三要素契约name函数名模型靠它指名道姓地调用description干什么用的、什么时候该用、什么时候不该用parameters入参的 JSON Schema字段类型、格式约束、哪些必填全写在里面。以按订单号查订单为例一份合格的契约长这样{ name: get_order_by_id, description: 根据订单ID查询订单详情仅在用户提供明确订单号时调用, input_schema: { type: object, properties: { order_id: { type: string, description: 订单号形如 ORD-12345678 } }, required: [order_id] } }这段 JSON 就是模型手里的工具说明书description 里那句仅在用户提供商单号时调用是在教模型克制parameters 里的格式示例是在降低它瞎填参数的概率。几条被反复验证的设计原则一个工具只干一件事。get_order和cancel_order分开写不要合并成万能订单接口否则模型容易混淆边界。命名与类型保持一致。动词开头get_/send_/cancel_参数统一用snake_case、统一用标准类型别一会儿email一会儿mail。description 写清触发条件。与其写查询订单不如写清什么时候该用、不该什么时候用命中率会明显提升。结构化输出让返回值开箱即用工具调用的一个隐藏福利模型的每一次调用请求天然是结构化的。比如你定义了一个print_sentiment工具声明它需要positive_score、negative_score、neutral_score三个数值输入那么模型为了调用它就必须老老实实把情绪分析结果填进这三个字段——相当于你用工具定义变相锁死了输出格式而且比在 prompt 里反复叮嘱请返回JSON可靠得多。# 工具入参即输出格式模型必须按 Schema 填齐三个分数 tool_input { positive_score: 0.1, negative_score: 0.9, neutral_score: 0.0 }这就是课程里说的用工具使用强制 JSON的技巧不是要模型真的执行而是借它填参数的动作拿到一份可被程序直接解析的结构化结果。它对工作流的价值在于下游免解析。在客服场景里假设情绪分析返回{sentiment: negative, confidence: 0.9}你的代码可以直接判断负面情绪且置信度高于 0.8 → 自动升级给资深客服并创建加急工单整条链路不需要正则、不需要 LLM 二次解读。参考 结构化输出示例课 可以动手体验这个技巧。智能路由控制模型选谁、何时选、怎么选得准工具一多新问题就来了模型该不该调该调哪一个tool_choice参数给出了三档控制权对应三种放权程度模式配置行为适用场景自动{type: auto}模型自主决定调用哪个工具也可以不调用直接回答多工具混合的日常对话任意{type: any}必须选一个工具不许空手而归用户输入天然需要查询如搜索入口指定{type: tool, name: ...}锁定调用某一个指定工具流水线里的一步结果要确定简单说就是auto给自由度any给确定性下限tool给确定性上限。工程上常见的用法是主流程用auto关键节点用tool锁死——比如取消订单这种有副作用的操作直接指定cancel_order不给模型犹豫的空间。提高命中率的几个具体做法在description里写清互斥关系查单个订单用我查订单列表请用get_customer_orders给模型看示例在对话里放一两个用户说了X → 应调用Y的示范效果往往好于长篇解释保持工具数量精简。经验上单个会话里工具超过 10 个混淆率会肉眼可见地上升能合并或分层的就分层。编排引擎从单工具到工具网真实业务很少靠一个工具搞定。观察实际系统多工具协同基本逃不出三种形态顺序执行B 的输入来自 A 的输出。典型如先get_user拿到 user_id再拿这个 id 去查订单。条件分支根据 A 的结果走不同路。比如查到订单状态是已发货就只查物流是待付款才提示支付。并行执行互不依赖的工具同时发起。比如同时查库存和查物流谁先返回谁先到缩短总耗时。管理这些依赖关系的标准做法是把工作流建成一张有向无环图DAG每个节点是一个工具调用边表示输出喂给输入没有环就意味着流程一定能走到头。声明式地描述这张图大致长这样workflow [ {tool: get_user, output: user_info}, {tool: get_customer_orders, input: {user_id: {{user_info.id}}}, output: orders}, {tool: send_email, input: {to: {{user_info.email}}, body: {{orders}}}} ]三个步骤自上而下读就是这张 DAG先取用户信息再查其订单列表最后把结果发给用户——{{...}}表示前一步的输出被引用为后一步的输入。韧性设计失败时系统如何自救上线之后你会发现工具会挂。按成因分失败基本落在四类参数错误模型或上游传来的字段格式不对权限错误调用方无权访问目标资源超时错误下游服务响应过慢或网络抖动逻辑错误调用成功但返回了不符合预期的结果比如查订单返回了空。对应的恢复策略应当分级使用而不是一律重试重试只用于超时、网络抖动这类再试一次可能就好的临时故障参数修正把校验错误信息回传给模型让它自己改参重调模型对参数 X 格式应为 Y这类反馈的修正能力很好工具降级主工具不可用时切换到备用通道比如在线接口挂了改查本地缓存表人工兜底连续失败或涉及资损的操作如取消订单直接挂起并转人工绝不硬猜。每个工具节点上配置超时与重试上限是最低成本的加固invocation { tool: get_order_by_id, parameters: {order_id: ORD-12345678}, timeout: 5, # 秒超过即判为超时错误 max_retries: 2, # 临时故障最多重试 2 次 retry_delay: 1 # 两次重试间隔秒数 }这段配置的意思是单次调用最多等 5 秒失败了隔 1 秒再试最多试 2 次再不行就交给上层策略降级或转人工处理。想一想在你的系统里哪类错误重试一次就能好哪类错误重试一百次也没用把这条线画出来你的错误处理框架就有了骨架。落地案例把知识拼成一套客服工作流把前面所有零件装到一起就是一个可运行的客服机器人。官方课程 06_chatbot_with_multiple_tools.ipynb 用一家虚构电子公司的后台演示了完整链路工具清单如下get_user按邮箱查询用户资料get_order_by_id按订单号查询单个订单详情get_customer_orders列出某用户名下所有订单cancel_order取消指定订单有副作用实际系统里这里应加鉴权。一次典型对话的工作流是这样的用户帮我查下 ORD-8891 的订单。 → 模型识别出订单号调用get_order_by_id应用执行查询把订单 JSON 作为工具结果回传模型用户接着说那把订单列表发我看看。 → 先调get_user拿到账号再调get_customer_orders拉列表用户这单我不要了退了吧。 → 模型锁定cancel_order执行最后用自然语言汇总每一步的结果答复用户。整个过程中模型负责听懂意图 汇总表达应用负责执行 拼回结果多轮工具调用在同一个会话里串联完成。建议按课程目录从 工具调用总览 一路做到 第一个简单工具最后跑通这个多工具对话机器人六节课正好构成完整的落地路径。进阶与调优让系统跑得更快更稳系统能跑通之后三个抓手可以明显压低调用开销批处理把查 10 个订单合并成一次批量接口调用而不是 10 次单查——每次调用都意味着一次模型推理合并即省钱压响应时间工具侧加索引、走缓存、砍掉慢依赖。工具越慢整条工作流的体感延迟越差缓存重复请求同一user_id一小时内被查 20 次第二次起直接命中缓存即可对模型来说工具瞬间返回。再往上有三种进阶形态按需选用工具链Tool chaining把几个高频组合的工具固化成一个复合工具减少模型每轮的选择负担动态工具生成根据当前需求现场组装临时工具定义比如动态拼接查询条件适合长尾场景自适应选择记录每个工具的历史成功率与耗时动态调整description中的优先级提示或候选集让路由越用越准。延伸学习从这篇文章到完整体系本仓库cours/coursesAnthropic 官方教学课程集里有一套循序渐进的资源按顺序走下来就能从概念到实战全部覆盖入门工具调用总览——三个角色与调用闭环的完整演示基础你的第一个简单工具——从零写一个可运行的最小工具技巧用工具使用强制JSON——结构化输出的实战用法进阶工具选择策略 与 多工具对话机器人——路由控制与完整工作流。最好的学习方式是动手挑一个你自己业务里查一下、再操作一下、最后通知一下的真实流程用这里的工具定义、结构化输出和编排思路把它搭出来——跑通第一个工具调用的那一刻你会真正理解AI 会动手这句话的重量。【免费下载链接】coursesAnthropics educational courses项目地址: https://gitcode.com/GitHub_Trending/cours/courses创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 让AI从“会分析“到“会动手“：AI工具集成实战指南，3类模式+5步构建智能工作流
让AI从会分析到会动手AI工具集成实战指南3类模式5步构建智能工作流【免费下载链接】coursesAnthropics educational courses项目地址: https://gitcode.com/GitHub_Trending/cours/courses凌晨两点一个客户在工单里问我的订单怎么还没发货如果没有人工值守这句话就只能躺到天亮。大模型能读懂这句话也能写出一段漂亮的安抚话术但它不知道你的订单系统里发生了什么——它查不了库存、调不了接口、发不了通知。这就是很多团队把大模型接入生产后最先撞上的墙模型只会分析信息却不会动手执行操作。而AI工具集成Tool Use正是为了解决这件事给模型配上一组可调用的外部函数让它像人一样边思考、边操作把一次提问变成一条可自动跑完的智能工作流。本文基于 Anthropic 官方教学仓库cours/courses中的 tool_use 课程带你从零搭出一套能查订单、能取消订单、失败还会自己重试的工具调用系统。机制拆解AI是怎么用上工具的把整个系统拆开看只有三个角色在干活可以类比成一家小餐厅应用App服务员。负责接单用户的原始请求、跑腿执行工具、再把最终答复端上桌。模型Model主厨。负责看懂需求、决定要不要下厨调用工具、以及用什么食材、下多少料。工具函数Tool function后厨的设备和原料库。查数据库、发邮件、调支付接口都是它的具体实现。一次完整调用的数据流动是这样的应用把用户问题 一整套工具说明书一起交给模型模型判断需要动手后不直接执行而是回传一条我想用某工具、参数是这些的调用意图应用拿到意图后自己执行工具函数把执行结果再塞回给模型模型消化数据后才产出最终的自然语言回答。注意关键点模型从不直接碰工具它只发指令真正干活的是应用侧——这既是安全边界也让你可以在执行层做缓存、鉴权、审计。想一想你手头有没有那种查一下A再操作一下B最后通知一下C的固定动作那基本就是第一个值得自动化的工作流了。工具契约把工具描述给模型模型选不选对工具、填不填对参数几乎完全取决于你怎么描述它。每个工具本质上是一份三要素契约name函数名模型靠它指名道姓地调用description干什么用的、什么时候该用、什么时候不该用parameters入参的 JSON Schema字段类型、格式约束、哪些必填全写在里面。以按订单号查订单为例一份合格的契约长这样{ name: get_order_by_id, description: 根据订单ID查询订单详情仅在用户提供明确订单号时调用, input_schema: { type: object, properties: { order_id: { type: string, description: 订单号形如 ORD-12345678 } }, required: [order_id] } }这段 JSON 就是模型手里的工具说明书description 里那句仅在用户提供商单号时调用是在教模型克制parameters 里的格式示例是在降低它瞎填参数的概率。几条被反复验证的设计原则一个工具只干一件事。get_order和cancel_order分开写不要合并成万能订单接口否则模型容易混淆边界。命名与类型保持一致。动词开头get_/send_/cancel_参数统一用snake_case、统一用标准类型别一会儿email一会儿mail。description 写清触发条件。与其写查询订单不如写清什么时候该用、不该什么时候用命中率会明显提升。结构化输出让返回值开箱即用工具调用的一个隐藏福利模型的每一次调用请求天然是结构化的。比如你定义了一个print_sentiment工具声明它需要positive_score、negative_score、neutral_score三个数值输入那么模型为了调用它就必须老老实实把情绪分析结果填进这三个字段——相当于你用工具定义变相锁死了输出格式而且比在 prompt 里反复叮嘱请返回JSON可靠得多。# 工具入参即输出格式模型必须按 Schema 填齐三个分数 tool_input { positive_score: 0.1, negative_score: 0.9, neutral_score: 0.0 }这就是课程里说的用工具使用强制 JSON的技巧不是要模型真的执行而是借它填参数的动作拿到一份可被程序直接解析的结构化结果。它对工作流的价值在于下游免解析。在客服场景里假设情绪分析返回{sentiment: negative, confidence: 0.9}你的代码可以直接判断负面情绪且置信度高于 0.8 → 自动升级给资深客服并创建加急工单整条链路不需要正则、不需要 LLM 二次解读。参考 结构化输出示例课 可以动手体验这个技巧。智能路由控制模型选谁、何时选、怎么选得准工具一多新问题就来了模型该不该调该调哪一个tool_choice参数给出了三档控制权对应三种放权程度模式配置行为适用场景自动{type: auto}模型自主决定调用哪个工具也可以不调用直接回答多工具混合的日常对话任意{type: any}必须选一个工具不许空手而归用户输入天然需要查询如搜索入口指定{type: tool, name: ...}锁定调用某一个指定工具流水线里的一步结果要确定简单说就是auto给自由度any给确定性下限tool给确定性上限。工程上常见的用法是主流程用auto关键节点用tool锁死——比如取消订单这种有副作用的操作直接指定cancel_order不给模型犹豫的空间。提高命中率的几个具体做法在description里写清互斥关系查单个订单用我查订单列表请用get_customer_orders给模型看示例在对话里放一两个用户说了X → 应调用Y的示范效果往往好于长篇解释保持工具数量精简。经验上单个会话里工具超过 10 个混淆率会肉眼可见地上升能合并或分层的就分层。编排引擎从单工具到工具网真实业务很少靠一个工具搞定。观察实际系统多工具协同基本逃不出三种形态顺序执行B 的输入来自 A 的输出。典型如先get_user拿到 user_id再拿这个 id 去查订单。条件分支根据 A 的结果走不同路。比如查到订单状态是已发货就只查物流是待付款才提示支付。并行执行互不依赖的工具同时发起。比如同时查库存和查物流谁先返回谁先到缩短总耗时。管理这些依赖关系的标准做法是把工作流建成一张有向无环图DAG每个节点是一个工具调用边表示输出喂给输入没有环就意味着流程一定能走到头。声明式地描述这张图大致长这样workflow [ {tool: get_user, output: user_info}, {tool: get_customer_orders, input: {user_id: {{user_info.id}}}, output: orders}, {tool: send_email, input: {to: {{user_info.email}}, body: {{orders}}}} ]三个步骤自上而下读就是这张 DAG先取用户信息再查其订单列表最后把结果发给用户——{{...}}表示前一步的输出被引用为后一步的输入。韧性设计失败时系统如何自救上线之后你会发现工具会挂。按成因分失败基本落在四类参数错误模型或上游传来的字段格式不对权限错误调用方无权访问目标资源超时错误下游服务响应过慢或网络抖动逻辑错误调用成功但返回了不符合预期的结果比如查订单返回了空。对应的恢复策略应当分级使用而不是一律重试重试只用于超时、网络抖动这类再试一次可能就好的临时故障参数修正把校验错误信息回传给模型让它自己改参重调模型对参数 X 格式应为 Y这类反馈的修正能力很好工具降级主工具不可用时切换到备用通道比如在线接口挂了改查本地缓存表人工兜底连续失败或涉及资损的操作如取消订单直接挂起并转人工绝不硬猜。每个工具节点上配置超时与重试上限是最低成本的加固invocation { tool: get_order_by_id, parameters: {order_id: ORD-12345678}, timeout: 5, # 秒超过即判为超时错误 max_retries: 2, # 临时故障最多重试 2 次 retry_delay: 1 # 两次重试间隔秒数 }这段配置的意思是单次调用最多等 5 秒失败了隔 1 秒再试最多试 2 次再不行就交给上层策略降级或转人工处理。想一想在你的系统里哪类错误重试一次就能好哪类错误重试一百次也没用把这条线画出来你的错误处理框架就有了骨架。落地案例把知识拼成一套客服工作流把前面所有零件装到一起就是一个可运行的客服机器人。官方课程 06_chatbot_with_multiple_tools.ipynb 用一家虚构电子公司的后台演示了完整链路工具清单如下get_user按邮箱查询用户资料get_order_by_id按订单号查询单个订单详情get_customer_orders列出某用户名下所有订单cancel_order取消指定订单有副作用实际系统里这里应加鉴权。一次典型对话的工作流是这样的用户帮我查下 ORD-8891 的订单。 → 模型识别出订单号调用get_order_by_id应用执行查询把订单 JSON 作为工具结果回传模型用户接着说那把订单列表发我看看。 → 先调get_user拿到账号再调get_customer_orders拉列表用户这单我不要了退了吧。 → 模型锁定cancel_order执行最后用自然语言汇总每一步的结果答复用户。整个过程中模型负责听懂意图 汇总表达应用负责执行 拼回结果多轮工具调用在同一个会话里串联完成。建议按课程目录从 工具调用总览 一路做到 第一个简单工具最后跑通这个多工具对话机器人六节课正好构成完整的落地路径。进阶与调优让系统跑得更快更稳系统能跑通之后三个抓手可以明显压低调用开销批处理把查 10 个订单合并成一次批量接口调用而不是 10 次单查——每次调用都意味着一次模型推理合并即省钱压响应时间工具侧加索引、走缓存、砍掉慢依赖。工具越慢整条工作流的体感延迟越差缓存重复请求同一user_id一小时内被查 20 次第二次起直接命中缓存即可对模型来说工具瞬间返回。再往上有三种进阶形态按需选用工具链Tool chaining把几个高频组合的工具固化成一个复合工具减少模型每轮的选择负担动态工具生成根据当前需求现场组装临时工具定义比如动态拼接查询条件适合长尾场景自适应选择记录每个工具的历史成功率与耗时动态调整description中的优先级提示或候选集让路由越用越准。延伸学习从这篇文章到完整体系本仓库cours/coursesAnthropic 官方教学课程集里有一套循序渐进的资源按顺序走下来就能从概念到实战全部覆盖入门工具调用总览——三个角色与调用闭环的完整演示基础你的第一个简单工具——从零写一个可运行的最小工具技巧用工具使用强制JSON——结构化输出的实战用法进阶工具选择策略 与 多工具对话机器人——路由控制与完整工作流。最好的学习方式是动手挑一个你自己业务里查一下、再操作一下、最后通知一下的真实流程用这里的工具定义、结构化输出和编排思路把它搭出来——跑通第一个工具调用的那一刻你会真正理解AI 会动手这句话的重量。【免费下载链接】coursesAnthropics educational courses项目地址: https://gitcode.com/GitHub_Trending/cours/courses创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考