Aspire | The .NET Blog

私有端点、VNet、NSG — Aspire 现在接管网络管理

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

我见过这个场景太多次了。应用程序已经完成。演示很棒。然后安全清单出现了：将存储从公共互联网移除、在 VNet 内运行、为合作伙伴允许列表提供出站 IP、证明只有正确的子网与正确的服务通信。

此时应用程序模型和基础设施模型开始以令人痛苦的方式分离。

Aspire 新的 Azure 企业网络支持直接解决了这个问题。你在 AppHost 中将网络形态描述在使用它的资源旁边。

构建块

每个 Azure 网络概念的用途，提炼如下：

功能	使用时机	为何重要
虚拟网络	需要私有地址空间时	子网、私有端点和路由的网络边界
子网	需要在 VNet 内分离工作负载时	系统的每个部分获得自己的地址范围和策略面
委托子网	平台服务（如 ACA）需要管理子网时	允许服务安全地在 VNet 中放置受管基础设施
NAT 网关	需要可预测的出站公共 IP 时	用于允许列表和审计的稳定地址
私有端点	希望 PaaS 资源可私密访问时	在 VNet 内放置该服务的私有 IP，消除公共暴露
NSG	需要子网级流量规则时	每个子网的入站和出站流量显式允许/拒绝

在 AppHost 中描述它

这里的关键转变是你将网络与使用它的资源一起建模，而不是在随时间与应用模型产生偏离的单独 Bicep 文件中。

从 AppHost，你可以：

使用 AddVirtualNetwork() 和 AddSubnet() 创建 VNet 和子网
为子网附加 NAT 网关以获得稳定的出站 IP
为存储、Key Vault、SQL 和其他 PaaS 服务创建私有端点
使用入站和出站安全规则定义 NSG
配置网络安全边界以实现跨资源策略

结果是当你运行 azd up 时，基础设施与应用模型所说需要的内容相匹配。而不是手动维护的模板所说的。

为何对实际应用程序重要

一旦在 Aspire 中建模了网络，一些事情就会变得容易很多：

Key Vault 和存储的私有端点 — 你在这些资源上描述 WithPrivateEndpoint()，Aspire 处理 DNS 区域配置和端点附加。应用程序永远不会改变。

一致的出站 IP — 向相关子网添加 NAT 网关，应用程序的每个出站请求都通过一个已知的稳定 IP。合作伙伴可以将其加入允许列表。审计人员可以追踪它。

代码中的 NSG 规则 — 不再需要在门户中点击或维护 Bicep 代码段，你的安全规则与它们保护的资源一起存在于 AppHost 中。

这是不会让演示令人兴奋但会让生产系统可维护的集成类型。

总结

如果从一开始就与应用程序一起建模，网络安全在项目生命周期后期出现是一个已解决的问题。Aspire 的企业网络支持使这成为可能，而无需单独的基础设施轨道。

完整详情请参阅原始文章：Securing Azure apps with Aspire enterprise networking

Aspire 13.3：Kubernetes 支持、浏览器日志和 Aspireify 技能

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

五周对于一个版本来说并不长，但 Aspire 13.3 让人感觉不是这样。主要内容非常重要：使用 Helm 进行 Kubernetes 和 AKS 一流部署、名为 Aspireify 的代理辅助入门技能、直接在仪表板中捕获浏览器日志，以及结构化命令结果。还包括 45 项新功能、134 项改进和 93 个错误修复。

让我们来看看亮点。

Aspireify：代理辅助入门

将 Aspire 添加到现有项目听起来很简单——添加 AppHost，完成。实际上需要大量研究：哪些端口重要、哪些环境变量是真正的依赖项、哪些 Docker Compose 服务应该映射到 Aspire 集成。

新的 Aspireify 技能 正是为此为您的编码代理提供了引导工作流程。当 aspire init 创建骨架 AppHost 时，Aspireify 技能会帮助代理检查存储库、了解其已有的工作方式，并连接 AppHost 以适应应用程序——而不是反过来。

默认立场是"最小化对代码的更改"。如果您的应用程序已经读取 DATABASE_URL，代理会使用 WithEnvironment() 进行映射，而不是要求您重写配置。如果端口是硬编码的，该技能会告诉代理何时保留它。

这正是那种能真正节省时间而不是生成更多审查工作的 AI 工具。

一流的 Kubernetes 和 AKS 部署

这在愿望清单上已经有一段时间了。Aspire 13.3 提供了使用 Helm 的 Kubernetes 和 AKS 一流部署支持。您现在可以直接从 Aspire 工具中将 AKS 指定为部署目标。

对于已经在 AKS 上运行生产工作负载的团队，这弥补了一个重要缺口。您的 Aspire 应用模型现在有了从本地开发到 Kubernetes 的清晰路径，无需手动编写 Helm 图表。

仪表板中的浏览器日志

这是那些在调试前端问题之前看起来很小的功能之一。

新的 WithBrowserLogs() API 将跟踪的浏览器资源附加到任何支持端点的资源。Aspire 使用私有 CDP 管道启动 Chromium，并将控制台日志、网络请求和错误直接流式传输到资源的日志流中：

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost 同样支持：

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

控制台错误、失败的网络请求、客户端异常——所有这些都在您已经观察追踪和指标的同一仪表板中可见。不再需要为了基础内容切换到浏览器 DevTools。

结构化命令结果

资源命令获得了重大升级。到目前为止，命令返回成功/失败。现在它们返回结构化结果：流经模型、仪表板 UI、CLI 和 MCP 工具的文本、JSON 或 Markdown。

仪表板通过标题中的新通知中心将这一切联系在一起。命令结果以带时间戳的通知形式出现，带有 Markdown 渲染和"查看响应"操作。

这使资源命令真正可组合。集成现在可以公开一个返回有意义输出的命令——比如隧道 URL——而不仅仅是在某处更改状态。

结论

Aspire 13.3 仅凭 Kubernetes 支持就值得升级。浏览器日志和结构化命令结果感觉像是那种在日常开发工作流程中快速积累的生活质量改进。

完整发布说明：What’s New in Aspire 13.3

Aspire 13.2：Bun支持、更好的容器和更少的调试摩擦

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

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

如果你在Aspire中构建.NET后端和JavaScript前端，13.2是那种悄悄让你一天变得更好的更新。

Bun现在是一等公民

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

如果你的团队已经使用Bun，Aspire不再让你逆流而上。

Yarn更可靠了

Yarn用户在withYarn()和addViteApp()中会遇到更少的神秘失败。

容器改进

ImagePullPolicy.Never用于使用本地镜像而不访问注册表。PostgreSQL 18+数据卷现在可以正确工作。

调试改进

核心类型上的DebuggerDisplayAttribute，WaitFor的更好错误消息，BeforeResourceStartedEvent在正确时机触发。

David Pine的原始文章：Aspire 13.2: Bun Support and Container Enhancements。

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 于 2026年4月18日 在马德里 Alcobendas 的 Kinépolis Diversia 举办。这是西班牙最大的社区驱动 Azure 活动，38位演讲者在3个平行分场分享 AI 代理、Azure 网络、Cosmos DB、Fabric、IoT、安全等主题。

活动时间为 08:30 至 18:30，包括主题演讲、茶歇、午餐和闭幕问答环节。

议程亮点

Domando Agentes de IA：使用 Azure AI Foundry 和 Azure API Management 的治理、工具和 API
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!：多代理系统实战
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

门票

注册为象征性捐赠 — 门票全部收入直接捐赠给 Plan International，支持全球儿童权利和平等。名额有限，请尽早报名。

Azure Tour 2026

除马德里外，Global Azure Tour 2026 还将在 萨拉戈萨、特内里费 和 塞维利亚 举办。

别再盯着终端了：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。

.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来试用。

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 参考获取所有细节。

Aspire 13.2的Dashboard现在有了遥测API — 这改变了一切

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

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

如果你一直在用 .NET Aspire 构建分布式应用，你已经知道dashboard是整个体验中最棒的部分。所有的trace、日志和指标都在一个地方 — 不需要外部的Jaeger，不需要Seq配置，不需要"让我看看另一个终端"的时刻。

Aspire 13.2 刚刚做了重大改进。James Newton-King 发布了更新公告，说实话，单是遥测导出和API功能就值得升级。

像正常人一样导出遥测数据

这是我们都经历过的场景：你在调试一个分布式问题，花了二十分钟终于复现了，现在你需要和团队分享发生了什么。之前？截图。复制粘贴trace ID。一如既往的混乱。

Aspire 13.2 添加了一个管理日志和遥测对话框，你可以：

清除所有遥测（在复现bug之前很有用）
将选定的遥测数据导出为标准OTLP/JSON格式的ZIP文件
稍后将该ZIP重新导入任何Aspire dashboard

最后一点是杀手级功能。你复现一个bug，导出遥测数据，附加到工作项，你的队友可以导入到自己的dashboard中，看到你所看到的完全一样的内容。不再需要"你能在你的机器上复现吗？"

单个trace、span和日志也在上下文菜单中有了"Export JSON"选项。需要分享一个特定的trace？右键点击，复制JSON，粘贴到PR描述中。搞定。

遥测API才是真正的革命性变化

这是最让我兴奋的。Dashboard现在在/api/telemetry下暴露了HTTP API，用于编程式查询遥测数据。可用端点：

GET /api/telemetry/resources — 列出有遥测数据的资源
GET /api/telemetry/spans — 带过滤器查询span
GET /api/telemetry/logs — 带过滤器查询日志
GET /api/telemetry/traces — 列出trace
GET /api/telemetry/traces/{traceId} — 获取特定trace的所有span

一切都以OTLP JSON格式返回。这驱动了新的CLI命令aspire agent mcp和aspire otel，但真正的意义更大：你现在可以构建工具、脚本和AI代理集成，直接查询你应用的遥测数据。

想象一个AI编码代理在调试时能看到你实际的分布式trace。这不再是假设 — 这就是这个API所实现的。

GenAI遥测变得实用

如果你正在用Semantic Kernel或Microsoft.Extensions.AI构建AI驱动的应用，你会喜欢改进的GenAI遥测可视化器。Aspire 13.2 新增了：

AI工具描述以Markdown渲染
Trace页面上的专用GenAI按钮，方便快速访问
对截断或非标准GenAI JSON更好的错误处理
工具定义之间的点击高亮导航

文章提到VS Code Copilot chat、Copilot CLI和OpenCode都支持配置OTEL_EXPORTER_OTLP_ENDPOINT。将它们指向Aspire dashboard，你可以通过遥测数据实时观看你的AI代理思考过程。这是你在其他任何地方都找不到的调试体验。

总结

Aspire 13.2将dashboard从"不错的调试UI"转变为"可编程的可观测性平台"。单是导出/导入工作流就能在分布式调试中节省真实时间，而遥测API为AI辅助诊断打开了大门。

如果你已经在用Aspire，升级吧。如果还没有 — 这是一个了解aspire.dev的好理由。

Aspire | The .NET Blog

私有端点、VNet、NSG — Aspire 现在接管网络管理

构建块

在 AppHost 中描述它

为何对实际应用程序重要

总结

Aspire 13.3：Kubernetes 支持、浏览器日志和 Aspireify 技能

Aspireify：代理辅助入门

一流的 Kubernetes 和 AKS 部署

仪表板中的浏览器日志

结构化命令结果

结论

Aspire 13.2：Bun支持、更好的容器和更少的调试摩擦

Bun现在是一等公民

Yarn更可靠了

容器改进

调试改进

Global Azure Spain 2026

议程亮点

门票

Azure Tour 2026

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

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

管理正在运行的进程

与隔离模式结合使用

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

总结

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

问题是真实存在的

Aspire作为智能体基础设施

保龄球护栏类比

入门

总结

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

解决方案：--isolated

这个功能发光的真实场景

底层工作原理

何时使用

总结

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

这到底解决了什么问题

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

列出所有文档

搜索主题

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

AI 代理的视角

真实场景

文档始终是最新的

总结

Aspire 13.2的Dashboard现在有了遥测API — 这改变了一切

像正常人一样导出遥测数据

遥测API才是真正的革命性变化

GenAI遥测变得实用

总结

解决方案：`--isolated`