WorkBuddy进化史：一款AI产品背后，是一套新的团队工作方式

WorkBuddy的爆发不是偶然，而是能力外溢的结果

回到今年3月9日，腾讯正式上线WorkBuddy。上线第二天，由于访问量远超预期，核心服务触及容量预警，团队紧急扩容并调整系统架构。两个月后的腾讯一季度财报中，马化腾首次将WorkBuddy放到公司级业绩叙事里：腾讯称，按照日活用户计算，WorkBuddy已经是中国使用最广泛的效率型AI Agent服务。（华尔街见闻）

一款年初才开始内部试用的产品，为什么能在如此短的时间内冲出来？表面上看，这是腾讯抓住了桌面Agent和“龙虾”热潮；但把时间线向前拉，会发现WorkBuddy并不是突然出现的产品。它的真正起点不是2026年3月，甚至不是2026年1月，而是腾讯云团队过去几年围绕AI Coding、Agent架构和企业研发场景所积累的一套能力。

起点：AI Coding能力积累从Coding Agent到内部原型公开测试与公司级产品化团队协作、企业治理与移动化组织整合与质量基准

CodeBuddy是WorkBuddy真正的技术母体

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）

这背后是一个很重要的产品演进路径：

协作方式重构：Task Contract取代传统职能分工

WorkBuddy背后，是一套不同于传统产研体系的协作方式

截至目前，腾讯没有公开WorkBuddy完整的组织架构、正式人员规模和汇报关系。可以确认的是，WorkBuddy由腾讯云CodeBuddy团队孵化，汪晟杰担任产品负责人；早期CodeBuddy团队约10人，WorkBuddy获得市场验证后，团队规模持续增加。至于外界流传的“扩张至百人以上”，目前缺少腾讯官方公开确认，不宜作为确定事实。（腾讯云）

比人数更值得关注的是团队怎样工作。

在腾讯研究院整理的一场公开圆桌中，汪晟杰相对完整地描述了WorkBuddy内部的协作机制：团队会先把功能模块拆解出来，让AI参与定义模块边界；一个模块涉及的上游、下游和内核能力，由一个小组尽可能闭环负责。具体执行通常由大约3—5名开发人员组成的小团队完成，产品、研发之间的边界也明显弱化——开发人员可以参与撰写产品文档，产品经理也可以写代码。（腾讯云）

这不是简单地要求员工“多学一项技能”，而是传统职能分工正在被重新组合。

过去，一项产品功能往往要依次经过业务需求、产品设计、技术评审、开发、测试和运营等多个环节。每一个职能只完成其中一段工作，组织通过会议、文档和流程把这些环节连接起来。

在WorkBuddy的模式中，AI承担了越来越多的执行工作，人的组织单元因此可以变得更小、更完整。一个3—5人的团队不再只负责某个局部工序，而是对一个相对完整的问题域负责。

产品人员负责的不只是写PRD，而是定义用户问题、验证需求、生成原型和参与实现；开发人员不只是根据文档写代码，还要理解产品目标、参与边界设计和判断优先级；AI则承担代码生成、资料整理、任务拆解、测试、总结和部分协同工作。

团队之间的协作方式也发生了变化。

按照汪晟杰的描述，模块之间会先明确上游和下游的“约定”，由人类进行前期评审，再让AI根据这些约定执行。Agent可以把任务派发给其他Agent，完成后再汇总回来；人在执行过程中进行监控和抽样检查。（腾讯云）

这实际上是一种正在形成的Task Contract机制：组织不再主要通过岗位和层级推动工作，而是通过明确的输入、输出、上下文、接口和验收标准，让人和AI共同完成任务。

更值得注意的是，团队会把讨论结果、需求背景和执行经验继续沉淀到代码仓库和上下文中，AI完成工作后再进行复盘和更新，后续团队可以直接复用。（腾讯云）

于是，个人经验不再只存在于员工头脑里，而可以逐渐变成机器可读取、可调用的组织资产。这些资产可能表现为一个Skill、一套指令、一段工作流、一个专家Agent、一套验收规则，或者一个不断更新的项目上下文。

这正是AI原生组织与普通“全员使用AI工具”的本质差别。

普通企业只是让员工在原有流程里多使用一个AI工具；AI原生组织则会重新设计任务如何产生、如何拆分、如何传递、如何执行、如何验收，以及经验如何沉淀。

组织逻辑四支柱：厚平台、小团队、快反馈、Dogfooding

从产品变化看组织逻辑：厚平台、小团队、快反馈

综合官方材料、管理者访谈和媒体报道，可以看到WorkBuddy背后正在形成四个比较清晰的组织机制。

第一个机制是，先从高确定性场景建立闭环，再向复杂场景扩张。

代码是一个相对适合Agent成长的场景：输入和输出比较明确，结果可以运行、测试和验证。CodeBuddy团队先在代码环境中建立上下文管理、工具调用、循环执行和结果评估能力，再把这些能力迁移到办公场景。

传统企业应用AI，也不应该一开始就提出“打造全公司万能Agent”。更可行的起点，是找到一个任务高频、输入输出相对清晰、结果能够验证的工作域，先完成闭环。

第二个机制是，厚平台、小团队。

WorkBuddy前线功能由小型团队负责，但这些小团队背后共享CodeBuddy的Agent架构、模型能力、云资源、工具体系、安全沙箱、连接器和腾讯办公生态。

因此，小团队高效并不意味着“只需要几个人”。它真正需要的是：公共平台承担通用能力，前线小组集中解决业务问题。

没有公共平台，小团队只能重复开发；没有小型自治团队，平台又很容易变成一个庞大而缓慢的职能部门。

第三个机制是，Dogfooding，即用自己的产品生产自己的产品。

WorkBuddy最初就是借助CodeBuddy和已有Agent SDK快速搭建出来的；产品上线后，团队继续使用AI完成需求分析、编码、测试、文档和经验沉淀。产品能力提升团队效率，团队效率又进一步加快产品迭代，形成自我强化循环。（腾讯云）

AI带来的真正复利，并不只是某项任务节省了多少时间，而是生产系统本身开始不断改进生产工具。

第四个机制是，先允许分散探索，出现市场信号后再集中资源。

媒体在7月援引腾讯内部组织调整通知称，QClaw产品中心相关业务和部分团队被调整至WorkBuddy所在的云产品六部，QClaw产品仍将继续运营。腾讯尚未通过正式公告公开这一调整，因此这属于媒体报道，而不是官方确认。（36氪）

如果这一报道准确，它反映的是一个典型的创新组合管理过程：探索阶段允许多个团队从不同路径试验；当其中一条路径获得明确用户信号后，再把相近的团队、入口和资源集中到主航道。

这比一开始就要求全公司只能做一个方案，更有利于发现机会；也比长期维持重复建设，更有利于形成规模。

JOTO 企业落地观察

• 对企业部署意味着：不能仅将AI视为插件式工具，而需同步构建支撑Agent执行的底层平台能力——包括任务契约定义、上下文管理、工具连接器与安全沙箱。WorkBuddy的‘厚平台’表明，单点AI功能易复制，但跨场景复用的Agent基础设施才是护城河。
• 这类系统的取舍在于：是否接受用‘任务契约’替代‘岗位职责’作为协作基本单元。当输入/输出/验收标准可被机器解析，团队就可按问题域而非职能组建；但这也要求企业重构知识沉淀方式——经验必须结构化为Skill或工作流，而非仅存于文档或个体记忆。
• 对RAG知识工程而言，WorkBuddy团队将讨论结果与执行经验持续沉淀至代码仓库和上下文的做法，揭示了一种新型知识闭环：RAG不应只服务于问答，更应支撑Agent的任务执行与复盘迭代。静态知识库需升级为动态可演化的‘执行上下文’。
• AI安全治理的关键转变在于：从管控模型输出，转向定义任务边界与执行契约。WorkBuddy采用人类前置评审+AI按约定执行+人工抽样检查的机制，说明企业级Agent治理的核心不是禁止什么，而是明确‘在什么条件下、以何种方式、交付何种结果’。