AI智能体事故累计已达数万起，业界争论“安全召回”是否可行

知名AI研究者Gary Marcus在最新评论中引用Axios的独家报道指出，OpenAI等前沿模型公司正在排查的安全事件数量已经累计到数万起，远超此前公开披露的“几十起”。

这个数字和过去几年里大模型厂商反复强调的“可管可控”形成强烈反差，也让“安全事件到底有多少”这件事重新成为讨论焦点。

事件规模之所以被迅速放大，是因为涉及的不再是聊天机器人给出错误答案，而是能自动操作浏览器、执行代码、调用外部工具的AI智能体。

智能体一旦具备执行权限，一次判断失误就可能改文件、发邮件、转账、下单，这是传统聊天模型几乎不会碰到的风险面。

Marcus的主张：先暂停，再复盘

Marcus的立场很直接：在这些问题被系统性解决之前，应该临时召回通用型AI智能体，而不是等到出大事再补救。

他提到自己在2023年5月就向美国参议院预警过智能体风险，现在等于把三年前的担忧摆回到台面上。

在他看来，召回类似汽车行业发现刹车缺陷后先停售，AI智能体在安全机制没有验证之前也应该暂停对普通用户开放高权限能力。

业界分歧：“召回”并不容易执行

不过，多位从业者对“召回是否现实”持保留态度。智能体并不是一台可以统一关停的设备，它通常以API、插件或浏览器扩展形式部署，厂商很难强制收回所有调用入口。

更复杂的是，第三方开发者会在厂商模型之上自建工作流，一旦暂停底层能力，下游应用也会被一起按下暂停键，损失不小。

也有观点认为，与其追求一次性“召回”，不如要求智能体在执行高风险动作前必须经过人类确认，这更像是渐进式的安全护栏。

对中文用户和开发者的实际影响

对国内AI工具使用者来说，这条新闻更值得当作风险信号而不是恐慌来源。

如果你正在用Agent类工具跑自动化流程，建议把“删除文件、对外发送、调用支付”等动作单独拆出来，加一道人工确认。

企业用户在做选型时，也可以把厂商是否提供“危险动作拦截、审计日志、权限分级”列入评估清单，而不是只看模型跑分。

后续值得观察的几件事

第一，几万起事件的分布和类型是否会公开，比如多少来自智能体，多少来自普通对话。

第二，监管和厂商是否会推出类似“灰度发布”或“高风险操作强制确认”的行业标准。

第三，开源智能体框架会不会跟进类似机制，因为这批项目的安全责任往往落在开发者自己身上。

短期看，“召回”更像一种立场表达；长期看，它倒逼行业把智能体安全从一句口号，变成可以验证、可以追溯的工程问题。