越来越多人开始关注WorkBuddy。大多数讨论集中在它能做什么、怎样操作，以及有哪些值得掌握的使用技巧。这当然没有错，一款AI产品首先要解决的，就是用户是否会用、是否好用，以及能否真正完成工作。
但今天，我们想换一个视角：不只看WorkBuddy怎么用，而是看看它从哪里来、如何一步步演进，以及这款产品背后的团队是怎样工作的。
回到今年3月9日，腾讯正式上线WorkBuddy。上线第二天，由于访问量远超预期，核心服务触及容量预警，团队紧急扩容并调整系统架构。两个月后的腾讯一季度财报中，马化腾首次将WorkBuddy放到公司级业绩叙事里：腾讯称，按照日活用户计算，WorkBuddy已经是中国使用最广泛的效率型AI Agent服务。（华尔街见闻）
一款年初才开始内部试用的产品，为什么能在如此短的时间内冲出来？
表面上看，这是腾讯抓住了桌面Agent和“龙虾”热潮；但把时间线向前拉，会发现WorkBuddy并不是突然出现的产品。它的真正起点不是2026年3月，甚至不是2026年1月，而是腾讯云团队过去几年围绕AI Coding、Agent架构和企业研发场景所积累的一套能力。
更重要的是，WorkBuddy的快速迭代并不只是产品能力的结果。它背后同时发生了一场小范围但相当彻底的组织实验：产品经理开始写代码，开发人员开始参与PRD和需求定义，功能被拆给3—5人的小型闭环团队，AI参与任务分解、接口约定、代码生成、经验沉淀和Agent之间的任务调度。
一、先快速了解WorkBuddy的发展时间：从AI Coding到通用工作Agent
二、WorkBuddy不是突然出现的，它是CodeBuddy能力的一次“外溢”
WorkBuddy产品负责人汪晟杰从2021年开始参与AI Coding产品，最初的愿景是“让写代码像写文档一样简单”。2023年前后，腾讯云内部负责AI代码助手的团队大约只有10人。当时市场注意力主要集中在基础模型和Chatbot，AI Coding还不是一条足够热门、商业模式足够清晰的赛道。（Apple Podcasts）
为了证明产品价值，这支团队没有停留在腾讯内部做技术验证，而是直接进入企业客户现场。钛媒体的深度采访显示，汪晟杰曾在招商银行机房驻场近三周，参与开会、部署、收集反馈和修改产品，直到2024年底形成签约，随后又以类似方式进入小米、荣耀等企业客户。（钛媒体）
这段经历很重要。它意味着CodeBuddy团队早期积累的不只是模型调用能力，而是模型怎样进入真实工作环境：怎样读取上下文，怎样使用工具，怎样在企业权限内执行任务，怎样处理失败，怎样把一次模型回答变成一段完整工作。
随着Cursor、Devin和Claude Code等产品出现，AI在软件开发中的角色也从代码补全工具逐渐变成可以理解需求、调用工具并自主执行任务的Coding Agent。到2025年下半年，CodeBuddy团队已经建立了支持Agent自主执行任务的底层架构、开放平台和SDK。（华尔街见闻）
这套系统后来成为WorkBuddy快速出现的真正基础。
2026年1月，Claude Cowork公开后，汪晟杰与少数同事基于CodeBuddy已有平台快速搭建了一个面向非技术用户的Web原型，最初叫CodeBuddy Work。腾讯研究院整理的公开圆桌显示，WorkBuddy 0.1版本于1月15日上线；汪晟杰在媒体采访中则回忆，1月17日前后的一个周末，他和几位同事连续工作两天，完成了更早期的0.01版本。（腾讯云）
因此，把WorkBuddy简单理解为腾讯看到OpenClaw爆火后迅速推出的一款“腾讯版龙虾”，并不准确。OpenClaw加速了产品公开发布和功能调整，但WorkBuddy所依赖的Agent执行框架，在热潮出现前已经存在。腾讯选择的也不是直接套用OpenClaw代码，而是沿用CodeBuddy的自研底座，并在安全、自主程度和产品体验之间采取更克制的路线。（华尔街见闻）
WorkBuddy的产品逻辑，实际上是把CodeBuddy在代码世界中已经验证的Agent Harness，迁移到文档、数据、网页、设计和通用办公场景。
这是一种典型的“能力外溢”：不是从零开发一个新产品，而是把一个高确定性场景里形成的底层能力，推向更广泛的工作领域。
三、它真正改变的，是AI产品的价值单位
过去两年，企业办公AI大多停留在三个典型动作：总结、生成和问答。用户提交一份材料，AI给出一个答案；用户提出一个主题，AI生成一段文字。
WorkBuddy试图把产品的价值单位从“一次回答”变成“一个完成的工作成果”。
用户不只是问它一个问题，而是把一项工作交给它。WorkBuddy可以自主理解目标、拆解任务、读取本地文件、搜索资料、运行代码、调用不同工具，最后生成文档、网页、表格、PPT或其他交付物。官方将其定位为能够“自主规划并交付多模态复杂任务结果”的AI Agent工作台，而不是一个普通聊天助手。（CodeBuddy）
四、WorkBuddy背后，是一套不同于传统产研体系的协作方式
截至目前，腾讯没有公开WorkBuddy完整的组织架构、正式人员规模和汇报关系。可以确认的是，WorkBuddy由腾讯云CodeBuddy团队孵化，汪晟杰担任产品负责人；早期CodeBuddy团队约10人，WorkBuddy获得市场验证后，团队规模持续增加。至于外界流传的“扩张至百人以上”，目前缺少腾讯官方公开确认，不宜作为确定事实。（腾讯云）
比人数更值得关注的是团队怎样工作。
在腾讯研究院整理的一场公开圆桌中，汪晟杰相对完整地描述了WorkBuddy内部的协作机制：团队会先把功能模块拆解出来，让AI参与定义模块边界；一个模块涉及的上游、下游和内核能力，由一个小组尽可能闭环负责。具体执行通常由大约3—5名开发人员组成的小团队完成，产品、研发之间的边界也明显弱化——开发人员可以参与撰写产品文档，产品经理也可以写代码。（腾讯云）
这不是简单地要求员工“多学一项技能”，而是传统职能分工正在被重新组合。
过去，一项产品功能往往要依次经过业务需求、产品设计、技术评审、开发、测试和运营等多个环节。每一个职能只完成其中一段工作，组织通过会议、文档和流程把这些环节连接起来。
在WorkBuddy的模式中，AI承担了越来越多的执行工作，人的组织单元因此可以变得更小、更完整。一个3—5人的团队不再只负责某个局部工序，而是对一个相对完整的问题域负责。
产品人员负责的不只是