內建聯結器覆蓋的是大眾場景——郵箱、文件、知識庫這些。但真實工作裡，你可能有自研的業務系統、私有資料庫、特定物件儲存，這些官方不會預置。WorkBuddy 的解決方式是：自定義聯結器——按 MCP 協議配置任意 MCP 服務，訪問範圍完全由你決定。這一節我們把它開起來。
一、入口在哪#
自定義聯結器的入口比較低調，在聯結器管理頁的右上角：
- 開啟聯結器管理頁（或資料庫入口）
- 看右上角，有一個**"自定義聯結器"**按鈕
- 點選進入配置介面
和內建聯結器不同，自定義聯結器不提供"一鍵授權"的卡片，而是讓你自己填寫 MCP 服務的連線引數。這是因為它面向的是任意 MCP 服務，WorkBuddy 沒法替你預知每個服務的配置項。
二、按 MCP 協議配置#
自定義聯結器遵循的是 MCP（Model Context Protocol） 標準協議。只要你的目標服務實現了 MCP，理論上都能接進來。
基本配置項#
一個典型的 MCP 服務需要填這些：
| 配置項 | 說明 |
|---|---|
| 名稱 | 給這個聯結器起個名字，方便識別 |
| 服務地址 | MCP 服務的訪問地址（URL 或本地路徑） |
| 傳輸方式 | stdio / SSE / WebSocket 等，取決於服務實現 |
| 鑑權資訊 | API Key、Token 或其他憑證 |
| 啟動引數 | 部分服務需要命令列引數（如 stdio 模式） |
填完儲存後，WorkBuddy 會嘗試與該 MCP 服務建立連線，成功後聯結器即可使用。
三、核心原則：訪問範圍完全由使用者決定#
這是自定義聯結器最重要的一條原則——WorkBuddy 不預設邊界。
內建聯結器有明確的許可權邊界（比如騰訊文件只讀授權範圍內的文件），但自定義聯結器不同：
- 你配置的 MCP 服務能訪問什麼，AI 就能訪問什麼
- 邊界的設定責任在配置者，而非 WorkBuddy
換句話說，如果你接的是一個有完整資料庫讀寫許可權的服務，那 AI 就能對這個資料庫做讀寫。權力越大，配置越要謹慎。
四、典型適用場景#
自定義聯結器適合這些"內建聯結器夠不著"的場景：
| 場景 | 示例 |
|---|---|
| 自研業務系統 | 公司內部的 CRM、ERP、工單系統 |
| 私有資料庫 | MySQL、PostgreSQL 等，需查詢/分析 |
| 物件儲存 | 私有 OSS、MinIO，讀取檔案 |
| 特定 SaaS | 官方未預置的第三方工具 |
| 內部 API | 團隊封裝的業務介面 |
只要這些服務實現了 MCP（或你能用 MCP 閘道器把它們包裝成 MCP 服務），就能接進來。
五、配置注意事項#
自定義聯結器自由度高，但配置時這幾點要格外留心：
- 憑證安全：填入的 API Key、Token 會儲存在本地配置裡，請確保環境可信，避免明文洩露。
- 最小許可權原則：給 MCP 服務的憑證儘量收緊許可權，能只讀就別給寫。
- 先本地驗證：配置完先用一個無害的只讀指令測試（比如查詢），確認連線正常、返回符合預期，再放開復雜操作。
- 留意服務穩定性：自建 MCP 服務的可用性由你自己保證，斷線、超時會直接影響 AI 呼叫。
- 記錄配置來源：多個自定義聯結器時，建議記下每個的用途和服務地址，方便後續維護。
小結#
自定義聯結器是 WorkBuddy 的"萬能插口"：入口在管理頁右上角，按 MCP 協議配置任意服務，訪問範圍完全由你決定、WorkBuddy 不預設邊界。它適合接入自研業務系統、資料庫、物件儲存等官方沒預置的能力。配置時務必遵循最小許可權原則，先驗證再放開。至此，第 05 部分知識庫與聯結器就講完了，接下來我們進入第 06 部分。