本章进度 4 / 18
22%
正文已完成
L117工具名不能告诉模型该怎么用
把工具描述写成包含适用条件、输入、输出和副作用的决策信息。
先用本课建立“工具描述”的基本直觉,后面的判断和练习才不会只靠记结论。
建议按完整课程顺序先看上一课;如果术语陌生,可以随时回补。
- 无需安装新工具
- 直接阅读并完成本页理解检查
`search`、`send`、`update` 这样的名字对开发者似乎直观,但模型需要知道什么时候选、需要哪些参数、会返回什么以及是否改变外部状态。
能识别只写功能名称的工具描述为何不足,并补齐四类关键信息。
核心概念
先把关键判断说清楚
描述先说明何时使用
适用条件帮助模型在相似工具间选择,比重复工具名称更重要。
输入写业务语义
参数不仅要有类型,还应说明时区、单位、允许值和标识符来自哪里。
副作用必须显眼
发送、写入、删除或花费额度要在描述中明确,并关联审批要求。
案例拆解
两个“查客户”工具为何总被选错
系统同时有 search_customer 和 get_customer,描述都写“查询客户信息”。
- 01
search_customer 改为,不知道客户 ID 时按姓名或邮箱查候选,只返回摘要。
- 02
get_customer 改为,已知唯一客户 ID 时读取完整档案。
- 03
说明搜索结果可能多条,必须确认 ID 后才能调用完整读取。
案例结果
工具描述本身形成了先搜索、再确认、后读取的选择规则。
提交前练习
现在轮到你
重写一个过于简短的工具描述。
选做练习:本节练习可用于加速你巩固,但不影响继续学习。
内容会自动保存在当前设备
查看参考答案与评分标准
参考答案
create_ticket,仅在用户确认工单草稿后调用;输入 customer_id 来自已确认客户、summary 不含敏感数据;返回 ticket_id 或 validation_error;会写入客服系统并通知队列,调用前必须确认。
评分标准
- 适用边界可区分相似工具
- 参数语义可验证
- 副作用和审批明确
本课收口 · 理解检查
用 30 秒确认你理解了
用 30 秒理解检查确认你抓住了重点;阅读标记、练习和总结都不设硬门槛。
你现在更接近哪一种状态?
尚有必填项未完成,请补齐后再继续。
资料来源
继续核对与延伸阅读
本课内容最近更新于 。
- Building Effective Agents↗guide · 核对日期 2026-08-23
- JSON Schema Core Specification 2020-12↗standard · 核对日期 2026-08-23