Skip to Content
ユーザーガイド機能チャンネルDingTalk Workspace

DingTalk Workspace (DWS)

DWS チャネルは、DingTalk Workspace CLI で既に認証されたアカウントを使用します。1対1チャットとグループメッセージを受信し、DingTalk ドキュメントメンションの通知カードを認識し、エージェントの応答を発信元のメッセージまたはドキュメントコメントに返信します。

これは DingTalk ボットチャネルとは別物です。専用アプリケーションボットには type: "dingtalk" を引き続き使用してください。Qwen Code が既存の DWS ログインを通じて動作する場合は type: "dws" を使用します。

前提条件

Qwen Code を実行するホストに DWS CLI 1.0.57 以降をインストールし、そのプロセスの PATH から dws が解決できることを確認してください。

dws version --format json

同じホストで認証を行います。

dws auth login
dws profile list --format json
dws auth status --format json

ヘッドレスサーバーでは dws auth login --device を使用してください。チャネルは起動時に正確に 1 つの既存プロファイルに固定します。profile を正確なプロファイル名または corpId に設定するか、省略すると isCurrent とマークされたエントリに固定します。チャネルはすべての DWS ログインを同等に扱い、user_id メタデータに依存しません。

設定

~/.qwen/settings.json にチャネルを追加します。

{
  "channels": {
    "dws-work": {
      "type": "dws",
      "profile": "profile-name-or-corp-id",
      "senderPolicy": "pairing",
      "groupPolicy": "pairing",
      "watchTodos": true,
      "startReaction": "🤔",
      "endReaction": "赞",
      "groups": {
        "*": { "requireMention": true }
      },
      "sessionScope": "chat_thread",
      "cwd": "/path/to/your/project"
    }
  }
}

インタラクティブな確認なしにツール呼び出しを実行する回答ボットには、YOLO 承認モードが利用可能です。

{
  "channels": {
    "dws-answers": {
      "type": "dws",
      "senderPolicy": "pairing",
      "groupPolicy": "pairing",
      "approvalMode": "yolo",
      "cwd": "/path/to/answer-bot"
    }
  }
}

YOLO モードはすべてのツール呼び出しを自動承認します。信頼されたボットアカウントとワークスペースでのみ使用してください。

新しく管理される DWS チャネルの senderPolicy と groupPolicy のデフォルトは pairing です。チャネルが返したコードを使用して、ユーザーまたはグループを承認します。

qwen channel pairing approve dws-work CODE

senderPolicy は、ダイレクトメッセージの送信者、ドキュメント通知の作成者、ネイティブ Todo の作成者、および open または allowlist グループ内の送信者を制御します。groupPolicy はグループ会話を制御します。承認されたペアリンググループは共有チャネルの動作に従い、そのメンバーを承認します。open と allowlist グループは senderPolicy も通過する必要があります。

groups はメンションの動作を制御します。具体的なグループ ID は "*" をオーバーライドします。requireMention: true の場合、@ メッセージのみがチャネルを起動します。requireMention: false の場合、グループと送信者のポリシーを通過した後に通常メッセージも受信されます。

グループメンションはリアルタイムの個人イベントストリームを最初に使用します。チャネルは 5 秒ごとに最近の @ メッセージ履歴もチェックするため、DingTalk が個人イベントストリームからメンションを省略した場合でも、外部グループからのメンションが回復されます。メッセージは両方のパスで会話とメッセージ ID によって重複排除されます。

通常のダイレクトメッセージも同じ方法で回復されます。5 秒ごとの履歴チェックにより、リアルタイムストリームが省略したダイレクトメッセージが再度処理され、両方のパスで会話とメッセージ ID によって重複排除されます。

メッセージが別の DingTalk メッセージを引用している場合、引用テキストはリアルタイムパスと履歴フォールバックパスの両方でエージェントへの返信コンテキストとして含まれます。

startReaction は、受け入れられたタスクの実行中に追加される絵文字文字または DingTalk リアクション名です。省略または空の値の場合はデフォルトの 🤔 が使用されます。endReaction は、タスクの完了、失敗、またはキャンセル後にそれを置き換えます。省略または空の値の場合は終了リアクションが無効になります。

IM 返信配信

完了したグループ @ またはダイレクトメッセージの返信は、最初の送信前にチェックポイントされ、タスクを再実行せずにバックグラウンドで再試行されます。バックオフは 5 秒から始まり、倍増し、5 分間で上限に達します。返信は 16 回の配信試行失敗後に放棄されます。チャネルの切断やペアリング承認の読み取り不能によって引き起こされたローカルな延期は、32 回の連続チェックという別の制限を使用するため、トランスポート試行予算を消費しません。返信は、送信者、グループ、またはダイレクトメッセージの認可が明確に取り消された場合、直ちに削除されます。キューは最大 100 件の返信を保持し、満杯の場合は試行回数に関係なく最も古いエントリを削除します。設定された DWS プロファイルを切り替えると、キューがクリアされます。これらの削除はチャネルの stderr で報告され、チャット通知としては送信されません。

12,000 コードポイントを超えるキューイングされた IM 返信は切り詰められ、受信者に表示されるメッセージに [Response truncated for DWS delivery.] が追加されます。ドキュメントコメントおよびネイティブ Todo コメントの返信は、このキュー再試行または切り詰めパスを使用しません。各ターンで 1 回のコメント送信呼び出しを行い、不明な結果は飲み込まれ、決定的な失敗は既存の受信ターン再試行ポリシーに伝播します。終了リアクションはタスクの完了を示し、返信配信を示すものではないため、再試行された IM 返信はそのリアクションが表示された後に到着する可能性があります。

ドキュメントメンション

ドキュメントやナレッジベースのウォッチリストはありません。ドキュメントタスクを開始するには：

  1. 認証されたアカウントを @メンションする DingTalk ドキュメントコメントを追加します。
  2. そのアカウントに DingTalk 通知を送信するオプションを有効にします。
  3. DWS はそのアカウントのダイレクトメッセージ履歴を通じて通知カードを配信します。

チャネルはその通知からドキュメント ID、コメントキー、およびリクエストを抽出します。参照されているドキュメントを読んでコンテキストとし、タスクの実行中に設定された開始リアクションを追加し、元のドキュメントコメントに返信します。リアルタイムの DWS イベントストリームがカードを含んでいる場合に使用され、5 秒ごとの増分履歴チェックは現在のイベントストリームで省略されたカードをカバーします。

通知を生成しないコメントは設計上無視されます。同じドキュメントコメントに対する重複した通知メッセージは 1 回のみ実行されます。ドキュメントタスクは senderPolicy に従い、approvalMode は default、plan、または yolo をサポートします。省略時は default が使用されます。

ネイティブ Todo の変更

watchTodos: true を設定すると、選択された DWS プロファイルの保留中のネイティブ Todo で、アカウントが実行者であるものをポーリングします。このオプションのデフォルトは false で、DWS チャネルを追加しても既存の Todo が暗黙的に実行されることはありません。

初回の成功したスキャンでベースラインが確立され、過去の Todo は開始されません。以降のスキャンは、Todo が新規に割り当てられた場合、再開された場合、またはタイトル、優先度、期限、担当者など実行可能なフィールドが変更された場合にタスクを実行します。最終応答は発信元の Todo にコメントとして追加されます。コメントのみのメタデータと変更タイムスタンプは変更検出から除外されるため、チャネル自身の応答がループをトリガーすることはありません。完了または削除すると Todo は保留セットから削除されます。再開すると新しいトリガーが作成されます。

ネイティブ Todo は Todo 作成者の ID を使用して senderPolicy に従います。pairing の下では、チャネルは 1 つのペアリングコードコメントを追加し、Todo を保留状態にします。作成者がローカルで承認された後、後続のポーリングで未変更の Todo を処理できます。ポーリングは 30 秒ごとに実行され、固定プロファイルの現在の組織にスコープされたままです。

起動と検証

チャネルを直接実行します。

qwen channel start dws-work

またはデーモンに管理させます。

qwen serve --workspace /path/to/your/project --channel dws-work

チャネルサービスのリースを共有するため、両方の形式を同時に実行しないでください。

ローカル検証では、別のアカウントからダイレクトメッセージを送信し、必要に応じてペアリングを承認し、タスク実行中に設定された開始リアクションが表示されることを確認します。設定された終了リアクションがある場合は、その後それが開始リアクションを置き換えることを確認します。次に、@メンション通知を有効にしてドキュメントコメントを追加します。チャネルは通知メッセージにリアクションし、ドキュメントを読み、最終回答を元のコメントの下に投稿します。通知が無効なコメントではタスクは発生しません。

チャネルは、DWS が認証されたアカウントとして識別する送信者 ID からのイベントを無視し、メッセージテキストから ID を推論することなく、返信ループとペアリングループを防ぎます。IM ソースの起動には、この信頼できる自己 ID が必要です。認証されたアカウントが openDingTalkId を公開しておらず、同じプロファイルの以前のセッションが 1 つも記録されていない場合、チャネルは接続を拒否します。一時的に ID を失う再接続でも、以前に記録された自己送信者 ID でのフィルタリングを継続します。

Last updated on
QQ BotGitHub