AI 智能体依赖管理存风险：“最新”并非“安全”，该如何应对？

AI 智能体依赖管理的风险与应对建议AI 智能体通过层层委托让工作变得更轻松然而这些委托层会形成依赖关系而这些依赖关系又会带来风险。米切尔·哈西莫托Mitchell Hashimoto建议大家停止更新依赖项从历史经验来看这听起来简直疯狂透顶。但经历了今年春季 npm 发生的一系列事件后他的建议或许不再像是异端邪说反而更像是一种有效的控制手段。他的规则是对依赖项进行分叉精简到实际使用的部分除非用户遇到问题否则不要更新。在一个习惯将“最新”等同于“安全”的行业里这种做法听起来很鲁莽。但今年春天 npm 的两次严重攻击中受影响最严重的往往是那些使用最新版本的人。如 axios HTTP 客户端库被攻击时攻击者发布受污染版本约三小时内全新安装的机器被植入远程访问木马node - ipc 发布受污染版本后Mini Shai - Hulud 蠕虫传播到多个软件包。防范这种情况也许什么都不做就是最好的办法设置冷却期是有效的防御方法。依赖树脱离包管理器带来的风险几十年来我们将重复性工作外包给各种库开源因专业化分工和资源共享而可行但这也带来了风险。AI 加剧了这种风险因为依赖树不再局限于代码编码智能体的各项功能增加了受攻击的面。普渡大学研究人员对七个生态系统中的 117,062 个依赖项变更研究发现AI 智能体选择已知易受攻击软件包版本的频率比人类更高且做出的错误选择更难纠正。智能体还会创造不存在的依赖项成为攻击面。MCP 层也存在问题微软记录过工具投毒情况依赖模型遵循安全指令时超 25% 的情况会违反策略OWASP 指出工具响应进入模型上下文无审核机制。提示词问题及“最新”与“安全”的关系肖恩·戈德克Sean Goedecke指出提示词会引入技术债务且会悄然恶化。一个在某个模型上有效的提示词在另一个模型上可能表现不同。大多数团队不测试、审查或清理提示词内容会让智能体做出更糟糕的决策。哈西莫托的极端规则虽不能解决问题且多数团队无法遵循但背后原则正确每个依赖项都应有存在理由每次更新都应有合理原因。这与现代开发理念和智能体工作方式格格不入。AI 不能消除工程规范最终判断仍需人工完成。潜在漏洞与哈西莫托方法的完善哈西莫托的方法假设冻结的依赖项中未被发现的缺陷会一直不被发现但有了 AI这个假设不再成立。今年 4 月Anthropic 的 Claude Mythos 预览版自主发现并构建针对旧漏洞的有效利用程序一个月后谷歌威胁研究人员标记首个由 AI 开发的零日漏洞。这需要对哈西莫托的规则进行完善将依赖项精简到仅满足自己的使用场景分叉依赖项让模型先为自己评估代码了解攻击面并持续评估。减少依赖深入理解最优秀的 AI 工程团队不会将智能体应用到所有地方聪明的工程师会确切知道引入的依赖项及其影响。应将 MCP 服务器、智能体工具或第三方软件包视为生产依赖项严格审查。戈德克主张简化配置层治理团队对留存内容进行版本管理、审查和管控。行业中很多技术一开始带来解放后来成为运营负担智能体也遵循同样模式我们要更谨慎对待它们。关键词人工智能、代码安全、安全、开发工具、软件开发、安全实践、生成式 AI