这篇关于 DeepMind 技术性 AGI 安全与保障方案的材料最值得先看的东西不是某个模型又变强了多少也不是某条安全原则听起来有多对而是它的切入角度当 AGI 越来越接近现实时安全能不能被当作软件工程问题来处理。它关心的是如何在系统里预设边界、监控行为、验证约束、处理失败而不是等问题发生之后靠承诺和流程去补救。如果你在关注大模型应用、Agent 编排、多模态系统或者正在做 AI 平台的安全评审这份思路会比想象中更贴近实际生产。下面我按自己平时做技术评审的习惯拆开讲先理解它想解决什么问题再看技术模块怎么组织然后讨论怎么判断这套方案能不能落地最后给出可执行的排查和落地建议。1. 先把“安全”和“保障”分开看才能看懂这类方案读任何 AGI 安全材料第一件事是分清两个词。英文里分别是 Safety 和 Security中文常常都翻译成“安全”但实际含义不同。Safety 关心的是“模型会不会做错事或造成伤害”。比如一个自动驾驶模型在雨天误判障碍物或者一个医疗问答模型给出危险建议这属于 Safety 问题。Security 关心的是“外部攻击者或越权行为能不能利用系统”。比如有人通过提示注入让 Agent 调用危险工具或者模型数据被未授权读取这属于 Security 问题。DeepMind 这份方案标题里同时出现 Safety 和 Security说明它没有只谈抽象原则而是想把两类问题一起纳入技术框架。这个信号很重要AGI 安全不能只在论文里讲价值观还要在工程上给出可测试、可验证、可追溯的机制。我读这类材料时会先跳过前面的愿景部分直接看它有没有回答四个问题什么行为被允许什么行为被禁止。允许和禁止用什么形式表达是自然语言策略还是机器可读规则。模型行为是否可以被监控、审计和验证。一旦越界系统有没有阻断、降级和回滚能力。如果一份方案只回答了第一和第二点它还是一份倡议书。只有四个问题都有技术设计才配叫“技术方案”。在常规软件安全里这种差异也很明显。Windows Security 设置界面会告诉你“建议开启哪些保护”但真正决定系统安全的是底层策略是否生效、权限是否收敛、补丁是否更新。Spring Security 也是这样配置链顺序错了Filter 可能根本没执行。安全不是看写了多少文档而是看策略有没有被执行引擎强制落地。所以本章的结论是看待 AGI 安全要把“Safety”理解为行为安全把“Security”理解为系统安全。两者不能混为一谈也不能只靠一个模型解决。现有 AI 安全讨论里最常出问题的就是把“模型要对齐”当成“系统一定安全”。维度SafetySecurity关注点模型行为是否有害系统是否被攻击或越权典型来源能力越界、错误泛化、误导输出提示注入、权限漏洞、数据泄漏应对思路约束、监督、验证隔离、最小权限、审计验证方式评估集、红队、行为测试渗透测试、权限审查、日志分析2. AGI 安全方案的核心支柱约束、隔离、监督、验证抛开具体细节多数技术性 AGI 安全方案都会围绕四个支柱展开。DeepMind 这份资料没有用特别难以理解的表达但本质上也是在做这四件事。2.1 行为约束先画禁止线再谈能力开放行为约束的意思是给模型定义一套清晰的允许动作集合。不能说“你可以做任何有帮助的事”而要明确“你可以读文件、调用搜索、按用户指示生成代码但不能修改权限、不能访问内网、不能自动执行高风险操作”。约束的意义在于把安全从“模型自觉”变成“系统规则”。模型推断能力再强也不能突破外部执行层的权限限制。这就好比服务器程序如果被限制只能监听本机地址那即使代码里有漏洞外网也无法直接访问。很多 AI 开发框架现在会在启动服务时提示--host 0.0.0.0 is intentionally not supported yet for safety理由就是默认暴露所有网络接口风险太高先限制到本机再说。对 AGI 系统来说行为约束不是限制能力而是让能力在可控区域内发挥。真正危险的系统不是能力被约束的系统而是没有任何边界、所有操作都默认允许的系统。2.2 隔离给模型一个“受限执行室”隔离是安全架构里最基础的思路也是最容易迁移到 AGI 领域的经验。普通 Web 应用会把数据库、应用服务器、文件存储放在不同权限域里即使某一层被攻破攻击者也无法横向移动。AGI 系统也应该这样给 Agent 提供独立的执行沙箱、受限的工具权限、隔离的数据访问路径。我比较关注的点是模型本身是否拥有“直接操作现实世界”的能力。如果模型只能输出文本再危险也只是内容风险。一旦模型能调用工具、发送消息、写文件、执行命令那影响范围就从内容层进入了系统层。这时候隔离就是最后的防线。2.3 监督知道它在做什么比管住它更重要监督不是每次操作都要人类确认那是低效控制不是安全设计。好的监督包括三层行为日志模型每一步调用都记录上下文、输入、输出和决策原因。审计链路从用户请求到模型响应再到工具调用都能串成一条完整追踪链。抽样复核对高风险行为或异常行为抽取样本由人工或独立模型复核。监督和日志不是一回事。日志只是记录监督是在日志基础上设立判断规则和响应流程。比如某次 Agent 尝试访问一个从未出现过的路径系统就应该自动标记为高风险事件。2.4 验证行为约束不只看配置还要看实际效果AGI 系统的验证比普通软件复杂。普通软件可以写单元测试断言返回结果可以检查权限配置是否正确。AGI 系统充满概率性同一个输入可能在不同上下文里产生不同输出因此验证必须结合多种方式。一般会先做离线评估用固定测试集检查模型是否遵守约束再做在线监控看实际运行中有没有越界行为最后做红队测试专门模拟攻击和危险场景。如果一份安全方案只说了“我们会让模型更有道德”但没有提任何验证方式那它还没有构成技术方案。我建议把验证指标设计成两类类型指标判断标准离线验证禁止行为触发率测试集内高风险动作触发次数是否为零在线验证越界行为发生率每万次调用中出现越界的次数系统验证权限拦截率越权请求被权限层成功拦截的比例响应验证护栏触发后的降级率从正常模式切换到安全模式的响应时间3. 多模态 AGI 让安全边界从模型内移到了系统层现在说一个更实际的话题多模态 AGI。很多讨论 AGI 安全的材料默认模型只是输入文字、输出文字。但多模态 AGI 的输入可以是图片、语音、屏幕截图、视频流输出可以直接调用工具、操作文件、控制业务系统。这个变化看起来只是能力扩展实际上把安全问题的范围彻底改变了。在纯文本模型里安全主要关心“内容有没有问题”。但模型一旦具备多模态输入就相当于把摄像头、麦克风、浏览器、文件系统都接进了同一个决策引擎。你很难预判一个从上亿参数里泛化出来的模型会从哪张截图里提取到什么上下文。更麻烦的是多智能体场景。一个主 Agent 可能会把任务拆给几个子 Agent子 Agent 再调用更多工具。这时候权限会被逐级传递风险也跟着传递。如果一个子 Agent 通过某个模型获得了文件读取权限而它又被另一个来源的提示词控制那这整条链都可能被利用。这正好对应了传统软件里的一个经典问题权限定义漏洞。数据库里SECURITY DEFINER视图的执行权限继承自定义者而不是调用者。如果定义者权限过高调用者就相当于绕过了自己的权限限制。AGI 系统里如果出现“子 Agent 使用父 Agent 身份执行操作”的情况风险是完全一样的。所以多模态 AGI 的安全设计重心要放在系统层谁给模型开放了传感器输入谁允许模型调用工具一次调用最多能访问哪些数据子任务是否能继承权限。不要只盯着模型内部有没有“对齐”还要看模型外面有没有“护栏”。在系统层面可以参考常规安全领域的做法每个工具调用单独授权不提供全局 token。子任务只能访问任务必需的少量数据。执行环境尽量无状态任务结束后自动清理。任何外部输入都按不可信数据处理。4. 判断这套方案能不能落地先问三个问题面对一份 AGI 安全技术方案我不太关心它写得是否宏大我更关心它能不能在真实工程环境里落地。判断标准其实可以浓缩成三个问题。4.1 默认拒绝还是默认允许这个区别几乎是所有安全系统的分水岭。如果默认允许所有操作只有明确被禁止的才拦截那系统的安全水平完全取决于“禁止列表”是否完备。攻击者永远在找列表之外的新路径护栏很容易被绕过。如果默认拒绝所有操作只有明确授权的才放行那即使模型本身出现幻觉也很难产生危险后果。AGI 系统建议尽量采用默认拒绝并把权限设计成最小够用。这就像开发服务器绑定地址默认绑在 127.0.0.1 比默认绑在 0.0.0.0 安全得多。即使开发者忘了设置也不会把服务暴露给整个网络。4.2 验证是静态的还是动态的静态验证看的是配置和代码比如权限规则有没有写错、模型输出格式是否符合约定。动态验证看的是运行时行为比如模型在遇到提示注入时是否真的触发保护工具调用被拒绝后系统是否正常降级。一份好的技术方案必须同时包含两种验证。只看静态配置你会漏掉真实执行时的异常路径。只看动态测试你会很难确认问题到底出在哪个环节。我建议先写静态检查再跑动态测试。先确认规则本身没有语法和逻辑错误再去测试运行时有没有绕过路径。4.3 回滚和降级是否成体系AGI 系统一定会出错。方案里如果没有回滚路径那说明作者还没把问题想到底。回滚不是简单地把模型从版本 A 切回版本 B。它要回答任务执行到一半系统发现异常怎么中断已经产生的文件怎么处理Agent 已经调用的外部接口怎么补偿审计日志要保留哪些信息这些都属于安全设计的一部分。评估问题可落地的信号风险信号默认策略默认拒绝授权最小化默认允许靠黑名单拦截验证方式静态检查加动态测试只有人工复核没有自动检查权限体系每个调用独立授权使用全局 token 或共享身份日志能力有追踪 ID 和审计链路只有内容输出没有调用记录异常处理有中断、降级、回滚方案没有设计失败路径5. 落地排查清单从权限问题到日志链路按顺序查不管方案设计得多好落到具体系统里一定会有各种问题。根据我自己的实操经验AGI 安全系统出问题大多数时候不是模型不够聪明而是工程配置出了问题。排查顺序建议固定下来不要一上来就怀疑模型能力。5.1 先看现象再定位模块现象可能是启动失败、任务卡住、输出异常、越权工具调用成功、系统报权限错误。先确认现象再决定从哪一层查避免直接修改模型参数。比如很多系统运行时报类似could not set file security for file的错误第一反应不该是“模型策略写错了”而应该检查运行进程有没有文件目录权限。这是典型的环境问题。5.2 检查权限和身份映射重点排查三件事进程运行身份是否为普通用户而不是管理员权限。模型调用工具时使用的身份是否比最小需求更大。是否存在“用一个高权限身份跑低风险任务”的简化配置。数据库里常见的SECURITY DEFINER问题本质上也是权限身份映射出错。定义者是高权限账号视图执行时就获得了高权限。AI 系统里也要仔细检查 Agent 在执行时到底以什么身份操作。5.3 检查日志链路是否完整安全问题基本都要靠日志回溯。如果没有追踪 ID没有调用链信息你连问题发生的路径都找不到。我一般会要求系统在日志里至少记录用户请求、模型版本、Prompt 摘要、工具名称、工具入参、工具返回值、权限判断结果、执行耗时。缺少任何一环事后排查都会很困难。5.4 检查依赖和版本差异AGI 系统的安全配置经常和模型版本强相关。同一个 Prompt在旧模型上不会触发工具调用在新模型上可能就会。因此安全规则需要按模型版本做快照而不是统一覆盖。如果系统里同时存在多个版本更要确认安全策略与模型版本是否配套。这里可以理解成老系统要做 extended security updates靠补丁延长生命周期但补丁不能解决系统结构层面的问题只能算临时过渡方案。5.5 用一个小样本做全链路验证排查完之后不要一上来就跑完整业务。先准备 5 到 10 条包含正常、异常、危险输入的样例走一遍完整链路。至少确认三件事正常请求能完成异常请求会被拦截危险请求会触发降级。链路走通之后再逐步放开并发和更多工具权限。注意先跑通单条任务再开批量。批量任务里出现权限错误时不要只盯着模型还要检查任务队列的并发身份和运行目录。6. 给正在做 AI 项目的人一个最小安全基线很多人看到 AGI 安全会觉得这是大厂研究团队才需要考虑的事但其实只要你的模型应用接了工具调用、接入了外部数据、或者支持上传文件就已经涉及安全问题。以下是一个最小安全基线可以直接抄走。第一列出危险行为清单。把模型可能执行的危险操作全部写出来包括删文件、改配置、发消息、转账、访问内网。明确这些操作默认禁止。第二建立最小权限体系。每个 Agent 只给当前任务需要的权限最好是任务级授权不要全局复用身份。第三启用执行隔离。工具调用和文件访问都放在受限环境里禁止直接访问宿主机。第四部署完整审计日志。每次调用都记录来源、去向、结果。没有日志等于没有安全。第五设计回滚流程。至少完成一次演练确定模型异常时能够快速中断任务。第六定期做红队测试。用提示注入、越权调用、异常输入检查系统护栏。不要等出事再验证。我再看一次这份标题觉得它的重点不是“AGI 什么时候来”而是“如果 AGI 来了我们是否有能力在技术层面保持控制”。作为工程师我更关心能不能把安全从口号变成默认配置。如果你当前正在做多模态 Agent 或 AI 自动化系统可以先把标题里提到的安全思路对应到自己的系统架构上约束对应配置规则隔离对应沙箱环境监督对应日志审计验证对应测试和红队。把这四块做好了即使模型能力继续升级底层系统依然能把风险挡住。最后说一句个人经验AGI 安全方案真正落地时最值得盯住的不是功能列表而是输入格式、权限映射、资源隔离和失败恢复。这几件事看上去不性感却往往决定系统到底靠不靠谱。