WorkBuddy开放平台上线，腾讯开始把Agent底座交给开发者

腾讯 WorkBuddy 开放平台于 2026 年 9 月 2 日正式上线，开发者通过认证和资质审核后，可以在平台内管理并接入技能、专家、连接器和外部应用，构建面向具体任务和行业场景的自定义 Agent。

这不是一次普通的应用市场上新，而是 WorkBuddy 产品定位的一次转向：从“腾讯自己的桌面智能体”，转向“允许第三方在其上组装能力的 Agent 平台”。首批入驻共创伙伴已经超过 100 家，9 款联名智能硬件首发亮相，另有 30 余个行业应用接入，覆盖金融、法律、医疗、教育、公益等 20 多个领域。

开放的核心，不是聊天框而是四类能力

WorkBuddy 开放平台是面向 WorkBuddy 生态业务的一站式开发与管理工作台，它的价值在于把 Agent 所需的工具、知识、角色和外部系统放进同一套接入框架。

技能是可被 Agent 调用的任务能力。 技能可以理解为面向某类工作的可复用操作模块，例如内容改写、数据处理、文件整理、报告生成或特定业务流程。它解决的是“Agent 会不会做某件事”的问题。

专家是带有角色、知识和工作方法的数字员工。 与单个技能相比，专家更接近一个能够持续处理复杂任务的专业角色，例如法律审阅专家、金融分析专家或营销运营专家。它解决的是“Agent 应该以什么专业方式完成任务”的问题。

连接器是让 Agent 访问外部系统和数据的标准化接口。 连接器负责把 Agent 与企业已有的办公软件、业务系统、硬件设备或第三方服务连起来，解决的是“Agent 能不能真正进入工作现场”的问题。

外部应用接入是把已有产品能力嵌入 WorkBuddy 工作流。 对开发者而言，这意味着不必从一个空白聊天窗口开始做产品，而是可以利用 WorkBuddy 的 Agent 运行环境、交互入口和生态分发能力，把原有服务变成可被调用的智能能力。

四类能力组合起来，WorkBuddy 才有机会从“会执行任务的助手”升级为“能调度多个工具和角色的工作入口”。用户提出一个目标后，Agent 可以拆解任务、调用技能、访问连接器，再把结果交付回来；开发者则负责把专业能力封装成平台可识别、可管理、可复用的组件。

首批生态阵容，先从硬件和行业场景切入

首批 9 款联名智能硬件说明，腾讯并不满足于让 WorkBuddy 停留在电脑桌面上。合作方包括 Plaud、Rokid、影石、科大讯飞、安克、猛玛、京东京造等品牌，覆盖录音、智能眼镜、影像和办公设备等方向。

硬件接入的意义在于，Agent 的触发方式将从“用户打开应用并输入指令”，扩展到“设备捕捉信息后主动发起任务”。例如，录音硬件可以把会议内容交给 WorkBuddy 生成摘要和待办；智能眼镜可以把现场信息交给视觉能力处理；影像设备则可能调用内容整理、剪辑或发布相关技能。

这类场景的关键并不是硬件本身增加了一个语音助手，而是设备采集到的上下文能否进入后续工作流。如果录音只停留在转写结果，价值有限；如果它还能继续触发会议纪要、任务分派、日程创建和知识归档，Agent 才真正进入生产流程。

30 余个行业应用的接入，则对应另一条路线：把 WorkBuddy 变成垂直能力的统一入口。金融、法律、医疗和教育等行业通常有较强的知识壁垒、流程约束和权限要求，通用模型很难直接覆盖完整业务。把专业服务封装为专家、技能或连接器，可以让 Agent 在限定范围内完成更可控的工作。

不过，“接入”不等于“深度落地”。目前公开信息披露了首批伙伴数量和覆盖领域，但没有公布各应用的调用规模、活跃用户、任务成功率或商业分成规则。对于开发者来说，平台能否提供稳定分发、可观测运行数据和清晰的收益机制，仍需要后续观察。

腾讯真正开放的是 Agent 基座

Agent 基座是支撑智能体完成任务规划、工具调用、上下文管理、安全控制和结果交付的底层运行能力。腾讯此次开放平台的重点，不是单独开放一个模型，而是向生态伙伴开放 WorkBuddy 所依赖的整套 Agent 组织方式。

从此前公开的信息看，WorkBuddy 与腾讯 CodeBuddy 使用同一套 Agent 智能体架构，已经具备多模型切换、Skills 技能包、MCP 协议、多窗口多 Agent 并行和动态任务分解等能力。WorkBuddy 早期更像一个可以操作本地电脑和文件的桌面 Agent，而开放平台则试图把这些能力进一步抽象成第三方可接入的基础设施。

这条路线与单纯提供大模型调用不同。模型负责理解和生成，Agent 平台则负责让模型采取行动。一个模型能写出一份合同摘要，并不意味着它可以安全地读取企业文档、检查审批状态、创建任务、调用 CRM，再把结果写回系统。真正决定企业能否使用 Agent 的，往往是权限、上下文、工具编排、异常处理和审计，而不是聊天回答是否流畅。

腾讯云副总裁、腾讯 CodeBuddy 与 WorkBuddy 负责人刘毅在相关发布活动中提出，真正的生产力不取决于一个工具有多强，而取决于它能连接多少能力、进入多少场景。腾讯希望把 WorkBuddy 打造成面向 Agent 时代的操作系统，这句话也解释了开放平台的战略位置：WorkBuddy 不只是一个终端产品，更想成为能力调度层。

从“个人很爽”到“组织有感”

企业 Agent 落地的核心难题，是个人效率提升并不自动转化为组织效率提升。员工可以用 AI 更快地写文档、做总结和整理数据，但如果结果没有进入团队流程，知识没有沉淀，权限没有打通，部门之间仍然需要重复沟通，企业最终只能得到一批更快完成局部任务的个人用户。

WorkBuddy 的平台化方向，试图解决的是任务完成之后发生什么。一个 Agent 生成的报告可以沉淀为企业知识；一次项目协作可以形成可复用模板；一个外部系统连接器可以被多个专家和技能复用；一次人工修正则可能反过来改善后续执行流程。理想状态下，工作越多，组织留下的 AI 资产越多。

这也是 WorkBuddy 与普通办公助手的区别。普通助手的基本单位是一次问答，任务结束后上下文往往随之消失；工作流型 Agent 的基本单位则是一项任务，任务需要启动、拆解、执行、协同、交付和归档。两者都能生成文本，但后者更接近企业真正关心的生产链路。

腾讯此前披露的企业版方向包括 7×24 专家数字员工、基于项目的人机协作和企业级管理后台；办公智能体套件则计划将腾讯文档、腾讯网盘、腾讯乐享等能力接入 WorkBuddy 工作台。若这些能力与此次开放平台打通，第三方开发者可以在腾讯办公生态之上构建垂直 Agent，而企业用户则不必为每个 Agent 单独学习一套入口。

对开发者来说，机会和门槛同时上升

WorkBuddy 开放平台降低了 Agent 产品的基础设施门槛，但没有消除专业开发门槛。开发者不再只需要设计 Prompt，还需要处理身份认证、权限范围、数据隔离、工具调用失败、长任务状态、结果评估和成本控制。

当前平台支持企业认证和个人认证。企业开发者可以使用腾讯云账号、微信公众号或小程序账号，或者通过企业法人实名完成认证；个人开发者可以使用身份证、手机号和邮箱等信息完成认证。认证体系说明平台已经考虑到不同类型的生态参与者，但真正决定企业是否采用的，仍然是审核标准、权限模型和数据治理细节。

一个可用于生产环境的连接器，至少需要回答几个问题：它能访问哪些数据？权限由谁授予？调用是否需要二次确认？操作结果能否追溯？连接失败后 Agent 会不会重复执行？敏感信息是否会被写入长期记忆？如果这些问题没有标准答案，Agent 越“自动”，风险反而越大。

连接器尤其是平台生态的分水岭。技能可以在相对封闭的环境中运行，连接器却会把 Agent 推向真实业务系统。连接 CRM 可能涉及客户隐私，连接财务系统可能触及付款和发票，连接医疗系统则需要更严格的数据合规。未来平台竞争的关键，不只是“能接多少系统”，还包括“能否让企业放心地接入这些系统”。

腾讯的优势在于拥有腾讯云、企业微信、腾讯文档、腾讯会议等企业服务，也有微信生态和大量硬件、行业合作伙伴。它可以把入口、办公内容、通信关系和云端运行能力组合起来，这是独立 Agent 创业公司通常不具备的生态条件。

但生态整合也可能带来限制。如果开发者只能在腾讯自有产品体系内获得较好体验，跨平台能力不足，WorkBuddy 的开放性就会打折扣。企业客户通常已经在使用飞书、钉钉、金山办公、Salesforce 或自建系统，连接器的广度、开放协议兼容性和迁移成本，将直接影响平台的实际渗透率。

与开源 Agent 和办公助手的竞争，不在同一条起跑线

WorkBuddy 的主要竞争力不是模型参数规模，而是入口、连接器和 Agent 工程能力的组合。国内通用办公产品可以提供类似的文本生成和知识问答，开源 Agent 框架可以提供更高的部署自由度，但 WorkBuddy 试图把“低门槛使用”和“企业生态整合”放在一起。

| 方向 | WorkBuddy 开放平台 | 开源 Agent 框架 | 通用办公 AI | 企业自建 Agent 平台 | |---|---|---|---|---| | 核心定位 | Agent 能力接入与生态分发平台 | 自主搭建 Agent 的技术框架 | 办公场景中的 AI 助手 | 面向单一企业的定制基础设施 | | 优势 | 腾讯办公生态、硬件与行业伙伴接入 | 可控、可定制、可本地部署 | 上手简单、用户覆盖广 | 权限和流程可按企业需求设计 | | 主要短板 | 平台规则和生态边界仍待验证 | 运维、安全和评估成本高 | 跨系统执行能力有限 | 建设周期长、投入大、复用性低 | | 更适合的用户 | 希望快速发布 Agent 的开发者和企业 | 有工程团队的技术用户 | 个人和轻量办公用户 | 大型企业和复杂行业客户 |

开源方案的优势是自由，企业可以掌握模型、数据和运行环境，但这意味着团队需要自己处理沙箱、调度、权限和监控。WorkBuddy 的优势则是把大量通用工程工作平台化，让开发者更快验证产品；代价是需要接受腾讯的审核、产品规则、运行环境和生态依赖。

因此，WorkBuddy 不太可能凭一个平台就取代所有开源方案。更现实的判断是，它会吸引大量希望快速做出行业 Agent、但不想从底层运行时开始搭建的团队。对于硬件厂商和传统软件厂商来说，WorkBuddy 还可能成为把已有能力“智能化包装”的分发渠道。

仍需补上的三块拼图

第一，平台需要公开更完整的开发者规则和商业机制。当前已知信息包括认证方式和可接入能力，但开发者最关心的审核周期、上架规则、调用额度、分成方式、企业部署模式和 SLA 尚未在公开资料中充分呈现。没有这些信息，生态规模很难从“首批伙伴”进一步增长为稳定供给。

第二，平台需要建立可量化的 Agent 评测体系。技能能否完成任务，专家是否真的具备专业质量，连接器是否稳定，不能只靠演示视频判断。开发者需要看到任务成功率、平均执行时间、人工接管率、失败原因和单位任务成本，企业则需要知道不同 Agent 在真实数据上的表现。

第三，平台需要把安全治理做成默认能力。Agent 一旦能够读取文件、访问企业系统或控制硬件，传统的账号权限就不够用了。平台需要支持最小权限、敏感操作确认、调用审计、数据脱敏、沙箱隔离和异常回滚。对企业而言，“能不能自动完成”排在“出了问题能不能追责和恢复”之后。

腾讯此前披露的 Agent Runtime、Memory 服务、零信任访问和 AgentOps 平台方向，正是为解决这些问题而准备的基础设施。但这些能力最终能否在开放平台上以简单、稳定、透明的方式交给第三方，还要看后续产品落地，而不是发布会上的概念完整度。

WorkBuddy会成为腾讯的Agent操作系统吗？

WorkBuddy 开放平台的战略价值，在于它把腾讯已有的模型、办公产品、云基础设施、硬件合作和行业能力放到了同一张 Agent 生态地图上。对用户来说，入口可能仍然是一个桌面窗口、企业微信消息或智能硬件；对平台来说，背后连接的是一套能够持续调用技能、专家和外部系统的运行网络。

腾讯能否把 WorkBuddy 做成 Agent 操作系统，取决于三个数字：开发者能否持续加入，企业能否持续使用，Agent 能否稳定完成真实任务。超过 100 家首批共创伙伴和 30 余个行业应用是一个不错的起点，但还不是平台成功的证明。

更值得关注的是，腾讯选择在 Agent 市场从“单点工具竞争”转向“生态连接竞争”时开放底座。模型能力正在快速趋同，单个聊天窗口很难形成长期壁垒；相反，连接器数量、企业数据沉淀、工作流复用和用户习惯会产生更强的网络效应。

我们的判断是，WorkBuddy 开放平台对腾讯而言比再推出一个办公助手更重要，对开发者而言也比增加一个模型选项更有价值。它能否成为国内 Agent 生态的重要基础设施，暂时还不能下结论；但从产品方向看，腾讯已经明确押注了一件事：下一代办公入口不是“人找工具”，而是“人提出目标，Agent 负责调度工具和组织协作”。

结语

WorkBuddy 开放平台今日上线，意味着腾讯开始向外部开发者开放技能、专家、连接器和外部应用接入能力。首批超过 100 家共创伙伴、9 款智能硬件和 30 余个行业应用，展示了腾讯试图构建的生态范围。

对于开发者，眼下最值得做的不是简单把一个聊天机器人接入平台，而是寻找能够被标准化、可评估、可复用的专业工作流。对于企业，判断平台价值的标准也不应只是回答是否聪明，而应是 Agent 能否在权限可控的前提下，真正连接业务系统、交付结果并留下组织资产。

这场竞争才刚刚从“谁的模型更强”进入“谁能把 Agent 接进更多工作场景”。WorkBuddy 的下一步，不在于再展示多少功能，而在于让第三方 Agent 真的跑起来、用起来，并且经得住企业生产环境的长期考验。

参考来源

• IT之家：腾讯 WorkBuddy 开放平台上线，将全面开放 Agent 基座能力：提供开放平台上线时间、认证方式、首批硬件和行业应用等信息。
• 知乎：腾讯想让企业打开 AI 的方式只剩一个：补充腾讯 WorkBuddy 企业版、Agent Suite、连接器和企业工作流方向的行业观察。
• 腾讯云开发者社区：WorkBuddy 竞争分析：提供 Agent 基础设施、生态整合和竞争格局相关分析。
• 中国日报：从超级个体到超级团队，腾讯首发效率智能体工具集：补充腾讯云在模型、推理服务、Agent Runtime 和企业智能体套件方面的公开信息。