把模型接入工具和遥测后，风险未必发生在回答生成那一刻：一条工具结果存入历史再读回来，可能改变类型；一个嵌入请求的额外参数，也可能进入可观测平台。Pydantic AI在11月4日发布2.66.0，并在维护中的1.x分支提供1.107.10修复。对企业来说，这不是只改依赖版本就能结束的检查。

快速看点：工具历史重载要检查数据与文件的区别；嵌入轨迹可能包含额外参数中的凭据；本地URL和网页获取的风险取决于实际配置，不能笼统说所有用户都受影响。

同样一段JSON，重载后不该变成文件

官方公告描述，工具返回的普通数据如果恰好长得像框架序列化后的文件对象，旧版本在历史重新加载时可能把它还原成文件。原本作为JSON文本交给模型的内容，之后可能触发应用下载，或让模型供应商用应用身份解析文件引用。问题不要求工具服务器本身被攻破，也不依赖一段提示注入指令。

触发条件需要同时核对：工具结果中存在第三方可控数据；这段结果经过序列化和重载；后续模型路径会下载或解析相应文件。自存历史、由服务端管理的界面历史，以及Temporal、DBOS或Prefect的持久执行都值得排查。不能仅因项目用了某个MCP工具，就断言已经发生越权读取。

修复后的格式把真正的文件项记录在工具数据之外，读取时只按这个记录还原。普通映射继续是普通映射，而不是靠它的字段外形决定是否拥有文件语义。这给企业集成带来的启发很明确：外部业务数据不能因为看起来像内部类型，就获得内部执行能力。

旧历史没有新记录，迁移行为因此需要单独测试；普通存档读取对未记录的文件有更保守的处理。但在途持久任务与Harness的旧快照还保留兼容路径，不能把“支持滚动升级”理解成旧执行记录已全部净化。若旧记录可能含不可信工具数据，应按公告检查清理或结束旧运行的方案，避免无条件恢复旧行为。

关掉正文记录，不一定关掉嵌入凭据记录

另一项公告针对启用了OpenTelemetry的嵌入模型。如果通过EmbeddingSettings的extra_headers或extra_body传递认证信息，这些设置可能完整进入嵌入span。能读取导出轨迹的人因此可能看到原本不该持有的凭据；这不是所有模型请求都会自动泄露的结论。

该问题中，include_content=False和include_model_request_parameters=False都不会移除这两个设置。聊天模型和图像生成span不记录同样的设置，不能把嵌入路径的结论套到它们。对排障人员而言，“我关了提示正文”与“轨迹里没有秘密”是两项不同的验收，必须检查真实字段。

升级阻止后续同类记录，不会把已经导出的轨迹从另一套平台删除。官方建议限制历史轨迹访问，并轮换确实暴露过的凭据。企业应先确认使用了哪些嵌入设置、有哪些接收目的地和读权限，再决定具体处置；没有检查到实际内容前，不应宣称本公司凭据已经泄露。

网络边界与资源上限，也要按路径确认

腾讯云元数据问题的条件更具体：应用运行在腾讯云，并允许本地URL时，旧云元数据阻止清单漏掉了该平台的一个地址。默认不允许本地URL的路径会因链路本地地址范围而拒绝，不能把这一问题报道成默认设置对所有云平台失守。受影响团队可以检查是否确实开过本地访问例外。

本地网页获取还有资源消耗问题：旧处理先在事件循环上给嵌套JSON重新缩进，再限制返回内容。下载上限控制的是原始响应，给模型的长度上限控制的是最终结果，中间格式化的开销并没有被二者包住。使用供应商原生网页获取的路径不受这项问题影响。

这说明验收不能只看单次回答是否被截短。应用应先确认走本地工具还是供应商工具，再在隔离测试环境检查超限行为、并发请求和失败记录。本文只核对正式发布说明与四项公告，没有构造攻击输入、读取任何客户轨迹或运行上游测试，也不把其余同版条目当作已完成逐项审计。

小编判断

这次更新最实用的教训，是把“现在的代码”和“过去留下的材料”分开管理。版本修复、旧历史兼容、遥测留存和网络例外各有责任人。升级后再用非敏感样本验证恢复与导出路径，才是可交付的完成标准；安装成功本身不能证明历史风险已消除。