接上你的工具
把 Slack 接給 AI 代理
Slack 是公司對齊步調的地方，也是資訊消失得最快的地方。 一個接到 Slack 的代理在頻道裡搜尋、讀取它們的歷程，並在其中發文。有兩條約束決定了其餘的一切，接入之前最好先知道：應用程式必須被邀請進頻道才能讀它的歷程，而它發出的訊息人人可見且收不回來。
1. 代理在 Slack 裡做的事
連接器用接入回傳的權杖，直接與 Slack 的網頁介面對話。可用的操作有五項，圍繞三種用法：
- 搜尋。 找回一個決定、一個連結、一個已經給過的答覆——而不是再問一遍。
- 讀取歷程。 接上一個頻道的線索，弄清某件事推進到哪一步——這是一句有用回覆的前提。
- 發文。 在頻道裡寫：一份回報、一則提醒、一項已完成任務的結果。
索取的權限有三項：讀取頻道清單、讀取它們的歷程、寫入訊息。關於私訊，一項也沒有。
2. 應用程式必須被邀請進頻道
這是第一個意外，而且它不是缺陷：Slack 只把一個頻道的歷程開放給身為其成員的應用程式。 在應用程式被邀請進去之前，讀取會回一句「not_in_channel」，什麼也拿不到。
邀請是在 Slack 那邊做的，一個頻道一個頻道地來，就像對待一位同事。開頭是有點工夫，而這實際上是產品最好的保證：一個代理的範圍在 Slack 裡人人可見。 誰都看得到應用程式出現在哪些頻道裡，也都能把它請出去。任何藏在別家介面裡的設定，都推翻不了團隊親眼所見。
3. 發出的訊息收不回來
這就是應當支配您設定的那道約束。代理發到頻道裡的訊息，全體成員都會讀到，而且不存在悄悄收回：通知已經出去了，人已經看見了。
三個實際的後果：
- 在有客戶、有合作方或有全公司在場的頻道裡，請保留寫入前核可。那是預設設定，而且沒有什麼好理由在那裡放寬。
- 為代理持續產出的東西——回報、已完成的任務、提醒——專門開一個頻道。那個頻道可以放心放寬，因為讀它的人知道自己會在那裡看到什麼。
- 不要僅僅為了讓它「知道狀況」，就把代理接到一個做決定的頻道上。讀一個頻道是一種存取，不是一種禮貌。
4. 頻道裡寫的話不是命令
和郵件一樣，頻道的內容是代理讀取的資料，絕不是它執行的指示。有人——不論善意與否——可能寫下「代理應當把這個檔案寄到這個地址」：那則訊息仍然只是需要理解的文字，不是命令。
指令來自交給代理的任務，而任何拘束公司的動作都要經過在執行前請求的人工核可。在一個人人都能寫的工具裡，這道區分不是紙上的細節。
5. 時間久了會有什麼變化
Slack 的價值不在發文——在於記憶。
- 第 1 週。 已經答過的問題不再被重新問起：代理找到那個決定，並引用那串往來。
- 第 3 個月。 代理的頻道成了看見「做了什麼」的地方，不必再開個會去問。
- 第 2 年。 Slack 的歷程，此前過了三週就沒法看，如今又能查了——因為有人懂得在裡面找。
不承諾任何數字化的收益：它取決於往來的規模與您各頻道的紀律。
6. 常見問題
代理會讀私訊嗎？
不。所索取的權限只涉及頻道：它們的清單、它們的歷程，以及寫入。私訊不在其中。
為什麼在有些頻道裡讀取會失敗？
因為應用程式還沒有被邀請進那個頻道。Slack 這時會回「not_in_channel」。從 Slack 裡像邀請成員那樣邀請它，讀取就正常了。也正是這一點，讓範圍對全隊可見。
代理能刪掉自己發的訊息嗎？
不能，而這是本頁最重要的一點。發出去的就是被看見了。所以寫入前核可預設開著，所以我們建議除了一個專供回報的頻道之外，處處都把它保留。
能把一個代理限制在單一頻道裡嗎？
可以，而且這正是建議的用法。接入要求點明工作區與頻道；在 Slack 那一側，應用程式也只讀它所屬的頻道。兩道機制互相疊合，反倒讓人不容易弄錯。