把远程控制集成进自有系统

如果远程控制只是你团队自己用的一个工具，装个客户端就够了。

但当它要成为你自己产品的一部分——设备厂商想让自家软件带远程诊断、 SaaS 厂商想让客服在后台直接接管用户屏幕、运维平台想从工单页一键连上目标机器 ——这时候需要的就不是一个客户端，而是把能力嵌进去的接口。

WorksLink 为此提供三个集成面。先分清你的系统在哪一端，选择就清楚了。

三个集成面

集成进需要远程控制能力的软件里，装了你产品的那台机器就具备了被控能力。

典型的用法是设备厂商与软件厂商：你的产品已经装在客户机器上了，再让客户为了远程支持另外装一个远程控制软件，是一道多余的门槛—— 装机率会掉，而且出问题时客户往往正处在最不耐烦的时刻。

把被控能力做进你自己的安装包，这道门槛就消失了。

嵌入任意 Web 应用，让你的系统具备发起远程控制的能力。

这一端的典型用法是工单系统、客服后台、运维平台：工程师本来就在你的系统里处理问题，远程控制应该是那个页面上的一个按钮，而不是”打开另一个软件、找到设备、再连上”。

中间那几步不只是麻烦。每一次系统切换都是一次上下文丢失—— 工单号、设备标识、故障描述都要靠人重新对一遍，对错了就连到别的机器上去。

三类用途：

前两类的价值在于审计数据要落在你已有的系统里。连接日志留在远程控制软件自己的后台，等于合规检查时要多查一个地方；接进你的工单或合规系统，它才会真的被人看到。

第三类解决的是账号治理：员工入职离职时，账号的开通与回收应该只有一个地方要改。

不是三选一，大多数情况是按需组合：

一个常见的完整组合是设备厂商做售后：客户端 SDK 让出厂设备自带被控能力， Web SDK 让售后工程师在工单页直接发起，REST API 把会话记录回写进工单。客户那边不用装任何额外软件，工程师也不用离开工单系统。

跨平台，Windows、Linux、macOS 等主流系统都可以集成，支持主流编程语言。

这里有一点值得单独说明，因为它和下载页的信息看起来矛盾： WorksLink 自己的独立客户端目前只有 Windows 与 macOS 版本（见平台与下载 FAQ），但客户端 SDK 是跨平台的。

两者不是一回事：独立客户端是我们打包好的成品软件，SDK 是嵌进你的软件里的能力。所以如果你的产品运行在 Linux 上，通过 SDK 集成被控能力是可行的—— 即使 WorksLink 还没有独立的 Linux 客户端。

主流浏览器都支持，且无需安装插件。

不用装插件这点在实际部署里比听上去重要：需要装插件的方案，在客户的 IT 管控策略面前经常直接过不去，而且每次浏览器大版本更新都可能出问题。

取数是拉取模式——由你的系统按需调用接口取回连接日志与录屏，目前不提供 webhook 推送。

设计集成时要把这点算进去：如果你期望”会话一结束就自动写进工单”，需要在你这边加一个轮询任务，而不是等我们推给你。

接口认证使用 appKey + secret，这对凭据在商务开通时由客户经理发放。

secret 属于服务端凭据，具体的存放位置与签发方式随对接文档提供。规划架构时值得先把这一点问清楚：它决定了你的集成需不需要一个服务端中转层，而这个结论会影响工作量估算——发现得晚，返工的是整条调用链。

集成能力在团队版与企业版提供，免费版和个人版不含 —— 与定价页的功能对比一致。

但它不是自助开通的：需要联系商务，由客户经理配置后发放凭据。这和大多数功能不同，规划集成排期时要把这一步算进去。

技术文档目前随对接提供，暂时没有公开版本。

计费按并发通道计算，不按人头。这一点和多数远程控制产品不同，对集成场景尤其重要：接入的终端数量可能很大，但同时在进行的会话数通常远小于终端数，按通道计费意味着你为实际并发付费，而不是为装机量付费。

联系我们，说明你的场景、你的系统在哪一端、以及要取回哪些数据，会有客户经理与工程师对接，提供凭据与技术文档。