Azd | The .NET Blog

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工作流程中的摩擦。钩子的多语言支持现已可用——查阅官方文章获取完整文档。

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。

阅读原文公告。

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 的深入分析了解更多。

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

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

从笔记本到生产：用两个命令将 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 代理，试试看。查看完整教程获取包括前端聊天应用集成在内的完整步骤。