Continue + Stakpak：增强 DevOps 能力

Chad Metcalf

• 4分钟阅读
Four server racks in a row, with perforated doors, revealing stacks of variedservers with multicolored cabling and LEDs.
图片由 Taylor Vick / Unsplash

我们刚刚与 Stakpak 合作，将专业的 DevOps 能力引入 Continue，我对此非常兴奋。为什么？因为我以前就靠这个为生。

DevOps 的现实：它仍然复杂

很久很久以前，在一个遥远的星系，我曾领导 Cloudera 的基础设施团队。在“DevOps”这个词出现之前，我们就在做类似的工作——编写大量的 Puppet 代码来管理 Hadoop 集群。我们当时在构建自己的数据中心，并使用一家书店公司提供的这些新兴的“云”服务，比如 S3 和 EC2。学习曲线极其陡峭，因为需要掌握的领域太多了。

后来，我在 Docker 工作了几年，编写 Dockerfiles、Terraform 和 Kubernetes manifests。我记得凌晨两点盯着 YAML 文件解决 PEBKAC 问题时，心里想着为什么我们还没构建出更好的工具。

classic_pebkac.gif

这就是2025年 DevOps 的现状：尽管我们在基础设施即代码方面取得了令人难以置信的进步，但认知负担仍然很大。每个组织对于这些强大的工具都有自己的方法。

  • 基础设施工具需要深入理解特定于云的配置和模式
  • Kubernetes manifests 涉及许多相互关联的部分，并有组织特定的要求
  • Dockerfiles 可以很简单，直到你发现自己需要为层缓存优化多架构构建时就变得复杂了

而通用型 AI 编程助手，尽管取得了很大进展，有时仍然难以处理你的基础设施。

为什么通用型 AI 助手在 DevOps 方面表现不足

问题在于，大多数 AI 助手将基础设施代码视为普通代码，但它们并非如此。当你的 Python 脚本有 bug 时，它会抛出异常。而基础设施代码更棘手——AI 可以生成通过验证的完全有效的 Terraform 代码，但这代码可能根本不应该出现在你的代码库中。模型是在更广泛的互联网如何使用这些工具的方式上训练的，但每个人的基础设施都是不同的。

在处理基础设施时，我注意到黑箱 AI 助手经常难以应对几个 DevOps 特有的挑战

  1. 验证时机晚：配置问题通常只有在部署过程中才会显现出来
  2. 提供商知识不断变化：云 API 和最佳实践持续更新
  3. 安全考量各异：不同组织有不同的安全要求
  4. 最佳实践取决于上下文：对一个团队有效的基础设施模式可能不适用于另一个团队

在我那些年敲击花括号的日子里，我亲身经历了这些挑战，并经常希望有工具能更好地理解我们团队正在使用的基础设施上下文。

为不同领域构建专业助手

当我们创建 Continue 时，我们做了一个根本性的设计决定：不构建一个通用助手，而是创建一个平台，让专业助手可以针对不同的开发领域进行构建。

未来在于能够深入理解你特定开发上下文的定制助手。每个领域都有其自身的工具、模式和挑战。

对于前端开发者来说，这可能意味着理解组件库和设计系统。对于数据科学家来说，是连接到 notebooks 和数据源。而对于 DevOps 来说，则意味着理解基础设施即代码的格式、云提供商的要求以及组织特定的实践。

Stakpak：理解基础设施的 DevOps AI

这正是 Stakpak 的作用所在。他们为 DevOps 构建了专门的模型，这些模型能够理解基础设施代码。

  • 他们为 Terraform 实现了 95% 的单次有效率，帮助你减少修复配置的时间，将更多时间用于构建有用的基础设施。
  • 他们的模型理解基础设施工具的 schema 和约束，而不仅仅是语法。
  • 他们不断更新对云提供商 API 和最佳实践的了解。

但最令人兴奋的部分是什么？通过我们使用模型上下文协议 (MCP) 的集成，你现在可以直接在你的日常 Continue 工作流程中访问这些专业功能。无需再在工具之间切换或复制/粘贴生成的配置。

这在实践中意味着什么

假设你正在处理一个 Terraform 项目，需要在 AWS 中搭建一个新的微服务基础设施。你需要一个带有合适网络、IAM 角色和安全组的 ECS 集群。

传统方法可能包括

  1. 搜索符合你特定需求的示例
  2. 调整之前项目中的代码以适应新的上下文
  3. 阅读云提供商文档以了解当前的最佳实践
  4. 多次尝试部署以确保一切正常工作
  5. 一周后回来玩 IAM 打地鼠，因为安全审查反馈变更不符合他们的指导方针。

有了 Continue + Stakpak，你可以

  1. 用简单的语言描述你需要什么
  2. 获得一个很可能第一次尝试就能工作的 Terraform 配置
  3. 专注于重要的架构决策，而不是语法

我真希望几年前就有这个。那些花费在调试 Terraform 状态问题或追踪 Kubernetes 网络问题上的时间，本可以用来改进架构。

如何尝试

设置它很简单

  1. 安装适用于 VS Code 或 JetBrains 的 Continue
  2. 前往 Continue Hub 创建一个新的助手
  3. 将 Stakpak MCP 服务器添加到你的助手
  4. 将此添加到你的 config.yaml 中（在此获取免费的 Stakpak API 密钥）
name: Stakpak
version: 0.0.1
schema: v1

mcpServers:
  - name: stakpak
    command: npx
    args:
      - "@stakpak/mcp@latest"
      - "STAKPAK_API_KEY=YOUR_API_KEY"

然后只需开始描述你需要的基础设施，看看它是如何生成实际可用的配置文件的。

未来展望

这仅仅是专业 DevOps 辅助能力的开始。Stakpak 团队正在开发更宏伟的工具——能够调试云问题或自动化部署的“终结者式代理”。

未来不仅仅是生成代码——而是关于理解你的整个基础设施生命周期的 AI。

在基础设施和 DevOps 领域工作多年后，我开始欣赏那些能够满足开发者需求、尊重他们环境复杂性的工具。我对 Continue 的可扩展性与 Stakpak 的专业 DevOps 能力相结合感到兴奋，因为它帮助团队专注于重要的架构决策，同时减轻了基础设施工作的认知负担。

了解更多

Stakpak 撰写了他们对此次合作的看法。请查阅他们的公告，了解他们对此次集成如何减轻 DevOps 工作痛苦的观点。

在我们的 Discord 上加入其他 DevOps 同行，分享你使用 Stakpak 集成的经验，并诉说基础设施领域的“战争故事”。