微软在 2026 年下半年对自家「智能体」产品线做了一次重命名，把之前以代号 Scout 亮相的那个工具正式命名为 Autopilot。微软对它的定位很明确：这是面向 Microsoft Teams 等协作环境的最自主智能体。它盯频道、跟线程，可以跨天推进任务而不用你反复催。这次改名让我邮箱里涌入了一堆「到底是 Autopilot 还是 Copilot」的问题，两者名字相似但职责差别很大，对想把重复工作外包给 AI 的团队来说这是必须理清的一点。
我在一套 Microsoft 365 租户里把 Autopilot 交给真实的日常工作流跑了两周，下面是它跑得动的场景、还差点意思的地方，以及我如何在日常里把 Autopilot 和 Copilot 分工用起来。据 Stack Overflow 2024 年开发者调查报告，92% 的开发者表示自己希望至少部分时间远程工作，因此跨地域频道协作仍然是绝大多数工程团队的主战场。
Autopilot 到底能做什么
Autopilot 是长在 Microsoft Teams 与 Microsoft 365 里的一种自主智能体。微软对它的官方定义是：在给定目标前持续推进、而不是每被问一次就停一次。落到实测里，它有三项能力尤其突出。
第一项是频道监控。你可以给它一份关键词、正则表达式，或一段描述事件类型的 prompt，它会在指定频道里自动筛选并把命中的内容送到你的私聊里。
第二项是跟线程。当一个线程拖过一两天、跨了几十条消息，Autopilot 可以读完整历史，把它整理成已决事项、责任人、未决事项，让两个小时的对齐时间压缩成五分钟。
第三项是跨天续任务。给它一个目标，比如「持续收集发布状态直到周五」，它会每天主动提醒负责人、催收回复、把零散回复汇总成一个页面，而不需要你每天早上重新提醒它。
Autopilot vs Copilot：边界到底在哪
名字太像，导致在团队里做推广前我先做了一张对照表，否则讨论会跑偏。这个差别不只是营销文案，它决定了你该把什么工作交给谁。
| 维度 | Copilot | Autopilot |
|---|---|---|
| 自主性 | 逐轮对话式助手 | 跨天自主运行，直到目标达成 |
| 时间跨度 | 几分钟到几小时 | 数天到数周 |
| 触发方式 | 用户主动提问 | 计划、事件或频道活动触发 |
| 典型任务 | 起草、总结、生成 | 监控、催收、汇总 |
| 主要位置 | Chat、Word、Excel、Outlook | Teams 频道、Loop、共享空间 |
| 授权 | Copilot for M365 许可 | 包含在 M365 E5 / Copilot 商业版方案中 |
Copilot 是聊天助手，你问它答；Autopilot 是队友，你定目标，它干活，你来验收。把这两者混着用，要么 Autopilot 被闲置，要么 Copilot 被喂了一堆本该由 Autopilot 承担的长期工作。
一旦模型清晰，分工就很好判断：「帮我起草一封跟进邮件」归 Copilot；「把这个 Q3 发布决策盯到周五」归 Autopilot。
两周里我实测的三条工作流
我挑了三个团队每周都要做的重复性工作，把 Autopilot 交出去，同时保留一份私有日志记录它对错了什么。
工作流一：频道监控
我给它四五个产品频道和一份「关注点」列表：发布阻塞、客户升级、无主决策。十个工作日里它总共上报了 34 条我值得一看的内容，我逐条回看后确认 27 条是真信号，其余 7 条是模糊关键词误判或本应被合并的重复项，准确率大约 80%。
真正的价值不是准确率，而是过滤时间。之前每天早上读四个频道要花二十到三十分钟，现在看 Autopilot 的摘要只要三分钟，遗漏的信号我在周复盘里单独再补一次。
工作流二：跨天线程跟进行
最有价值的一条是用它追一个卡了九天的发布决策。我给了一句两句话的简报，之后它每天上午主动催责任人、把进展合并进一页汇总，最终决策下来之后它自己发了一条收口总结。整个过程我没再手工跟进一次。
两点值得单独拎出来：一是 Autopilot 能带上下文跨过周末，二是它没有凭空制造紧迫性。看它发出的催办消息，语气一直贴合最初的简报，避免了「智能体情绪失控」这种典型失败模式。
工作流三：异步站会汇总
我把原本在 Slack 上发的每日站会替换成 Autopilot 生成的早间摘要。每天早上 8:30 它会拉取异步频道里的更新，提取阻塞项，然后把一份私有汇总推给我。团队不用学新东西，仍然按老方式贴状态；我只是不再读原始 feed。
哪些交给它，哪些留给自己
两周跑下来，能交给 Autopilot 的和不能交的工作自然分成两堆。
| 适合 Autopilot | 留给真人 |
|---|---|
| 盯频道关键词或事件模式 | 需要客户共情与语气的沟通 |
| 收集周期性状态更新 | 跨团队外交与 1:1 对话 |
| 跟进长线程并产出汇总 | 需要利益相关者判断的决策 |
| 催办与提醒责任人 | 对外公开沟通 |
| 把发布进展汇总成一页文档 | 需要协商或妥协的议题 |
判断标准其实只有一条：Autopilot 在结构化、低歧义、可回滚的活上很稳。给它清晰的输入，它会是一个可靠的队友。
从 0 到能用的 20 分钟部署流程
部署比我预想的快，以下是我固定的顺序。
- 挑一项重复工作。回顾过去一周的 Teams 活动，找出最耗时的一项重复性工作。优先信息收集类，不要一上来就交判断类工作。
- 起名字、定角色。给它名字、角色和可度量的目标，格式通常是名字 + 角色 + 触发事件。
- 限定频道访问范围。只允许它访问必要的频道，明确谁能重派任务，敏感内容默认发私聊。
- 先在低风险线程试点。从一份周报或一次站会开始，先观察一周，再扩大访问范围或权限。
- 调整触发条件与语气。一周后回看日志，反应不足就放宽触发条件，反应过度就加排除关键词并限制每日响应条数。
顺序本身不复杂，复杂的是别跳过试点期。团队一旦把 Autopilot 一上来就放到全量频道上，往往第一周就被噪音冲垮，两周后就把它关了。
治理与护栏
Autopilot 进生产之后，问题就不再是「能不能做」，而是「怎么管得住」。三条实践基本能覆盖绝大部分场景。
第一条，写一份短的 Autopilot 政策。明确智能体能做什么、由谁负责、能读哪些数据，一段话就够。
第二条，每周复盘活动日志。Autopilot 会记录它读过哪些消息、执行了哪些动作、做过哪些判断，15 分钟的复盘足够早到把漂移扼杀在萌芽。
第三条，清理没在用的智能体。Autopilot 不会自己收拾，长期不用的智能体会继续读频道，白白积累权限和噪音。
据 Forrester 2024 年数字工作场所调研，拥有成熟远程办公政策的公司在员工流失率上低约 30%，给自主智能体做治理同样是文化投入，而不只是安全动作。
什么时候别用 Autopilot
有两种情况我不会推。第一种是频道消息量太低。Autopilot 需要信号才能干活，频道每天不到 10 条消息时它基本是在猜。
第二种是工作不发生在 Microsoft 365 里。Autopilot 的能力范围紧紧贴 Teams、Loop 与 Office 文档。如果你的团队跑在 Slack 加 Google Docs 上，Autopilot 不是最优解，用 Slack 或 Google 的原生智能体做同一件事会更顺手。
最终结论
两周下来，如果按 junior teammate 的标准去设定，我完全愿意把真实的重复性工作交给 Autopilot。清晰的边界、严格的触发、每周的复盘，这三件事做到了，它每周能为我省下大约 3 小时读频道和收状态的时间。它不是要替代一个聪明同事，它把「已经占了助手半天时间的催办和总结」这类工作变得稳定得多。
把它当成一个新来的同事对待：起名字、定边界、定期检查工作。它会每天到场，而且不会主动来问你。