摆脱“AI 就是魔法”的思维定式：为什么了解 AI 模型的工作原理必须成为全公司的优先事项

在有关失控 AI 智能体的警告声中，一名开发者最近让一个编程智能体不受限制地使用一台没有远程备份的机器。不到两分钟，它就删除了 48,000 个文件。

这类事件鲜明地提醒我们，部署 AI 智能体伴随着风险；在复杂流程中的某个环节安排人工审核，并不能让人就此认定流程是安全的。有些流程无需干预，另一些则需要严格得多的检查。修正一个错别字和删除数千个文件，显然风险等级不同，因此监督力度应当与实际风险相称。

组织必须更善于识别哪些时刻确实需要人的判断，尤其是在行动影响重大或难以撤销时。而且，一旦智能体出错，运行环境就需要限制其造成的影响范围。

AI 并非确定性的，而是概率性的

首先，也是最重要的一点，每一位直接或间接参与软件开发的员工，都必须对 AI 模型如何处理信息有基本了解。这绝非易事；这需要投入精力对团队开展培训，最终还应成为全公司的共同目标。

刚开始与 AI 互动时，人们会觉得它像魔法。你输入一句话，转眼间就开始了一场对话。要制定全公司的 AI 政策，尤其是涉及安全和生产力的政策，了解模型和训练在幕后究竟如何运作至关重要。神经网络、分词、背后的统计分析，以及这些环节如何最终产生输出，都将成为面向全体员工开展教育的重要内容。

大型语言模型永远无法产生确定性的结果。它们的输出具有概率性。使用传统软件时，输入信息后，你大致可以预期输出会是 A、B 或 C。但使用 AI 时，你可能得到 F、一个 & 符号，或者一段描写戴着太阳镜的猫的文字。

对于概率性事物，无法用常规方式进行测试。你需要一种测试方法，能够快速调整、推理、理解并提取上下文，从而发现概率性因素，并识别这些因素可能引发的问题。根据规模和风险，这类测试既可以由 AI 执行，也可以由具备相关专业知识的人来负责。在流程刚开始时让人参与其中最为有用，这样才能明确要解决的问题，并在最后进行审核。

开发者最有机会观察组织内部 AI 如何根据输入生成答案，以及其中涉及的变量和常见做法，因此他们能够很好地帮助公司制定 AI 教育计划，确保每个人都理解 AI 中确定性与概率性的区别，以及这种区别为何重要。目标是减少一种思维定式：把使用 AI 当作施展魔法，并满足于它给出的任何结果。相反，组织应努力揭开 AI 的神秘面纱，清楚说明业务正在使用哪些模型、如何使用这些模型、可能出现哪些问题、如何进行检查，以及检查流程产生了什么结果。

防护措施应设在基础设施中，而不是模型里

一旦揭开 AI 的“魔法”面纱，AI 主导的项目开始推进，就必须制定透明的审计政策，确保所有工作都按照预期推进。这样一来，如果项目产出的结果“不好”或不达标，负责人就可以审查已执行的步骤，防止问题再次发生。如果结果好于预期，这种政策也有帮助，因为相关步骤同样可以复制，并推广给其他项目或团队。

对于大型公司而言，将这一流程系统化尤为重要，因为每个团队可能有数十名开发者，而全天有数百名开发者在编写代码。AI 能以极快的速度完成许多工作；一旦出了问题，就必须有一套机制，准确判断问题发生在哪个步骤。看看今年夏天 OpenAI 的智能体入侵 Hugging Face一事。OpenAI 当时正在测试其模型利用软件漏洞的能力，使用的基准测试名为 ExploitGym。为了进行测试，OpenAI 有意放宽了模型对攻击性网络活动的拒绝限制。离开沙箱的唯一通道是一个软件包代理。模型发现了该代理中的一个未知漏洞，逃出了沙箱，并在 Hugging Face 的生产系统中待了两天多，寻找测试答案。

新闻标题称这是一起 AI 失控事件。我认为，这是在概率性系统周围搭建了一个确定性的环境。OpenAI 要求模型实施攻击，随后却寄望于它们始终沿着预期路径行动。该基准测试的创建者表示，模型以前也曾在测试中作弊，但始终没有离开沙箱。这一次，有一个模型越出了沙箱。标准防护措施假定行为符合常规，但 AI 并不一定会遵循常规。

这就是为什么 AI 安全归根结底取决于访问权限和控制措施，并且这些措施应由运行环境强制执行，而不是寄希望于模型行为良好。要假设智能体会尝试每一扇门，只留下它真正需要通过的门。那个删除了 48,000 个文件的智能体，原本被要求只处理副本，不要动原件。但它还是把原件删了。指令不等于控制措施。

管理智能体的权限，就像为一名新入职的初级开发人员办理入职一样。你不会在第一天就给他们生产环境的 root 权限。如果你这么做了，而他们又删掉了数据库，你不会把这归咎于他们是个天才黑客。无论安全事件规模大小，找出根本原因都至关重要。问题出在模型吗？出在创建模型的公司吗？还是出在允许模型访问的公司？无论原因是什么，最终都要由人承担责任。

最后，今天亟待解决的一个关键问题，是开发人员的笔记本电脑上那些不为人知的操作。过去，工作流程更容易追踪。开发人员编写代码、审查代码并发布代码，因此一旦出错，就能清楚地追溯到问题发生的时刻。现在，开发人员可能会把工单交给智能体，并对它说：“修好这个问题。”如果这些工作都在视线之外进行，就无从追踪。每一步都需要留下完整记录：运行的是哪个智能体、使用了哪个模型、收到过哪些提示词、调用了哪些工具，以及当时拥有哪些权限。将智能体集中运行，而不是让它们各自在个人笔记本电脑上运行，是实现这一目标的一种方式。关键是要留下完整记录。

归根结底，一旦发生事件，每家公司都需要保护自己。留下的记录应包含足够的信息，以便进行根本原因分析，并找出导致问题的环节和代码。

AI 已极大地改变了世界，业务流程也必须随之改变。要确定适当的防护措施，就必须更深入地了解 AI 流程、测试、审查周期和审计周期，既要在开发团队内部做到这一点，也要在整个公司范围内做到这一点。