从 EKS 迁往 GKE，谷歌想让 AI 生成的配置先过审

谷歌新开源的 GKE 智能体迁移工具，试图改变一种常见做法：把原有配置交给大模型，让它直接写出替代文件。谷歌介绍，这款面向迁移的智能体插件将大语言模型的推理能力与确定性工具、防护机制结合。关键不在于 AI 能否写出配置，而在于生成结果能否被独立检查，并在部署前接受工程团队的审查。2

迁移要核对的是行为，不只是文件格式

从亚马逊云科技的 EKS 迁往 Google Kubernetes Engine（GKE），不只是改写 Kubernetes 配置字段。团队还需弄清工作负载依赖什么资源、流量如何抵达服务，以及节点能否提供所需容量。谷歌的容器迁移指南也把工作负载及其依赖关系的评估放在迁移前期。19

对于拟议的配置转换，至少有三类问题值得逐项核对：

• **身份与权限：**将 AWS 身份配置对应到 GKE 的 Workload Identity 后，工作负载是否仍能访问必要资源，又不会获得多余权限？
• **流量入口：**将负载均衡器入口规则转换为 Gateway API 配置后，请求是否仍按预期路由？
• **节点供给：**转换节点配置后，工作负载的调度方式与可用容量是否仍满足要求？

这些是迁移工作流中的审核问题，并非已有证据表明工具能自动、完整地处理每一种情况。配置文件即使格式正确，也可能改变实际权限、流量走向或容量条件。

确定性检查与代码审查各管一段

按相同规则对生成文件做离线检查，比让模型自行解释“为什么这样改是对的”更容易复核。但检查只能覆盖规则明确规定的内容，不能单凭一次通过就断言应用切换后会照常运行。谷歌确认该工具设有确定性防护机制；现有公告摘录并未列明离线验证的全部覆盖范围。2

在所描述的工作流中，以拉取请求（Pull Request）的形式提交变更，而非直接改动运行中的集群，可以让工程师先查看差异，再通过持续集成与持续交付（CI/CD）流程执行测试、策略检查和审批。这与谷歌关于使用版本控制及 CI/CD 部署 GKE 的文档方向一致；不过，现有公告摘录不足以独立确认该工具拉取请求流程的每个具体步骤。172

Persistent 高管 Rahul Shrivastava 在谷歌公告中称，这种方法是“可验证、编译器级的迁移工厂”。这个比喻强调产出与检查迁移文件，并不等于数学意义上证明整次迁移安全。上线前仍须测试运行行为、访问权限、性能、依赖关系和切换过程。2

与 Intrinsic Core：相似的开放思路，不同的技术问题

在 GKE 公告发布前两天，Intrinsic 于 2026 年 9 月 22 日在多伦多举行的 ROSCon 2026 上介绍了 Intrinsic Core。这套开源、兼容机器人操作系统 ROS 的基础能力涵盖控制、运动与抓取规划、仿真和位姿估计；报道指出其采用 Apache 2.0 许可。Intrinsic 还介绍了不依赖特定硬件的实时控制框架和数字孪生能力。403337

两项发布的联系是战略层面，不是技术上的直接整合：GKE 工具可能降低迁移到谷歌云的操作门槛，Intrinsic Core 则可能降低工业机器人应用的开发门槛。有报道以“机器人的 Android”概括后一种开放基础能力、吸引开发者建立生态的思路。但无论哪项发布，都不能单独证明 AWS 客户会迁走，或开发者最终会购买谷歌的云与 AI 服务。230

**对企业团队而言，结论很实际：**让 AI 提出修改、让规则和人员决定能否采用，有助于把迁移纳入现有工程流程；它并不免除逐项验证的责任。目前提供的资料也没有给出迁移失败率或成本下降的实测数据。219