AI能在几分钟内改动成百上千行代码，但平台团队真正耗时的环节往往在后面：服务之间怎么连接、计划部署和实际运行差在哪、云凭证是否正确、失败后能不能恢复。微软Radius团队公开的Radius Canvas预览版，试图把这段断层收进GitHub Copilot应用侧栏。它不是再加一个聊天窗口，而是让人和Agent在同一张可操作的应用图上审查、确认并推进部署。

四张图把“代码已改”变成“部署可审”

Radius Canvas会读取仓库内容，生成或更新.radius/app.bicep应用定义，再把服务、数据库、消息队列和连接关系画出来。Modeled视图对应代码设计，Planned视图展示目标环境中的部署计划，Deployed视图反映正在运行的资源，Diff视图则比较两个分支。这样，审查者看到的不只是文件增删，而是一次变更会影响哪些服务和基础设施。

这对Agent写代码后的交付尤其关键。模型可能补齐容器设置或基础设施定义，却不一定理解组织的云规范。Radius把开发者写下的应用意图与平台团队提供的Recipe结合，让基础设施选择继续由组织约束。官方变更记录还强调，模型文件以原子方式发布：生成或校验失败时，现有定义不会被半截结果覆盖。

五个技能串起环境、身份与部署

插件把流程拆成五个技能：应用建模、应用图、云环境、部署和删除。用户可以让Copilot根据仓库生成定义、刷新关系图、配置AWS或Azure环境，再触发生成的GitHub Actions工作流。Canvas负责展示选择的仓库、分支、身份与进度，Agent负责调用相应能力，最终动作仍留给人确认。

身份并没有被简化成一枚长期密钥。官方文档为Azure环境列出GitHub OIDC、服务主体、AKS Azure RBAC和可定制的信任主体等路径，并要求验证凭证、脱敏诊断。失败时，界面提供重试、继续或回滚，而不是只返回一段终端日志。对平台工程来说，这些控制比“Agent能否一键部署”更接近真实上线条件。

删除也被当成需要治理的生产动作

Radius Canvas没有把删除包装成无摩擦按钮。相关技能要求先确认应用部署，再按依赖顺序清理环境；共享资源或人工修改过的资源应被保留，只有资源卡死时才提供带警告的强制恢复路径。状态变更命令需要确认，执行后还要回到画布验证结果。这套设计把Agent定位为受控执行者，而不是拥有无限权限的云管理员。

更值得注意的是，界面、技能和工作流使用同一套状态。审查者可以从图上的资源节点跳回源码，也能从失败状态拿到经过处理的诊断命令。模型生成、平台策略、CI执行和人工审批因此不再分散在四个互不相见的工具里，这正是企业AI交付中经常缺失的闭环。

编辑判断：可见性补上了，成熟度仍要验证

Radius Canvas的价值，不在于把部署按钮搬进Copilot，而在于给Agent的改动增加了可视化差异、身份边界、确认步骤和恢复路径。它让开发者看到基础设施后果，也让平台团队能把组织规则放在生成结果之前。对于正在尝试FDE或Agent辅助交付的团队，这是一种比纯聊天更可审查的工作界面。

但它仍是0.1.0预览版。官方没有披露具名生产客户、部署成功率、节省工时或故障数据，当前能力也围绕Radius、GitHub Actions及特定云环境展开。安装说明中的市场别名仍有变化痕迹，团队不应直接把预览插件接入关键生产账号。更稳妥的试点，是从隔离订阅和非关键应用开始，验证最小权限、失败回滚、资源漂移、并发变更和人工接管。

ATYUN编辑判断：Agent进入软件交付后，最稀缺的不是更多自动化，而是让每次动作可见、可确认、可追溯、可撤回。Radius Canvas给出了一个早期样本；它是否能成为长期生产入口，要看预览阶段之后能否用真实部署数据证明可靠性。