最近和几个做后端的朋友聊起AI安全有人抛出一个很具体的问题如果让一个没有任何生物背景的普通人拿着一款大模型连续对话几百轮他有没有可能真的设计出一套可执行的生物危害方案饭桌上立刻分成两派。一派说必须在模型层把这类问题全部拦截另一派说拦不拦得住根本不是重点重点是我们太高估了模型在真实物理世界里的行动能力。后来话题绕到弗朗索瓦·肖莱有人搬出他对AI能力边界的一贯判断大语言模型并没有被严格证明具备真正的自主推理和行动能力当前它更像是一个语言和知识整理系统。这个说法没有平息争论反而让问题更清晰了——我们到底是在评估“AI能不能做到”还是在脑补“AI应该能做到”这个问题看起来偏理论但对工程实践者来说非常现实。因为如果默认前者你会把所有精力花在给模型补限制上。如果默认后者你会认真去拆解能力边界、行为链路和人工介入点然后把安全策略建立在可验证的事实上。这两种思路最终做出来的系统完全不是一回事。顺着肖莱的立场往深处走我们会发现AI安全讨论里最容易被跳过的恰恰是一个工程问题你凭什么叫一个模型“具备某项能力”是凭它在测试集上的分数凭它能生成一份看起来专业的文档还是凭它能稳定输出专家认可的结果这个细节不搞清楚后面所有风险讨论都会悬空。1. 先搞清楚肖莱在和什么叙事抬杠1.1 一个绕不开的身份肖莱不是“纯理论党”弗朗索瓦·肖莱是Keras的创建者长期做深度学习框架、自动化机器学习和大规模模型训练相关的工作。他不是那种只在论文里讨论AI的人而是把大量时间花在“怎么让模型被人用起来”的工程世界里。这一点很重要因为一个人如果在生产环境里反复训练、部署、调优过模型他对“模型能力”的理解往往比只读论文的人更谨慎。肖莱有个非常出名的判断现代的深度学习方法在很多任务上表现很好但离真正的通用智能还有距离。他搭建了ARC-AGI基准专门测试模型在抽象推理、少样本泛化这些维度的表现而不是单纯比谁背下来的知识多。这个举动本身就是一种观点——大语言模型擅长的是从海量语料里学习统计规律然后流畅地重组语言。但“重组语言”和“自主完成一个复杂的物理世界任务”之间隔着一道尚未被跨过的能力鸿沟。把这条逻辑搬到AI生物安全风险上会得到一个关键推论如果一个人没有在物理世界里真正做过高风险的生物实验仅仅靠对话生成一份看起来详细的实验流程这个流程到底可不可行在现实环节是会出问题的。不是说它一定无害而是说我们必须先问清楚“模型在这个环节里到底贡献了什么”。是贡献了真正导致危害的核心思路还是只充当了一个信息整理器1.2 他真正反对的是“以能力臆想代替能力验证”肖莱在多种场合反驳过一种叙事深度学习一旦做到足够大就会像人类一样思考和规划然后掌握所有知识进而产生自我意识和反叛动机。他强调当前系统并不具备我们通常理解的“行动者”属性模型没有内在目标、没有持续主动性也不能自发地围绕一个复杂目标制定长期计划。这种反驳并不是说“AI绝对安全”。恰恰相反它是在要求更严谨的安全分析方式你得先验证一件事是不是真的可行再讨论它有多危险。危险不能靠脑补来定义。放到生物安全语境下就会出现一个有趣的分层。支持“AI生物安全风险高”的人会说模型能够给学生物的新手提供大量可执行细节从而降低制造危害的门槛。反对的人会说这类知识很多已经在公开文献里存在是否存在一本模型可能并没有那么关键。两条路线的分歧本质上不是“是否应该担心”而是“风险的主要贡献者到底是模型能力还是人类本身对知识的获取与使用”。作为技术从业者我更愿意用肖莱这个立场作为判断起点不要默认模型全知全能也不要默认它绝对鲁棒。用工程方式去验证才能得到一个相对可控的风险画面。2. AI生物安全风险为什么突然成为热点2.1 风险叙事的三层叠加AI生物安全风险这个词组近几年热度上升并不是因为某一次单一事件彻底改变了局面而是几类担忧被叠加到了一起。第一层是能力担忧。大模型确实展现出很强的跨领域知识能力能写代码、做推理、翻译文献、总结论文。于是很自然地有人推断既然它什么都知道那么它在生物领域也一定具备专业知识甚至可以根据用户需求生成危险方案。这个推断在逻辑上很顺滑但在现实中缺少完整验证。第二层是工具普及担忧。以前想检索生物领域的敏感知识你需要知道找什么数据库、用什么关键词、怎么筛选文献。但现在大模型让人可以用自然语言提问门槛确实降低了。于是大家会担心一些本来没有专业能力的人可以借由AI获得自己原本接触不到的信息。第三层是入口爆炸担忧。模型不是只在浏览器里存在它还被集成在客服系统、内部知识库、代码插件、办公套件里。当AI成为通用入口它处理的信息流变得更复杂安全问题也更难追踪。这一层对工程师来说最熟悉也最具体。这三层担忧叠加自然把“AI生物安全风险”变成了一个热门话题。但热门话题并不等于已经发生的现实。它更像一个信号我们还没有足够成熟的机制去评估模型在不同领域里的真实风险所以恐慌先走了一步。2.2 不能把“模型能生成文本”直接等同于“模型能实施危害”这里必须做一个非常朴素的切割文字即动作信息即能力。一个模型能写出一段关于某种危险试剂的合成描述和它能在现实世界里帮你完成一次危险试剂的制备是两种完全不同的能力。前者是语言生成任务后者涉及原料获取、实验操作、设备安全、环境控制、废弃物处理、失败重试等一连串物理过程。模型生成的文本可以描述这个过程但并不能代替这个过程。肖莱的思路在这里特别有参考价值。他觉得当前的模型更像是在一个封闭的文字符号空间里工作它缺少对真实世界因果关系的持续感知。模型可以输出“如果你的反应体系温度过高可能导致危险”但它很难知道这一刻实验里实际温度是多少、设备有没有故障、操作者是否受训。这些信息模型拿不到也不会真正去感知。所以从工程角度看“AI生物安全风险”实际上可以被拆成两个子问题一是模型能否提供足够精确且可执行的危险信息二是模型能否参与或驱动整个物理实施过程。前者是文本能力问题后者是机器人与自动化问题。把两个问题混在一起讨论风险很容易被高估。3. 用工程视角拆解AI在生物安全链路中的真实位置3.1 知识层AI确实可以充当高效的知识检索器我们不能走向另一个极端说大模型在生物安全领域毫无作用。如果用它来辅助科研、整理文献、设计实验方案、识别合成路线中的潜在问题它确实能提升效率。这种效率提升是真实的也是当前AI被广泛应用的价值所在。但“提升效率”和“独立制造危害”之间差得很远。一个高级生物专家用AI辅助自己设计一个全新的实验方案和一个小白用AI对话几轮就想做出一个高危险产物完全不是同一种风险景象。前者是专业能力的加速器后者是信息获取门槛的降低。现实中的风险并不呈现为“AI突然掌握了制造生物武器的方法”而更可能出现在两个角落一是小白真的把AI输出的内容当成了完整操作手册忽略现实变量二是专业人士利用AI压缩了大量前期调研时间从而加快了某种研究的进度。这两个方向都需要治理但治理方式完全不同。比如果断一点的判断如果模型中包含的参数、条件、注意事项存在幻觉那么它输出的高风险实验方案可能根本不可执行也可能在关键步骤上出现错漏。这种情况下AI的实际危害可能被高估因为它并不稳定到足以成为“可靠的专家”但它也可能在某个偶发场景下真的给出一个相对完整且危险的方案。所以问题不在于“AI是不是万能”而在于“AI在什么情况下会被误信为一个可靠的专家”。这恰恰是“AI幻觉”的研究范畴。模型生成的专业建议表面上看起来很权威、结构清晰、引用规范但里面可能是编造的文献和算错的浓度配比。一个没有经验的人如何分辨这些输出哪些可信、哪些不能信这才是真正的风险点。3.2 实验层物理世界的约束模型替不了执行者生物安全风险最终要落到物理操作上。实验过程中涉及的样本准备、设备消毒、温度控制、无菌操作、个人防护、废液处理这些环节任何一个出错都可能产生严重后果。把这些环节做出来需要人或者自动化设备。当前最主流的交互形态——浏览器对话框里的AI——根本接触不到这些物理环节。有人会说AI可以调用外部工具可以控制机器人。这是一个真实的技术方向但也是目前尚未成熟的方向。我们讨论AI生物安全风险的时候如果默认“AI已经能够自主控制实验设备”那是在拿未来的可能性替代当下的现实。肖莱批评这类想法时经常提到的点也在这里我们总是习惯把未来可能实现的技术能力提前赋予当下的系统然后基于这个错误前提讨论风险。工程经验告诉我判断一个系统能不能完成某个任务唯一可靠的方法是看它是否真的完成了而不是看它有没有能力描述完成步骤。这也是为什么很多实验室自动化项目实际落地时最难的不是模型推理而是设备接口、样本状态、环境变化、异常恢复这些物理变量。3.3 行动计划层有自主规划能力的AI Agent还远谈不上稳定当前行业里AI Agent是一个热词。大家希望模型不只是回答问题还能自己拆解任务、调用工具、执行动作、观察结果然后迭代。如果这样的Agent真的成熟它对安全问题的冲击会大得多因为它让模型从“文字生成者”变成“行动参与者”。但正因为这样我们更要诚实地评估Agent目前的状态。从工程实践看Agent在长链路任务里经常会出问题任务拆解不合理、工具调用参数错误、中间结果处理不当、遇到异常不会恢复。这些问题不是单纯靠更大模型就能解决的它涉及系统设计、状态管理、反馈机制、失败重试等一系列工程问题。放在生物安全场景里这意味着一个能够完成“从文献调研、设计路线、控制设备、分析结果到修正方案”的完整Agent距离我们并没有想象中那么近。它更像一个被过度宣传的方向而不是一个今天就能被恶意使用的现实工具。如果你正在做Agent开发这里的实际建议是不要只测正常链路一定要测异常链路。Agent在某个环节卡住后是继续执行还是停下求助它会不会在状态不确定时做出错误决策这些问题的答案决定了一个Agent是否适合被投入高风险场景。4. 真正值得开发者关注的工程风险不是“模型要造反”4.1 AI幻觉带来的错误级联很多人讨论AI安全时把问题推到“模型自主性”上好像最可怕的事情是模型产生恶意。但从实际生产经验看更容易出问题的其实是模型一本正经地胡编——也就是AI幻觉。在一个知识密集场景里幻觉的后果会被级联放大。模型给出一条不存在的文献引用工程师可能会顺着这条假文献去做调研模型计算出一个错误的配比实验人员可能会照着执行。如果流程里没有人工复核一个早期幻觉就可能在后端被放大成一次严重的实验事故或判断失误。所以如果你负责把AI集成到专业系统里第一件要做的事不是去幻想机器人造反而是建立一个输出校验机制。让模型的生成结果能被权威数据源校验让危险或关键操作需要人工确认。这种机制看起来不够酷但它才是真正能减少现实损失的事情。4.2 模型被滥用时的输入输出管控另一个实际风险是模型被恶意绕过来生成违规内容。几乎所有大模型产品都会做安全对齐禁止生成涉及高危行为的内容。但绕过安全对齐不是一个新鲜问题攻击者可以通过换表述、分步提问、伪装角色等方式让模型在多层对话中逐步生成危险信息。工程上这需要做多层防线。输入侧可以加分类器判断当前请求是否可能涉及敏感内容输出侧可以加检测规则识别模型生成的文本是否包含高危关键词组合对话层可以加上下文审计追踪多轮对话是否在诱导模型解锁限制。这些措施都不是完美的但可以大大提高滥用的成本。这里我要特别提醒如果做模型部署不要只依赖模型厂商的安全配置。不同模型版本的拒绝策略不一样提示词稍微换一下情况就可能完全不同。把这一点当成“依赖版本问题”来对待。上线前的安全测试必须包含对抗性样本和边界case而不是只跑几个常规样例。4.3 谁为AI建议“兜底”责任链设计更根本的工程问题是责任链设计。当AI给出的建议被用户执行后产生负面后果谁来负责是模型提供方、应用开发方、部署方还是最终使用者这个责任归属如果不清晰安全机制很难真正落地。常见的做法是做一个分层设计。第一层模型负责输出候选方案但不做最终决策。第二层系统中的规则引擎或专家知识库对候选方案做校验剔除明显不合理的部分。第三层在高风险决策前强制人工确认。第四层全程记录日志方便事后追溯。这种设计的思想是AI是参与者不是决策者。即使某个时刻模型输出有问题系统也有能力在后续环节把它拦住。这比试图训练一个永远不会犯错的模型要现实得多。5. 一套面向AI项目的风险评估框架5.1 第一步评估模型能力边界而不是先入为主假设威胁拿到一个开源模型或者API应该先做能力探测。不是直接根据文档描述推断它能做什么而是用一组代表性测试集去验证它在目标领域的真实表现。如果你关心生物安全风险那么在测试集里可以包含生物学知识问答、实验方案设计、危险信息识别、安全边界探测等场景。核心目标只有一个搞清楚模型在哪些设置下输出稳定在哪些设置下开始胡编在哪些设置下可以被绕过。这个步骤没有捷径必须有足够多样化的测试样本。5.2 第二步画出真实行为链路把“用户输入 → 模型处理 → 输出 → 外部工具调用 → 用户执行”的完整链路画出来然后逐个环节问风险可能出现在哪里。在用户输入环节风险是诱导与伪装在模型处理环节风险是幻觉与潜在恶意对齐在输出环节风险是格式污染与错误指令在外部工具调用环节风险是API误调用、权限扩大、数据泄露在用户执行环节风险是错误理解与盲目相信。画出链路之后你会发现模型的“恶意”只是整条链路里很小的一部分更多问题来自系统设计和用户行为。5.3 第三步为高风险场景设置人工介入点对于任何可能存在高风险后果的环节都要设置人工介入点。规则很简单只要自动化判断的置信度不够高就把人拉进来。具体落地时可以分三个级别。绿色场景模型直接输出用户自行判断黄色场景系统给出警告要求用户确认是否继续红色场景直接终止输出或强制跳到人工审核流程。这三个级别的划分需要结合具体业务场景反复调整。不要等出了事再补要先预设好规则。5.4 第四步持续用新评测重新校准模型不是一次部署就永久不变的。API端的模型版本会更新开源模型的微调版本会迭代同一个模型在不同提示词风格下的表现也会漂移。如果一直沿用旧的安全评估结果真实风险很可能被低估。所以建议把安全评测做成例行流程而不是一次性工作。每次模型版本变更都要重新跑一遍对抗样本测试。同时也要从日志里收集真实用户的异常输入和违规尝试持续增强防护。这个过程和模型性能监控一样是整个工程体系的一部分。6. 工程师该如何面对这类宏大叙事6.1 区分“风险管理”与“情绪管理”AI安全相关的话题存在大量情绪化表达。每出现一个大模型发布社交媒体上都会出现“AI即将掌控世界”或“AI生物安全风险已迫在眉睫”一类的声音。这类表达在传播上有优势但对工程实践没有太大帮助。工程师需要做的是把宏大命题翻译成具体问题风险来自哪个环节概率有多大影响面有多广是否有缓解措施如何验证缓解措施有效。这些问题不需要大词只需要细致和耐心的测试。肖莱对AI安全讨论的启发也在于此。他反复提醒我们不要把模型能力当作一个未经检验的信仰。这句话放在风险讨论里可以翻译成不要因为模型生成了一份看起来很危险的方案就断定它能完成一次危险的行动。6.2 与其争论“会不会”不如先落实“能不能被追踪”在AI系统里可追踪性可能是最接近“抗风险”的能力。如果每一个关键输出、每一次工具调用、每一次高风险决策都被记录在案那么即使问题发生了我们也能快速定位是哪个环节出了错然后针对性修复。这个思路要落地并不需要特别高级的技术。日志里记录请求ID、用户标识、模型版本、上下文摘要、输出内容、人工审核意见然后做一个简单的审计平台。这些事情不难难的是愿意在平稳期投入成本去做。等到出了事再补代价往往高得多。6.3 落到行动先跑通小场景再建系统边界如果你正在做AI应用开发我建议不要被“AI危害人类”的宏大叙事带偏。先选择一个具体的小场景比如一个内部知识库问答系统或者一个面向特定用户的内容生成工具把之前说的能力测试、链路分析、人工介入点、日志审计都做一遍。在这个小系统里验证安全设计的有效性再逐步扩大范围。这样做的好处有两个。第一你不会在没有任何数据支撑的情况下凭想象设计一套很重的安全架构结果发现根本不适用。第二你可以积累自己的风险案例库真正理解模型在哪些方面可靠、在哪些方面不稳定。这份经验远比任何外部结论可靠。7. 把AI安全讨论带回到“能力验证”这个原点回到开头那个饭桌问题。一个完全没有生物背景的人能否靠大模型生成一套可执行的高危方案我倾向的答案仍然是“不能简单说能或不能”。它取决于模型能力、安全对齐强度、用户的已有知识、物理操作的现实门槛以及整个系统有没有设置人工介入点。每一项都是一个变量不是一句“AI很危险”或“AI无害”能概括的。肖莱在这类讨论中的真正价值不是提供一个结论而是提供一种方法先验证能力再讨论风险。不管你是AI应用开发者、模型部署者还是技术决策者都可以借用这个思路。不要默认模型很强大也不要默认模型很弱小。先去跑测试再去判断边界。如果你真的把这条路径走通了你会发现很多宏大的AI恐惧在具体工程里都会变得可控、可拆解、可回应。正如肖莱所强调的我们离真正的通用智能还有很长一段距离。这段时间也许正是工程实践者最应该用来夯实安全体系的窗口。等能力真的接近通用时如果你还没有一套成熟的安全机制那才是真正需要焦虑的事。
最近和几个做后端的朋友聊起AI安全有人抛出一个很具体的问题如果让一个没有任何生物背景的普通人拿着一款大模型连续对话几百轮他有没有可能真的设计出一套可执行的生物危害方案饭桌上立刻分成两派。一派说必须在模型层把这类问题全部拦截另一派说拦不拦得住根本不是重点重点是我们太高估了模型在真实物理世界里的行动能力。后来话题绕到弗朗索瓦·肖莱有人搬出他对AI能力边界的一贯判断大语言模型并没有被严格证明具备真正的自主推理和行动能力当前它更像是一个语言和知识整理系统。这个说法没有平息争论反而让问题更清晰了——我们到底是在评估“AI能不能做到”还是在脑补“AI应该能做到”这个问题看起来偏理论但对工程实践者来说非常现实。因为如果默认前者你会把所有精力花在给模型补限制上。如果默认后者你会认真去拆解能力边界、行为链路和人工介入点然后把安全策略建立在可验证的事实上。这两种思路最终做出来的系统完全不是一回事。顺着肖莱的立场往深处走我们会发现AI安全讨论里最容易被跳过的恰恰是一个工程问题你凭什么叫一个模型“具备某项能力”是凭它在测试集上的分数凭它能生成一份看起来专业的文档还是凭它能稳定输出专家认可的结果这个细节不搞清楚后面所有风险讨论都会悬空。1. 先搞清楚肖莱在和什么叙事抬杠1.1 一个绕不开的身份肖莱不是“纯理论党”弗朗索瓦·肖莱是Keras的创建者长期做深度学习框架、自动化机器学习和大规模模型训练相关的工作。他不是那种只在论文里讨论AI的人而是把大量时间花在“怎么让模型被人用起来”的工程世界里。这一点很重要因为一个人如果在生产环境里反复训练、部署、调优过模型他对“模型能力”的理解往往比只读论文的人更谨慎。肖莱有个非常出名的判断现代的深度学习方法在很多任务上表现很好但离真正的通用智能还有距离。他搭建了ARC-AGI基准专门测试模型在抽象推理、少样本泛化这些维度的表现而不是单纯比谁背下来的知识多。这个举动本身就是一种观点——大语言模型擅长的是从海量语料里学习统计规律然后流畅地重组语言。但“重组语言”和“自主完成一个复杂的物理世界任务”之间隔着一道尚未被跨过的能力鸿沟。把这条逻辑搬到AI生物安全风险上会得到一个关键推论如果一个人没有在物理世界里真正做过高风险的生物实验仅仅靠对话生成一份看起来详细的实验流程这个流程到底可不可行在现实环节是会出问题的。不是说它一定无害而是说我们必须先问清楚“模型在这个环节里到底贡献了什么”。是贡献了真正导致危害的核心思路还是只充当了一个信息整理器1.2 他真正反对的是“以能力臆想代替能力验证”肖莱在多种场合反驳过一种叙事深度学习一旦做到足够大就会像人类一样思考和规划然后掌握所有知识进而产生自我意识和反叛动机。他强调当前系统并不具备我们通常理解的“行动者”属性模型没有内在目标、没有持续主动性也不能自发地围绕一个复杂目标制定长期计划。这种反驳并不是说“AI绝对安全”。恰恰相反它是在要求更严谨的安全分析方式你得先验证一件事是不是真的可行再讨论它有多危险。危险不能靠脑补来定义。放到生物安全语境下就会出现一个有趣的分层。支持“AI生物安全风险高”的人会说模型能够给学生物的新手提供大量可执行细节从而降低制造危害的门槛。反对的人会说这类知识很多已经在公开文献里存在是否存在一本模型可能并没有那么关键。两条路线的分歧本质上不是“是否应该担心”而是“风险的主要贡献者到底是模型能力还是人类本身对知识的获取与使用”。作为技术从业者我更愿意用肖莱这个立场作为判断起点不要默认模型全知全能也不要默认它绝对鲁棒。用工程方式去验证才能得到一个相对可控的风险画面。2. AI生物安全风险为什么突然成为热点2.1 风险叙事的三层叠加AI生物安全风险这个词组近几年热度上升并不是因为某一次单一事件彻底改变了局面而是几类担忧被叠加到了一起。第一层是能力担忧。大模型确实展现出很强的跨领域知识能力能写代码、做推理、翻译文献、总结论文。于是很自然地有人推断既然它什么都知道那么它在生物领域也一定具备专业知识甚至可以根据用户需求生成危险方案。这个推断在逻辑上很顺滑但在现实中缺少完整验证。第二层是工具普及担忧。以前想检索生物领域的敏感知识你需要知道找什么数据库、用什么关键词、怎么筛选文献。但现在大模型让人可以用自然语言提问门槛确实降低了。于是大家会担心一些本来没有专业能力的人可以借由AI获得自己原本接触不到的信息。第三层是入口爆炸担忧。模型不是只在浏览器里存在它还被集成在客服系统、内部知识库、代码插件、办公套件里。当AI成为通用入口它处理的信息流变得更复杂安全问题也更难追踪。这一层对工程师来说最熟悉也最具体。这三层担忧叠加自然把“AI生物安全风险”变成了一个热门话题。但热门话题并不等于已经发生的现实。它更像一个信号我们还没有足够成熟的机制去评估模型在不同领域里的真实风险所以恐慌先走了一步。2.2 不能把“模型能生成文本”直接等同于“模型能实施危害”这里必须做一个非常朴素的切割文字即动作信息即能力。一个模型能写出一段关于某种危险试剂的合成描述和它能在现实世界里帮你完成一次危险试剂的制备是两种完全不同的能力。前者是语言生成任务后者涉及原料获取、实验操作、设备安全、环境控制、废弃物处理、失败重试等一连串物理过程。模型生成的文本可以描述这个过程但并不能代替这个过程。肖莱的思路在这里特别有参考价值。他觉得当前的模型更像是在一个封闭的文字符号空间里工作它缺少对真实世界因果关系的持续感知。模型可以输出“如果你的反应体系温度过高可能导致危险”但它很难知道这一刻实验里实际温度是多少、设备有没有故障、操作者是否受训。这些信息模型拿不到也不会真正去感知。所以从工程角度看“AI生物安全风险”实际上可以被拆成两个子问题一是模型能否提供足够精确且可执行的危险信息二是模型能否参与或驱动整个物理实施过程。前者是文本能力问题后者是机器人与自动化问题。把两个问题混在一起讨论风险很容易被高估。3. 用工程视角拆解AI在生物安全链路中的真实位置3.1 知识层AI确实可以充当高效的知识检索器我们不能走向另一个极端说大模型在生物安全领域毫无作用。如果用它来辅助科研、整理文献、设计实验方案、识别合成路线中的潜在问题它确实能提升效率。这种效率提升是真实的也是当前AI被广泛应用的价值所在。但“提升效率”和“独立制造危害”之间差得很远。一个高级生物专家用AI辅助自己设计一个全新的实验方案和一个小白用AI对话几轮就想做出一个高危险产物完全不是同一种风险景象。前者是专业能力的加速器后者是信息获取门槛的降低。现实中的风险并不呈现为“AI突然掌握了制造生物武器的方法”而更可能出现在两个角落一是小白真的把AI输出的内容当成了完整操作手册忽略现实变量二是专业人士利用AI压缩了大量前期调研时间从而加快了某种研究的进度。这两个方向都需要治理但治理方式完全不同。比如果断一点的判断如果模型中包含的参数、条件、注意事项存在幻觉那么它输出的高风险实验方案可能根本不可执行也可能在关键步骤上出现错漏。这种情况下AI的实际危害可能被高估因为它并不稳定到足以成为“可靠的专家”但它也可能在某个偶发场景下真的给出一个相对完整且危险的方案。所以问题不在于“AI是不是万能”而在于“AI在什么情况下会被误信为一个可靠的专家”。这恰恰是“AI幻觉”的研究范畴。模型生成的专业建议表面上看起来很权威、结构清晰、引用规范但里面可能是编造的文献和算错的浓度配比。一个没有经验的人如何分辨这些输出哪些可信、哪些不能信这才是真正的风险点。3.2 实验层物理世界的约束模型替不了执行者生物安全风险最终要落到物理操作上。实验过程中涉及的样本准备、设备消毒、温度控制、无菌操作、个人防护、废液处理这些环节任何一个出错都可能产生严重后果。把这些环节做出来需要人或者自动化设备。当前最主流的交互形态——浏览器对话框里的AI——根本接触不到这些物理环节。有人会说AI可以调用外部工具可以控制机器人。这是一个真实的技术方向但也是目前尚未成熟的方向。我们讨论AI生物安全风险的时候如果默认“AI已经能够自主控制实验设备”那是在拿未来的可能性替代当下的现实。肖莱批评这类想法时经常提到的点也在这里我们总是习惯把未来可能实现的技术能力提前赋予当下的系统然后基于这个错误前提讨论风险。工程经验告诉我判断一个系统能不能完成某个任务唯一可靠的方法是看它是否真的完成了而不是看它有没有能力描述完成步骤。这也是为什么很多实验室自动化项目实际落地时最难的不是模型推理而是设备接口、样本状态、环境变化、异常恢复这些物理变量。3.3 行动计划层有自主规划能力的AI Agent还远谈不上稳定当前行业里AI Agent是一个热词。大家希望模型不只是回答问题还能自己拆解任务、调用工具、执行动作、观察结果然后迭代。如果这样的Agent真的成熟它对安全问题的冲击会大得多因为它让模型从“文字生成者”变成“行动参与者”。但正因为这样我们更要诚实地评估Agent目前的状态。从工程实践看Agent在长链路任务里经常会出问题任务拆解不合理、工具调用参数错误、中间结果处理不当、遇到异常不会恢复。这些问题不是单纯靠更大模型就能解决的它涉及系统设计、状态管理、反馈机制、失败重试等一系列工程问题。放在生物安全场景里这意味着一个能够完成“从文献调研、设计路线、控制设备、分析结果到修正方案”的完整Agent距离我们并没有想象中那么近。它更像一个被过度宣传的方向而不是一个今天就能被恶意使用的现实工具。如果你正在做Agent开发这里的实际建议是不要只测正常链路一定要测异常链路。Agent在某个环节卡住后是继续执行还是停下求助它会不会在状态不确定时做出错误决策这些问题的答案决定了一个Agent是否适合被投入高风险场景。4. 真正值得开发者关注的工程风险不是“模型要造反”4.1 AI幻觉带来的错误级联很多人讨论AI安全时把问题推到“模型自主性”上好像最可怕的事情是模型产生恶意。但从实际生产经验看更容易出问题的其实是模型一本正经地胡编——也就是AI幻觉。在一个知识密集场景里幻觉的后果会被级联放大。模型给出一条不存在的文献引用工程师可能会顺着这条假文献去做调研模型计算出一个错误的配比实验人员可能会照着执行。如果流程里没有人工复核一个早期幻觉就可能在后端被放大成一次严重的实验事故或判断失误。所以如果你负责把AI集成到专业系统里第一件要做的事不是去幻想机器人造反而是建立一个输出校验机制。让模型的生成结果能被权威数据源校验让危险或关键操作需要人工确认。这种机制看起来不够酷但它才是真正能减少现实损失的事情。4.2 模型被滥用时的输入输出管控另一个实际风险是模型被恶意绕过来生成违规内容。几乎所有大模型产品都会做安全对齐禁止生成涉及高危行为的内容。但绕过安全对齐不是一个新鲜问题攻击者可以通过换表述、分步提问、伪装角色等方式让模型在多层对话中逐步生成危险信息。工程上这需要做多层防线。输入侧可以加分类器判断当前请求是否可能涉及敏感内容输出侧可以加检测规则识别模型生成的文本是否包含高危关键词组合对话层可以加上下文审计追踪多轮对话是否在诱导模型解锁限制。这些措施都不是完美的但可以大大提高滥用的成本。这里我要特别提醒如果做模型部署不要只依赖模型厂商的安全配置。不同模型版本的拒绝策略不一样提示词稍微换一下情况就可能完全不同。把这一点当成“依赖版本问题”来对待。上线前的安全测试必须包含对抗性样本和边界case而不是只跑几个常规样例。4.3 谁为AI建议“兜底”责任链设计更根本的工程问题是责任链设计。当AI给出的建议被用户执行后产生负面后果谁来负责是模型提供方、应用开发方、部署方还是最终使用者这个责任归属如果不清晰安全机制很难真正落地。常见的做法是做一个分层设计。第一层模型负责输出候选方案但不做最终决策。第二层系统中的规则引擎或专家知识库对候选方案做校验剔除明显不合理的部分。第三层在高风险决策前强制人工确认。第四层全程记录日志方便事后追溯。这种设计的思想是AI是参与者不是决策者。即使某个时刻模型输出有问题系统也有能力在后续环节把它拦住。这比试图训练一个永远不会犯错的模型要现实得多。5. 一套面向AI项目的风险评估框架5.1 第一步评估模型能力边界而不是先入为主假设威胁拿到一个开源模型或者API应该先做能力探测。不是直接根据文档描述推断它能做什么而是用一组代表性测试集去验证它在目标领域的真实表现。如果你关心生物安全风险那么在测试集里可以包含生物学知识问答、实验方案设计、危险信息识别、安全边界探测等场景。核心目标只有一个搞清楚模型在哪些设置下输出稳定在哪些设置下开始胡编在哪些设置下可以被绕过。这个步骤没有捷径必须有足够多样化的测试样本。5.2 第二步画出真实行为链路把“用户输入 → 模型处理 → 输出 → 外部工具调用 → 用户执行”的完整链路画出来然后逐个环节问风险可能出现在哪里。在用户输入环节风险是诱导与伪装在模型处理环节风险是幻觉与潜在恶意对齐在输出环节风险是格式污染与错误指令在外部工具调用环节风险是API误调用、权限扩大、数据泄露在用户执行环节风险是错误理解与盲目相信。画出链路之后你会发现模型的“恶意”只是整条链路里很小的一部分更多问题来自系统设计和用户行为。5.3 第三步为高风险场景设置人工介入点对于任何可能存在高风险后果的环节都要设置人工介入点。规则很简单只要自动化判断的置信度不够高就把人拉进来。具体落地时可以分三个级别。绿色场景模型直接输出用户自行判断黄色场景系统给出警告要求用户确认是否继续红色场景直接终止输出或强制跳到人工审核流程。这三个级别的划分需要结合具体业务场景反复调整。不要等出了事再补要先预设好规则。5.4 第四步持续用新评测重新校准模型不是一次部署就永久不变的。API端的模型版本会更新开源模型的微调版本会迭代同一个模型在不同提示词风格下的表现也会漂移。如果一直沿用旧的安全评估结果真实风险很可能被低估。所以建议把安全评测做成例行流程而不是一次性工作。每次模型版本变更都要重新跑一遍对抗样本测试。同时也要从日志里收集真实用户的异常输入和违规尝试持续增强防护。这个过程和模型性能监控一样是整个工程体系的一部分。6. 工程师该如何面对这类宏大叙事6.1 区分“风险管理”与“情绪管理”AI安全相关的话题存在大量情绪化表达。每出现一个大模型发布社交媒体上都会出现“AI即将掌控世界”或“AI生物安全风险已迫在眉睫”一类的声音。这类表达在传播上有优势但对工程实践没有太大帮助。工程师需要做的是把宏大命题翻译成具体问题风险来自哪个环节概率有多大影响面有多广是否有缓解措施如何验证缓解措施有效。这些问题不需要大词只需要细致和耐心的测试。肖莱对AI安全讨论的启发也在于此。他反复提醒我们不要把模型能力当作一个未经检验的信仰。这句话放在风险讨论里可以翻译成不要因为模型生成了一份看起来很危险的方案就断定它能完成一次危险的行动。6.2 与其争论“会不会”不如先落实“能不能被追踪”在AI系统里可追踪性可能是最接近“抗风险”的能力。如果每一个关键输出、每一次工具调用、每一次高风险决策都被记录在案那么即使问题发生了我们也能快速定位是哪个环节出了错然后针对性修复。这个思路要落地并不需要特别高级的技术。日志里记录请求ID、用户标识、模型版本、上下文摘要、输出内容、人工审核意见然后做一个简单的审计平台。这些事情不难难的是愿意在平稳期投入成本去做。等到出了事再补代价往往高得多。6.3 落到行动先跑通小场景再建系统边界如果你正在做AI应用开发我建议不要被“AI危害人类”的宏大叙事带偏。先选择一个具体的小场景比如一个内部知识库问答系统或者一个面向特定用户的内容生成工具把之前说的能力测试、链路分析、人工介入点、日志审计都做一遍。在这个小系统里验证安全设计的有效性再逐步扩大范围。这样做的好处有两个。第一你不会在没有任何数据支撑的情况下凭想象设计一套很重的安全架构结果发现根本不适用。第二你可以积累自己的风险案例库真正理解模型在哪些方面可靠、在哪些方面不稳定。这份经验远比任何外部结论可靠。7. 把AI安全讨论带回到“能力验证”这个原点回到开头那个饭桌问题。一个完全没有生物背景的人能否靠大模型生成一套可执行的高危方案我倾向的答案仍然是“不能简单说能或不能”。它取决于模型能力、安全对齐强度、用户的已有知识、物理操作的现实门槛以及整个系统有没有设置人工介入点。每一项都是一个变量不是一句“AI很危险”或“AI无害”能概括的。肖莱在这类讨论中的真正价值不是提供一个结论而是提供一种方法先验证能力再讨论风险。不管你是AI应用开发者、模型部署者还是技术决策者都可以借用这个思路。不要默认模型很强大也不要默认模型很弱小。先去跑测试再去判断边界。如果你真的把这条路径走通了你会发现很多宏大的AI恐惧在具体工程里都会变得可控、可拆解、可回应。正如肖莱所强调的我们离真正的通用智能还有很长一段距离。这段时间也许正是工程实践者最应该用来夯实安全体系的窗口。等能力真的接近通用时如果你还没有一套成熟的安全机制那才是真正需要焦虑的事。
