微软启动 Teams 智能体系列：把对话直接做成工作结果

微软宣布启动面向 Teams 的智能体系列，强调将智能体直接嵌入聊天、频道和会议，使查数据、拉人协作、审批和分派任务等工作能在对话中直接产生可执行结果。该系列与 Copilot、SharePoint 与 SPFx 的进展相互呼应，面向开发者提供完整的 SDK、协议与编排能力，推进从“回答问题”到“完成工作”的转变。

微软 7 月 14 日在 Microsoft 365 Developer Blog 发布《Building Agents for Teams: Turning conversations into outcomes》，宣布启动一个面向 Teams 智能体的月度系列。文章把 Teams 里的智能体定义为直接参与聊天、频道和会议的协作角色，目标是让查数据、拉人协作、审批和分派任务这类工作，不再被困在一长串对话里。微软同时把这篇文章放在 SharePoint Copilot Apps 公测公告 和 SPFx 路线图更新 之后，显示其正把 Copilot、SharePoint 和 Teams 串成同一条企业智能体路线。

Teams 里的智能体，先从“在场”开始

这篇文章最明确的判断，是微软认为智能体不该只停留在独立应用或侧边栏里，而应当出现在工作发生的地方。它把 Teams 描述成一个天然适合协作智能体的场景：用户可以直接 @ 它，把它拉进频道，要求它在同一线程里回应，或者在会议中让它参与讨论。微软的逻辑是，现实工作里最耗时间的往往不是最复杂的任务，而是那些高频、碎片化的小动作——查状态、找资料、请求批准、把相关的人拉进来。

在这套叙述里，Teams 的价值不是“再多一个入口”，而是把智能体变成像同事一样可被调用的参与者。对微软来说，这种工作方式的门槛很低，因为用户已经知道怎么和人协作；智能体只需要遵循相同的交互习惯。

为什么微软说“现在”是窗口期

微软在文中给出的时间判断也很直白：一年以前，智能体更多还停留在演示；现在，LLM 能力、延迟和成本都已经到了可以真正交付工作的阶段。文章还特别提到，Model Context Protocol 让智能体有了统一接入工具、技能和记忆的方式，agent-to-agent 通信则让多个智能体能够协同工作。微软把这些标准视为行业共识，而不是单一产品路线。

这和微软在 4 月 7 日发布的 MCP Apps now available in Copilot chat 形成了前后呼应。那篇文章已经把“富交互界面”带进 Microsoft 365 Copilot chat；7 月 9 日的 SharePoint Copilot Apps 公测 则进一步把“意图”与“动作”拆开，让 Copilot 负责理解和推理，让 SPFx 承载可验证、可审计的业务操作。Teams 这次的系列，则把同样的方向推进到协作现场。

开发者面对的是一套更完整的产品栈

从开发者角度看，微软并不是只在讲愿景。其 Microsoft Learn 的 Teams SDK 欢迎页 写得很直接：Teams SDK 是一组用于在 Microsoft Teams 上构建智能体和应用的包，负责身份验证、事件路由和 Teams 特有的底层工作，让开发者把注意力放在业务逻辑上。它支持 TypeScript、C# 和 Python，也覆盖 AI-powered agents、message extensions、嵌入式 web app、Adaptive Cards、dialogs 和 Microsoft Graph 集成。

另一篇 Agents in Teams 概览 则进一步说明，这些智能体不仅能回答问题，还能总结对话、起草文档、管理任务、自动化流程并提供个性化洞察。换句话说，微软想卖给开发者的，不只是“一个聊天机器人接口”，而是一整套把智能体接进 Teams 工作流的工程路径。

微软想把协作入口变成行动入口

这篇新系列最值得注意的地方，不是“又一个博客系列”本身，而是它把微软过去几个月已经分散出现的信号重新串了起来：Copilot 先接纳富交互界面，SharePoint Copilot Apps 把结构化操作带进画布，SPFx 路线图把它们押进下一轮发布，而 Teams 则把智能体放回人们真正协作的地方。微软 7 月 14 日还明确说，后续文章会继续讨论公共交互、MCP 和 agent-to-agent 模式的实码实现、发布与规模化、隐私与合规，以及它们从开发者那里学到的东西。

这条线索也和 微软让 SharePoint Copilot Apps 进入公测：Copilot 开始从“回答问题”走向完成工作 、微软 Agent Framework 编排模式达 1.0 和 微软为 Agent Framework 的 harness 加上四项扩展能力 互相衔接：前者解决前台交互，后者解决后台编排，而 Teams 智能体系列则试图把两端接到同一条协作链路上。

微软真正要证明的，不是智能体能不能回答问题，而是它们能不能在用户不离开对话的情况下，把事情推进到可执行、可追踪、可落地的结果。