很多人学 Agent，第一步都会做一个天气 demo。

这当然没问题，但如果一直停在“给模型挂一个工具”，其实很难真正理解 Agent 工程的价值。
真实系统里的关键，不是工具有没有挂上去，而是模型能不能判断：

• 什么时候该查文档
• 什么时候该查数据库
• 什么时候该查外部 API
• 什么时候根本不该猜，必须先拿证据

最近我在做一套循序渐进的 Agent 工程学习实验。
到 Tool Use 这一阶段，我不想只停留在“看文档”和“跑最小 demo”，而是想把前面已经做好的能力真正串起来。

所以我做了一个多工具 Agent 实验：

• 能查天气
• 能做数学换算
• 能查 SQLite 订单数据库
• 能调用我前面做好的完整业务 RAG 系统

重点不是“工具越多越好”，而是让 Agent 真正学会一件事：

什么时候该查文档，什么时候该查数据库，什么时候该查天气，而不是直接胡答。

这篇文章我想分享四件事：

1. 我是怎么把多个工具接到同一个 Agent 里的
2. bind_tools 和 ReAct 这两种思路到底有什么区别
3. 我为什么要把一个完整 RAG 系统再封装成工具
4. 我在实现过程中遇到的几个很典型的坑

一、我这次做的不是单工具 demo，而是一个真正的“多路路由”实验

很多 Tool Use 教程的第一步，通常是“给模型挂一个天气工具”或者“给模型挂一个计算器”。

这当然是必要的，但如果一直停在这里，会很难真正理解 Agent 工程的价值。

因为真实问题往往不是单一路径：

• “北京现在多少度？换算成华氏度是多少？”
• “退款金额高于 200 元需要谁审批？”
• “帮我查 ORD-1003 的退款状态”
• “订单查询接口默认每分钟限流多少次？”
• “先告诉我退款规则，再帮我看具体订单状态”

这些问题背后对应的是完全不同的数据源：

• 天气 API
• 计算能力
• 订单数据库
• 知识库 / 文档检索

所以这版实验的核心目标不是“挂工具”，而是“让模型在多个工具之间做判断”。

二、工具箱怎么设计

我最后放进 Agent 里的工具有 4 个：

1. weather_lookup

负责查天气，优先走 wttr.in。
如果当前环境不能联网，就明确退回 mock 数据，而不是直接报错中断。

2. safe_calculator

负责做数学运算。
这里我没有偷懒直接 eval，而是做了 AST 白名单，只允许数字和安全运算符。

3. orders_db_lookup

负责查 SQLite 订单库。
它支持两种输入：

• 自然语言问题
• 单条 SELECT SQL

这一步很适合练习“让 LLM 知道什么时候该查结构化数据，而不是继续生成文本”。

4. business_rag_lookup

这是这次实验里我最满意的一步。
它不是一个轻量字符串检索函数，而是直接把我前面做好的完整业务 RAG 服务封装成了一个工具。

也就是说，Agent 不是在调用一个“简化版文档搜索”，而是在调用一套真实的：

• 问题改写
• 向量检索
• BM25 混合召回
• 严格基于上下文回答
• 引用溯源

这件事很重要，因为它让前面做过的 RAG 系统，不再只是一个独立项目，而是变成了 Agent 真正会调用的一项能力。

三、为什么要把 RAG 封装成工具

这一步对我来说有一个认知转变：

RAG 不一定只是一个独立应用，它也可以是 Agent 的一个工具。

以前我更容易把 RAG 想成：

• 用户提问
• 系统检索
• 模型回答

但当工具箱足够丰富之后，RAG 就不再是“唯一入口”，而变成了 Agent 在多种数据源中的一个选择。

比如下面这种问题：

“退款金额高于 200 元需要谁审批？顺便再帮我看一下 ORD-1003 的退款状态。”

这里其实天然分成两段：

• “退款金额高于 200 元需要谁审批？”
  这是知识型问题，应该走 RAG
• “ORD-1003 的退款状态”
  这是结构化业务数据，应该走数据库

如果系统把这两个问题都丢给文档检索，信息就会不完整。
如果都丢给数据库，也答不出政策规则。

把已有的业务 RAG 服务包成工具之后，Agent 才真正有机会学会“分流”。

四、bind_tools 和 ReAct 到底有什么区别

这次我同时保留了两种实现：

1. bind_tools

这条路径更接近现代 function calling / tool calling。

流程是：

1. 把工具 schema 绑定给模型
2. 模型返回结构化的 tool_calls
3. 代码执行工具
4. 再把 ToolMessage 回填给模型

它的好处是：

• 工具调用格式更稳定
• 比较适合生产
• 更容易做参数校验和日志追踪

2. ReAct

我又单独做了一版 create_react_agent 实验。

ReAct 的思路是：

• 模型先输出 Thought
• 再输出 Action
• 再输出 Action Input
• 执行后把 Observation 回给模型
• 重复这个循环直到 Final Answer

它的优点是：

• 很适合学习 Agent 的思维过程
• 能直观看到多步推理链路

但缺点也很明显：

• 输出格式更依赖 prompt
• 更容易因为格式漂移导致解析失败

如果用一句话概括两者区别，我会这样说：

• bind_tools 更像“结构化工具调用协议”
• ReAct 更像“可被框架解析的文本推理流程”

五、为了调 Agent，我做了很多“可观察性”处理

工具系统一旦变复杂，最怕的不是报错，而是：

• 不知道模型有没有打算调工具
• 不知道它为什么选了这个工具
• 不知道 message 上下文是怎么越滚越长的
• 不知道它卡在模型、工具还是回填阶段

所以我给 loop 加了比较详细的日志：

• 当前运行到第几轮
• 模型返回了几个 tool_calls
• 每次工具调用的参数是什么
• 每个工具返回了什么结果
• 当前 messages 里到底堆了哪些消息

这一步带来的收益非常直接：

很多“Agent 看起来怪怪的”问题，最后其实都是日志问题，而不是模型问题。

六、我踩过的几个坑

坑 1：本地代理开了，但 socksio 没装

这个报错很典型：

ImportError: Using SOCKS proxy, but the 'socksio' package is not installed

最后发现不是模型的问题，而是：

• 本地开了 ALL_PROXY=socks5://...
• httpx 在走 SOCKS
• 但 Python 环境里没装 socksio

这类坑特别说明一件事：

Agent 工程很多时候不是“提示词工程”，而是“运行环境工程”。

坑 2：on_chain_start 为什么会触发多次

我在 ReAct 的 callback 里一开始加了 on_chain_start，结果发现同一个问题会打印很多次。

后来去看 LangChain 源码才明白：

• 它监听的是“每个 chain / runnable 的开始”
• 不只是最外层 AgentExecutor
• 内部子链也会把 callback 传播下去

最后我的处理方式是：

• 只保留顶层 run
• 用 parent_run_id 过滤内部子链

坑 3：把业务 RAG 接进来后，第一次初始化比想象中重

因为这个工具不是简单函数，而是完整服务，所以首次初始化会涉及：

• embedding 模型加载
• 向量库初始化
• 样例知识库建立索引

如果本地没有模型缓存，第一次启动就可能要联网下载。
所以我最后做了两件事：

• 改成懒加载
• 默认先关掉 reranking，减少首次启动负担

七、这次实验最大的收获，不是“又多会了一个框架”

如果只从技术清单看，这次好像只是又加了几样东西：

• function calling
• ReAct
• callback
• 多工具编排

但我真正的收获其实是下面这个认知：

Agent 工程的关键，不是让模型“更聪明地说话”，而是让系统“更准确地决定下一步该去哪拿信息”。

换句话说，Agent 的价值不只是生成，而是调度。

当我把天气、数据库、RAG 都放进一个工具箱之后，这件事一下子就具体了很多。

八、下一步我准备做什么

接下来我会继续往下走两步：

1. 用 LangGraph 把这套工具调用流程改造成可控状态机
2. 在多 Agent 场景里，把“RAG 专家”“数据专家”“写作专家”拆开协作

如果你也在学 Agent，我很推荐你试一下这个路径：

• 不要只做一个天气 demo
• 尽量把不同类型的数据源放到同一个 Agent 里
• 尝试让它真正判断“该查哪里”

当系统开始具备“分流”能力的时候，你会第一次明显感觉到：

这已经不是普通聊天机器人了。

代码说明

这篇文章对应的是我在 Tool Use 学习阶段做的一个多工具 Agent Lab，包含：

• bind_tools 版工具调用
• ReAct 版 Agent
• SQLite 订单工具
• 天气工具
• 业务 RAG 工具封装

如果你准备把自己的 RAG 系统继续往 Agent 方向演进，我会很推荐你优先做一件事：

先别急着重写整个系统，先把已有的 RAG 服务封装成一个工具。

这一步往往比你想象中更自然，也更能帮助你真正进入 Agent 工程的语境。

想入门 AI 大模型却找不到清晰方向？备考大厂 AI 岗还在四处搜集零散资料？

别再浪费时间啦！2025 年 AI 大模型全套学习资料已整理完毕，从学习路线到面试真题，从工具教程到行业报告，一站式覆盖你的所有需求，现在全部免费分享！

👇👇扫码免费领取全部内容👇👇

​

一、学习必备：100+本大模型电子书+26 份行业报告 + 600+ 套技术PPT，帮你看透 AI 趋势

想了解大模型的行业动态、商业落地案例？大模型电子书？这份资料帮你站在 “行业高度” 学 AI：

1. 100+本大模型方向电子书

2. 26 份行业研究报告：覆盖多领域实践与趋势

报告包含阿里、DeepSeek 等权威机构发布的核心内容，涵盖：

• 职业趋势：《AI + 职业趋势报告》《中国 AI 人才粮仓模型解析》；
• 商业落地：《生成式 AI 商业落地白皮书》《AI Agent 应用落地技术白皮书》；
• 领域细分：《AGI 在金融领域的应用报告》《AI GC 实践案例集》；
• 行业监测：《2024 年中国大模型季度监测报告》《2025 年中国技术市场发展趋势》。

3. 600+套技术大会 PPT：听行业大咖讲实战

PPT 整理自 2024-2025 年热门技术大会，包含百度、腾讯、字节等企业的一线实践：

• 安全方向：《端侧大模型的安全建设》《大模型驱动安全升级（腾讯代码安全实践）》；
• 产品与创新：《大模型产品如何创新与创收》《AI 时代的新范式：构建 AI 产品》；
• 多模态与 Agent：《Step-Video 开源模型（视频生成进展）》《Agentic RAG 的现在与未来》；
• 工程落地：《从原型到生产：AgentOps 加速字节 AI 应用落地》《智能代码助手 CodeFuse 的架构设计》。

二、求职必看：大厂 AI 岗面试 “弹药库”，300 + 真题 + 107 道面经直接抱走

想冲字节、腾讯、阿里、蔚来等大厂 AI 岗？这份面试资料帮你提前 “押题”，拒绝临场慌！

1. 107 道大厂面经：覆盖 Prompt、RAG、大模型应用工程师等热门岗位

面经整理自 2021-2025 年真实面试场景，包含 TPlink、字节、腾讯、蔚来、虾皮、中兴、科大讯飞、京东等企业的高频考题，每道题都附带思路解析：

2. 102 道 AI 大模型真题：直击大模型核心考点

针对大模型专属考题，从概念到实践全面覆盖，帮你理清底层逻辑：

3. 97 道 LLMs 真题：聚焦大型语言模型高频问题

专门拆解 LLMs 的核心痛点与解决方案，比如让很多人头疼的 “复读机问题”：

三、路线必明：AI 大模型学习路线图，1 张图理清核心内容

刚接触 AI 大模型，不知道该从哪学起？这份「AI大模型 学习路线图」直接帮你划重点，不用再盲目摸索！

路线图涵盖 5 大核心板块，从基础到进阶层层递进：一步步带你从入门到进阶，从理论到实战。

L1阶段:启航篇丨极速破界AI新时代

L1阶段：了解大模型的基础知识，以及大模型在各个行业的应用和分析，学习理解大模型的核心原理、关键技术以及大模型应用场景。

L2阶段：攻坚篇丨RAG开发实战工坊

L2阶段：AI大模型RAG应用开发工程，主要学习RAG检索增强生成：包括Naive RAG、Advanced-RAG以及RAG性能评估，还有GraphRAG在内的多个RAG热门项目的分析。

L3阶段：跃迁篇丨Agent智能体架构设计

L3阶段：大模型Agent应用架构进阶实现，主要学习LangChain、 LIamaIndex框架，也会学习到AutoGPT、 MetaGPT等多Agent系统，打造Agent智能体。

L4阶段：精进篇丨模型微调与私有化部署

L4阶段：大模型的微调和私有化部署，更加深入的探讨Transformer架构，学习大模型的微调技术，利用DeepSpeed、Lamam Factory等工具快速进行模型微调，并通过Ollama、vLLM等推理部署框架，实现模型的快速部署。

L5阶段：专题集丨特训篇 【录播课】

四、资料领取：全套内容免费抱走，学 AI 不用再找第二份

不管你是 0 基础想入门 AI 大模型，还是有基础想冲刺大厂、了解行业趋势，这份资料都能满足你！
现在只需按照提示操作，就能免费领取：

👇👇扫码免费领取全部内容👇👇

​

2025 年想抓住 AI 大模型的风口？别犹豫，这份免费资料就是你的 “起跑线”！