自动驾驶 DevOps？Stakpak 如何应对基础设施复杂性
核心要点：Stakpak 是一个开源 DevOps 代理，帮助开发人员保护系统、遏制破坏性操作并集中知识，旨在使基础设施实现自动驾驶
技术领域的一切似乎都在以惊人的速度变化——除了 DevOps 基础设施。
实际上，Stakpak 联合创始人兼 CEO George Fahmy 表示，管理基础设施正在变得更难——尽管有 AI 浪潮。或者也许正是因为 AI？
"自从 LLM（大语言模型）出现以来……我们意识到它们真的很擅长编码——大多数开发人员实际上喜欢编码，"他评论道。"但它们在开发人员必须处理的所有其他事情上都很糟糕。"
这正是他和 Stakpak 团队着手改变的目标："让 LLM 在开发人员实际上不喜欢做的所有事情上变得可靠。"
开发人员不喜欢做（AI 无法处理）的"事情"
基础设施现状：DevOps 基础设施需要彻底改革，即使是自动驾驶汽车近年来也比基础设施工具取得了更多进展
Fahmy 认为现在是 DevOps 基础设施彻底改革的时候了，他评论说即使是自动驾驶汽车近年来也比基础设施工具取得了更多进展。
正如他所说，"我们正试图让基础设施实现自动驾驶，这样开发人员可以花更多时间……构建实际产品。"
那么，这些开发人员不喜欢做的"事情"是什么？
很难定义。DevOps 已经成为各种职责的大杂烩，延伸到编码之外，包括设置本地机器、配置云环境以及管理部署流水线和生产系统等任务。
正是这种无所不包的混合使 DevOps 成为 LLM 的尴尬空间。
"[对于]编码任务，你只需生成代码然后运行……但对于 DevOps，有无数事情……除了编码，LLM 在这方面很糟糕，"Fahmy 说。更糟的是，开发人员"讨厌做所有这些事情"。
两端都有问题。不仅 DevOps 任务对开发人员来说臭名昭著地拖累，执行这些任务所需的技能也让行业感到不足。在 Linux 基金会的 2024 年技术人才状况报告中，51% 的组织将 DevOps 命名为"优先考虑人员配备的关键技术领域"，填补这些职位的平均时间接近六个月。
"全球市场上关于这种知识和专业技能存在巨大技能差距，"Fahmy 确认。"人们一直在试图招聘 DevOps……和 DevSecOps……但他们找不到人才。"
如今，想法是让自动化——更具体地说，AI——在时间和熟练人手短缺时介入填补空白。但 Fahmy 说这对基础设施不起作用：
"我们看到编码代理……它们擅长编码，但它们不是为这种基础设施工作而构建的。"
在他看来，这归结为三个核心挑战。
挑战 1：保护生产系统和机密
安全要求：DevOps 需要在实时系统上工作并处理敏感数据，但大多数 AI 代理依赖的工具在生产级安全性方面达不到标准
DevOps 需要在实时系统上工作并处理敏感数据——但 Fahmy 表示，大多数 AI 代理今天依赖的工具在生产级安全性方面达不到标准。
"这就是为什么我们开始重建这个工具层并开源它，"他解释说，"因为我们想设定一个标准，这些东西可以有多安全才能处理生产工作。"
他指的是 Stakpak，一个完全开源的 DevOps 代理，帮助开发人员保护、部署和维护生产就绪的基础设施。
据 Fahmy 称，Stakpak 通过使 LLM 能够与敏感系统交互而不暴露机密来解决这个安全挑战："我们处理编辑敏感信息和机密，并允许 LLM 处理敏感数据而不看到实际的敏感数据。"
挑战 2：防止跨碎片化工具的破坏性操作
工具复杂性：越来越多的基础设施管理工具正在造成头痛，代理可能在碎片化的工具生态系统中执行破坏性操作
安全性不是阻止开发人员安全自动化基础设施工作的唯一障碍。越来越多的基础设施管理工具也在造成头痛。
"有数百种不同的工具和数百种不同的方法来做同样的事情，"Fahmy 解释说。"所以你可以使用三四种不同的工具……或者你可以把它们堆叠在一起。"
听起来很方便：更多选择，更多灵活性。但在现实中，过多的工具（以及随之而来的所有冲突意见）只会造成更多混乱、摩擦和风险。
当 AI 代理——那些本应帮助开发人员管理这些工具的代理——最终制造新问题时，这是双重麻烦。
Fahmy 回忆起现在臭名昭著的 Replit 惨败，一个代理意外擦除了某家可怜公司的整个代码库。
"这些代理和模型——它们超级有创意，"他说。"它们可以找到许多不同的方法来做同样的事情……对于试图控制它们的人来说，这是一场噩梦。"
一场噩梦，他声称 Stakpak 可以通过 Warden 解决，这是一个护栏系统，防止代理执行破坏性操作。
如何实现？Fahmy 说它将编码代理封装在沙盒中，显式安全规则阻止不安全操作："例如，你可以在 AWS 中列出你的资源，但不能删除它们，无论你使用什么工具来处理 AWS。"
他解释说，这与典型的代理控制方法截然不同，他声称这些方法不起作用："你不能使用一个代理来防止另一个代理破坏东西。"你也不能简单地黑名单或白名单特定操作，这会创建手动枚举每个可能场景的不可能任务。
相反，Warden 提供了一种确定性方法来防止代理执行破坏性操作，无论它使用哪种工具。
诚然，Fahmy 说这对编码不是特别有价值。但他确认这对操作任务来说是游戏规则改变者，比如数据库迁移、更新或其他基础设施变更，其中"错误的命令可能使整个系统崩溃"。
挑战 3：教代理学习、共享和记住知识
知识管理：DevOps 团队深陷工具之中，但每个工具都说不同的语言，LLM 使情况更糟，因为它们只可靠地处理最常见的编程语言
Fahmy 毫不掩饰："LLM [在]基础设施工作上很糟糕。"
他将这很大程度上归因于碎片化：DevOps 团队深陷工具之中，但每个工具都说不同的语言。LLM 使情况更糟，因为它们只可靠地处理最常见的编程语言。
这就是为什么 Fahmy 说 Stakpak 将大量研发投入到 LLM 知识差距："教 LLM 使用它们从未训练过的新工具……；[获取]它们以前从未[见过]的新知识……这超级具有挑战性。"
与编码代理不同，你可以通过创建新规则文件来添加知识，DevOps 代理需要共享知识库才能有效运作——Fahmy 说 Stakpak 通过集中规则书和池化内存交付：
"我们认为这将是一个游戏规则改变者，因为基础设施空间不缺乏很多基础设施工具……；它缺乏一种有效的方式来学习新知识然后传达它。"
Stakpak 通过定义标准操作程序的集中规则书以及测量一致性的内部评估基准来实现这一点，确保代理在适应每个环境时始终遵循正确的程序。
这只是等式的一部分。同时，池化内存允许代理从过去的会话中学习。当团队成员完成任务时，推理模型提取关键记忆，所以当代理被另一个团队成员使用时，它会记住并应用学到的知识。
这个共享内存池打破了知识孤岛，Fahmy 将其描述为 DevOps 中最大的障碍："平台或基础设施团队[可能已经]创建了某些东西，而开发人员仍然不知道[它]……[或它]可以使他们的生活更轻松。"
下一个挑战
持续改进：Stakpak 已经在应对下一个运动：使代理自我改进，通过反馈循环优化自身参数
当然，这不是基础设施自动化的终点。Fahmy 说 Stakpak 已经在应对下一个运动：使代理自我改进。
"如果你能获取坏或好的示例并将其反馈给系统，帮助它微调自己的参数，随着你继续前进而变得更好，会怎么样？"
随着自动化的进步，DevOps 基础设施可能终于开始迎头赶上——对于厌倦处理所有这些"事情"的开发人员来说，这是一个受欢迎的升级。
文档来源：Self-Driving DevOps? How Stakpak Tackles Infrastructure Complexity原始作者：Meredith Shubel原始发布日期：2025 年 12 月 29 日
本文由 AI 助手整理优化，欢迎关注、分享转载，请注明出处
