雷峰网

AI办公进入「上下文战争」，百度如何出牌？

张嘉敏 — Wed, 30 Sep 2026 11:50:00 GMT

导语：网盘文库十余年的家底，正成为「库库AI」的上下文富矿。

上下文，正成为AI办公的新竞争变量。

“任何事情都可以成为用户的上下文。”在百度AI Day开放日接受雷峰网采访时，百度集团副总裁、个人超级智能事业群组（PSIG）总裁王颖表示，过往的历史积累、沉淀的文件资产，以及与同事之间的对话，都是上下文的重要组成部分。

当AI办公迈入上下文竞争阶段，各家手里的优势也各不相同：

有的来自企业协作场景，消息、文档、会议天然沉淀其中；有的来自业务软件，更贴近垂直流程和行业数据；而百度的一张王牌，来自文库和网盘等多年积累的内容资产。

对百度而言，这是一座“富矿”——文库和网盘，均已运营十余年。

这种优势，让团队在过去几年里并没有跟随ChatBot热潮，而是前瞻性地选择生产力赛道：

去年4月，百度文库和网盘联合推出GenFlow 1.0，开始以通用AI Agent的形态，切入写论文、做PPT、生成行业报告等任务场景。

今年8月，GenFlow官宣中文名为“库库AI”，同时上线独立端，以更完整的产品形态继续参与AI办公大战。

十余年家底，成为上下文“富矿”

如果把视线拉回AI时代之前，百度文库和网盘解决的是两类颇为具体的需求：

文库积累了十多年的公域知识，用户不断上传、沉淀文档资料；网盘则承载个人和企业多年积累的数据，文件、图片、视频等内容都长期放在里面。

过去，这些内容更多以“存档”形态存在；到了AI办公时代，它们开始被AI调用，变成可检索、可生成的数据资产。

但数据被调用，并不等于它就能直接成为上下文。换言之，数据资产多，也不等于上下文多。

如何让这些数据发挥价值？PSIG国内业务部负责人钟昊认为，关键在于让数据“从沉淀变成使用，从零散变成结构化，并最终能被AI吸收和复用”。

因此，过去几年，团队始终在做两件事：一是加深对内容的理解，二是让AI不断渗透。

这源于AI办公落地的一个困境——工作的上下文本身就很复杂，也并非现成。

以网盘为例，存储于其中的数据只是原材料，只有这些数据能够被理解、被结构化，并在具体任务中被重新调用，它才真正成为上下文。

但回到真实的工作场景，上下文并不只来源于网盘：沟通发生在飞书、钉钉等协作工具里，信息来自搜索，业务则散落在不同的专业软件和系统中。

不同系统之间，天然存在一道道“上下文墙”。AI办公真正争夺的，是一个人完整的工作上下文。

如何打破这些墙？王颖提到，目前库库AI已经开放连接器授权，飞书、钉钉等平台的内容，在获得用户授权后，可以直接被库库AI调用。

与此同时，百度网盘也在盘活自身内容资产，希望成为用户“工作上下文”的内容源。

雷峰网了解到，对于网盘里大量的Word、PDF、PPT、图片和视频，百度已经在持续做多模态内容理解和文件格式解析，再进一步识别其中的实体、概念和关系，将原本零散的内容结构化，让它们能够被Agent真正调用。

PSIG基础研发和B端业务负责人唐海浩提到，相比单纯的文档，多模态数据的解析和结构化本身就是一个更大的难题，也是百度网盘希望形成差异化的地方。

从个人上下文，到企业上下文

AI办公产品想要成为真正的生产力工具，所需的上下文就不能局限于个人，而要走向企业。

企业上下文，并不是个人上下文的简单放大。

王颖在采访中表示，个人与企业的区别，并不只是用户规模。“比如很多工作场景都需要组织协同来共同解决一个问题，这就是一个人和一个团队的区别。”

在她看来，上下文对组织的价值，核心在于组织协同、知识沉淀与经验复用。

这意味着，企业上下文不仅要求AI“懂我”，还要“懂组织”：既能参与协同，也能把工作中产生的知识和经验沉淀下来，供其他人、其他Agent复用。这一理念也贯穿于库库AI企业版。

唐海浩透露，目前B端已经成交的客户，主要看中三点：

一是能直接解决问题。比如金融客户，尤其是投研场景，效果不错，就直接买了；教育场景里，老师平时要做PPT，也会直接买单。
二是安全。如果每个员工都单独用一个智能体，企业会担心数据安全，所以老板尤其看重企业版的安全能力。
三是能沉淀经验。有些老板希望把优秀员工的经验留下来，变成公司的积累。

除了解决问题、安全这类通用考量，企业上下文也正成为B端采购AI办公产品时的一个新关注点。

据雷峰网(公众号：雷峰网)了解，库库AI企业版刚推出，已经有3000家企业试用，其中中小企业的推广速度更快。

这背后，还藏着PSIG团队的一套“打法”：

他们洞察到大型企业流程长、决策慢，改造重构难度不小；相比之下，中小企业转型更快，因此选择从这一方向切入。

此外，多模态能力也让它拿下了一批以图片、视频为主要工作内容的企业客户。

王颖表示，库库AI在To C和To B场景都已跑通，且二者能够相互反哺。

一方面，To B场景积累了大量专家Skill，可以向下赋能To C；另一方面，To C的办公需求数据，又能帮助完善Agent数据、提升通用智能体能力，再服务于要求更高的To B客户，由此形成数据飞轮。

出海，重建一套“工作上下文”

AI办公大战正酣，但在王颖看来，AI办公工具还没有真正建立起用户粘性，眼下的市场空间并不小——这也意味着，这场大战还远没有定数。

但百度早已将目光投向海外市场。

去年，百度文库网盘推出海外一站式AI办公平台Oreate AI，此番也焕新为库库AI海外版Kooko，一年内海外用户突破1000万。

PSIG海外业务部负责人文思颖表示，海外市场仍处于普及和使用的早期阶段，“蛋糕”还在越做越大，当前最重要的是先抢占用户心智。

但在海外，AI办公产品仍要面对本地化考验：不同国家的用户有不同的软件环境、工作习惯和内容偏好。

比如韩国用户对特定模板的需求增长较快；拉美、中东的AI渗透情况与美国又有所不同，甚至同样是一份PPT，不同市场对信息密度、设计和色彩的偏好也存在差异。

由此可见，AI办公出海不只是把产品搬到另一个市场，而是把AI放进另一个工作环境里，让它重新理解当地用户的工作方式。

从这个角度看，这也未尝不是在重建“工作上下文”。

雷峰网原创文章，未经授权禁止转载。详情见转载须知。

DeepSeek 开源算子工具大礼包，联手华为昇腾，手撕 CUDA 绑定！

高允毅 — Wed, 30 Sep 2026 10:58:00 GMT

导语：一套代码能跑遍所有芯片。

一套代码能跑遍所有芯片。

作者丨高允毅

编辑丨岑峰

刚刚，DeepSeek做了一个开源壮举：把给英伟达 GPU 写代码的全套工具链，原样铺到了华为昇腾 950 NPU 上。

最核心的算子开发产品 TileLang 官宣原生支持昇腾。不仅如此，连同 DeepGEMM、DeepEP、FlashMLA、TileKernels、DeepSelect 五大核心计算与通信库也同步推出昇腾版本，直接对标英伟达平台的全套工具链。

这意味着国产算力第一次在核心算子工具层面，做到了与英伟达生态的能力对标。

在此之前，全球 AI 行业苦 CUDA 垄断久矣；而现在，DeepSeek 用一行行开源代码，为国产算力自主生态蹚出了一条康庄大道。

写算子的 “手工作坊” 时代，该结束了

做过 AI 底层开发的都知道，“写算子”一直是门槛最高、耗时最久的工作之一。

一张芯片的理论算力上限很高，但如果底层算子写得不达标，芯片内部的计算单元就会有大量时间等数据流转，导致几万块钱的芯片可能只能发挥出 20% 的性能。写算子的目的，就是为了把这 20% 的硬件利用率提高到 95% 以上。

拿最常见的矩阵乘法（GEMM）来说，要想榨干一张 AI 芯片的算力，开发者要手动管理三级缓存、调度线程块、搞定数据预取流水线，甚至要深入到寄存器分块和指令重排层面。为了优化上千行底层代码，资深工程师打磨好几周都是常态。这就导致了一个行业的核心冲突：模型算法迭代太快，芯片厂商官方算子库永远跟不上。

过去行业里有三条路可选，但各有各的局限：

第一条路是自己手写 CUDA：性能天花板最高，但开发效率极低，深度绑定英伟达生态，无法跨平台移植；

第二条路是使用厂商的预制算子库：比如英伟达 cuBLAS，标准算子开箱即用、性能拉满，但灵活性极差，开发者无法修改内部逻辑、也无法做算子融合，新算法很容易卡在算力层；

第三条路是使用高层 DSL 编译器：比如 OpenAI 的 Triton，大幅降低了开发门槛，但性能上限受限于编译器本身的优化策略，对昇腾、AMD 等非英伟达硬件原生支持度低，异构适配成本很高。

而 TileLang 开辟了第四条路，终结算子开发的 “手工作坊” 模式，同时兼顾开发灵活性、运行性能与跨平台能力。

它的核心是多级分块（Tiling），将庞大计算任务切分成标准化的数据块。开发者只需声明 “每块数据在哪里计算”，编译器自动完成数据搬运、线程同步等底层工作，性能直逼手写 CUDA 的硬件上限。

这本质上是把资深工程师手工调优的成熟思路抽象为标准化编程原语。

TileLang 主攻大模型核心算子：通用矩阵乘法、反量化 GEMM、FlashAttention、线性注意力、稀疏 MLA。这些算子承载大模型训练和推理 90% 以上计算量，直接决定 AI 芯片算力利用率。

算子速度每提升一倍，都意味着大模型训练成本下降、推理效率提升，从而大幅摊薄算力成本。DeepSeek 能够把 API 价格打到行业极致，除了模型架构本身的精妙设计，还因为底层拥有这套极高效的自研算子工具链 TileLang。

站在 TVM 肩膀上，

性能跑进全球第一梯队

从技术角度而言，TileLang 没有从零去写一套完整编译器，它复用了 Apache TVM 现成的编译能力。

Apache TVM 是华盛顿大学陈天奇团队开发的开源机器学习编译器框架，现为 Apache 顶级项目，在 AI 界的地位相当于 LLVM 在编程语言界的地位。

它的作用是 AI 芯片与大模型之间的“万能翻译官兼超级优化师”，不管上层是什么框架，底层是什么芯片，它都能编译成适合该芯片的高性能机器码。

TileLang 在 TVM 之上包装了一层简单好用的语法，专门处理大模型里最重要的分块计算。开发者不用关心底层硬件细节，只用很少代码，就能把芯片算力跑到接近上限。

TileLang 最早由北京大学团队在 TVM 编译器基础设施上孵化。DeepSeek 把它接过去、推到生产，再反向捐赠给开源社区。截至 2026 年 9 月，仓库收获 7.6k stars、1,992 次 commit，已经成为事实上的国产 DSL 标杆。

它的效果可以用官方基准数据说话：

基于 TileLang 优化的 DeepSeek V3.2 稀疏注意力 TopK 算子，比原生 PyTorch 快 2–20 倍；其推理中最核心的 MLA、FlashAttention、LinearAttention 等算子，也已全部提供可直接商用的极致优化实现。

同样在英伟达 H100 上运行核心算子，TileLang 的速度大幅超越了 Meta 的 PyTorch 原生实现。要知道，PyTorch 是目前全球使用人数最多、生态最庞大的 AI 核心框架，绝大多数主流大模型都基于它搭建。

同时，它也击败了 OpenAI 的主力加速工具 Triton。Triton 是 OpenAI 倾力打造的、全球开源社区公认最主流的第三方加速标杆，世界顶级的大模型公司都在用它来压榨英伟达芯片的算力。

图注：H100 上各底层框架的 MLA 解码性能对比，相比传统和通用框架，FlashMLA 与 TileLang 具备极佳的硬件算力释放效率

它甚至追平了英伟达官方调校的 cuBLAS 以及官方版 FlashAttention，直接进入全球顶尖性能的第一梯队。

要注意的是，英伟达官方工具只支持自家芯片，而 TileLang 具有跨平台能力，在 AMD 顶级芯片 MI300X 上跑，同样拿到了接近硬件极限的跑分数据。

TileLang 架构深度拆解：

为什么一套代码能跑遍所有芯片

TileLang 能用同一套编译器，灵活切换不同的芯片，核心在于从设计之初就采用了“前后端解耦，目标与执行分离”的架构。

传统编译器的痛点在于，把 “为哪款芯片生成指令” 和 “怎么编译加载运行” 两件事深度绑定。换一款芯片，整套逻辑都要推倒重来。而TileLang 把这两件事彻底拆开：

目标后端：只负责定义这款硬件的指令语法、优化规则，是硬件专属部分；
执行后端：只负责通用的编译、加载、启动流程，和具体硬件无关。

每当新芯片适配时，执行后端完全不用改动，只需要新增一个对应的目标后端即可。每个目标后端都遵循统一的四层流水线结构，上层通用代码输入后，会逐步翻译成对应芯片的底层指令：

第一层是语言方言（Dialect），把代码翻译成每家芯片能听懂的指令

像针对英伟达 CUDA 后端：它负责翻译并注入 WGMMA 和 TCGEN05 等张量核心指令；针对 AMD ROCm 后端：它对应翻译为 MFMA 和 WMMA 核心架构指令；针对华为昇腾后端：它则负责翻译为 Ascend C 的底层向量指令与矩阵运算原语。

第二层是上下文贡献（Context）。这一层要感知你当前跑的是什么芯片，并把不同硬件的规格参数统一转换成标准格式；记录整个编译过程的状态，保证前后一致。

第三层是Pass 流水线（Pass Pipeline），这是整个流程最核心的翻译优化环节，要把高层逻辑转换成芯片能跑的底层代码，并且针对不同芯片做不同优化。

第四层是主机 / 设备代码生成（Codegen）层，把优化好的代码拆成两份，主机侧代码运行在 CPU 上，负责任务调度；设备侧代码跑在 AI 加速器上，承担核心计算，两段代码组合完成最终编译与执行。

截至目前，TileLang 覆盖主流 AI 算力平台：英伟达 CUDA 是核心主力，拥有最完整的功能和优化；AMD ROCm、苹果 Metal、华为昇腾 950 为官方支持级；LLVM CPU、WebGPU、CuTe DSL 等处于实验阶段；沐曦、摩尔线程、海光等国产芯片则通过生态项目适配，基本覆盖了国内外主流 AI 算力平台。

这套解耦架构不仅解决了跨硬件适配的难题，还向上开放了精细化的硬件控制力。开发者只用接近 Python 的简洁语法，就能对底层硬件做精准操控，最终跑出媲美手写 CUDA 的性能。

控制算子运行效率的核心，在于三个维度：存储控制、线程调度、并行节奏。TileLang 允许开发者直接在高级的 Python 代码中，对这三个底层维度进行显式控制。

存储控制（数据放哪）：芯片内部有三层存储。全局内存容量最大，但速度最慢；共享内存速度中等；寄存器容量最小，访问速度最快。TileLang 允许开发者在 Python 中直接用代码决定数据放在哪一层存储里，避免计算单元因为等待数据而闲置。
线程调度（任务怎么分）：TileLang 通过一句代码，就能把庞大的矩阵计算像 “划分网格” 一样，精准分配给芯片里成千上万个计算核心。例如把一个巨大的计算切分成 100 份任务，在芯片上拉起 100 组计算单元（线程块），每组里面跑 128 条并发工序（线程），多路并行同时开工。
并行节奏（传输和计算怎么并发）：TileLang 用一句 T.Pipelined(num_stages=3) 直接开启三级软件流水线，让数据搬运和算力计算异步并行，一边搬数据一边算数据，绝不让芯片闲着。

用这三个维度编写的通用矩阵乘法（GEMM）算子，可以把传统 CUDA 实现通常需要 500 行以上的代码，直接压缩到 30 多行 Python 代码。

押注华为昇腾，

DeepSeek 最大的赌注

9 月 21 日，据《The Information》报道，在投资人闭门会上，梁文锋将“使用华为或其他国产芯片训练模型”描述为公司当前“最大的赌注之一”，并明确表示此役“必须成功”。

据彭博社此前报道，DeepSeek 已投入 25.6 亿美元的订单，采购至少 16 万颗华为昇腾 950DT 加速器，用于部署在内蒙古乌兰察布在建的吉瓦级数据中心，这笔订单最快 2026 年 Q4 开始交付。这批昇腾 950DT 主要面向推理侧，训练环节目前仍主要依赖英伟达。

在算力布局上，DeepSeek 没有将国产芯片视为英伟达的退路，而是被摆在了核心战略位。梁文锋的判断是，国产芯片走向全球一线只是时间问题，DeepSeek应该率先行动，适应英伟达之外的半导体硬件。

DeepSeek 转向昇腾，其背后仍有三个难关。

第一块：训练软件栈全部重写。

DeepSeek-V3、V4 的训练代码，最早是为英伟达的 Tensor Core / Hopper 架构 WGMMA 指令写的。要在昇腾上跑，必须把每一处 cuBLAS / NCCL 调用替换成 Ascend C / HCCL。同时，FlashMLA、DeepEP、DeepGEMM 这些自研核心算子，要逐一在昇腾 950 上验证性能。

第二块：通信原语底层替换。

大模型训练要在成千上万颗加速器之间同步梯度，通信原语是并行训练的基石。英伟达生态的 NCCL 与昇腾体系的 HCCL，在 API 设计、性能曲线、容错模型上完全不同。从 NCCL 到 HCCL 的迁移不是改个 import 那么简单，任何一个集合通信操作的适配偏差，都可能导致整轮训练静默失效。

第三块：芯片产能押注。

更隐蔽的风险藏在供应链。推动 DeepSeek 转向国产芯片的动因是美国出口管制，而同一管制政策也制约着华为扩大 Ascend 950 产能的能力。DeepSeek 押注 16 万颗昇腾的隐含前提是：华为的 Q4 交付不能掉链子。

目前，DeepSeek 正在训练一款 2 万亿参数的大模型，参数规模超过现有旗舰 V4 的 1.6 万亿；梁文锋同时透露，公司已规划 8 万亿参数的更大模型。

模型规模越大，训练与推理对算力的需求就呈指数级增长。据梁文锋此前估算，训练一款与 OpenAI 同级别的大模型，大约需要 5 万颗英伟达 GB300 处理器，对应需要 20 万颗华为昇腾 950 芯片。

尽管 DeepSeek 全力推进国产算力迁移，但现实是华为当前的芯片供货仍有缺口。知情人士透露，受先进内存等核心元器件短缺影响，华为正面临生产瓶颈，DeepSeek 短期内仍无法完全摆脱对英伟达硬件的依赖。为此，DeepSeek 已完成多轮大规模融资，持续投入算力扩张。

未来 12 个月里，至少有 4 个变量会决定这场赌局的胜负：

华为 Ascend 950 的 Q4 交付率，决定 DeepSeek 训练时间表；TileLang 昇腾后端是否能在 6 个月内追平 CUDA 后端，决定开发效率；字节、腾讯、阿里是否跟随押注昇腾，决定生态规模；美国出口管制是否再次升级，决定这条路的下限。

这些问题里，还没有定论。但一个趋势已经清晰，TileLang 的开源，把“国产算力生态怎么建”这件事，从一个工程问题变成了一个生态问题。

对比 CUDA 与 TileLang，两者代表了两种完全不同的生态路线：CUDA 是闭源、全栈、硬件绑定的厂商主导生态，积累深厚但迁移成本极高；TileLang 是开源、聚焦、跨硬件的社区化工具，专注解决大模型最核心的算子开发问题，灵活度高、移植成本低。

TileLang 的意义不在于替代 CUDA，而是补上了当下最紧迫的短板，让国产芯片不需要从零搭建完整的软件生态，就能快速拥有大模型训练所需的顶级算子能力。当越来越多的大模型厂商基于 TileLang 开发算子，国产芯片的适配成本会指数级下降，整个生态的迭代速度也会大幅加快。

某种意义上，DeepSeek证明了用国产芯片，一样能堆出世界级规模的超算集群。

当大模型竞争进入算力成本与供应链安全的深水区，“用软件定义算力” 不再是一句口号，TileLang 这样的底层工具创新，正在悄然重构国产算力生态的格局。

参考链接：https://github.com/tile-ai/tilelang

https://www.theinformation.com/articles/deepseek-bets-big-huawei-chips-bypass-u-s-export-controls?utm_campaign=Editorial&utm_content=Article&utm_medium=organic_social&utm_source=threads,twitter&__cf_chl_rt_tk=iW7ZBFXRrEVuB9NBtCSW3X3dfxuUsmhAeiCUuxwa9RI-1790041475-1.0.1.1-NZ2.jEQlxsBBSsJDT6m6kKkiC9ImC8gHkVtqSlKM8iI

上车，雷峰网(公众号：雷峰网)带你看遍全球 AI 顶会精华

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

扫描上方二维码

或点击「阅读原文」关注专区。

雷峰网原创文章，未经授权禁止转载。详情见转载须知。

Muse爆火，dots入场：Personal Agent开始和互联网平台抢入口

李娜 — Wed, 30 Sep 2026 08:35:00 GMT

导语：Personal Agent 正试图成为互联网的新中间层。

Personal Agent，正在成为这一轮 AI 产品竞争里最热的新概念之一。

9 月 29 日，OpenAI 发布了可以长期在线的个人 Agent 产品 dots，提出“always-on agents”。更早把这个词推到台前的是 Meta 发布的个人 Agent 产品 Muse，截至 9 月下旬下载量突破 300 万，一度将 ChatGPT 从美国 App Store 免费榜第一的位置上挤下。（雷峰网）

Muse 运行在一台独立的云端虚拟电脑里，有自己的浏览器，可以替用户打开网页、填写表格、发邮件、预订旅行；一些耗时更长的任务，即使用户退出 App，它也可以继续在后台执行。扎克伯格举过用 Muse 爬山预约的例子：任务可以跨几天甚至几周持续存在。

Muse 之后，这条路线很快开始变得拥挤。9 月 28 日，Manus 推出一款名为 Cue 的独立应用。

国内大厂也开始往同一个方向靠拢。千问宣布加速打造 Personal Agent；豆包早在今年 4 月就启动了代号 Spell 的 Personal Agent 项目，Muse 走红后字节进一步加速推进，计划 9 月底完成体验版测试。腾讯也被曝正在内测代号 Handy Bot 的 Personal Agent，并计划推出独立 App。

不到一个月，Muse、Cue、千问，以及更多正在跟进的产品，把 Personal Agent 从一个产品概念推成了新的竞争方向。问题也随之出现：过去两年 Agent 已经火过很多轮，为什么现在 Personal Agent 突然集中出现？以及这些公司想竞争的到底是什么？

Personal Agent 围绕“人”建立 Context

Personal Agent 为什么在这个时间点集中爆发？我们可以从以下三个方面理解。

首先，是场景成熟度。过去一段时间，Codex、WorkBuddy 这类办公 Agent 已经把“AI 能真正替用户做事”推向了主流。用户愿意交给 Agent 的任务正在变得越来越重。

其次，是用户需求的变化。Assistant Benchmark 创始人 David Pawlan 指出，市场上已有 122 款不同类型的 Agent 产品，日常高频场景集中在邮件归类、表单填写和代理协作事项上。这些需求有一个共同特征：用户希望产品长期记住自己的状态、习惯和偏好，替自己长期管理某件事。

最后，是技术可行性。支撑长期记忆和后台执行的技术，在这半年里集中走向工程可用。过去 Agent 一旦跨天、跨周，容易出现信息衰减、关键上下文丢失和任务跑偏；现在这些问题开始被长期 Memory、云端执行环境和后台任务机制逐步缓解。

但长期理解一个人，和完成一个明确任务，是两种不同的工作方式。

办公 Agent 通常围绕任务工作。任务很明确，比如要修一个项目 Bug，就读取相关代码、报错和测试文件，这是它工作的上下文，一项任务结束，这组 Context 的作用也基本结束。

办公 Agent 主要管理任务状态，Personal Agent 则试图长期管理一个人的状态。

很多时候，用户的想法还比较模糊，告诉它的可能只是“下个月想出去玩几天”“最近想把生活规律一点”“这笔花费是不是还能更便宜”。

正在做 Personal Agent 的创业者林周告诉雷峰网(公众号：雷峰网)，他们早期的产品更像“一句话生成一个小应用”，但很快发现，只要用户没有明确想法，Agent 就很难继续提供价值。后来产品开始转向长期记住用户状态、习惯和偏好，再判断下一步需要什么。

这也决定了Personal Agent 的 Context 很难只围绕一项任务建立，它要逐渐围绕用户本人组织起来。它不仅要知道这次要订酒店，还可能需要知道用户过去住什么样的酒店、不喜欢什么航班、预算大概多少；一件事情隔了几天甚至几周，也不能因为对话结束就重新从零开始。

因此，Memory在 Personal Agent 里最困难的是从大量个人信息中持续判断：个人偏好中哪些是真的和眼前的任务相关的，要排除掉哪些一次例外、过期的信息。

另一层差别发生在执行端。

办公 Agent 通常面对的是相对固定的工具集合：代码库、终端、文件系统和企业 API；Personal Agent 却需要根据用户需求在不同服务之间做选择，再跨浏览器、邮箱、日历、电话和支付等环境把任务接着做下去。

也因此，Muse 给 Agent 配独立的云端电脑和浏览器，Cue 更进一步给 Agent 配上邮箱、电话号码、钱包和电脑。Manus 创始人肖弘在网络平台上把这种产品形态描述得更进一步：“……也许可以称之为人……”

这些设计背后的方向是一致的：让 Agent 成为一个可以长期存在、跨服务行动的执行层。

两类 Agent 的差别也因此不只是“办公”和“生活”。办公 Agent 更关心如何把一个明确任务做完，Personal Agent 则试图长期理解用户，并在不同时间、不同服务之间把事情接着做下去。

Personal Agent 想抢在用户选择平台之前

过去二十年，互联网平台长期争夺的是用户注意力和流量入口。谁能让用户先进入自己的平台，谁就更有机会掌握后面的搜索、推荐、广告和交易。

过去，一个人想买一台咖啡机，会先打开淘宝，再搜索、筛选、比较。如果换成 Personal Agent，用户只需要说一句：“帮我买一台 1000 元以内、明天能到、评价不错的咖啡机。”在淘宝或Amazon真正被打开之前，Agent 已经知道了他的需求、预算和时间要求。

过去的链路是：用户 → 平台 → 服务。Personal Agent 想把它改成：用户 → Agent → 平台 / 服务。

正在做 Personal Agent 的创业者林周告诉雷峰网，他们现在会让 Agent 长期追踪用户的状态，再主动判断什么时候应该介入。比如一个人持续健身一段时间后，Agent 不必等用户重新来问，可以根据此前的计划和状态主动给出下一步建议。

这也正是Personal Agent 想占据的，比注意力更靠前的一层东西。我们可以把这种逻辑称之为：Intent Economy，意图经济。谁先拿到用户意图，就开始拥有替用户选择服务的分发权。用户已经产生需求，但还没有决定去哪个平台。这也是它和互联网平台原有的入口和分发权发生重叠的地方。

要做到这一步，光有一个会操作网页的通用 Agent 还不够，它还需要 Connector。Connector 可以简单理解成 Agent 和外部服务之间的“接口”。它可以把用户日常使用的服务接进来，用户授权后，Agent 可以读取邮件、日历、商品和订单，并在权限范围内执行操作，这也是 Personal Agent 和通用 Agent 一个主要的差异点。

Meta 最近围绕 Muse 快速扩展 Connectors，把零售、支付、旅行、办公等服务接到 Agent 后面，包括 Walmart、PayPal、Expedia、Notion 等。换句话说，Muse 正在尝试搭建一张 Agent 可以直接调用的服务网络。

也就是说，Personal Agent 真正想争夺的不只是用户需求的第一入口，而是需求之后的服务分配权。问题在于，这种分配权并不是 Agent 单方面就能获得的。

Agent 想成为入口，巨头还守着门

Personal Agent 的产品叙事里，互联网像一个可以自由调用的巨大工具箱。用户给出目标，Agent 自己去搜索、比较、调用不同服务，最后把事情做完。但真正开始执行以后，它很快会碰到一个问题：用户愿意让 Agent 去，并不意味着平台愿意让 Agent 进。

Muse 和 Amazon 的冲突就是一个很例子。

Muse 上线后可以替用户在不同网站搜索和购物，但 Amazon 很快阻止了它访问自己的购物网站。Amazon 给出的理由是 Muse 没有事先获得许可，并强调第三方 Agent 应当公开自己的身份，同时尊重服务提供方是否愿意参与的决定。Amazon 此前也对 OpenAI、Google 等公司的购物 Agent 采取过类似限制。

这件事也暴露出了 Personal Agent 入口逻辑里的一个缺口。

用户可以授权 Muse 替自己购物，但在平台看来，Agent 是谁、代表谁、能读取什么数据、出了问题由谁负责，仍然要由平台自己的规则决定。换句话说，Personal Agent 面前其实有两道授权：第一道来自用户，我允许你代表我行动；第二道来自平台，我是否承认你可以这样进入。只有用户授权，Agent 即使知道用户想做什么，也未必真的能把事情做完。

只有用户授权，Agent 能理解用户想做什么，却未必真的做得成。

Amazon 的态度就很典型：它限制站在消费者前面的第三方 Agent，却同时在卖家业务中增加 Agentic AI 能力。区别在于，后者仍然服务于 Amazon 自己的工作流；而当 Personal Agent 先拿到用户需求，再决定是否调用 Amazon 时，它已经开始介入平台原本掌握的入口和分发。

Shopify 给出的则是另一种答案。它没有简单把第三方 Agent 当成一个未经邀请的自动化程序，而是开始把 ChatGPT、Gemini、Microsoft Copilot、Meta 等 AI 产品正式纳入 Agentic Storefronts，让商家决定自己的商品是否进入这些渠道，并由 Shopify 继续承担商品、订单和结账等基础设施。这可能更接近未来平台与 Agent 的关系：平台不会放弃规则制定权，它会把 Agent 纳入自己的规则。

从搜索爬虫、第三方 App 到小程序，新中间层出现后，平台最终都会建立自己的访问规则。Personal Agent 很可能也一样：身份认证、官方 Connector、支付和关键操作确认，会逐渐被标准化。Agent 拿到用户需求，并不意味着天然拿到了整个互联网的分发权。需要重新定义的是：当一个 AI 声称自己代表用户时，平台在什么条件下承认这种代理关系。

Personal Agent 离“下一代入口”还差什么？

如果只看最近一个月的产品发布和融资节奏，Personal Agent 很容易给人一种“下一代入口已经出现”的感觉。但它离这条路线离真正成立还有距离。

首先，它没有明显的底层技术跃迁。Muse、Cue 依赖的浏览器自动化、Container、长期记忆、工具调用和后台任务，此前都已经存在，开发者也早就可以把这些能力拼成自己的 Agent。Muse 真正的变化更像是工程和产品层面的：把云端电脑、浏览器、Memory、权限和工具调用这套过去需要开发者自己拼起来的东西，做成普通用户可以直接使用的产品。

这也是为什么今天跑得最顺的场景仍然是退款退货和购物比价：目标明确，出错后也大多可以补救。它距离“长期理解一个人并替他处理生活”，还有很长距离。

再往前，一个更难的问题是用户愿意把多少行动权交给 AI。扎克伯格举过一个例子：如果 Muse 知道用户怀孕，它可以据此推荐无酒精饮品更好的餐厅，但不应该把“怀孕”这件事告诉餐厅。Meta 把这种能力叫“分寸感”。Agent 知道得越多，这种判断反而越重要。

到了中国，还会多上一层平台的限制。

海外的 Personal Agent，很大程度建立在 Email、Web、Calendar、信用卡这些相对开放的基础设施上；而中国用户的很多数字生活，都沉淀在微信、淘宝、美团、抖音、小红书这样的超级 App 里。社交、支付、交易和本地生活服务，都深嵌在各自生态内部，并不天然向一个独立的第三方 Agent 开放。

（Muse的通知消息：它会主动让用户把“在别的 AI 那里说过的背景信息”再发给自己）

这也带来一个尴尬的局面：最有条件把这些服务串起来的，恰恰是平台自己。腾讯有微信和小程序，阿里有电商、支付、地图和旅行，字节也有内容、电商和本地生活。但如果一个 Agent 最后主要活动在自家体系里，它究竟是用户的 Agent，还是平台新的入口形式，就很难说了。

所以今天限制 Personal Agent 的，已经不只是模型够不够聪明。它至少还要同时跨过三道门槛：任务能不能连续跑几天而不掉链子，用户敢不敢让它真的替自己做决定，以及平台是否愿意把关键服务交给一个外部 Agent。

这三件事，目前都还没有被彻底解决。

新故事，还是新入口？

Personal Agent 之所以迅速升温，一个很直接的原因是，它被不少从业者视为接下来最具确定性的方向。

相比 AI 办公，Personal Agent 面向的是一个人的整个数字生活。Muse 出现以后，很多人的反应是“终于等到了！”这种确定性，大厂已经用行动投了票。

但另一面也很明显：Personal Agent 的热度，本身也符合这一轮 AI 行业对“新故事”的需要。

过去两年行业谈参数、Token、API 和企业收入；Personal Agent 出现以后，下载量、DAU、入口、生态、交易和分发这些消费互联网熟悉的词又回来了。

故事成立，不等于产品已经成立。长期 Memory、用户对交易控制权的让渡、平台开放，以及高推理成本下的商业模式，都还没有真正解决。所以 Personal Agent 最后未必会以一个独立 App 的形态存在，它也可能直接长进手机系统、超级 App 和已有的 AI 助手里。

但有一点已经越来越清楚：AI 正在从完成一次任务，走向长期代表用户行动。过去互联网争的是用户先打开谁的 App，Personal Agent 想争的，是用户打开 App 之前的那一步。谁能成为用户和互联网之间新的中间层，已经开始成为下一轮竞争的位置。

▼

推荐阅读

▼

流沙之上：陈冕、景鲲、倪正民和中国 AI 应用创业者的三种选择

2026-09-01

WorkBuddy、豆包工作、千问办公实测：AI 把活干完了，为什么你更累了？

2026-09-18

雷峰网原创文章，未经授权禁止转载。详情见转载须知。

2000座高速闪充站落成，比亚迪如何扛住国庆车流？

马诗晴 — Wed, 30 Sep 2026 08:31:00 GMT

导语：比亚迪接下来的目标，年底建成两万座闪充站。

作者丨马诗晴

编辑丨马广宇

在第2000座高速闪充站建成后，比亚迪将迎来第一场大考。

几天前，比亚迪宣布第2000座高速闪充站在扬州宝应服务区落成。这意味着在国庆假期，比亚迪高速闪充网络将要面临首次车流集中压力测试。

在现场演示中，比亚迪汽车从10%电量充至97%，用时约9分钟。用比亚迪闪充业务总经理王俊保的的话来说：“充电站‘有’和‘好用’是两个概念”，而从其表述来看，比亚迪是后者。

当前，节假日补能需求仍在增长。从国家能源局披露的数据来看，今年春节假期，全国高速公路新能源汽车日均充电量达到0.17亿度，而五一期间日均充电量达到了0.19亿度，再创历史新高。

但单车充得快，并不意味着高峰时段排队就短。站点能同时服务多少辆车、车位能否及时周转、供电能否跟上，都会影响实际补能耗时。

2000座高速闪充站落成，体现了比亚迪的建设进度。国庆期间，这些站点能否在集中补能需求下保持充电效率、缩短用户等待，考验的却是整站运营能力。

建站数量之外看什么？

闪充站总量增长，并不一定弥补了局部补能缺口。对长途自驾而言，尤其在偏远旅游地区，关键位置的一座站，就可能影响整条线路的出行安排。

今年比亚迪位于海拔4000多米的珠峰小镇闪充站已经投入运行，成为比亚迪内部观察长途补能需求的一个样本。

长期以来，珠峰地区海拔高、气温低，补能基础设施相对薄弱，对新能源汽车长途出行提出了更高要求，也限制了部分车主前往当地。

王俊保介绍，该站建设初期主要考虑展示作用及偶发补能需求，但后台数据显示，包括比亚迪、小米、特斯拉在内的多个品牌纯电动车用户，在长途旅游过程中使用了该站的充电服务。

珠峰小镇案例表明，补能设施的完善既能满足既有需求，也可能释放此前受充电条件限制的出行意愿。

因此，衡量补能网络的价值，除了看站点数量，还要看其是否填补了关键线路和目的地的设施缺口。对消费者而言，返乡、旅游途中能否方便充电，既影响车辆的使用范围，也可能影响购车判断。

根据比亚迪披露，2000座高速闪充站覆盖国家高速、省级高速及都市圈环线等278条高速公路，在京沪、京港澳、沈海、连霍等22条高速主干线上形成“11纵11横”布局。河西走廊、华东沿海等旅游线路，以及国道、景区和偏远目的地，也被纳入补能网络建设范围。

值得注意的是，比亚迪在位置选择上也有自己的逻辑。

第2000座闪充站落地的扬州宝应服务区位于京沪高速。京沪高速是连接南北的重要通道，沿途补能需求较强。尤其扬州及周边旅游资源丰富，该站能够兼顾江浙地区用户和跨区域出行车辆。这一选择是比亚迪兼顾交通流量与区域出行需求综合考量结果。

从珠峰小镇到京沪高速，比亚迪正将补能网络延伸至不同出行场景。

随着覆盖扩大，建设重点也需向服务能力提升延伸。这需要车企、场站运营方、电网和交通管理部门一同推进，结合实际车流、电网供应能力和用户反馈，使站点配置更贴合不同地区的出行需求。

国庆少排队，比亚迪怎么做？

高速补能需求存在明显的时段差异，相比平日，节假日车流集中涌入部分热门服务区，更考验站点的连续服务能力。

今年春节的保障措施提供了参考。据交通运输部披露，春节期间，全国高速公路服务区累计增设移动充电设施约1.7万个，增派充电服务人员约11.8万人次，引导新能源车至对向服务区充电约3.8万辆次。从结果来看，在新能源车日均流量同比增长34%的情况下，日均充电特别繁忙服务区数量下降48%。

由此可见，设备增补与运营调度共同缓解了高峰压力，好的运营管理能改善补能体验。着眼当下，今年国庆，比亚迪为提高高速闪充站车位周转效率，也做出了不少动作。

比如闪充桩配备摄像头和语音提醒功能。不仅能够识别车辆类型，而且可以结合插枪及充电状态判断是否存在占位。对于燃油车或停入车位但未充电的新能源汽车，系统可通过语音提醒车主及时驶离。

另外，比亚迪表示将联合服务区管理方加强巡查和车辆引导，配合系统提醒处理占位，帮助有补能需求的车辆尽快进入充电车位。

除了车位周转问题外，电力条件则决定了闪充能力能否持续发挥。

比亚迪一方面通过配套储能降低对上游电网供给能力的要求；另一方面，加强与服务区和地方政府的前期沟通，协调电网扩容。同时，比亚迪还将安排技术和运营人员提供现场应急支持。

在适配车型上，比亚迪闪充站也面向其他品牌新能源汽车开放。

据介绍，享有相关权益的比亚迪闪充车型车主，可获得一年免费充电服务，权益适用场景包括比亚迪高速站及城区相关站点；其他品牌新能源汽车也可使用相关充电服务，按相应规则付费。

王俊保在接受采访也表示，希望车主在使用高速闪充服务后，通过官方渠道或其微博留言，反馈车位占用、站点位置及使用便利性等问题。比亚迪将根据用户意见调整站点布局和现场管理，改善新能源汽车用户的补能体验。

2000座高速闪充站能否接住国庆车流，要看高峰时段的实际表现：多车同时充电时功率能否跟上，充电车位能否及时周转，故障能否迅速处理。任何一个环节出现堵点，都可能抵消单车充电提速带来的时间优势。

都在建站，比亚迪有何不同？

完成2000座高速闪充站建设后，比亚迪将推进下一阶段目标：年底前全国闪充站总量达到2万座。按9月24日已建成的11586座计算，年内还需新增8414座。

“年底建成2万座闪充站是硬性目标。”王俊保表示，高速站建设仍将继续，同时团队会将更多精力投入其他场景，通过站中站、油中站和自建旗舰站等模式加快布局。

事实上，当前补能网络建设方式正趋于多元。

除车企主导建设外，车企还与既有的商场、4S店或者加油站合作建设站中站、油中站，借助既有场站及运营资源扩大覆盖。行业内也出现通过股权合作推进充换电网络整合的尝试。此外，电池企业通过提供标准化电池及换电方案，与车企合作开发适配车型，推动跨品牌网络建设。

值得注意的是，这些模式并非相互独立，一家企业可以同时采用多种方式。但无论采用哪种模式，都需要解决车辆与充电设备适配、车位翻台、电力供应等问题，确保站点建成后，车主能够顺利充电、减少等待。

比亚迪的差异化体现在其同时布局整车、动力电池和闪充设施。因此能够在研发阶段就考虑车辆与充电设备如何配合，这为统一技术和服务标准提供了便利。但这并不意味着建站和运营全部由自身承担，场地、电力接入及现场管理仍需要合作伙伴参与。

根据王俊保介绍，目前比亚迪还在通过“圆梦建站”计划收集需求。车主可以提出住宅或工作地点周边的建站申请，当有四位车主提出需求，比亚迪方面进行实地勘测后，场地和电网条件具备将可能推进建设。这一机制也为选址增加了用户视角。

面对年底的两万座目标，从行业来看，自建与合作共建并行，已经成为扩大补能网络的常见方式。比亚迪由于已经集中力量先完成难度较高的2000座高速闪充站建设，相关负责人表示剩下的任务一部分将通过站中站、油中站等模式建设，利用已有场地和配套资源，提升建设效率。

比亚迪的扩张路径由此更加清晰：车辆、电池和闪充设备由自身统筹，网络铺设则结合自建与合作共建推进。对比同行通过通过股权合作推进充换电网络整合，或者电池企业主导标准化方案。比亚迪全流程自己都覆盖了，节省了各个环节的磨合成本。

如果年底两万座目标兑现，比亚迪闪充从高速到日常道路实现覆盖，这张网络有机会成为汽车之外的另一项购买理由。【来源：雷峰网(公众号：雷峰网)】

雷峰网作者长期追踪新能源产业（宁德/华为/比亚迪/国轩/特斯拉等），重点关注储能/AIDC/动力电池/补能体系，欢迎添加微信 dmzb287 交流讨论

雷峰网原创文章，未经授权禁止转载。详情见转载须知。

实测 Qwen-3.8 与 GLM-5.3 的 Flash 版：谁能让我提前下班半小时？

李娜 — Wed, 30 Sep 2026 08:28:00 GMT

导语：两款 Flash 模型均能胜任办公应用开发，但 GLM 偏工程完整性，Qwen 偏个人工作流设计，Flash 正从低价问答转向承接高频办公工作流。

2026 年 8 月 26 日，同一天，Qwen 发布 Qwen3.8-Flash-Next/Qwen3.8-Flash，Z.AI 发布 GLM-5.3-Flash。从名字看，“Flash 模型”代表低价、快速、负责高频调用，更多是旗舰模型的补位产品，但这次两家官方给出的宣传重点，其实已经不再停留在便宜聊天上。（雷峰网(公众号：雷峰网)）

千问云对 Qwen3.8-Flash 的定位直指 1M 长上下文、长文档、完整代码库、复杂对话、编程辅助、工作流编排和视觉理解，并强调它能够接入开发者工具；而智谱对 GLM-5.3-Flash 的描述则更进一步把视觉编程、办公任务、金融研究、文档处理，以及 PPTX、PDF、DOCX、XLSX 这类交付成果写进核心卖点。因此，两款模型都传递出一个新的信号：Flash 并非只是旗舰模型的低价补位，而是正在进入办公、开发和交付物生成这些真实生产力场景的底层基座。

那么，一个更实际的问题是：如果 Flash 模型是为了应对用户每天的高频任务而生，首先应该证明什么？我们的判断是：模型首先要证明自己懂办公。

结合模型超强的综合能力，我们认为懂办公，应该能理解用户在办公场景中的真实痛处：对多数办公用户来说，办公任务常常是一组持续发生的上下文切换，今天要做什么，哪些事项最紧急，哪些会议会挤占时间，哪些项目已经延期，哪些笔记需要沉淀成行动项，哪些零散信息要在需要时被重新找到，而真正消耗人的，往往不是某一个任务本身，而是任务、日程、项目、笔记和资料彼此分散之后带来的管理成本。

因此，我们要求模型完成一组包含任务管理、日程管理、笔记管理、工作概览和全局搜索等功能的工作台开发任务，从而看清模型能否把办公痛点转译成一套合理的工作流：帮助用户规划任务优先级，安排日程节奏，追踪项目状态，沉淀工作笔记，并通过一个统一入口降低来回切换工具的成本。

从结果来看，两个 Flash 模型都已经迈过了“能不能做”的门槛：它们都能把自然语言需求拆成前后端、数据持久化、页面交互和测试文档，并交付出一个可运行的个人工作台。但真正有意思的差异也在这里出现：GLM-5.3-Flash 更像一个工程交付型模型，先把登录、模块、CRUD、统计和测试补完整；Qwen3.8-Flash 更像一个个人工作流设计型模型，更早把优先级、截止日期、7 天内安排、全局搜索和 Markdown 笔记放到办公体验核心。

这也构成了本文的核心结论：Flash 模型的价值，已经从“更便宜地回答问题”转向“以更低成本进入真实高频工作流”，两款模型都能胜任基础办公应用开发，但 GLM 胜在系统完整度和工程感，Qwen 胜在对个人办公节奏的捕捉；前者把办公做成一套管理系统，后者则更像在尝试替用户整理一天的工作。再结合 GLM-5.3 的成本对比来看，一个更值得关注的产业趋势正在浮现：未来大多数办公任务未必都需要旗舰模型出手，Flash 模型将成为承接日常生产力需求的主力模型。

实测：从零开发个人工作台，谁更懂日常办公？

我们分别调用 Qwen3.8-Flash 和 GLM-5.3-Flash，在 Claude Code 中完成一个“网页版个人工作台”开发任务，采用同一任务、同一环境进行实测。

测试任务如下：

# 任务：开发一个完整可运行的个人工作台 / 办公网站

本次测试要求模型从零开发一个可独立运行的个人工作台 Web 应用，面向个人日常办公场景，支持任务管理、日程管理、笔记管理、Dashboard 工作概览和全局搜索等核心功能。

项目必须同时包含前端与后端，后端负责业务逻辑、数据读写和接口服务，前端负责页面展示与交互。任务、日程、笔记等数据需具备真实持久化能力，应用重启后数据不得丢失。系统应支持完整 CRUD 操作、筛选、搜索、统计展示，并提供清晰的 API 说明。

交付内容需达到可继续开发的软件工程标准，包括合理的项目结构、依赖配置、环境变量示例、数据初始化逻辑、测试代码、示例数据和完整 README。

项目需适配 Windows 11、Python 3.12、Node.js 22.14.0 环境，不允许依赖 Docker 或要求用户额外部署 MySQL、PostgreSQL、Redis、MongoDB 等独立数据库服务。

该任务重点考察模型是否具备完整软件项目设计、前后端开发、数据持久化、接口设计、工程组织和交付文档编写能力，而不仅是生成静态页面或代码片段。

这个任务的不考察页面多漂亮，而在于它能反向检验两个 Flash 模型是否具备进入办公场景的基础能力：能不能理解用户的工作痛点，能不能把任务规划、日程管理、笔记沉淀和项目跟踪组织到一个清晰界面里，能不能产出一个真正对日常工作有帮助的交付物。

在实际任务任务推进过程中，为了让模型给出更好的效果，我们首先让模型完成第一轮开发，然后进一步让模型自优化第一轮开发的版本，因此我们获得了下面 2x2 个版本的办公平台：

GLM 5.3 Flash

GLM5.3-Flash 第一轮开发版本测试录屏

GLM5.3-Flash 自优化开发版本测试录屏

从第一轮生成结果看，GLM-5.3-Flash 首先搭建了一个“办公管理系统”的基本骨架：左侧导航把工作台、任务、日程、笔记拆成清晰模块，任务页支持状态、优先级、截止日期、筛选、搜索和编辑删除，日程页有日历视图和编辑弹窗，笔记页也提供了标签、编辑/预览切换等基础能力。整体来看，模型对“网页版个人工作台”这个题目的理解落在了把办公对象系统化管理起来，任务是任务、日程是日程、笔记是笔记，每个模块都有相对完整的增删改查入口。

紧接着，自优化版本进一步补充了注册登录、统计卡片、待办提醒、近期日程和最近笔记，同时把产品从“功能分区”向“日常驾驶舱”推进了一步。不过的核心逻辑仍然偏系统完整性：先把一个全栈应用该有的页面和表单补齐，再用统计面板做聚合，离真正替用户规划工作优先级还有一步距离。尤其体现在平台虽然能帮助用户管理任务，却不太能立刻让用户知道“今天最该处理什么”；能够帮助用户查看日程，却没有把日程和待办的优先级联动起来；能够提供笔记记录功能，但笔记更多是独立存档，而不是工作推进过程中的行动项沉淀。

Qwen3.8-Flash 第一轮开发版本测试录屏

Qwen3.8-Flash 自优化开发版本测试录屏

Qwen3.8-Flash

Qwen3.8-Flash 的第一版，给人的第一印象不是功能更复杂，而是更早抓住了个人办公里的轻重缓急。

在任务页中，模型不仅提供状态、优先级、截止日期和编辑弹窗，还加入了智能排序、逾期提示、今天到期、几天后到期等时间语义；页面顶部也放了全局搜索和当天日期。这些细节说明，Qwen3.8-Flash 没有把任务管理简单理解成一张待办清单，而是意识到办公场景里的关键矛盾往往不是有没有任务，而是哪些任务正在逼近，哪些任务应该先处理。

在笔记模块上，Qwen3.8-Flash 也呈现出更强的知识工作取向：标签侧栏、笔记卡片、搜索、Markdown 编辑/预览，以及改进版里的工具栏、分屏预览、表格和代码块渲染，都让笔记不只是一个文本输入框，而更接近知识沉淀和材料整理工具。此外，模型在 UI 设计上也存在失误，“最近笔记”模块中的文本内容明显超出了模块区域且不能自动换行。

自优化后的首页进一步把“当前待完成”和“7 天内到期”放到工作台核心区域，配合任务统计、完成率、近期日程和最近笔记，产品意图更接近一个个人效率中枢。当然，Qwen3.8-Flash 也存在短板：整体布局仍有较多留白，信息密度较低，后端、权限、工程结构等“完整应用”的存在感不如 GLM5.3-Flash 明显。但如果只看“是否理解办公用户的真实痛点”，Qwen3.8-Flash 的设计更像是从用户每天打开工作台后的第一反应出发。

Qwen3.8-Flash 第一轮开发版本

出现文本超出模块范围的设计错误

从更详细的对比细节来看，两个模型最终交出的版本差异更为明显：

在登录页上，GLM 与 Qwen 都补了账户入口，但这并不是办公工作台的核心胜负点，真正的差异发生在登录之后。GLM 的改进版像一个标准 SaaS 系统，先有账户、模块、数据表和统计卡片；Qwen 的改进版则更像个人效率工具，首页打开就是“开始今天的工作”，并把未完成任务、近期日程、笔记和完成率放在第一屏。

两个模型交付版的登陆页面对比截图

两个模型交付版的首页对比截图

紧接着，任务页的差异最能说明模型对办公场景的理解边界，GLM 的任务页符合传统管理系统的设计习惯：筛选、搜索、按截止日期排序、优先级标签、状态标签一应俱全；Qwen 则增加了“智能排序”和更清晰的到期语义，把任务从“可管理对象”进一步变成“需要安排先后顺序的工作流”，这也是实测环节中 Qwen 更像个人效率工作台的原因。

两个模型交付版的任务页面对比截图

日程页也类似，GLM 把日历和当天日程拆成左右结构，信息更克制；Qwen 则把月视图、当天事项、未来 7 天安排放到同一屏，虽然信息密度仍不算特别高，但它尝试把日程从“日期记录”变成“接下来一周的时间占用”。对于办公用户来说，后者更接近日程管理的真实价值：不是知道某天有会，而是提前知道这些安排会怎样影响任务节奏。

两个模型交付版的日程页面对比截图

最后，笔记模块的差异则说明模型有效与无效往往同时出现，Qwen 显然更重视标签、搜索、Markdown、预览和知识沉淀，对应的笔记功能更接近真实办公里的材料整理；不过，页面也暴露出文本溢出、布局约束不足的问题。GLM 的笔记页更简单、稳定，也更像 CRUD 系统里的一个模块。因此，Qwen 在理解笔记为什么重要上更主动，GLM 在把笔记作为系统模块交付上更稳，但两者都还没有真正做到把笔记自动转成任务、把会议纪要沉淀成行动项。

两个模型交付版的笔记页面对比截图

从测试角度来看，两个 Flash 模型都已经具备进入办公 Agent 的基础能力，但它们的强项不在同一个方向。

GLM-5.3-Flash 的能力更像是工程系统搭建能力，能快速把复杂需求拆成页面、模块和数据流，强在编程能力，能给出更好的设计体验；Qwen3.8-Flash 的能力更像是个人工作流组织能力，能更早意识到办公用户关心的是优先级、截止日期、搜索和知识复用，对办公场景的体感把握更好，但是编程能力稍显逊色，多次出现文本溢出问题，同时整体 UI 设计的文字和模块偏小，测试人员的使用体验有所欠缺。

综合来看，GLM-5.3-Flash 交出了一套标准化的个人办公管理系统，结构完整、边界清楚，任务、日程、笔记都有独立页面和明确操作入口，自优化后还补上了登录注册、首页统计和快速新建等典型全栈应用能力。

这种设计路径说明 GLM 擅长先把一个“可运行、可管理、可扩展”的产品框架搭起来，再用仪表盘把各模块聚合到一起，其对办公的理解偏向组织化、流程化和系统化。Qwen3.8-Flash 则更像在做一个面向个人效率的工作台，任务管理更强调优先级、截止日期、逾期状态和智能排序，笔记模块也更接近真实知识工作中的材料整理和复用场景；改进版首页围绕“当前待完成”和“7 天内到期”组织信息，比单纯展示统计数据更贴近用户每天处理工作的节奏。因此，二者的差异体现在把“办公”被理解成什么：GLM 更偏完整系统交付，Qwen 更偏个人工作流设计。

性能分析：一个偏工程系统，一个偏个人工作流

实测结果只是表层，要解释为什么两个模型在 Claude Code 中表现不同，还需要回到官方给出的模型参数、架构和 benchmark。

【注：本文测试调用的是 Qwen3.8-Flash，官方公布的技术报告和完整榜单主要对应 Qwen3.8-Flash-Next，因此，讨论 Qwen 的架构路线和榜单数据时，更准确的理解方式是：用 Qwen3.8-Flash-Next 解释 Qwen3.8-Flash 背后的能力来源，而不是把二者完全等同。】

从参数看，Qwen3.8-Flash 的主模型规模为 125B，推理激活 6B 参数，同时通过 51B N-gram Embedding 和 4B MTP 扩展能力；GLM-5.3-Flash 则包含约 320B 总参数、18B 激活参数。二者都属于 Flash 产品，但前者更强调低激活参数下的长上下文和工具调用，后者更强调大专家池带来的 Agent 能力。此外，需要补充说明：Qwen3.8-Flash 是本文实测模型，Qwen3.8-Flash-Next 是官方开放权重和技术报告对应版本，可以理解为 Qwen3.8-Flash 背后的架构预览与开源参考。

换句话说，Qwen 走的是用更少激活参数承接更多上下文路线，N-gram Embedding 把一部分局部模式和短语级记忆做成更便宜的查表式容量；Gated DeltaNet 与 Qwen Sparse Attention 在长上下文里压低注意力成本，让模型在处理长需求、完整代码库、多轮修改时不至于被上下文长度拖垮。对应到上述测试，Qwen3.8-Flash 生成的任务页更强调智能排序、逾期提醒、今天到期、7 天内到期和全局搜索，这很像一个模型在长需求中持续抓住“办公工作流”的主线：任务不是孤立条目，而是有时间压力和优先级关系的信息流。

GLM 的路线则更像用更大的专家池冲 Agent 上限，再用推理结构把成本压回 Flash 区间，320B 总参数和 18B 激活参数让单次推理调用到的有效容量更大；同时，GLM-5.3-Flash 引入 sparse + linear attention 的混合结构。因此，GLM-5.3-Flash 在实测中更早呈现出完整应用的惯性：登录注册、任务、日程、笔记、统计卡片、快速新建、模块导航都比较规整，像是在先补齐一个全栈办公系统该有的结构。

下面我们再结合官方给出的榜单数据更全面看看模型的能力，尤其看看两家官方各自在强调什么。

首先，GLM-5.3-Flash 在 DeepSWE、NL2Repo、Toolathlon Verified、AutomationBench、Terminal-Bench 2.1 这些 coding / agentic 指标上给出的数字更激进，官方叙事也更直接：以 Flash 成本逼近顶级 coding agent 表现。这刚好解释了为什么 GLM 在实测中更像一个“工程交付型”模型，面对“开发一个完整可运行的个人工作台”时，GLM 优先把前后端、登录、导航、CRUD、统计面板和页面骨架补齐，先保证系统看起来完整、能操作、能继续扩展。

来到 Qwen 侧，可以发现其榜单覆盖面更全，Qwen3.8-Flash-Next 不只给出 DeepSWE、SWE-bench Pro、SWE-bench Multilingual、Toolathlon Verified 这些编码与工具使用指标，也给出了 CoWorkBench、JobBench、Vision2Web、AndroidWorld、RecreationBench 等更贴近“长期任务、办公任务、应用复现、多模态 Agent”的数据。

尤其 CoWorkBench 本身就是 Qwen 用于评估长程办公和生产力 Agent 的内部 benchmark，这和实测任务中 Qwen 更重视“当前待完成”、“7 天内到期”、“最近笔记”、“Markdown 预览”等设计细节形成了呼应：强项不一定是把所有工程模块堆得最满，而是更倾向于把用户每天的工作节奏组织出来。

总结：Flash 正在成为办公 Agent 的主力模型

回到最初的问题：Flash 模型是否已经能理解办公？

从这次实测看，两个模型都能很好理解办公需求并打造一套工作台系统。无论是 GLM-5.3-Flash 交出的标准化办公管理系统，还是 Qwen3.8-Flash 更偏个人效率工作流的设计，两者都没有把题目简单理解成一个静态网页，而是抓住了任务、日程、笔记、Dashboard、搜索、登录、持久化和测试等办公软件的基础构件。

这说明 Flash 模型已经具备进入办公 Agent 场景的基本理解能力：能把自然语言需求拆成模块、页面、数据流和交互入口，并产出一个可运行、可继续迭代的交付物。

再看经济账，这件事的产业意义会更清楚。

具体地，办公场景具有高频、重复、长周期的特点：每天整理任务、生成周报、追踪项目、处理文档、沉淀会议纪要。对用户来说，模型不仅要强，还要便宜、稳定、等待时间可接受；对厂商来说，模型不仅要能跑榜单，还要能在大量真实请求中维持可控毛利，因此，Flash 模型之所以重要，正在于它把“可用能力”和“可规模化调用”放到了一起。

【注：按“输入上下文总量 × 输入单价 + 输出 Token 量 × 输出单价”粗算；为保持三列可比，未按缓存命中价折算，实际账单会受缓存命中、调用平台、促销活动和计费口径影响。】

从这张表来看，在 Flash 模型之间对比，Qwen3.8-Flash 用更少工具调用、更少上下文、更少输出 Token 和更短时间完成了任务，呈现出更轻的执行路径；GLM-5.3-Flash 则调用工具更多、生成代码更多、后端测试更多，换来了更强的工程完整性。把 GLM-5.3 加进来以后，旗舰模型并不一定在每一项经济指标上都“更重”：运行时长短于 GLM-5.3-Flash，工具调用次数也少于 GLM-5.3-Flash，但 LLM 调用次数更多，输入上下文总量也高于两个 Flash 模型。

这意味着，单 token 价格、模型级别和最终任务成本之间并不是线性关系。

按官方公开单价估算，Qwen3.8-Flash 本次任务约 6.26 元，GLM-5.3-Flash 约 7.72 元，而 GLM-5.3 约 80.49 元。这个差距说明，Flash 与旗舰之间已经不是“贵一点”和“便宜一点”的差别，而是能否承接高频办公流的经济模型差别。

与此同时，GLM-5.3 的平均上下文和最大上下文都低于 GLM-5.3-Flash，说明其在单次上下文控制上更收敛；但 123 次 LLM 调用又意味着它把任务拆得更细，整体调用频次更高。对企业和开发者来说，未来选择模型不会只看官网单价，也不会只看模型是否旗舰，而会看一个完整公式：任务完成率 × 端到端耗时 × token 消耗 × 重试次数 × 工具链稳定性。

因此，通过这次我们可以发现 Flash 模型的定位正在被重新定义：过去，Flash 往往意味着低价、快速、轻任务，适合摘要、改写、分类和简单问答；但这次，两款同日发布的 Flash 模型都已经把 1M context、多模态、工具调用、Coding Agent、Office Agent 写进核心能力，并在实测中完成了一个包含前后端、数据持久化、页面交互和测试的办公应用。

同时，LLM 产业化正在进入一个更务实的阶段：未来真正支撑大多数应用的，未必总是最强旗舰模型，而是性价比更高、调用频率更高、服务成本更可控的 Flash 模型。旗舰模型负责处理少数高难、低频、强推理任务，Flash 模型则承接用户 80% 的真实工作流（二八原则）。当更轻量的参数激活量已经可以覆盖日常办公、代码辅助和交付物生成，模型厂商竞争的重点就会从“谁的模型更大”，转向“谁能把能力标准化、接口标准化、成本标准化，并稳定嵌入产业工作流”。

这也是本文最后想强调的判断：Qwen3.8-Flash 与 GLM-5.3-Flash 的同日发布，不只是两家国产模型团队在 Flash 产品线上的一次正面交锋，更像是大模型产业标准化道路的一次预演。办公场景里，用户最终不关心模型参数有多漂亮，而关心它能不能理解任务、控制成本、稳定交付；厂商最终也不只是在卖一个模型，而是在卖一套可被反复调用、可被嵌入业务、可被财务部门算清楚账的生产力基础设施，Flash 模型的主流化，正在从这里开始。

▼

推荐阅读

▼

我们拆了 1.1 万个 DeepSeek Harness 插件，发现官方几乎没有建立插件治理机制

2026-08-28

唐杰说后训练是关键，GLM 5.3 实测却被自己的安全策略卡住了

2026-08-22

雷峰网原创文章，未经授权禁止转载。详情见转载须知。

从 Codex Harness 开源，看 AI 公司的护城河是什么？

李娜 — Wed, 30 Sep 2026 08:24:00 GMT

导语：技术领先非护城河，开源意在沉淀转换成本、规模与反馈。

8 月 19 日，OpenAI 正式开源了 Codex Harness。这家公司名字里的 Open，久违地兑现了一次。（雷峰网(公众号：雷峰网)）

长期深耕 Agent Harness 的开发者群体对该消息的普遍反馈是“振奋”。因为过去只有少数顶尖 Agent 产品掌握的 Harness，现在终于开始向更多开发者和企业开放了。

随着 Codex 等最佳实践的开源，Harness 正在经历从“私产”到“公器”的转化，其本身的稀缺性，正在快速下降。这也是 OpenAI 为什么终于“Open”了一回的重要原因。

当顶尖 Agent 产品积累的 Harness 方法论不断扩散，Codex 这样的最佳实践也正式开源，开发者便可以站在现成的 Agent Runtime 上继续开发。过去许多公司依靠 Harness Engineering 建立起来的技术领先，也会更快被行业学习和复制。

那究竟什么是 Harness？

对于不太熟悉这个领域的朋友，可以用一个极简公式来理解这个概念：

Agent = Model + Harness

如果说模型是输出原始推力的“发动机”，那么 Harness 就是将这种不确定推力转化为确定性输出的“传动系统”和“调压站”，负责把智能组织成可以持续完成交付任务的系统，其中包括管理模型的上下文、调用工具、保存状态、控制权限，也要在任务失败后继续推进。

在Chatbot时代，模型原本只能一轮一轮地回复，顶多起到一个解答问题，提供情绪价值的作用。但是在经过 Harness 的组织后，我们才能开始利用模型的智能去实际交付产出。

Harness 的核心价值不再是智能，而是“治理”。当我们评价一个 Agent 能力时，只看模型是不够的，同一个模型放进不同套 Harness，最终表现可能相差很大。

从去年 Claude Code，再到今年爆火的 Codex，已经有许多 Agent 产品证明了一套优秀的 Harness 系统加上顶级模型是能够释放巨大的商业潜力。

现在，开发者每月排着队为这类产品支付几十甚至几百美元，而付费用户也不再局限于开发者，越来越多的白领、知识工作者和企业主开始为 Agent 产品买单。

市场中已经出现了极端的商业案例：有小企业主为某款 Agent 产品支付了单周近 10 万元的费用。他们之所以愿意支付这么高的费用，是因为这项Agent切实帮助他获得了远超成本的收入。

刚刚是从收益角度衡量Harness的机制，从成本测出发，一套更设计的 Harness 还可能在任务质量接近的情况下，降低 Token 消耗，改善投入产出比。最近，Databricks 最近在自己的数百万行代码库上做了一次内部测试(https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase)。

测试任务来自公司内工程师真实完成过的工作，覆盖 Python、Go、TypeScript 和 Scala 等语言，比常见的公开 Benchmark 更接近大型公司的日常开发流程。

其中一组实验直观展示了 Harness 对成本的影响。Databricks 在相同模型、相同推理强度下，分别用 Claude Code、Codex 和更轻量的 Pi 三种 Harness 完成同一任务。结果显示，三者完成质量接近，但单任务成本最高相差两倍以上。原因在于 Pi 每轮送入模型的上下文量约为 Claude Code 或 Codex 的三分之一，所需轮次也更少。

这些产品与测试都说明，Harness 会直接影响 Agent 的体验、成本和商业价值。按常理，这样的技术理应成为公司的最核心资产，并且对外严防死守。但是，在过去两周发生的事情却恰好相反，顶尖模型厂商开始主动开源自己的 Harness。

八月中旬，DeepSeek 率先开放 DeepSeek Harness；不到一周，OpenAI 也开放了支撑 Codex App、CLI 和 IDE Extension 的 Agent Harness。

比如，Cisco 将 Codex 引入复杂的企业工程环境。Thrive Holdings 则与 OpenAI 合作，把 Codex 应用到税务工作流中，参与处理了 7000 份报税材料，覆盖 30 多家会计师事务所，帮助从业者将准备的工作时间缩短了约三分之一。

同一套 Agent 执行能力，已经开始进入代码托管平台、IDE、企业工程环境和专业服务流程。对于仍在从头搭建通用 Agent Harness 的创业公司，这会直接改变竞争的格局。

Codex 负责人 Tibo 的态度更耐人寻味。他甚至判断，再过两三个月，今天这套Codex Harness 也会显得原始。

图：Tibo 演示把 GPT-5.6 Sol

接入 Claude Code Harness。

Tibo 判断今天的 Codex Harness 会在两三个月后显得原始

以上一系列信号指向一个问题：

技术领先，能成为一家公司的护城河吗？

为了评估 Codex Harness 的真实价值，需要从“功能解剖”与“实战演练”两个维度切入：

先搞清楚 OpenAI 这次Codex Harness 开源到底开放了什么？
再用这套开源 Harness 实际做一个真实产品demo。

只有通过深度的实战测评，才能更具体地理解 OpenAI 为什么选择在这个时间点开源 Codex Harness，以及它想通过这次开源完成怎样的战略转换。

OpenAI 为什么把 Codex Harness 开源了？

OpenAI 在官方文章里用一句话概括了这次开放的核心：

The reusable part is the agent loop.

这句话也划清了本次开源的边界。OpenAI 开放的是 Codex 用来持续执行任务的 Agent Loop，也就是支撑 Codex App、CLI 和 IDE Extension 运行的那一层 Harness。

开发者现在可以查看它的实现，也可以通过 SDK 和 App Server，把任务管理、工具调用、事件回传和人工审批等能力接进自己的产品。Codex 使用的模型仍然由 OpenAI 提供，背后的云端服务也没有随代码仓库一起开放。开发者拿到的是模型之外那套可以重复使用的 Agent Runtime。

技术拆解显示，在众多的接入入口中，其中最值得关注的是 Codex App Server。

你可以把 App Server 理解成 Codex 与外部产品之间的连接层。过去，用户主要在 Codex 自己的界面里发起任务；现在，开发者可以把同样的执行能力接进自己的产品：启动任务、让 Codex 持续执行、接收输出和工具调用，也可以在中途暂停，等待用户确认后继续。

在 App Server 里，一项持续进行的任务叫 Thread，其中每一轮具体执行叫 Turn。比如，“审核完这篇文章并生成修改稿” 可以放在同一条 Thread 里：第一轮 Turn 只读检查文章，用户确认以后，下一轮 Turn 再生成修改稿。

对开发者来说，他们再也不必把业务流程迁进一个通用聊天窗口。团队可以保留已有的控制台、编辑器、任务队列和审批流程，再决定 Agent 能读取哪些数据、调用哪些工具、在哪里运行，以及什么操作必须经过人工确认。

OpenAI 官方展示的物流控制台 Relay，就是开源 Harness 如何进入现有业务系统的一个具体案例。工作人员面对的仍然是熟悉的订单、运输状态和异常处理按钮。Codex 在后台分析问题并调用应用提供的 MCP 工具，涉及生产数据写入时，再把决定交给工作人员。

20 分钟做出一个 Agent：

Harness 开源到底降低了什么门槛？

图：OpenAI Codex 的公开仓库。Codex CLI、核心 Runtime、SDK 和文档都在同一个项目中持续维护。

随着 Codex Harness 的开源，一个行业核心假设亟待验证：开发者能否直接利用这套 Harness，从一项真实的业务需求出发，快速做出一个可以交给用户使用的 Agent 产品？

实验选择从一个长期困扰自己的需求开始，做一套文章审核工作台。

在内容生产的典型场景中，Agent 承担着核对事实、纠正技术定义及区分立场等高频需求。在实测中，通过加载定制化的审核 Skill，这一流程在 Codex 体系下表现得非常丝滑顺手。

可一旦想把这项能力交给其他内容创作者，事情就麻烦了。大部分用户不想研究 Prompt，也不了解 Skill 和底层接口。大部分用户需要的是一套简单操作流程，选中一篇文章，点击开始审核，看见系统正在做什么，读完审核结论，再决定是否生成修改稿。

过去要做这样一款产品，团队通常需要先用 LangGraph、Agno 或 Pi 等框架搭建 Agent 的运行系统。模型怎样读取长文，什么时候调用搜索和本地工具，多轮任务怎样保持状态，执行过程如何回传前端，文件写入如何等待审批，任务中断后怎样继续 —— 这些通用能力都需要逐项实现、调试和优化。等到整套系统稳定下来，产研团队才有精力处理真正影响业务价值的问题。

依托开源的 Codex Harness，开发者的重心得以发生根本性偏移：从繁琐的底层工程重构，转向对产品核心价值（如审核标准、交互边界）的定义。

以下是验证该逻辑的产品需求 Prompt 范例：

基于https://github.com/openai/codex Codex App Server构建一个面向内容创作者的文章审核台。用户可以选择一篇待发布文章，启动 AI 审核，并看到完整的执行轨迹。第一轮审核必须保持只读。界面需要展示当前任务状态、审核结论、工具调用与执行事件、文件修改数量，以及写入前的人工审批按钮。只有用户明确批准以后，Codex 才能另存一份修改稿，不能覆盖原文。

图：这次构建从产品需求开始，描述了目标用户、核心流程、需要展示的信息和写入权限，没有重新设计一套 Agent Loop。

Codex Harness 已经解决了任务怎样持续执行、工具怎样被调用、权限怎样被控制这些通用问题，剩下真正需要开发者设计的，反而都是更靠近业务的部分。

比如，Codex 底层会产生大量命令、搜索和文件事件，但普通创作者不需要理解这些东西。更重要的是，在实际场景中，开发者还需要告诉 Codex，什么才算真正审核好一篇文章。这部分工作的难度和工作量不亚于开发一套稳定的 Harness，但它对最终产品价值的贡献更加直接。开源的 Codex Harness 省掉了重复搭建通用执行系统的时间。开发者可以把省下来的精力直接用于打磨审核标准、信息呈现和权限边界 —— 这些才是真正决定产品价值的部分。

不到 20 分钟，这个文章审核工作台 Demo 就端到端跑通了。

最终 Demo 的页面很简单，包括文章路径、“开始审核”按钮、审核结论，以及一条展示执行过程的事件流。页面通过本地 WebSocket 代理连接 codex app-server。用户点击“开始审核”后，系统启动第一轮 Turn，只读取文章和资料，不修改任何文件。

图：页面右上角显示 Harness 已连接。此时还没有启动任务，Observer 中的事件、工具调用和文件修改都为 0。

图：左侧持续输出审核判断，右侧展示已经发生的工具调用。第一轮保持只读，因此文件修改数量始终为 0。

实测反馈显示，即便是不具备 Prompt 经验的非技术人员，也能在无需指导的情况下完成任务。这证明了 Harness 开源的核心价值：将 AI 能力从“专家级配置”降维为“普通用户交互”。

开发者不再需要从零构建复杂的 Agent 循环，只需在成熟的执行层之上叠加一层面向场景的应用界面。

审核完成以后，真正写入文件以前，产品把决定交还给用户

这会给新一批 Agent 创业公司和企业内部开发者带来很大的价值。创业公司可以用更低的工程成本验证垂直场景，企业开发者也能更快地把 Agent 接进客服、财务、法务、内容和研发等现有流程。现在，他们不需要推翻原来的产品和业务边界，只需要接入 Codex 的任务执行能力，再根据具体场景设计它的工作方式。

但门槛降低从来都有两面。当越来越多开发者可以直接使用一套成熟的 Harness，原本需要长期积累的工程能力，也会迅速变成一种随手可得的基础设施。

回头文章开头的问题，如果 Harness 不再稀缺，竞争优势会转移到哪里？

技术领先为什么还不是护城河？

过去一年大模型行业已经反复证明，模型能力的领先窗口非常短。新的模型发布以后，Benchmark 会被刷新，推理成本会下降，蒸馏、合成数据和训练方法会迅速扩散，原本只有头部闭源模型才能完成的任务，会逐渐进入更便宜的模型，甚至进入开放权重模型的能力射程范围。

今天，Claude 模型在 Coding 和 Agent 场景里依然处于最强梯队，但领先本身并不等于长期壁垒。Kimi、GLM、DeepSeek 等厂商都在持续追赶，并且开源模型权重。虽然，和 Anthropic SOTA 级别的模型之间当然还存在差距。判断这项领先是否具备长期价值，还要看差距能够维持多久，以及竞争者需要付出多大成本才能追上。

最近的模型竞争里，能力与成本之间的关系越来越重要。当模型能力接近以后，谁能用更低的推理成本和更高的效率，把相近的能力交付给更多用户，就会获得更大的市场空间。

现在来看，Harness 也在经历同样的价值稀释过程。

一年前，一套优秀的 Agent Harness 还需要大量内部工程经验及和烧过大量的TOKEN才能总结沉淀下来。今天，OpenAI 已经可以把其中的通用能力直接开放给开发者。模型也一样，今天只有顶尖模型才能完成的任务，可能在下一代模型发布后迅速变成标准能力。

但如果 Anthropic 能利用这段技术领先所争取到的时间窗口，赢得更多开发者的认可，让 Claude Code 进入越来越多大型组织的研发流程，企业也开始围绕 Claude 建立权限、数据、评估体系和使用习惯，甚至参与制定行业规范，并进一步影响有利于自身发展的政策，那么情况就大大不同了。这些优势虽然形成得更慢，却更难被竞争者在下一次模型发布时一并“蒸馏”。

讨论到这里，技术领先的价值已经不用赘述了。对于企业更难回答的问题是，一家公司怎样把阶段性的技术领先，变成竞争者长期难以复制的优势。

在投资领域，人们通常用 “护城河” 描述这种能够长期抵挡竞争的能力。要判断技术领先能不能变成长期优势，可以借用 Hamilton Helmer的7 Powers 框架。Helmer 给出的判断标准其实很简单：一项优势必须同时具有Benefit和Barrier。

7 Powers：什么样的技术优势才不会被复制？

7 Powers 是投资人、战略学者 Hamilton Helmer 提出的一套竞争战略框架，整套理论试图回答一个问题：

面对同样聪明、行动迅速，而且全力竞争的对手，一家公司为什么还能长期获得显著的超额回报？

Hamilton Helmer 的《7 Powers》

Helmer 把支撑这种结果的竞争结构称为 Power，也可以理解为能够长期存在的护城河。一项优势能被最后认定为 Power，必须同时通过两项检验：

Benefit，收益。它确实能让公司多赚钱，比如提高价格、降低成本、加快增长，或者让客户留得更久。
Barrier，壁垒。对手即使知道你在做什么，也很难复制；或者复制时需要付出高昂代价。

能创造收益却容易复制，领先会随着竞争者追上而消失。难以复制却不能改善经济结果，守住它也没有太大意义。Benefit 和 Barrier 同时成立，优势才有机会变成 Power。

Helmer 在书中总结了七种反复出现的 Power：

这七种 Power 的来源不同，判断标准却一致，都必须同时具备 Benefit 和 Barrier。

用这套标准回看本文的问题，技术领先本身算不算一种 Power？

在 AI 行业里，几个月的领先就足以改变竞争格局。模型效果更好，可以更早吸引开发者和企业客户；Harness 更成熟，也可以让模型承担更长、更复杂的任务。从 Benefit 看，技术领先的带来的价值是巨大的。

可问题在于，Benefit 只是 Power 的一个条件。

如果这种领先会随着模型迭代、人才流动和工程经验扩散被竞争者快速追上，那么它带来的收益虽然真实，却未必拥有足够强的 Barrier。

这种领先更应被视为一种阶段性红利，也是一股势能。但这种势能会衰减——论文会传播，人才会流动，工程实现会被复刻，代码也可能被主动开源。

真正重要的是，公司能不能利用这段领先窗口，把暂时的技术优势进一步沉淀成更难复制的 Power。

技术领先只有完成这一步转换，才真正开始具有护城河的意义。

伟大的科技公司往往同时运行两个循环：一边把上一轮技术领先沉淀成 Power，一边继续创造下一轮技术领先。前者提供长期优势，后者不断创造新的时间窗口，而已经形成的 Power 又反过来为下一轮研发提供资金、数据、人才和应用场景。

有了这套判断标准，再看 Codex Harness 开源，如果暂时技术领先只提供了一段势能，OpenAI 接下来真正需要证明的就是这段势能能否继续沉淀为更持久的 Power。

OpenAI 放弃 Harness 的稀缺性

想换来什么？

OpenAI 开源 Codex Harness，直接降低了 Harness 实现本身的稀缺性。

前文提到的 Databricks 测试已经说明，外部团队可以使用更轻量的 Harness，在部分任务上以更低成本达到接近的完成质量。竞争者并不需要 1:1 复刻 Codex。只要在特定任务里做到质量接近、成本更低，就足以削弱 Codex Harness 的技术稀缺性。

但开源也让 Codex 获得了更大的分发范围。

在前面的实测里，几乎没有重新实现 Agent 的执行系统。Codex App Server 已经提供了 Thread、Turn、工具调用、事件回传和人工审批等基础能力。只需要通过 WebSocket 接收执行事件，再围绕文章审核设计界面、审核标准和权限边界，不到 20 分钟就跑通了一个可以交给普通用户试用的产品。

这件事对开发者的直接价值是降低构建 Agent 产品的工程门槛。对 OpenAI 来说，价值则在于让 Codex 从一个面向最终用户的产品，进一步变成其他产品可以复用的执行层。

按照 7 Powers 的标准，OpenAI 接下来需要证明两件事：这种开放能够带来什么 Benefit，以及它能否进一步形成竞争者难以复制的 Barrier。

首先是转换成本。

在 Demo 里，接入 Codex Harness 还很轻，只需要处理文章路径、事件流和写入审批。但放进真实企业以后，接入对象会复杂得多。Agent 需要连接企业的代码库、内部工具、权限体系、评估集、部署环境和审批流程。团队还要决定什么数据可以读取，哪些操作必须经过人工确认，任务失败后怎样恢复，以及执行结果如何进入原来的业务系统。

这些工作最终会沉淀为一套围绕 Codex 建立的配置、评估标准、历史任务和组织流程。

当企业更换底层 Harness 时，需要迁移的就不只是一套代码接口，还包括已经运行在上面的工作方式。Codex Harness 接入得越深，更换系统的成本就越高。开源降低了第一次接入的门槛，深入使用则可能逐渐形成转换成本。

第二层是规模经济。

Codex Harness 虽然开放，但它和底层模型之间仍然存在大量协同。模型怎样理解工具描述、怎样压缩上下文、什么时候继续执行、什么时候请求审批，都需要 Harness 与模型共同优化。

我在 Demo 中看到的 Thread、Turn 和事件流，表面上是产品接口，背后每一次审核、搜索和工具调用都会产生模型推理需求。当更多开发者直接基于 Codex App Server 构建产品，OpenAI 获得的也不只有更多 Harness 用户，还可能包括更多模型调用和更丰富的真实任务。

如果规模扩大能够提高推理基础设施的利用率，并帮助 OpenAI 持续优化模型与 Harness 的配合方式，开放 Harness 就可能进一步形成模型层面的规模经济。当然，这条链路能否成立，最终仍然要看新增调用能否真正转化为更低的单位成本。

第三层是独占资源。

前面的文章审核 Demo 会产生一条完整的任务轨迹：Codex 读取了什么资料，调用了哪些工具，在哪一步请求人工审批，用户是否接受审核结论，以及修改稿最后有没有被采用。

类似的轨迹如果出现在代码、财务、法务和客服等专业场景中，其中会包含大量公开语料里很少出现的信息：任务为什么失败，专家怎样纠正，什么结果可以被业务接受，以及人在什么节点选择接管 Agent。

在合规和用户授权的前提下，如果这些反馈能够进入 OpenAI 的评估和模型优化体系，它们就可能成为公开语料与合成数据之外的一类稀缺资源。外部竞争者即使拿到同样的 Harness 代码，也很难立刻获得相同规模和质量的真实任务反馈。

转换成本、规模经济和独占资源都不会因为开源自然而然地出现。开源 Codex Harness 完成的第一步，是让更多开发者能够低成本地把 Codex 接入自己的产品。OpenAI 还需要让这些产品进入真实业务、产生持续使用，并把新增使用沉淀为客户流程、模型规模和高质量反馈。

如果这条路径能够跑通，OpenAI 放弃的是正在快速扩散的 Harness 稀缺性，获得的则可能是更广的分发，以及更难被下一轮技术迭代抹平的 Power。

所以，再回答本文最初的问题：

技术领先当然重要，但其本身还不足以构成护城河。

技术领先更像一种势能，为公司争取用户、收入、数据和时间窗口。真正决定长期竞争力的，是企业能否在这段领先消失以前，把这些红利沉淀成竞争者难以复制的 Power。

技术会扩散，代码会开源，模型会被追上。

真正的护城河，不是你曾经领先过，而是领先消失以后，你还剩下什么。

▼

推荐阅读

▼

全网最硬核 OpenClaw 2.0 实测：从 ToC 到 ToB 的试探，Agent 网关能重塑工作流边界吗？

2026-09-05

我们拆了 1.1 万个 DeepSeek Harness 插件，发现官方几乎没有建立插件治理机制

2026-08-28

雷峰网原创文章，未经授权禁止转载。详情见转载须知。

全网最硬核 OpenClaw 2.0 实测：从 ToC 到 ToB 的试探，Agent 网关能重塑工作流边界吗？

李娜 — Wed, 30 Sep 2026 08:22:00 GMT

导语：OpenClaw 2.0 让 Agent 更像一个可复盘、可协作的工作系统，但依然不是普通用户能轻松上车的工具。(雷峰网)

8 月 31 日，OpenClaw 2.0 正式发布（版本号： v2026.8.1 ），933 位贡献者、569 位首次贡献者、16,962 个 PR 提交。这组数字让它成为近期最受关注的开源 Agent 更新之一。（雷峰网(公众号：雷峰网)）

在过去 230 天里，OpenClaw 曾发布 106 个版本，但在 2.0 到来前已经有近 7 周没有更新了。因此，这一次 OpenClaw 不是给 Agent 多补几个工具，而是把安装、浏览器、云会话、记忆管理、插件、安全、多人协作和恢复能力几乎重新梳理了一遍。

因此，一个急需回答的问题是：OpenClaw 2.0 到底是一次声量很大的版本升级，还是把个人 AI Agent 从一个能干活的工具，往可长期运行、可协作、可审计的系统推了一步？为回答这个问题，我们选择 OpenClaw v2026.7.1-2 （1.x）和官方标注为 2.0 的 v2026.8.1 的新版本进行对比。

我们用同一道复杂长任务，对比两个版本的上手门槛、任务推进和交付表现。

OpenClaw v2026.8.1 (2.0) 配置界面增加“询问 OpenClaw”

OpenClaw 2.0 优化了什么？

8 月 31 日，官方将发布的 v2026.8.1 版本称为“自托管 AI 网关”，核心强调把 Discord、Google Chat、iMessage、Matrix、Microsoft Teams、Signal、Slack、Telegram、WhatsApp、Zalo、WebChat 等消息入口和 AI 编程助手、浏览器、终端、本地/远端机器、插件、记忆系统连在一起。因此，2.0 想做的是：模型负责思考，工具负责执行，网关负责把消息入口、文件系统、远端机器、长期记忆、权限审批和团队协作组织进同一个工作流。

但从用户体验看，真正关键的不是功能清单有多长，而是三条主线：

上手：配置重新组织，但工程门槛还在

对比 v2026.7.1-2，2.0 把很多复杂度散落在命令行、配置文件、模型服务商、插件和渠道连接里，2.0 把这些步骤往更结构化的首次引导里收。实测中，新版启动后会主动检查本机已有的 AI 工具和模型配置，并把 OpenAI、OpenRouter、xAI、Google、Anthropic 等模型入口放进初始化流程。而这些，对第一次接触 OpenClaw 的用户来说很重要。

2.0 版本加载本地 AI 工具集成到平台（左侧面板展示了本机的 CLAUDE CODE 工具）

长任务：从会话变成有状态的任务

2.0 强化了历史会话搜索、对话分支、持续进度卡片、任务面板、主动记忆等能力，共同解决 Agent 能不能记住一件还没做完工作的问题，而不是每次都像第一次见到用户。

协作和安全边界变得更显性

通过云会话、共享会话、团队角色、私密凭证请求、共享凭证库、权限模式、插件安全审计等功能一起来解决另一个问题：当 Agent 开始接入远端机器、消息渠道、浏览器、插件、团队成员和各种凭证时，谁能看见什么，谁能操作什么，出问题后又怎么追溯？

同时，官方安全文档也强调，一个网关就是一个信任边界，更适合单人或互相信任的小团队，而不是让互不信任的人共享同一套网关。这说明尽管 OpenClaw 开始具备协作能力，但面对 ToB 场景暂时还不能用于企业级多租户的协作应用。

具体地，我们进一步把 v2026.7.1-2 和 v2026.8.1 (2.0) 放在一起来直观对比这次升级的重点：

通过表格可以发现，2.0 的核心变化是把 OpenClaw 从一个可运行的个人 Agent 往一个能长期托管任务的工作系统推了一步。

实战测试：

同一道长任务，2.0到底改变了什么？

尽管 2.0 看起来有了极大的改进，但有用户愿意选择它才是关键，因此我们选择 v2026.7.1-2 和 v2026.8.1 (2.0) 两个连续的版本进行对比测试。

具体地，我们在同一台服务器上分别创建独立的全新 Ubuntu 容器（OP1 和 OP2）作为两个连续 OpenClaw 版本的测试环境，并分别安装和配置了 OpenClaw，在任务运行环节都使用智谱发布的 GLM 5.3 模型作为基座。

OP1 用于部署 OpenClaw v2026.7.1-2 的测试环境信息

OP2 用于部署 OpenClaw v2026.8.1 的测试环境信息

先说安装，2.0 的确比旧版更重视新手引导，但还没有把 OpenClaw 变成传统意义上的“下载、双击、下一步”产品。

官方文档给出的主路径仍然是命令行安装：macOS / Linux 通过一条脚本命令启动安装，Windows 通过 PowerShell 完成，这对开发者来说不算门槛，但对普通用户来说，仍然需要理解终端、Node 环境、安装脚本、端口和权限这些基础概念。

同时，OpenClaw 是自托管网关，天然要和本机环境、模型服务、消息渠道、浏览器、工作目录打交道，所以安装成功并不等于马上能顺滑使用，2.0 降低的是配置过程中的迷路感，而不是彻底消除工程门槛。

官方安装教程页截图

在本次测试中，我们设计了一个开放式但验收标准明确的综合任务，把“信息检索 → 来源判断 → 多源交叉验证 → 信息组织 → 面向领导的汇报写作 → 数据可视化 → Web 开发”串成一个完整任务。简化版的测试题目如下：

请调研 OpenClaw 2.0 的全部重要公开信息，包括官方公告、GitHub、开发者社区、媒体报道，以及行业大佬和关键人物的公开发言。重点梳理：OpenClaw 2.0 是什么、什么时候发布；

- 相比上一版本有哪些核心变化；

- 最重要的新功能和技术特点；

- 官方、社区和行业人士分别如何评价；

- 当前有哪些争议、问题和风险；

- 与主流 Agent 产品相比有什么优势和差异；

- 它对 AI Agent 行业可能产生什么影响。请优先使用一手来源，对重要信息进行交叉验证，并保留原始链接；无法确认的信息不要编造。

完成调研后，整理一份适合向领导汇报的总结材料，提炼核心结论和是否值得关注/跟进的建议。

最后，将调研结果制作成一个可直接运行的可视化网页，以专业的 AI 科技情报 Dashboard 风格呈现，至少包含核心结论、版本变化、时间线、关键人物观点、社区反馈、竞品对比、风险分析和信息来源，并合理使用图表或其他可视化方式展示信息。

请直接完成调研、总结和网站制作，不要只提供执行方案。

这道题的难度在于我们把一个真实打工人遇到的完整工作流压进了同一轮任务里：先要从官方公告、GitHub、媒体报道和社区讨论中找信息，然后要区分一手事实、二手转述和无法确认的说法，接着还要把散乱材料整理成领导能快速判断的汇报，最后再做成可运行的可视化网页。

这样的设计对 OpenClaw 这类 Agent 是合理的，这个题目核心用来考察 Agent 的长期任务、工具调用、浏览器、文件系统、进度追踪和可交付物组织能力，通过把信息检索、事实校验、文档生成、网页交付和任务复盘放在一起，用来测试 OpenClaw 到底是一个会聊天的工具，还是一个能接住复杂任务的 Agent 工作台。

下面一起来看看两个版本 OpenClaw 的任务执行表现：

v2026.7.1-2：更像一个工程工作台

从界面上看，v2026.7.1-2 具备比较完整的工作台形态：可以创建会话、选择模型、切换权限模式、查看任务状态，也能在侧栏里看到工作区文件。对于熟悉命令行和项目目录的用户，v2026.7.1-2 可以支撑较复杂的任务。

OpenClaw v2026.7.1-2 的主界面截图

同时，v2026.7.1-2 的问题也很直观：界面能展示很多信息，却更像把底层配置直接摊给用户。主界面顶部提示版本更新，底部看到模型和思考强度，左侧是会话入口；设置页里集中放着模型、通信渠道、安全、浏览器、工具权限、MCP、工作区、日志等模块。对工程用户来说，这种透明度是优点；但对普通用户来说，它也意味着每一步都要理解自己在调什么。1.x 版 OpenClaw 能做事，但更是需要用户自己掌舵的工程控制台。

OpenClaw v2026.7.1-2 的设置界面截图

从任务完成情况来看，整体很完整：研究报告、检索日志、还有数据分析、可运行网页目录和多张网页截图，v2026.7.1-2 报告的结果结果包括 50 个信息源、27 个时间线事件、32 条人物/社区观点、13 个功能模块、17 个对比维度、5 组竞品矩阵，以及 9 张可视化截图。从执行角度看，v2026.7.1-2 能把开放式的调研题拆成搜索、筛选、结构化、报告、网页和截图几个步骤，覆盖多个内容编辑和行业分析工作的基本链路。

任务跑起来之后，这种“工程工作台”气质会更明显，如下图所示，v2026.7.1-2 一边显示综合调研任务正文，一边在右侧展示工作区，下面还能看到模型状态和任务进度，能把任务、文件、会话和执行状态放在同一个页面里，这是 1.x 版已具备的能力。

v2026.7.1-2 任务执行截图

v2026.8.1：产物没有一味贪多，证据边界更清楚

到了 v2026.8.1（2.0），变化首先体现在任务完成后的交代方式上，如下截图里的进度卡片不是简单告诉用户“完成了”，而是像 Codex、Claude Code、Zcode 等 Agent 一样把任务拆成了多个步骤：前提校验、官方信源调研、社区与媒体调研、竞品和时间线梳理、报告生成、数据与网页拆分、可视化网站验证。

2.0 还直接写出产物路径和验证方式，例如打开 html 文件或进入 web 目录运行服务。因此，对长任务来说，用户可以沿着清单去复查资料、网页、截图和原始记录。

当然，这并不意味着 OpenClaw 2.0 已经形成了不可替代的产品壁垒，更准确地说，OpenClaw 正在向其他 Agent 产品的交互方式靠拢：把任务拆开、把进度摊开、把产物列清楚。

v2026.8.1 任务执行截图

然后，一起来看看模型交出的“答案”：

从最终网页看，两个版本都完成了可视化交付，但风格差异很明显。v2026.7.1-2 版页面的信息密度更高，首页直接放出 GitHub Stars、贡献者、PR、首次贡献者、消息渠道、HN 讨论等多个指标，还用图表呈现 star 增长和讨论热度，整体像一份资料铺得很开的情报看板。新版页面则更强调结论先行：顶部保留关键数字，但很快进入执行摘要、热度周期和八个核心问题，把“是否值得关注”、“应该怎么跟进”、“哪些地方有风险”放到更显眼的位置。前者更像研究员交出的全量资料包，后者更像给管理者看的判断材料。

v2026.7.1-2 可视化页面首页

v2026.8.1 可视化总览

最后，对比两个版本的后台执行统计数据，揭开底层运行逻辑，完整的统计信息如下图所示：

这组后台数据，比界面截图更能说明 2.0 的真实变化：

首先，2.0 并没有在总耗时上拉开差距，1.x 版任务耗时 103.3 分钟，2.0 版为 106.1 分钟，基本持平。但 2.0 版的执行方式明显变了：1.x 版用了 74 次 LLM 请求，2.0 只用了 46 次，请求次数减少 38%；工具调用结果也从 100 次降到 65 次，减少 35%。这说明 2.0 版不是简单少做了事，而是把更多上下文和工具结果合并到更少轮次里处理。

代价也很清楚，2.0 版输入 tokens 从 369,251 增加到 516,897，平均单次请求输入从约 4,990 提高到约 11,237，几乎是1.x 版的 2.25 倍；输出 tokens 和推理 tokens 也都有增加。这说明 2.0 的内置指令更长，执行方式更像“大步少轮”：每次请求携带更多上下文、做更重的判断，再减少来回切换和工具调用。这种变化对复杂任务有利，降低了碎片化决策和中途丢上下文的风险；但如果按实际计费折算，它不一定更省。

最值得注意的是上下文压缩，1.x 版在任务中触发了 1 次 138,781 tokens 的压缩，这意味着早期细节会被摘要替代，存在信息损失风险；2.0 版全程没有触发压缩，却仍然完成了更长报告和网页交付。这与 2.0 强调的状态工程、SQLite 存储和上下文管理方向相吻合。

结合界面和产物看，2.0 的进步不在于把任务跑得更快，而在于让长任务更少被打断、更少依赖人工催促，也更容易被复盘。

OpenClaw 2.0 在进步，但依然不好上手

这次对比之后，OpenClaw 2.0 的定位反而更清楚了，一个以消息入口为中心、自托管、模型中立的 Agent 网关，更适合希望把 AI Agent 接进消息工具、浏览器、终端、远端机器、长期记忆和团队协作流程的人。

相比上一个版本 v2026.7.1-2，v2026.8.1 的进步是真实存在的，把新手引导、任务面板、主机状态、产物清单、信源分级和网页交付都做得更清楚，让一次长任务更像可以被托管和复盘的工作流。从后台数据看，新版减少了 LLM 请求次数和工具调用次数，没有触发上下文压缩，说明它确实在用更集中的方式处理长任务，而不是只换了一层界面。

但 2.0 的门槛也同样真实，安装仍然需要命令行，Ubuntu 用户仍然要处理 Node、npm、安装脚本和权限配置；云会话、共享会话、记忆、凭证管理这些能力也不是打开就自动变好，而是需要用户理解它们的边界。如果选择 Openclaw 作为日常工作的助手，也意味着用户要为系统复杂性付出学习成本。

那么，OpenClaw 还剩下什么？对比 ChatGPT、Claude Code、Kimi Code、Zcode 这类更成熟的交互产品比网页界面更具有亲和力，OpenClaw 并不占优；如果只做单机编码，也不是最省事的选择。最后，真正剩下的就是自托管、模型中立、多入口连接、远端执行、长期会话和团队协作这些系统能力。

因此，OpenClaw 2.0 不适合被简单理解成“更好用的助手”，而是一个面向复杂工作流的 Agent 基础设施，对媒体调研、投研分析、产品研究、技术管理这类需要长期检索、整理、交付和复盘的工作，OpenClaw 已经值得放进受控环境里认真测试。

OpenClaw 2.0 还没有把开源 Agent 的上手门槛真正打掉，但已经把 OpenClaw 从“能干活的工具”，往“能长期托管复杂任务的系统”方向推了一步，虽然没能让所有普通用户立刻上车，却依然引导行业思考如何在小团队内协作使用智能工具。

▼

推荐阅读

▼

我们拆了 1.1 万个 DeepSeek Harness 插件，发现官方几乎没有建立插件治理机制

2026-08-28

唐杰说后训练是关键，GLM 5.3 实测却被自己的安全策略卡住了

2026-08-22

雷峰网原创文章，未经授权禁止转载。详情见转载须知。

5500颗光引擎如何撑起4096卡超节点？华为NPO的故事还没讲完

陈悦琳 — Wed, 30 Sep 2026 08:19:00 GMT

导语：1颗如何共享光源，5500颗如何接入超节点——华为自研光引擎的留白。

华为自研光引擎Hi-ONE的首个落点终于浮出水面——千卡级超节点。

不久前的CIOE上，海思已经展示这颗带宽能力高达7.2T的光引擎，并透露Hi-ONE将以NPO（Near-Packaged Optics，近封装光学）形式进入下一代超节点。华为称，这也是全球首个采用NPO的AI智算超节点。

为什么是NPO？答案藏在电信号的传输路径上。随着芯片侧高速接口速率不断提升，从电芯片到光引擎的这段电连接越长，信号越容易出现衰减和失真，对信号完整性的挑战也越大。

相比传统可插拔光模块还要让高速电信号在PCB板上“长途跋涉”，也不同于CPO（Co-Packaged Optics，共封装光学）将光引擎与主芯片更紧密绑定的“破釜沉舟”，华为锚定的NPO，试图在带宽、时延和可维护性之间寻找平衡，将高速电连接压缩至约5厘米——相当于两枚1元硬币首尾相接的长度。

不只一颗光引擎实现了近距离互联，几天后的华为全联接大会上，华为又公布了Hi-ONE在下一代超节点中的部署情况：代替4.8万颗800G可插拔光模块，5500颗Hi-ONE将进入4096卡昇腾960超节点；跨柜灵衢互联设备支持176个1.6T端口，单机全光互联带宽约280T。

但聚光灯下的信息，更多仍是规模和性能参数。雷峰网近期对话光通信产业相关人士，试图厘清Hi-ONE进入昇腾960超节点之后，哪些技术路径已经能够看见，哪些仍藏在冰山之下。

待解之谜一

光源收进光引擎后，如何共享？

Hi-ONE并不是今年才出现。

早在2025年IFOC讯石光通信大会上，海思就已经披露过这颗光引擎采用内置共享集成光源和硅光芯片，按7.2T的容量计算，一颗Hi-ONE对应9个800G可插拔光模块，所需的光源和光器件数量也随之大幅减少。

与这一变化直接相关的，是Hi-ONE内置的共享多波长集成光源：多条发射路径可以共用光源资源，无需分别配置独立光源。

与此同时，不同波长的光还可以通过WDM（Wavelength Division Multiplexing，波分复用）架构复用到同一根光纤中，以减少光纤数量。

但公开信息并没有进一步解释，在这套“共享多波长”设计中，发射侧到底有多少个发光单元、使用多少个波长，又如何分配给36条发射通道。

更重要的是，在硅光材质上做内置光源，这在业内极其罕见。业内人士J叔更关心的正是这一层。在他看来，这些配置最终都会牵动传输距离、面积、功耗、散热以及冗余设计等工程代价。

硅光芯片本身不会发光，需要激光器的“点亮”。为了让光源尽量远离服务器内部更复杂的热环境，以及避免光源损坏后难以单独更换，不少方案会选择将激光器放置在光引擎外。

光芯片产业人士David也表示，在当下的NPO方案中，内置光源并不是常见选择。不过在他看来，华为的“不同寻常”也是一件“顺理成章”的事。

既然已经舍弃传统可插拔光模块、选择把光引擎推到主芯片附近，华为显然希望进一步提高系统集成度，并尽可能压缩光互联占用的物理空间。

沿着同一思路，如果激光器仍然独立部署在外，系统就还得另外给光源腾位置，削弱NPO在集成度上的优势。（有关华为为何选择内置光源，欢迎添加作者微信 Evelynn7778 继续探讨）

待解之谜二

7.2T带宽如何被系统拆开使用

华为早已亮出的底牌还包括Hi-ONE的数据吞吐能力——共储备36条光收发通道，单通道速率最高可达200G，总带宽高达7.2T。

不过，这只是单颗Hi-ONE的总传输能力。将视野放大至整套超节点，另一个问题随之而来：Hi-ONE集成的7.2T总带宽具体如何被系统使用？

在比较华为同期公布的几组参数时，J叔首先注意到，业内6.4T NPO更常见的通道组合是“32×200G”，Hi-ONE却选择了“36×200G”。

一种直观的猜想是，36条通道中存在冗余设计。结合跨柜灵衢互联设备的176个1.6T端口，J叔做了一次算术拆分：按200G单通道计算，一个1.6T端口对应8条通道，32条正好分成4组，36条却无法被8整除。

照此推演，J叔认为36条通道可以被理解为“32+4”，其中32条承担常态通信，4条平时待命，在主通道故障时接替工作。如果这一假设成立，7.2T就是全部物理通道的容量，系统平时实际用于传输数据的只有6.4T。

但J叔随即指出，这种推演会和其他信息相矛盾。华为称5500颗Hi-ONE可替代4.8万个800G光模块，但按7.2T计算，5500个引擎的总带宽约为39.6Pb/s，与4.8万个800G模块的38.4Pb/s相比略有富余；如果每颗引擎只有6.4T可用，总带宽约为35.2Pb/s，又不足以完成这一替代。

换句话说，华为的口径更像是按36条通道全部承载流量来计算的。

此外，32条中预留4条、约12.5%的备份比例，在功耗和面积上代价不小。业内更常见的做法是少量预留，或者在数据传输出错时重新发送这段数据来应对故障。

不过，J叔同时强调，由于Hi-ONE贴近NPU部署，首先连接的是柜内灵衢互联刀片，而非跨柜灵衢互联设备，且华为并未公开176个1.6T端口是否同样采用Hi-ONE，因此拿两个不同层级的参数做整除只是一种推演方式。

他指出，36条通道也可能会按照柜内NPU与灵衢交换设备之间的连接关系，被分配到不同链路，或者只是华为在芯片、光引擎和交换设备都由自己定义的前提下自行选择的宽度，不必受限于行业标准的32通道规格。

“仅凭‘36×200G’‘1.6T端口’这些公开信息，还无法反推出Hi-ONE在超节点中的真实连接方式。”J叔说。（更多待解技术细节的思考，可添加作者微信 Evelynn7778 交流）

NPO未必需要「大一统」

华为没有一味筑高墙。在核心系统上坚持全栈自研的同时，华为又联合中国移动研究院、京东云、百度以及光器件、连接器头部厂商启动OPEN NPO项目，主动建设行业通用标准。

这意味着，华为还需要重新划定一条边界——哪些设计可以牢牢攥在自己手里；哪些关键接口必须成为摆上台面，要求所有参与者共同遵循。

这种收放自如的底气，来自华为近30年在光网络上的积累。

过去，华为的光通信能力更多服务于骨干网、城域网和数据中心等大型通信网络，解决的是长距离、大带宽的数据传输。

进入AI智算时代，越来越多计算芯片被塞进同一套系统，高带宽互联的需求也开始向更短距离延伸。Hi-ONE正是在这样的变化中加入昇腾超节点，直接参与高速互联。

由此，华为原本分散在不同业务线上的能力，也在超节点里完成了一次“会师”：昇腾负责输出算力，灵衢组织机内与机间的高速连接，Hi-ONE则负责光侧链路的物理延伸，最终共同组装出完整的超节点系统。

David指出，这些原本需要产业链上下游不同企业反复协商、彼此适配的环节，现在全都掌握在华为自己手里。这意味着华为无需等待一套全行业统一的标准。

但不是所有人都是华为。David以阿里、腾讯为例，这些云厂商同样在布局NPO和超节点光互联，却没有华为这样完整的硬件链条，因此更需要先定义好系统和互联侧的需求，再让不同供应商围绕同一套规格开发产品。

今年国内外围绕NPO的标准动作越来越密集。除了上文提及的华为联合启动的OPEN NPO项目，由Coherent、Marvell、Molex等产业链厂商发起的Open CPX MSA（Multi-Source Agreement，多源协议），已在9月发布的1.0规范中将6.4T、7.2T以及不同光源方案纳入同一套Socket和管理框架；

国际光通信产业组织OIF也已启动面向下一代NPO模块的正式标准项目。该提案由中国信通院联合华为、腾讯、阿里云、美团、中国移动等产业方推动立项，覆盖6.4T和12.8T、单通道200G，并计划进一步统一机械外形、电气接口、供电、液冷和光连接等关键接口。

但一个生态内部需要共同规则，并不等于NPO最终一定要走向“大一统”。

David认为，不同于传统可插拔光模块需要适配不同服务器和交换机，当NPO服务于超节点内部这一相对封闭的Scale-Up（纵向扩展）场景时，多套接口规范长期并存，并不妨碍不同系统各自运行。

这也决定了供应商更现实的选择。“生态需要生意来构建。卖给谁，就follow（跟随）谁。”J叔直言。

产业更多NPO方案的部署节奏和技术难题，欢迎添加作者微信 Evelynn7778 交流。

雷峰网雷峰网(公众号：雷峰网)

雷峰网原创文章，未经授权禁止转载。详情见转载须知。

对比 Codex，免费的 AgnesCode 也能在底层算子优化任务中打得有来有回

李娜 — Wed, 30 Sep 2026 08:13:00 GMT

导语： AgnesCode在部分芯片上跑出更高性能，免费模型完成专业级交付。

AgnesCode在部分芯片上跑出更高性能，免费模型完成专业级交付。

作者丨吴海明曹PP

编辑丨李娜

免费的 AI Coding Agent，能不能和付费 Codex 在真实工程任务里打得有来有回？

过去一年，我们已经习惯了让 Coding Agent 写网页、做应用、修 Bug。但这一次，我们想把它往更底层推一步：让 AI 去优化大模型自己运行时使用的算子。

所谓“算子”，可以简单理解为大模型运行时反复执行的一小段底层计算程序。模型每生成一个 Token，都要在 GPU 或其他 AI 芯片上执行大量矩阵计算、注意力计算和数据变换。单个算子看起来很小，但会被模型反复调用。因此，一段高频算子如果能快 10%、20%，最终就可能转化为推理速度、硬件利用率和服务成本上的实际差异。

这恰好提供了一种不同于常规 Coding Benchmark 的测试方式：如果 Agent 能够读懂任务、修改算子、适配不同芯片，并最终跑出真实的性能提升，那么它触及的已经不只是应用开发，而是 AI Infra 中一部分真正的工程工作。

为了回答这个问题，我们把 AgnesCode + Agnes 3.0 Flash 放进众智 FlagOS 开放计算全球大赛的一道算子优化题：为 DeepSeek-V3 解码阶段使用的底层算子写优化代码，并在 8 款芯片上接受赛事官方自动化评测，同时，选择 Codex + GPT-5.6 Sol 组合作为对照。两组候选者使用完全相同的环境为算子撰写优化代码，最终都提交到赛事官方的自动化评测系统进行评测。

结果很有趣：

两组选手都顺利完成了任务，Codex + GPT-5.6 Sol 用 8 分 57 秒给出结果，AgnesCode + Agnes 3.0 Flash 在中途被测试人员催促了一次后，耗时 20 分 36 秒完成任务。经过官方自动化评测后，对比 Codex 通过7款芯片的战绩，AgnesCode 略逊一筹，通过了 6 款芯片；但在双方共同通过的 5 款芯片上，AgnesCode 有 4 项加速比更高，其中在国际通用芯片 B 上达到 4.81×，高于 Codex 的 3.71×，加速比分数高出约 29.6%；昆仑芯上也只有 AgnesCode 通过测试。

这不只是一个“免费模型全面替代付费模型”的故事，还说明了另一件事：当任务边界、工具链和评测闭环足够清晰时，免费 Agent 已经可以进入底层工程任务，并交出可验收、有性能收益的产物。

Agent 时代，模型便宜只是入场券，能把任务交到终点才是分水岭。本文真正想回答的，是当 AI 开始拧紧自己的底层螺丝，免费的 AgnesCode 距离一个可用的工程助手还有多远。(雷峰网(公众号：雷峰网))

一道题：

优化 DeepSeek-V3 底层算子

考虑到常见测试任务的数据很可能已经用于模型训练，导致模型本身已经很擅长，因此，在这次测试中，我们直接跳过常见的网页生成、数据看板、文案撰写等常见测试场景，选择让 AgnesCode 直接挑战更接近基础工程的题目：大模型推理算子优化。

具体来说，算子是模型算法能运行的基础环节，模型每生成一个 Token，背后都要反复调用矩阵乘法、注意力、归一化、激活函数等底层算子。在单个算子上几个百分点的加速比，往往直接变成推理延迟、显存占用和服务成本的差异。更重要的是，算子优化正在成为 AI 自进化的一部分，过去，优化这类底层代码高度依赖系统工程师手写经验；现在，Coding Agent 开始尝试读任务、写算子代码、跑测试、看报错、再改代码，这是 AI 开始反过来优化自身运行底座的一种工程样本。

所选测试题来源截图1: 众智 FlagOS 开放计算全球大赛赛季二的赛道一

需要说明的是，这次的测试题目来自众智 FlagOS 开放计算全球大赛赛季二的赛道一：SGLang框架算子在多款芯片的性能优化。该比赛围绕 SGLang 推理框架开放了 200 余道算子任务，每周发布一批算子题目，参赛者只能在本周内看到赛题内容。因此，这可以极大保证测试任务的数据没有被测试模型提前学习，对评测对象来说，这完全是一次“摸底考试”。

所选测试题来源截图2: 200+算子的多芯片优化任务

具体来说，我们选择了一道 DeepSeek-V3 在解码阶段使用的融合 QKV-A 下投影算子 题目（Task66: dsv3_fused_a_gemm）作为测试任务，该算子是将输入特征与合并后的投影权重相乘，一次完成 Q 分支和 KV 分支的前置投影，为后续注意力计算准备数据。题目本身的计算并不难，真正的挑战在于考察 AgnesCode 能否生成一套优化算子代码能快速通过 8 款芯片（2款国际芯片、天数智芯、沐曦、燧原、海光信息、昆仑芯和华为）。

所选测试题来源截图3: Task66-dsv3_fused_a_gemm 赛题

对打 Codex：

入口名翻车，但性能结果并不弱

为了更好知道 AgnesCode 的行业水平，我们选择 Codex+GPT-5.6 Sol 组合作为对照组，AgnesCode 则用官方提供的免费模型 Agnes 3.0 Flash 作为后台。我们为两个组合同时提供一个标准化的 Skill，该 skill 提供了赛制的全部信息，例如如何命名每个代码文件、如何在代码文件中命名函数名、写完代码以后要打包等。之后，我们在相同的环境下让两个组合为测试题撰写代码。

具体地，我们首先让两个组合在一台含有 NVIDIA 芯片的机器上撰写第一个版本代码，然后再基于这个版本代码撰写适配其他所有芯片的代码。

从运行过程来看，AgnesCode + Agnes 3.0 Flash 组合在第二阶段生成代码的时候，首先花费了7分10秒没有给出答案，经过测试人员催促以后，再次经过13分26秒后给出了针对不同后端调整优化的代码。包括语法、禁用项和文件依赖检查，最终整理提交包，并更新开发记录。整体来看，从编写实现、跨芯片适配，到代码自检、打包和交付，这个组合已经能够围绕一个专业任务推进完整的工作流程。

AgnesCode + Agnes 3.0 Flash 组合运行截图

再来看看 Codex+GPT-5.6 Sol 组合的表现，相对AgnesCode + Agnes 3.0 Flash 组合整体使用 20 分 36 秒的时间开销，Codex+GPT-5.6 Sol 组合仅用8分57秒就给出了结果。对比来看，Codex+GPT-5.6 Sol 组合的整体工作推进更快，也更加流畅。

Codex+GPT-5.6 Sol 组合运行截图

任务推进过程是一方面，两个模型经过系统评测的效果如何呢？

众智 FlagOS 开放计算全球大赛赛事官方自动化评测结果截图，第一行为 AgnesCode + Agnes 3.0 Flash 测评结果，第二行为 Codex+ GPT-5.6 Sol 测评结果。

整体来看，虽然在芯片的适配数量上，AgnesCode 落后Codex 一个，仅有六个芯片通过了测试。但在双方共同通过的五个芯片上，AgnesCode 有四项加速比更高，在天数智芯上，AgnesCode 为 2.16×，Codex为 1.72×；在国际通用芯片 B 上，AgnesCode 达到 4.81×，高于对照组的 3.71×，加速比分数高出约 29.6%；在昆仑芯上仅有 AgnesCode 通过了测试，并取得来2.56X的加速比。

该结果表明，AgnesCode + Agnes 3.0 Flash 交付了能够在多个平台获得实际加速的算子成果，体现了一定的竞争力，但在跨平台覆盖和最终验收，仍有继续改进的空间。

最后，对于一个绕不开的话题——成本，AgnesCode + Agnes 3.0 Flash 完全免费，这让它在真实的业务场景里更具吸引力。很多任务往往需要多轮问答才能获得较为不错的效果，而且模型还需要反复读取文件、根据用户反馈进行调整。若按闭源模型计费，账单很可能快速爆炸，而免费模型至少把“敢不敢让多试几轮”的门槛降了下来。

AA榜单揭示

Agnes 3.0 Flash 的能力边界

上述测试可以发现，免费的 AgnesCode+Agnes 3.0 Flash 完全可以和付费订阅的 Codex+ GPT-5.6 Sol 打的有来有回，这是个例还是普遍存在呢？

对此，我们调取了 Artificial Analysis (AA榜单)公布数据，其中的 Intelligence Index 指标综合考察模型在工作任务、工具执行、编程、复杂推理、知识可靠性与长上下文等方面的表现，为模型的整体水平提供参照，Agnes 3.0 Flash 的得分为 36 分，即为接近 GPT-5.6 Luna（max）的 38 分。这说明 Agnes 3.0 Flash 本身能力已经和主流模型能力不相上下了。

Artificial Analysis (AA榜单)公布数据截图

在 Artificial Analysis 的智能表现 × Token价格对比中，Agnes 3.0 Flash以约 0.03 美元/百万 Token 的价格进入最具吸引力区间，并位于帕累托前沿。

另外，把能力和价格放到同一张图里看，Agnes 3.0 Flash 的位置会更直观。AA 榜单的智能表现 × Token 价格对比显示，它以约 0.03 美元/百万 Token 的价格，进入了图中最具吸引力的低价高能区间：横向看，它的价格显著低于多数同等智能表现的模型；纵向看，在相近价格带里，拿到了更靠前的智能表现，这直接让模型坐稳帕累托前沿的位置。

从实际的 Agent 工作流来说，这个位置尤其重要，因为长任务会不断放大 Token 消耗，模型每便宜一点，都会直接影响用户是否愿意让它持续读文件、改代码、跑测试和反复迭代。

Artificial Analysis (AA 榜单)的智能表现 × Token 价格对比数据截图

免费又不失性能，

为 AI 进化带来更多探索空间

通过代码优化测试可以发现，AgnesCode + Agnes 3.0 Flash 已经能自动化生成能被系统验收、能被继续迭代、能在成本上算得过账的交付物。Agent 时代，模型便宜只是入场券，能把任务交到终点才是护城河。

换句话说，随着 AI 的发展，用户需要的不再只是生成应用，而是 AI 开始拧紧自己的底层螺丝。

从结果看，AgnesCode + Agnes 3.0 Flash 展示了两个信号：

1.在有明确工作流、任务文件和评测反馈的情况下，它已经能推进跨芯片算子适配，并在部分芯片上跑出更高加速比。

2.Agent 可能会在“最后一公里”犯错，例如入口命名、提交规范、覆盖范围等细节，这些问题不一定抹掉性能亮点，但会直接决定结果能不能被真实系统接收。

模型能力决定上限，工作台能力决定它能不能稳定抵达上限。对开发者和企业用户而言，AgnesCode 的优势不只在模型本身，也在它把模型、项目文件、Skill、命令执行和评测反馈组织到同一个工作流里，帮助用户少打扰、少返工、少花钱地把事做完。

从算子优化来说，这也是国产 AI 芯片生态正在面对的现实问题，不同芯片之间的差异，不会因为上层框架统一就自动消失；推理框架、算子库、编译工具链和真实业务负载之间，仍然需要大量适配工作。如果 Agent 能进入这条链路，它就有机会把过去依赖少数系统工程师经验的优化工作，变成可以持续生成、持续验证、持续迭代的工程流程。

对比，Codex + GPT-5.6 Sol 在任务推进速度和整体流畅度上依然更占优，AgnesCode + Agnes 3.0 Flash 也暴露出交付细节上的不稳定。但同时证明了一件事：免费模型并非只能停留在简单任务层面，只要工具链、上下文和评测闭环足够明确，它同样可以进入专业工作流，并交出有竞争力的结果。

免费模型的真正价值，正在从让 AI 变得更便宜转向让更多真实任务有机会被 AI 反复尝试。当试错成本下降，Agent 才可能从“偶尔帮忙”变成“持续干活”；当持续干活成为可能，谁能把专业要求稳定写进执行过程，谁就更接近下一代 AI 工作台的入口。

雷峰网原创文章，未经授权禁止转载。详情见转载须知。

从海拉鲁到现实世界：视频模型如何理解「变化」

李娜 — Wed, 30 Sep 2026 08:09:00 GMT

导语：HiDream-O1-Video 的三场世界回应测试。

HiDream-O1-Video 的三场世界回应测试。

作者丨Reah

编辑丨李娜

在《塞尔达传说：旷野之息》中，玩家点燃一片草地，火焰会沿着草叶蔓延，热空气随之升起。此时展开滑翔帆，林克便能借助上升气流离开地面。雷雨中装备金属武器可能招来闪电，降雨又会让攀爬变得困难。海拉鲁并没有追求照片级的视觉拟真，却通过一组稳定、可组合的规则，让玩家感受到一个世界正在持续运行。

这种体验的关键是无论世界里有多少种物体，系统都会回应玩家的行动，并且符合物理规律。规则稳定，玩家才有可能根据经验作出预测；多条规则相互作用，又会产生未被逐一写死的解法。一个可信的虚拟世界，因而同时包含状态、变化、交互与反馈。

素材出自抖音博主「丑丑鱼-主机游戏」

《塞尔达》当然不是机器学习语境中的世界模型。前者的规则主要由设计师与工程师显式构建，后者则试图从数据和交互中学习状态、行动与后果之间的关系。两者机制不同，但指向了同一种直观体验：一个世界之所以成立，肯定不是因为它看起来真实，关键是它能够对行动作出符合人们物理世界的回应。

这也是理解世界模型的一个有效入口。世界模型不是更大规模的视频生成器，也不是把图像、视频、三维空间和机器人排列在同一张矩阵图里。它需要形成对世界状态及其变化规律的表征，并进一步支持预测、规划或行动。

智象（HiDream.ai）将新发布的 HiDream-O1-Video-1.0 (下文简称为HiDream V1)定义为“更懂真实世界的视频生成模型”，并把它放在“一个 UiT( Unified Transformer)、四大模型同源演进”的世界模型路线中。按照官方介绍，模型具备前置多模态意图理解、5—20 秒动态时长、1080P 输出、物理变化生成和原生音画等能力。Video 在这套叙事中的作用，是让静态空间进入时间：模型不仅要呈现世界是什么样，还要表达一个动作发生后，世界将如何变化。

不过，视频模型本身并不是完整的世界模型，一段符合常识的成片也不能证明模型已经形成了可泛化的物理认知。要判断更懂真实世界是否超越传播口号，仍然需要回到可观察的输出。

比如在下面这个场景中，拉环尚未弹开，气泡声是否已经提前响起；可乐在手中晃动是否符合液态规律。

比如在炒菜的场景里料酒还未落入热锅，火焰是否凭空升起；

比如鼓槌没有接触鼓面，鼓声是否已经出现。

宏大的世界模型命题，最终需要从这些最小的状态变化开始接受检验。

我们怎么测试

“世界有没有正确回应”？

今天的视频模型已经能够稳定生成大量运动效果：镜头推进、人物转身、头发飘动、烟雾扩散与火焰变化都不再罕见。但画面存在运动，并不等于模型完成了一个事件。完整事件至少包含三个层次：首先是对象发生运动，其次是动作按顺序产生结果，最后是视觉、声音与状态变化都能找到对应原因。

大量生成结果仍会停留在第一层。它们通过运动模糊、镜头晃动、火焰和烟雾制造强烈动感，却可能漏掉关键动作、改变对象身份，或让结果早于原因发生。对用户而言，这类视频的单帧质量可能很高，但只要连续观看，世界的规则就会迅速失效。

为验证 HiDream V1 的能力，本文设计了三组原创图生视频任务，并与 Seedance 2.5、MiniMax H3 进行对比。三家使用相同参考图和原始中文提示词，目标时长统一设为 10 秒（三家实际交付时长并不相同，见下方规格说明），开启原生音频，并保留各平台正常面向用户的默认理解与提示词处理流程。测试关注的不是单一画质分数，而是意图规划、时间因果和音画对应三个维度。

这并非纯底模的实验室测试，而是同图、同原始需求、同目标时长的端到端产品对比。三家的前置理解、提示词增强和服务系统存在差异，这些差异本身也是产品能力的一部分。

实测环境：三家实际平台与完整模型版本
HiDream-O1-Video-1.0——HiHarness
Seedance 2.5——即梦
MiniMax H3——MiniMax Design
实际交付规格：
HiDream：1920×1080 / 30fps 恒定帧率；爆炒与可乐 10.07 秒，鼓手 7.93 秒
Seedance：1280×720 / 实际 24fps（封装声明 60fps，PTS 为 3:2 间隔，非真 60 帧）；三题均 8.00 秒
MiniMax：2560×1440 / 24fps；三题均 7.96 秒
以下分析中在涉及三家在分辨率、帧率与实际时长时运用了专业软件和模型辅助进行量化分析

第一场：料酒落锅之后，

火应该什么时候起来

第一组任务发生在夜市铁锅前。厨师先把一勺料酒泼入滚烫的锅中，油爆声出现后，橙蓝色火焰随之升起；随后连续颠锅三次，让面条、红椒和葱段腾空再落回；最后火焰收起，食材被装入原本空着的白瓷碗，铁勺敲击锅沿完成收尾。

火焰是这一场景中最醒目的视觉元素，也最容易掩盖问题。真正需要维持的是从料酒接触热锅、油汽被点燃，到颠锅、食材回落和最终装盘的连续关系。如果火焰早于触发动作出现，或者食材在高速运动中消失、变种，再强烈的视觉效果也无法证明事件已经完成。

这一任务还要求模型同时处理快速运动与对象一致性。三次颠锅需要形成可辨认的“腾空—落回”，锅中三类食材在运动前后应保持一致，最终白碗也应从空碗连续变为装有成品的状态。油爆、爆燃、金属撞击与敲锅声，则用于检验声音是否准确对应各自的动作节点。

Seedance 2.5

Seedance 的画面表现确实非常出片，整体运镜和色彩是有讲究的，天然会有场景-主体-动作的交代关系。从物理关系上看也有可圈可点的地方，比如料酒的加入过程很狂野，虽然说有一半撒到了炒锅之外，但鉴于中餐大排档的制作过程非常依赖厨师风格，这种操作也不能算错，甚至有些节目效果，视效拉满。但面条在锅里的状态让人提不起食欲，整体不是根根分明的状态，而是一个整体的面团在锅里搅拌，也算不上对错，从最后出锅的效果看也是前后一致的。

HiDream-O1-Video-1.0

HiDream V1 的出片非常非常优秀，料酒刚开始撒入后没立即变化，炒勺移开之后再进画面依旧是同一个东西，然后厨师开始颠勺火苗才窜起来，整个面条在锅里被颠起来的上松下紧的效果已经极其接近物理世界的状态了，包括最后面条入碗的流动状态，是主体面条“滚进”碗里，最后锅里的几根会残留在锅里，并不是一股脑进去滑进去的，并且锅具放回灶上的时候依旧有合理的碰撞声。

MiniMax H3

MiniMax 的起火位置有些偏，但锅具和灶台的撞击点音画配合挺好，每一次都精准卡进去了，非常符合大众的认知。就是最后装盘的时候模型没理解面条这个材质的东西应该怎么表现，所以视频上像是直接快速位移搬运过去的，并不是面食这种黏度较大的组合物品自然的流到碗里，如果细看的还会发现面条在锅里颠勺的过程也像是一个整体的面饼在移动，不是有层次的。

把三家放到同一条时间轴上来看就可以把起火这个节点量化核对。HiDream 是炒勺 2.4 秒重新进入锅内、油爆声 2.5 秒达到峰值、火焰面积 2.6 秒进入最快增长，动作、声音、结果依次相隔约 100 毫秒。

Seedance 是 0.25 秒泼酒、0.54 秒起爆声、0.58 秒起火，顺序同样成立，只是整体节奏被压缩到前半秒。

MiniMax 则是 1.5 秒起火、2.26 秒才出现对应的高频爆声，火焰比声音早了约 0.5 秒；而且火苗位置明显偏离锅心，与锅内食材不在同一处，起火点和燃料不在一起，这比时序偏差更根本。

火焰规模的差别也挺大：Seedance 峰值占到画面 54.7% 并持续四秒多，几乎把颠锅和食材全遮住；HiDream 峰值 36.2%；MiniMax 只有 30.6%，而且只烧了 0.6 秒就熄灭，不太像料酒爆燃应有的衰减过程。火焰越大越容易掩盖事件本身，这一题里 Seedance 恰好演示了这一点，因为最壮观的四秒，也是最看不清发生了什么的四秒。

出锅场景里面 HiDream 的转移持续约 0.9 秒（7.5—8.4 秒），面条呈连续流态滚入碗中，并且到 9.3 秒锅壁上仍挂着几根葱段没有倒净。不完全转移反而是真实厨房里的常态。Seedance 的转移约 0.5 秒，面条在碗中逐步堆积，过程是连续的，但整体是一团黏聚的面块。MiniMax 的转移只用约 0.42 秒，且面团在下落过程中几乎不发生形变，是整块平移下去的，确实更接近搬运而不是倒出。

第二场：

鼓槌落下之后，声音能否准时出现

第二组任务是一段舞台鼓手的演奏收尾。鼓手先在中央红色军鼓上连续击打两次，再依次敲击左右两只黑色通鼓，踩下一次底鼓，最后双臂交叉击中两面金色镲片。最终一击落下时，冷蓝色舞台灯切换为红色，观众欢呼，人物以举起两根鼓槌的姿势结束。

这组任务把音画同步拆成了可以逐项核对的动作。军鼓、通鼓、底鼓和镲片具有不同音色，每个声音都应当在对应鼓面或脚踏被击中的时刻出现。镲片长鸣可以延续，但必须由先前的击打触发；灯光切换与观众欢呼，也应在最后一击后进入高潮，而不是提前出现。

快速演奏同时提高了人物和器材一致性的难度。两根鼓槌需要在双手交叉、人物甩头和镜头推进中保持数量与归属，鼓手面部、服装和鼓组位置也不能因遮挡发生漂移。这类任务可以检验模型是否只是生成一层泛化鼓点，还是能够让声音、动作与舞台反馈进入同一条时间序列。

Seedance 2.5

Seedance 在"起手才有声"这件事上做的最好：音轨前 450 毫秒只有环境底噪，第一次能量跃升出现在 0.47 秒，画面里双槌首次落到鼓面是 0.5 秒，两者基本重合。真正的问题出在最后一击。4.66 秒落下的时候，双槌收在军鼓与通鼓一侧，并没有打到左右两面金色镲片；这一击的频谱里 43% 的能量压在 120Hz 以下，6kHz 以上几乎为零，听感是一记低频闷响，不是镲片的宽频炸裂。

紧接着的 50 毫秒后画面里双臂完全放下，4.71 秒左右的下一帧，灯光已从冷蓝整片切成红色、双臂变成完全举起、景别同时前推。帧间变化量达到全片中位数的 11.3 倍。手臂在 50 毫秒内从最低点回到最高点在物理上不成立，所以这不是"面光跳变"，而是一次硬切。提示词要求的"双臂交叉击中两面金色镲片"这个动作，被这次剪切跳过去了。

切点之后还叠了一段持续低频轰鸣，总能量是最后一击本身的 2.6 到 5.9 倍，频谱重心压在 sub 频段（0.79—0.86），更像影视预告片里的低频冲击音效，而不是提示词要的观众欢呼——人声频段要到 6.5 秒之后才出现。整条音轨的带宽也是三家最窄的，7.9kHz 之上基本截断，高频能量比另两家低一个数量级，所以鼓组整体音色偏钝。

收尾姿势与人物一致性没有问题：两根鼓槌数量全程正确，最终停在举槌姿态，面部与发型和参考图一致。

HiDream-O1-Video-1.0

HiDream 是三家里唯一全片没有出现硬切或突变帧的一条：帧间变化量最大值也没超过中位数的 5 倍，整段是一次连续推镜。军鼓—通鼓—底鼓—双镲的顺序成立，击打位置、时间与音色能对应上，鼓槌、双手、人物脸与鼓组的一致性也没问题。但视频开头鼓手还没动手就出现了镲击声

最后一击的处理是它和另两家分开的地方。4 秒左右双臂向左右完全展开、落点在两侧镲片高度，这一击的频谱是真正的宽频（sub 0.26 / low 0.36 / mid 0.24 / hi 0.10 / vhi 0.03），能分析出镲片而不只是鼓皮。灯光从 4.5 秒开始升温，4.7 秒越过冷暖分界，整个过渡约 270 毫秒完成，变化速率 +2.11/秒。也就是说击打先发生，灯光在大约 200 毫秒后跟上，是渐变而不是跳切。人物还保留了独立于红色背景的打光。

尾段 5.5—7.9 秒的音轨里 96% 以上的能量集中在 400—2000Hz 的人声频段并持续了三秒半，画面下方同时出现观众举起的手，那就是说欢呼场景是真的被生成出来了。结束姿势是举起两根鼓槌，与提示词一致。整条音轨里中频占 47.8%、低频只占 9.3%，是三家中最接近真实鼓组音色的一条，棒击的 attack 和镲片泛音都在。

MiniMax H3

MiniMax 这一条的单帧规格最高（1440P），但事件层的问题也最多。

首先是结构。全片在 2 秒、4 秒、6 秒各有一次硬切，帧间变化量分别是中位数的 6.4、9.7、8.7 倍，间隔几乎正好两秒，这更像是按两秒片段拼接后接起来的，而不是一次连续演奏。

其次是音色。开场 0.1 秒左右就有一记极大的低频撞击，通过定量分析发现能量是前 50 毫秒底噪的三十八万倍，但 93% 的能量落在 120Hz 以下，是近乎纯低频的闷响；而提示词此处要求的是先击中央红色军鼓两次，军鼓应当有脆亮的中高频。放到全片看，78.5% 的能量都在 400Hz 以下，能检出的高频事件只在 6.32—6.56 秒出现过一次。也就是说前六秒多的演奏里，几乎没有棒击的 attack，也没有镲片。

灯光的表现有一点复杂。末击在 6 秒左右出，冷暖越界要到第 7 秒了，滞后几乎有一秒，这已经进入人能明确感知不同步的区间；而且红光最终只走到 +0.16，另两家是 +0.39 和 +0.42，所以红色既晚又没到位，转换速率也是三家最慢的 +1.29/秒。

第三场终极大考：

老板来杯可乐加冰

第三组任务是一段冰可乐 ASMR。人物需要拉开覆满水珠的银色易拉罐，在“咔嗒”之后听到绵长的气体释放声；随后把三块冰倒入空杯，注入深褐色可乐，让气泡和泡沫沿杯壁上涌；最后端起杯子晃动两次，喝下一大口并呼气收尾。

提示词：一镜到底的冰可乐 ASMR，节奏利落。年轻人先“啪”地拉开冰凉的易拉罐，清脆的“咔嗒”后立刻冒出一声绵长的“嘶——”，细密泡沫冲到罐口。紧接着，他把碟里的三块冰快速倒进空杯，响起连续的“叮、当、咚”；马上把深褐色可乐冲进杯里，气泡沿玻璃杯壁疯狂上涌，泡沫贴近杯口但没有溢出。随后他端起杯子猛晃两下，让冰块密集撞击杯壁，再仰头咕噜喝下一大口，放下杯子痛快地“哈——”一声。镜头顺着手部动作小幅跟移，只保留拉环、气泡、冰块、吞咽和呼气这些现场声，不要背景音乐。

这段 Prompt 刻意没有写入：人物不能变脸、冰块不能增减、杯子不能变形、所有动作必须完成。因为这些不是用户故事，并且把这些变量交给模型去处理更能看出对真实世界的理解。

这个场景包含连续的状态转换：易拉罐从密闭变为打开，空杯先装入冰块，再被可乐填满，最终又被人物端起并饮用。声音同样具有明确顺序，从拉环、气泡、冰块碰杯、液体注入，一直延伸到吞咽和呼气。这个测试任务最难的是冰块的转换要从碟子里往杯子中过渡，并且人物手拿杯子的时候还要摇晃一下，这相当考验模型对真实世界的理解能力。

测试的重点主要是对象状态是否真正随动作变化。比如说可乐应当从罐口连续流入杯中，不能在遮挡后凭空出现；冰块、泡沫与液面应当受到注入和晃动影响；人物饮用前后的杯中液体也应保持连续。

Seedance 2.5

Seedance 2.5 的风格挺明显，是有成熟视听语法的高情绪短片，易拉罐被拉开的声音处理的很细腻，分了好几段来表现扣开、拉扯、掀开喷气的几个过程。但是冰块入杯的声音很奇怪，不符合冰块逐点下落的事实，是黏在一起的一连串声音，有点强行找素材配上去的感觉。冰块进杯子之后也从三块变成了四块，逐帧看得很清楚：2.83 到 2.96 秒稳定是 3 颗，到 3.10 秒变成 4 颗，而此时碟子已经移出画面，没有任何第四颗入杯的过程——是凭空多出来的。并且在摇动杯子时液体的晃动程度不符合物理规律，明显感受到液体的黏稠度，晃动幅度较

小。片尾也没有遵循提示词中需要放下杯子的硬约束：到 7.97 秒最后一帧，杯子仍然端在手里。

HiDream-O1-Video-1.0

HiDream-O1-Video-1.0 的液体晃动情况就好很多，符合可乐这种低粘度液体的摩擦力应有的反应，并且也遵循了提示词中的所有约束，包括 Seedance 丢掉的那一条：9.3 秒把杯子放回台面、手离开杯身，随后张口呼气，音轨的最大能量峰值就落在 9.5 秒，是能和这个动作对齐的。但在冰块数量上依旧翻车了，碟子上清晰的看到三块冰，落进杯子之后变成了五块。

MiniMax H3

有意思的是 MiniMax 对自己的生成结果进行校验发现结果有出现多次明显剪切，开罐、倒冰、注液、摇杯和饮用分别使用了不同景别与机位，于是重新申请生成一次。也就是说重做的目的瞄准的是一镜到底，不是符合物理规律。

这是重制版：

MiniMax H3 重新生成的视频虽然是一镜到底了，但仍在 4 秒左右处留有一次明显的动作断裂（帧间变化量为中位数的 6.7 倍），这是修正版里唯一的突变点，比初版的十余处已经收敛很多。

修正版的端点数量其实是对的：碟中 3 颗，落定后 3 颗。问题不在数量而在材质稳定性，比如说冰块在飞行途中会糊成没有棱角的白色团块，可见颗数一度掉到 2 颗，落到杯底才重新收敛成三颗有棱有面的方冰。初版的碟子上一开始就摆了 4 颗以上，并且开罐、倒冰之间还夹着多次景别切换。（但说实话初版的冰块摇动声音是最好听的）

Seedance 给液体设置了过高的等效阻尼，或者根本没有成功把液体作为独立于杯子的动态对象来处理。明显压缩了摇杯动作，液体、泡沫与冰块近似随杯体整体移动，呈现出过度阻尼的糖浆感

HiDream 更好地表现了低黏度液体受杯体加速后的惯性滞后、液面形变与余振

“先理解，再生成”

正在成为完整系统能力

按照智象的介绍，HiDream V1 在生成前设置了多模态意图理解模块，将用户口语化、碎片化的输入整理为镜头时长、场景、人物、动作、声音和转场等结构化规划，再交由视频生成核心执行。这套机制的价值，在于能大幅减少动作遗漏、顺序错误和对象关系错配。（雷峰网(公众号：雷峰网)）

因此，判断前置理解是否有效，需要同时观察规划和结果。若结构化规划已经正确识别动作顺序，而最终视频没有执行，问题主要发生在生成阶段；如果规划本身就遗漏关键动作或改变因果顺序，则说明意图理解仍未稳定。把规划与执行分开分析，比笼统讨论“指令遵循”更有助于定位模型能力。

音画生成也需要遵守同样的证据边界。智象称 O1-Video 采用文本、视频与音频联合建模，使声音和画面在同一次生成中相互约束。

输出表现则已经拥有外部坐标。Artificial Analysis 的 Image-to-Video with Audio 榜单是面向带音频图生视频的独立 Elo 池，HiDream 在其中进入第一梯队，说明其完整音画成片获得了较高的人类偏好评价。

HiDream 距离“世界模型”还有多远

▪ 第一梯队的竞争，正在从能力清单走向路线分化

截至 2026 年 9 月 15 日，HiDream-O1-Video-1.0 在 Artificial Analysis 带音频图生视频榜上名义排名第 4，Elo 为 1186；考虑置信区间后，更稳妥的表述是处于第 3—6 名区间。

在 Arena Image-to-Video 榜上，它暂列第 8，置信排名约为第 6—10 名。

两项成绩足以说明智象 HiDream 已进入全球视频生成模型第一梯队，放到国内看它与 Seedance 2.5、MiniMax H3 和阿里 Wan 3.0 一同构成了这一轮原生音画视频生成的头部阵容。

更值得关注的是，三家已经在不同方向上建立产品路线。Seedance 2.5 将原生单段时长扩展至 30 秒，支持大量多模态参考，并把生成、编辑和延长纳入同一生产流程，其重点是服务复杂内容创作。MiniMax H3 则开放了 33B Base 权重，同时以 Context-IR 负责多模态意图解析，并通过 Regenerate-2K 处理高分辨率输出；fal 基于开放权重进一步后训练出 H3 Max，也表明基础模型、第三方后训练与推理服务正在成为不同的竞争层次。

HiDream 的选择是前置意图理解、内容驱动时长，以及把 Video 纳入图像、交互世界和具身模型组成的更大体系。由此可以看到，原生音画已经逐渐成为第一梯队的共同能力，“先理解、再生成”也不是单一厂商独有的方向。差异最终仍需体现在输出中：声音是否服从动作，时长是否服从内容，结果是否服从原因。

▪ 三篇研究构成技术储备，但不是产品配方

智象在HiDream V1的技术叙事中重点介绍了 DMSampler、DiffusionCompass 和 EvoID 三项 2026 年顶会研究。三者可以组成一条视频 Diffusion RL 后训练路线，分别回应训练成本、质量稳定和身份保持三个问题。

该图是 DMSampler 如何压缩扩散强化学习的采样成本。传统流程中，采样约占训练时间的 70%；DMSampler 以持续重蒸馏的少步采样器替代高成本 rollout，将约 50 步压缩至 4–8 步。

来源：HiDream × 中国科学技术大学，ICML 2026。

视频强化学习首先面临高昂的采样成本。一次 rollout 需要完成整段视频的扩散去噪过程，远高于单张图像的生成开销。DMSampler尝试将奖励评估采样从大约 50 步压缩至 4—8 步，使 rollout 成本下降一个数量级，为视频 Diffusion RL 的规模化训练提供基础。

在此之后，DiffusionCompass使用 off-policy 高质量样本锚定 on-policy 探索，降低模型追逐奖励时出现质量漂移的风险；EvoID则将身份保持、运动自然度与时间一致性纳入强化学习优化。从研究逻辑看，它们形成了“降低试错成本—稳定探索质量—优化时间一致性”的连续路径。

▪ Video 补上的是时间维度

按照智象的世界模型路线，HiDream-O1-Image 用于表达静态空间，HiDream-O1-Video 加入时间、动作与音画变化，HiDream-O1-World 进入可探索的三维环境，HiDream-O1-Embodied 则让模型在现实中行动并接收反馈。四个位置分别对应世界“是什么样”“如何变化”“能否进入”和“能否被行动改变”。

Video 的意义并不只是增加一种内容格式。图像可以呈现玻璃杯、铁锅和架子鼓，却不需要回答可乐倒入后液面如何升高、料酒接触热锅后火焰何时出现、鼓槌击中不同鼓面时应当发出什么声音。视频把静态空间放进时间，迫使模型处理状态转换、事件顺序、对象一致性和同步反馈。

这也解释了为什么视频是世界模型路线中不可缺少的一环：它承载的是世界如何随时间变化。但需要强调的是，生成正确的时间顺序不等于模型已经形成可泛化的因果认知，符合物理直觉的样片也不能证明模型能够进行反事实推理或真实世界预测。视频输出可以作为行为层证据，世界模型则是更大的架构。

一个 UiT 底座、四模型同源演进”构成了这条路线的骨架。后续值得观察的是：四个模型能否使用可迁移的共同表征，能否在彼此之间传递状态与约束，以及虚拟环境中获得的经验能否进入真实行动。只有这些关系逐步建立，四个模型才有可能从并列产品走向真正协同的世界模型体系。

世界模型，

最终要接受最小事实的检验

回到三组任务。HiDream 真正做到的是行动在前、回应在后这条关系，比如料酒入锅 2.4 秒、油爆声 2.5 秒、火焰 2.6 秒；或者末次击鼓 4.365 秒、灯光转红 4.567 秒；以及三块冰逐颗落杯、数量前后一致。

塞尔达传说里面之所以像一个世界，不仅因为它拥有更多山川或更接近现实的材质，而是因为点燃草地之后，火焰、热气与滑翔会沿着稳定规则依次发生。玩家可以基于这些规则进行预测和试探，并获得连贯反馈。

但是世界模型的目标远比一套游戏规则复杂，HiDream-O1-Video 仅仅是智象世界模型路线中的一个组成部分。不过理解世界无论被扩展到多大，最终都会回到我们上面演示的这些具体变化：拉环弹开后，气泡是否响起；料酒落锅后，火焰是否升起；鼓槌落下后，鼓声是否到来。

世界模型的宏大，不在于它能生成多大的世界，而在于它能否回答好每一次最小的变化。只有经得起这些具体事实的检验，模型生成的才不只是一段视频，而是一个真正成立的世界。

▎体验申请：

HiDream-O1-Video-1.0目前进入内测阶段并将在近期上线，用户可以扫码填写体验申请表，申请提前体验。

上车，带你看遍全球 AI 顶会精华

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

扫描上方二维码

或点击「阅读原文」关注专区。

雷峰网原创文章，未经授权禁止转载。详情见转载须知。