Slackをプロジェクトに接続すると、スレッド内のメッセージでセッションが始まります。エージェントは専用のクラウドコンピューターを起動して作業し、同じスレッドで回答します。依頼のために新しいツールを開く必要はありません。
mainに対して変更リクエストを作成しますか？
launch-note.md · +64 −0
A channel is a chat platform bound to a project — a closed set of three, not an open field. Here is the real state of each one, including the parts a marketing page usually leaves out.
フラグなしでデフォルト有効。ダッシュボードまたはCLIから接続し、ボットをチャンネルに招待してメンションします。このページのその他の説明はすべてSlackについてです。
すべてのプロジェクトで有効で、フラグは不要です。テナント管理者が一度同意するか、プロジェクトが独自のボットアプリを使います。セッションもIDのルールもSlackと同じです。
プロジェクトの受信トレイです。アドレス宛のメッセージでセッションが始まり、返信で継続します。Customize → Feature flagsからプロジェクトごとにオプトインできます。実際に動作しますが、まだ完成版ではありません。
Telegram、WhatsApp、SMS、Discordはチャンネルではありません。実現を約束できないロードマップに載っているような印象も与えません。また、独自チャンネルを構築するAPIもありません。プラットフォームの一覧は固定のenumです。その代わりに署名付きwebhookトリガーがあります。「拡張可能」という言葉を売り込むより、その制限を正直にお伝えします。
正直な代替案 →スレッドの最初のメッセージでセッションが作成されます。その後のメッセージはすべて同じセッションに届きます。サンドボックスが夜間に停止した後も、開始した人が退勤した後も同じです。この対応関係は、2つのサービスが守ると合意した慣例ではなく、データベースの一意インデックスです。
mainに対して変更リクエストを作成しますか？
launch-note.md · +64 −0
招待済みのチャンネル、またはダイレクトメッセージで行います。タスクのない単独のメンションには、誰も求めていないセッションを作る代わりに、タスクの追加を促すリマインダーが返ります。
Kortixはブランチを分岐し、専用の分離されたクラウドコンピューターを起動します。ダッシュボードやCLIから開始したセッションとまったく同じです。ボットが「対応中」と投稿するのではなく、自分のメッセージにリアクションが付きます。
シェル、ファイルシステム、ネットワーク、そしてエージェントブロックで許可されたコネクターとシークレットを利用できます。状況を確認する場所はスレッド、作業が行われる場所はマシンです。
返信は、質問されたスレッド内で、開始元のメッセージに続けて表示されます。2人で確認できます。どちらも何かを開く必要はありません。
まったく新しい同じスレッドに同時に届いた2つのイベントが、2つのセッションを作ることはありません。2つ目は1つ目に参加し、フォローアップとして配信されます。1つのSlackワークスペースが複数のプロジェクトに紐づいている場合、最初のメンションで推測せず、プロジェクト選択画面を表示します。
共有 Slack アプリが設定されたホストでは、kortix channels connect がインストールリンクを表示します。あとは3クリックで完了です。共有アプリのないデプロイでは、同じコマンドが自動的に手動モードへ切り替わり、貼り付けるだけのアプリマニフェストを渡します。
# 管理環境：インストールリンクを開き、ワークスペースを選択$ kortix channels connect --wait→ 接続済み：slack ワークスペース acme-hq # セルフホスティングの場合も、同じコマンドが手動モードに切り替わる$ kortix channels manifest > slack-app.json$ kortix channels connect --manual \--bot-token xoxb-... --signing-secret ... # 確認、または接続解除$ kortix channels status$ kortix channels disconnect質問した場所に答えが届いてこそ、チャンネルを接続する価値があります。ファイルは双方向にやり取りでき、エージェントがあなたに求める判断は、別の場所へのリンクではなくスレッド内のボタンになります。
返信は更新されていく1つのメッセージとしてスレッドに表示され、更新メッセージが大量に並ぶことはありません。エージェントはそのメッセージを確定し、下に別のメッセージを投稿しません。
スレッドにドロップしたファイルは、エージェントのクラウドコンピューターに取り込まれます。エージェントが作成したファイルは、同じスレッドにアップロードされます。資料は、指定した場所に届きます。
エージェントに判断が必要なときは、処理を永遠に止める代わりに、ボタン付きのカードを投稿します。クリックが判定となり、同じスレッドでそこからセッションが再開されます。
正直な制限も1つあります。カードには判断内容と Kortix へのリンクが含まれます。変更依頼の実際の diff を読むのは、diff があるべき Web アプリ上です。Slack はコードレビュー用のツールではなく、そうであるかのように扱うつもりもありません。
Slack では /kortix <command> として入力するか、ダイレクトメッセージでプレーンテキストとして入力します。通常ならダッシュボードを開く操作の多くが、チャンネル内の1行で完了します。
Slack のメッセージに、ダッシュボードのセッションにない権限が付与されることはありません。変わるのは画面だけで、その下にあるものは変わりません。
自分でチャンネルを構築するための API はありません。プラットフォーム一覧は固定 enum であり、空白をプラグインシステムのように見せるつもりもありません。提供されるのは、会話ごとにセッションを開始する署名付き webhook トリガーです。受信側は十分に解決しますが、できないことも正確にお伝えします。
# チャンネル固有のコードなしで、あらゆる会話ソースに対応triggers:- slug: support-inbox type: webhook agent: support secret_env: WEBHOOK_SECRET # メッセージごとではなく、会話ごとに1セッション session_mode: keyed session_key: "{{ body.data.conversation_id }}" # エージェント自身の送信メッセージを無視 filter: "body.data.direction": "inbound" prompt: "{{ body.data.text }}"会話ごとに1セッション。session_key はペイロードから展開されるため、1つのトリガーから、チャットごと、顧客ごと、リポジトリごとに個別のセッションを作成できます。混ざり合った議事録ではなく、分離されたスレッドになります。
会話の両側を報告するソースでは、エージェント自身の返信でもエージェントが起動してしまいます。filter はその配信を 200 で破棄し、セッションを作成しません。すべての Kortix webhook と同様、HMAC-SHA256 で署名されます。
返信の中継はありません。実際のチャンネルなら回答を返送しますが、ここではエージェント自身が、権限を付与したコネクターを通じて送信メッセージを送る必要があります。受信側は解決済みです。送信側はあなたの配線に委ねられます。