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
