工具实验与验收

本文来自《AI 应用开发课程》月份 1 课程文档，已整理为网站文章版本。

1. 文档目的

本文件用于汇总 Tool Calling 模块的实验要求和最终验收标准。

2. 最低实验要求

你至少应完成以下实验：

1. 无工具直接回答
2. 调用 1 个工具后回答
3. 调用工具失败并正确返回错误
4. 工具参数缺失时被程序拦截

3. 推荐实验场景

围绕研发助手主线，建议使用这些任务：

• “请从下面这段需求里抽取待办项”
• “请根据下面的 diff 生成 commit message”
• “请总结下面的错误日志”

4. 实验记录模板

5. 最终验收标准

以下 5 项全部满足，才算通过 Tool Calling 模块：

• 至少有 1 个真实有用工具，不是纯玩具 demo
• 完成一次完整闭环
• 工具执行和模型调用职责分离
• 错误处理可以区分至少 3 类错误
• 实验结果有文档记录

6. 录屏建议

如果你要对外展示本模块，录屏顺序建议为：

1. 先展示工具定义
2. 再展示用户输入
3. 再展示模型触发工具
4. 再展示程序执行
5. 最后展示最终回答

7. 常见未达标情况

• 工具只是把输入原样返回
• 工具调用逻辑散落在多个入口文件
• 只有成功路径，没有失败路径验证
• 没有记录实验过程，无法复盘

8. 为什么 Tool Calling 模块一定要做实验记录

因为这个模块最容易出现一种错觉：

看起来已经能调用工具了，应该就算学会了。

实际上，真正需要验证的是：

• 模型是否稳定触发正确工具
• 工具参数是否稳定
• 程序在异常路径下是否还能维持结构清晰
• 工具结果回填后，模型最终回答是否更好

这些都只能通过实验记录看出来，不能靠“感觉这次好像成功了”判断。

9. 一个完整实验应包含哪些内容

建议每次至少记录：

• 用户输入原文
• 本次提供给模型的工具列表
• 模型是否触发工具
• 触发了哪个工具
• 参数长什么样
• 工具是否成功
• 最终模型回答
• 你的复盘结论

10. 推荐的 4 条最小验收链路

链路一：无工具路径

验证模型在不需要工具时能直接回答，而不是“乱调用”。

链路二：单工具成功路径

验证最基础的闭环真的打通。

链路三：参数错误路径

验证程序能拦截并说明问题，而不是崩掉。

链路四：工具执行失败路径

验证失败信息是否被结构化保存，并能进入后续调试流程。

11. 展示型验收和学习型验收的区别

展示型验收

目标是给别人看：

• 能跑
• 有结果
• 结构清晰

学习型验收

目标是给自己看：

• 我真的知道哪里容易失败
• 我能解释为什么这次工具触发正确
• 我知道这套系统还缺什么

月份 1 建议两者都做，但先优先学习型验收。

12. 本章在研发助手项目中的位置

第 4 周综合项目里的工具能力，完全可以复用这里的实验记录方法。你如果现在就养成“每条工具路径都留下证据”的习惯，后面项目演示和面试回答都会轻松很多。

13. 从本章过渡到下一章的桥接说明

接下来进入 05-FastAPI服务化基础 模块。

因为到这里，你已经有了一套最小可用的模型调用和工具调用逻辑。下一步要做的是把这些能力封装成服务，使它们不再只是终端里的脚本能力，而是可以通过接口被外部调用的系统能力。

14. 一条建议的展示主链路

如果你要把 Tool Calling 模块展示给别人看，推荐使用这条最小主链路：

1. 输入一段需求描述
2. 模型决定调用 extract_todo_items
3. 程序执行工具并返回结果
4. 模型基于工具结果生成最终答复

这条链路足够短、足够清楚，也最能说明“模型决策 + 程序执行”的分工。