早上刷信息流的时候，三条新闻几乎同时出现在我的时间线上：微软把 Copilot 往“智能体操作系统”的方向重构，谷歌新一代 TPU 在算力榜单上把英伟达逼到了墙角，苹果那边又传出基于千问开源基座做端侧模型的落地动作。单独看每一条都值得写一篇长文，但放在一起就有意思了——它们其实指向了同一个转折：AI 正在从“单点工具”变成“基础设施”，而围绕基础设施的话语权，开始从一家独大转向多方博弈。
这篇文章我会把三条新闻拆开讲清楚，再聊点跟普通开发者、AI 产品经理、甚至只是重度使用 AI 的上班族真正有关的事。比如 Copilot 重构之后我们的工作流到底怎么搭、TPU 值不值得从 GPU 迁过来、以及千问这种开源基座模型在 LangGraph 里怎么流式调用、怎么做手写文字识别之类的实际场景。毕竟新闻热点一周就凉，但技术选型和个人效率工具的调整，才是能沉淀下来的东西。
1. 三件事放在一起读：智能体、算力、模型权重的三重变局
1.1 微软 Copilot 重构“智能体 OS”：从对话助手到调度中枢
如果你对 Copilot 的印象还停留在“Office 软件里帮我写周报的侧边栏”，那这次重构可能会让你觉得陌生。微软现在想做的，是把 Copilot 从“一个能对话的应用内助手”升级成“一个能编排其他智能体运行的操作系统”。也就是说，以后你面对的不是单个聊天机器人，而是一套运行时环境：它负责分配任务、调度模型、调用工具、管理多个智能体之间的上下文流转。
这个思路其实和操作系统很像。早期的操作系统管的是进程和文件，现在的 Copilot 管的是 agent、知识和连接器。用生活化的类比就是：以前你请了个帮手，你交代一句他干一件；现在你请了个项目经理，他负责把活拆给不同的人、盯进度、汇总结果。靠 Copilot Studio 这类低代码工具，非工程师也能把一个复杂的“多智能体协作流程”搭出来，然后发布到 Teams、Microsoft 365 甚至你自己的业务系统里。
当然，普通用户最直接的感知变化是入口变多了、变乱了：Edge 浏览器里的 Copilot 入口没了，Windows 里又多出一个新的 Copilot 应用，VS Code 里还区分了 GitHub Copilot Chat 和内置 AI 聊天。这些我在后面第 2 节会逐一讲清楚，别一看到入口变化就以为产品砍了，其实只是把入口收拢到“系统层”而已。
1.2 谷歌 TPU 逆袭英伟达：算力市场的第二极正在成形
说“TPU 逆袭英伟达”，有人会觉得夸张，但这几年谷歌确实把 TPU 的迭代节奏提到了让人无法忽视的程度。从最早只能做推理，到能训千亿参数模型，再到最新一代在训练效率、互联带宽和单位成本上跟英伟达旗舰卡正面掰手腕，TPU 已经不再是“谷歌内部自嗨的专用芯片”。
我身边不少做模型训练的朋友，以前提到 TPU 第一反应是“JAX 语法门槛太高、生态太冷”，现在态度已经松动。原因是两方面的：一个是硬件本身，谷歌把 TPU 的矩阵计算单元和内存带宽往极致的方向堆，同时用光交换机把芯片之间的互联规模做大，这种“人多力量大”的打法特别适合大规模并行训练的通信瓶颈；另一个是软件生态，JAX、PyTorch/XLA 的成熟度大幅提升，Hugging Face 上大量模型已经能直接跑在 TPU 上，迁移成本不再像前几年那么劝退。
这事的行业意义远不止“又多了一家芯片公司”。英伟达的护城河是 CUDA，而 TPU 的崛起意味着“不写 CUDA 也能训大模型”成为现实。对开发者和企业来说，算力终于有了可替换的选项，谈价格和带宽的时候，腰杆也能硬一点。
1.3 苹果开源千问基座模型：端侧模型终于等到了重量级基座
苹果和千问的组合乍一看有点意外，细想却很合理。千问系列作为开源大模型，在中文场景、工具调用、多模态理解这几个方向上一直有很扎实的口碑，而苹果需要在自家芯片上跑一个高质量、可私有化部署的端侧基座。未来设备上的 AI 要处理日历、邮件、备忘录、照片这些隐私敏感数据，与其全部上传到云端，不如在本地跑一个足够聪明的模型。苹果把基于千问适配的基座模型开源出来，等于告诉开发者：以后你想做 iOS/macOS 上的离线智能应用，不用从零预训练了，直接用这套基座，再结合 CoreML 和端侧推理栈就能干活。
这件事对普通用户的影响是隐性的，但对开发者来说是实打实的机会。往前推一年，想在 MacBook 上本地跑一个好用的大模型，要么选小参数模型凑合，要么自己折腾量化、LoRA 微调。有了适配好的开源基座，端侧 AI 应用的门槛一下就降下来了。这也是为什么千问 qwen、LangGraph 流式调用千问系列这些词会跟着一起上热搜——开发者真正关心的不是新闻标题，而是这模型到底能不能接进自己的项目里。
2. Copilot 重构后的落地姿势：从 Studio 到日常编辑器
2.1 用 Copilot Studio 搭一个多智能体工作流
Copilot Studio 这套工具，我之前在项目里实际用过几次，说它是“重构为智能体 OS”后在创作端的落地入口并不夸张。它把微软那些复杂的能力：语义理解、记忆、对话管理、连接器、工作流，全部封装成可视化的画布，你不需要写多少代码，就能搭出一个能跑的业务智能体。考虑到现在网上相关教程很多但都很零散，我把一条适合起步的路径整理出来：
- 创建 Agent。在 Copilot Studio 中新建一个 Agent，给它起个名字，写清楚系统指令。这个指令是灵魂，比如“你是一个项目周报助理，负责汇总团队成员的工作进展，并以简洁的 Markdown 表格输出”。
- 配置知识源。把 SharePoint 文档库、企业 Wiki 或某个内部 API 加进来，模型回答时就能基于你的业务数据进行 RAG 检索。这一步比很多人想象的重要，没有知识源的智能体和搜索引擎没区别。
- 设计触发器和编排。你可以定义当用户聊到某个关键词时，跳转到特定对话流；也可以让这个智能体调用另一个智能体，形成一个“主智能体调度多个子智能体”的拓扑结构。
- 发布与测试。在预览窗口试跑几轮，确认回答质量和调用路径没问题，再发布到 Teams 或 Microsoft 365 的入口。
实操中最大的坑是“权限和范围控制”。智能体一旦能调用多个系统，权限就容易被放大，所以每个连接器最好只授予最小必要权限，宁可多卡一步，不要裸奔。另一个坑是循环调用：A 智能体调用 B，B 又回头调用 A，很容易把 token 烧光。我建议在编排阶段就画清楚调用方向，严禁反向调用。
2.2 近期 Copilot 热门疑问实测解读：入口消失、认证被拒、正确用法
我先说 Edge Copilot 消失这件事。严格来讲不是功能没了，而是微软把 Copilot 从浏览器的侧边栏里“搬走了”，收拢到独立的 Copilot 应用、Windows 系统集成和 Microsoft 365 的入口里。如果你习惯按快捷键召唤侧边栏，现在可能按了没反应，这给人的体感确实像“消失”。但实际上去微软官网下载新版 Copilot 应用，或者直接用浏览器访问 Copilot 的网页版，功能都还健在，而且新入口对上下文的理解更连贯。我的建议是，别死守老入口，尽快适应新的入口形态，毕竟产品架构都重构了，交互入口不可能一直停留在旧时代。
再就是 GitHub Copilot 教师认证被拒的问题。这类问题通常不是因为“资格不够”，而是材料审核有硬性要求。很多人拿学校邮箱申请，但邮箱域名不在教育认证库里，或者提交的教师工作证明没有学校盖章和英文翻译件，就会被拒。我帮同事排查过几次，最快的解决办法是走 GitHub Global Campus 的申请流程，而不是普通 Copilot 个人版页面；上传的证明材料里要有清晰的姓名、学校和日期，图片大小控制在 1MB 以内。如果一直被拒，别急着反复提交，先看 GitHub 账号的地区设置和注册邮箱是否匹配。
最后说 Copilot 使用教程里最核心的一条心法：把提示词从“帮我写”升级成“你是某某角色，基于什么背景，按什么结构输出”。比如你要写代码，就告诉 Copilot 用项目里的哪套风格；你要写文档，就指定目标读者和篇幅。越具体，输出越接近你想要的结果，这是所有 AI 工具通用的一条规矩。
2.3 VS Code 里 GitHub Copilot Chat 和内置 AI 助手的区别
这个热点讨论度很高，我干脆对比着讲。VS Code 现在的界面里其实有两条 AI 聊天入口：一个是 GitHub Copilot Chat，它是 GitHub Copilot 品牌下的聊天面板，需要登录 GitHub 账号，适合已经有 Copilot 订阅、并且团队有统一管理诉求的开发者；另一个是 VS Code 内置的 AI 聊天助手，它依托你的微软账号登录，是直接长在编辑器里的基础智能体，不需要单独安装扩展。
两者最大的区别在于上下文能力和扩展性。GitHub Copilot Chat 能够结合 GitHub 仓库的代码库索引做检索增强，支持多文件编辑、跑测试、修错误，还能被组织级策略管控；而 VS Code 内置助手更偏轻量，适合问答、单文件解释、快速生成代码片段。我个人的习惯是：在正式项目里用 GitHub Copilot，因为它能理解我这套仓库的整体结构；临时写个小 demo 就直接用内置面板，省得切换账号。
有一张表格可以帮你快速决策：
| 维度 | GitHub Copilot Chat | VS Code 内置 AI 助手 |
|---|---|---|
| 账号体系 | GitHub 账号，可集成组织策略 | 微软账号，随 VS Code 登录 |
| 上下文范围 | 可检索整个 GitHub 仓库 | 主要基于当前文件/选区 |
| 多文件编辑 | 支持，可批量修改 | 较弱，偏向对话式建议 |
| 安装方式 | 安装 GitHub Copilot 扩展 | 随 VS Code 版本内置 |
| 适合场景 | 团队协作、大型工程 | 个人轻量编码辅助 |
如果你还在纠结到底用哪个，我建议直接两个都用，让它们各干各擅长的部分。代码开发这个场景，多一个 AI 帮手不亏，关键是搞清楚各自的边界，别在调试的时候找错对象。
3. TPU 逆袭背后的硬核拆解：架构、生态与成本
3.1 单芯片算力和互联带宽：TPU 凭什么在训练场翻身
很多人一听到芯片，第一反应就是单卡算力有多大。其实对大规模模型训练来说，更致命的指标有两个：一是内存带宽，二是芯片间的互联带宽。模型参数和数据要在内存里快速搬进搬出，训练时多卡还要频繁做 all-to-all 通信，这时候如果互联带宽不够，单卡算力再强也是白搭。
谷歌 TPU 在这两块的设计思路非常“极端”。它的核心矩阵计算单元长得就是为矩阵乘法定制的，推理和训练时能把大部分资源砸在乘加运算上，而不是去处理五花八门的通用计算。同时，新一代 TPU 在机架之间采用光路交换，允许大规模集群低成本互联，这种“大力出奇迹”的路线在训练超大模型时效率极高。我打个比方：GPU 像是一辆性能均衡的跑车，能跑赛道也能走市区；TPU 更像一辆专为高速公路设计的重卡，单论跑高速这件事，效率和成本都可能反超跑车。
当然，如果你要处理的是结构不稳定、经常要改算子的科研模型，TPU 的“专”也会变成“轴”。所以谁逆袭、谁被逆袭，看的其实是场景：当规模化训练成为主流配置，TPU 的优势就会被放大，而 CUDA 生态带来的灵活性优势，就没有以前那么不可替代了。
3.2 软件生态的转折点：JAX、PyTorch 兼容性和开源的合谋
TPU 过去最大的短板是真生态，首要就是 CUDA 的替代品。早期开发者不用 TPU 的最大理由就是“代码在 GPU 上能跑，TPU 上全是坑”。但现在情况明显变了。谷歌押注的 JAX 已经相当成熟，自动微分、XLA 编译这些能力让很多新模型天然就是 TPU 友好的；同时 PyTorch 通过 XLA 后端也能在 TPU 上跑，Hugging Face 的模型库里有大量开箱即用的 TPU 示例。
更关键的是，开源社区开始把 TPU 当成“多一种选择”而不是“异类”。比如说分布式训练框架、推理引擎、模型评测工具，都在同步做 TPU 适配。我近一年看到的变化是：以前“CUDA only”是很多开源项目的默认前提，现在越来越多的项目会在 README 里写明“同时也支持 TPU 运行”，这对谷歌生态的助力比任何广告都管用。
当然，迁移成本仍然是客观存在的。你不可能把一个深度依赖 FlashAttention 和自定义 Triton kernel 的 GPU 项目一行不改地搬到 TPU 上。但对于那些本来就用 PyTorch/JAX 构建、训练流程比较标准的模型，TPU 的接入成本已经可以接受了。
3.3 普通开发者和中小企业怎么搭 TPU 的便车
对普通开发者和中小企业来说，不一定需要自己买 TPU 集群，主流的路径是上谷歌云，按秒或按实例租用。Google Cloud 上的 TPU 有按需和抢占式两种定价，后者价格优势明显，适合做实验和短期的大规模训练任务。如果你手头有一个融资租赁式的需求：比如今天要跑一批离线数据处理，明天可能又不跑了，那抢占式 TPU 的性价比会比常年挂着的 GPU 实例高不少。
但我也要提醒一句：不要把 TPU 当成万灵药。如果你的项目只是微调一个 7B 模型，或者做个轻量推理接口，直接用 GPU 可能更省事。TPU 真正有优势的场景是：模型参数量在几十亿以上、训练步数多、数据并行和通信开销大的任务。我建议你先在自己的数据集上跑一个小规模的 benchmark，对比 GPU 和 TPU 的单步时间和每小时成本，再做决定，而不是听别人说“TPU 厉害”就直接迁。
如果你决定试，第一步是考虑迁移代码。如果你用的是 PyTorch，就加torch_xla来让运行环境感知 TPU；如果你愿意尝试 JAX，那就更顺了，JAX 本身就是为这种硬件而生的。不要一上来就啃大模型训练，先拿一个小模型把训练、验证、checkpoint 的链路跑通，再逐步放大。
4. 千问基座模型的终端落地：LangGraph 流式调用与办公场景
4.1 苹果开源基座模型，到底意味着什么
前面说过了，苹果这次并不是“重新发明了一个千问”，而是把千问这条开源基座模型路线，收编进自家生态，同时把适配好的权重和工具链回馈给开源社区。这个行为的价值在于：它把“开源基座模型”和“商业化终端”拉到了同一条起跑线上。开发者可以基于同一套模型权重，同时部署到云端 GPU 和苹果端侧芯片上，而不用在“私有化部署”和“体验流畅”之间二选一。
对做应用的人来说，这个信号非常直接：以后在 iPhone、Mac 上做离线 AI 功能不再需要自己预训练一个模型。你只需要拿这套开源的端侧基座，做好提示词工程、知识库挂载和模型量化就好。端侧 AI 的成本结构会从“每个用户烧云计算费”变成“一次部署全终端复用”。特别是涉及病历、合同、财务这些敏感性文档时，离线本地处理几乎是刚需，开源基座的合规价值极其明显。
当然，端侧模型也不能只靠基座本身，还需要一套完整的运行时：模型量化、显存调度、推理加速、隐私沙箱。苹果开源这部分之后，第三方 App 才有机会做出真正深入系统级的智能体验，这也是我特别关注后续进展的原因。
4.2 用 LangGraph 流式调用千问系列模型：最少代码的完整方案
LangGraph 是 LangChain 团队推出的智能体编排框架，核心是让开发者用“图”来描述任务状态流：节点是函数，边是状态转移，智能体则在这个状态流里循环运行。千问系列模型支持 OpenAI 兼容的接口格式，因此可以非常顺滑地接进 LangGraph。我直接给你一段可以跑通的代码，演示流式调用：
from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI from typing import TypedDict # 千问模型走 OpenAI 兼容协议，base_url 指向你自己的网关或官方兼容端点 llm = ChatOpenAI( model="qwen3-72b", base_url="https://your-qwen-gateway.example.com/v1", api_key="your-api-key", streaming=True, temperature=0.3, ) class AgentState(TypedDict): messages: list answer: str def call_model(state: AgentState) -> AgentState: response = llm.invoke(state["messages"]) return {"answer": response.content} # 构建一个最小可运行的有向图 graph = StateGraph(AgentState) graph.add_node("model", call_model) graph.add_edge("model", END) graph.set_entry_point("model") app = graph.compile() # 流式输出事件 async for event in app.astream( {"messages": [{"role": "user", "content": "用三句话总结这段技术方案的核心"}]}, stream_mode="messages", ): # 这里的 event 是 token 级别的事件，按需打印 if event and hasattr(event[0], "content"): print(event[0].content, end="", flush=True)这套代码的核心思想是：把“调用模型”本身变成一个节点，图的入口和出口都指向它。真实项目里你可以在call_model前后插入工具调用节点、知识检索节点、代码执行节点，甚至条件分支节点。流式调用的意义在于，用户不需要盯着空白界面等十几秒，模型边生成边返回，体感上会快很多。
有几个值得注意的点。第一，千问的网关层要支持高效流式输出，不要把返回结果一次性缓冲到网关里，那样还不如直接用非流式。第二，LangGraph 默认的处理模式可能缓存事件，你在astream时要注意用stream_mode="messages"来获取 token 级事件而非整段结果。第三，如果你的场景只是“单轮对话、不需要工具调用、不需要多步状态”，那就别上 LangGraph，直接用 OpenAI SDK 的stream=True更轻；杀鸡不要用牛刀。
4.3 千问识别手写文字并在办公场景落地
千问系列里视觉多模态模型一直很能打。在线上的很多 office 场景中，大家最常遇到的需求就是“拍一张手写笔记，把它变成电子文档”。这件事千问视觉模型完全可以搞定。关键是要给它明确的输出格式和边界。我推荐这样一条提示词策略：先告诉模型识别图片内容，再指定输出的 Markdown 结构，最后对金额、日期、编号等敏感字段提出格式要求。
下面是一段直接可参考的调用示例：
from openai import OpenAI client = OpenAI( api_key="your-api-key", base_url="https://your-qwen-gateway.example.com/v1", ) resp = client.chat.completions.create( model="qwen-vl-max", messages=[ { "role": "user", "content": [ { "type": "text", "text": "请把这张手写图片完整转写成 Markdown 表格，保留原有日期、金额、商品名称，金额统一为阿拉伯数字。" }, { "type": "image_url", "image_url": { "url": "data:image/png;base64,..." } } ] } ], max_tokens=2000, ) print(resp.choices[0].message.content)手写识别的难点不在“认字”，而在“上下文还原”。如果只是单个词识别，很多 OCR 库都能做；但当你面对一整页潦草的会议纪要，模型必须理解语义、排版、缩进和逻辑关系。千问视觉模型在中文手写体的鲁棒性上表现不错，尤其是结合语义纠错能力，能把“看起来像错别字但其实是同一个词”的情况处理得比传统 OCR 好很多。
实际落地办公场景时，我会建议做一条简单的流水线：手机拍照 -> 上传到私有化部署的千问视觉节点 -> 输出 Markdown 文本 -> 程序里自动转成 Excel 或 Word。然后是向后处理：把识别出来的日期、金额抽出来，写一段 Python 校验逻辑。别完全信任模型输出，模型帮你完成 90% 的机械工作，剩下 10% 的格式和逻辑校验留给规则引擎。
5. 三个信号背后的共性趋势与我的实操建议
5.1 智能体化、算力多元化、模型开源化：三个正在交汇的方向
把 Copilot 重构、TPU 逆袭、苹果基于千问开源这三件事摆在一起，就能看出一个很明显的趋势：AI 产业链的每个环节都不再欢迎“唯一解”。交互层从聊天气泡升级为智能体调度系统，甚至操作系统级入口；算力层从英伟达一卡独大走向 GPU、TPU、端侧 NPU 共生；模型层面，闭源 API 不再是唯一选项，开源基座模型配合端云协同正在成为主流。
对开发者来说，这意味着以前“把宝押在一个平台上”的玩法风险越来越大。你可能会发现今天用的 Copilot 功能被重构，明天用的 GPU 价格高企，后天选型的闭源模型被开源社区反超。所以我现在做技术选型，会刻意选那些“抽象层做得好的工具”：支持 OpenAI 兼容协议、支持多芯迁移、支持开源模型替换。有了这层抽象，等下一次行业重构时，你只需要换适配器，而不是从头再来。
5.2 我的实际体会：先别急着追概念，动手做一个最小闭环
最近很多人一听到“智能体 OS”就焦虑，觉得自己再不转智能体开发就会被淘汰。根据我的经验，这种焦虑完全没有必要。比起追概念，更重要的是把手头最繁琐、最重复的任务挑出来，分别用 Copilot Studio 或 LangGraph 做一个最小原型。比如你每周要整理三份报告，那就试着写一个智能体，专门做格式归一化；你每天要翻译几十封邮件，那就接一个千问模型的批处理脚本。
我在实际操作中最大的体会是：新工具的第一版往往会让你失望，因为它的上下文理解、权限配置、流式输出细节都需要磨合，但只要坚持把一个真实需求跑通，后面的价值就逐步显现。另外要养成看账单的习惯。Copilot 的席位费、TPU 的计算费、千问的 API 调用费，每一项都会随着使用深度快速累积。别等月底看到账单再后悔。
最后分享一个小技巧：无论你用哪条技术路线，都先在本地把数据流画清楚。输入是什么、模型要做什么、输出给谁、失败时怎么兜底。这不只是写代码前的设计步骤，也是你在各种新概念轰炸下保持清醒的锚点。AI 的输出永远是可替代的，但你对业务流程的理解不可替代。
