腾讯Agent工厂：从赛马机制到生产体系的战略跃迁
从赛马到工厂：腾讯Agent战略的悄然转向
2026年，中国桌面端Agent市场的竞争格局出现了一个耐人寻味的信号。易观分析的数据显示，6月份17款AI原生办公智能体的总访问量突破6000万次，其中腾讯的WorkBuddy以2097万次独占鳌头，甚至超过了第二名和第三名的总和。更值得关注的是，腾讯旗下还有CodeBuddy、QClaw和Marvis等多款产品跻身前十，它们并非同质化竞争，而是分别瞄准了软件研发、本地任务和操作系统交互等不同场景。
这一幕与几个月前各大厂商围绕Chatbot入口的激烈争夺形成了鲜明对比。彼时，行业焦点还集中在单一对话入口的流量争夺上，而如今，竞争的硝烟已经迅速蔓延至Agent领域。字节跳动正将Agent能力整合进豆包、飞书等高频应用，阿里则着手合并多款办公Agent并调整组织架构，两者都试图通过集中入口来提升效率。
腾讯却走出了一条不同的路径。它的Agent并未完全收敛于单一入口，WorkBuddy在办公市场领先，而CodeBuddy、QClaw和Marvis仍在各自的场景中深耕。这种多线并进的态势，很容易让人联想到腾讯历史上著名的“赛马”机制——让多个团队围绕同一需求竞争，胜者脱颖而出。
然而，如果Agent并非单一品类，而是AI时代的一种基础产品形态，那么腾讯在不同场景的布局，或许并非重复下注，而是对Agent生产体系的一种系统性构建。真正值得追问的是：腾讯究竟在如何“生产”Agent？
一款编程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工厂中的一条产品线。
模型、云、应用网络：腾讯的“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负责后续执行，文档承载协作成果，网盘保存内容资产，乐享再将其沉淀为组织知识。原本相对独立的办公产品，开始围绕“任务如何完成”重新分工。
这些产品的角色也随之发生变化。会议纪要和项目资料，可以成为Agent理解任务的上下文；文档、搜索和存储能力，可以成为Agent调用的工具；办公软件本身，则成为用户审核、修改和接收结果的界面。腾讯过去分别面向用户提供的软件，正在转化为Agent可以读取、调用和组合的能力。
类似的连接也出现在Buddy体系之外。2026年6月，元宝接入ima公开知识库。腾讯文档和微信读书负责输入内容，ima承担知识沉淀与检索，元宝可以调用其中的专业内容，WorkBuddy则参与资料整理和后续执行。过去分散在不同应用中的内容与知识，开始彼此流动。
至此，一套生产循环开始成形。以Buddy为代表是产品线，腾讯云是生产底座，应用网络则负责将Agent送入具体任务。三者彼此连接，共同勾勒出腾讯Agent工厂的基本轮廓。
大厂争夺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形态，而是一套能够持续生成、验证和筛选产品的机制。天下武功，唯快不破。当答案尚不明确时，寻找答案的速度，就变得格外重要。