在 Feishu 或 Lark 群組中 @ 你的 Claude Code

在 Feishu 群組中 @ coding agent，代表群組成員在 Feishu（海外版為 Lark）中發送訊息時，該訊息會傳遞至某人機器上運行的 Claude Code 或 Codex agent，執行過程與結果會回傳至同一個 thread 中，且任何危險操作都會先轉為卡片發送給機器主人進行審批。agent 不會移至雲端，憑證絕不離開電腦，群組成員也無需安裝任何軟體。

這篇文章介紹 muti 的 Feishu connector 設計架構：綁定、路由、審批與節流機制，以及在正式推出前你可以先做好的設定。該 connector 目前正在開發中；以下是其行為規格，而非現已上線的功能。中文原文請見 /zh-CN/blog/feishu-lark-claude-code。

為什麼選擇通訊軟體，而不是另一個用戶端

與你協作的人最不想要的，就是為了一次性使用你的 agent 還得特地註冊帳號並安裝用戶端。對於許多團隊而言，日常工作討論本來就在 Feishu 中進行。把 agent 帶到群組中，遠比把人拉到 agent 面前容易得多。

Feishu 也非常契合這項任務：長連線事件訂閱無需公網 callback URL、訊息卡片支援原地更新、thread 回覆能將單一任務的訊息集中在一起，且圖片也可以直接下載作為 agent 的輸入。

兩層綁定

群組 ↔ 房間。 房間是 muti 中的邊界：決定了誰能看到什麼、誰可以使用哪個 agent。將 Feishu 群組綁定至房間後，該房間的成員名單與授權便會套用至該群組。在房間設定中選擇「connect a Feishu group」，取得六位數代碼，並在群組中發送 @muti bind 123456。

個人 ↔ 帳號。 成員第一次提及機器人時，機器人會透過私訊發送一組時效性代碼；成員在 muti 中輸入後，身分即完成關聯。未綁定的成員預設會被忽略；房間也可以開啟訪客模式，允許他們提問但不能觸發執行。

綁定的核心在於：執行權限來自房間的授權與主人的審批，絕非取決於誰在群組裡說了什麼。 聊天訊息一律被視為不可信輸入。

一任務一 thread：受理、審批卡片、進度與結果全在同一處。

一個任務，一個 thread

成員發送 @muti @api rerun the failing tests and open a PR。機器人會在此訊息下方開啟一個 thread 並依序回覆：

1. 已受理，附帶如 R20260906-03 的請求 ID 及其狀態。
2. 審批狀態。如果該成員對此 agent 沒有常態授權，主人將收到一張僅自己可見的審批卡片。
3. 進度卡片，按階段或每 30 秒原地更新：變更的檔案、目前為止的測試進度、指令輸出的最後幾行。不會每一步驟都發送新訊息。
4. 結果：回覆內容加上 agent 產生的任何檔案、圖片或連結。

主頻道保持安靜；想了解細節的人點開 thread 查看即可。

審批卡片

當執行過程中遇到危險操作時，主人會收到一張卡片：發起人是誰、哪一個 agent、打算執行什麼操作、觸發了哪條規則。三個按鈕：approve / reject / run read-only，並可附帶與請求具同等權重的備註說明。

有四類操作無論範本為何皆會暫停：推送至共享分支、刪除、涉及費用支出、接觸憑證。受保護的輸入（如登入憑證與雙因素驗證碼）一律路由至主人，絕不會發給請求者。審批預設於 24 小時後過期。無論在 Feishu、網頁端或手機上做出決定，效果均全域生效。

群組看到的內容，以及絕不離開機器的資料

現在可以先做好的準備

• 將 agent 加入房間。 連接你的機器，為你打算共享的每個目錄各建立一個 agent，並以工作內容命名（如 api、site、notes），而非模型名稱。
• 先建房間，再建群組。 邀請日後會加入綁定群組的成員，並設定誰是唯讀、誰可以編輯。connector 會將群組 ↔ 此房間綁定，並復用這些規則。
• 使用 muti service install 將 daemon 安裝為系統服務，如此一來，即便筆記型電腦闔上螢幕，來自 Feishu 的任務也會處於等待狀態，而不是直接失敗。
• 寫下團隊風格規範。 STYLE.md、簡報範本、上週的報表 SQL：凡是 agent 應該參考的內容，都放進其工作目錄中。

常見問題

我們的 Feishu 管理員需要審批嗎？ muti 的雲端服務為所有使用者運行同一個 Feishu 應用程式；將其安裝至租戶（tenant）通常需要一次管理員同意。自我託管（Self-hosted）模式則允許主人使用自己的應用程式憑證。

支援 Lark（海外版）嗎？ Feishu 與 Lark 共用相同的開放平台；此 connector 同時支援兩者。

那麼 Slack 和釘釘（DingTalk）呢？ Slack connector 已經發布：每個 agent 一個機器人，可私訊或 @ 它，審批會在主人的私訊中進行。Feishu/Lark 是下一個；釘釘（Stream 模式）緊隨其後。三者共用相同的房間與授權機制。請參閱在 push 前主動確認的 Claude Code Slack 機器人。

如果群組裡有人不是 muti 使用者怎麼辦？ 預設會被忽略。房間可以開啟訪客模式：訪客可以提問，但絕不能觸發執行。

先為你的 agent 建立一個房間；群組隨後接入即可。從這裡開始。