一條被開發者踩出來的路：OpenClaw“涌進”飛書

作者 | 文朋

這幾周里，只要在 AI 開發者社區多待一會兒，幾乎都很難躲開撲面而來的“龍蝦”熱度。

而一旦準備部署這只“龍蝦”，一個繞不開的問題就會冒出來：到底把它落在哪個平臺最合適？

在中文社區里，一個明顯的趨勢是，越來越多開發者開始把它接入飛書。

OpenClaw 官方文檔已將飛書納入內置消息渠道之列，社區也迅速長出了一整套配套資源：專門的飛書接入倉庫、遷移指南以及排障文檔等。

從教程產出頻率到討論熱度來看，飛書已經成為 OpenClaw 在中文語境下落地最清晰、也最成體系的去處之一。

這股 OpenClaw 對接飛書的熱度背后，是飛書接口生態的開放性，以及官方近乎“追著需求跑”的更新節奏。

就在昨天，飛書還進一步發布了基于最新 OpenClaw 插件打造的合作生態，正式把更多主流模型和云服務廠商接入進來。

可以說，飛書的這波更新，是在把原本只屬于少數極客的技術，推向官方化、產品化，并具備可規模復制的能力。

開發者先實踐，再官方化

事實上，這波“飛書熱”，并不是飛書官方點起來的。

早在 2026 年 1 月 26 日，就有開發者在 OpenClaw 官方倉庫提出“請增加飛書和微信支持”。當時的理由很簡單：國內公司的日常協作，本來就大量發生在這些工具里。

隨后，圍繞“怎么把 OpenClaw 接進飛書”的腳本、教程、排障帖，以及權限配置經驗，開始密集出現。OpenClaw 官方文檔也把飛書列為綁定渠道之一。

在開發者社區的“野生力量”里，OpenClaw 中文社區創辦人楊明鋒是很有代表性的一個。

根據媒體報道，他判斷在國內環境里，飛書可能是最快、也是最合適接入 OpenClaw 的平臺。在發現 OpenClaw 對中文用戶不夠友好后，先做了漢化，再補齊飛書擴展，讓用戶可以直接接入飛書；報道還提到，這部分代碼后來被 OpenClaw 官方團隊采納。

GitHub 上的 OpenClaw-feishu 目前仍有約 598 個 star、47 個 issue、52 次提交。README 里明確把自己定義為“早期開發的社區飛書插件”，并說明如今飛書接入已經演化出三條路徑：飛書官方插件、OpenClaw 內置飛書插件，以及這個更早期的社區方案。

可以說，飛書并不是主動對接 OpenClaw，而是先被開發者用代碼、文檔和實踐，一點點抬進了生態中心。

當然，除了社區推動，飛書本身也確實具備更適合 Agent 生長的土壤。在一批更愿意嘗鮮、也更重視效率工具的企業里，飛書已建立起相當深的用戶基礎。

這意味著，當 OpenClaw 需要在中文世界尋找一個默認落地場景時，飛書背后并不缺愿意擁抱新技術的用戶群。

例如獵豹移動傅盛的實踐。按照他的公開復盤，在春節 14 天里，他幾乎只靠在飛書上與 OpenClaw 對話，就把一只“龍蝦”養成了一個擁有 8 個 Agent、40 多個 Skill 的團隊，而且很多時候根本不需要再回到電腦前操作。

李志飛那次“兩天做一個 AI 原生版飛書”的實驗，則從另一個側面印證了這件事：他之所以會去做那樣一個原型，恰恰是因為他判斷，未來當大量執行者變成 Agent，協作平臺的底層邏輯也會被重寫。開發者會天然去尋找一個最容易讓 Agent 接手真實工作流的平臺，而飛書剛好最接近這種形態。

飛書這邊，直到開發者們把飛書做成高頻入口后，才開始迅速把這條路徑“官方化”。

不過，飛書下場后，并不只是做一些插件，而是把整條鏈路一起補齊。例如飛書開放平臺基礎免費版企業自建應用 API 調用總量被限時提升到 100 萬次 / 月；3 月 9 日，飛書又正式推出妙搭一鍵部署 OpenClaw，省去了開發平臺配置流程，并且自帶飛書官方插件。

目前，飛書開源的官方 OpenClaw 插件，已經與火山引擎、階躍星辰、Kimi、扣子、MiniMax、智譜等主流模型與云服務廠商完成對接。從火山引擎和智譜的公開教程看，“接入飛書”已經被做成標準化、甚至一鍵化流程。

最在乎的是，
“便捷與實用”體驗

對開發者來說，真正有吸引力的，從來不是某個平臺某一項能力有多強，而是它能不能滿足兩件事：一是足夠開放、省事，二是功能邊界足夠大，足夠有想象力。

過去，Agent 接入平臺的流程都很繁雜。從創建應用，配置，公網 IP 或內網穿透，到隨后處理鑒權、權限、事件訂閱、證書等一整套問題。開發時往往是一邊翻文檔，一邊盯日志，哪里報錯就回去重改哪里。

OpenClaw 剛出來時，不少開發者就是按這套標準流程把它接進各種系統。結果是，模型跟業務邏輯還沒打磨，時間就被接入消耗掉了大半。

而飛書這次特別的地方，在于它給出了一條不同的路徑：讓接入更簡單、更統一，但能力邊界并沒有因此被壓縮。

飛書開放平臺已提供 2500+ 開放接口與事件，覆蓋消息、文檔、電子表格、多維表格、日歷、任務、審批等多個業務域；OpenClaw 的飛書官方插件，進一步把一批工作對象封裝成了直接調用的能力。

同時，OpenClaw 的飛書插件已在 GitHub 開源，開發者可以直接查看實現邏輯、提交優化或擴展功能。這種開放的方式也讓插件的演進更貼近真實使用場景。

官方插件頁面顯示，目前這些能力已經被細化到非常具體的操作層面：文檔創建與更新、多維表格中的管理，以及日程的增刪改查、任務與評論管理等，而且仍在不斷地迭代中。

在連接層，飛書也降了門檻。它的長連接模式，本質上是用 WebSocket 替代傳統 WebHook：開發者不再需要公網 IP 和域名，也不必額外折騰內網穿透。

同時，企業自建應用也無需經過飛書平臺審核，只要企業管理員審批通過，就可以在組織內部使用。對開發者來說，這意味著驗證一個 Agent 場景，不再是一場高成本的消耗。

除了接入部署快，還讓開發者心動的是，它能像“走進公司”的實習生一樣干活。

飛書的價值，恰恰在于它把工作上下文、權限體系和執行工具放進了同一個協作空間。官方插件頁面顯示，目前這些能力已經被細化到非常具體的操作層面：文檔創建與更新、多維表格中的管理，以及日程的增刪改查、任務與評論管理等。

從開發角度，這些原本分散在不同系統里的對象，被納入同一套開放體系，本身也能省掉很多工程煩惱。這樣一來，開發者就不必再為每一類對象單獨給 Agent 寫一套連接器，也不必在多個系統之間反復拼接流程。

這帶來的收益非常直觀：一方面，開發者少做了大量“同步數據”“搬運上下文”的體力活；另一方面，Agent 的運行終于可以建立在真實、連續的工作環境之上，而不只是用戶臨時粘貼過來的一小段文本。

Agent 能干，但也不能出事。對開發者來說，永遠都不愿意背安全的“鍋”。好在飛書把身份和權限做成了底層工程能力。通過 Access_Token 機制，平臺能夠明確“是誰在調用、以什么身份調用、訪問的是哪個租戶的數據”。

這讓飛書的 Agent 更像綁定了一個真實入職的員工賬號，在組織既有規則內行動。

開發的最終站——運維對于開發者來說，也是重頭戲。飛書并沒有把這些問題一股腦丟給開發者自己處理。

開發者不僅可以直接在飛書里與 Agent 對話做灰度測試，還可以借助插件提供的能力做基礎的“自我診斷”。出了問題，在群里發幾條命令，往往就能完成初步定位；再結合官方和社區提供的大量防踩坑教程，整個調試與運維鏈路會順暢很多。

從這個角度看，飛書這段時間，是在持續放大這條工程路徑本身的吸引力。它不僅讓開發者更容易接入，也讓他們變的更敢于試錯，更敢于放量。

這也就不難理解，為什么開發者會對它如此上頭，很難不被這種誘惑打動。

開發方向轉變，
飛書定位“升級”

沒有人能斷言 OpenClaw 會火多久。

但比單個項目熱度更確定的是，智能辦公的判斷標準已經發生變化：企業和員工越來越關心，Agent 如何真正接入業務、嵌入流程，并把任務做成閉環。

從這個角度看，OpenClaw 的爆火，其實是把一個更大的問題提前擺到了企業面前：當 Agent 真正進入組織，什么樣的平臺能接得住它？

飛書之所以在這輪浪潮中被重新評估，是因為它本就是少數能將消息、文檔、電子表格、多維表格、日歷、任務等工作對象，統一納入同一套賬號、組織與權限體系的平臺之一。

如果把 Agent 比作發動機，高質量的業務數據就是燃料。相比外部碎片化信息，可以說，飛書中沉淀的協作記錄和文檔，天然就是更整齊、連續的“企業級上下文”。

開發者看中飛書的一部分主要原因，也是因為它不是一個孤立的接口，而是一個自帶真實邏輯的工作現場。

吳恩達前不久提出“AgenticWorkflow”，正是這種務實主義的方向：與其追求一個無所不能的超級模型，不如讓由迭代、反思與協作構成的“智能體工作流”，去解決真實業務問題。

未來的公司，可能會演變為“少數核心決策者 + 大量 Agent 團隊”共同運轉的模式。這種變化與共識幾乎是全球性的。

會看飛書這次更新，很像是一次身份轉變的預告。它不再只是接入 Agent 的渠道，而是正向“入口級”智能平臺靠攏：既要承載運行，又要連接私有數據，還能把結果寫回工作流上。

工具也許會不斷更替，但智能辦公的深水區已經到來。而飛書正在做的，就是朝著“Agent 基礎設施”的方向繼續邁進。