他们把这个模型接上了多模态输入又给了它调用搜索、读文件、执行脚本的工具。内部评测跑下来知识问答和代码生成分数都很漂亮。结果上线不到一周一条构造好的输入就让模型把访问权限之外的内部文档摘要带了出来。安全团队复盘时发现问题不在模型能力而在评估流程里根本没有覆盖“工具被恶意引导”的场景。这类事在今天的 AGI 应用里不是孤例。模型能力越强越像 Agent安全就不再只是“内容审核”或“拒绝回答有害问题”而是变成了一个完整的技术系统问题。DeepMind 提出的 “An Approach to Technical AGI Safety and Security” 之所以值得认真看不是因为给出了某个一劳永逸的安全开关而是把 AGI 安全与安保拆成了一整套可设计、可评估、可迭代的工程技术思路。这篇文章我会试着把这个思路拆开结合落地时常见的问题聊聊它对普通 AI 应用团队到底意味着什么。1. 为什么AGI安全不能只靠“能力评测”这一个动作1.1 能力评测通过只说明“它能答”不说明“它不会答错”很多团队把“安全”和“能力”混在一起评估跑一遍公开的问答集、代码生成集看看准确率再拿几个禁止类问题测一测发现模型能拒绝就认为通过了。这个习惯在单轮 chat 模型时代还不算致命因为危害大多停留在文本输出层面。但一到多模态、工具调用、Agent 工作流这种思路就开始失灵。原因很简单能力评测是在验证模型“能不能做好”安全评估是在寻找模型“会在哪里坏掉”。前者看的是正常输入下的输出质量后者需要刻意构造异常、恶意、边界输入逼着系统露出问题。这两个目标方向完全相反不能共用一套指标。打个比方驾照考试考的是标准路况下的操作规范性但实际的驾驶安全考验的是突发爆胎、前车急刹、行人穿行时你能不能正确处理。标准考试拿满分不意味着紧急情况不会出事故。AI 领域也一样。公开评测集往往覆盖不到 prompt injection、角色扮演诱导、多模态输入中的对抗样本、Agent 工具被劫持等真实风险。模型在评测上表现良好只能说明它在预期数据分布里是可靠的一旦遇到攻击者故意设计过的输入原有判断就可能失效。1.2 DeepMind这份方法不是安全补丁而是一条完整链路从标题看DeepMind 给的不是一份“禁止事项清单”也不是一个测评数据集而是 “An Approach to Technical AGI Safety and Security”——一个技术性的安全方法体系。这里的 “Technical” 很重要它把安全问题从“价值观讨论”拉回到“工程实现”安全原则要变成模型训练目标、评估标准、部署监控和技术指标。这件事的现实背景是AGI 能力的边界正在快速移动。一个去年还很安全的能力组合今年可能因为工具调用、多模态理解变得更复杂而出现新的漏洞。安全如果只是打完补丁就结束很快会被新的攻击方式甩开。所以 DeepMind 的方法更像是把安全设计成一条贯穿模型生命周期的流水线开发前定原则训练中做内建部署前做红队上线后做监控。每一环都不是独立存在的后面每一环都会把前面环节的盲区暴露出来然后再反馈回去修正原则和训练。这里要克制一点说公开资料里并没有完整地给出 DeepMind 内部每一步的具体操作细节很多内容属于论文标题下的方向性描述。但从工程经验看这套“原则—训练—评估—监控”的闭环是当前能让 AGI 安全可执行的基础框架。它不是某个点上的工具而是一整套工作方式。1.3 对普通开发者的第一层启示安全应该前置而不是后补如果你是做 AI 应用而不是训练基础模型可能觉得 DeepMind 这套方法离自己很远。实际上只要你调用的模型有 Agent 能力哪怕只是接入了一个开源大模型做自动化总结你同样会面对安全链路缺失带来的问题。一个常见场景模型输出最终要传递到一个有权限的动作里比如发邮件、执行命令、调用数据库。这时如果不做前置风险判断、不做输入输出过滤、不设置操作边界模型一旦被提示词注入攻击者就能通过对话间接控制你的业务系统。这个风险不是靠模型自己“聪明”能解决的而是要在系统架构层面提前设计。所以 DeepMind 这份方法最大的启示不是“你必须拥有一个安全实验室”而是“安全的起点越早后面修正的成本就越低”。等你上线后才想补安全往往只能靠外挂过滤器和临时熔断效果有限而且很容易误伤正常用户。2. 一套可参考的技术AGI安全链路原则、训练、红队、监控2.1 第一环先明确安全原则与风险边界任何安全系统都要先回答一个问题这个 AI 系统到底允许做什么绝对不允许做什么没有明确的边界后面所有评估和监控都是空谈。在 DeepMind 的思路里这一环不只是写一份宣言而是要把原则翻译成可执行约束。比如“不得帮助用户实施网络攻击”是原则那么落到系统里就要变成检测类别的定义、拒绝响应的策略、对攻击性请求的分类逻辑以及触发后是否升级到人工审核。只有在原则层先把边界定清楚训练数据筛选和模型评估才有依据。实际做项目时我建议团队用一张表来梳理风险边界维度要明确的问题例子使用场景这个系统要被用来做什么客服、代码助手、文档分析禁止行为什么情况下必须拒绝不执行系统命令、不输出个人隐私权限边界模型能触发哪些外部动作只读文件、只调用白名单 API异常处理检测到风险时怎么响应拒绝、降级、转人工、记日志升级通道不确定的情况谁来决策风险委员会或安全负责人原则写得越具体后面 2.2 到 2.4 越好做。反过来如果原则只是停留在“我们要负责任地开发 AI”那它既无法指导训练也无法让评估团队设计测试用例。2.2 第二环在训练阶段把安全内建进去只依赖部署后的内容过滤就像盖房子不装消防通道等起火后才想从哪里逃生。更稳妥的做法是在训练阶段就给模型注入安全偏好。常见实践包括在指令微调阶段加入“安全拒绝”样本让模型学会在遇到敏感请求时解释原因并拒绝在偏好对齐阶段比如 RLHF 或类似方法把“安全且有用”作为排序标准而不是只追求有用在数据筛选阶段剔除高风险内容减少模型学习到有害模式的概率训练过程中持续跑安全回归集防止模型能力增强后丢掉早期学到的拒绝能力。需要说明的是训练内建不等于模型永远不会被攻击。它只是让模型在“正常边界”内更稳定地表现出安全行为。真正的攻击者会不断尝试绕开模型被训练出来的规则所以你仍然需要外部防护层。这里有一个容易被忽略的点训练内建安全也不能只靠公开的安全数据最好结合你自己的产品场景。比如你的系统要处理医疗信息那么这条安全边界就不仅包括通用有害内容还包括医疗建议滥用、隐私泄露等特定风险。这类场景化的安全样本往往比通用数据更能提升模型在真实业务里的表现。2.3 第三环用红队和对抗性评估主动寻找盲区红队是这套链路里最能体现“技术 AGI 安全”精髓的一环。它不是简单找一群人“骂模型”而是有计划地模拟攻击者构造对抗性输入试图让模型突破预设边界。一个有效的红队评估通常覆盖这些维度越狱和角色扮演诱导让模型扮演 DBA、开发者绕过安全提示Prompt Injection把恶意指令藏在看似正常的文本、网页或图片中多模态对抗样本在图片里嵌入文字让模型读取并执行不该执行的指令Agent 工具劫持让模型错误调用搜索、文件读写、代码执行等工具数据提取与隐私泄露诱导模型复述训练数据或上下文中的敏感信息。红队的输出不只是一份“我们需要加强”的报告而应该包含“哪些攻击路径成功、哪些失败、失败点是模型本身还是周边系统、成功案例的上下文是什么”。这些信息会反馈回训练环节变成新的安全训练样本也会反馈给监控系统变成上线后的检测规则。从经验上看红队评估要玩得足够“脏”因为它本质是蓝军。真实的攻击者不会按你预设的礼貌方式提问他们会尝试编码混淆、分步诱导、多轮铺垫甚至利用模型上下文窗口的弱点。如果红队只是跑了一遍标准测试集那它大概率发现不了真正有价值的问题。2.4 第四环部署后的监控、熔断与持续升级模型上线只是安全开始不是结束。攻击者会持续尝试新的绕过手段模型本身的更新也可能引入新的风险所以必须有一套运维层面的安全机制。核心动作包括输入输出监控记录异常请求模式比如高频诱导、特殊编码、工具调用链异常行为审计查看 Agent 实际执行了哪些动作、访问了哪些资源而不是只看模型输出了什么文本熔断机制当检测到风险或异常时自动停止执行、拒绝后续请求或降级到人工处理定期复评每次模型权重更新、工具权限变更、prompt 逻辑调整后重新跑一遍红队评估和安全回归集应急响应预案如果出现真实安全事故知道谁负责决策、如何下线、如何恢复、如何向用户说明。这里要给一个印象上的提醒很多团队会把监控焦点放在“模型是否输出有害内容”但真正的严重事故往往发生在权限链路上。一个模型也许本身不会主动作恶但当它被诱导调用工具时就相当于被攻击者当成了跳板。所以监控系统一定要看到“模型做了哪些动作”而不仅仅是“模型说了哪些话”。注意部署后的熔断不能只在应用层做一个简单关键词过滤。一个下载 PDF、解析图片、再调用 LLM 总结的流程每一步都可能成为攻击面。完整监控需要把输入来源、解析结果、模型决策、工具执行、输出返回串成一条可追踪链路。3. 落地过程中最容易被低估的三个误区和一条排查链路3.1 误区一把红队当成一次“考试”而不是长期对抗很多团队在产品发布前临时找几个人测一遍发现没有明显漏洞就宣布“通过了安全评估”。实际上红队的核心不是得出一个“通过/不通过”的结果而是建立一套可持续发现盲区的方法。为什么必须持续因为模型会更新攻击手法会进化你的产品功能也会变化。今天构造的对抗样本明天可能因为模型上下文长度变长而失效今天安全的 Agent 工具调用链明天新增一个 API 后可能就成了新的注入点。红队如果只是一个时点动作那它评估的其实是“过去的模型在过去的攻击面下的安全性”而不是现在。更实际的做法是建立安全回归集。每次模型或系统升级都跑一遍之前的攻击路径确保没有复发同时根据最近的外部攻击案例和内部事故不断往回归集里加入新的测试用例。让红队像自动化测试一样长期运行才能真正把安全变成持续行为。3.2 误区二只关注模型本身忽略了工具、权限和周边链路如果模型是一辆车安全评估不能只检查发动机还要检查刹车、油路、方向盘和安全气囊。今天很多 AI 事故的根因不在模型“不懂拒绝”而在模型被赋予了过大的执行权限。举个例子一个文档处理 Agent 被要求“读取某目录下的所有文件并生成摘要”如果目录里混入了攻击者上传的一个可疑文件文件内藏了 prompt injection模型就可能把后续指令篡改成“读取环境变量并回传”。这时候光给模型加“不要越狱”的提示词是不够的你还要限制 Agent 的文件系统访问范围、去掉读取敏感文件类型的权限、对工具调用设置独立审批。所以AGI 安全的边界远大于“模型安全”。它应该包括数据安全、权限管理、工具调用链、沙箱隔离和审计日志。红队评估时也要面向整个系统不能只向模型提问要模拟一个用户从端到端发起任务看整条链路上有哪些环节可以被操控。3.3 误区三评估集是死的威胁是活的有些团队的评估策略是“我们有一套 1000 条安全测试题每次跑一遍”。这比没有好但远远不够。原因在于 AGI 系统的威胁空间不是静态的。今天的新威胁可能来自一种新的多模态攻击方式、一个新型工具组合甚至是一个你产品原本没考虑过的误用场景。静态评估集只能证明系统在“已知坏人样本”上表现良好无法证明它能应对“未知攻击”。因此评估集需要持续更新。除了沿用公开的红队数据集还要结合产品当前用户反馈中的异常行为安全社区公布的新攻击方式内部红队日常发现的失败例子业务功能变更带来的新风险点。理想状态下每一条成功攻破系统的样本都不应该只是记录下来而应该被纳入自动回归集形成“发现一次、永久预防”的机制。3.4 异常输出排查链路从现象到根因的五个节点当模型出现“意外输出”或“异常动作”时不要急着先骂模型。更有效的排查顺序是看输入输入里是否包含明显的恶意构造、编码混淆、角色扮演提示或者隐藏在多模态内容中的指令看模型策略模型本身的 system prompt、安全指令、温度参数和上下文是否发生变化安全指令是否被覆盖看权限链路模型调用工具时工具权限是否过大有没有缺少校验或白名单看周边防护输入过滤器、输出过滤器、沙箱、审计日志是否生效是否被绕过看运维状态版本是否一致、prompt 是否被动态修改、依赖包是否有异常更新。这个顺序的核心逻辑是先把变量最小化从最外层的输入一路向内排查。如果一上来就怀疑模型权重很多真实问题会被掩盖。实际上大量“模型不安全”事故最后定位到的是应用层过滤规则缺失或工具权限过大。建议每次排查完都输出一份“现象—原因—处置—预防”的记录。长期累积下来这套记录比任何外部培训材料都更能帮助团队建立对 AGI 安全边界的直觉。4. 从DeepMind方法到我们自己的系统最小可行安全流程4.1 先判断你的项目是否需要照搬整套体系不是所有 AI 项目都要立刻搞一个完整的安全实验室。对于学习型、原型验证型项目先把单次流程跑通做一条基础的内容拦截即可。但如果是面向生产环境、有真实用户、能影响外部资源或涉及数据权限的产品那就需要认真参考 DeepMind 这套链路并裁剪出适合自己的版本。下面这个对照表可以帮助判断项目类型建议采取的安全力度本地演示项目设计边界记录风险不做大规模监控接入外部 API 的普通应用增加输入输出过滤、简单审计、调用白名单Agent / 工具调用型应用实现权限最小化、全链路日志、红队测试、熔断机制高风险领域金融、医疗、基础设施完整原则—训练—评估—监控闭环并配合独立审计这里的判断标准不是团队大小而是“系统一旦出错会造成什么影响”。影响越大安全投入就要越早。4.2 一个可以今天就开始的最小安全闭环哪怕没有 DeepMind 的完整团队配置你也可以从四个动作开始建立最小闭环第一步定义边界。用一张表格列出系统允许做什么、禁止做什么、哪些动作必须二次确认。第二步加输入输出过滤。在调用大模型之前检查输入是否包含明显的恶意模式在模型输出之后检查是否包含敏感信息、是否试图触发系统命令。过滤器可以是规则引擎、分类模型或两者混合。第三步做小规模对抗测试。找两三个熟悉安全的人用一天时间尝试让模型突破边界记录成功的攻击路径。不追求全面但要把已知风险测试一遍。第四步建立监控和熔断。记录每次请求的行为日志尤其是工具调用。当某个请求触发高风险规则时自动停止工具执行转人工处理。下面是一个示意性的朴素流程不代表生产代码只用于理解链路# 伪代码最小安全闭环结构 def safe_agent_call(user_input): # 1. 输入检查 if not input_filter.is_safe(user_input): return block(输入不满足安全要求) # 2. 提取动作意图 action agent.decide(user_input) # 3. 权限校验只允许白名单动作 if action not in allowed_actions: return block(动作不在白名单内) # 4. 工具执行前二次确认 if action.requires_confirmation: return user_confirm(action) # 5. 执行并记录审计日志 result execute_with_sandbox(action) audit.log(user_input, action, result) return result这个闭环不算复杂但它能堵住最常见的问题恶意输入直接触达模型、模型调用未授权工具、高风险操作没有留痕。先跑通最小闭环再根据红队发现和线上事故把过滤规则、权限边界和审计日志越做越细。4.3 长期来看还需要补齐哪些工程能力当你的系统开始承担真实业务最小闭环就不够了。长期看需要补齐以下几个工程能力统一的日志与审计体系所有输入、输出、工具调用、权限决策都要有唯一 ID方便回溯和复现权限最小化机制Agent 能访问什么、能执行什么都要单独配置不要直接给大而全的权限红队样本管理系统把攻击样本按类别、版本、攻击结果管理起来形成回归集模型版本与 Prompt 版本管理每次更新都记录模型权重版本、prompt 版本、周边依赖版本方便定位风险变化应急响应流程定义谁负责判断严重性、谁有权下线系统、什么时候通知用户定期安全评估节奏不要只在发布前做而是按模型更新周期、业务功能变更周期主动做。这些能力的本质是让“安全”从一种临时动作变成一套可度量、可回溯、可迭代的系统。DeepMind 的方法里最值得借鉴的不是某个具体工具而是这种“把安全当成系统工程”的视角。说到底AGI 技术和安全之间不是“先造完再加固”的先后关系。模型的每一次能力升级都会带来新的攻击面安全方法也必须同步演进。DeepMind 这份方法给出的是骨架每个具体团队要根据自己的业务风险、部署方式和使用者真实诉求不断往里填充细节。最该做的不是等一个更安全的大模型而是从今天开始把你的使用场景、权限边界、评估用例和监控日志尽量串成一条可控的闭环。