腾讯エンジニアが Kuikly で DeepSeek Harness をモバイル化

オリジナル記事：腾讯程序员 2026年9月8日 17:57 投稿于广东

「一码三端」のネイティブアプリを使えば、DeepSeek Harness をそのままポケットに持ち運んで、PC 版を直接操作できます。

作者：腾讯程序员 yuki

DeepSeek Harness は非常に面白いツールですが、PC の画面に縛られていてはもったいない。そこで私は Kuikly フレームワークを活用し、「一码三端（1 つのコードで Android、iOS、HarmonyOS をカバーする）」を実現したネイティブアプリを開発しました。このアプリでは、公式の Host プロトコルを通じて PC 上の DeepSeek Harness と対話することができます。

DeepSeek Harness でタスクを実行すると、完了までに数分乃至それ以上の時間がかかることが珍しくありません。その間、処理が一時停止し、人間の介入を待つ場面も頻繁に発生します。承認待ちや情報の追加、方向性の確認などがそれに当たります。もし人間が PC から離れてしまうと、そのタスクはそこで足止めされてしまいます。

私が解決しようとしたのは「スマホでコードを書く」という課題ではありません。むしろ、短くても頻度の高いやり取りをスマホで受け持つ仕組みを作ることが目的でした。通勤中や会議の合間、待ち行列にいるときなどに、スマホでタスクの進捗を確認し、承認処理を行ったり、Agent からの質問に答えたりするのです。そうすれば、PC 側での実行は継続されます。

そこで Kuikly を活用して「DSH Mobile」を開発しました。Kotlin のコードを 1 つ書くだけで Android、iOS、HarmonyOS に対応し、DSH 公式の Host プロトコルに従って PC 上の Harness と接続します。Agent のループ処理やツールの実行、プラグインの動作はすべて PC 側で行い、スマホ側では接続管理、ユーザーとの対話、そして画面描画を担当します。

最も手軽な方法として WebView を使う手もありますが、このアプリは単に Web ページをスマホ用に縮小しているわけではありません。WebSocket の長期間接続を維持し、ロック解除やバックグラウンド切り替え、ネットワークの切替といった状況に対応する必要があります。また、再接続した際には見逃されたイベントも補完しなければなりません。QR コード読み取り、SSH トンネルの構築、ローカルキャッシュの管理などにもプラットフォーム固有の機能が必要です。こうした要件を考えると、ネイティブクライアントの方が適していると言えます。

DSH App のページ機能デモ：

Kuikly を使う理由

このプロジェクトでは、クロスプラットフォームフレームワークに対する要件が極めて具体的です。

チャット画面の本文は常に変化する Markdown です。モデルが出力するたびにページが更新され、ツール呼び出しや承認待ちカード、質問カード、バックグラウンドタスクも同時に反映されます。その裏側では HTTP RPC、2 つの WebSocket イベントストリーム、QR コードによるペアリング、SSH トンネル、ローカルストレージといった複雑な仕組みが動いています。3 つのプラットフォーム（Android、iOS、HarmonyOS）は見た目だけでなく、接続や復旧の挙動も一貫している必要があります。

Kuikly を選んだ最も直接的な理由は開発スピードです。コンポーネント市場にはすでに多くの標準機能が用意されており、必要なコンポーネントを見つけて依存関係を追加するだけで共有コードとして利用できます。Android、iOS、HarmonyOS 向けにそれぞれ別々の実装を書く手間が省けます。

Kuikly の AI 開発サポートも非常に実用的です。本プロジェクトでは「KuiklyUI-AI」を活用しました。これは Kuikly DSL と Kuikly Compose DSL の開発ルールを提供し、コンポーネントの使用法や Module 拡張、ネットワークリクエスト、反応型状態管理、コルーチン、マルチプラットフォーム対応のリソース活用といったスキルを包括しています。これらのルールは CodeBuddy、Cursor、Claude Code などの AI プログラミングツールに引き渡せます。AI エージェントがページ作成やコンポーネント接続、ネイティブブリッジの補完を行う際、Kuikly の API やプロジェクト規約を一々推測する必要がなく、生成されたコードをそのままプロジェクトに組み込むことが可能です。プロトコルモデル、状態マシン、重複するページなどは Agent に任せておき、私は主にインタラクション、プラットフォーム間の差異、実機での動作を確認する役割に集中できます。

コンポーネント市場：Markdown と WebView の高速導入

DSH Mobile では、2 つの既存コンポーネントをそのまま採用しました。

implementation("com.tencent.kuiklybase:KuiklyMarkdown:1.0.6-2.1.21")

implementation("com.tencent.kuiklybase:KuiklyWebview:1.0.1-2.0.21")

特に KuiklyMarkdown が省略できる作業は大きいです。AI 会話における Markdown は一度解析すれば終わりではなく、モデルからの出力が継続的に変化するため、コードブロックやリスト、引用、リンクも随時更新されなければなりません。ゼロから実装する場合、まず三端で動作するパーサーを探し出し、AST から UI へのマッピングを実装し、コードハイライトやテーマ設定、リストのインデント処理、ストリーミング対応などをすべて手掛ける必要があります。

KuiklyMarkdown はこの骨格をすでに完成させています。intellij-markdown をベースにテキストを解析して Block リストを出力し、ストリーミングレンダリングの状態管理も提供しています。導入後は DSH 独自のビジネスロジックに集中できます。完了した Block は固定され、末尾のコンテンツのみが継続的に更新されます。コードブロックがまだ閉じていない場合は、解析用のコピー版に閉じタグを追加します。ページ更新は 16 ミリ秒ごとにフレームを合成し、小さなチャンクが来るたびに再描画するのを防ぎます。

これにより、Markdown 文法の解析やコードブロックのレンダリング、三端共通の基礎スタイルを自社で維持する必要がなくなります。ストリーミングシーンに集中できるため、長文回答の前半部分は安定して表示され、末尾はモデルの出力に合わせてリアルタイムで更新されます。

KuiklyWebview は Markdown 内のリンクや外部ページをアプリ内で開く際に使用します。共有ページに WebView を配置し URL を設定するだけで、読み込み開始、進行状況、完了、失敗などのイベントを監視すれば十分です。更新処理と戻る動作のロジックも同じ Kotlin コードで完結します。このコンポーネントがない場合、Android の WebView、iOS の WKWebView、HarmonyOS の Web コンポーネントをそれぞれ個別にラップし、イベントを共有層へブリッジする必要があります。

コンポーネント市場には他にも SQLite、カメラ、画像選択、録音、位置情報、Bluetooth、MMKV などの標準機能が用意されています。本プロジェクトではこれらすべてを導入していませんが、新機能開発時には既存のコンポーネントから探すのが基本です。クロスプラットフォーム開発において、単なるコントロールの数を減らすだけでなく、3 つのプラットフォームそれぞれで実装・調整・保守する必要がある基礎機能を削減できる点が大きなメリットです。

ネイティブブリッジ能力：差異は底層へ、共有層はビジネスロジックに統一を

クロスプラットフォームプロジェクトで最も時間を要するのは、ページの実装そのものではなく、WebSocket、QR コード認証、SSH、データベースといったシステム機能の構築です。

DSH Mobile では、commonMain モジュール内で接続、メッセージ送信・受信、切断といった業務ロジックを定義した統一された Module インターフェースを用意しています。Android、iOS、HarmonyOS（鸿蒙）ではそれぞれが自社のシステム実装に対応し、このインターフェースを実装します。

WebSocket を例に挙げると、三つのプラットフォームの基盤層はそれぞれ OkHttp、NSURLSession、NetworkKit ですが、上位レイヤーのページ実装が直面するのは共通の DshWebSocketModule だけです。プラットフォーム固有の違いは最下層で吸収され、チャット画面やイベント処理、ビジネス状態管理などは「どのシステム上で動作しているか」を意識する必要がありません。SSH トンネルや QR コードによるペアリングも、同じくこのレイヤー設計によって統一されています。

このように機能を下位に集約するメリットは、プロトコルが変化するほど顕著になります。DSH はまだ完全に安定した状態ではありませんが、今後 RPC の追加やイベント仕様の改修が発生しても、共有層のみを変更すれば三つのプラットフォームで同時に反映されます。これは後から各プラットフォームごとに別々の実装を維持するよりもはるかにコスト効率が良いのです。

現在、プロジェクトには約 1.3 万行の Kotlin コードが commonMain に定義されており、これらは三つのプラットフォームで共有されています。Android、iOS、HarmonyOS のホスト側にはそれぞれ数千人分のコードがあり、主にシステム機能への接続や各プラットフォーム特有の設定作業に用いられています。コンポーネントはそのまま再利用でき、プロトコルと状態管理は共有層に残すため、同じ機能を三つのプロジェクトで個別に実装する必要はありません。

Kuikly における三つのプラットフォームでの同一ページの実装例：

Android、iOS、HarmonyOS の三つのプラットフォームにおける UI 比較ページ

中間層を設けず、直接 Host プロトコルに接続する構成です。

DSH Mobile は、スマートフォンと PC の間に独自の業務サービスレイヤーを追加していません。代わりに、公式 Web フロントエンドの背後にある Host プロトコルをそのまま利用しています。ブラウザが DSH をどのように呼び出すかという仕組みは、App 側でも同じ方法とイベントフローを踏襲しています。

DSH はもともと Cordis を基盤としたプラグイン化されたエージェントランタイムです。モバイル端末との接続に関わる部分は、大きく 3 つの層に整理できます。

「core/session」「agent-loop」「tools」は、それぞれセッション管理、エージェントのループ処理、ツール実行を担当し、必要なイベントを生成します。「host/apiproxy」は内部機能を RPC メソッド表と 2 つの下り方向イベントストリームにまとめます。そして「client/connection」がこれらを本機のポート 3080 に接続し、外部に対して HTTP の /api/...、WebSocket の /api/events.mux と /api/events.host を提供します。

PC 上のエージェントは引き続きワークスペースの読み書きやツールの呼び出し、プラグインの実行を行います。一方、アプリ側は最外層の client/connection に接続するだけでよく、DSH 内部のプラグイン構造を理解したり再翻訳したりする必要はありません。

メッセージ送信は HTTP RPC の一種

DSH は利用可能な機能を 1 つの RPC メソッド表に登録します。例えば dsh-v0.1.1-rc.2 では 52 個の方法が定義されています。メッセージ送信に対応するのは session.prompt で、リクエストパスは POST /api/session.prompt です。セッション一覧、履歴、ワークスペース、モデル、Goal（目標）、設定など他の機能もすべて同じ RPC チャンネルを経由します。

メソッドの引数と戻り値は TypeScript の関数シグネチャから取得され、レジストリがメソッド名を実際の処理実装にマッピングします。DSH Mobile は必要な部分のみを実装しており、モバイル向けに独自に別のインターフェースを構築しているわけではありません。

完全な方法表は rpc-map.ts で確認できます。「52」という数字は本文で参照されたバージョンに限定されたものです。DSH は現在も急速に迭代（更新）を続けており、接続する際は常に最新マスターブランチが互換性を持つと信じるのではなく、すでに検証済みのタグを固定して利用するのが安全です。

2 つの WebSocket がそれぞれ役割を分担

リモート接続が確立されると、Host は 2 つの「下り方向のみ」の WebSocket を通じて App にイベントをプッシュします。

/api/events.mux は、現在のセッション内で進行中の出来事を担当します。具体的にはモデルからの出力、ツール呼び出し、承認・質問、メッセージキュー、バックグラウンドタスクなどが含まれます。

/api/events.host は PC 側のグローバルな変化を管理します。セッションの追加・削除、実行状態、ワークスペースの変更、Host レベルのエラーなどが対象です。

このようにストリームを分離することで、会話本文とグローバル状態が同じチャンネルで競合することがなくなります。App もライフサイクルに応じてそれぞれを別々に処理できます。チャットページでは主に mux を消費し、ワークスペースやセッション一覧では host に依存する傾向があります。

ただし、2 つの点には特別な注意が必要です。

1. session/queue と session/jobs は「追加された行」のようなインクリメンタルなイベントではなく、完全なスナップショットをプッシュします。これらはセッションログに含まれず、再接続時にもイベント再生成だけで復元できないため、App 側は新しいスナップショットを受信すると即座にローカル状態を上書きします。
2. session/projection.value と host/remote-event.args はキャリア層では広義の型（wide type）です。その構造はそれぞれの業務パッケージが管理しており、App 側はすべてのフレームが厳密なデータクラスに従うと仮定できません。未知フィールドを保持し、解析に失敗した場合はストリーム全体を中断させるのではなく、 gracefully にフェイルオーバー（降格処理）を行う必要があります。

接続断線時は「イベント補完」→「履歴同期」の順序で復旧

モバイルネットワークでは切断が避けられません。ロック画面、バックグラウンドへの切り替え、トンネル内での通信、Wi-Fi とセルラー回線の切替などが原因で接続が失われる可能性があります。

DSH Mobile は再接続後、以下の手順で状態を回復します。

1. SSH または Relay トンネルを再構築する。
2. 最後に受信したシーケンス番号を用いて、欠落した session/event を補完する。
3. session.history をリクエストしてチャット履歴の整合性を再調整する。
4. 最新のスナップショットで queue と jobs の状態を上書きする。

各接続には世代番号が付与されます。接続が切断された後、旧接続から遅れて到着した RPC 応答はすべて破棄され、新しいセッション状態に反映されることはありません。

もしエージェントが切断中にパソコン上で実行を続けていた場合、アプリが再接続した際にはそのタスクの再購読が行われ、ユーザーのプロンプトが再度送信されることはありません。この違いは非常に重要です。再接続は観察と制御の回復であり、タスクの再実行ではありません。

状態マシンは共有層に位置しているため、3 つの端末で同じ補完順序と失效ルールが適用されます。プラットフォーム側のコードは、単に底層の接続イベントを共有層に渡す役割のみを果たします。

DSH Mobile の 2 つの遠隔接続方式

DSH はデフォルトで 127.0.0.1:3080 を監視しています。これは維持すべきデフォルト値です。なぜなら、このポートにアクセスできるクライアントは、エージェントやツールを通じて高いローカル操作権限を有している可能性があるからです。DSH Mobile では 3080 ポートを直接公网に開放するのではなく、SSH と QR コードによる Relay の 2 つの接続方式を提供しています。

SSH があればトンネルでつなぐ

SSH モードでは、スマートフォン上でローカルポート転送を確立し、アプリ側のループバックポートをパソコンの 127.0.0.1:3080 にマッピングします。HTTP RPC と 2 つの WebSocket はすべてこのトンネルを通じて転送されます。

この方式では DSH の認証ロジックは変更されません。認証は SSH レベルで行われ、DSH は依然としてローカルループバックからのリクエストのみを受け取ります。SSH ホストとキーの設定が既に整っている場合、この経路が最も直接的です。

SSH 設定が面倒なら、QR コードをスキャンして接続

手動でアドレス、ポート、キーを入力するのは一般的なモバイル操作には不向きなため、私は dsh-scan-remote プラグインを追加しました。

プラグインをインストールすると、DSH Settings に「Remote Access」ページが追加されます。パソコン側で QR コードを生成し、スマートフォンでスキャンしてペアリングを完了します。パソコン側のプラグインとアプリの両方が Relay へ能動的に接続し、sealed-tunnel-v1 を介して DSH のトラフィックを転送します。

接続時、DSH は依然としてパソコン上の 127.0.0.1:3080 だけを監視しています。Host プラグインはローカルから DSH にアクセスし、Relay へ能動的に接続します。スマートフォン側のアプリも同じ Relay へ能動的に接続します。両端がペアリングを完了すると、App から送信された HTTP と WebSocket のトラフィックは密封トンネルを経由して Host プラグインに転送され、そこからパソコン内の DSH に届けられます。この間、Relay は直接 3080 ポートにアクセスする必要はなく、パソコン側も DSH サービスを LAN や公网に開放する必要はありません。

QR コードに含まれるマスターキーは URL フラグメント内にあります。通常の HTTP リクエストではフラグメントが Relay に送信されることはありません。トンネル内のデータは密封された状態で転送され、Relay は単に接続相手とデータの伝達のみを担当します。

スマートフォンを意思決定ノードの入口として活用

DSH Mobile は現在、短く軽量で頻度の高いインタラクションに適しています。

エージェント実行中は、スマートフォン上でストリーミング応答やツールのステータスを確認できます。コマンド承認が必要な場合は、直接許可または拒否できます。エージェントからの質問に対しては、追加情報を補足してタスクを継続させることも可能です。バックグラウンドジョブ、Goal の進捗状況、そしてセッションの状態も、隙間時間で確認するのに適しています。

一方で、長いプロンプト、大規模なコード Diff、あるいは持続的な思考を要する修正作業については、依然としてデスクトップ環境の方が適しています。スマートフォン画面や入力方式が、エージェントへの接続によって突然拡大するわけではありません。このアプリの位置づけは「遠隔コントロールパネル」であり、完全な IDE をスマートフォンに移植するものではありません。

このような製品は現在、ますます一般的になりつつあります。Cursor の iOS アプリではクラウド上のエージェントを起動でき、Remote Control 機能を通じてパソコン上のエージェントも操作可能です。ChatGPT のデスクトップ版のドキュメントによると、Codex は ChatGPT モバイルアプリにも組み込まれており、Mac ホスト上で実行中のタスクを引き継ぐことができます。また、Claude Code Remote Control もスマートフォンから本機のセッションを継続することをサポートしています。

各社の実行位置やデータパスは異なりますが、すべてが同じ変化に対応しようとしています。具体的なコーディング作業をエージェントに任せることで、人間は主にタスクのノードにおいて意図を示し、判断を下し、結果を確認する役割へとシフトします。これらの動作には、人が常にパソコンの前に座っている必要はありません。

「DSH Mobile」の次なるステップは、入力機能の強化です。

すでに session.prompt は画像コンテンツ配列をサポートしており、これを基盤として画像アップロードや音声入力を追加する計画があります。通知機能については、PC 側の連携が不可欠です。単にアプリ側に通知権限を付与しただけでは、「いつタスクの処理に人間の介入が必要か」を把握できません。

現時点では、プッシュ通知のために公式プロトコル外の RPC を勝手に追加する方針ではありません。まずは接続と再接続の安定性を徹底して確保します。

このクライアントは、必ずしも DSH に永久バインドされるわけではありません。多くの Agent Host において、モバイル端末が求める基本機能（セッション一覧の表示、メッセージ送信、イベント受信、承認処理など）は非常に類似しています。ストリーミング Markdown、ツールカード、切断状態マシン、そしてセッションモデルはすでに共有層に実装済みです。

今後、他の Agent サービスへ接続する際は、主にプロトコルアダプタを追加するだけで済み、三つの端末向けインターフェースをゼロから書き直す必要はありません。

すぐに動かす

「紙の上の知識は浅い。真に理解するには自ら実践せねばならない」という言葉通り、ここまでの説明だけでは不十分です。実際に手を動かして効果を確認しましょう。

#### DSH と Relay の起動

ローカル環境でのスキャン接続は、以下の 4 ステップで完了します。

1. Relay を起動する。
2. スキャン用プラグインをインストールし、DSH を起動する。
3. スマホに「DSH Mobile」をインストールする。
4. 「Settings（設定）」画面にある「Remote Access（リモートアクセス）」の QR コードをスキャンする。

まず、スマホと PC を同じ信頼できる Wi-Fi またはホットスポットに接続してください。

端末 1：ローカル Relay の起動

git clone https://github.com/yukiykchen/dsh-scan-remote.git
cd dsh-scan-remote/relay
cp .env.example .env
npm ci
npm run build
HOST=0.0.0.0 PORT=8787 npm start

ローカル環境で試す際、Relay はスマホからアクセス可能なネットワークインターフェースを監視する必要があります。HOST=0.0.0.0 を指定すると、8787 ポートがホストマシンのすべてのネットワークインターフェースに開放されます。これはセキュリティリスクがあるため、信頼できるネットワーク内でのみ使用し、システムファイアウォールの設定も確認してください。

次にプラグインをインストールして DSH を起動します。

端末 2：プラグインのインストールと DSH の起動

npx @deepseek-ai/dsh plugin --profile web add \
  "github:yukiykchen/dsh-scan-remote#v0.0.1"
export PUBLIC_RELAY_URL=http://192.168.1.10:8787
npx @deepseek-ai/dsh web

PUBLIC_RELAY_URL は、PC 現在のローカルネットワークアドレスに書き換えてください。この URL は QR コード内に埋め込まれるため、スマホ側から確実にアクセス可能である必要があります。

DSH が起動したら、「Settings（設定）」を開き、「Remote Access（リモートアクセス）」ページへ移動します。

アプリのダウンロードとインストール

Android ユーザーは、リリースページから APK ファイルをダウンロードしてインストールできます。

iOS では Xcode を使用して iosApp/iosApp.xcworkspace を開き、開発者署名を設定した上で実機にインストールします。HarmonyOS 側では DevEco Studio で ohosApp を開いて自行ビルドが可能です。コードリポジトリのリンクは「deepseek-harness-mobile」です。

QR コードをスキャンしてもタイムアウトが続く場合は、以下の三つを確認してください。

1. スマホから http://电脑局域网地址:8787/health にアクセスできるか。
2. PUBLIC_RELAY_URL がまだ PC の現在のアドレスになっているか。
3. Relay がスマホから到達可能なインターフェースを本当に監視しているか、ファイアウォールで 8787 ポートが許可されているか。

PC を Wi-Fi やホットスポットに切り替えると、ローカル IP アドレスは通常変更されます。その際は PUBLIC_RELAY_URL を更新し、DSH を再起動して新しい QR コードをスキャンしてください。

腾讯云上で実行：Agent に PC の常時接続を不要にする

個人用 PC でのローカル実行に加え、DSH Mobile は腾讯云の軽量アプリケーションサーバーとも連携できます。DeepSeek Harness を轻量应用服务器上 にデプロイすれば、Agent ループ、ツール実行、プラグイン、ワークスペースはすべてクラウド上で継続して動作します。スマホアプリは依然として接続、インタラクション、レンダリングのみを担当します。

これにより、長時間のタスクも PC の常時起動を必要としなくなります。作業席を離れたり PC を閉じたりしても Harness は実行を続けられます。ユーザーはスマホでストリーミング出力やツールの状態を確認でき、必要な時に承認処理を行ったり、文脈を追加したり、次の方向性を確認したりできます。

さらに開発を進めるなら、ここから始めよう

アプリの拡張だけを目指す場合は、入口が集中しています。

• 新しい Host メソッドを追加する場合: DshHostProtocol.kt に定義を追加し、既存の RPC チャンネルを再利用します。新しいシステム能力を伴わない限り、三つのプラットフォームで個別にネイティブコードを変更する必要はありません。
• 新しいネイティブ機能を追加する場合: まず commonMain で Module を定義し、その後三端の実装を補完します。Android は KuiklyRenderActivity からモジュールをエクスポートし、iOS の実装は KuiklyExpand/Modules に、HarmonyOS の実装は kuikly/modules に配置します。
• 新しいページを追加する場合: @Page アノテーション付きのページクラスを作成すれば、KSP が自動的にルートを生成します。

DSH 内部の新しいイベントをスマホに表示させたい場合は、対応するイベントを監視する DSH プラグインを作成し、host/remote-event を経由して転送します。ただし、対象となるイベントは Host 側で転送が許可された範囲に含める必要があり、App 側でも広義の型パラメータに対するフォールバック処理が必要です。

新しい公式 RPC メソッドを登録したり、伝送層全体を置き換えたりする場合は、単なるアプリの変更ではなく DSH 本体への改修となります。此类改动はアップストリームプロジェクトとして提出・維持管理するのが適切です。

関連リポジトリとリンク

• Kuikly フレームワーク
• Kuikly コンポーネントリポジトリ
• DSH Mobile
• QR コードスキャンプラグインと Relay
• KuiklyUI AI 開発ルールと Skills
• 腾讯云轻量应用服务器
• DSH RPC メソッド一覧表
• DSH ダウンストリームイベント定義

DSH はまだデベロッパープレビュー段階であり、プロトコルやパッケージ構造には破壊的変更が生じる可能性があります。本記事に記載されているメソッド数、ディレクトリ構成、イベント名は dsh-v0.1.1-rc.2 に対応しています。実際の開発では、検証済みのバージョンをロックして使用し、その後アップストリームの変更を追跡していくことをお勧めします。

Kuikly について

Kuikly は腾讯がオープンソース化した高性能なクロスプラットフォームフレームワークです。Kotlin Multiplatform 技術を基盤とし、Android、iOS、HarmonyOS、H5、微信小程序、Mac の 6 つのプラットフォームをカバーし、日次アクティブユーザー数は 5 億人を超えています。

現在 Kuikly はオープンソース化されており、興味やニーズのある製品は以下の方法で Kuikly リポジトリとドキュメントにアクセスできます。Star、Watch、体験のご利用を歓迎します：

👉 Github リポジトリ | 📚 公式ドキュメント

Kuikly フレームワークは、腾讯端服务联盟（tds.qq.com）の重要なメンバーです。詳細については公式サイトをご確認ください。

腾讯端服务公式サイト：TDS 腾讯端服务

Kuikly 公式サイト：跨平台框架

WeChat で開くにはこちらへジャンプ