Developer Tools | The .NET Blog

VS Code 1.119：代理会话的 OpenTelemetry、浏览器集成和安全性

Emiliano Montesdeoca — Fri, 15 May 2026 00:00:00 +0000

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

VS Code 1.119 于 2026 年 5 月 6 日发布（随后发布了 1.119.1 安全补丁）。此版本专注于代理可观察性、浏览器交互和减少中断。

代理会话的 OpenTelemetry 追踪

对于在生产环境中运行代理或调试代理工作流的人来说，这是最重要的功能。通过两个设置启用：

"github.copilot.chat.otel.enabled": true,
"github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"

追踪遵循 GenAI 语义约定。每个代理请求创建一个 invoke_agent 根 span，带有嵌套子 span：chat、execute_tool 和 execute_hook。Token 使用情况按请求报告——包括缓存读取和缓存创建计数。

适用于本地代理、Copilot CLI 后台代理和 Claude 代理。任何兼容 OTLP 的后端都接受追踪——独立 Aspire 仪表板非常适合本地开发。

代理现在可以访问浏览器标签页

代理可以请求访问内置浏览器标签页——但不是自动的。你必须通过上下文选择器、拖放或建议的上下文明确共享标签页。浏览器中有一个共享按钮用于撤销访问。当代理尝试打开与已打开（未共享）标签页相同域的新标签页时，VS Code 会建议重用现有标签页。

Token 使用优化

实验性轻量级模型现在管理代理任务列表，释放主模型用于这项日常工作。减少不需要完整推理能力的任务的 token 使用。

信任和安全

减少中断：VS Code 1.119 减少了来自代理的网络访问和向临时文件夹写入的提示。1.119.1 补丁解决了特定的安全问题——如果还没有更新，值得升级。

快速切换到 Markdown 预览

小但实用：现在可以快速将当前编辑器切换到 Markdown 预览，无需导航。

VS Code Agents（Insiders 预览版）

重新设计的代理会话界面——新的仓库选择器（本地/仓库/远程）、子会话改进、Web 和移动端改进、进度动画——在 Insiders 上的 insiders.vscode.dev/agents 中可用。

完整更新日志：code.visualstudio.com/updates/v1_119。

Azure Data Studio 已停用：将您的 Azure SQL 工作流迁移到 VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

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

Azure Data Studio 于 2025 年 2 月 6 日停用，支持将于 2026 年 2 月 28 日结束——推荐的替代方案是带有 MSSQL 扩展的 VS Code。

需要安装的内容

开始所需的三样东西：

MSSQL 扩展 — 在 VS Code Marketplace 中搜索"SQL Server (mssql)"
SQL Database Projects 扩展 — 模式即代码、构建验证、引导式发布
.NET 8 SDK — 构建系统所需；SDK 缺失是首次运行时最常见的问题

迁移 ADS 连接和设置

MSSQL 扩展附带 ADS Migration Toolkit，在引导式流程中处理一次性迁移：已保存的连接、连接组、设置和键绑定均自动导入。

恢复 F5 肌肉记忆

ADS 用户依靠 F5 运行查询。安装 MSSQL Database Management Keymap 扩展，即可恢复 ADS 风格的键绑定，包括 F5。

SQL Database Projects：模式即代码

右键单击项目 → 发布 → 配置目标 → 审查生成的 T-SQL 脚本 → 部署。部署前的脚本预览是关键安全功能。项目模板为表、存储过程和视图生成存根——与 SSDT 相同的工作流。

常见问题：如果项目是针对不同的 SQL Server 版本创建的，.sqlproj 文件中的目标平台不匹配将导致构建错误。

Schema Compare 和 Schema Designer

该扩展还包括 Schema Compare（对比项目与已部署数据库的差异）和 Schema Designer（无需手动编写 DDL 即可进行可视化架构编辑）。

Microsoft Fabric 开发者

设置相同，但请先从 Fabric 门户开始，先将数据库连接到 Git，再在 VS Code 中打开。Microsoft 有专门的指南：Azure Data Studio to VS Code — What it means for SQL database in Fabric developers。

总结

迁移是一次性的引导式流程，而非手动重建。安装三个工具，运行 ADS Migration Toolkit，恢复键绑定，即可在 10 分钟内恢复正常。

请参阅完整文章，获取逐步截图和 Fabric 专属演练。

Azure MCP Server 现在是 .mcpb — 无需任何运行时即可安装

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

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

你知道配置 MCP 服务器有什么烦人的地方吗？需要运行时。npm 版需要 Node.js，pip/uvx 需要 Python，dotnet 版需要 .NET SDK。

Azure MCP Server 刚刚改变了这一切。它现在作为 .mcpb — MCP Bundle — 提供，配置方式是拖放。

什么是 MCP Bundle？

把它想象成 VS Code 扩展（.vsix）或浏览器扩展（.crx），但用于 MCP 服务器。.mcpb 文件是一个独立的 ZIP 存档，包含服务器二进制文件及其所有依赖项。

如何安装

1. 为你的平台下载 Bundle

前往 GitHub Releases 页面，下载适合你 OS 和架构的 .mcpb 文件。

2. 在 Claude Desktop 中安装

最简单的方式：在扩展设置页面（☰ → 文件 → 设置 → 扩展）打开时，将 .mcpb 文件拖放到 Claude Desktop 窗口中。查看服务器详情，点击安装，确认。完成。

3. 向 Azure 进行身份验证

az login

就这样。Azure MCP Server 使用你现有的 Azure 凭据。

能做什么

直接从 AI 客户端访问 100 多个 Azure 服务工具：

查询和管理 Cosmos DB、Storage、Key Vault、App Service、Foundry
为任何任务生成 az CLI 命令
创建 Bicep 和 Terraform 模板

开始使用

查看完整文章。

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 是一个重大版本（测试版几天前发布）。

查看完整发行说明。

azd钩子支持Python、TypeScript和.NET：告别Shell脚本

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

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

如果你曾经有一个完全用.NET构建的项目，却还需要为azd钩子编写Bash脚本，你一定懂那种痛苦。当项目其他部分都是C#时，为什么要在pre-provisioning步骤中切换到Shell语法呢？

这个问题现在有了官方解决方案。Azure Developer CLI 刚刚发布了钩子的多语言支持，效果正如预期的那么好。

什么是钩子

钩子是在azd生命周期关键节点运行的脚本——预置配置之前、部署之后等。它们在azure.yaml中定义，无需修改CLI即可注入自定义逻辑。

此前只支持Bash和PowerShell。现在可以使用Python、JavaScript、TypeScript或.NET——azd会自动处理其余的一切。

检测机制

只需将钩子指向一个文件，azd就会从文件扩展名推断语言：

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

无需额外配置。如果扩展名不明确，可以添加kind: python（或相应语言）来明确指定。

各语言的重要细节

Python

在脚本旁边（或任意父目录中）放置requirements.txt或pyproject.toml，azd会自动创建虚拟环境、安装依赖并运行脚本。

JavaScript和TypeScript

同样的模式——在脚本附近放置package.json，azd会先运行npm install。对于TypeScript，使用npx tsx，无需编译步骤，也不需要tsconfig.json。

.NET

提供两种模式：

项目模式：如果脚本旁边有.csproj文件，azd会自动运行dotnet restore和dotnet build。
单文件模式：在.NET 10+上，独立的.cs文件可通过dotnet run script.cs直接运行，无需项目文件。

执行器特定配置

每种语言都支持可选的config块：

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

对.NET开发者的意义

钩子曾是基于azd的项目中最后一个强制语言切换的地方。现在，整个部署流水线——从应用代码到基础设施脚本再到生命周期钩子——都可以使用同一种语言。你可以在钩子中复用现有的.NET工具，引用共享类库，不再需要维护Shell脚本。

总结

这看起来是个小改动，但它切实减少了日常azd工作流程中的摩擦。钩子的多语言支持现已可用——查阅官方文章获取完整文档。

Foundry Toolboxes：AI Agent工具的统一端点

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

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

有一个问题听起来无聊，直到你真正遇到它：你的组织在构建多个AI Agent，每个都需要工具，每个团队都从头开始配置。相同的Web搜索集成、相同的Azure AI Search配置、相同的GitHub MCP服务器连接——但在不同的仓库里，由不同的团队，使用不同的凭据，没有任何共享治理。

Microsoft Foundry刚刚以公开预览版发布了Toolboxes，这是对该问题的直接回应。

什么是Toolbox

Toolbox是一个有命名的、可复用的工具包，在Foundry中定义一次，通过单一MCP兼容端点公开。任何能够使用MCP的Agent运行时都可以消费它——不受限于Foundry Agents。

承诺很简单：build once, consume anywhere。定义工具，集中配置身份验证（OAuth直通、Entra托管标识），发布端点。需要这些工具的每个Agent连接到端点即可获取全部工具。

四个支柱（今天两个可用）

支柱	状态	功能
Discover	即将推出	无需手动搜索即可发现已批准的工具
Build	现已可用	将工具整合到可复用包中
Consume	现已可用	单一MCP端点公开所有工具
Govern	即将推出	集中身份验证+所有工具调用的可观测性

实践示例

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="搜索文档并回应GitHub issues",
 tools=[
 {"type": "web_search", "description": "搜索公开文档"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

发布后，Foundry提供统一端点。一次连接，获取所有工具。

不受限于Foundry Agents

Toolboxes在Foundry中创建和管理，但消费面是开放的MCP协议。可以从使用Microsoft Agent Framework或LangGraph的自定义Agent、GitHub Copilot和其他MCP兼容IDE以及任何支持MCP的运行时中使用它们。

为什么现在重要

多Agent浪潮正在进入生产环境。每个新Agent都是重复配置、过期凭据和不一致行为的新风险面。Build + Consume基础足以开始集中化。当Govern支柱推出时，你将拥有对整个Agent群完全可观测、集中控制的工具层。

总结

还是早期阶段——公开预览，Python SDK优先，Discover和Govern仍在路上。但模型是稳固的，MCP原生设计意味着它可以与你已经在构建的工具配合使用。查阅官方公告了解详情。

Windows App Dev CLI v0.3：从终端实现F5调试和面向智能体的UI自动化

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

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

Visual Studio的F5体验非常棒。但是，仅仅为了启动和调试一个打包的Windows应用而打开VS，在CI流水线、自动化工作流或AI智能体执行测试时就显得过于繁重了。

Windows App Development CLI v0.3正式发布，通过两个核心功能直接解决了这个问题：winapp run和winapp ui。

winapp run：随处可用的F5

winapp run接受一个未打包的应用文件夹和清单，执行VS在调试启动时所做的一切：注册松散包、启动应用，并在重新部署之间保留LocalState。

# 构建应用，然后作为打包应用运行
winapp run ./bin/Debug

支持WinUI、WPF、WinForms、Console、Avalonia等。各模式同时面向开发者和自动化工作流：

--detach：启动后立即将控制权返回给终端。非常适合CI/自动化。
--unregister-on-exit：应用关闭时清理已注册的包。
--debug-output：实时捕获OutputDebugString消息和异常。

新NuGet包：打包应用的dotnet run支持

面向.NET开发者，新增了一个NuGet包：Microsoft.Windows.SDK.BuildTools.WinApp。安装后，dotnet run处理整个内循环：构建、准备松散布局包、在Windows中注册和启动——一步完成。

winapp init
# 或
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui：从命令行实现UI自动化

这是开启智能体场景的功能。winapp ui从终端提供对任何正在运行的Windows应用（WPF、WinForms、Win32、Electron、WinUI3）的完整UI自动化访问。

可以实现：

列出所有顶层窗口
遍历窗口的完整UI自动化树
按名称、类型或自动化ID搜索元素
单击、调用和设置值
截图
等待元素出现——非常适合测试同步

将winapp ui与winapp run结合使用，即可从终端实现完整的构建→启动→验证工作流。智能体可以运行应用、检查UI状态、以编程方式交互并验证结果。

其他新功能

winapp unregister：测试完成后删除旁加载的包。
winapp manifest add-alias：添加别名，从终端按名称启动应用。
Tab补全：一条命令配置PowerShell补全。

安装方式

winget install Microsoft.WinAppCli
# 或
npm install -g @microsoft/winappcli

CLI处于公开预览阶段。完整文档请查看GitHub仓库，所有详细信息请查看原始公告。

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 的代码智能与安全执行环境的结合，正是生产团队一直在等待的。

别再盯着终端了：Aspire 的分离模式改变了工作流程

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

每次运行 Aspire AppHost，你的终端就没了。被锁住了。一直占用到你按 Ctrl+C 为止。需要快速运行个命令？打开另一个标签页。想查看日志？再开一个标签页。这是一种小摩擦，但积少成多。

Aspire 13.2 解决了这个问题。James Newton-King 写了完整的详情，说实话，这是那种一用就立刻改变工作方式的功能。

分离模式：一条命令，终端回来了

aspire start

这是 aspire run --detach 的简写。你的 AppHost 在后台启动，终端立即回到你手中。不需要额外的标签页。不需要终端多路复用器。就是你的提示符，随时可用。

管理正在运行的进程

关键在于——在后台运行只有在你能管理那些进程时才有用。Aspire 13.2 为此提供了一整套 CLI 命令：

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

这让 Aspire CLI 变成了一个真正的进程管理器。你可以启动多个 AppHost，检查它们的状态，跟踪日志，然后关闭它们——全部在一个终端会话中完成。

与隔离模式结合使用

分离模式与隔离模式天然搭配。想在后台运行同一个项目的两个实例而不产生端口冲突？

aspire start --isolated
aspire start --isolated

每个实例都会获得随机端口、独立的密钥和自己的生命周期。用 aspire ps 查看两者，用 aspire stop 停掉不需要的那个。

为什么这对编码代理意义重大

这才是真正有趣的地方。在你的终端中工作的编码代理现在可以：

用 aspire start 启动应用
用 aspire describe 查询状态
用 aspire logs 检查日志来诊断问题
完成后用 aspire stop 停止应用

所有操作都不会失去终端会话。在分离模式之前，运行你的 AppHost 的代理会把自己锁在终端里。现在它可以启动、观察、迭代和清理——这正是你期望自主代理的工作方式。

Aspire 团队在这方面下了功夫。运行 aspire agent init 会设置一个 Aspire 技能文件，教会代理这些命令。这样，像 Copilot 的编码代理这样的工具就能直接管理你的 Aspire 工作负载。

总结

分离模式是一个伪装成简单标志的工作流升级。你不再需要在终端之间切换上下文，代理不再阻塞自己，新的 CLI 命令让你真正看到正在运行的内容。它实用、干净，让日常开发循环明显更顺畅。

阅读完整文章了解所有详情，并通过 aspire update --self 获取 Aspire 13.2。

Azure MCP 工具现已内置于 Visual Studio 2022 — 无需安装扩展

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

如果你一直通过单独的扩展在 Visual Studio 中使用 Azure MCP 工具，那你一定很熟悉这套流程——安装 VSIX、重启、祈祷别出问题、处理版本不匹配。这种摩擦现在消失了。

Yun Jung Choi 宣布，Azure MCP 工具现在直接作为 Visual Studio 2022 中 Azure 开发工作负载的一部分发布。无需扩展，无需 VSIX，无需重启。

这实际意味着什么

从 Visual Studio 2022 版本 17.14.30 开始，Azure MCP Server 捆绑在 Azure 开发工作负载中。如果你已经安装了该工作负载，只需在 GitHub Copilot Chat 中启用它即可。

超过 230 个工具，覆盖 45 项 Azure 服务——直接从聊天窗口即可访问。列出你的存储账户、部署 ASP.NET Core 应用、诊断 App Service 问题、查询 Log Analytics——全程无需打开浏览器标签页。

为什么这比听起来更重要

开发工具有个道理：每多一个步骤就是摩擦，摩擦会扼杀采用率。MCP 作为单独的扩展意味着版本不匹配、安装失败，以及又多了一个需要保持更新的东西。将它内置到工作负载中意味着：

单一的更新路径——通过 Visual Studio Installer
无版本偏差——扩展和 IDE 之间不会出现版本不一致
始终保持最新——MCP Server 随 VS 常规发布一起更新

对于标准化使用 Azure 的团队来说，这意义重大。安装一次工作负载，启用工具，每次会话都能使用。

你能用它做什么

这些工具通过 Copilot Chat 覆盖完整的开发生命周期：

学习——询问 Azure 服务、最佳实践、架构模式
设计与开发——获取服务推荐，配置应用代码
部署——预配资源并直接从 IDE 进行部署
排查问题——查询日志、检查资源健康状况、诊断生产环境问题

一个简单的例子——在 Copilot Chat 中输入：

List my storage accounts in my current subscription.

Copilot 在后台调用 Azure MCP 工具，查询你的订阅，返回一个包含名称、位置和 SKU 的格式化列表。无需打开门户。

如何启用

更新到 Visual Studio 2022 17.14.30 或更高版本
确保已安装 Azure development 工作负载
打开 GitHub Copilot Chat
点击 Select tools 按钮（双扳手图标）
开启 Azure MCP Server

就这样。跨会话保持启用状态。

一个注意事项

这些工具默认是禁用的——你需要手动启用。而且 VS 2026 特有的工具在 VS 2022 中不可用。工具的可用性还取决于你的 Azure 订阅权限，与门户中一样。

更大的图景

这是一个清晰趋势的一部分：MCP 正在成为在开发者 IDE 中呈现云工具的标准方式。我们已经看到了 Azure MCP Server 2.0 稳定版发布以及在 VS Code 和其他编辑器中的 MCP 集成。将其内置到 Visual Studio 的工作负载系统中是自然而然的演进。

对于我们这些常年在 Visual Studio 中工作的 .NET 开发者来说，这又少了一个需要切换到 Azure 门户的理由。说实话，标签页切换越少越好。

azd update — 一个命令搞定所有包管理器

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

你知道那个每隔几周就会弹出来的"azd 有新版本可用"提示吗？就是那个你总是忽略掉的，因为你根本想不起来当初是用 winget、Homebrew 还是半年前跑的那个 curl 脚本安装的 azd。好了，这个问题终于解决了。

Microsoft 刚刚发布了 azd update — 一个命令就能将 Azure Developer CLI 更新到最新版本，不管你最初是怎么安装的。Windows、macOS、Linux — 都一样。就一个命令。

工作原理

azd update

就这么简单。如果你想提前体验新功能，可以切换到每日 Insiders 构建：

azd update --channel daily
azd update --channel stable

这个命令会自动检测你当前的安装方式，并在后台使用对应的更新机制。再也不用纠结"等等，这台机器上我用的是 winget 还是 choco 来着？"

一个小前提

azd update 从版本 1.23.x 开始提供。如果你用的是更早的版本，需要用原来的安装方式做最后一次手动更新。之后，azd update 就能接管一切了。

用 azd version 查看你当前的版本。如果需要全新安装，安装文档可以帮到你。

为什么这很重要

这是一个小小的生活质量改善，但对于我们这些每天都在用 azd 把 AI Agent 和 Aspire 应用部署到 Azure 的人来说，保持最新意味着更少的"这个 bug 在最新版本里已经修复了"的尴尬时刻。少操心一件事。

阅读完整公告和 Jon Gallant 的深入分析了解更多。

.NET Aspire 13.2想成为你AI智能体的好朋友

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

你知道那种感觉吗？你的AI编码智能体写出了不错的代码，你很兴奋，然后当它试图运行这个东西时一切都崩溃了？端口冲突、幽灵进程、错误的环境变量 — 突然你的智能体在排查启动问题上烧掉了大量token，而不是构建功能。

Aspire团队刚刚发布了一篇关于这个问题的深思熟虑的文章，他们的答案很有说服力：Aspire 13.2的设计不仅面向人类，更面向AI智能体。

问题是真实存在的

AI智能体在写代码方面令人难以置信。但交付一个可工作的全栈应用涉及的远不止生成文件。你需要按正确的顺序启动服务、管理端口、设置环境变量、连接数据库，以及在出问题时获得反馈。目前，大多数智能体通过试错来处理所有这些 — 运行命令、读取错误输出、再试一次。

我们叠加Markdown指令、自定义技能和提示来引导它们，但这些是不可预测的，无法编译，而且仅仅解析就要消耗token。Aspire团队抓住了核心洞察：智能体需要编译器和结构化API，而不是更多的Markdown。

Aspire作为智能体基础设施

以下是Aspire 13.2为智能体开发带来的内容：

整个技术栈用类型化代码描述。 AppHost用可编译的TypeScript或C#定义你的完整拓扑 — API、前端、数据库、缓存：

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

智能体可以读取这些来理解应用拓扑、添加资源、连接组件，并通过构建来验证。编译器会立即告诉它哪里出了问题。不需要猜测，不需要在配置文件上反复试错。

一个命令统治所有。 智能体不再需要在docker compose up、npm run dev和数据库启动脚本之间来回切换，一切只需aspire start。所有资源按正确顺序、在正确的端口、用正确的配置启动。长时间运行的进程也不会挂起智能体 — Aspire负责管理它们。

并行智能体的隔离模式。 使用--isolated，每次Aspire运行都会获得自己的随机端口和独立的用户密钥。多个智能体在git worktree中工作？它们不会冲突。这对于VS Code的后台智能体等创建并行环境的工具来说意义重大。

通过遥测赋予智能体视野。 这是真正强大的地方。Aspire CLI在开发期间暴露完整的OpenTelemetry数据 — 追踪、指标、结构化日志。你的智能体不是只读控制台输出然后祈祷一切顺利。它可以跨服务追踪失败的请求、分析慢端点，并精确定位问题所在。这是开发循环中的生产级可观察性。

保龄球护栏类比

Aspire团队用了一个很棒的类比：把Aspire想象成AI智能体的保龄球道护栏。如果智能体不够完美（它确实不会完美），护栏会防止它打出沟球。技术栈定义防止配置错误，编译器捕获错误，CLI处理进程管理，遥测提供反馈循环。

将此与Playwright CLI之类的工具结合，你的智能体就可以真正使用你的应用 — 点击流程、检查DOM、在遥测中发现问题、修复代码、重启并重新测试。构建、运行、观察、修复。这就是我们一直追求的自主开发循环。

入门

Aspire新手？从get.aspire.dev安装CLI并遵循入门指南。

已经在使用Aspire？运行aspire update --self获取13.2，然后将你最喜欢的编码智能体指向你的仓库。有了Aspire的护栏，你可能会惊讶于它能走多远。

总结

Aspire 13.2不再仅仅是一个分布式应用框架 — 它正在成为必不可少的智能体基础设施。结构化的技术栈定义、一键启动、隔离的并行运行和实时遥测，为AI智能体提供了从编写代码到交付应用所需的一切。

阅读Aspire团队的完整文章获取所有细节和演示视频。

Aspire的隔离模式解决了并行开发中端口冲突的噩梦

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

如果你曾试过同时运行同一个项目的两个实例，你就知道那种痛苦。端口8080已被占用。端口17370已被使用。杀掉进程、重启、摆弄环境变量 — 这是生产力杀手。

这个问题在变得更严重，而不是更好。AI智能体创建git worktree来独立工作。后台智能体启动独立环境。开发者为了功能分支两次checkout同一个仓库。每一个场景都撞上了同一堵墙：同一个应用的两个实例在争夺相同的端口。

Aspire 13.2用一个flag就解决了这个问题。Aspire团队的James Newton-King写了完整的细节，这是那种"我们怎么之前没有这个"的功能。

解决方案：`--isolated`

aspire run --isolated

就这样。每次运行获得：

随机端口 — 实例间不再冲突
隔离的用户密钥 — 连接字符串和API密钥在每个实例间保持独立

不需要手动重新分配端口。不需要摆弄环境变量。每次运行自动获得一个干净的、无冲突的环境。

这个功能发光的真实场景

多次checkout。 你有一个功能分支在一个目录，一个bugfix在另一个：

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

两个都无冲突运行。仪表盘显示什么在运行以及在哪里运行。

VS Code中的后台智能体。 当Copilot Chat的后台智能体创建git worktree来独立处理你的代码时，它可能需要运行你的Aspire AppHost。没有--isolated，这就会和你的主worktree产生端口冲突。有了它，两个实例就能正常运行。

aspire agent init附带的Aspire技能会自动指导智能体在worktree中工作时使用--isolated。所以Copilot的后台智能体应该能原生处理这个问题。

开发同时运行集成测试。 需要在继续开发功能的同时对活跃的AppHost运行测试？隔离模式给每个上下文提供独立的端口和配置。

底层工作原理

当你传递--isolated时，CLI会为该运行生成一个唯一的实例ID。这驱动两个行为：

端口随机化 — 不再绑定到AppHost配置中定义的可预测端口，隔离模式为所有内容选择随机可用端口 — 仪表盘、服务端点，全部。服务发现自动调整，所以服务能找到彼此，不管它们落在哪个端口上。
密钥隔离 — 每个隔离运行获得自己的用户密钥存储，以实例ID为键。一次运行的连接字符串和API密钥不会泄露到另一次运行中。

你的代码不需要任何改动。Aspire的服务发现在运行时解析端点，所以不管端口分配如何，一切都能正确连接。

何时使用

当同时运行同一AppHost的多个实例时使用--isolated — 无论是并行开发、自动化测试、AI智能体还是git worktree。对于偏好可预测端口的单实例开发，常规的aspire run仍然可以正常使用。

总结

隔离模式是一个解决真实且越来越常见问题的小功能。随着AI辅助开发推动我们走向更多并行工作流 — 多个智能体、多个worktree、多个上下文 — 能够简单地启动另一个实例而不必争夺端口是必不可少的。

阅读完整文章获取所有技术细节，并用aspire update --self获取13.2来试用。

VS Code 1.116 — Agents应用获得键盘导航和文件上下文补全

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

VS Code 1.116是2026年4月的版本，虽然比最近的一些更新更轻量，但变化是有针对性且有意义的 — 尤其是如果你每天都在使用Agents应用。

以下是基于官方发行说明的更新内容。

Agents应用改进

Agents应用继续通过可用性优化不断成熟，这些改进在日常工作流中产生了真正的影响：

专属快捷键 — 现在你可以用专属命令和键盘快捷键来聚焦更改视图、更改中的文件树，以及聊天自定义视图。如果你之前一直在Agents应用中到处点击来导航，这带来了完全由键盘驱动的工作流。

辅助功能帮助对话框 — 在聊天输入框中按Alt+F1现在会打开一个辅助功能帮助对话框，显示可用的命令和快捷键。屏幕阅读器用户还可以控制播报的详细程度。良好的辅助功能让每个人受益。

文件上下文补全 — 在Agents应用聊天中输入#来触发限定在当前工作区范围内的文件上下文补全。这是那些加速每次交互的小型生活质量改进之一 — 不再需要在引用代码时输入完整的文件路径。

CSS `@import`链接解析

前端开发者的好消息：VS Code现在可以解析使用node_modules路径的CSS @import引用。当使用打包工具时，你可以通过Ctrl+点击跳转到像@import "some-module/style.css"这样的导入。虽小但消除了CSS工作流中的一个摩擦点。

总结

VS Code 1.116是关于改进的 — 让Agents应用更易导航、更易访问、更友好的键盘操作。如果你在Agents应用中花费大量时间（我猜很多人都是如此），这些变化会累积起来。

查看完整发行说明获取完整列表。

那个你不知道的Visual Studio浮动窗口设置（但你应该知道）

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

如果你在Visual Studio中使用多个显示器（说实话，现在谁不用呢？），你可能经历过这种烦恼：浮动工具窗口在你最小化主IDE时消失，它们总是在所有窗口之上，而且不会在任务栏中显示为单独的按钮。这对某些工作流有效，但对多显示器设置来说很令人沮丧。

Visual Studio团队的Mads Kristensen 分享了一个鲜为人知的设置，它完全改变了浮动窗口的行为。一个下拉菜单。就这样。

设置

Tools > Options > Environment > Windows > Floating Windows

下拉菜单"These floating windows are owned by the main window"有三个选项：

None — 完全独立。每个浮动窗口都有自己的任务栏条目，行为就像普通的Windows窗口。
Tool Windows（默认）— 文档自由浮动，工具窗口保持与IDE绑定。
Documents and Tool Windows — 经典的Visual Studio行为，所有窗口都绑定到主窗口。

为什么"None"是多显示器设置的最佳选择

将其设置为None，突然间你所有的浮动工具窗口和文档都像真正的Windows应用程序一样运行。它们出现在任务栏中，当你最小化Visual Studio主窗口时保持可见，并且不再强制自己始终在最前面。

将此与PowerToys FancyZones结合使用，效果惊人。在你的显示器上创建自定义布局，将解决方案资源管理器放在一个区域，调试器放在另一个区域，代码文件放在你想要的任何地方。一切都保持在原位，一切都可以独立访问，你的工作空间感觉有条理而不是混乱的。

快速建议

多显示器高级用户：设置为None，搭配FancyZones
偶尔浮动的用户：Tool Windows（默认）是不错的折中方案
传统工作流：Documents and Tool Windows保持经典行为

专业提示：在任何工具窗口的标题栏上Ctrl + 双击即可立即浮动或停靠。更改设置后无需重启。

总结

这是那种"我不敢相信我之前不知道"的设置之一。如果Visual Studio中的浮动窗口曾经让你烦恼，现在就去改掉它。

阅读完整文章获取详细信息和截图。

VS Code 1.115 — 后台终端通知、SSH Agent 模式及更多

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

VS Code 1.115 刚刚发布了，虽然从主要功能来看这是一个较轻量的版本，但如果你每天都在使用 AI 编程助手，那么与 Agent 相关的改进确实非常实用。

让我来重点介绍一下真正值得了解的内容。

后台终端与 Agent 通信

这是本次最突出的功能。后台终端现在会在命令完成时自动通知 Agent，包括退出代码和终端输出。后台终端中的输入提示也会被检测并展示给用户。

这为什么重要？如果你用过 Copilot 的 Agent 模式在后台运行构建命令或测试套件，你肯定知道"那个跑完了没？“的痛苦——后台终端基本上就是发射后不管。现在 Agent 会在你的 dotnet build 或 dotnet test 完成时收到通知，看到输出，并相应地做出反应。这是一个小改动，但让 Agent 驱动的工作流程变得更加可靠。

还有一个新的 send_to_terminal 工具，允许 Agent 在用户确认后向后台终端发送命令，解决了 run_in_terminal 带超时参数时会将终端移到后台并使其变为只读的问题。

SSH 远程 Agent 托管

VS Code 现在支持通过 SSH 连接到远程机器，自动安装 CLI 并以 Agent 主机模式启动。这意味着你的 AI Agent 会话可以直接针对远程环境——对于在 Linux 服务器或云虚拟机上构建和测试的 .NET 开发者来说非常有用。

Agent 会话中的编辑追踪

Agent 会话期间进行的文件编辑现在会被追踪和恢复，支持差异对比、撤销/重做和状态恢复。如果 Agent 修改了你的代码并且出了问题，你可以准确地看到哪些内容发生了变化并将其回滚。让 Agent 修改代码库时更加安心。

浏览器标签页感知及其他改进

还有一些生活质量方面的提升：

浏览器标签页追踪 — 聊天现在可以追踪和链接会话期间打开的浏览器标签页，这样 Agent 可以引用你正在查看的网页
终端文件粘贴 — 使用 Ctrl+V、拖放或右键点击将文件（包括图片）粘贴到终端
小地图中的测试覆盖率 — 测试覆盖率指示器现在显示在小地图中，提供快速的视觉概览
Mac 上的双指缩放 — 集成浏览器支持双指缩放手势
会话中的 Copilot 使用权限 — 状态栏在会话视图中显示使用信息
转到文件中的网站图标 — 打开的网页在快速选择列表中显示网站图标

总结

VS Code 1.115 是一个渐进式版本，但 Agent 改进——后台终端通知、SSH Agent 托管和编辑追踪——加在一起为 AI 辅助开发带来了明显更流畅的体验。如果你在 .NET 项目中使用 Copilot 的 Agent 模式，这些正是每天减少摩擦的生活质量改进。

查看完整的发行说明了解所有细节。

Aspire 13.2 自带文档 CLI — 你的 AI 代理也能用

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

你知道那种时刻吗——你正深入一个 Aspire AppHost，接入各种集成，然后需要确认 Redis 集成到底需要哪些参数？你 Alt-Tab 切到浏览器，在 aspire.dev 上翻来翻去，眯着眼看 API 文档，然后切回编辑器。上下文没了，心流断了。

Aspire 13.2 刚刚发布了解决方案。aspire docs CLI 让你直接从终端搜索、浏览和阅读 Aspire 官方文档。而且因为它由可复用的服务支撑，AI 代理和技能可以使用同样的命令来查找文档，而不是幻想出不存在的 API。

这到底解决了什么问题

David Pine 在原文中说得很到位：AI 代理在帮助开发者构建 Aspire 应用方面糟糕透了。它们推荐 dotnet run 而不是 aspire run，引用 learn.microsoft.com 来查找实际在 aspire.dev 上的文档，建议过时的 NuGet 包，还有——我个人最喜欢的——幻想出根本不存在的 API。

为什么？因为 Aspire 作为 .NET 专属工具的时间远比它成为多语言工具的时间长，而且 LLM 使用的训练数据早于最新功能。当你给 AI 代理真正查找当前文档的能力时，它就不再猜测，开始变得有用了。

三个命令，零个浏览器标签页

CLI 简洁得令人耳目一新：

列出所有文档

aspire docs list

返回 aspire.dev 上所有可用的文档页面。需要机器可读的输出？加上 --format Json。

搜索主题

aspire docs search "redis"

同时搜索标题和内容，使用加权相关性评分。与内部驱动文档工具的搜索引擎完全一样。你会得到带有标题、slug 和相关性分数的排名结果。

阅读完整页面（或仅一个章节）

aspire docs get redis-integration

将完整页面以 markdown 格式流式传输到你的终端。只需要一个章节？

aspire docs get redis-integration --section "Add Redis resource"

精准定位。不用滚动 500 行。只看你需要的部分。

AI 代理的视角

对于我们这些使用 AI 工具进行开发的人来说，这才是真正有趣的地方。同样的 aspire docs 命令可以作为 AI 代理的工具——通过技能、MCP 服务器或简单的 CLI 封装。

你的 AI 助手不再根据过时的训练数据编造 Aspire API，而是可以调用 aspire docs search "postgres"，找到官方集成文档，阅读正确的页面，给你文档记录的方案。实时的、最新的文档——而不是模型六个月前记住的内容。

背后的架构是有意为之的。Aspire 团队构建了可复用的服务（IDocsIndexService、IDocsSearchService、IDocsFetcher、IDocsCache），而不是一次性集成。这意味着同一个搜索引擎为终端中的人类、编辑器中的 AI 代理以及 CI 流水线中的自动化服务。

真实场景

终端快速查询： 你已经深入到第三个文件，需要 Redis 配置参数。两个命令，九十秒，回去干活：

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI 辅助开发： 你的 VS Code 技能封装了 CLI 命令。你问"给我的 AppHost 添加一个 PostgreSQL 数据库"，代理在回答之前先查阅真实文档。没有幻觉。

CI/CD 验证： 你的流水线以编程方式根据官方文档验证 AppHost 配置。--format Json 输出可以干净地通过管道传递给 jq 和其他工具。

自定义知识库： 在构建自己的 AI 工具？将结构化 JSON 输出直接导入你的知识库：

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

不需要网页抓取。不需要 API 密钥。与文档工具内部使用的完全一样的结构化数据。

文档始终是最新的

这是我最欣赏的部分。CLI 不会下载快照——它通过基于 ETag 的缓存查询 aspire.dev。文档一旦更新，你的 CLI 和构建在其之上的所有技能都会反映出来。没有过时的副本，没有"但是 wiki 上说的是…“的尴尬时刻。

总结

aspire docs 是那种以简洁方式解决真实问题的小功能之一。人类获得了终端原生的文档访问。AI 代理获得了停止猜测、开始引用真实文档的方式。而且一切都由同一个事实来源支撑。

如果你正在使用 .NET Aspire 开发，还没试过这个 CLI，运行 aspire docs search "你的主题" 看看感觉如何。然后考虑将这些命令封装到你正在使用的任何 AI 技能或自动化设置中——你的代理会感谢你的。

查看 David Pine 的深入分析了解文档工具是如何构建的，以及官方 CLI 参考获取所有细节。

azd现在可以在本地运行和调试AI代理了 — 2026年3月都有哪些变化

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

一个月七个版本。这是Azure Developer CLI (azd) 团队在2026年3月发布的成果，而头条功能正是我一直在等的：AI代理的本地运行和调试循环。

PC Chan 发布了完整摘要，虽然内容很多，但让我筛选出对构建AI驱动应用的.NET开发者真正重要的部分。

不用部署就能运行和调试AI代理

这是最大的亮点。新的 azure.ai.agents 扩展添加了一组命令，为AI代理提供了完整的内循环体验：

azd ai agent run — 在本地启动你的代理
azd ai agent invoke — 向其发送消息（本地或已部署的）
azd ai agent show — 显示容器状态和健康状况
azd ai agent monitor — 实时流式传输容器日志

以前，测试AI代理意味着每次修改都要部署到Microsoft Foundry。现在你可以在本地迭代，测试代理行为，准备好了再部署。

GitHub Copilot为你配置azd项目

azd init 现在提供了"Set up with GitHub Copilot (Preview)“选项。无需手动回答关于项目结构的提示，Copilot代理为你生成配置。当命令失败时，azd 提供AI辅助的问题排查——全程不需要离开终端。

Container App Jobs和部署改进

Container App Jobs：azd现在通过现有的host: containerapp配置部署Microsoft.App/jobs。
可配置的部署超时：azd deploy的新--timeout标志和azure.yaml中的deployTimeout字段。
远程构建回退：当ACR构建失败时，azd自动回退到本地Docker/Podman构建。
本地预检验证：部署前在本地验证Bicep参数。

开发体验改进

自动检测pnpm/yarn — JS/TS项目
pyproject.toml支持 — Python打包
本地模板目录 — azd init --template接受文件系统路径
更好的错误消息 — --no-prompt模式
构建环境变量 — 注入到所有框架构建子进程（.NET、Node.js、Java、Python）

总结

本地AI代理调试循环是这个版本的明星，但部署改进和DX优化的积累使azd比以往更加成熟。如果你在Azure上部署.NET应用——特别是AI代理——这次更新值得关注。

查看完整发行说明了解所有细节。

Azure DevOps终于修好了所有人都在抱怨的Markdown编辑器

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

如果你使用Azure Boards，你可能经历过这种情况：你在阅读一个工作项描述，也许在检查验收标准，然后不小心双击了。砰——你进入了编辑模式。你根本不想编辑任何东西。你只是在阅读。

Dan Hellem 宣布了这个修复，这是那种听起来很小但确实从日常工作流中消除了真正摩擦的改动。

什么变了

工作项文本字段的Markdown编辑器现在默认以预览模式打开。你可以阅读和交互内容——跟随链接、检查格式——不用担心意外进入编辑模式。

当你真的想要编辑时，点击字段顶部的编辑图标。完成后，显式退出到预览模式。简单、有意图、可预测。

为什么这比听起来更重要

社区反馈帖子很长。双击编辑的行为是在2025年7月随Markdown编辑器引入的，投诉几乎立刻开始了。

对于使用Azure Boards进行冲刺计划、需求梳理或代码审查的团队来说，这种微摩擦会累积。

部署状态

已经在向部分客户推出，将在未来两到三周内扩展到所有人。

总结

不是每个改进都需要成为头条功能。有时候最好的更新就是简单地移除恼人的东西。这就是其中之一——一个小小的UX修复，让Azure Boards对只想安静阅读工作项的人变得不再那么敌意。

Bookmark Studio为Visual Studio书签带来基于槽位的导航和分享功能

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

Visual Studio中的书签一直…还行。你设置一个，导航到下一个，然后忘记哪个是哪个。它们能用，但从来不是你会称之为强大的功能。

Mads Kristensen刚刚发布了Bookmark Studio，一个实验性扩展，精确填补了你可能遇到的空缺。

基于槽位的导航

书签可以分配到1-9号槽位，通过Alt+Shift+1到Alt+Shift+9直接跳转。新书签自动获得下一个可用槽位。

书签管理器

新的工具窗口在一个地方显示所有书签，支持按名称、文件、位置、颜色或槽位过滤。

用标签、颜色和文件夹组织

书签可以有标签、颜色，并分组到文件夹中。元数据按解决方案存储。

导出和分享

Bookmark Studio允许将书签导出为纯文本、Markdown或CSV。

跟随代码移动的书签

Bookmark Studio相对于锚定的文本跟踪书签，所以编辑时不会漂移到错误的行。

总结

Bookmark Studio没有重新发明任何东西。它把一个多年来"够用"的功能变得真正有用。从Visual Studio Marketplace下载吧。

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来体验所有新功能。

从笔记本到生产：用两个命令将 AI 代理部署到 Microsoft Foundry

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

你知道"在我的机器上能跑"和"已部署并正在处理流量"之间的鸿沟吗？对于 AI 代理来说，这个鸿沟一直痛苦地大。你需要配置资源、部署模型、配置身份、设置监控 — 这些都是在任何人能实际调用你的代理之前要做的。

Azure Developer CLI 刚刚把这变成了两个命令的事。

新的 `azd ai agent` 工作流

让我带你看看这实际是什么样子。你有一个 AI 代理项目 — 比如说一个酒店礼宾代理。它在本地运行正常。你想让它在 Microsoft Foundry 上运行。

azd ai agent init
azd up

就这样。两个命令。azd ai agent init 在你的仓库中生成基础设施即代码，azd up 在 Azure 上配置一切并发布你的代理。你会得到一个直接指向 Foundry 门户中你的代理的链接。

底层发生了什么

init 命令在你的仓库中生成真实的、可检查的 Bicep 模板：

一个 Foundry Resource（顶层容器）
一个 Foundry Project（你的代理所在的地方）
模型部署配置（GPT-4o 等）
带有适当 RBAC 角色分配的托管身份
服务映射用的 azure.yaml
带有代理元数据和环境变量的 agent.yaml

关键是：这一切都是你的。它是仓库中的版本化 Bicep。你可以检查它、自定义它，并与你的代理代码一起提交。没有魔法黑盒。

开发内循环

我真正喜欢的是本地开发体验。当你在迭代代理逻辑时，不想每次改变提示词都重新部署：

azd ai agent run

这会在本地启动你的代理。配合 azd ai agent invoke 发送测试提示，你就有了一个紧密的反馈循环。编辑代码、重启、调用、重复。

invoke 命令的路由也很智能 — 当本地代理在运行时，它会自动指向本地。不在运行时，指向远程端点。

实时监控

这是说服我的功能。一旦你的代理部署完成：

azd ai agent monitor --follow

流经你的代理的每个请求和响应都会实时传输到你的终端。对于调试生产问题，这是无价之宝。不用挖 Log Analytics，不用等指标聚合 — 你看到的就是现在正在发生的事情。

完整的命令集

快速参考：

命令	功能
`azd ai agent init`	用 IaC 搭建 Foundry 代理项目
`azd up`	配置 Azure 资源并部署代理
`azd ai agent invoke`	向远程或本地代理发送提示
`azd ai agent run`	在本地运行代理用于开发
`azd ai agent monitor`	从已发布的代理流式传输实时日志
`azd ai agent show`	检查代理健康状态和状态
`azd down`	清理所有 Azure 资源

为什么这对 .NET 开发者重要

虽然公告中的示例是基于 Python 的，但基础设施的故事是语言无关的。你的 .NET 代理得到相同的 Bicep 脚手架、相同的托管身份设置、相同的监控管道。如果你已经在用 azd 部署 .NET Aspire 应用或 Azure 部署，这直接融入你现有的工作流。

AI 代理的部署鸿沟一直是生态系统中最大的摩擦点之一。从一个工作原型到一个具有适当身份、网络和监控的生产端点，不应该需要一周的 DevOps 工作。现在只需要两个命令和几分钟。

总结

azd ai agent 现在可用。如果你一直因为基础设施设置看起来工作量太大而推迟部署 AI 代理，试试看。查看完整教程获取包括前端聊天应用集成在内的完整步骤。