DevOps 要进入“自动驾驶”时代?Stakpak 正在解决企业最难啃的交付难题
一款用于保护系统安全、遏制破坏性操作并集中知识的开源 DevOps 代理。科技领域的一切似乎总在以惊人的速度变化 —— 但 DevOps 基础设施除外。事实上,[Stakpak](https://stakpak.dev/) 的联合创始人兼 CEO [George Fahmy](https://www.linkedin.com/in/george-fahmy-b0978212a/) 表示,管理基础设施正变得越来越困难 —— 尽管 AI 浪潮来袭,情况依然如此。又或者,这正是 AI 浪潮所致?“自从大语言模型 (LLM) 问世以来……我们意识到它们非常擅长编码——而大多数开发者也确实喜欢编码。但对于开发者需要处理的其他所有事情,它们就一窍不通了。”“让 LLM 在处理所有开发者们实际上不喜欢做的事情时变得可靠。”Fahmy 认为,[DevOps 基础设施](https://thenewstack.io/devops/) 早该进行一次彻底的改革了。他指出,近年来,就连自动驾驶汽车取得的进展都比基础设施工具要多。“我们正努力让基础设施实现‘自动驾驶’,这样开发者就能花更多时间……去构建真正的产品。”这很难定义。DevOps 已经变成了一系列杂乱无章的职责集合,其范围早已超越了编码,还包括设置本地机器、配置云环境、管理部署流水线和生产系统等任务。正是这种包罗万象的复杂性,使得 DevOps 成为了 LLM 难以施展拳脚的 [尴尬领域](https://thenewstack.io/devops-is-still-waiting-for-its-cursor-moment/)。“对于编码任务,你只需生成代码然后运行它……但在 DevOps 领域,除了编码之外,还有无数其他的事情,而 LLM 对此并不擅长。”问题出在供需两端。一方面,DevOps 任务是出了名的拖累开发者;另一方面,行业内也极度缺乏执行这些任务所需的技能。在 [2024 State of Tech Talent Report from the Linux Foundation](https://www.linuxfoundation.org/blog/the-2024-state-of-tech-talent-report?utm_source=chatgpt.com) 中,51% 的组织将 DevOps 列为“优先配置人员的关键技术领域”之一,而填补这些职位空缺的平均时间将近六个月。“全球市场上,这类知识和专业技能存在巨大的差距。企业一直在尝试招聘 DevOps……和 DevSecOps……人才,但就是找不到合适的人选。”如今,人们的想法是让自动化——更具体地说是 AI——在时间和专业人员短缺时挺身而出,填补空白。但 Fahmy 表示,这在基础设施领域并不可行:“我们看到那些编码代理 (coding agent)……它们擅长编码,但并非为这类基础设施工作而生。”DevOps 需要操作线上系统并处理敏感数据——但 Fahmy 表示,如今大多数 [AI agents](https://thenewstack.io/welcome-to-ais-messy-middle-where-36x-gains-require-distinguished-engineers/) 所依赖的工具在生产级别的安全性方面还达不到标准。“因此,我们开始重建这个工具层并将其开源,因为我们希望为这些工具的安全性设定一个标准,使其能够处理生产环境的工作。”他指的是 Stakpak,一个 [完全开源的 DevOps 代理 (DevOps agent)](https://github.com/stakpak/agent),可以帮助开发人员保护、部署和维护生产就绪的基础设施。根据 Fahmy 的说法,Stakpak 通过让大语言模型 (LLM) 与敏感系统交互而无需暴露密钥,从而解决了这个安全挑战:“我们负责处理敏感信息和密钥的编辑,让 LLM 可以在不看到实际敏感数据的情况下处理这些数据。”安全并非是阻碍开发人员安全地自动化基础设施工作的唯一障碍。日益增多的基础设施管理工具也带来了令人头疼的问题。“有数百种不同的工具和数百种不同的方式来做同样的事情,所以你可以使用三四种不同的工具……或者你可以将它们组合在一起。”这听起来很方便:更多选择,更高灵活性。但实际上,数量庞大的工具(以及随之而来的各种相互冲突的观点)只会造成更多的困惑、摩擦和风险。当本应帮助开发人员管理这些工具的 AI 代理 (AI agent) 反而制造出新问题时,麻烦就加倍了。Fahmy 回忆起现在臭名昭著的 [Replit 灾难性事件](https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/),当时一个代理意外地删除了某家倒霉公司的整个代码库。“这些代理和模型——它们极具创造力,它们能找到很多不同的方法来做同一件事……对于试图控制它们的人来说,这简直是一场噩梦。”他声称,Stakpak 的 Warden 可以终结这场噩梦。Warden 是一个护栏系统,可以防止代理 (agent) 执行破坏性操作。这是如何实现的呢?Fahmy 表示,Warden 将编码代理封装在一个沙箱 (sandbox) 中,通过明确的安全规则来阻止不安全的操作:“例如,你可以在 AWS 中列出资源,但无法删除它们,无论你使用什么工具与 AWS 交互。”他解释说,这与那些他认为行不通的典型代理控制方法截然不同:你也不能简单地通过黑名单 (blacklist) 或白名单 (whitelist) 来限制特定操作,因为手动枚举所有可能场景是一项不可能完成的任务。相反,Warden 提供了一种确定性的 (deterministic) 方式,无论代理使用何种工具,都能阻止其执行破坏性操作。Fahmy 坦言,这对于编码工作本身价值不大。但他坚信,对于运维任务 (operational tasks) 而言,这绝对是颠覆性的。这些任务包括数据库迁移、更新或其他基础设施变更,在这些场景中,“一个错误的命令就可能导致整个系统瘫痪。”Fahmy 毫不讳言:“大语言模型 (LLM) 在处理基础设施工作方面表现糟糕。”他将此主要归因于碎片化 (fragmentation):DevOps 团队深陷于海量工具之中,但每种工具的“语言”都各不相同。而 LLM 只能可靠地处理最常见的编程语言,这让情况雪上加霜。正因如此,Fahmy 表示 Stakpak 将大量研发 (R&D) 资源投入到填补 LLM 的知识鸿沟上:“教会 LLM 使用它们从未接受过训练的新工具……;让它们获取前所未见的新知识……这极具挑战性。”与编码代理不同——你可以通过创建新的规则文件来为其补充知识——DevOps 代理需要一个共享知识库 (shared knowledge base) 才能高效运作。Fahmy 表示,Stakpak 正通过集中式规则手册和共享内存 (pooled memory) 来实现这一点:“我们认为这将带来颠覆性的改变,因为基础设施领域并不缺少工具……;真正缺少的是一种高效学习并传递新知识的方法。”Stakpak 通过集中式规则手册来定义标准操作流程 (standard operating procedures),并结合内部评估基准来衡量一致性 (alignment),从而确保代理在适应不同环境时,能够始终如一地遵循正确的流程。这只是其中一个方面。与此同时,共享内存池 (pooled memory) 让代理 (agent) 能够从过去的会话中学习。当团队成员完成一项任务时,推理模型会提取关键记忆,因此当[另一位团队成员使用该代理时](https://thenewstack.io/how-crewai-enables-ai-agents-as-collaborative-team-members/),它会记住并应用学到的知识。这种共享内存池打破了知识孤岛 (knowledge silos),Fahmy 将其描述为 DevOps 中最大的障碍:“平台或基础设施团队 [可能] 已经创建了某些东西,但开发人员仍然不知道 [它的存在]……[或者不知道它] 可以让他们的工作更轻松。”当然,这并非基础设施自动化的终点。Fahmy 表示,Stakpak 已经在着手下一个动向:让代理实现自我改进 (self-improving)。“如果你能将好的或坏的示例反馈给系统,帮助它微调 (fine-tune) 自身参数,从而在使用过程中不断进步,那会怎么样?”随着自动化的发展,DevOps 基础设施可能终于开始迎头赶上——对于那些厌倦了处理所有这些“杂事”的开发人员来说,这是一次受欢迎的升级。