2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
几天前，我发布了一些关于 GitHub Copilot 的内容。今天我想谈谈那个较少被理解但同样强大的“表亲”：Microsoft 365 Copilot。核心区别在于，GitHub Copilot 存在于你的集成开发环境（IDE）中，帮助你编写代码，而 Microsoft 365 Copilot 则内置于 Word、Excel、PowerPoint、Outlook、Teams 和 SharePoint 中，并使用真实的业务数据进行工作。对于开发人员而言，这开辟了一个巨大的可扩展性领域，其潜力远超市场营销公告中的描述。本文旨在准确展示你目前可以构建什么、使用哪些工具以及需要做出哪些技术决策。
根本划分：声明式代理与自定义引擎代理
Microsoft 提供了两种扩展 Copilot 的方式，选择正确的方式是项目中最重要的决策。
声明式代理是 Microsoft 365 Copilot 的定制版本。你无需自带模型或编排器：而是使用 Copilot 的编排器、基础模型和基础设施，但为其声明特定的指令、附加知识和可执行的操作。实际上，它是一个 JSON 文件（即清单），告诉 Copilot 在特定场景下如何行为。它不需要自有托管服务，继承 Microsoft 365 的所有安全性和合规性，并且由于运行在同一界面内，体验与 Copilot 一致。
自定义引擎代理则在控制权方面截然相反。你需要自带编排器，可以选择模型（Azure OpenAI、其他 Foundry 模型等），使用 Semantic Kernel 或 LangChain 等框架，并将其部署到多个渠道：Microsoft 365 Copilot、Teams、Web 或自定义应用程序。它需要在 Azure 上进行自有托管，费用由你承担，并且你必须自行确保合规性及负责任的人工智能策略。
我遵循的经验法则是：如果问题是根据组织数据以特定的语气和规则进行回答，则使用声明式代理。如果你需要复杂的多步工作流、无需用户操作即可发送的主动消息、带有交互式自适应卡片的自定义用户界面，或者面向没有 Copilot 许可证的用户，则使用自定义引擎代理。
2026 年的重大变化
第一个根本性变化是模型上下文协议（MCP）在声明式代理中的官方支持。不久前，将你的代理连接到外部服务意味着编写开放应用程序编程接口（OpenAPI）规范、手动配置身份验证，并祈祷编排器能正确调用它。通过 MCP，你只需将 MCP 服务器的统一资源定位符（URL）传递给代理工具包，工具包便会发现可用的工具，生成插件规范并连接所有内容。集成外部服务的门槛从“一周的配置时间”降低到了“几分钟”。
第二个相关变化是MCP 应用程序和 OpenAI 应用程序软件开发工具包（SDK）。现在，你可以通过扩展基于 MCP 服务器的操作，为声明式代理添加交互式用户界面小部件。这些小部件可以在 Microsoft 365 Copilot 内部以内联或全屏方式渲染。这解决了声明式代理历史上的一大局限性，即它们仅支持文本。
第三个变化是用于 Claude Code 和 GitHub Copilot 命令行界面（CLI）的 Microsoft 365 代理工具包插件，它是 microsoft/work-iq 套件的一部分。它允许你在终端中使用自然语言搭建框架、配置并部署完整的声明式代理（包括 MCP 服务器、身份验证和小部件）。该功能目前处于预览阶段，需要管理员同意，但它彻底改变了开发循环。
第四个重要细节是TeamsFx 软件开发工具包（SDK）正在被弃用。其完全弃用计划于
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
