Containers | The .NET Blog

.NET 10 随 Ubuntu 26.04 LTS 发布 — 新特性概览

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

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

Ubuntu LTS 发布日。Ubuntu 26.04 (Resolute Raccoon) 今天发布，与每个 Ubuntu LTS 一样，携带最新的 .NET LTS — 这次是 .NET 10。

两条命令安装 .NET 10

sudo apt update
sudo apt install dotnet-sdk-10.0

.NET 是 Ubuntu 官方支持的工具链之一，不是第三方附加组件。

容器：将 `-noble` 更新为 `-resolute`

sed -i "s/noble/resolute/g" Dockerfile

包括 Chiseled 在内的所有现有镜像变体均可用。

Native AOT：3ms 启动，1.4MB 二进制文件

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# 1.4MB 原生二进制文件，启动时间 3ms

对于冷启动时间至关重要的云原生工作负载——Functions、容器、Serverless——这是真正的游戏规则改变者。

需要 .NET 8 或 9？

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

完整文章包含有关 cgroup v2、后量子密码学和 Linux 7.0 的更多详情。

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。

Azure上のAIエージェントはどこにホストすべき？実践的な判断ガイド

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

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

如果你现在正在用.NET构建AI代理，你可能已经注意到一件事：在Azure上托管它们的方式太多了。Container Apps、AKS、Functions、App Service、Foundry Agents、Foundry Hosted Agents——在你真正需要选择之前，每个都听起来合理。Microsoft刚刚发布了一份Azure AI代理托管综合指南来澄清这个问题，我想从.NET开发者的实践角度来拆解它。

六种选项速览

以下是我对这个版图的总结：

选项	最适合	你需要管理
Container Apps	无需K8s复杂性的完整容器控制	可观测性、状态、生命周期
AKS	企业合规、多集群、自定义网络	所有东西（这就是重点）
Azure Functions	事件驱动的短时代理任务	几乎不需要——真正的无服务器
App Service	简单的HTTP代理、可预测的流量	部署、扩展配置
Foundry Agents	通过门户/SDK的无代码代理	几乎不需要
Foundry Hosted Agents	托管基础设施上的自定义框架代理	仅你的代理代码

前四个是通用计算——你可以在上面运行代理，但它们不是为此设计的。最后两个是代理原生的：它们将对话、工具调用和代理生命周期理解为一等概念。

Foundry Hosted Agents——.NET代理开发者的最佳选择

这是引起我注意的地方。Foundry Hosted Agents正好处于中间位置：你获得运行自己代码的灵活性（Semantic Kernel、Agent Framework、LangGraph——随便什么），但平台处理基础设施、可观测性和对话管理。

关键部分是Hosting Adapter——一个将你的代理框架连接到Foundry平台的薄抽象层。对于Microsoft Agent Framework，看起来是这样的：

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

这就是你的整个托管方案。适配器自动处理协议转换、通过server-sent events的流式传输、对话历史和OpenTelemetry追踪。不需要自定义中间件，不需要手动配置。

部署真的很简单

我以前在Container Apps上部署过代理，虽然可以工作，但最后你会写很多胶水代码来处理状态管理和可观测性。使用Hosted Agents和azd，部署是：

# 安装AI代理扩展
azd ext install azure.ai.agents

# 从模板初始化
azd ai agent init

# 构建、推送、部署——完成
azd up

这个单独的azd up会构建你的容器、推送到ACR、配置Foundry项目、部署模型端点并启动你的代理。五个步骤压缩成一个命令。

内置对话管理

这是在生产中节省最多时间的部分。不需要构建自己的对话状态存储，Hosted Agents原生处理：

# 创建持久对话
conversation = openai_client.conversations.create()

# 第一轮
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# 第二轮——上下文被保留
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

不需要Redis。不需要Cosmos DB会话存储。不需要自定义中间件来序列化消息。平台直接处理了。

我的决策框架

在审查了所有六个选项之后，这是我的快速心智模型：

需要零基础设施？ → Foundry Agents（门户/SDK，无容器）
有自定义代理代码但想要托管主机？ → Foundry Hosted Agents
需要事件驱动的短期代理任务？ → Azure Functions
需要不用K8s的最大容器控制？ → Container Apps
需要严格合规和多集群？ → AKS
有流量可预测的简单HTTP代理？ → App Service

对于大多数使用Semantic Kernel或Microsoft Agent Framework构建的.NET开发者来说，Hosted Agents可能是正确的起点。你能获得scale-to-zero、内置OpenTelemetry、对话管理和框架灵活性——无需管理Kubernetes或搭建自己的可观测性栈。

总结

Azure上的代理托管格局正在快速成熟。如果你今天要开始一个新的AI代理项目，我会在习惯性地使用Container Apps或AKS之前认真考虑Foundry Hosted Agents。托管基础设施节省实际时间，而hosting adapter模式让你保留框架选择。

查看Microsoft的完整指南和Foundry Samples仓库获取可运行的示例。

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代理——这次更新值得关注。

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