腾讯是在“赛马”，还是在打造 “Agent工厂”？

文 / 绛枫

近期，易观分析发布的一张榜单，呈现出中国桌面端 Agent 市场一个颇为特殊的竞争格局。

2026 年 6 月，17 款桌面端 AI 原生办公智能体的合计访问量超过 6000 万次。其中，WorkBuddy 以 2097 万次位居第一，访问量甚至超过第二、第三名之和。

更值得注意的是，进入前十的腾讯产品不止一款。CodeBuddy、QClaw 和 Marvis 同样位居榜单前列。它们并非对同一产品的简单复制，而是分别面向软件研发、本地电脑任务和操作系统级交互等不同场景。

几个月前，各家公司还在围绕 Chatbot 入口激烈争夺。硝烟未散，竞争的重心却已迅速转向 Agent。

字节跳动正在将 Agent 能力向豆包、飞书等高频入口聚拢。阿里则着手整合多款办公 Agent，并同步调整相关组织。两家公司都试图通过集中入口、收拢产品边界，提升产研效率。

与字节和阿里不同，腾讯的 Agent 并未完全走向单一入口。WorkBuddy 已在办公智能体市场取得阶段性领先，CodeBuddy、QClaw 和 Marvis 仍在各自对应的任务场景中继续发展。

这容易让人联想到腾讯惯用的“赛马”机制。

“赛马”的前提，是多款产品围绕同一需求、争夺同一个入口。如果 Agent 并非单一品类，而是 AI 时代的一种基础产品形态，那么它分别进入研发、办公等场景，就未必是重复下注，而更像是对不同场景体验的重塑。

真正值得追问的是：腾讯正在以怎样的方式生产 Agent？

1、一款编程Agent，如何长出一个产品家族？

在腾讯的 AI 生态中，一条以“Buddy”为名的 Agent 产品谱系正在逐渐成形。

Buddy 原意为“伙伴”，最初只是 CodeBuddy 名称中的一个产品后缀。2023 年，AI 代码助手 CodeBuddy 以 IDE 形态推出，并开始在腾讯内部推广使用。早期，它主要承担代码补全、技术问答和错误诊断等辅助工作。

随着软件开发智能体 Craft，以及 MCP、CLI、Skills、Agent SDK 等能力陆续接入，CodeBuddy 开始能够读取项目、拆解任务、调用工具、执行操作并验证结果。它也由“帮助开发者写代码”，逐步走向“自主完成研发任务”。

在这一过程中沉淀下来的，不只是代码生成能力，还有一套可以复用的 Agent 执行框架。

编程之所以成为起点，并非偶然。代码库、终端和测试系统，为 Agent 提供了一个可操作、可反馈、可验证的环境；代码本身又能被用来创造新的工具和工作流。

因此，Coding Agent 不仅可以完成研发任务，也能够参与生产其他软件乃至其他 Agent。

Anthropic 将 Claude Code SDK 更名为 Claude Agent SDK，背后也是类似的逻辑：驱动编码产品的工具系统、Agent Loop 和上下文管理机制，已经能够被迁移到研究、内容处理和个人助理等非编程任务中。随后推出的 Cowork，则进一步将类似的执行方式带入知识工作。

WorkBuddy 的出现，验证了同样的迁移也在腾讯内部发生。

腾讯于 2025 年第四季度启动 WorkBuddy 项目，并在 2026 年 3 月正式发布。据腾讯云相关负责人介绍，WorkBuddy 最初的内测版本，是一名产品经理借助 CodeBuddy 和智能体 SDK，用一个周末搭建出来的。

这个细节的意义，不只在于开发速度。CodeBuddy 既提供了 WorkBuddy 所依赖的执行能力，也直接参与了这款产品的生产过程。

WorkBuddy 保留了 CodeBuddy 沉淀下来的任务编排、工具调用和执行机制，再围绕办公任务重新组织 Skills、工具接口和产品交互。一款编程 Agent，由此生长为一款办公 Agent。

这意味着，共同的执行框架不仅能够脱离代码环境，也可以显著降低生产下一款 Agent 的成本。

此后，这种迁移方式迅速走向标准化。

2026 年 5 月发布的 DataBuddy，被腾讯称为“Buddy 家族的第三位成员”。它在底层继承了 WorkBuddy 的 Harness，再通过 Skills 注入腾讯云在大数据领域积累的专业经验，并连接 WeData、DLC 等业务系统，由此获得数据分析、数据治理和数仓工程等能力。

从 CodeBuddy 到 WorkBuddy，再到 DataBuddy，腾讯逐渐形成了一套生产垂直 Agent 的公式：

垂直 Agent = 通用 Harness + 专业 Skills
+ 行业知识 + 业务系统 + 交付界面

Harness 负责理解任务并组织执行，Skills 提供专业流程与判断规则，业务系统则让 Agent 能够真正采取行动。

Buddy 所复制的单位，也由一项具体功能，转变为一整套岗位能力。

6 月发布的 LearnBuddy 延续了这一思路。作为“Buddy 家族首个行业应用”，它建立在与 WorkBuddy 同源的框架之上，再加入教育知识、科研 Skills、多智能体协作和长期记忆，从而进入教学、学习与科研场景。

这种生产方式并不局限于以 Buddy 命名的产品。

由 CodeBuddy、WorkBuddy 团队打造的创意设计智能体 Miora，与二者共享底层架构，同时加入图像、视频、3D 和 UI 设计等专业子 Agent，以及面向创意工作的 Skills。

“AI 航海家+”则以 WorkBuddy 智能体平台为基础，叠加七国专业语料和 22 位专家智能体，形成一套面向企业出海的解决方案。

由此，Buddy 不再只是一个产品后缀。它正在成为腾讯 Agent 工厂中的一条产品线。

2、模型、云、应用网络，腾讯的“Agent工厂”如何运转？

不过，一条能够反复复制的产品线，还不足以构成完整的生产体系。

更重要的变化在于，Buddy 产品中经过验证的能力，正在走出具体产品、进入腾讯云，并与腾讯既有的应用网络连接起来。

最直接的信号是 WorkBuddy Managed Agents。它同样基于 WorkBuddy Harness 构建，将原本服务于 WorkBuddy 的任务编排、记忆和执行能力封装为云端服务，再与腾讯云的算力、沙箱、安全和治理能力结合。企业客户据此创建的 Agent，还可以被直接分发至 WorkBuddy 工作台。

这改变了 WorkBuddy 与腾讯云之间原有的关系。

过去，WorkBuddy 是一款生长在云基础设施之上的产品。现在，它在真实场景中得到验证的 Agent 内核，又被抽取出来，成为其他 Agent 可以复用的公共能力。

云生成产品，产品再反哺云。腾讯的 Agent 生产体系，在这样的循环中逐渐成形。

腾讯云本身也在围绕 Agent 重新组织。

2026 年 3 月，腾讯云首次发布 Agent 产品全景图，将原本分散的模型、基础设施、技能、应用和安全能力纳入同一体系。TokenHub 统一接入混元及第三方模型，Agent Runtime 提供专门的运行环境，ADP（腾讯云智能体开发平台）则覆盖 Agent 的开发、连接、运行和治理。

在这套体系中，模型成为 Agent 可以灵活选择的智力供给，Runtime 承载具体任务的执行，开发平台则进一步将知识、工具和业务系统组织成可用的应用。

腾讯内部由此形成了两条彼此连接的生产路径。

一条以 Buddy 为代表，将公共能力封装成用户可以直接使用的 Agent；另一条以 Agent Runtime、Managed Agents 和 ADP 为代表，把产品中积累的 Agent 能力转化为企业和开发者可以调用的基础设施。

前者持续带来真实任务与产品反馈，后者则不断降低新 Agent 的生产和运行成本。两者共同构成一个“应用—基础设施”飞轮。

放在整个行业中看，这与微软依托 Copilot、Microsoft 365 和云平台打通企业任务的思路类似。但腾讯的现实起点依然不同：

微软拥有高度统一的生产力套件和企业软件体系；腾讯面对的，则是一个体量庞大、入口众多，且分属于不同场景的产品网络。

因此，腾讯并没有简单地用一个 AI 入口取代所有应用，而是在尝试建立一层共享的 Agent 执行能力，让原本相互独立的产品，逐渐成为 Agent 可以理解、调用和组合的组件。

腾讯原有的办公与内容产品，也开始成为 Agent 理解任务、调用工具和交付结果的空间。

Agent Suite 以 WorkBuddy 为工作台中枢，通过 One ID 连接腾讯文档、腾讯网盘和腾讯乐享。腾讯文档推出的“人机双写”功能，则接入了 WorkBuddy 的统一 Agent 内核。AI 不再停留在编辑器外围提供问答和建议，而是直接进入文档、PPT 和表格的生产过程。

Workbuddy“人机双写”功能示意

腾讯会议、腾讯网盘和腾讯乐享也开始进入同一条任务链：会议产生讨论内容和任务信息，WorkBuddy 负责后续执行，文档承载协作成果，网盘保存内容资产，乐享再将其沉淀为组织知识。

原本相对独立的办公产品，开始围绕“任务如何完成”重新分工。

这些产品的角色也随之发生变化。会议纪要和项目资料，可以成为 Agent 理解任务的上下文；文档、搜索和存储能力，可以成为 Agent 调用的工具；办公软件本身，则成为用户审核、修改和接收结果的界面。

腾讯过去分别面向用户提供的软件，正在转化为 Agent 可以读取、调用和组合的能力。

类似的连接也出现在 Buddy 体系之外。

2026 年 6 月，元宝接入 ima 公开知识库。腾讯文档和微信读书负责输入内容，ima 承担知识沉淀与检索，元宝可以调用其中的专业内容，WorkBuddy 则参与资料整理和后续执行。过去分散在不同应用中的内容与知识，开始彼此流动。

至此，一套生产循环开始成形。

以 Buddy 为代表是产品线，腾讯云是生产底座，应用网络则负责将 Agent 送入具体任务。三者彼此连接，共同勾勒出腾讯 Agent 工厂的基本轮廓。

3、大厂争夺Agent，开始比拼生产体系

Agent 仍处于产品形态快速变化的阶段。现阶段的比拼，首先是一场探索效率的竞速。

决定竞争力的，不只是能否推出一款成功产品，还包括能否以较低成本并行验证不同场景，迅速将模型和工具能力转化为产品，并根据真实使用反馈持续调整。

过去半年，字节跳动没有大规模推出独立 Agent，而是将相关能力集中到少数高频入口中迭代。

豆包从聊天助手扩展到任务模式和专业版订阅，不断调整自身的交互方式和任务边界；飞书则将 Agent 嵌入群聊、多维表格和企业知识等既有场景。对字节而言，Agent 探索更多发生在主产品内部，试验的基本单位是新的模式、功能和工作流。

阿里推出的独立产品相对更少，近期的重点则是从产品架构和组织架构上进一步收敛。

QoderWork、MuleRun 和悟空被整合为千问办公。这次整合既压缩了重复的产品与组织边界，也试图让办公 Agent 进一步连接钉钉以及阿里体系内的商业服务。

腾讯采取了另一种方式。

它没有将所有 Agent 能力都收进 WorkBuddy、微信或元宝，而是通过 Buddy AI、Agent Runtime、ADP 和 TokenHub，集中建设模型接入、运行环境、任务执行和安全治理等公共能力；与此同时，腾讯文档、腾讯会议等业务仍在分别探索 Agent 与各自场景的结合方式。

由此，腾讯形成了一种“底座能力集中化、场景应用去中心化”的结构。

统一底座能够减少重复建设，降低新 Agent 的启动成本；分散在各个业务中的团队，则可以利用自身掌握的用户、数据和流程，提高对具体场景的命中率。

如果说移动互联网时代的字节跳动，通过共享算法、流量分发和增长体系，建立了一座集中化的“App 工厂”；那么，腾讯正在组织的，则是一座更加去中心化的 Agent 工厂。

前者复制的是一套从内容供给、用户获取到商业化的完整产品机制；后者复制的，则是 Harness、Runtime 和 Skills 等 Agent 执行能力。至于具体产品解决什么问题、以何种方式交付，仍由不同业务团队在各自场景中定义。

这种差异也源于 Agent 本身的特殊性。

App 通常拥有相对完整的产品边界，而 Agent 需要读取业务上下文、调用工具，并进入真实流程。不同场景中的数据权限、专业规则和交付标准，很难由一个中心团队统一规定。

因此，Agent 工厂可以集中建设底层能力，却必须把场景探索留给最接近用户的位置。

Agent 时代的终局，究竟是一个超级入口吸收所有场景，还是一群专业 Agent 重新组织软件生态？

腾讯总裁刘炽平在腾讯 2026 年第一季度财报电话会上，将 Agent 的发展类比为互联网的演进。

互联网早期曾由浏览器和搜索引擎承担强入口，但随着服务数量增加，网站、应用和移动端产品仍在持续分化。大模型市场已经呈现出类似的特征。不同模型分别擅长对话、代码和多模态任务，开源与闭源模型长期并存，单一模型尚不足以满足全部需求。

Agent 可能进一步强化这种分化。不同公司和应用可以拥有自己的 Agent，Agent 再根据具体任务选择模型、读取文件、调用工具并连接业务系统。

腾讯当下押注的，未必是某一种确定的 Agent 形态，而是一套能够持续生成、验证和筛选产品的机制。

天下武功，唯快不破。当答案尚不明确时，寻找答案的速度，就变得格外重要。