独家｜上线3个月、1200万DAU，WorkBuddy是怎么炼成的？

2026年7月，腾讯内部开始讨论，上线仅数月的WorkBuddy，能不能冲进今年的「名品堂」？

「名品堂」是腾讯内部对里程碑式产品的最高奖励之一。它并非每年颁发。自2015年设立以来，微信支付、王者荣耀、微信小程序、腾讯视频、微信视频号等产品先后入选。2025年度，腾讯会议和企业微信又成为新的成员。

这份名单横跨游戏、内容、支付和企业服务，看似没有统一标准，但有一个隐秘的共同点：它们在某个关键节点上，为腾讯重新拿到了一张门票。微信支付补齐了交易闭环，小程序建立了服务分发体系，视频号补上了微信生态的内容短板，企业微信和腾讯会议则让腾讯在产业互联网与远程协作中拥有了稳定支点。

因此，WorkBuddy是否配得上「名品堂」，真正要回答的并不是它有多少用户，而是另一个问题：在大模型重写人机交互方式的窗口期，它能不能替腾讯拿下办公Agent的入口。

至少从增长速度看，它已经拿到了候选资格。

3月9日，WorkBuddy正式公测。上线第二天，请求量迅速冲高，核心服务一度承压，团队随后将容量紧急扩充十倍。

到6月，第三方机构统计WorkBuddy全平台月活（MAU）已达2000万，日活（DAU）突破1300万，其中PC端日活超过200万。

易观分析

更恐怖的是用户黏性，其DAU/MAU比率稳定在65%至75%之间，而海外办公巨头Slack在最巅峰时的黏性长期也仅为65%至70%。同时，WorkBuddy桌面端用户占比高达92%，表明它的核心场景已死死锚定在PC桌面。

7月，腾讯云副总裁、CodeBuddy与WorkBuddy负责人刘毅对外表示，团队只是“暂时跑赢半个身位”。

“半个身位”的说法确实更符合行业所处的阶段。2026年上半年，中国办公Agent突然变成一条拥挤的赛道。阿里整合千问办公，字节在Trae、扣子和豆包专业版之间布阵，百度推出DuMate，月之暗面上线Kimi Work，智谱、MiniMax等模型公司也在向桌面和工作流延伸。大家争夺的已经不是聊天框里的一次问答，而是谁能进入用户的文件、浏览器、会议和企业系统，接管一段完整的工作。

WorkBuddy是目前冲得最快的一款。但为什么偏偏是它？这需要先回到一款更早、适用范围也更窄的产品CodeBuddy。

WorkBuddy官网：AI原生桌面智能体工作台，“Work Smart, Not Hard”

汪晟杰，从代码场景开始

要理解CodeBuddy为什么会成为WorkBuddy的起点，需要先理解产品负责人汪晟杰。

他的履历，几乎串起了过去二十年企业软件的几次形态变化。他做过PowerDesigner核心开发，在Sybase研究数据库，参与过SuccessFactors HCM系统，也曾在Autodesk负责BIM软件架构。后来，他加入Teambition担任产品负责人，又在腾讯云陆续负责Cloud Studio、CODING DevOps等开发者产品。

Teambition后来被阿里巴巴收购，创始人齐俊元此后曾负责豆包PC端，随后再次创业。多年以后，这批做过协作软件的人，又在不同公司相继进入AI桌面与Agent赛道。人事流动背后，是同一个产品命题在不同技术周期里的反复出现：如何把复杂的专业工具变得足够简单，让用户不必理解系统内部的全部细节，也能完成工作。

汪晟杰曾多次提出，希望“让写代码像写文档一样简单”。大模型出现后，这句话才第一次具备了明确的技术路径。

2022年前后，腾讯开始持续投入AI Coding；2024年5月，CodeBuddy作为AI编程助手对外发布；2025年7月，它升级为CodeBuddy IDE，尝试用自然语言串联产品构思、设计、编码和部署。到2025年下半年，团队又将能力延伸到终端形态的CodeBuddy Code。

CodeBuddy的意义并不只是增加一个代码补全工具。团队选择Coding，是因为它可能是验证Agent能力最合适的起点。

代码同时具备复杂性和相对明确的反馈。模型写出的程序能否编译、测试是否通过、性能有没有改善，都可以被验证。相比“写一份更有感染力的报告”，编译器不会因为审美差异给出模糊判断。模型必须理解项目、定位文件、调用工具、修改内容、运行测试，并在失败后读取错误、继续修复。

在这条执行链上，生成代码只是其中一步。更难的是如何管理上下文，怎样让模型正确调用工具，如何维持长时间任务循环，又怎样在出错后恢复。也正是在这些问题上，CodeBuddy逐步搭建起Agent Runtime、上下文工程、MCP协议栈、Skills体系、隔离沙箱和模型适配层。它的软件开发工具包最初就被命名为“Agent SDK”，而不是“Code SDK”，说明Coding从一开始就被视为Agent能力的第一块试验田，而非最终边界。

截至2026年初，CodeBuddy Code已覆盖腾讯内部约1.2万名工程师。团队对外披露，部分项目中AI生成代码的比例达到九成。腾讯内部长期存在的“吃狗粮”传统，使这套系统在进入办公场景之前，先在大型代码仓库、真实生产流程和高频调用中接受了压力测试。

但推动产品越过编程边界的，并不是一份自上而下的规划，而是一些“不按说明书使用产品”的人。

腾讯研究院的非技术员工开始用CodeBuddy检索论文、整理资料，运营和产品人员也尝试让它处理文件与报告。他们不写代码，却绕过IDE的专业界面，把一款编程工具用成了通用工作台。这些行为让团队意识到，用户在意的并不是代码本身，而是最终能否得到一份可用的结果。代码只是机器完成任务的一种中间语言。

2026年1月，Anthropic推出Claude Cowork，把Claude Code的Agent能力迁移到普通知识工作者的桌面，恰好从外部验证了同一方向。它给出的定义很直接：Claude Code for the rest of your work。

Claude Cowork：“Claude Code for the rest of your work”，从面向工程师到面向所有人

汪晟杰随即决定做一个面向非技术用户的版本。1月17日，一个周六，他和几名核心成员连续工作两天，完成了WorkBuddy 0.01原型，随后直接放到腾讯内部测试。团队用Demo证明，同一套Agent底座只要换掉IDE界面，再增加面向办公场景的Skills，就能服务另一批用户。

“48小时完成原型”后来成为WorkBuddy早期故事中最容易传播的部分，但这并不是一次真正意义上的从零起步。如果没有此前对CodeBuddy的投入，一个周末最多只能完成演示。正因为上下文、任务循环、沙箱和工具体系已经存在，团队才能把主要精力放在界面、交互和使用场景的迁移上。

WorkBuddy也不是腾讯内部唯一一条面向个人Agent的路线。

几乎在同一时间，腾讯电脑管家团队基于开源框架OpenClaw开发了QClaw。它把原本需要命令行配置的OpenClaw封装成本地安装包，主打“三步安装”和微信远程控制电脑。3月9日前后，QClaw启动测试，WorkBuddy也正式公测。两款产品由不同团队推出，却指向相近的人群和场景，由此形成了一轮内部赛马。

两条路线的出发点并不相同。QClaw选择利用已经成熟的开源生态，优势是部署快、微信入口直接、能够迅速承接当时的“养龙虾”热潮；WorkBuddy则建立在CodeBuddy多年积累的自研Agent架构之上，起步更重，但在上下文管理、任务恢复、企业权限和后续扩展上拥有更完整的控制权。

QClaw的远程通信渠道设置，支持微信、企业微信、QQ等入口。来源：腾讯QClaw官方发布资料

早期看，QClaw更像一条快速响应市场的捷径，WorkBuddy则更接近一项长期工程。随着使用深入，差异开始显现：个人用户需要的是简单安装和远程控制，企业真正关心的却是任务能否稳定完成、数据是否留在可控范围内、执行过程能否审计，以及Agent能否接入既有系统。后者恰好是CodeBuddy路线长期积累的部分。

据接近腾讯的人士透露，在后续的内部赛马中，QClaw没有成为集团办公Agent的主线，相关团队、产品能力和微信入口逐步向WorkBuddy体系合并。

3月9日公测后，WorkBuddy个人版在3月至6月累计迭代43个版本，平均不到两天更新一次。早期团队主要修复稳定性和容量问题，随后补充专家中心与MCP生态，再向小程序、海外版、企业版和政务场景延伸。Codex或Claude Code出现新的交互和执行机制后，WorkBuddy往往也能较快完成适配。与其说这是对单项功能的追赶，不如说团队已经建立了一条从模型评估、底层适配到产品发布的高频迭代链路。

迭代速度背后，是腾讯内部资源开始向一条主线集中。公开与采访材料对团队人数存在不同口径，较稳妥的说法是：WorkBuddy核心团队已经扩展至百人规模，外围还有来自腾讯文档、腾讯会议、元宝以及QClaw等业务的协同力量。

据接近团队的人士透露，WorkBuddy目前在腾讯内部被列为最高优先级的AI项目之一，在部分资源排序中仅次于微信。它的考核顺序也反映了现阶段的任务：用户留存和活跃度权重最高，其次是Token消耗，再往后才是企业与政务场景的实际落地；短期利润并非主要考核目标。

这并不意味着腾讯已经确认WorkBuddy能够成为办公入口，而是说明公司愿意先为这个可能性投入资源。元宝未完全达到腾讯对C端AI入口的预期后，WorkBuddy提供了另一条路径：不再从聊天和内容消费切入，而是从任务执行进入用户桌面。

由此，WorkBuddy完成了从小团队原型到集团级项目的转换。但资源、合并和高频迭代只能解释它为何获得先发位置，不能保证它能把任务稳定做完。要判断这条路线是否成立，还要回到它从CodeBuddy继承的Harness。

Harness引擎：给Agent套缰绳

过去两年，AI应用需要解决的问题不断从单次生成向完整执行链条延伸。最初是Prompt Engineering：如何更准确地向模型提问。随后是Context Engineering：如何把正确的信息，在正确的时间放进模型的上下文。到了Agent阶段，问题进一步扩展为：如何给模型配置工具、环境、记忆、反馈、权限和质量门槛，让它在长时间、多步骤任务中保持方向。

围绕模型建立的这套工程系统，通常被称为Harness。

2026年2月，OpenAI公开总结其“Harness Engineering”实践。LangChain随后披露，在不更换底层模型的情况下，仅通过优化验证、追踪和上下文机制，就把智能体在Terminal Bench 2.0上的成绩从52.8提高到66.5。

两者都指向同一个判断：当领先模型之间的能力差距缩小时，应用能否把模型能力稳定释放出来，越来越取决于Harness。

Red Hat对Harness有一个精确定义：sandbox是subtractive（减法式）的，你在移除能力以降低风险；Harness是additive（叠加式）的，你在叠加知识与工具以增加能力。Sandbox constrains，Harness enables。

可以把模型理解为能力较强、但表现仍不稳定的执行者，Harness则规定它去哪里找资料、可以使用哪些工具、失败后如何重试、哪些动作需要审批，以及怎样判断任务已经完成。

WorkBuddy的Harness大致可以拆成五个部分。

• 首先是编排。系统将用户目标拆成任务链，并决定由单一Agent顺序执行，还是由多个Agent并行处理。

• 其次是上下文工程，它不是把所有文件粗暴塞进窗口，而是先查看目录和结构，再逐层定位关键材料。

• 第三是Hooks，在删除文件、发送消息、支付等高风险节点插入确认和拦截。

• 第四是分层记忆，分别保存当前会话信息与长期偏好。

• 第五是Action，通过MCP和连接器调用腾讯文档、企业微信、浏览器及其他工具。

沙箱和Harness在这里扮演相反但互补的角色。沙箱做减法，限制Agent能够访问的文件、网络和系统权限；Harness做加法，给它补充知识、工具、记忆与反馈。前者解决“不能做什么”，后者解决“怎样把事情做成”。

例如，当用户要求“整理本周会议纪要并发送给项目组”时，生成摘要只是其中一步。系统还要找到正确的会议记录，区分决策与讨论，按既定格式整理，并识别对应的项目群。发送属于外部写操作，通常还需要在最后一步取得确认。任何一个环节出错，都可能影响最终结果。

办公Agent与聊天产品的差别也在这里：错误回答主要影响信息判断，执行错误则可能直接触发文件修改、消息发送或其他现实操作。

WorkBuddy采取“模型不可知”的策略，可以根据任务在混元、DeepSeek、Kimi、GLM、MiniMax等模型之间切换。这让它不必被单一模型的能力上限锁住，也更接近一个中立的AI工作台。

但“模型不可知”并不意味着没有模型包袱，而是WorkBuddy主动承担了路由责任。不同模型的价格、延迟、上下文能力和工具调用稳定性并不相同。当Auto模式为用户选择了一个昂贵模型却没有显著提高结果质量，用户只会认为WorkBuddy消耗太快；当一次任务失败，用户也不会区分错误来自模型、连接器还是上下文，他只会认为产品不好用。

因此，多模型接入本身很难构成长期优势。更重要的是，WorkBuddy能否从真实任务中积累有效的路由和恢复经验：不同任务适合什么模型，哪些步骤容易失败，失败后应该重试、切换模型还是向用户追问。

模型API可以被其他产品接入，任务轨迹、失败记录和修复策略则需要长期积累。不过，数据积累并不会自动转化为产品改进。如果平台只知道用户消耗了多少Token，却不知道结果是否被采用、修改或丢弃，调用量本身无法说明任务质量。只有建立“执行—反馈—修正”的闭环，Harness才可能随使用规模扩大而改善。

因此，WorkBuddy的长期优势不取决于接入模型的数量，而取决于能否持续降低同类任务的失败率。但即使单个任务越来越稳定，也只解决了个人使用的问题；当Agent进入企业，它还要面对组织层面的约束。

WorkBuddy Agent Harness的两个目标五个层次：运行环境层、引导层、反馈层、编排层、迭代层

从0.01到3亿ARR：一个产品的三个月狂奔

WorkBuddy上线后，人均Token消耗在三个月内增长超过十倍。但刘毅观察到，个人效率的提高，并没有自动转化为组织效率的同步上升。

他把这种矛盾概括为六个字：“个人很爽，组织无感。”

这也是企业应用AI时常见的落差。

一个员工原来需要两小时完成的PPT，现在二十分钟就能生成，并不意味着项目交付周期会同比缩短。材料仍可能等待其他部门提供，权限仍需要申请，生成结果也需要审核。当内容生产速度普遍提高后，审核和决策反而可能成为新的瓶颈。

个人Agent优化的是一个人的操作效率，企业Agent必须改造任务在组织中的流动方式。二者之间隔着权限、知识、责任和协同四道墙。

WorkBuddy企业版因此不再只是给个人版增加一个管理后台，而是试图建立三层协同。

第一层是把人和数字员工放入同一个项目空间；第二层是共享项目级上下文、Skills和连接器，让任务过程和产物能够沉淀；第三层是任务级交接，使同事或Agent接手工作时能够继承完整上下文。Admin后台则负责统一管理权限、模型预算、知识库和数字员工版本。

Managed Agents进一步把这种能力产品化。每个数字员工运行在独立环境中，可以保存检查点、恢复任务、维护长周期Session，并在空闲时休眠。企业还可以像管理软件版本一样管理数字员工：发布v1.1，同时保留v1.0作为回退选项。

这些功能不如“一句话生成PPT”直观，却直接影响Agent能否进入生产环境。

当Agent接入财务、客户和供应链系统时，稳定性、权限边界和责任记录会成为基本要求。企业需要知道它访问过什么、执行过什么、为何执行，以及出现问题后如何恢复。因此，可控、可观测、可回退和可审计并不是附加功能，而是生产部署的前提。

WorkBuddy企业版的方向也由此变得清楚：把分散在员工电脑上的个人Agent，纳入企业统一的权限、知识和流程管理。

如果这种管理方式能够落地，企业购买的就不只是软件席位，还包括一套重新分配任务的机制。财务Agent可以负责对账，销售Agent维护CRM，研究Agent追踪行业变化；员工则更多地定义目标、处理例外并承担最终责任。企业管理的对象可能由单纯的人，扩展到人与Agent的组合。

从这一角度看，WorkBuddy试图进入的并非单一办公环节，而是企业任务的分配与执行层。

把Agent纳入企业管理，只解决了“如何管”的问题；要让它真正参与工作，还要解决“能接入什么”的问题。这恰好是腾讯现有产品生态能够提供的条件。如果只比较模型，腾讯的优势并不明显。混元仍要面对DeepSeek、Kimi、GLM、MiniMax以及海外模型的竞争。但在企业执行层，腾讯同时拥有企业微信、腾讯会议、腾讯文档、腾讯云、微信支付，以及覆盖大量政企客户的销售与交付体系。

这些产品分别占据沟通、会议、文件、算力和交易节点。WorkBuddy可以把它们串成一条任务链。

传统办公软件出售的是工具：Word负责写作，Excel负责计算，IM负责沟通，员工在工具之间搬运信息。Agent出售的则是一种新的组织接口：员工只描述目标，系统决定调用什么模型、读取哪些材料、使用哪些工具，以及把结果交付到哪里。

如果WorkBuddy能够承担这层接口，它就不只是企业微信和腾讯文档之外的一个应用，还会负责在不同工具之间调度任务。过去，用户通过菜单和按钮操作企业软件；在Agent界面中，用户先描述目标，再由系统选择工具和执行顺序。两种方式对应的是不同的软件入口。

微信支付AI专属卡体现了这种延伸。它不直接开放用户主账户，而是让用户单独转入资金、设定限额，并对关键交易进行确认。相比信息检索和文档生成，支付意味着Agent开始参与有实际后果的操作，也对权限和风险控制提出了更高要求。

不过，生态导流也会影响对产品增长质量的判断。

如果WorkBuddy的相当一部分企业客户来自企业微信、腾讯文档和腾讯云的交叉销售，快速获客既说明腾讯生态能够降低销售成本，也留下一个问题：企业是在独立采购WorkBuddy，还是把它视为现有腾讯产品的一项增值能力？

未来，企业微信、飞书和钉钉都可能把Agent变成基础功能。若WorkBuddy不能显著提高跨系统任务的完成率，它就可能被重新吸收为腾讯办公体系中的一个功能模块。

因此，需要从两个方向观察其产品独立性：在腾讯生态之外，它是否仍有足够的任务完成能力；在腾讯生态之内，它是否能提供企业微信和腾讯文档单独无法实现的跨系统协同。前者影响市场边界，后者影响它在腾讯内部的产品定位。

产品独立性最终还要接受付费意愿的检验。2026年4月底，腾讯云调整WorkBuddy定价：SaaS企业版由78元/人/月上调至198元，专有云企业版由158元上调至316元。市场信息显示，产品已经获得数千家企业客户和十余万付费席位。按照席位数与公开价格简单年化，可以得到接近3亿元的收入规模，但这一数字更适合作为估算，而不是已经确认的财务口径。

即便如此，这组数据仍可以说明两个问题。

第一，部分企业愿意为Agent支付高于传统协作工具的价格，因为采购内容并非一个聊天入口，而是模型额度、连接器、知识库、权限管理、数字员工与部署服务的组合。

第二，席位订阅未必是唯一的收费方式。随着任务量提高，模型调用、数字员工、私有化部署、行业Skills和交易服务都可能形成增量收入。传统SaaS主要按照使用人数收费，Agent产品未来也可能按照任务量或资源消耗收费。

这可以解释腾讯为什么重视Token消耗。Token既是成本，也能在一定程度上反映Agent的使用强度。消耗增加，通常意味着用户交给系统的任务更多或更复杂。

但Token不能单独作为效率指标。消耗增加可能来自任务变复杂，也可能来自模型低效、重复调用或错误循环。如果成本增长十倍，任务结果却没有相应改善，使用量的增长就缺乏商业意义。

因此，更有价值的指标是单位任务的成功率和经济性：完成一份合格报告需要多少成本，处理一张订单能够节省多少人工时间，一个数字员工可以稳定承担多少重复流程。

从企业采购角度看，可核算的工作结果最终比调用量更重要。而这又把问题带回产品最基础的一层：WorkBuddy交付的结果究竟有多可靠。

未完成的战斗

一份面向WorkBuddy的第三方评测设计了70道题，覆盖Word、Excel、PPT、浏览器操作、代码、深度研究和设计七个方向。产品平均得分为2.31分，满分4分。其中Word达到2.85分，设计类只有1.45分。

这份成绩单呈现了WorkBuddy现阶段较为具体的能力边界：它可以在不少办公任务中交付可继续加工的半成品，但距离稳定产出无需人工修改的结果仍有距离。它在结构化整理与信息转换方面相对稳定，在审美、复杂表格、跨系统操作和开放性判断方面表现较弱。

腾讯最近发布的WorkBuddy Bench，也在尝试解决Agent评测失真的问题。它不再只测单轮回答，而是把代码、网页、办公和安全任务放进可复现环境，通过隐藏测试、规则检查和基于证据的评判验证最终产物。这代表Agent竞争的评价标准正在发生变化：从“说得像不像”，转向“事情到底有没有做成”。

对WorkBuddy而言，更现实的目标不是在所有场景中达到同样水平，而是以通用入口的形式，稳定承担不同Agent之间的调度与管理。

汪晟杰曾说，AI时代每个人都应该有“两个自己”：一个负责干活，一个负责生活。过去，这句话更像一种关于效率的设想；随着Agent进入企业，它开始对应一个具体的组织问题：当越来越多执行环节交给机器后，人应该承担什么工作？

但无论如何，WorkBuddy 已经证明：在办公 Agent 这场关键的入场券争夺战中，腾讯没有掉队。

参考来源

1. 腾讯集团官网：《Tencent Cloud Debuts Productivity Agent Suite》，2026年6月5日。

2. 腾讯集团官网：《Tencent Rolls Out New AI Tools and Enterprise Solutions》，2026年5月28日。

3. 腾讯云WorkBuddy产品页及WorkBuddy官网。

4. 《10人小团队，如何跑出日活第一Agent？》，腾讯新闻，2026年5月19日。

5. 《领跑AI办公智能体赛道，腾讯WorkBuddy负责人刘毅称“暂时跑赢半个身位”》，2026年7月。

6. 腾讯云关于CodeBuddy、WorkBuddy计费方案调整的公告，2026年4月28日。

7. 《2026年Q2中国办公智能体平台市场洞察报告》相关公开报道，2026年7月20日。

8. OpenAI：《Harness engineering: leveraging Codex in an agent-first world》，2026年2月11日。

9. LangChain：《Improving Deep Agents with harness engineering》，2026年2月17日。

10. Tencent WorkBuddy Bench论文及公开评测材料，2026年7月。