企业人工智能噩梦:丧失对运行内容的洞察掌控力,新思路亟待开启!

📅 2026/8/3 17:17:39
企业人工智能噩梦:丧失对运行内容的洞察掌控力,新思路亟待开启!
机器之心编辑部了解到企业人工智能的噩梦并非是杀人机器人而是我们对自身环境中运行内容的洞察和掌控能力逐渐丧失。是时候醒醒了。如今关于企业人工智能即将融入生产系统的讨论不绝于耳。或许你没意识到这一现实——或者说噩梦取决于你如何应对——其实早已来临。一切往往始于一个“试点项目”、“原型”或者“副业”。也许有人用智能体搭建了一个内部仪表盘这个仪表盘很快变得不可或缺转眼间原本的试验就成了正式项目。在此过程中没人去问那些看似枯燥又麻烦的问题到底从 npm、PyPI 或 Docker Hub 拉取了什么认证是如何配置的或者曾经是如何配置的有没有人关注智能体选用的工具和库是否遭受供应链攻击而且这并非个别项目或少数应用的问题。人工智能让企业能够以前所未有的速度编写更多代码、推出更多产品和项目。等到安全团队介入时业务已经对其产生依赖回不了头了真正的噩梦就此开始。有三大问题让这场噩梦成为现实。未明确选择的组件当你让人工智能智能体开发应用时它并非只生成一个简单的脚本而是围绕你描述的问题悄然构建起一整个生态系统。它会引入一个 Web 框架抓取一堆库搭建数据库还可能基于容器镜像中的依赖项构建一切。从生产力角度看这很棒但从安全角度讲至少可以说令人担忧。我自己用这种方式开发应用时若不回头让智能体解释根本说不清楚用了哪些组件。在如今这个时代任何人都能在 npm 或 PyPI 上发布内容我们也看到过攻击者将恶意软件包混入这些生态系统或者篡改广泛使用的软件包。近期就有一些事件安全和运维工具拉取了被篡改的依赖项以高权限在持续集成/持续部署CI/CD流程中运行悄悄窃取机密信息或篡改构建过程。几个月前我就亲身经历过这种情况不得不更新 GitHub 上的所有凭证。随意拉取未经审查的代码本就糟糕现在再加上人工智能智能体问题就更严重了。它们默认选择最容易找到和集成的内容。如果某个软件包能解决智能体面临的问题它就会添加进去。这就像过去“从互联网上随意下载一个库”的问题但现在是自动且大规模地发生速度之快前所未见。要解决这个问题我们必须让智能体了解我们的风险承受能力、批准使用的组件列表以及我们对日志记录的要求等。我们可以通过规范文件和行业所说的“章程”来实现。总体而言这被称为“约束工程”后面我们会详细讨论。技能从编码向架构转移很多人担心如果人工智能包办了所有编码工作初级开发者是否还能真正学会编码。但这并非我所担忧的。我认为让智能体生成代码没问题这是它们擅长的工作。但它们不太擅长识别和避免代码中的问题。我已经有段时间没写代码了我能写但对我来说这么做没什么意义。对我而言更有价值的是留意智能体提出的愚蠢甚至危险或者两者皆有的建议。比如我最近在做一个个人项目时智能体提议在没有任何认证的情况下将内存服务器暴露在公网上。它把一切都连接得很顺畅乍一看一切正常且能正常运行。但我停下来思考“等等这到底是如何认证的流程中的密码、密钥或 OAuth 在哪里”结果发现根本没有认证也没有密码。如果我没有停下来思考还和智能体争论一番这个应用就会在毫无保护的情况下上线。所以技能问题不在于我们是否会失去编码能力而在于我们是否有能力提出问题、做出判断是否能在某些事情看起来或感觉不对劲时有所察觉。当智能体提出危险的软件模式时企业里是否有人能识别出来你需要有人能识别认证流程是否过于宽松、数据存储是否不应超出特定边界以及架构何时积累了大量技术债务以至于最好的办法是推倒重来。你需要有人明白“能运行”并不等同于“安全”或“正确”并且当两者不一致时能与智能体据理力争。这无关语法而是关乎架构、供应链意识以及即便原型表面看起来不错也有勇气说“我们要推倒重来把它做好”。要教导使用人工智能辅助编码的开发者基本的安全原则和架构模式。只要他们不断提问人工智能会教会他们更高级的内容。缺乏约束的智能体第三个问题是我们在开发流程中引入了非常强大的智能体却没有将它们视为需要治理的一等角色。很多企业把人工智能助手接入代码仓库或集成开发环境IDE让它们搭建项目和管道。也许他们还会加上一个安全扫描器就宣称实现了“人工智能赋能”。这并非治理模式只是盲目乐观甚至都算不上谨慎乐观。实际上一个能广泛访问你的代码仓库、CI/CD 管道和工件注册表的代码生成智能体就像是一个效率极高但未经良好训练的初级开发者能访问互联网却对组织政策毫无概念。它引入新工具、新依赖项和新模式的速度远超你的审查流程所能应对的范围。在我的个人项目中我开始把这视为人工智能编码者所说的“约束工程”问题。对于每个负责构建或连接代码的智能体我都会尝试引入其他智能体至少从概念上让它们起到制衡作用。例如一个智能体专注于安全查找明显的漏洞和不良实践另一个关注架构指出应用设计何时走向难以维护的方向第三个则着眼于性能和可靠性问题毕竟在考虑拒绝服务和资源耗尽等情况时这也是一种安全隐患。再结合为智能体提供架构、安全和设计基本原则的章程这就不再是凭感觉编码而是为所有项目进行大规模的约束工程。我所做的并不完美在这个领域也没有完美的解决方案因为这些都是非确定性的统计工具。但很多企业连这一步都没做到。实际上它们的智能体在自行其是凭感觉编码不受可信注册表或加固基础镜像的限制也无需以安全部门可审计的方式记录决策。没人负责约束这意味着很多实施决策已完全从人类手中转移到无人真正监管的系统中。新问题需要新思路企业人工智能的噩梦并非杀人机器人而是在我们的开发速度呈爆炸式增长之际我们对自身环境中运行内容的洞察和掌控能力逐渐丧失。危险在于放弃控制权在于推出内部和外部客户喜爱且不愿舍弃但本质上不安全的应用程序。此刻你所在的企业中可能就有人在用人工智能开发一个功能强大的应用从不知何处拉取不知何物然后添加到你的基础设施中。好消息是这些问题是可以识别的也是可以解决的不过需要一种与过去不同的新思路。你必须从统计学角度思考制定包含基本原则的章程。你可以标准化可信技术栈和注册表。你可以围绕架构安全而非仅仅是“安全编码”对人员进行再培训。你可以开始将智能体约束视为值得进行设计审查和修改的系统。但在企业愿意承认这场噩梦已经来临之前这一切都无法实现。关键词人工智能生成式 AI软件开发代码安全安全