本文介绍了一种 HelpDesk Copilot 的开发，该 Copilot 是 Contoso 的 IT 服务台，利用 Microsoft Foundry 代理对员工提问进行分诊并提供基于 IT 知识库的答案。该系统在策略要求时，可通过真实渠道将任务移交给人工处理。其架构由三个 Azure Container Apps、一个 Foundry Prompt Agent 以及一个事件驱动的工单管道组成。该代理具备三项能力：文件搜索、create_ticket 和 get_ticket_status，用于回答员工问题并在必要时升级问题。该系统构建于 Azure Container Apps 之上，完全通过 Terraform 进行配置，且不包含任何 API 密钥；所有服务间调用均使用 Microsoft Entra ID 和管理身份。Foundry 账户已彻底禁用本地密钥认证。该架构采用事件驱动设计，API 将工单事件发布到 Service Bus 主题，随后通过 Dapr 订阅投递至工作器。工作器将工单更新到表存储（Table Storage），并将有效负载发布到 Power Automate HTTP 流程，该流程向 IT 团队的 Teams 频道发送自适应卡片（Adaptive Card）。该系统设计为幂等，工单 ID 由对话 ID 和主题确定性推导得出，确保同一对话中针对同一问题的重复 create_ticket 工具调用会收敛为同一 ID，而非创建重复项。系统还采用最终一致性设计：在 KEDA 唤醒工作器的几秒钟内，工单行可能尚不存在。该架构设计为可扩展，能够在不更改 API 的前提下，向 Service Bus 主题添加新的订阅。身份模型设计为通过 DefaultAzureCredential 使用 Entra ID，每个应用均使用用户分配的管理身份。API、工作器和前端各自拥有独立身份：API 拥有 AcrPull、Foundry 代理访问权限、存储表数据读取器、密钥库秘密用户和服务总线发送者权限；工作器拥有 AcrPull、存储表数据贡献者、密钥库秘密用户和服务总线接收者权限；前端仅拥有 AcrPull 权限。本文还讨论了使用 Terraform 配置 Azure 资源的过程，作者指出看似显而易见的资源并不总是正确的选择。作者不得不使用 azurerm_cognitive_account 来配置 Foundry Agent 服务，而非 azapi。文章最后总结，该系统设计为安全、可扩展且事件驱动，重点在于使用管理身份和 Entra ID 来认证服务间调用。