这是 Agent 学习笔记的第 3 篇讲工具调用。我一开始卡住的三个术语stakes、Schema 校验、Few-shot也在这篇里讲清。先记住一个判断没有工具调用严格来说不算 Agent。工具是 Agent 的手和脚也是工程上最容易出错的地方。本系列导航00 开篇Agent 是什么与 Chatbot / Workflow / RAG 的边界01 推理范式ReAct / Plan-and-Execute / Reflexion02 记忆系统四类记忆与冲突处理03 工具调用Schema 设计与工具幻觉防护本篇04 可靠性工程循环、假终止、多 Agent 与安全05 成本、上下文、评测与项目故事一、Schema 怎么写写什么时候用不是是什么反例差get_weather获取天气正例好get_weather当用户问天气、温度、是否适合出行时使用参数 city 必填如北京为什么差别这么大因为 Schema 是给模型看的模型要根据它决定该不该调、调哪个。只写获取天气模型不知道适不适合跑步这种间接意图该不该调它写上触发场景意图匹配就准了。我的理解工具描述本质上是路由提示词。写得好模型选工具就准写得含糊就会出现该调不调和乱调。Schema 的结构用天气工具举例{name:get_weather,parameters:{city:{type:string,required:true,description:城市名如北京},date:{type:string,required:false,description:日期默认今天}}}它规定了三件事工具名是get_weathercity必须是字符串必填date是字符串可选。二、三个高频术语我当时问的1. stakes 风险 / 利害关系原意是赌博里押的钱引申为这件事搞砸了后果有多严重。high stakes高风险搞错了后果很严重low stakes低风险搞错了也没啥大不了。场景stakes原因推荐餐厅low推荐错了用户换一家就行推荐电影low不喜欢就不看修改用户昵称low改错了再改回来退款 500 元high钱的事错了有损失医疗建议high可能影响健康甚至生命法律意见high可能影响官司删除生产数据库high数据没了就没了支付转账high钱直接出去为什么高 stakes 要转人工因为 Agent 会犯错低 stakes 犯错可以容忍高 stakes 犯错代价太大。面试口述版“stakes 就是风险等级。high stakes 指搞错了后果严重的场景比如涉及金额、医疗、法律、安全这类操作不能完全交给 Agent需要人工审批或兜底。我们系统退款超过 500 元就转人工。”补一句加分stakes 不仅用于转人工也用于要不要自动更新记忆见上一篇。2. Schema 校验 检查参数是否符合定义Schema可以理解成表格模板规定有哪些字段、每个字段什么类型、哪些必填。Schema 校验就是Agent 调用工具之前检查它传的参数是否符合 Schema。{tool:get_weather,parameters:{city:123}}→city应该是字符串传了 123整数→校验失败拦截。{tool:get_weather,parameters:{}}→city必填但没传 →校验失败。用什么做校验Python 里常用PydanticfrompydanticimportBaseModelclassWeatherParams(BaseModel):city:strdate:strtodaytry:paramsWeatherParams(**agent_output)exceptValidationErrorase:returnf参数错误{e}3. Few-shot 给几个示例让模型照着学方式给几个例子zero-shot不给例子直接问one-shot给一个例子few-shot给几个例子通常 2–5 个例子工具调用Zero-shot用户北京天气 Agent ← 模型可能不知道怎么调工具Few-shot用户北京天气 正确调用get_weather(city北京) 用户上海明天天气 正确调用get_weather(city上海, date明天) 用户杭州天气 正确调用 ← 模型看到前两个例子就知道第三个怎么调为什么有用LLM 是模仿机器。Few-shot 能告诉模型工具名怎么写、参数格式什么样、什么时候该调。关键关系面试爱问Few-shot 让模型尽量写对Schema 校验负责兜底拦住错的。两者不是二选一而是配合使用。三、工具幻觉四层防护工具幻觉 Agent 编了一个不存在的工具或者参数乱填。例子Agent 想发邮件生成了{ tool: send_email, ... }但系统里只有send_sms。四层防护层做法作用① 白名单只允许调用列表里的工具allowed_tools: [get_weather, get_order, send_sms]不存在的工具直接拦截② Schema 校验检查参数类型、必填项拦住类型/缺参错误③ Prompt 约束系统提示写明只能用以下工具不要编造从源头降低概率④ Few-shot给 3 个用户问 X → 正确调用 Y的示例让模型模仿正确格式校验失败之后怎么办这一步很关键不能只是报错要返回错误 可用工具列表“工具 send_email 不存在可用工具[send_sms, send_wechat]”Agent 看到后重新规划改成send_sms。这就是可恢复的错误处理拦截的目的不是让任务失败而是把模型导回正确路径。四、另外两类真实故障1. 参数类型错误例子order_id12345是字符串但 API 要整数。处理用Pydantic 自动转换能转就转转换失败 →把错误信息交回 LLM 重新生成参数。2. 工具结果过长例子搜索 API 返回 50 篇论文、共 25000 字直接塞进上下文会挤爆窗口、拉高成本。处理只取Top-5、每篇摘要 200 字总长控制在1000 字左右。这条我特别有共鸣——它和 RAG 那边只放最相关的 3–5 个 chunk是同一个思路上下文是预算不是垃圾桶。五、面试口述版“工具幻觉是 Agent 生成了不存在的工具名或错误参数。防护四层白名单限制可用工具、Schema 校验参数类型和必填项、Prompt 约束只能用提供的工具、Few-shot 给正确示例。校验失败时返回错误和可用工具列表触发重规划。我们系统工具幻觉率从 12% 降到 1%。”被追问怎么保证不传错参数文档最后留的那道题我的答法“三个角度Few-shot 让模型照着正确格式写Schema Pydantic 做类型和必填校验校验失败把错误和可用工具返回给 Agent触发重新生成。另外工具描述要写清’什么时候用’减少选错工具的概率。”六、我的复盘这一篇让我把工具调用理解成一条流水线而不是一个动作工具描述路由提示→ 模型选择工具 → 参数生成 → Schema 校验 → 执行 → 结果处理截断/摘要 ↑ ↓ └──── 失败时返回错误并要求重规划 ────┘每一环都有对应的兜底环节失败模式兜底选择工具工具幻觉白名单 Prompt 约束 Few-shot生成参数类型错、缺参Schema/Pydantic 重新生成执行结果结果过长Top-K 摘要 长度上限整体反复失败转人工见下一篇下一篇讲可靠性工程无限循环与假终止怎么治、多 Agent 的死锁和成本爆炸、以及 Prompt 注入和越权怎么防。
【Agent 学习笔记 03】工具调用：Schema 怎么写、工具幻觉怎么防、参数错了怎么办
这是 Agent 学习笔记的第 3 篇讲工具调用。我一开始卡住的三个术语stakes、Schema 校验、Few-shot也在这篇里讲清。先记住一个判断没有工具调用严格来说不算 Agent。工具是 Agent 的手和脚也是工程上最容易出错的地方。本系列导航00 开篇Agent 是什么与 Chatbot / Workflow / RAG 的边界01 推理范式ReAct / Plan-and-Execute / Reflexion02 记忆系统四类记忆与冲突处理03 工具调用Schema 设计与工具幻觉防护本篇04 可靠性工程循环、假终止、多 Agent 与安全05 成本、上下文、评测与项目故事一、Schema 怎么写写什么时候用不是是什么反例差get_weather获取天气正例好get_weather当用户问天气、温度、是否适合出行时使用参数 city 必填如北京为什么差别这么大因为 Schema 是给模型看的模型要根据它决定该不该调、调哪个。只写获取天气模型不知道适不适合跑步这种间接意图该不该调它写上触发场景意图匹配就准了。我的理解工具描述本质上是路由提示词。写得好模型选工具就准写得含糊就会出现该调不调和乱调。Schema 的结构用天气工具举例{name:get_weather,parameters:{city:{type:string,required:true,description:城市名如北京},date:{type:string,required:false,description:日期默认今天}}}它规定了三件事工具名是get_weathercity必须是字符串必填date是字符串可选。二、三个高频术语我当时问的1. stakes 风险 / 利害关系原意是赌博里押的钱引申为这件事搞砸了后果有多严重。high stakes高风险搞错了后果很严重low stakes低风险搞错了也没啥大不了。场景stakes原因推荐餐厅low推荐错了用户换一家就行推荐电影low不喜欢就不看修改用户昵称low改错了再改回来退款 500 元high钱的事错了有损失医疗建议high可能影响健康甚至生命法律意见high可能影响官司删除生产数据库high数据没了就没了支付转账high钱直接出去为什么高 stakes 要转人工因为 Agent 会犯错低 stakes 犯错可以容忍高 stakes 犯错代价太大。面试口述版“stakes 就是风险等级。high stakes 指搞错了后果严重的场景比如涉及金额、医疗、法律、安全这类操作不能完全交给 Agent需要人工审批或兜底。我们系统退款超过 500 元就转人工。”补一句加分stakes 不仅用于转人工也用于要不要自动更新记忆见上一篇。2. Schema 校验 检查参数是否符合定义Schema可以理解成表格模板规定有哪些字段、每个字段什么类型、哪些必填。Schema 校验就是Agent 调用工具之前检查它传的参数是否符合 Schema。{tool:get_weather,parameters:{city:123}}→city应该是字符串传了 123整数→校验失败拦截。{tool:get_weather,parameters:{}}→city必填但没传 →校验失败。用什么做校验Python 里常用PydanticfrompydanticimportBaseModelclassWeatherParams(BaseModel):city:strdate:strtodaytry:paramsWeatherParams(**agent_output)exceptValidationErrorase:returnf参数错误{e}3. Few-shot 给几个示例让模型照着学方式给几个例子zero-shot不给例子直接问one-shot给一个例子few-shot给几个例子通常 2–5 个例子工具调用Zero-shot用户北京天气 Agent ← 模型可能不知道怎么调工具Few-shot用户北京天气 正确调用get_weather(city北京) 用户上海明天天气 正确调用get_weather(city上海, date明天) 用户杭州天气 正确调用 ← 模型看到前两个例子就知道第三个怎么调为什么有用LLM 是模仿机器。Few-shot 能告诉模型工具名怎么写、参数格式什么样、什么时候该调。关键关系面试爱问Few-shot 让模型尽量写对Schema 校验负责兜底拦住错的。两者不是二选一而是配合使用。三、工具幻觉四层防护工具幻觉 Agent 编了一个不存在的工具或者参数乱填。例子Agent 想发邮件生成了{ tool: send_email, ... }但系统里只有send_sms。四层防护层做法作用① 白名单只允许调用列表里的工具allowed_tools: [get_weather, get_order, send_sms]不存在的工具直接拦截② Schema 校验检查参数类型、必填项拦住类型/缺参错误③ Prompt 约束系统提示写明只能用以下工具不要编造从源头降低概率④ Few-shot给 3 个用户问 X → 正确调用 Y的示例让模型模仿正确格式校验失败之后怎么办这一步很关键不能只是报错要返回错误 可用工具列表“工具 send_email 不存在可用工具[send_sms, send_wechat]”Agent 看到后重新规划改成send_sms。这就是可恢复的错误处理拦截的目的不是让任务失败而是把模型导回正确路径。四、另外两类真实故障1. 参数类型错误例子order_id12345是字符串但 API 要整数。处理用Pydantic 自动转换能转就转转换失败 →把错误信息交回 LLM 重新生成参数。2. 工具结果过长例子搜索 API 返回 50 篇论文、共 25000 字直接塞进上下文会挤爆窗口、拉高成本。处理只取Top-5、每篇摘要 200 字总长控制在1000 字左右。这条我特别有共鸣——它和 RAG 那边只放最相关的 3–5 个 chunk是同一个思路上下文是预算不是垃圾桶。五、面试口述版“工具幻觉是 Agent 生成了不存在的工具名或错误参数。防护四层白名单限制可用工具、Schema 校验参数类型和必填项、Prompt 约束只能用提供的工具、Few-shot 给正确示例。校验失败时返回错误和可用工具列表触发重规划。我们系统工具幻觉率从 12% 降到 1%。”被追问怎么保证不传错参数文档最后留的那道题我的答法“三个角度Few-shot 让模型照着正确格式写Schema Pydantic 做类型和必填校验校验失败把错误和可用工具返回给 Agent触发重新生成。另外工具描述要写清’什么时候用’减少选错工具的概率。”六、我的复盘这一篇让我把工具调用理解成一条流水线而不是一个动作工具描述路由提示→ 模型选择工具 → 参数生成 → Schema 校验 → 执行 → 结果处理截断/摘要 ↑ ↓ └──── 失败时返回错误并要求重规划 ────┘每一环都有对应的兜底环节失败模式兜底选择工具工具幻觉白名单 Prompt 约束 Few-shot生成参数类型错、缺参Schema/Pydantic 重新生成执行结果结果过长Top-K 摘要 长度上限整体反复失败转人工见下一篇下一篇讲可靠性工程无限循环与假终止怎么治、多 Agent 的死锁和成本爆炸、以及 Prompt 注入和越权怎么防。
