如何从零构建智能体工具Hugging Face Agents Course 完整实战指南【免费下载链接】agents-courseThis repository contains the Hugging Face Agents Course.项目地址: https://gitcode.com/GitHub_Trending/ag/agents-course问模型今天纽约天气如何它没有联网却会自信地编出一个温度——这是大模型在没有工具时的典型翻车。给智能体装上工具后同样的问题它会主动发起一次 API 调用拿到真实数据再作答。本文以 Hugging Face Agents Courseagents-course这门开源课程为素材讲清楚智能体工具从定义、描述、注册到被调用的完整链路并对比 smolagents 与 LangGraph 两条主流落地路线。课程源码可以直接克隆到本地逐章通读git clone https://gitcode.com/GitHub_Trending/ag/agents-course为什么智能体离不开工具一次典型的翻车课程在 units/zh-CN/unit1/what-are-agents.mdx 里给智能体下了一个很直白的定义它是利用 AI 模型与环境交互、以达成用户目标的系统。可以把这个系统拆成两半看——大脑LLM负责推理、规划决定下一步做什么四肢工具决定这个智能体到底能干什么。问题出在大脑只能处理文本。LLM 的输出永远是一段文字它自己既不能查数据库也不能发邮件更不可能知道训练截止之后发生的任何事。直接问它今日天气得到的往往是一段看似合理的幻觉。课程用Alfred 煮咖啡的类比说明这一点理解指令、规划步骤的是大脑真正动手的是咖啡机——也就是工具。所以课程的结论很干脆工具是赋予 LLM 的函数用来扩展模型能力边界。一个合格的智能体工具至少包含四种要素一段说明这个函数干什么的文本描述一个真正执行操作的调用对象带类型声明的输入参数可选的、同样带类型声明的输出声明。常见的工具类型包括网络搜索、信息检索、图像生成、对接外部 APIGitHub、YouTube、Spotify 等但任何用例都可以被封装成工具——这正是units/zh-CN/unit1/tools.mdx开篇强调的工具没有边界边界只取决于你想给智能体配什么四肢。把 Python 函数改造成智能体工具手动描述与 tool 装饰器LLM 无法凭空调用工具前提是它知道工具存在。课程的做法是把工具的元信息写成一段文本注入系统提示system prompt。这段文本本质上是一份说明书工具名、功能、参数类型、输出类型。以课程里的乘法工具为例。手动写法就是拼一句话工具名称calculator描述将两个整数相乘。参数a: int, b: int输出int工具一多这种手工描述既容易漏项又难以保持一致。课程给出的改进方案是借助 Python 的自省能力只要函数本身规范——命名清晰、参数带类型注解、写了 docstring——那么函数名、功能说明、参数类型、返回类型就已经全部在代码里了。加一个tool装饰器框架就能通过inspect模块自动提取这些信息tool def calculator(a: int, b: int) - int: Multiply two integers. return a * b print(calculator.to_string()) # Tool Name: calculator, Description: Multiply two integers., # Arguments: a: int, b: int, Outputs: intto_string()生成的这段文本随后被注入系统提示模型据此学会什么时候该调用 calculator、该传什么参数。smolagents 框架沿用了这个思路units/zh-CN/unit2/smolagents/tools.mdx 里给出了两条工具定义路径tool装饰器简单工具的推荐方式框架直接从函数签名和 docstring 解析接口信息因此命名和注释要写得像给人看的接口文档继承Tool类复杂工具用类封装显式声明name、description、inputs每个参数带类型和说明、output_type和forward执行逻辑。工具接口标准化还有另一层意义。课程在 tools.mdx 末尾专门介绍了MCPModel Context Protocol模型上下文协议它规范了应用向 LLM 提供工具的方式使得任何实现了 MCP 的框架都能复用同一套工具接口不必为每个框架重写一遍。如果你要长期维护一组工具这个协议值得纳入视野。一次完整的智能体工具调用流程思考-行动-观察循环工具描述写好后真正执行调用的其实不是 LLM而是包裹它的智能体框架。units/zh-CN/unit1/agent-steps-and-structure.mdx 用一个天气智能体把整条链路走了一遍思考ThoughtLLM 分析用户问题判断需要外部数据决定调用get_weather行动Action框架解析模型输出生成结构化调用指令并执行工具。模型给出的动作通常长这样{ action: get_weather, action_input: { location: New York } }观察Observation工具返回值比如多云15°C湿度 60%作为一条新消息追加进对话重新发给 LLM更新思考并输出模型基于观察结果组织最终答案若观察显示数据不完整循环会再次迭代。整个过程对用户是透明的——看起来像 LLM 直接用了工具实际是应用代码在循环中代劳。这个 while 式的循环结构课程中对应 ReAct 模式是后面所有框架的共同底座无论你用哪个框架底层跑的几乎都是思考→行动→观察的变体。smolagents 与 LangGraph两种工具集成路线怎么选Unit 2 把工具落地分成三条线各自的取舍很清楚维度smolagentsLangGraphLlamaIndex定位轻量智能体框架状态图式工作流编排面向数据的索引与工作流工具定义tool装饰器或Tool子类普通函数注册为节点/工具以索引、检索组件为主控制风格模型自主决定调用顺序显式定义节点、边与状态流转面向检索增强场景封装适合场景快速搭一个能自主干活的 CodeAgent流程固定、需要审计和分支控制的生产工作流围绕私有数据构建智能体课程入口units/zh-CN/unit2/smolagents/tools.mdxunits/zh-CN/unit2/langgraph/units/zh-CN/unit2/llama-index/两条路线的差异可以概括为自主性和确定性的权衡smolagents 路线把工具交给CodeAgent由模型在循环里自主决定调用哪个工具、何时停止搭得快适合探索性任务。课程里的示例是让 Alfred 在哥谭市查询评分最高的餐饮服务工具本身只是个查字典的小函数但智能体自己完成了调用→读取结果→回答的全过程。LangGraph 路线用状态图把流程画出来每个步骤是图上的一个节点。units/zh-CN/unit2/langgraph/document_analysis_agent.mdx 里的文档分析智能体就是典型图像输入 → 视觉模型提取文本 → 需要时执行计算 → 生成摘要 → 按指令后续处理每一步都被显式建模分支和重试都可控。工具在这里同样以函数形式存在只是被钉在了流程图的固定位置上。如果你要做的是流程明确、需要稳定可控的系统比如批量处理合同、周报LangGraph 更稳如果目标是快速验证模型自己串起几个工具是否可行smolagents 成本最低。两者并不互斥课程在 units/zh-CN/unit2/smolagents/multi_agent_systems.mdx 中还会进一步讲多智能体协作可以按需衔接。智能体工具设计上的三个高频坑把工具跑通只是起点课程里反复出现的几个设计原则更值得记下来实时知识必须外包给工具。模型内部知识止于训练截止日凡是需要此刻信息的任务天气、行情、最新文档都不该指望模型原生能力硬问只会换来幻觉。这也是课程用天气例子开篇的原因。描述即契约。模型调用工具的依据只有你写进系统提示的那段文字——参数名、类型、取值范围。类型注解缺失或 docstring 含糊模型就会传来错误格式的参数。课程里Tool类要求每个输入都带type和description正是为了把这份契约写死。观察结果要能被下一轮直接消化。工具输出会以新消息的形式回到对话中格式越标准化明确的字段、稳定的结构模型的反思和纠错就越可靠。解析失败往往不是模型的错而是返回值写得不够对话友好。接下来可以做什么工具这一环打通后顺着课程目录走即可Unit 2 的 unit2 框架总览 把三个框架的边界讲得更细Unit 3 的 Agentic RAG 案例 演示工具与检索的结合想进一步观察智能体运行轨迹可以看 bonus-unit2 的观测与评估章节。【免费下载链接】agents-courseThis repository contains the Hugging Face Agents Course.项目地址: https://gitcode.com/GitHub_Trending/ag/agents-course创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何从零构建智能体工具：Hugging Face Agents Course 完整实战指南
如何从零构建智能体工具Hugging Face Agents Course 完整实战指南【免费下载链接】agents-courseThis repository contains the Hugging Face Agents Course.项目地址: https://gitcode.com/GitHub_Trending/ag/agents-course问模型今天纽约天气如何它没有联网却会自信地编出一个温度——这是大模型在没有工具时的典型翻车。给智能体装上工具后同样的问题它会主动发起一次 API 调用拿到真实数据再作答。本文以 Hugging Face Agents Courseagents-course这门开源课程为素材讲清楚智能体工具从定义、描述、注册到被调用的完整链路并对比 smolagents 与 LangGraph 两条主流落地路线。课程源码可以直接克隆到本地逐章通读git clone https://gitcode.com/GitHub_Trending/ag/agents-course为什么智能体离不开工具一次典型的翻车课程在 units/zh-CN/unit1/what-are-agents.mdx 里给智能体下了一个很直白的定义它是利用 AI 模型与环境交互、以达成用户目标的系统。可以把这个系统拆成两半看——大脑LLM负责推理、规划决定下一步做什么四肢工具决定这个智能体到底能干什么。问题出在大脑只能处理文本。LLM 的输出永远是一段文字它自己既不能查数据库也不能发邮件更不可能知道训练截止之后发生的任何事。直接问它今日天气得到的往往是一段看似合理的幻觉。课程用Alfred 煮咖啡的类比说明这一点理解指令、规划步骤的是大脑真正动手的是咖啡机——也就是工具。所以课程的结论很干脆工具是赋予 LLM 的函数用来扩展模型能力边界。一个合格的智能体工具至少包含四种要素一段说明这个函数干什么的文本描述一个真正执行操作的调用对象带类型声明的输入参数可选的、同样带类型声明的输出声明。常见的工具类型包括网络搜索、信息检索、图像生成、对接外部 APIGitHub、YouTube、Spotify 等但任何用例都可以被封装成工具——这正是units/zh-CN/unit1/tools.mdx开篇强调的工具没有边界边界只取决于你想给智能体配什么四肢。把 Python 函数改造成智能体工具手动描述与 tool 装饰器LLM 无法凭空调用工具前提是它知道工具存在。课程的做法是把工具的元信息写成一段文本注入系统提示system prompt。这段文本本质上是一份说明书工具名、功能、参数类型、输出类型。以课程里的乘法工具为例。手动写法就是拼一句话工具名称calculator描述将两个整数相乘。参数a: int, b: int输出int工具一多这种手工描述既容易漏项又难以保持一致。课程给出的改进方案是借助 Python 的自省能力只要函数本身规范——命名清晰、参数带类型注解、写了 docstring——那么函数名、功能说明、参数类型、返回类型就已经全部在代码里了。加一个tool装饰器框架就能通过inspect模块自动提取这些信息tool def calculator(a: int, b: int) - int: Multiply two integers. return a * b print(calculator.to_string()) # Tool Name: calculator, Description: Multiply two integers., # Arguments: a: int, b: int, Outputs: intto_string()生成的这段文本随后被注入系统提示模型据此学会什么时候该调用 calculator、该传什么参数。smolagents 框架沿用了这个思路units/zh-CN/unit2/smolagents/tools.mdx 里给出了两条工具定义路径tool装饰器简单工具的推荐方式框架直接从函数签名和 docstring 解析接口信息因此命名和注释要写得像给人看的接口文档继承Tool类复杂工具用类封装显式声明name、description、inputs每个参数带类型和说明、output_type和forward执行逻辑。工具接口标准化还有另一层意义。课程在 tools.mdx 末尾专门介绍了MCPModel Context Protocol模型上下文协议它规范了应用向 LLM 提供工具的方式使得任何实现了 MCP 的框架都能复用同一套工具接口不必为每个框架重写一遍。如果你要长期维护一组工具这个协议值得纳入视野。一次完整的智能体工具调用流程思考-行动-观察循环工具描述写好后真正执行调用的其实不是 LLM而是包裹它的智能体框架。units/zh-CN/unit1/agent-steps-and-structure.mdx 用一个天气智能体把整条链路走了一遍思考ThoughtLLM 分析用户问题判断需要外部数据决定调用get_weather行动Action框架解析模型输出生成结构化调用指令并执行工具。模型给出的动作通常长这样{ action: get_weather, action_input: { location: New York } }观察Observation工具返回值比如多云15°C湿度 60%作为一条新消息追加进对话重新发给 LLM更新思考并输出模型基于观察结果组织最终答案若观察显示数据不完整循环会再次迭代。整个过程对用户是透明的——看起来像 LLM 直接用了工具实际是应用代码在循环中代劳。这个 while 式的循环结构课程中对应 ReAct 模式是后面所有框架的共同底座无论你用哪个框架底层跑的几乎都是思考→行动→观察的变体。smolagents 与 LangGraph两种工具集成路线怎么选Unit 2 把工具落地分成三条线各自的取舍很清楚维度smolagentsLangGraphLlamaIndex定位轻量智能体框架状态图式工作流编排面向数据的索引与工作流工具定义tool装饰器或Tool子类普通函数注册为节点/工具以索引、检索组件为主控制风格模型自主决定调用顺序显式定义节点、边与状态流转面向检索增强场景封装适合场景快速搭一个能自主干活的 CodeAgent流程固定、需要审计和分支控制的生产工作流围绕私有数据构建智能体课程入口units/zh-CN/unit2/smolagents/tools.mdxunits/zh-CN/unit2/langgraph/units/zh-CN/unit2/llama-index/两条路线的差异可以概括为自主性和确定性的权衡smolagents 路线把工具交给CodeAgent由模型在循环里自主决定调用哪个工具、何时停止搭得快适合探索性任务。课程里的示例是让 Alfred 在哥谭市查询评分最高的餐饮服务工具本身只是个查字典的小函数但智能体自己完成了调用→读取结果→回答的全过程。LangGraph 路线用状态图把流程画出来每个步骤是图上的一个节点。units/zh-CN/unit2/langgraph/document_analysis_agent.mdx 里的文档分析智能体就是典型图像输入 → 视觉模型提取文本 → 需要时执行计算 → 生成摘要 → 按指令后续处理每一步都被显式建模分支和重试都可控。工具在这里同样以函数形式存在只是被钉在了流程图的固定位置上。如果你要做的是流程明确、需要稳定可控的系统比如批量处理合同、周报LangGraph 更稳如果目标是快速验证模型自己串起几个工具是否可行smolagents 成本最低。两者并不互斥课程在 units/zh-CN/unit2/smolagents/multi_agent_systems.mdx 中还会进一步讲多智能体协作可以按需衔接。智能体工具设计上的三个高频坑把工具跑通只是起点课程里反复出现的几个设计原则更值得记下来实时知识必须外包给工具。模型内部知识止于训练截止日凡是需要此刻信息的任务天气、行情、最新文档都不该指望模型原生能力硬问只会换来幻觉。这也是课程用天气例子开篇的原因。描述即契约。模型调用工具的依据只有你写进系统提示的那段文字——参数名、类型、取值范围。类型注解缺失或 docstring 含糊模型就会传来错误格式的参数。课程里Tool类要求每个输入都带type和description正是为了把这份契约写死。观察结果要能被下一轮直接消化。工具输出会以新消息的形式回到对话中格式越标准化明确的字段、稳定的结构模型的反思和纠错就越可靠。解析失败往往不是模型的错而是返回值写得不够对话友好。接下来可以做什么工具这一环打通后顺着课程目录走即可Unit 2 的 unit2 框架总览 把三个框架的边界讲得更细Unit 3 的 Agentic RAG 案例 演示工具与检索的结合想进一步观察智能体运行轨迹可以看 bonus-unit2 的观测与评估章节。【免费下载链接】agents-courseThis repository contains the Hugging Face Agents Course.项目地址: https://gitcode.com/GitHub_Trending/ag/agents-course创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考