安全检查已经运行，模型收到的却仍可能是另一份文本。PydanticAI的新修复聚焦这个容易被忽略的交接处：输入护栏应识别本轮用户真正提交的提示，并把替换结果写到实际发送的位置。相关改动已纳入2.61.0正式版本。对接入客户资料、内部知识和业务工具的团队来说，这比再加一个“已启用安全检查”的状态更值得关注。

快速看点：一，处理用户提示及其副本，而不是误把附加提醒当成原始输入；二，脱敏依赖顺序执行，并不支持先把原文发给模型再替换；三，返回值、历史记录、工具失败信息和多模态附件各有边界，不能把修复理解为全链路防泄露。

护栏检查的对象，必须与实际请求对得上

智能体一次调用并不总是把用户输入原封不动地交给模型。规划、记忆和系统提醒等能力可能增加消息，也可能复制、重排已有内容。如果护栏只检查“最后一段文字”，就可能检查到提醒而漏掉用户提示；如果只改一份副本，其他位置仍可能保留原文。

此次实现区分运行历史中的提示与当前请求中的副本，结合对象身份、时间戳和内容寻找对应部分。能确认的多个相同副本会一并处理，必要时也关联历史中的原始部分。这不是凭关键词猜测哪段文字更重要，而是在消息结构中追踪该改动应该落到哪里。

配套测试设置了真实记录模型输入的函数模型，并核对脱敏后的跟踪记录：在所覆盖的案例中，记录应包含替换标记而非原始测试密钥。本轮核验阅读了正式标签内的实现与测试，没有执行上游整套测试，也没有据此推断所有第三方扩展都已通过同样检验。

写着unsafe的返回值，仍可能被当成允许

另一个细节更容易让业务团队误判。护栏应返回布尔值或明确的GuardrailResult。如果分类器直接返回字符串“unsafe”，Python会把非空字符串视为真。当前版本对这类返回值给出弃用警告，但仍沿用真假值判断，因此警告出现并不等于请求已经被拒绝。

实现说明未来版本才会对这类返回值改为报错。眼下的迁移重点是明确转换分类结果，而不是把分类器标签直接接到控制逻辑上。还要区分允许、阻止与替换三种结论，并为每种结论准备断言；一个没有抛异常的检查函数，不一定执行了团队以为的策略。

多个检查组成一条链时，替换后的文本会传给后续检查，但后面的阻止会提前结束整条链。文档特别提示：若链条没有完成，清理结果可能尚未写回历史，原文仍会留在那里。先脱敏还是先拦截，并非只影响性能，也影响哪些记录最终保留什么内容。

并行、多模态与工具调用，不能共用一个保证

输入替换要求顺序模式，因为并行模式启动模型请求时已经带着原文。并行检查可以在判定违规后取消调用，却不能收回已经发送的提示或已经消耗的token。因此，降低等待时间与保证敏感文字不先外发，是两种不同目标，必须在设计时明确选择。

多模态提示也不能随意替换成一段字符串。当前约定遇到不适用的替换会拒绝，以免丢掉附件。内置正则检测器只识别特定形状的文字，可能误改代码或路径，也不会理解自然语言中的提示注入；需要结合实际业务选择模式，不能把正则脱敏当成完整的语义防护。

InputGuardrail只覆盖一次运行首次模型请求中的用户提示。工具的参数与返回值要另外配置ToolGuardrail；工具运行期间产生的部分失败信息也会接受结果检查，但覆盖窗口受能力排序与钩子影响，并非所有异常文字都会自动清理。结果阶段要求重试时，工具可能已经产生副作用，不能假设业务只执行一次。

历史消息同样有信任前提：调用方直接传入的message_history被视为自己控制的资料，其中元数据也被信任。不可信客户端历史应经过合适的适配层处理。版本文档还保留了历史清理能力的待完成边界，不能因为安装了新版，就把此前保存的全部对话视为已经清洗。

小编判断：验收应看到请求内容，而不只是开关

版本标题标为10月23日，GitHub发布记录显示10月24日，本轮保留这个区别，不把合入时间或页面日期混写。这里的改动位于Pydantic AI Harness护栏能力，不能理解成所有使用PydanticAI的应用都会自动获得相同策略；仍需核对依赖版本、配置与具体挂载位置。

更可复用的交付方法是给每个边界准备负例：原始提示、副本、恢复历史、错误返回值、附件和工具失败都分别检查。既确认该拦的动作没有发生，也确认该替换的文字确实离开了实际请求路径。护栏是否存在不难回答，真正要验收的是它到底检查了哪一份内容、在什么时刻作出了什么决定。