8月26日消息，腾讯集团高级执行副总裁、云与智慧产业事业群 CEO 汤道生在腾讯内部刊物《知点》年刊上发表文章，系统阐述他对 AI 的思考，并复盘混元、CodeBuddy、WorkBuddy、元宝等产品的实践。他在文中承认，混元大模型曾因公司整体算力严重不足而拖慢训练与产品发展；同时提出，AI 的下半场才刚开始，场景与工程是腾讯做 AI 的底牌，企业 Agent 应用应是个人 Agent 与服务 Agent 并存的完整架构。 汤道生在文中说明，这篇文章由他与 AI 共同完成。全文六部分依次回应"腾讯 AI 慢"的外部评价、AI 应用不止大模型、创新不可规划但能力可积累、个人 Agent 与服务 Agent 并存、以 AI 原生的方式重构组织力，以及长期主义与以人为本两个"不变"。
文中提到的具体信息包括：混元经历了不同阶段与多次重构，Hy3 在同等参数下效果突出，但公司整体算力严重不足拖慢了模型训练与产品发展；Hy4 将迎来更多突破；CodeBuddy 源于长期亏损、一度险些被收缩的腾讯云 DevTools 业务，2024 年推出后获得项目收入，2026 年初团队基于 CodeBuddy 底座推出 WorkBuddy，上线三个月迭代了四十多个版本，代码基本由 AI 生成，人转向判断与把关；元宝此前在模型与产品尚未 ready 时投入较多精力做推广与引流，效果不理想，目前与混元 Hy3 协同设计，搜索体验改善、留存率提升、单位运营成本下降；腾讯正推动企业微信、腾讯文档、ima、腾讯会议、iwiki 等产品与 WorkBuddy 打通。 从文章内容看，汤道生把腾讯在 AI 竞赛中的位置从起跑速度重新定义为长跑耐力：算力约束被明确摆上台面，场景与工程被放在模型层之上，元宝与 WorkBuddy 的得失进入同一套复盘框架。
原文：汤道生《知点》年刊文章全文
先声明，这篇文章是我和AI一起完成的。AI"读过"我这些年的讲话和笔记，帮我把散落在各处的想法重新翻出来、连成了线。放在过去，这样的活得翻上许久材料，整理思绪；而现在，是我把念头讲出来，它帮我回看、整理、修正。这大概就是AI正在改变的一件小事——工具不再只是执行，它开始能陪你一起想。
面对AI这样一次量级的技术变化，我们到底该用什么方法去拥抱它？下面这些文字，是我回想过去经历行业变革中的一些体会，以老登的视角寻找一些不变的道理，同时也时刻提醒自己要敢于放弃过去习惯与依赖的路径，以第一性原理思考，多聆听用户的声音。
一、熬得久，比起得早更重要
前一阵子，一些外部声音普遍认为，腾讯做AI慢了。要说一点不焦虑，那不可能。全球大模型市场竞争激烈，每天都有新消息——谁又发布了新模型、模型参数又大了多少，评测刷分的排名都广为流传。ToB客户也非常关注，过去几年友商在AI的声势也比较占优。
混元大模型经历了不同阶段，多次重构，混元Hy3架构化繁为简，更注重训练数据的质量，在同等参数的大模型中效果突出。但由于公司整体的算力严重不足，拖慢了模型训练与产品发展，产生了比较大的影响。
不过冷静下来，还是会回到同一个基本判断：起得早也许不是最关键，AI的下半场才刚开始，新机会不断出现，市场格局正在变化，商业模式与产业链的价值分配还没定型。
回顾移动设备的历史，早在上世纪80年代末，日本任天堂就推出手提游戏机Game Boy。90年代初，苹果推出第一代手提助理PDA的Newton。到90年代后期，各种品牌的PDA与功能手机并行发展，还有国内流行的传呼机、小灵通和手提字典等。到2000年代的iPod与电子书，最后才到iPhone与Android手机集合以上所有功能，普及全球——哪怕是苹果，也是经历了十多年、多种产品形态的探索与迭代，才真正抓住移动设备的市场；有更多起得早的品牌如诺基亚、摩托罗拉与黑莓等玩家，在市场竞争中掉队，最终成为历史。重要的从来不是谁最早走出第一步，而是谁能更坚定地长期投入，在技术突破与迭代过程中冷静地思考事情的本质，针对具体场景解决问题与痛点，在市场噪音中识别出真实信号，保留实力与灵活性，才能穿越周期。
大模型这场竞赛，我更愿意把它看成一场马拉松，现在可能才跑完头一公里。起得早虽然重要，但熬得久才有机会抓住持续出现的新机遇。
二、AI应用不止大模型，算法与工程都重要
这轮生成式AI的加速发展，可以说始于ChatGPT的诞生，虽然核心是大模型能力的突破，但只有在一般用户能使用后，社会（以及资本）才感知到基础大模型的重要性——对腾讯这样的平台公司来说，必须确保大模型的投入、紧跟最前沿的基础技术研究，这一点毫不含糊。在顺雨与研究团队的努力下，Hy4将会迎来更多突破与更大的进步，大家可以拭目以待。但眼睛也不能只盯着模型这一层。这就好比移动时代，如果说只有做智能手机的企业才算拿到船票，这显然太狭窄。
更重要的是AI 能不能真正落到应用场景里，给用户带来价值。对腾讯来说，我们本来就有大量to C和to B产品，每一个都连着真实用户、具体的场景需求或业务流程。腾讯会议用大模型生成会议纪要，腾讯乐享用大模型做企业知识助手——今天混元已经支持了公司内部数百个应用，而且各产品团队打造的智能体也在快速增加。场景，是腾讯做AI最厚的底牌。场景中的数据，不管是用户生成的，还是专业机构提供的，都为大模型提供了上下文；场景中的历史互动，也能被提炼成个人记忆，或打造成可复用的技能。
很多产品甚至会接入多个大模型来满足不同需求，针对不同模型的能力与价格，把任务分类来选择性价比高的模型。AI应用的落地应该是算法与工程的结合。也许算法决定天花板，工程能力决定你多快触达它——从数据整理、训练、推理到场景落地，每一步都需要AI Infra的工程加持，才能把大模型构造出来。在大模型应用阶段，要跟用户习惯对齐，让AI能跑起来干活的，一套完整的工作环境也是必须的——文件系统、工具调用、长记忆、反馈循环。就像年初的一只小龙虾，接入了最新的大模型，就搅动了整个行业。今天，模型不仅会回答问题，还能真正把一件事做好、做完整。
模型能干活了，能规划，能调用工具，能验证结果，能产生高价值的生产力，因此企业更愿意为此买单。当然，企业对AI应用也有更多要求，包括敏感数据的安全防护与权限管理，还有token资源的成本管理与分配。另外，企业内部系统打通，涉及企业应用生态的打造，让更多企业应用的数据，通过skills与MCP接进大模型智能体，丰富的企业应用生态可能更是长期的护城河。
三、创新不可规划，能力可以积累
大家可能以为，CodeBuddy/WorkBuddy团队早就预料到办公智能体的机遇，提前做好布局，其实不是。
腾讯云上本来很多产品就是面向开发者的，所以CSIG一直有做一些开发者工具，腾讯云早期收购的coding.net，就是做代码托管与CI/CD的DevOps产品。后来增加了Web IDE能力，构建了代码执行的沙箱等技术。当时，因为研发工具的商业模式不太好，这些产品一直处于亏损状态，拖着腾讯云扭亏为盈的后腿。在降本增效的那几年，CSIG关掉了不少亏损的SaaS/PaaS产品，一度也要收缩对DevTools的投入，幸好没有砍掉这个项目。
2021年微软发布了GitHub Copilot，用AI写代码成为被广泛关注的新方向。大模型在编程场景里有天然优势：代码是高度结构化的语言，有明确的语法规则，也有丰富的开源语料可供学习；许多研发任务的输入输出边界相对清晰，模型生成的结果可以通过编译、测试和运行反馈快速验证。这让研发成为大模型最早落地、也最容易产生高阶生产力的场景之一。 当时，腾讯云DevTools团队也开始研究AI写代码的可行性，让AI接入到研发工具中，构建了Coding Agent早期的代码模型与Harness。恰逢TEG研发管理部的工蜂团队也要推动公司内部做AI研发提效，就与云这边的开发者相关业务合作起来，一起探索AI Coding的未来，并在公司内验证与试用。在CSIG技术委员会推动下，CSIG的产品研发团队，自然成为"最积极"吃螃蟹的一群。最初大模型只能做简单的代码补全，虽然减少了程序员敲代码的时间，但实际对研发工作的提效还不够明显。随着模型越来越强大，生成的代码越来越完整，质量也越来越高。一些企业客户对AI Coding也抱有期待，因此我们在2024年推出CodeBuddy，通过私有化部署获得了一些项目收入，让团队可以继续探索与完善产品。
到2025年底，Claude Opus 4.5发布，大模型已经能长时间执行各类编程任务，此时的AI已经不仅仅能输出完整代码，而且能优化算法、验证结果，还能发现与修正bugs。司内由AI生成的代码比例突然快速攀升，所有研发人员都在改变开发方式，tokens消耗爆发式增长。 到了2026年初，在龙虾爆火出圈之际，团队基于CodeBuddy底座打造出界面更简单、更适合非技术研发人员使用的WorkBuddy，给产品经理写方案，运营同学做数据报告，管理者处理邮件和会议。这些事情背后本质是任务拆解、信息获取、数据整理、内容生成、验证结果；我们似乎看到了办公场景中一个通用智能体的雏形。正当我们需要加大WorkBuddy的投入时，腾讯文档团队也调整到了CSIG，两个团队快速融合，正好补齐了WorkBuddy所急需的文档编辑能力，让人机双写、资料库等能力快速上线，继续领先同行。
WorkBuddy上线后获得了意想不到的市场关注，接住了逐步衰减的龙虾热，热心的用户给了团队许多反馈，团队也用着他们最熟悉的AI Coding工具快速迭代，以原生AI工作方式疯狂迭代产品，以前所未有的速度解决各种问题；上线短短三个月，团队就迭代了四十多个版本，几乎是一天一小步地往前跑。这速度背后，是一套和以前很不一样的工作方法。过去做产品，往往要先写文档、评审、排期，再进入开发；而WorkBuddy团队是先让 AI 把东西做出来，大家围着一个能跑的原型看效果、提意见、再调整。整个过程中，代码基本上都是由AI生成的，人更多地转向"做判断、调试和把关"。白天，人和AI一起想、一起改；晚上，AI接着跑长任务。产品迭代自然就快了。
今天CodeBuddy和WorkBuddy已经成了内部很多同事日常工作离不开的工具，连接着内部各个系统与数据，过去要花好几个小时的工作，比如清洗一批数据、做一份经营分析、起草一份文书，现在只需要20分钟左右，就能打磨出一个像样的初稿，越来越多的工作，正在变成人和AI一起完成。
所以，AI原生应用要真正跑出来，关键是要能够自由探索，基于对场景痛点的理解找机会，在变化出现时及时行动，快速做出可用的产品，重视用户反馈，验证想法，并持续迭代。
这两年元宝的探索，同样也在为我们积累做大模型产品的经验与能力。很多人可能会觉得，Chatbot的战役已经打完了，但我认为，信息搜索与问答是用户长期的刚需，只要把答案做得比竞品好，机会永远存在。做元宝的过程，很大程度上提升了我对AI工作的认知——AI产品不是简单地把模型加上页面与输入框，而是要建立一整套可进化的系统能力，包括实验平台、评测体系和反馈闭环，持续验证不同模型、检索策略和答案组织方式的效果。元宝在这些方面沉淀下来的很多基础能力，今天也在被WorkBuddy等产品复用。
对于元宝本身，虽然市场上主要竞品，在拟人化和语音体验上做得不错，的确也值得我们学习。但如果回到问答产品的本质，用户最在意的，仍然是答案是否准确、信息来源是否权威可信、内容是否足够实时。元宝如果能够做好这些核心能力，仍然有很大的赶超机会。过去一年，元宝在巨大的用户增长压力下，花了较多精力去做推广与引流，当时模型与产品都还没ready，其实效果并不满意。但现在，公司的AI战略越来越清晰，多个产品齐头并进，元宝团队反而可以更有节奏地打磨产品体验，把基础能力继续做厚。最近在元宝与混元Hy3的Co-Design加持下，搜索体验在持续改善，留存率在不断提升，单位运营成本也在持续下降。就像前面说的，只要方向正确，耐心打磨产品，做时间的朋友，我对元宝的长期发展还是非常有信心。
四、个人Agent向左，服务Agent向右
刚刚讲到的WorkBuddy，很多时候它扮演的是"个人助手"的角色：帮你写邮件、查资料、做分析、写报告、写代码等，把繁琐的事情为我们一口气做完。这类Agent站在用户侧，理解用户个人的意图，高效地创造或完成任务。
但在企业里，还有很多需求，发生在持续在线的服务场景中，比如面向用户的智能客服、面向销售的售前产品知识库、面向员工的人力资源或法务咨询入口等。这些场景，往往要连接企业内部的CRM、知识库、工单、OA、ERP 等系统，提供这些服务的组织，对于信息的准确性、时效性、数据格式、数据权限、流程约束、内容审核等都有严格的要求，也要满足高可用、7×24小时的响应。这就引出了另一类重要角色：服务Agent。
和个人Agent不同，服务Agent遵循服务提供者与管理者的意图，对于所有数据输出要承担责任，也要避免使用者的滥用—— 这类Agent往往要服务大量用户，或被个人Agent调用，开发者要决定用什么模型、接入什么数据、遵循什么流程、提供什么接口、开放什么权限、交付什么能力等。它可以有很多种搭建路径。比如在腾讯内部，就有很多技术团队，基于tRPC或langchain等开源框架，搭建一些知识问答、流程自动化、数据查询等场景化的服务Agent，支持着许多在Knot（腾讯内部的Agent平台）上可以被调用的skills。
但是对大多数传统企业来说，自己用开源组件拼装智能体，若要做得很完善，工作量不小，管理与维护成本也不低。这时候，腾讯云智能体开发平台ADP，可以提供开箱即用的配置方式，让客户快速打造稳定、安全、可扩展、可运维的服务Agent，并提供多Agent的管理平台。它把常见的工作流编排、RAG、工具调用、调试评测、安全治理和系统集成等能力，做成了完整的产品化支持；还可以通过OpenAPI体系， 嵌入客户已有的系统。在落地过程中，FDE工程师还会和客户一起深入场景，梳理业务流程、数据权限与信息安全等需求，最终沉淀业务工作流，提供可复用的skill与MCP接口。当然，用CodeBuddy从零搓一个满足以上所有需求的服务Agent 也是一个选择。
所以，个人Agent和服务Agent是并存与互补的关系。假如一个员工，正在做一份客户分析报告，WorkBuddy会帮他理解目标、拆解任务、整理资料和生成初稿；但当任务需要调用客户数据、产品知识、报价规则、合同模板时，就可以发请求给对应的服务Agent来承接，由服务Agent核实身份，对数据权限把关，防御攻击行为，把信息整理后返回准确结果。两者结合起来，才是企业Agent应用的完整架构。
五、用AI原生的方式重构组织力
说完产品，再讲讲组织。AI在改变我们做产品方式的同时，也在重塑传统的组织形态和产品研发模式。
过去研发一款在线产品，基本是一条长长的流水线：产品经理写需求，设计师做交互界面，工程师写代码实现产品功能，前后端开发联调，测试工程师跑完所有测试用例，运维工程师部署到生产环境，流程一环扣一环。一个产品团队里必须有多个专业角色，分工较细，沟通成本较高，全流程走一遍也蛮花时间。很多时候，需求不是一开始就能被完整定义出来，而是要实现出来后，边试用边调整，每次调整可能再重新走一遍。
有了大模型，产品经理可以更早搞个原型来验证想法，直接把交互界面设计了；开发也能用AI直接生成前后端代码，包括生成完整的测试用例；有些简单的产品功能，产品经理就能vibe code完成。整个产品研发过程被改造了，同样的事情只需要更少的人就能完成，研发时间也被大大缩短。
当AI能同时把多个环节都做好，原来角色边界变得模糊，大团队的流水线反而变得臃肿与低效。在一个AI原生组织里，跨界不只是员工的常态，更是小团队办大事的基础。
另一个发现是，在Agent时代，模型和产品的深度协同也变得非常重要，否则很容易造成灵魂与肉体的分离；产品为模型展示了不同用户需求的分布，也提供了能提升模型能力的宝贵数据；产品与模型Co-Design就是指一起对齐优化目标、构造环境数据、加强模型后训练，再通过实验反复验证。在Coding场景，模型需要的Context是代码、工程架构、数据结构等；而在PPT场景，需要的则是会议纪要、业务资料、市场状况、公司模板和表达风格等等。不同场景下，什么信息是有用的，如何喂给模型，需要模型和产品团队，从各自视角共同参与设计。混元团队与元宝、WorkBuddy团队的Co-Design，就是让模型架构和产品体验，在同一过程中共创、迭代。
最近，我们也在推动企业微信、腾讯文档、ima、腾讯会议、iwiki等产品与WorkBuddy的打通，在WorkBuddy可以一站式实现文档处理、知识管理、会议总结、协作办公和人机共创等高频需求。这样，模型就能在多个高频入口中，持续获得更多真实任务数据、用户交互反馈和场景化Context，并将这些反馈用于调优、能力补齐和体验优化。
通过这些例子可以看出，AI原生绝不仅仅是把 AI 能力接入一个产品，而是从产品设计、研发协作到团队组织，都要用新的方式重新思考。
当然，这对我们的组织管理，也提出了更高的要求：团队要更扁平，目标要提前对齐，评测指标要清晰，实验与试错成为研发流程的一部分。很多过去放在后面的验证工作，现在要尽量前置；很多过去按角色分工完成的事情，现在需要产品、工程、算法、设计一起提前参与判断。
六、坚持长期主义，回归以人为本
前面讲了很多AI带来的变化：产品形态在变，研发方式在变，组织协作也在变。但变化越快，越要想清楚：什么必须变，什么不能变。
对我来说，有两个"不变"尤其重要。
第一个不变，是长期主义。
就像前面说的，AI这场马拉松才刚起步，真正决定终局的不是谁起跑最快，而是谁能穿越周期、持续把耐心和资源押在长期价值上。
第二个不变，是以人为本。
技术只是手段，人才是目的。
我们做 AI，不是为了追求最酷的技术，也不是为了证明自己站在风口上，而是希望用技术解决真实问题，让产品更好用、服务更贴心、效率真正提升。
最近有例子让我印象很深，北京密云一位基层干部用WorkBuddy，开发了一款防汛小程序，打通了地灾预警、雨情、群众转移等信息。过去，需要几十人通宵电话核对的工作，现在他一个人一小时就能够完成16个乡镇预警下发和转移统计，大幅提升了基层防汛效率。
这就是以人为本的一个很好的证明。AI不是替代人，而是帮助人把那些繁琐、重复、低效但又重要的事情做得更好，让每个人都能把能力用在更有价值的地方。当我们抱着纯粹的、以人为本的心态去做产品时，我们的产品口碑和商业回报，自然水到渠成。
结语
最后我想说，AI 时代来了，来得比很多人预想得更快、更迅猛。但技术越是变化，我们越要回到商业最朴素的底层逻辑：持续为用户创造价值。把能力做厚，把产品做实，把场景吃透，机会真正到来时，我们才能够稳稳接住。
对于我们每个个体而言，我的建议是，越是在快速变化的时代，越要保持清醒。真正能够make a difference的，往往不是最勤快抓风口的人，而是那些了解自己的优劣势，把精力聚焦在自己喜欢的事与自己可以改变的地方，低谷期仍然能坚定投入的长跑手。不被无法改变的事情消耗，把力气用在真正能产生改变的地方，这既是一种判断力，也是一种长期能力。
种子早已埋下，土壤也一直在养。AI的长跑才刚刚开始，让我们一起笃定前行！
AI 速览
