完整校验流式响应后再执行工具

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

流式助手准备写入 notes.txt。教学轮次包含 write_file 调用 u1，解析对象看似有 path 与 contents，但最终停止原因为输出上限。若收到字段就写文件，截短内容可能覆盖已有笔记。

具体做法

1. 完整消费并收集轮次；文本片段可展示，工具参数片段不得触发写入。
2. 检查最终停止状态，截断或拒绝轮次不执行工具；仅按有界策略重新生成。解析失败与认证、限流等API错误分开处理。
3. 对可取得的原始输入严格解析，再校验工具名、参数模式、实际路径范围和授权。SDK宽容解析成功不能替代这些门禁。
4. 通过后执行；按宿主协议保存完整助手内容，为每个调用ID返回对应成功或错误结果。不能在缺失ID时伪造匹配结果。

反例

把流式 u1 的解析对象写入 notes.txt：既然已有 path 和 contents 就执行，不必等待轮次结束。

改进写法

u1用于写notes.txt，先消费完整流并查看最终状态。即使参数对象可解析，输出上限或拒绝也保持文件不变并记录未完成。正常结束后严格解析、验证模式与路径和授权，再执行并返回匹配u1的结果。最多按既定策略重试两次，其他API错误单独上报。

为什么这样改

部分 JSON 解析器可能容忍未闭合输入或丢弃尾部。字段存在只证明可构成对象，不能证明生成完整。把完成状态、输入契约和执行权限放在副作用前，才有机会阻止过早覆盖。

如何验证

使用临时教学文件和模拟流：截断且可解析对象、拒绝、非法JSON、根目录外路径都应产生零次写入；正常完整且已授权的输入应写一次，并返回 u1 对应结果。比较前后文件哈希及调用日志。这里是回归检查设计，不是模型实测。

适用边界

合法字符串也可能在语义上不完整，模式校验无法识别所有截短内容。路径解析还需处理符号链接及写入竞态。具体SDK的事件、异常与历史格式不同；冻结示例仅提供机制依据。此门禁不能撤销工具或服务器已经发生的副作用。