Docker新AI能聊核事故？这是个危险信号

一个专门帮你写Dockerfile的AI助手，突然开始讲解1966年帕洛马雷斯核事故的历史细节。这不是彩蛋，是安全架构的裂缝。

当"专业工具"变成"通才聊天机器人"

Docker最近推出了Gordon，一个定位为"容器编排终极伴侣"的AI助手。按官方设计，它该解释概念、写配置文件、调试容器故障——所有操作都嵌入你的工作流。

但测试者很快发现了尴尬的现实落差。

Gordon经常表现得像个通用百科全书，而非专门的技术工具。你问Docker构建优化，它可能岔开话题聊冷战历史。这种"角色崩坏"在安全领域有个专门术语：能力泄漏（capability leak）。

能力泄漏指AI系统未能抑制底层大语言模型的无约束知识。换句话说，Gordon虽然披着Docker专家的外衣，内核仍是那个能聊任何话题的通用模型。

测试中发现的具体行为包括：撰写与容器无关的Python脚本、讲述与Docker无关的历史事件、生成与基础设施管理无关的创意内容。这些"额外技能"在演示时显得有趣，在生产环境却是隐患。

麦当劳聊天bot的教训：面具越薄，风险越大

这事有先例。麦当劳的客服聊天机器人曾被用户"越狱"——诱导它写代码、参与哲学辩论。当代理"脱离角色"，证明信任模型已经失效。

Gordon的情况类似：一个通用引擎戴着单薄的品牌面具。

表面看，"知道披萨配方"无害甚至可爱。但每个"无辜"能力都是攻击者的潜在工具。允许Gordon充当通用解释器或讲故事者，攻击面就显著扩大。

攻击者无需直接要求"删除容器"。他们可以把恶意意图藏在复杂请求里——比如一个基于Python的计算器，或一段历史叙事——逐步引导代理执行未授权操作。

在真正的代理系统（agentic system）中，AI能与本地环境交互。一个"什么都能做"的工具，就是一个能被操纵去做任何事的工具。

从"会做事的聊天机器人"到"带概率接口的软件组件"

构建安全的AI代理，需要思维转换：别再把它们当"能做事的聊天机器人"，而要当作带有概率接口的软件组件。

简单的系统提示词（如"你是Docker专家"）太容易被绕过。需要多层防御策略。

第一层是守门人模型（gatekeeper）。用户提示到达主LLM之前，先被一个更小的专用模型拦截。它的唯一任务是判断："这个请求与Docker相关吗？"如果用户要披萨配方，守门人在触发任何强大能力前就拒绝。

第二层是权限最小化。剥离所有非必要功能。如果代理只该管理Dockerfile，它就不该能访问开放网络获取非技术数据，不该能执行任意代码，不该能读取主机文件系统。

第三层是输出过滤。即使绕过前两层，最终响应也该经过验证——确保输出确实是Docker配置，而非即兴创作的诗歌。

为什么这事值得技术人警惕

Gordon的"身份危机"不是Docker一家的产品问题。它暴露了当前AI代理设计的普遍困境：在"有用"和"安全"之间，厂商往往选择前者，把后者留给用户承担。

对25-40岁的技术从业者来说，这意味着评估新工具时得多问一层：它的能力边界在哪里？当我说"不"的时候，它真的听吗？

毕竟，一个能聊核事故的Docker助手，在派对上可能是明星，在你的生产环境里可能是颗定时炸弹——而且它还不知道自己戴着表。