我们团队有一次在做自主智能体迭代的时候遇到一个非常典型的安全问题。v1 版本我们做了整整两轮红队测试把高危动作、Prompt 注入、敏感信息泄露这些场景都过了一遍内部结论是可以小范围灰度。v2 版本只加了两样东西一个是跨会话记忆一个是日历和邮件工具。结果灰度第三天它在一次长对话里把用户历史邮件中的一段联系人信息自动写进了第三方日历邀请的备注里。v1 里精心设计的输出过滤规则还在但它面对的是全新的输入结构规则被绕过去了。这件事让我彻底改变了一个看法自主智能体的安全无法从一个迭代直接继承到下一个迭代更不能被简单“组合”起来。这里说的“无法跨迭代组合”不是指安全不重要也不是说版本越迭代越不安全。而是说安全不是一个可以被增量叠加的属性。上一代的测试结论、策略配置和风险清单换到新一代的能力组合里可能全部失效。我们真正要建立的不是一次性的安全评审而是一套逐代重跑、逐代重估的安全运营机制。1. 为什么上一代的安全通过不能推导出下一代安全1.1 安全不是一代代累积出来的“补丁包”很多团队在管理智能体安全时天然会把它想象成传统软件的漏洞补丁v1 修好一个问题v2 继续保留修复再增加新功能只要旧补丁没被删掉安全水平就应该只升不降。这个直觉在普通业务系统里大概率成立但在自主智能体里不成立。自主智能体的行为不是由一套固定代码路径决定的而是由模型、系统提示词、外部工具、用户输入、历史记忆和当前环境共同决定的。也就是说安全不是某个模块的静态属性而是智能体与整个运行环境交互之后涌现出来的结果。v1 里配好的“禁止调用危险 API”“输出内容过滤敏感词”只能约束 v1 能力范围内的行为路径。到了 v2工具集变了、上下文结构变了、记忆状态变了原来被规则掐住的路径可能就不存在了但更麻烦的是出现了新路径旧规则根本没覆盖到。所以把上一代的安全结论直接继承下来是风险最高的假设。1.2 三个直接原因行为空间、工具权限和记忆上下文第一个原因是行为空间变了。新一代智能体通常会在自主规划、工具调用、上下文长度、任务拆解能力上有所增强。能力增强之后以前“模型根本不会想到这样做”的路径现在会真的发生。安全规则本质上是在限制行为空间但如果行为空间在膨胀旧规则的覆盖率就在下降。第二个原因是工具权限变了。很多安全事件并不是模型主动作恶而是新接入的工具把原本隔离的信息流串在了一起。比如“读取邮件”是安全能力“创建日历邀请”也是安全能力但把它们组合起来允许智能体自动把邮件内容放进日历邀请就可能在用户不知情的情况下泄露信息。第三个原因是记忆和上下文变了。跨会话记忆引入之后上一轮的敏感信息会进入下一轮的工具调用上下文而旧的输出过滤规则往往只考虑了单轮对话。上下文一旦跨代累积安全评估的输入空间就彻底改变了。1.3 迭代中的“新增能力”恰恰是安全失效的来源我经常和团队说一句话不要问“这版有没有保留旧安全策略”要问“这版新增了什么能力旧策略还够不够用”。安全失效往往不是发生在旧能力上而是发生在新增能力与旧能力之间的组合路径上。新增工具、新增记忆、新增自主规划层级表面上都是产品功能增强实际上每一个“增强”都可能给旧安全规则制造一个绕行通道。就像一间房子装了监控但新开了一扇窗户监控还在入侵者可以从窗户进来。如果只盯着旧监控的覆盖范围就会得出一个错误的“安全”结论。2. 组合安全不等于整体安全一个典型的组合爆炸问题2.1 为什么不能用“每个模块都安全”来推断“整体安全”组合数学里有一个很基础的概念多个集合的笛卡尔积。假设智能体有 5 个工具每个工具能接收 10 种输入格式那么从输入到工具调用的路径就有 5×1050 种。如果再加上多轮状态路径数会呈指数级增长。传统软件工程里我们可以用模块化验证来降低这种复杂度每个函数测过组合起来仍然可以通过接口契约推导。但自主智能体不是纯函数系统。它不是给定输入就返回确定输出而是会根据当前上下文、历史记忆、系统提示词甚至模型随机性生成不同的行为序列。所以即使我们验证了“读取邮件”这个动作本身是安全的也验证了“发送日历邀请”这个动作本身是安全的也不能推断“自动把邮件内容提取出来并填入日历邀请”这个组合是安全的。组合之后信息的流转路径发生了质变安全属性不能简单相加。2.2 组合测试为什么很难穷尽假设我们把安全测试用例分成三类输入注入类、敏感信息类、高危动作类。单测每类都覆盖得很好看起来已经很完善。但自主智能体真正的风险往往发生在三类用例的交叉点一次包含 Prompt 注入的用户输入激活了一个本来安全的高危动作工具同时把记忆中的敏感信息带了出来。这种交叉组合的数量是非常庞大的。工具数量、上下文长度、历史轮数、系统提示词里的规则数量任意一个维度增加组合空间都会爆炸。试图通过一次测试把所有组合都穷尽既不现实也不经济。因此组合测试的策略不是“追求全覆盖”而是“优先覆盖高风险交叉点”。这个高风险交叉点也必须逐代重新识别因为每一代的能力边界都在变化。2.3 典型案例多工具串联、多轮自主规划和跨会话记忆常见的风险模式主要有三种。第一种是多工具串联智能体把一个工具的输出直接作为另一个工具的输入中间没有做信息分类和脱敏就会造成跨工具泄露。第二种是多轮自主规划智能体在早期轮次里生成了高风险意图但由于当时没有合适工具它把意图记录下来等到后续轮次里工具出现时再执行。这种延迟执行会让单轮安全测试失效。第三种是跨会话记忆上一轮对话中的敏感信息被写进长期记忆新会话里一个无关请求把它带了出来。这三个模式都说明一个事实安全评估不能只盯着单次调用要看智能体的整体行为链路。而整体行为链路又会随着迭代不断改变所以跨迭代组合安全天然是一个悬而未决的难题。3. 当前自主智能体安全的主战场人机协同与有限自主执行3.1 不要追求“完全无人干预”在真实工程环境里我很少看到有团队敢把自主智能体完全放开让它在生产环境里不受限制地执行任务。更常见的状态是人机协同为主、有限自主执行。所谓“有限”就是让智能体在限定任务、限定工具、限定权限的范围内自主执行重要操作必须经过人确认。这不是保守而是对“安全无法跨迭代组合”的务实回应。既然安全结论不能继承那我们就用人在环来控制风险最高的操作不让智能体单独完成一个高风险闭环。比如只读类任务可以自动执行但发送消息、删除文件、支付转账、对外发布内容这类操作必须有审批节点。3.2 安全边界应该跟着能力变化走而不是跟着版本号走很多团队把安全评估和版本released绑定v1 发布前测一次v2 发布前再测一次。这个节奏本身没错但问题在于他们把版本号当成了安全边界。实际上版本的划分往往是产品节奏决定的而安全边界应该由能力边界决定。每次迭代都应该重新画一遍它能做什么、它不能做什么、它在什么条件下不能自动做什么。这些边界要落到配置、提示词约束、工具权限和审批流程里。举个例子如果 v2 新增了一个“读取附件内容”的能力那么即使版本号还是小版本升级也需要重新评估“附件内容是否会被写入记忆”“附件内容是否可能被后续工具调用输出”。能力变了安全边界就必须跟着变。3.3 人机协同里最难的是“何时介入”介入太早智能体变成人工客服效率优势没了介入太晚风险已经发生补救成本很高。通用做法是按操作等级分级干预读取类操作自动执行但记录日志。写入类操作默认自动执行但敏感字段需要用户确认。高风险操作强制人工审批并且不允许智能体绕过审批。这个分级规则也需要随迭代更新。上一代不需要审批的操作下一代可能因为新工具组合变成高风险。不能因为“以前不需要审批”就默认这一代也不需要。4. 逐代重跑不是重复劳动一套可落地的安全评估流程4.1 先把上一代的安全资产归档但别把结论归零很多团队一提到“逐代重跑安全评估”第一反应是成本太高、重复劳动。其实这里有一个关键区分安全资产可以复用安全结论不能继承。可复用的资产包括测试数据集、红队剧本、监控告警规则、日志采集脚本、权限矩阵、评估工具。这些基础设施能帮你大幅降低逐代重跑的成本。但“上一代测试通过”“上一代风险清单已经闭环”“上一代高危场景已覆盖”这些结论必须归档而不是继承。因为结论依附于当时的行为空间行为空间一变结论就过期了。4.2 五步评估法从能力盘点、威胁建模、测试集重写到组合验证、灰度观察我一般建议团队按五个步骤来做新一代智能体的安全评估。第一步能力盘点。列出本代新增了哪些工具、哪些记忆能力、哪些自主规划层级上下文和权限有哪些变化。这一步不需要做判断只需要完整记录。第二步威胁建模。针对新增能力重新问一遍攻击者可能怎么利用这个能力敏感数据可能从哪些路径泄露高危动作可能通过哪些新组合被触发这一步不能沿用上一代的威胁模型。第三步测试集重写。在旧测试集基础上新增针对新工具、新组合、新上下文的用例。重点不是堆数量而是覆盖高风险交叉点。旧用例中已经不适用的要标记不要盲目保留。第四步组合验证。用一组小规模但高代表性的组合测试验证跨工具、跨会话、多轮自主规划场景。这一步最容易发现“单模块安全但整体不安全”的问题。第五步灰度观察。在真实流量或模拟环境中用小流量运行依靠日志和告警判断是否出现越界行为。灰度期不能太短至少要覆盖足够多的输入分布。4.3 每次迭代的安全交付物清单为了让流程可持续我建议每个迭代版本都要产出这些安全交付物本代能力边界说明更新后的威胁模型更新后的测试用例和测试结果风险清单及未覆盖项监控告警规则人工审批节点列表回滚方案这些交付物未必每代都很厚但它们强制团队把安全评估变成显式流程而不是靠“感觉没变化”带过。5. 当新一代智能体出现安全异常时按什么顺序排查5.1 先确定是能力变化、环境变化还是评测覆盖不足线上出现安全异常时第一反应不要是“调参重试”而是分类定位。如果异常是由新能力触发的比如新增工具被用于从未预料的路径说明行为空间膨胀后安全边界没有同步更新。如果异常是由环境变化触发的比如工具 API 返回格式变了、某个字段从可选变成必填导致校验逻辑失效说明配置需要升级。如果异常在测试集里没有覆盖但在线上出现说明评估流程存在覆盖盲区。这个分类决定了后续动作能力变化要重新威胁建模环境变化要修配置和依赖评测覆盖不足要补测试用例。5.2 推荐排查链路输入上下文 → 工具权限 → 指令优先级 → 记忆污染 → 协作涌现在具体排查时我推荐按这个链路一步步走不要跳跃。第一看输入上下文。是不是出现了旧版本没有见过的系统提示词、用户注入、外部工具返回内容这些输入是否被当作指令执行了第二看工具权限。当前工具调用链路上某个工具是否有超出其职责的权限比如一个只该读日历的插件为什么能读取通讯录第三看指令优先级。系统提示词、用户指令、工具返回内容、历史记忆之间的优先级是否被新逻辑重排了智能体有没有把工具输出当作比安全限制更高的指令第四看记忆污染。跨会话记忆是否把上一轮敏感信息带入了新一轮记忆写入策略是否过滤了危险内容第五看协作涌现。如果存在多个实例或子任务并行某个子任务是否与另一个子任务组合出了意料之外的行为单轮规则往往覆盖不了这种协作场景。5.3 如何记录和沉淀排查结果每次安全异常都是一个宝贵的样本。排查结束后要把触发链路、失效规则、修复方式、新增测试用例都记录下来。这个案例库可以在未来几代迭代里复用帮助团队更快识别同类风险。但要注意案例库只代表已知问题的积累不代表对未知问题的覆盖。它能让你的测试集越来越厚却仍然不能给你“这一代绝对安全”的承诺。所以案例库要迭代但不要让它取代逐代重估。6. 长期主义把“不可跨迭代组合”变成团队的安全运营原则6.1 安全资产可复用安全结论不可继承这是我们总结出的最核心心智模型。工具、脚本、平台、测试数据、红队剧本、日志分析流程这些资产都可以随着版本迭代不断复用。但“安全结论”必须跟版本走每一个新版本都要重新回答“它安不安全以及在什么条件下安全”。如果团队能接受这个前提就不会再把安全评估看成一次性的验收而是看成每次迭代都必须经历的日常重复。这个重复不是内耗而是自主智能体这种动态系统所必需的工程纪律。6.2 建立面向迭代的安全运营节奏我建议团队把安全重估排进迭代节奏里而不是等到发布前才临时抱佛脚。短周期项目可以用轻量版至少做能力边界重述、新威胁评估、关键测试重跑。高风险场景比如涉及用户隐私数据、支付链路、公网自动发布、自动发送消息就必须走完整版威胁建模、测试集重写、组合验证、灰度观察。安全运营节奏的目标是让“这一代是否安全”成为一个有依据、可回答的问题而不是一个只能靠祈祷回答的问题。6.3 适用边界什么时候可以适当简化什么时候不能省如果你的智能体只是研究 Demo、内部小工具、非敏感任务也没有接触真实用户数据那么可以适当简化安全流程但至少要记录能力边界保留基础日志。如果智能体会接触用户数据、会做自动写入操作、会面向外部环境发送内容那安全评估就不能省更不能靠“上一代已经测过”来带过。团队规模小的时候可以借助自动化工具减少人工成本但最后的人为判断和审批节点不能省。自主智能体的安全责任最终在人不在模型。后来我们再迭代智能体时不再问“这版安全吗”而是问“这版在哪些条件下是安全的哪些条件下还不确定我们怎么在灰度里去确认”。承认安全无法跨迭代组合不是对安全失望反而是把安全从一句模糊的承诺变成了一件可以落地、可以改进、可以长期坚持的工程事务。