用 Agentic Platform Engineering 消除迁移的重复性工作

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击此处.

Removing the Monkey Work of Migration with Agentic Platform Engineering — Git-Ape（git 智能体平台工程工具）将真实的 AWS Terraform 仓库迁移到 Azure 的演练，专注于提取部署意图而非逐行转换。

输入：contoso-migration

源项目是一个真实的 Terraform 项目（contoso-migration），在 AWS 上部署 Next.js 应用——EC2 用于计算，ALB 用于负载均衡，S3 用于制品，IAM 密钥用于身份认证。成本：约 34 美元/月。目标不是在 Azure 上复现相同的基础设施；而是弄清楚这个部署实际上要做什么，然后用 Azure 原生服务重新构建它。

步骤 1：验证与认证

Git-Ape 首先验证所有必需的 CLI 工具——az、aws、gh、jq、git——并在进行任何操作之前确认活跃的认证会话。不做部分运行。

步骤 2：意图提取

智能体通过 GitHub API 读取整个源仓库，并提取部署意图：运行时（Node.js）、计算类型、入口模式、制品处理、身份模型、网络和监控。这是关键步骤——它构建了一个关于部署做什么的语义模型，而不是它使用了哪些 Terraform 关键字。

步骤 3：服务映射

AWS 服务映射到 Azure 等效服务：

EC2 → App Service（Linux，Node 20 LTS）
ALB → App Service 内置负载均衡
IAM 角色/密钥 → Managed Identity
Terraform → Bicep + GitHub Actions

步骤 4：评审智能体

在生成输出之前，评审智能体运行并发现两个阻塞问题：

启动时构建反模式 — 原始 Terraform 在 EC2 启动时运行 npm install && npm run build。修复：在 CI 中构建，部署已就绪的制品。
不必要的 Blob Storage — S3 用于制品暂存，通过适当的 CI/CD 可以完全省去。评审智能体将其彻底删除。

步骤 5：生成的输出

结果是约 80 行 Bicep，而不是原来的 200 多行 Terraform。智能体创建了一个新的 GitHub 仓库，包含 infra/main.bicep 和 .github/workflows/deploy.yml，并删除了所有 AWS 特定文件。

安全态势对比

迁移还带来了显著的安全升级：

AWS 原始	Azure 输出
仅 HTTP	仅 HTTPS，TLS 1.2
SSH 对 0.0.0.0/0 开放	无 SSH 暴露
IAM 访问密钥	OIDC + Managed Identity
无监控	Application Insights

成本：约 13 美元/月，而原来是 34 美元/月。

与语法转换器的区别

评审智能体步骤是将其与机械翻译区分开来的关键。它发现了在 AWS 上可行但在 Azure 上会出错的模式——并修复了它们而不是复制它们。输出不是"Azure 语法的 AWS"；而是以更简洁方式实现同一目标的 Azure 原生部署。

请查看完整演练以获取完整的智能体追踪和生成的文件。

智能体平台工程正在成为现实 — Git-APE展示了方法

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

平台工程一直是那种在技术大会上听起来很棒的术语，但通常意味着"我们搭了一个内部门户和一个Terraform封装器。“真正的承诺 — 真正安全、受治理且快速的自助式基础设施 — 总是差那么几步。

Azure团队刚刚发布了智能体平台工程系列的第二部分，这次全是关于动手实现。他们称之为Git-APE（是的，这个缩写是故意的），这是一个开源项目，使用GitHub Copilot智能体加Azure MCP服务器，将自然语言请求转化为经过验证和部署的基础设施。

Git-APE究竟做什么

核心思路：开发者不再需要学习Terraform模块、浏览门户UI或向平台团队提交工单，而是直接和Copilot智能体对话。智能体理解意图、生成基础设施即代码、根据策略进行验证并部署 — 全部在VS Code内完成。

配置如下：

git clone https://github.com/Azure/git-ape
cd git-ape

在VS Code中打开工作区，GitHub Copilot会自动发现智能体配置文件。你直接与智能体交互：

@git-ape deploy a function app with storage in West Europe

智能体在底层使用Azure MCP Server与Azure服务交互。VS Code设置中的MCP配置启用特定功能：

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

为什么这很重要

对于我们在Azure上构建的人来说，这将平台工程的对话从"如何构建一个门户"转变为"如何将我们的护栏描述为API。“当你的平台接口是AI智能体时，你的约束和策略的质量就成了产品本身。

第一部分博客阐述了理论：描述良好的API、控制模式和明确的护栏使平台做好了智能体化的准备。第二部分通过交付实际工具证明它确实有效。智能体不会盲目生成资源 — 它会根据最佳实践进行验证、遵守命名约定并应用你组织的策略。

清理同样简单：

@git-ape destroy my-resource-group

我的看法

说实话 — 这里更多是关于模式而非具体工具。Git-APE本身是一个演示/参考架构。但底层的理念 — 智能体作为平台的接口、MCP作为协议、GitHub Copilot作为宿主 — 这就是企业开发者体验的前进方向。

如果你是一个正在寻找如何让内部工具对智能体友好的平台团队，没有比这更好的起点了。如果你是.NET开发者想知道这和你的世界如何关联：Azure MCP Server和GitHub Copilot智能体可以与任何Azure工作负载配合使用。你的ASP.NET Core API、你的.NET Aspire技术栈、你的容器化微服务 — 都可以成为智能体部署流程的目标。

总结

Git-APE是对智能体平台工程实践的一个早期但具体的展示。克隆仓库，试试演示，开始思考你的平台的API和策略需要是什么样子，才能让智能体安全地使用它们。

阅读完整文章获取详细教程和演示视频。

Platform Engineering | The .NET Blog