Microsoft Teams Blog articles ... 笔记

Microsoft Teams Blog articles 中文

Microsoft Teams Blog on TechNet是一个专门为Microsoft Teams创建的平台,涵盖了包括即将推出的功能、产品改进和提高用户体验的最佳实践在内的多个主题。该博客包含了Microsoft产品团队成员、MVP和领域专家的文章。博客文章涵盖了Microsoft Teams的不同方面,如配置、部署、故障排除、用户反馈和共享知识。

笔记线程

本文介绍了一种 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 来认证服务间调用。
使用 Microsoft Intune 管理大型设备舰队时,通常需要获取大量报告数据,这一任务非常适合使用导出 API。该 API 支持报告的异步导出作业,与针对单个设备的 Graph API 调用相比,可大幅减少 API 调用次数。例如,原本针对 50,000 台设备的夜间作业,涉及 100,000 次 Graph API 调用并耗时 2.5 小时,现在借助导出 API 仅需 15 次调用即可在 15 分钟内完成。这一显著改进源于导出 API 能够在服务器端生成完整报告并提供单个可下载文件。旧方法使用操作型 Graph API,需要枚举设备并为每台设备的合规状态单独发起调用,导致频繁触发限流、线程处理复杂,且因故障点众多而显得脆弱。相比之下,导出 API 遵循“请求 - 轮询 - 下载”的简单模式,消除了每台设备的额外开销。其核心优势在于减少往返次数而非数据量,因为每次 API 调用都会产生身份验证、TLS 建立和网络延迟等成本。通过将数据检索整合为单次批量传输,导出 API 最大限度地降低了这些开销。这一转变为 IT 管理员带来了显著收益,包括更短的维护窗口、更低的代码复杂度、更高的可靠性以及更小的服务影响。同时,它还具备可扩展性:设备舰队规模翻倍主要意味着下载的文件更大,而非 API 调用呈指数级增长。输出模式保持一致,确保下游系统(如仪表板或数据仓库)不受影响。虽然导出 API 非常适合批量、定时快照,但操作型端点仍适用于实时、单设备查询。关键要点是:利用导出 API 获取全面的舰队数据,将耗时过程转变为高效、稳健的操作。
许多组织在推进 Microsoft 365 Copilot 的采用时面临挑战,因为用户并非提示工程师,面对空白屏幕感到畏惧。他们往往输入简单的查询,对结果不满意,从而停止使用该工具。解决方案在于利用组织提示(organizational prompts),这是一种管理员设置,允许您为整个组织预加载一个即用型提示库。这些提示会出现在 Copilot 聊天、Microsoft Edge 和 Teams 中,为用户提供起点,而非空白框。要配置此功能,请导航至 Microsoft 365 管理中心,然后依次选择 Copilot 和提示(Prompts)。您可以逐个添加提示,或通过 CSV 模板批量导入,最多可发布 1,000 个提示。创建提示时,您需要定义字段,如标题、显示提示、实际提示文本、支持的应用、部门、任务类型和语言。部门是供用户使用的自由文本过滤器,任务类型由 Microsoft 预定义以辅助过滤。发布后,提示大约需要三小时才能在提示实验室(prompt lab)中显示,且最多可将四个重要提示固定以便快速访问。分析(Analytics)选项卡提供有关提示使用情况的宝贵见解,帮助您识别高效提示及改进领域。用户可通过“建议”(Suggested)按钮、提示实验室以及 Copilot 输入框中的自动建议访问这些提示。启用组织提示后,至关重要的是告知用户其存在,并提供渠道供用户提交成功的提示以供纳入库中。此功能通过为用户提供有效起步所需的基础,为提升 Copilot 采用率提供了显著的“快速见效”举措。
Azure AI Speech 的流后细化(Post-Stream Refinement,PSR)现已达到一般可用性(GA),可在不牺牲即时流式结果的前提下提供高度准确的最终转录文本。该技术通过在流式处理的同时并行运行第二次识别过程,在语句完成后用更准确的版本替换初始片段。GA 版本引入了关键的生产级功能,包括用于说话人归属的说话人分离(diarization)、用于领域特定词汇的短语列表(phrase lists),以及对 19 种语言区域和 22 个 Azure 区域的扩展支持。现有的实时合同和部分结果流式传输保持不变;用户只需在 SpeechConfig 中设置属性即可启用细化功能。PSR 中的说话人分离支持确保说话人标签在细化后的转录文本中得以保留,使其非常适合会议、联络中心和访谈场景。短语列表允许识别器优先处理特定术语,显著提升产品名称和专用词汇的识别准确率。内部测试显示,词错误率(WER)相对降低了两位数,尤其在长语句和专有名词方面表现突出。虽然部分结果的延迟未受影响,但由于细化过程,最终片段可能会略有增加。PSR 现已支持 19 种语言区域,包括多种印度次大陆语言,并覆盖美洲、欧洲和亚太地区的 22 个 Azure 区域。该技术已为 Microsoft Teams 和 Microsoft 365 Copilot 提供支持,现将为 Azure AI Speech 客户带来生产级的转录体验。要开始使用,用户需要 Speech SDK 1.50 或更高版本、位于支持区域的语音资源,并在识别器中设置会话语言区域。需在 SpeechConfig 中设置"PostRefinement"选项,并可添加可选的短语列表。对于涉及多种语言或代码切换(code-switching)的场景,可使用多语言 PSR 公共预览版。然而,对于已知会话语言区域且需使用短语列表和说话人分离的场景,推荐使用单语言 GA 路径。此次发布为 Azure AI Speech 应用带来了转录质量的重大飞跃,仅需极小的配置变更。
Azure Logic Apps Consumption 集成服务账户由约 60,000 个运行在旧版运行时上的 Azure Functions 应用提供支持。团队成功将这些应用全部迁移至更新的 Functions v4 运行时,且无需客户采取任何操作。这一成果是通过精心设计的多阶段方法实现的,旨在确保兼容性并最大限度减少中断。核心策略采用“影子运行”(shadowing),将真实的生产流量同时路由至旧版和新版运行时。这使得能够直接对比每一个结果,而无需让未经验证的路径影响客户。关键举措是建立强健的等价性基准(parity bar),确保对 100% 符合条件的流量进行分析,以区分真实缺陷与本质上非确定性负载。检测到的任何实际差异均在切换流量前被仔细修复。发布过程渐进且可回滚,即根据流量哈希逐区域逐步转移流量。一个关键特性是能够通过简单的配置变更回滚整个迁移,该变更可在数分钟内生效。旧应用的退役处理极为谨慎:首先停止旧应用,随后进入显著的观察期,之后才永久删除。这种分阶段方法确保任何意外问题均可解决,且不影响客户。此次复杂迁移之所以可行,是因为微软拥有并运营底层计算基础设施。客户持久数据(如协议和模式)保持原样,所执行的操作均为纯转换。这种控制平面实现了对两个运行时的并行执行与对比。主要挑战并非新运行时本身,而是证明其与现有客户负载的兼容性。旧版运行时即将达到生命周期结束(end-of-life),风险日益增加。转向采用隔离工作器模型的 Azure Functions v4,代表了重大的架构转变。由于主机模型变更以及涉及 60,000 个应用的大规模操作,标准的轻量级迁移选项(如原地升级或简单的部署槽)被认为不足。此次迁移确保了无客户可见的中断,尽管在极少数情况下,少量客户在高负载下曾遇到短暂的边缘案例,随后触发了回滚。团队吸收了复杂性,为客户提供了无缝体验。
托管和混合云合作伙伴目前正在经历重大的基础设施转型。在 5 月的博客文章中,我们探讨了虚拟化许可变更、基础设施成本上升以及不断演变的客户期望如何为托管业务带来压力与机遇。如今,讨论的重点已从理解机遇转向采取行动。关键在于在不造成中断的前提下实现演进:保留行之有效的部分,在关键领域推进现代化,并借助 Microsoft Adaptive Cloud 拓展至高价值服务。正因如此,我们推出了新电子书《驾驭托管的下一个时代》。这是一份面向托管合作伙伴的实用指南,旨在帮助其保护利润空间、维系客户信任,并在 Azure、混合云及就绪 AI 场景中明确现代化路径。从意识到行动托管合作伙伴已开始应对更为复杂的客户对话。客户希望在本地、边缘、合作伙伴数据中心和公有云环境中获得灵活性;他们期望获得统一的管理、内置的安全、更强大的治理,以及清晰的现代化选项,而无需被强制导向单一目的地或时间表。与此同时,许多合作伙伴正在重新评估长期以来的平台战略。许可变更、商业模式的演进以及基础设施成本的上升,引发了关于利润可预测性、平台控制力以及长期差异化优势的新思考。此时,行动至关重要。率先行动的合作伙伴能够主导与客户的对话,而非被动应对。您可以阐明哪些将保持一致、现代化可从何处起步,以及客户如何在为未来做准备的同时保留选择权。继续阅读此处