Function Calling：商品筛选与只读工具调用｜课后复习
课程名称：Function Calling：商品筛选与只读工具调用｜项目任务：基于商品事实的客服回答｜编号：W04-D04
看图复述：两轮协议中，模型提出工具动作；程序在本地验证；Commerce（商城业务） API（应用程序接口） 提供事实；第二轮只解释真实结果。
今天的主线
先口述完整协议：声明工具→模型提出调用→程序校验执行→保留 assistant 调用消息→用相同 tool_call_id 回传→模型解释→核对事实。工具编号关联的是调用，不是订单。第一轮截断、坏参数或归属不一致时，本最小实验停止；第二轮再提工具也不自动扩展循环。
面试追问：为什么直接把查询结果作为新 user 消息不够？为什么 JSON 正确还需要业务检查？为什么两次请求都要记录用量？用自己的一次正常运行和一次坏参数记录回答。预防靠协议与业务双重校验，发现靠消息角色/编号/结果码，修复后重跑正常、坏参数、越权、截断与限流；不要只看最后一句回答。
- 商品候选使用冻结硬筛选、稳定排序、最多 3 个；
- Tool（工具） Schema（数据结构约束） 是协议描述，不是执行授权；
- allowlist、effect（副作用类型）、参数和 Host（宿主应用） 注入必须在程序侧检查；
- TrustedCustomerContext（可信模拟客户上下文） 是可信虚构 Fixture/Session，不是真实鉴权；
- 负例必须有零副作用证据；
- 模型不能生成价格、库存、可信 customer_id 或写操作结果。
风险怎么防、怎么发现、怎么处理、怎么复验
| 风险 | 提前预防 | 怎样发现 | 怎样处理 | 怎样复验 |
|---|---|---|---|---|
| 候选被模型改写 | 程序持有候选 ID/事实 | 解释出现未知 ID/价格 | 拒绝并用事实重建上下文 | ID/事实白名单断言 |
| extra customer_id | 参数 exact match | trace（执行轨迹） 含未知字段 | Handler（处理函数） 前 BLOCKED（受阻） | side_effect=0 |
| 上下文不一致泄露 | Host 注入并比对 | 返回了他人订单详情 | 停止/不返回详情 | mismatch 用例 |
| 模型说已执行 | 要求 Handler/HTTP trace | 无真实 API artifact（交付产物） | 标 Pending/重跑 | 请求响应与状态对照 |
自测
- strict Tool Schema 为什么仍不能代替 allowlist？
- 输入顺序改变时如何保持候选稳定？
- TrustedCustomerContext 能做什么，不能宣称什么？
- 怎样证明退款请求没有产生副作用？
面试考点与面试题
考点：Function Calling（函数调用） 两轮协议、Tool Schema、白名单、事实所有权、最小权限、可信模拟上下文。
- 模型返回 tool call 后，应用为什么不能直接执行？
- 怎样保证模型不能修改商品价格和候选集合？
- 工具参数合法为什么仍不代表操作允许？
- TrustedCustomerContext 与真实 Authentication/Authorization 有什么差别？
留给 D05
交付筛选器、只读 registry/adapter、正常和失败 trace、零副作用与 Evidence（验证证据） 状态。D05 只整合现有机制、跑固定评测、修一个未见表达并交接 W05。
和下次课的衔接：带去 D05 的是你自己跑出来的证据、失败复盘和已冻结的输入/输出约定。
再验证一次：工具参数的形状和类型都要核对
面试追问：模型输出带有 order_id，但它的值是一个列表。应该交给订单服务试一试，还是在哪里停止？
回答要点：在 Handler 前核对对象形状、精确字段集合、字段类型与 ID 格式，再核对可信上下文。dataclass 标注不等于校验；错误参数应在零工具调用时返回 INVALID_ARGUMENTS。
独立练习：在自己的实现中保留一个正常输入和一个同类异常输入，写出修改前后的输出及数据是否改变。再解释：为什么不能让 AI（人工智能） 简单包一层 except Exception 后返回“成功”？
用一个反例把边界讲清楚
复习问题： 参数格式完全正确，为什么仍可能查不到订单？把 customer_id 放在模型参数里，能证明归属吗？
核对思路： 格式校验只检查结构。订单存在性与归属由业务数据、可信课堂上下文和宿主规则核对，不能由模型自行声明。
从你的项目中挑一个相似输入，记录预期、实际输出，以及拒绝发生在哪一层；面试被追问时，一并说明适用场景、代价和还没验证的部分。
复盘：从员工登录到可信客户上下文
先不看课件回答：员工已登录为什么不能证明可以替任意客户创建工单？
用今天自己的失败记录讲清四步：预防时冻结什么；怎样发现错误；在哪层修复；怎样证明没有回归。自检应覆盖：区分员工、客户、服务与审批者；注明 Fixture 边界；模型身份字段在 Handler 前被拒绝，零泄漏/零写入。
交接：在原项目证据中附上修改前后结果、仍未验证的边界和下一课需要保留的合同。遇到解释不清的部分，回到同日课堂的“从员工登录到可信客户上下文”节，重新做一条反例，不能只抄定义。