GitHub Copilot | The .NET Blog

Azure DevOps MCP服务器4月更新：WIQL查询、PAT认证和实验性MCP Apps

Emiliano Montesdeoca — Mon, 27 Apr 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击这里。

Azure DevOps MCP服务器持续改进。Dan Hellem的四月更新同时覆盖了本地和远程服务器。

WIQL查询支持

新的wit_query_by_wiql工具允许直接从MCP客户端运行工作项查询语言查询。

个人访问令牌

本地服务器上的PAT身份验证 — 对于没有交互式身份验证的集成场景很重要。

MCP注解

只读、破坏性和开放世界工具的元数据标签 — 代理可靠性的基础。

Wiki工具整合

5个独立的wiki工具 → 2个更强大的工具。工具越少 = LLM性能越好。

实验性：MCP Apps

在MCP服务器环境中打包的工作流。方向是对的。

Dan Hellem的原始文章：Azure DevOps MCP Server April Update。

VS Code 1.118：Copilot CLI 获得会话名称、模型徽章和 TypeScript 7.0 夜间版选择加入

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

本文已自动翻译。如需查看原文，请点击此处。

Visual Studio Code 1.118 是一个较小的专注版本——主要是 Copilot CLI 的改进——但有几点值得关注。

Copilot CLI：会话拥有真实名称

Copilot CLI SDK 的会话标题 API 现在用作会话名称的真实来源。会话显示 SDK 中的实际名称，而非自动生成的标签。

使用键盘快捷键快速切换会话

Agents 应用现在绑定了 Ctrl+1、Ctrl+2 等快捷键，用于快速切换会话。

聊天中的模型徽章

Copilot CLI 在聊天面板中的回复现在显示模型徽章——一眼即可看出哪个模型处理了每个请求。

Copilot CLI 中的自动模型选择

自动模型选择功能——之前在 Copilot 的其他部分已可用——现在也在 Copilot CLI 代理中工作。

TypeScript 7.0 夜间版选择加入

现在可以直接从 VS Code 设置中选择加入测试 TypeScript 7.0 夜间版。TypeScript 7.0 是一个重大版本（测试版几天前发布）。

查看完整发行说明。

每天花68分钟重新解释代码？这里有个解决方案

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击这里。

你知道那个时刻——当你的Copilot会话触发/compact，代理完全忘记你在做什么？你花接下来五分钟重新解释文件结构、失败的测试、你已经尝试过的三种方法。然后又发生了。

Desi Villanueva测量了一下：每天68分钟 — 仅用于重新定向。不是写代码，不是审查PR，只是让AI了解它已经知道的事情。

上下文窗口的谎言

实际计算：200K总上下文，减去MCP工具65K，减去指令文件10K，实际上在你输入任何内容之前只剩125K。LLM在60%容量时会撞墙，有效限制是45K token。

压缩税

残忍的部分：记忆已经存在。 Copilot CLI将每个会话写入~/.copilot/session-store.db中的本地SQLite数据库。代理只是无法读取它。

auto-memory：召回层，而非记忆系统

pip install auto-memory

~1,900行Python。零依赖。30秒安装完成。

不是用grep结果淹没上下文，而是给代理外科式访问真正重要的内容——50个token而不是10,000个。

总结

上下文腐烂是真实的架构约束。auto-memory通过给你的代理提供廉价、精确的召回机制来绕过它。

查看：GitHub上的auto-memory。Desi Villanueva的原始文章：I Wasted 68 Minutes a Day。

azd + GitHub Copilot：AI 驱动的项目设置和智能错误修复

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

本文为自动翻译。如需阅读英文原文，请点击这里。

你是否有过这样的经历：想把现有应用部署到 Azure，却盯着空白的 azure.yaml 发呆，想不起来 Express API 到底该用 Container Apps 还是 App Service？这种时刻即将成为历史。

Azure Developer CLI（azd）现已与 GitHub Copilot 以两种实用的方式集成：azd init 时的 AI 辅助项目脚手架，以及部署失败时的智能错误排查。两项功能都完全在终端内运行——正是我想要的方式。

在 azd init 中使用 Copilot 设置

运行 azd init 时，现在会出现"Set up with GitHub Copilot (Preview)“选项。选择它，Copilot 会分析你的代码库，根据实际代码生成 azure.yaml、基础架构模板和 Bicep 模块。

azd init
# 选择："Set up with GitHub Copilot (Preview)"

前提条件：

azd 1.23.11 或更高版本 — 用 azd version 检查，或用 azd update 更新
有效的 GitHub Copilot 订阅（Individual、Business 或 Enterprise）
GitHub CLI（gh） — 必要时 azd 会提示登录

我觉得真正实用的是它能双向工作。从零开始构建？Copilot 从一开始就帮你配置正确的 Azure 服务。有现有应用想部署？把 Copilot 指向它，无需重构代码即可生成配置。

它实际做什么

假设你有一个 Node.js Express API，依赖 PostgreSQL。不必手动在 Container Apps 和 App Service 之间抉择，也不必从零编写 Bicep，Copilot 检测到你的技术栈后会生成：

包含正确 language、host 和 build 设置的 azure.yaml
Azure Container Apps 的 Bicep 模块
Azure Database for PostgreSQL 的 Bicep 模块

并在做任何更改前运行预检——验证 git 工作目录是否干净，提前请求 MCP 服务器工具的授权。一切都在你知情的情况下进行。

Copilot 驱动的错误排查

部署错误无可避免。缺少参数、权限问题、SKU 可用性问题——而错误信息很少告诉你真正需要知道的那一件事：如何修复。

没有 Copilot 时的循环：复制错误 → 搜索文档 → 读三篇不相关的 Stack Overflow 回答 → 运行一些 az CLI 命令 → 重试并祈祷。有了集成在 azd 中的 Copilot，这个循环消失了。任何 azd 命令失败时，它会立即提供四个选项：

Explain — 用通俗语言解释出了什么问题
Guidance — 逐步修复指导
Diagnose and Guide — 完整分析 + Copilot 应用修复（经你批准）+ 可选重试
Skip — 自己处理

关键在于：Copilot 已经了解你的项目、失败的命令和错误详情。它的建议针对你的具体情况，而非泛泛的文档。

设置默认行为

如果你总是选择同一个选项，可以跳过交互式提示：

azd config set copilot.errorHandling.category troubleshoot

可选值：explain、guidance、troubleshoot、fix、skip。还可以启用自动修复和重试：

azd config set copilot.errorHandling.fix allow

随时重置为交互模式：

azd config unset copilot.errorHandling.category

总结

这正是真正有价值的 Copilot 集成。运行 azd update 获取最新版本，在下一个项目中试试 azd init。

阅读原文公告。

VS Code 1.117：Agent 拥有了自己的 Git 分支，我举双手赞成

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

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

“AI 助手"和"AI 队友"之间的界限越来越模糊。VS Code 1.117 刚刚发布，完整的发行说明内容丰富，但核心很明确：Agent 正在成为你开发工作流中的一等公民。

以下是真正重要的内容。

Autopilot 模式终于能记住你的偏好了

以前，你每次开始新会话都得重新启用 Autopilot。很烦。现在你的权限模式会在会话之间持久化，你还可以配置默认值。

Agent Host 支持三种会话配置：

Default — 工具在运行前会请求确认
Bypass — 自动批准一切
Autopilot — 完全自主，自己回答问题并继续执行

如果你正在搭建一个带有迁移、Docker 和 CI 的新 .NET 项目——设置一次 Autopilot 就行了。这个偏好会一直保持。

Agent 会话的 worktree 和 git 隔离

这是重头戏。Agent 会话现在支持完整的 worktree 和 git 隔离。这意味着当一个 Agent 处理任务时，它会获得自己的分支和工作目录。你的主分支完全不受影响。

更好的是——Copilot CLI 会为这些 worktree 会话生成有意义的分支名称。不再是 agent-session-abc123。你会得到一个真正描述 Agent 正在做什么的名称。

对于管理多个功能分支或在长时间脚手架任务运行期间修复 bug 的 .NET 开发者来说，这是一个游戏规则的改变。你可以让一个 Agent 在一个 worktree 中构建 API 控制器，同时你在另一个 worktree 中调试服务层问题。没有冲突。没有 stash。没有混乱。

子 Agent 和 Agent 团队

Agent Host Protocol 现在支持子 Agent。一个 Agent 可以启动其他 Agent 来处理任务的各个部分。把它想象成委派——你的主 Agent 负责协调，专门的 Agent 处理各个部分。

这还处于早期阶段，但对 .NET 工作流的潜力显而易见。想象一下，一个 Agent 处理你的 EF Core 迁移，另一个设置你的集成测试。我们还没有完全到达那里，但协议支持现在落地意味着工具很快就会跟上。

Agent 发送输入时终端输出自动包含

虽小但有意义。当 Agent 向终端发送输入时，终端输出现在会自动包含在上下文中。以前，Agent 需要额外的一个回合才能读取发生了什么。

如果你曾经看到一个 Agent 运行 dotnet build，失败了，然后又需要一次往返才能看到错误——这种摩擦消失了。它立即看到输出并做出反应。

macOS 上的 Agents 应用自动更新

macOS 上的独立 Agents 应用现在可以自动更新了。不再需要手动下载新版本。它会自动保持最新。

值得了解的小改进

package.json 悬停提示现在同时显示已安装版本和最新可用版本。如果你在 .NET 项目旁边管理 npm 工具，这很有用。
JSDoc 注释中的图片在悬停和补全中正确渲染。
Copilot CLI 会话现在会显示是由 VS Code 还是外部创建的——当你在终端之间切换时很方便。
Copilot CLI、Claude Code 和 Gemini CLI 被识别为 shell 类型。编辑器知道你在运行什么。

总结

VS Code 1.117 不是一个花哨的功能堆砌。它是基础设施。Worktree 隔离、持久化权限、子 Agent 协议——这些是构建一个工作流的基石，在这个工作流中，Agent 可以处理真实的并行任务而不会干扰你的代码。

如果你正在用 .NET 开发，还没有尝试 Agent 工作流，说实话，现在就是开始的时候。

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 扩展在你自己的代码库上试试。

智能体平台工程正在成为现实 — 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和策略需要是什么样子，才能让智能体安全地使用它们。

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

Visual Studio 3月更新允许构建自定义Copilot代理 — find_symbol是一大亮点

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

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

Visual Studio刚刚获得了最重要的Copilot更新。Mark Downie 发布了3月版本，标题是自定义代理——但说实话，find_symbol工具可能才是最能改变你工作流的功能。

仓库中的自定义Copilot代理

想让Copilot遵循你团队的编码标准？自定义代理定义为.github/agents/中的.agent.md文件。每个代理都有完整的工作区感知、代码理解、工具、首选模型和MCP连接访问权限。

代理技能：可复用的指令包

技能从仓库的.github/skills/或个人资料的~/.copilot/skills/自动加载。

find_symbol：语言感知导航

新的find_symbol工具为Copilot的代理模式提供了基于语言服务的符号导航。代理不再搜索文本，而是可以找到符号的所有引用并访问类型信息和作用域。

对于.NET开发者来说这是巨大改进——拥有深层类型层次结构的C#代码库受益匪浅。

用Copilot分析测试性能

Test Explorer上下文菜单中新增了Profile with Copilot。Profiling Agent自动运行测试并分析性能。

实时调试中的Perf Tips

性能优化现在在调试过程中进行。Visual Studio内联显示执行时间。看到慢的行？点击Perf Tip向Copilot请求优化建议。

从Solution Explorer修复NuGet漏洞

当检测到NuGet包漏洞时，Solution Explorer中直接显示Fix with GitHub Copilot链接。

总结

自定义代理和技能是标题，但find_symbol是隐藏的亮点——它从根本上改变了Copilot重构.NET代码时的准确性。下载Visual Studio 2026 Insiders来体验所有新功能。