两个工具都返回结果，模型怎么知道哪个结果属于哪个请求？
先让一个很像正确的答案出错
上一课只有一次库存查询，结果放回消息后不容易混淆。现在用户要红笔3盒、蓝笔2盒。我们同时发出两个请求：r1查红笔，b1查蓝笔。真实库存是红笔5盒、每盒12元；蓝笔1盒、每盒8元。红笔可以满足，蓝笔还差1盒。这组数字是本课构造的可核对场景，不是官方模型实测。
最容易想到的实现是：发出请求时排成一列，收到结果也排成一列，第一条配第一条。假设蓝笔查询花1秒，红笔查询花3秒，先回来的就是蓝笔。如果按到达顺序配对，程序会把“库存1、单价8”贴到红笔上，继而声称红笔不足；把“库存5、单价12”贴到蓝笔上，又声称蓝笔足够。每个返回值本身都是真的，错误发生在关联关系上。
因此，问题不在于模型会不会比较大小，而在于送给它的证据是不是关于同一件事。后面的计算再准确，也救不了前面配错的对象。先预测一下：如果只在结果中加一个工具名称，能修复这次混淆吗？两个请求都调用 read_inventory，所以名称还不足以区分它们。
身份属于一次调用，不属于某种工具
每次发出请求时，宿主保存一份记录：调用ID、工具名称、参数、所属运行和当前状态。r1对应红笔，b1对应蓝笔。结果返回时携带关联ID，程序通过这个ID查原请求，而不拿完成先后当作身份。
这里有两种“相同”需要分开：工具名称相同，表示调用同一类能力；调用ID相同，表示这条结果声称属于同一次请求。参数不同的两次调用必须能区分，即使它们只相隔一毫秒。多任务系统还应在运行范围内查找ID，避免别的会话里的同名标识误入当前历史。
最小处理过程可以手工走一遍：登记 r1→红笔 与 b1→蓝笔；收到 b1 时把结果存到蓝笔格；收到 r1 时存到红笔格；检查两个请求是否都有终态，再组织消息供模型继续。展示顺序可以按请求顺序排列，实际执行顺序仍然是并行的，二者不矛盾。
如果返回一个不存在的 x9，不能随便塞进最近一个空位。应把它记为无法关联的结果并停止使用，查清是服务错误、解析错误还是过期响应。同一ID重复返回时，也要区分重复投递与另一次执行；不要因为收到两条消息就把库存加两次。对读操作，重复结果可能只是冗余；对扣库存、付款这类动作，重复执行会产生真实副作用。
亲眼看先后顺序怎样失去决定权
红笔与蓝笔：调换完成顺序
先预测结果，再逐步展开；最后只改变一个条件，找出最早发生分歧的位置。
教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。
r1查红笔；b1查蓝笔。蓝笔先返回。
- 1. 登记
r1→红笔；b1→蓝笔。
- 2. 先收蓝笔
b1返回库存1、单价8，写入蓝笔记录。
- 3. 再收红笔
r1返回库存5、单价12，写入红笔记录。
r1→红笔；b1→蓝笔。
先预测，再核对结果与原因
红笔3盒共36元；蓝笔缺1盒。身份跟随ID，不跟随完成时间。
再改两个条件，检查边界
如果两种笔恰好库存和价格都一样，错误配对可能暂时不改变最终答案。但这不证明实现正确，只是测试数据没有暴露错误。应故意使用不同数量和价格，并交换返回顺序；验收的是关联不变，而不是某一次碰巧输出正确。
如果蓝笔查询超时，红笔成功，不能把红笔结果复制过去填满空位。可以回填一条属于 b1 的明确错误，让后续决定重试或向用户报告部分结果。返回错误也是有身份的观察，既不能丢失，也不能变成另一商品的事实。
ID只解决关联。拿到正确ID不代表有权执行退款，也不证明参数商品名合法，更不证明返回数据新鲜可信。这些检查发生在其他边界。把所有保障都压在一个字符串上，会让系统看起来整齐，实际上缺少权限和业务验证。
自己解释一次
两个请求都叫read_inventory，为什么还需要ID？
名称识别能力，ID识别本次调用。两个参数不同的请求用同一工具名，必须分别关联结果；否则乱序返回会混用证据。
红笔5盒、蓝笔1盒，用户各要2盒。蓝笔先返回，正确结论是什么？
红笔足够，2×12=24元；蓝笔缺1盒。返回先后不改变商品归属或用户需求，不能依次填到两个请求槽位。
如何证明配对逻辑不依赖“碰巧按顺序回来”？
固定请求与结果，分别按正常、逆序、带延迟和重复投递顺序重放。每次都检查ID到商品的对应关系，再检查缺失、未知和重复ID有没有被显式处理。
请求与结果已经能对上，但下一步还有一个更隐蔽的问题：一个格式完全正确的请求，也可能要求负数数量或越权下单。下一课把“能读懂”与“应该执行”拆开。