Docker Sandbox 让 Copilot 代理重构你的代码而不危及你的机器

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

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

如果你用过 Copilot 的代理模式做一些超出小修改范围的事情，你一定知道那种痛苦。每次写文件，每个终端命令——又一个权限提示。现在想象一下在 50 个项目上这样操作。一点都不好玩。

Azure 团队刚发布了一篇关于 GitHub Copilot 代理的 Docker Sandbox 的文章，说实话，这是我见过的最实用的代理工具改进之一。它使用微型虚拟机为 Copilot 提供一个完全隔离的环境，让它可以随意操作——安装包、运行构建、执行测试——而不会触及你的主机系统。

Docker Sandbox 实际给你带来什么

核心思路很简单：启动一个带有完整 Linux 环境的轻量级微型虚拟机，将你的工作区同步进去，然后让 Copilot 代理在里面自由操作。完成后，更改会同步回来。

以下是让它不仅仅是"在容器里运行东西"的特点：

双向工作区同步，保留绝对路径。你的项目结构在沙箱内看起来完全一样。不会有路径相关的构建失败。
私有 Docker 守护进程在微型虚拟机内运行。代理可以构建和运行容器，而无需挂载你主机的 Docker socket。这对安全性来说意义重大。
HTTP/HTTPS 过滤代理控制代理在网络上可以访问什么。你来决定允许哪些注册表和端点。沙箱内恶意 npm install 带来的供应链攻击？已封锁。
YOLO 模式——是的，他们就是这么叫的。代理运行时无需权限提示，因为它根本无法损坏你的主机。每一个破坏性操作都被隔离了。

为什么 .NET 开发者应该关注

想想现在有多少团队正在面对现代化工作。你有一个包含 30 个项目的 .NET Framework 解决方案，需要迁移到 .NET 9。那是数百个文件的更改——项目文件、命名空间更新、API 替换、NuGet 迁移。

使用 Docker Sandbox，你可以将 Copilot 代理指向一个项目，让它在微型虚拟机内自由重构，运行 dotnet build 和 dotnet test 进行验证，然后只接受那些真正有效的更改。不用担心它在实验过程中意外破坏你的本地开发环境。

文章还描述了运行并行代理舰队的场景——每个代理在自己的沙箱中——同时处理不同的项目。对于大型 .NET 解决方案或微服务架构来说，这是一个巨大的时间节省。每个服务一个代理，全部隔离运行，全部独立验证。

安全角度很重要

大多数人忽略的一点是：当你让 AI 代理执行任意命令时，你是在把整台机器都托付给它。Docker Sandbox 翻转了这个模型。代理在一次性环境中获得完全自主权。网络代理确保它只能从已批准的来源下载。你的主机文件系统、Docker 守护进程和凭据完好无损。

对于有合规要求的团队——这是大多数企业级 .NET 公司的情况——这就是"我们不能使用代理式 AI"和"我们可以安全地采用它"之间的区别。

总结

Docker Sandbox 解决了代理式编程的根本矛盾：代理需要自由才能发挥作用，但在你的主机上拥有自由是危险的。微型虚拟机两者兼得。如果你正在规划任何大规模的 .NET 重构或现代化，现在就值得设置起来。Copilot 的代码智能与安全执行环境的结合，正是生产团队一直在等待的。

GitHub Copilot 的现代化评估是你还没用上的最好迁移工具

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

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

将传统 .NET Framework 应用迁移到现代 .NET 是那种每个人都知道应该做但没人想开始的任务。它从来不是简单的"更改目标框架"。而是消失的 API、不再存在的包、工作方式完全不同的托管模型，以及关于什么要容器化、什么要重写、什么要保持不变的无数小决策。

Jeffrey Fritz 刚刚发布了一篇 GitHub Copilot 现代化评估的深入解析，说实话？这是我见过的 .NET 最好的迁移工具。不是因为代码生成 — 那现在已经是标配了。而是因为它生成的评估文档。

它不仅仅是代码建议引擎

VS Code 扩展遵循评估 → 计划 → 执行模型。评估阶段分析你的整个代码库，生成一份结构化文档，捕获一切：什么需要更改、需要配置哪些 Azure 资源、使用什么部署模型。下游的一切 — 基础设施即代码、容器化、部署清单 — 都源自评估发现的内容。

评估存储在项目的 .github/modernize/assessment/ 下。每次运行产生一份独立的报告，因此你可以积累历史记录，并在修复问题时跟踪迁移态势的演变。

两种开始方式

推荐评估 — 快捷路径。从策划好的领域（Java/.NET 升级、云就绪、安全）中选择，无需配置即可获得有意义的结果。非常适合初次了解应用的状态。

自定义评估 — 定向路径。精确配置要分析的内容：目标计算（App Service、AKS、Container Apps）、目标操作系统、容器化分析。选择多个 Azure 目标来并排比较迁移方法。

那个比较视图真的很有用。一个应用在 App Service 上可能有 3 个必须解决的问题，在 AKS 上可能有 7 个。看到两者有助于在确定迁移路径之前做出托管决策。

问题分解是可操作的

每个问题都带有严重程度级别：

必须 — 必须修复，否则迁移失败
潜在 — 可能影响迁移，需要人工判断
可选 — 推荐的改进，不会阻止迁移

每个问题都链接到受影响的文件和行号，提供详细描述说明什么地方有问题以及为什么对目标平台重要，给出具体的修复步骤（不仅仅是"修复这个"），并包含官方文档链接。

你可以将单个问题分配给开发者，他们拥有行动所需的一切。这就是告诉你"有个问题"的工具和告诉你如何解决的工具之间的区别。

涵盖的升级路径

针对 .NET 具体来说：

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

每条升级路径都有检测规则，知道哪些 API 被移除、哪些模式没有直接等价物、哪些安全问题需要关注。

对于管理多个应用的团队，还有一个 CLI 支持多仓库批量评估 — 克隆所有仓库，全部评估，获取每个应用的报告加上汇总的组合视图。

我的看法

如果你坐拥传统 .NET Framework 应用（说实话，大多数企业团队都是这样），这就是那个应该开始使用的工具。仅评估文档就值得投入时间 — 它将模糊的"我们应该现代化"变成了一个具体的、有优先级的工作项列表，指明了前进的方向。

协作工作流也很聪明：导出评估、与团队分享、无需重新运行即可导入。决策者不是运行工具的人的架构评审？涵盖了。

总结

GitHub Copilot 的现代化评估将 .NET 迁移从一个可怕的、不明确的项目转变为一个结构化的、可跟踪的过程。从推荐评估开始了解你的现状，然后使用自定义评估来比较 Azure 目标并制定迁移计划。

阅读完整演练并获取 VS Code 扩展在你自己的代码库上试试。

Modernization | The .NET Blog