WorkBuddy 开放平台详解：五大核心能力、API 接入与竞品定位

WorkBuddy 开放平台把两件事连在了一起：让行业服务进入办公 Agent，也让外部产品调用 Agent 完成任务。接入价值取决于具体任务能否可靠交付，以及开发者能否保留自己的业务控制权。

一、9 月 2 日发布了什么

2026 年 9 月 2 日，腾讯宣布 WorkBuddy 开放平台上线，首批引入超百家生态伙伴。科技日报的现场报道还记录了 9 款联名硬件和 30 余个行业应用。它们属于发布时披露的生态规模，不代表付费客户数、活跃开发者数或已经通过独立验证的使用效果。科技日报现场报道

"9.2"指发布日期。官方更新日志显示，9 月 2 日桌面客户端版本为 5.5.1 ；前一天的 5.5.0 已加入行业 Buddy 应用入口。客户端更新与开放平台上线是相关但不同的发布事项。WorkBuddy 更新日志

可以先形成三个判断：

产品边界向外延伸。 第三方既能给 WorkBuddy 增加能力，也能把它接到自己的产品里。
行业应用的价值需要来自专业资产。 相同模型和相似提示词容易被复制，业务数据、服务权限、质量标准和客户关系更难替代。
开放程度需要逐层判断。 文档公开、账号获批、接口可用、生产稳定、商业回报成立，是五个不同阶段。

二、五大核心能力分别解决什么问题

官网将首期生态归为 Buddy 应用、专家、Skill、连接器、硬件五类。专家团属于专家体系的协作形态，Open API 则是第三方调用能力的接口层，不宜混成另一套"五大能力"。开放平台官网

能力开发者提供什么适合的起点

Buddy 应用行业专属工作台与场景配置已有用户、数据和多项业务能力的产品团队

专家 / 专家团专业角色、工作方法与分工有稳定判断流程的领域服务

Skill 可复用的任务步骤、资料和脚本能交付一种明确成果的小工具

连接器对外部服务的授权访问和操作已有 API 或成熟 CLI 的软件厂商

硬件设备采集与交互入口希望把设备输入转成后续任务的厂商

Buddy 应用：把能力组织成用户能直接选择的场景

官方文档支持配置工作模式、场景胶囊、模型组合和行业市场，并可通过 MCP Apps 接入已有服务。WorkBuddy 承担多 Agent 协作、上下文、记忆与工具编排等基础能力；应用配置需要经过预览和审核，更新也要重新审核。Buddy 应用文档

这里的产品工作是安排任务入口与完成标准。例如"销售工作台"不应只陈列"写作专家、表格专家、搜索专家"，可以直接提供"整理拜访记录""生成跟进草稿""检查客户信息缺项"。用户选择任务，产品在内部组织能力。

这也意味着，品牌工作台与完全独立的白标产品不能画等号。独立安装、独立账户、独立计费与完整数据迁移能力，需要另行确认。

专家与 Skill：专业判断和可重复步骤分开维护

专家包通过插件配置与 Agent 定义描述角色，可声明技能和连接器依赖；文档明确，专家不能自行添加系统工具权限。Skill 则以 SKILL.md 为入口，搭配参考资料、脚本和模板。专家文档、Skill 文档

建议把"判断资料是否充分、怎样组织结论"放入专家，把"读取表格、校验字段、生成固定格式文件"放入 Skill。这样更容易分别测试：判断错了检查方法，文件错了检查脚本。复杂任务也不必立即增加多个专家，先证明分工能减少返工。

连接器：让业务能力可调用

官方提供 MCP + Skill 与 CLI + Skill 两种接入方式：网络服务优先 MCP；已有稳定命令行工具时可以选择 CLI。文档要求凭证不进入安装包或示例，并强调最小权限。连接器文档

对 SaaS 厂商，最有价值的第一版通常是少量明确动作：查询订单、读取客户资料、创建草稿。不要一开始暴露任意 SQL、任意文件读取或不受约束的批量修改。服务端仍须校验用户、租户、对象权限和操作额度，不能只相信模型传来的参数。

硬件：把采集延伸为可完成的工作

发布报道展示的方向包括智能眼镜、录音设备等，目标是让设备输入与账号、任务、产物形成多端连续体验。这属于发布会展示与目标，具体到某一设备的上市状态、固件和开放权限仍需逐项验证。中国证券报现场报道

硬件方案应测试完整链路：采集内容能否正确归属用户，生成的待办是否准确，跨设备后能否找到结果，用户能否撤回授权。仅有转写准确率不足以证明办公任务已经完成。

三、Open API 开放到哪一步

公开接口覆盖用户授权、本地助理、云端任务和产物等能力。采用用户授权后调用的方式，不能把一个开发者密钥理解为可任意控制所有用户。

接口方向文档已列出的能力接入时要防止的误解

身份授权 OAuth 授权码、访问与刷新凭证、权限范围用户授权不等于无限业务权限

本地助理查询在线状态、发送消息、增量读取历史有公网 API 不等于本地电脑离线也能执行

云端任务创建和查询任务，获得 ACP 通信信息云端任务不自动拥有本机文件

交互与成果实时通道、审批回复、会话产物查询接受任务不等于已经成功交付

积分权益兑换码核销核销接口不等于开发者支付分账

依据：Open API 文档。当前公开文档的手机号校验接口表格与请求示例存在 GET / POST 不一致；正式集成应通过官方确认与测试确定行为，不能原样复制所有示例。

一个安全的最小流程可以是：用户授权 → 业务后端校验请求 → 选择本地或云端任务 → 展示进度与待确认操作 → 用户确认 → 保存成果引用。这是建议架构，尚未进行账号接入实测。

若已有短信、设备或网页入口，应优先验证官方接口能否覆盖消息发送、任务结果和审批交互，减少对桌面内部协议的依赖。但撤销授权、重复消息、断线恢复、任务取消与费用限制，都要加入测试清单。

四、与扣子、Dify、OpenClaw 如何定位

这些平台覆盖范围有重叠。选型应比较控制权和交付方式，不能靠功能数量排名。

平台官方资料显示的主要路径相对定位与选择建议（外部研判）

WorkBuddy 行业工作台、生态组件、用户授权下的本地与云端任务适合把专业服务带到已有办公入口，或给已有产品增加 Agent 执行能力

扣子构建智能体与工作流，再发布为 API、SDK 等服务适合以自己设计的应用逻辑为核心；先比较已有流程能否直接复用，避免重复搭建

Dify 可视化工作流、知识处理、插件、API 与自托管选择对执行路径可观察、后端编排与部署控制有明确要求时，值得优先评估

OpenClaw 自托管 Gateway，连接消息渠道、会话、工具与 Agent 适合愿意承担配置、安全和运维责任，并需要更强运行环境控制的团队

竞品事实依据：扣子工作流 API、扣子工作流与对话流、Dify Workflow Studio、Dify 部署方式、OpenClaw 官方概述。比较限于这些公开能力，没有进行同任务性能测试。

对 WorkBuddy 的定位判断

它正在争取三个位置：用户开始工作的入口、第三方专业能力的分发位置、外部产品调用的任务执行层。竞争压力也来自三个方向：入口要有复用频率，分发要给开发者带来有效用户，执行层要有可预期的质量和成本。

"Agent 操作系统"可以表达战略方向，但选型时仍应拆成可检验的问题：任务是否能恢复？权限是否可撤销？成果是否可导出？用户换工具时能否带走业务记录？这些问题比战略称呼更接近采购与开发决策。

对其他平台的建议：保留业务主系统，增加 Agent 入口

已有 SaaS、行业数据库或工作流平台，可以把 WorkBuddy 看作新增渠道和执行客户端。订单、客户、权限与账务仍以自己的系统为准，Agent 读取必要上下文，再通过受控接口提交操作。

对于已有 Dify 或扣子流程的团队，先尝试把成熟流程包装成可调用服务，测量结果是否足够稳定；没有必要为了加入一个生态，把所有业务编排迁移过去。接口与协议适配仍需要开发，不能假定工作流或插件可以无损通用。

对于硬件平台，设备身份、采集质量、断网缓存与设备生命周期应保留在自己的产品体系中。WorkBuddy 可以提供任务理解与执行，但设备厂商仍要对完整体验负责。

五、开发者应怎样选择接入路径

你的现状建议第一步第一轮应验证什么

有方法和模板，没有业务后端一个 Skill，必要时配一个专家陌生用户能否得到符合标准的成果

有 API、数据或工具一个只读连接器授权成功、工具选对、数据没有越权

有稳定客户和多项行业任务一个小范围 Buddy 应用用户是否会持续使用场景入口

有 App、网页或硬件入口一个用户授权的任务调用试验进度、审批、结果能否回到原入口

需要无人值守的持续业务服务先核实云端运行与服务条款不依赖个人电脑，且可处理失败和费用上限

个人与企业均有入驻认证路径，适用证件、主体和发布条件以当前后台为准。认证通过也不意味着所有能力自动开放。入驻指南

项目预算至少应包含模型或平台消耗、第三方数据费用、连接器维护、人工复核和客户支持。建议用"每个被用户接受的成果花了多少钱"评估经济性，分母中排除失败和被退回的结果。

独立开发者更适合先选择一个有明确验收标准的任务，例如把指定格式的会议记录整理为待办草稿。面向高风险行业时，专业审查必须作为产品流程的一部分，不能以专家名称代替真实资质或审核。

六、后续如何计划：官方方向与建议分开

已披露的方向

深圳新闻网的发布报道提到，WorkBuddy 的支付能力与分发通路正在建设。可以确认商业化与分发是后续方向；这不构成具体上线日期、抽成比例、结算周期或流量保证。发布报道

对平台方的产品建议

以下是外部建议，不是腾讯内部路线图。

先提高可接入性。 保持文档、示例和实际接口一致，公开各能力的账号条件、错误处理和版本兼容规则。
让质量可以比较。 给开发者提供任务失败分类、授权流失位置和成果验收反馈，避免市场只展示安装量与资产数量。
补齐经营规则。 明确谁付费、失败任务如何处理、第三方服务怎样收费、退款和售后由谁承担。
把迁移能力做成可信承诺。 公开业务数据与成果的导出边界，让伙伴能够评估长期依赖成本。

给接入团队的 90 天验证计划

时间与样本量都是建议值，用于安排验证，不是效果预测。

阶段工作范围进入下一阶段的条件

第 1--14 天选一个高频任务；准备约 20 个脱敏样本；完成授权、调用、结果获取同一批样本可重复测试，知道失败发生在哪一步

第 15--30 天邀请约 5--10 名目标用户；加入过期授权、重复请求与离线测试用户能独立完成任务，关键权限错误已处理

第 31--60 天接入受控写操作与人工审批；记录成本、返工和支持时间单次交付成本可接受，高风险操作有阻断和追溯

第 61--90 天按使用证据决定扩展 Buddy 应用、多入口或继续优化单点能力复用需求来自真实用户，商业条款和运维责任已经确认

每周看四项指标就够：任务完成率、成果接受率、人工介入时间、单位有效成果成本。分别保留"系统声称完成"和"用户接受"的记录，避免把模型输出当作业务成功。

如果用户只尝鲜一次，应检查任务频率与入口是否合适；如果经常需要人工修正，应先收窄范围或改进规则；如果推理成本低但售后成本高，扩量会放大亏损。验证不过关时，延后扩展到更多专家和行业。

七、未能验证与选型前必问项

接口可用性： 未使用已审批的开发者账号实测，文档存在不一致之处；生产并发、限流、稳定性与恢复能力需要验证。
商业化： 未确认统一分成、定价权、提现和结算机制，也没有生态伙伴收入数据。
数据与记忆： 未验证跨设备、跨应用的记忆访问与隔离细节；不能从"多端同步"推断第三方可以导出全部用户记忆。
运行环境： 本地与云端的文件、工具、网络条件不同；同一场景是否表现一致需要实测。
规模指标： 未取得独立审计的活跃人数、留存率与任务成功率，不据累计安装量推算收入。
生态互通： MCP、CLI 和 Skill 可减少部分适配工作，但权限、展示字段和运行环境仍可能绑定平台。

近期最合理的行动是完成一个可退出、可测量的接入试验。让 WorkBuddy 证明它能带来更好的交付或更多有效用户，再决定投入多少产品能力。

八、信息来源与说明

资料截至 2026 年 9 月 4 日。功能以开放平台官方文档为主要依据；发布日期、现场生态规模与战略表述由科技日报等发布会报道交叉确认。没有完成客户端对比评测、开发者后台申请或真实业务 API 联调。

平台定位、接入顺序、产品建议与 90 天计划属于外部研判。示例场景是设计建议，不代表客户案例或已上线功能。公开文档可能继续更新，申请与开发时需重新核对。

相关专题：WorkBuddy 入门、WorkBuddy 个人短信助理方案、双向短信群与 Agent 架构。旧方案中的接口可用性判断带有原始资料日期，应结合新开放文档重新评估。