半年之后，AI 办公从产品赛马走向体系竞争

过去两个月，阿里、腾讯、字节陆续调整了各自的 AI 办公布局，但三家的收拢路径并不相同。8 月 3 日，阿里开放“千问办公”QwenWork 公测，将 QoderWork、MuleRun 和悟空的核心能力汇入同一平台，最明显的是产品线整合；腾讯在 6 月推出 Productivity Agent Suite，把 WorkBuddy、腾讯文档、会议上下文、Agent 开发平台和企业治理能力放入一套产品体系，并据晚点 LatePost 的调查报道继续向 WorkBuddy 归拢相关资源，产品体系与组织资源同时收拢。

字节这轮最明确的公开信号则是组织调整：飞书产品团队并入豆包，飞书的战略、市场、销售与客户服务体系归入火山引擎。换句话说，阿里以产品整合最明显，腾讯同时推进产品体系和资源归拢，字节则先调整产品汇报与商业化组织。路径不同，目标却相近：把基础模型、办公入口、云基础设施和企业商业化能力接到同一条交付链上。

这里所说的“AI 办公”，不只是给文档、表格和会议软件增加几个生成按钮，而是让 Agent 获得工作上下文和工具，在一段时间内持续执行任务，并留下可检查、可修改和可流转的成果。把时间线往前拉，国内这轮集中整合与 Claude 从 Code 走向 Cowork，间隔大约只有半年。

Claude Code 于 2025 年 5 月正式开放。Anthropic 在 9 月 2 日披露，其年化收入运行率已超过 5 亿美元，三个月内使用量增长超过十倍；Anthropic 随后在 12 月 3 日的公告中表示，Claude Code 已于 11 月达到 10 亿美元年化收入运行率。2026 年 1 月 12 日，Cowork 以研究预览形式发布，把 Claude Code 已经形成的长任务执行能力带到桌面文件和更广泛的知识工作。（Anthropic：Series F 与 Claude Code 商业数据、Anthropic：Claude Code 10 亿美元里程碑、Anthropic：Claude 应用更新记录）

时间先后不能证明国内三家的战略调整都由 Claude 触发。它们原本就拥有大模型、编程助手、办公软件、云服务和企业客户，也已经在不同团队中探索 Agent。但 Claude Code 的商业成绩与 Cowork 的产品扩张，至少提供了一个强烈的外部信号：Agent 不只是一种新的聊天界面，它可能成为用户愿意持续付费的工作产品。

一条由海外先行者验证的 Agent 路线，为什么在半年后表现为国内大厂的集中整合？这场竞争又会把企业软件和垂直 AI 产品推向哪里？

一、Claude 先验证的不是办公，而是一条 Agent 商业化路径

今天回看 Claude Code，很容易把它的成功简单归因于模型编程能力更强。但从产品和商业视角看，编程更重要的价值，是为 Agent 提供了一个罕见的理想环境。

编程任务通常有相对清楚的目标：实现一个功能、修复一个错误、重构一段代码，或者完成一组测试。Agent 可以读取代码库、修改文件、调用终端并运行测试，结果是否成立也能通过编译、测试、代码审查和实际运行获得反馈。任务价值高、工具环境相对标准化、成果可以被直接修改、结果能够验证，这几个条件恰好构成了完整的任务闭环。

这与普通聊天机器人存在本质区别。聊天机器人的基本交付物是一段回答，Claude Code 的交付物则可能是一个已经修改、可以运行并接受审查的代码库。前者主要出售信息与生成能力，后者开始按照任务交付创造价值。

Claude Code 提供的关键验证并不是“企业第一次愿意为 AI 付费”，而是更窄也更有价值的一层：模型获得环境和工具后，可以持续执行复杂任务，并通过交付可检查的成果形成一门规模可观的生意。

Cowork 随后把这套产品原语迁移到更广泛的知识工作。用户可以交付一个目标，让 Claude 在被授权的文件和工具中自行拆解任务、执行多个步骤，再产出文档、表格、演示文件或研究结果供人审查，而不只是告诉用户应该怎样做。Anthropic 对 Cowork 的产品介绍同样强调，用户把任务交给 Claude，由它跨文件和工具执行，再由人检查和调整结果。（Anthropic：Claude Cowork）

这也解释了为什么 Claude 先从编程切入，而不是一开始就覆盖“所有知识工作”。后者市场更大，却也更加模糊；代码反而是一个更适合验证任务规划、工具调用、成果修改、人工审查和商业模式的楔子。新品类常常不是先占据理论上最大的市场，而是先找到价值高、反馈快、结果可验证的窄任务，等执行机制跑通后再向外扩展。

二、半年延迟不是复制速度，而是从试验到收拢所需的时间

如果 Claude 已经提供了外部验证，为什么国内三家公司没有立即推出一套统一的 AI 办公产品，而是先经历多团队、多品牌和多入口并行？

因为复制一种产品形态，与确认一条公司级战略，是两件完全不同的事。

Claude 的成绩可以降低“这类产品是否可能产生真实使用和收入”的不确定性，却不能直接替国内厂商回答：用户更愿意使用独立 Agent，还是办公软件内嵌功能；个人付费能否转化为企业采购；本地文件、云文档、消息和企业数据库怎样连接；模型、办公、云和销售团队分别承担什么责任；多个相似产品最终应该淘汰、保留还是重新组合。

因此，前期多产品并行不一定都属于重复赛马。从《悟空上线仅四个月就“消失”，大厂为何急着整合 AI Work？》对几条产品线的梳理和公开定位看，有些路线更偏桌面文件与软件操作，有些负责 Agent 运行、技能与任务托管，有些依托协同软件处理组织身份、权限和安全。它们可能分别验证了完整企业任务中的不同部分。

晚点 LatePost 的调查呈现了这段从并行探索到资源收拢的过程：阿里内部一度存在 QoderWork、悟空和 MuleRun 三条智能体产品线；腾讯逐渐将更多产品和公司内部能力接入 WorkBuddy；字节则在产品侧与商业化侧同时调整飞书的归属。这些内部线索能够支持“三家公司正在从多线探索转向集中投入”，但不能证明它们采取了完全相同的战略，也不能证明所有调整都由 Claude 单独触发。

问题在于，任何一部分能力单独成立，都不足以完成企业任务的完整闭环。桌面 Agent 可以操作文件，却未必掌握组织身份和权威数据；办公平台拥有协作关系，却未必具备稳定的长任务执行能力；Agent 平台能够运行任务，却可能缺少企业入口、治理能力和销售交付体系。

阿里的整合尤其能说明这一点。QwenWork 的官方介绍并未将 QoderWork、MuleRun 和悟空简单描述成三款被淘汰的重复产品，而是明确表示，新平台建立在三者的核心能力之上，尝试统一桌面、云端和企业协同 Agent。与其把这次整合只理解为赛马结束，不如说前期分别验证的能力，到了需要重新组装的时候。（阿里云：QwenWork 公测）

WorkBuddy 的形成过程提供了另一个更具体的案例。Cowork 于 1 月 12 日推出；据 WorkBuddy 负责人汪晟杰公开回忆，他与团队在 1 月 17 日这个周末，基于此前已经搭建的 CodeBuddy Agent 架构，连续工作两天，完成并上线 WorkBuddy 0.01，随后首先投入腾讯内部使用。这里的“五天”指 Cowork 发布到团队开始周末开发的大致间隔，不能写成“五天后才完成整个产品”，更不能理解为腾讯在两天内从零复制了一套 Cowork。（对话腾讯 WorkBuddy 负责人）

WorkBuddy 能在一个周末做出 0.01，关键并不只是开发速度，而是团队已经有了 Coding Agent 的执行底座。进入新场景时，真正需要重做的是用户、任务、交互和安全边界，而不是从头再造一套 Agent。

春节后 OpenClaw 在国内的传播又进一步加快了市场教育和产品推进。据汪晟杰的回忆，WorkBuddy 内部版本早于 OpenClaw 在国内爆发；后者的热度则推动团队将项目正式纳入 CodeBuddy 产品家族，并由内部使用转向公开测试。OpenClaw 更适合作为加速信号，而不是本文时间线的起点。（对话腾讯 WorkBuddy 负责人）

当这些试验逐渐给出答案，多产品并行的成本也会开始超过探索收益：用户难以理解不同产品的边界，文档、消息和工作状态无法互通，底层能力与算力被重复建设，销售团队也很难向企业客户提供一套完整方案。此时，问题从“还有哪些形态值得尝试”，转变为“公司应该把资源集中到哪套体系上”。

这张时间线是本文根据公开事件作出的归纳。“半年”指 Cowork 发布到国内集中整合的大致时间窗口，不是固定的产业扩散周期，时间先后也不等同于确定因果。

半年延迟不是国内厂商复制产品所需的时间，而是从外部验证、内部试验走到能力与组织收拢所需的时间。

三、三家竞争的已经不是谁更会做 PPT

在多产品试验阶段，用户很容易从功能层面比较 AI 办公产品：谁生成的 PPT 更好看，谁读取 Excel 更准确，谁更擅长整理文件，谁能够控制浏览器和桌面应用。

这些差异仍然重要，但进入整合阶段后，它们已经不足以解释竞争格局。企业任务能否真正完成，至少同时取决于四组能力。

第一组是模型与 Agent 执行能力。模型需要理解目标、拆解任务、调用工具、维持长上下文，并在遇到错误时调整计划。模型能力还要与推理成本、速度和稳定性共同考虑，不能只看一次生成结果。

第二组是办公入口与组织上下文。AI 需要出现在用户原本工作的地方。钉钉、企业微信、腾讯文档、会议、飞书消息和云文档不仅是分发渠道，也保存着身份、协作关系、历史材料和任务状态。

第三组是企业系统连接与治理。Agent 需要连接 CRM、ERP、知识库、数据库和企业自建系统，同时处理权限隔离、审批、审计、操作回放和失败撤销。个人可以自行决定授权范围，组织则必须把这种判断写成统一规则。

第四组是销售、部署和持续交付。个人用户可以下载产品后直接使用，企业客户通常还涉及采购、账号管理、系统集成、知识迁移、培训和后续服务。产品功能接近时，谁能把 Agent 安全地装进客户的真实流程，可能比演示效果更重要。

这些能力补齐的是企业 Agent 的横向拼图，但个人产品的成功并不能直接外推到组织场景。个人 Agent 进入企业，不是把用户数量从一个人扩大到一百个人，而是需要跨过一道产品阶段门：

这是本文对个人 Agent 与企业工作系统关键差异的归纳，不是完整的企业 Agent 能力清单；具体要求还会随行业、任务风险和部署方式变化。

腾讯在 Productivity Agent Suite 中，将 WorkBuddy Enterprise、腾讯文档、会议上下文、Agent 开发与治理平台放入同一套产品体系；阿里计划让 QwenWork 进一步接入钉钉、企业数据库和业务系统；据晚点 LatePost 的调查报道，字节的调整则同时发生在飞书的产品侧与商业化侧。这些动作不能证明产品整合已经完成，却足以说明厂商正在沿着同一个方向补齐能力。

国内 AI 办公正在从模型或单点产品竞争，转向模型、办公入口、云、企业数据、治理和商业化能力的联合竞争。

这还不足以说明竞争已经“白热化”。产品发布和组织调整能证明投入正在加速，却不能证明企业付费、客户迁移、续约和价格竞争已经大规模发生。体系竞争已经开始，商业胜负仍远未确定。

四、这场竞争会怎样重新分配企业软件的价值

AI 办公的意义不只是出现几款新的办公产品。更深的变化是，企业软件不同层级的价值正在被重新定价。

通用生成与操作能力会越来越便宜

写一份普通文档、整理会议纪要、制作基础 PPT、分析常规表格、搜索资料和批量处理文件，曾经可以分别支撑多个独立 AI 产品。随着大模型和 Agent 平台将这些能力集成进基础产品，它们不会失去使用价值，却越来越难单独构成长久壁垒。

受到压力最大的，可能是那些既没有独立用户入口，也没有专有数据和深入工作流，主要差异仍停留在提示词、模型调用与界面包装的产品。

工作入口与组织上下文会升值

AI 办公平台争夺的并不只是首页流量。员工从一个入口发起任务时，平台可能同时知道他的身份、团队、历史文档、会议、消息、协作者和当前项目；如果结果也在同一环境中被修改、分享和归档，平台还能获得后续反馈。

这些上下文决定了 Agent 是一个需要用户不断解释背景的陌生助手，还是一个能够持续参与工作的组织成员。入口的稀缺性也不只来自用户每天打开多少次，而是它能否影响三个节点：任务在哪里发起、上下文从哪里获得、成果最终交付到哪里。

当用户习惯先把工作交给某个 Agent，这个入口还可能影响任务默认调用哪款模型、使用哪些软件、消耗哪家的 Token 和云资源，以及成果最终存放在哪个平台。它不一定拥有绝对控制权：大型企业仍会采用多模型、多云和多供应商策略，垂直业务系统也拥有自己的数据和规则。但即便只能影响部分默认选择，任务入口的商业价值也已经高于一个孤立的 AI 功能。

模型厂商、云厂商和办公软件公司真正希望争取的，是企业任务的默认调度权。这是本文根据模型、云、办公和商业化能力开始共同整合所作的推断，而不是已经发生的市场结果。

软件的操作层可能变薄，记录与规则层反而变厚

一种常见判断是，未来员工只需要和 Agent 对话，因此大量 SaaS 将被替代。但这个结论忽略了企业软件同时承担交互界面、事实记录和规则执行等不同职责。

以金融机构为例，客户经理未来可能减少进入多个页面查询客户信息、复制产品数据和整理沟通材料的操作。Agent 可以读取相关信息，生成一份带来源的准备稿，并在获得确认后创建后续任务。

但客户身份、风险等级、持仓、交易记录、产品状态、适当性规则、审批结果和对客沟通记录，仍需由权威系统维护。Agent 可以改变这些系统被操作的方式，却不能自行创造权威事实，也不能绕过业务规则和责任记录。

Agent 压缩的是一部分人工操作软件的价值，放大的则是软件作为事实、规则、权限和责任记录底座的价值。

这种价值迁移大致可以概括为：

这是本文针对企业办公和 B 端软件所作的归纳，不代表所有软件品类都会以相同方式变化。两侧也并非严格互斥：通用能力仍有价值，只是更容易被平台集成并压低溢价。

垂直软件需要重新选择自己的位置

当综合办公平台越来越强，垂直软件大致有三种位置可以选择。

第一种是继续掌握用户入口，自己提供行业 Agent 和完整工作台。这可以控制产品体验和客户关系，但也意味着要承担模型、基础设施、连接与治理成本，并与综合办公平台争夺用户的工作入口。

第二种是成为平台上的行业能力层，向通用 Agent 提供专业数据、Skills、业务规则和工作流。这可以借助平台的模型和分发，却可能让客户关系与议价权逐渐向平台移动。

第三种是继续掌握业务记录与交易系统，允许上层 Agent 通过接口调用，但保留对权威事实、确定性规则、审批、交易和审计的控制。此类系统未必直接拥有新的 AI 入口，却可能成为任何 Agent 都无法绕过的底座。

企业不必只选择其中一条路。真正需要回答的是：我们控制的究竟是用户入口、专业任务能力，还是不可替代的业务事实与交易记录？

收费方式也会随之调整，但未必出现席位费被全面取代的剧烈变化。更可能的组合是基础账号订阅、模型和工具调用额度、高价值任务包，以及企业连接、治理和实施服务。纯结果付费仍受责任归因限制，因为大部分企业成果由人、模型、数据和外部环境共同决定。

通用生成和软件操作会逐渐变便宜；入口、上下文、业务记录、治理与任务交付能力会变得更贵。

五、通用能力被平台吸收后，垂直 AI Builder 还应该做什么

如果通用搜索、文档生成、PPT 排版、浏览器控制和基础 Agent Runtime 都在被平台快速吸收，垂直 AI Builder 就没有必要继续重复建设这些能力。有限的产品和研发资源，更应该投向平台难以统一解决的需求判断、具体任务、行业上下文和责任链路。

从需求判断开始，而不是从模型能力开始

每次接到一个看似明确的 AI 或问答需求，都不能直接进入模型选型、Prompt 优化或 Agent 设计。首先要向上追溯：用户为什么提出这个需求，现有流程的真实痛点是什么，解决后会改变哪个业务结果；还要判断其中哪些环节适合使用生成式 AI，哪些更适合检索、规则、确定性计算、传统自动化或流程改造。

以“比较两只基金”为例，表面上是一个问答需求，背后可能是个人理解、内部研究、产品筛选、客户沟通或合规审核。不同任务不仅需要不同的数据、分析深度和后续流程，也对应不同的 AI 参与方式：有的适合检索后生成，有的依赖确定性计算，有的只能辅助专业人员判断，还有的并不适合交给生成式 AI。

AI Builder 的第一项工作，不是让模型开始回答，而是判断 AI 是否应该参与、参与哪一段，以及哪些环节必须保持确定性。

从角色助手收窄到可交付任务

确定了业务问题和 AI 的参与边界之后，才轮到产品形态。此时不宜立即设计一个覆盖所有工作的“客户经理助手”“投顾助手”或“运营助手”，而应先把需求收窄成一项可开发、可评测和可采购的完整任务。

例如：当市场出现重要变化时，读取客户持仓、产品资料和机构合规口径，生成一份带证据来源的客户沟通准备稿，由客户经理审核后使用，并将确认结果写入客户记录。

这个定义明确了触发条件、输入数据、权威来源、交付物、审核角色和后续系统，也让团队可以继续讨论哪些表达禁止出现、信息不足时是否反问、工具失败后如何处理。

“角色助手”描述的是愿景，“可交付任务”才是产品建设和评测的基本单位。

把任务知识沉淀成可执行、可验证的 AI 产品资产

大模型可以理解语言，却无法凭借通用训练自动知道一家机构内部的真实口径、数据优先级和责任边界。垂直 AI Builder 需要把这些知识沉淀成可维护的产品资产，而不是只保存在零散 Prompt 或个别业务人员的经验中。

对我当前接触的财富业务智能体 POC，最值得持续积累的是三类材料：

1. 行业任务地图：不同角色为什么发起任务，需要完成什么结果，任务依赖哪些前置条件，又会进入哪个后续环节；其中哪些步骤适合 AI，哪些必须由规则、系统或专业人员完成；
2. 评测集与 Bad Case：什么结果才算正确、完整和可用，依据是否可追溯，模型通常在哪里失败，失败后应该反问、拒绝、重试还是转人工；
3. 数据—权限—流程关系：每项任务可以读取什么数据、调用什么工具，哪些动作允许自动执行，谁负责审核，结果需要写回哪个系统。

这三类资产不能只停留在文档中，还需要转化为正式产品机制：任务地图定义触发条件、输入输出和 AI 的参与边界；评测集定义完成标准、证据要求和失败处理；数据—权限—流程关系则落实为授权、审批、审计、回退和系统写回。

这些资产不会因为底层模型从 Claude 换成千问、豆包或其他模型而失效，也更接近金融软件公司的长期竞争力。

连接现有业务链，而不是重新造一个工作台

垂直 Agent 的价值不一定来自新建一个独立聊天工作台。更现实的路径，是从既有业务系统读取权威事实，在用户熟悉的办公或业务界面中呈现结果，经专业人员确认后写回 CRM、工单或记录系统，再触发下一项工作。

只有当结果能够进入后续流程、形成责任记录并支持失败回退时，Agent 才不再只是一个生成界面，而成为真实工作系统的一部分。产品设计的重点也由“用户能否和 AI 对话”，转向“AI 能否在明确边界内参与任务，并与既有系统和人员完成交接”。

垂直 AI Builder 的工作，正是在业务任务和模型能力之间完成这层设计：识别值得解决的问题，划定 AI 的参与边界，组织所需的上下文、数据、工具和权限，再通过评测、人工审核与失败回退，让概率性的模型能力在可控条件下交付业务结果。

Claude 给国内厂商提供的，不是一套可以直接照搬的办公界面，而是一条已经获得外部验证的 Agent 扩张路径：先从价值高、结果可验证的窄任务切入，再把任务执行能力扩展到更广泛的知识工作。国内阿里、腾讯、字节的集中整合也说明，通用 Agent 一旦显示出商业可能性，平台厂商吸收基础能力的速度会很快，竞争随后会转向模型、入口、上下文、云、治理和商业化体系。

对垂直 AI Builder 来说，真正需要提前积累的，不是另一个通用入口，而是识别高价值任务与 AI 适用边界的能力，以及任务依赖的业务上下文、验证标准和责任链路。通用能力会越来越强，也越来越便宜；真正稀缺的，是知道应该完成什么、依据什么完成，以及完成之后由谁负责。

参考资料

一手文件与官方发布

• Anthropic：Series F 融资及 Claude Code 商业数据
• Anthropic：Claude Code 达到 10 亿美元年化收入运行率
• Anthropic：Claude 应用更新记录
• Anthropic：Claude Cowork
• 腾讯：Productivity Agent Suite
• 阿里云：QwenWork 公测

一手或近一手报道

• 晚点 LatePost：腾讯、阿里、字节的 AI 办公大战
• 对话腾讯 WorkBuddy 负责人
• 悟空上线仅四个月就“消失”，大厂为何急着整合 AI Work？