跳到主要内容

一个完整的 Tool-Using Agent 案例

学 AI Agent 时，最值得尽早看懂的一类系统，其实不是最复杂的 RAG Agent，而是：

Tool-Using Agent

因为它最直接体现了 Agent 和普通问答系统的区别：

  • 普通问答主要是在“回答”
  • Tool-Using Agent 开始真正“做事”

这篇文档的目标，就是用一个完整案例，把下面这些问题讲清楚：

  • 什么叫 Tool-Using Agent
  • 它最适合解决什么任务
  • 它的系统结构长什么样
  • 它和普通 Tool Use / Function Calling 有什么区别
  • 第一版应该做到什么程度

1. 先定义一个案例场景​

我们先假设做这样一个系统：

团队运营助手

用户可能会提这类请求：

  • 帮我查一下这个订单当前状态
  • 帮我看一下这个用户最近 7 天的活跃情况
  • 帮我把某个任务拆成待办清单
  • 帮我汇总今天需要优先处理的问题

这个场景为什么适合 Tool-Using Agent？

因为它具备这些特点：

  • 依赖外部数据
  • 需要调工具才能拿到真实结果
  • 结果往往不是一次调用就结束
  • 有时需要根据第一步结果决定第二步

2. 什么是 Tool-Using Agent​

可以先用一句最简单的话理解：

Tool-Using Agent 是一种围绕目标持续决定“该调什么工具、什么时候调、调完以后下一步怎么办”的系统。`

它不是“支持工具调用的模型”本身，而是：

  • 把工具调用放进多步任务循环里
  • 让系统根据运行结果动态决定后续动作

3. 它和普通 Tool Use 的区别​

很多系统其实只做到：

  1. 用户问问题
  2. 模型决定调一个工具
  3. 工具返回结果
  4. 模型输出答案

这更像：

  • 单次 Tool Use
  • 或带工具的问答系统

而 Tool-Using Agent 更像：

  1. 接收目标
  2. 判断当前需要什么信息
  3. 调一个工具
  4. 看结果
  5. 判断是否还需要别的工具
  6. 更新状态
  7. 最终收束输出

关键差别在于：

  • 它不是只调一次工具
  • 它会围绕目标持续决策

4. 一个完整案例的系统结构​

可以先把系统拆成下面几层：

4.1 Goal Layer​

理解用户到底想完成什么。

4.2 Tool Router​

判断现在应该调哪个工具。

4.3 Tool Execution Layer​

真正执行：

  • 数据查询
  • 接口调用
  • 状态读取

4.4 State Layer​

记录：

  • 当前目标
  • 已拿到的信息
  • 已做过的动作
  • 当前步数

4.5 Synthesis Layer​

把中间结果整合成最终输出。

5. 先看一张图​

你可以把它理解成：

  • 目标驱动
  • 工具选择
  • 工具执行
  • 结果观察
  • 状态更新
  • 再决定下一步

6. 一个典型执行流程​

比如用户说：

帮我看看这个用户最近是不是需要重点跟进。

系统可能会这样走：

6.1 第一步：理解目标​

系统先判断：

  • 这不是一个纯事实问答
  • 它需要先拿用户行为数据

6.2 第二步：调用用户活跃工具​

比如查询：

  • 最近登录记录
  • 最近操作频率
  • 最近异常事件

6.3 第三步：观察结果​

系统看结果后发现：

  • 活跃度下降
  • 但还缺业务维度

6.4 第四步：继续调用另一个工具​

例如查询：

  • 最近订单变化
  • 最近工单情况

6.5 第五步：更新状态​

把当前证据和结论草稿记下来。

6.6 第六步：输出建议​

最后整合成：

  • 当前状态判断
  • 为什么判断如此
  • 推荐下一步动作

这就明显比“单次调一个工具”更像 Agent。

7. State 在这里为什么重要​

如果没有状态，系统会很容易出现：

  • 查过的数据忘掉
  • 同一个工具重复调
  • 没法知道当前证据够不够

一个最小状态通常可以先包含：

  • goal
  • steps_taken
  • tool_results
  • evidence_summary
  • pending_questions

这已经足够支撑第一版系统。

8. Tool Schema 在这里为什么关键​

很多 Tool-Using Agent 失败，不是因为模型不够聪明，而是因为工具定义太差。

常见问题包括：

  • 工具职责太混
  • 参数太模糊
  • 返回结果太散

好的工具定义通常应该：

  • 一次只做一类事
  • 参数含义明确
  • 返回结构稳定

这样 Agent 才更容易选对工具、用对结果。

9. 这个案例最该评估什么​

对 Tool-Using Agent 来说，至少要评下面几类。

9.1 Tool Selection​

工具选得对不对。

9.2 Tool Argument Quality​

参数提取对不对。

9.3 Step Efficiency​

是不是用了太多无效步骤。

9.4 Final Task Completion​

最终有没有完成用户目标。

9.5 Cost and Latency​

工具调用多了之后，成本和延迟是否还可接受。

10. 第一版最小实现应该做到什么程度​

我建议第一版先控制在：

  • 2 到 3 个工具
  • 1 条明确任务链
  • 1 个简单状态对象
  • 1 组固定样本
  • 1 套最小日志

先把“根据结果决定下一步”的主链跑通。

不要一开始就追求：

  • 十几个工具
  • 多 Agent
  • 自动写操作

11. 常见坑​

11.1 工具过多​

一开始就接太多工具，会极大增加调试噪音。

11.2 没有工具分层​

只读工具和高风险工具混在一起，会让后面治理很难做。

11.3 没有停止条件​

系统很容易不断追加工具调用。

11.4 把 Tool Use 当成 Agent 全部​

有工具不代表就是完整 Agent，关键还是目标驱动的多步决策。

12. 一句话总结​

一个好的 Tool-Using Agent 案例，本质上是在教你看懂：

系统如何围绕目标，选择合适工具、读取结果、更新状态，并把行动能力组织成一个真正可持续推进任务的闭环。