Claude Artifacts 能讀即時 MCP 資料,但不能公開分享連結——這條互斥規則,任何方案都一樣

如果我的 artifact 一開始沒有連接器、有公開連結,後來才加上連接器功能,原本的公開連結會發生什麼事?

根據這條限制的邏輯,一旦這個 artifact 被改成會呼叫連接器,它就不再符合「可以有公開連結」的條件——這代表你沒辦法讓同一個 artifact 同時保留原本的公開連結、又加上即時抓資料的能力。實際會發生的情況,通常是系統會要求你在「保留公開連結、不呼叫連接器」跟「呼叫連接器、放棄公開連結」之間二選一,而不是讓兩者同時生效之後,某個功能在背後悄悄失效。

比較保險的做法,是在動手加連接器功能之前,先想清楚這個 artifact 未來的分享對象是誰——如果你已經把連結發給了不特定的外部人士,之後才想加上即時資料功能,通常代表你得另外做一個新版本,而不是直接在原本那個已經公開分享出去的版本上加功能。

Team 或 Enterprise 方案裡,組織內部同事打開一個會呼叫連接器的 artifact,看到的資料真的會不一樣嗎?為什麼會這樣設計?

是的,會不一樣。因為連接器呼叫的資料,是透過「每個查看者自己」帳號連接的服務去讀取的——舉例來說,如果這個 artifact 是一個查詢資料庫的儀表板,你自己打開時看到的是你的帳號能存取到的資料表跟權限範圍,你的同事打開時看到的是他自己帳號能存取到的範圍,如果他的權限跟你不一樣,兩個人看到的數字很可能不一致,甚至如果某個查詢牽涉到對方權限不足的資料表,查詢本身就會失敗。

這樣設計的原因,是這個機制刻意不讓發布者的連接器權限被「借用」給其他查看者使用——如果換成用發布者自己的連接器去幫所有查看者抓資料,等於是發布者一個人的存取權限,被無限次轉發給任何打開這個 artifact 的人,這在資安上是明顯的風險。要求每個人用自己的連接器,雖然會讓體驗因人而異,但確保了每個人看到的資料,本來就是他原本就有權限看到的東西,沒有任何權限被跨帳號轉移。

如果我在 Pro 或 Max 方案上,真的需要跟外部客戶分享一個會即時抓資料的儀表板,目前有沒有變通做法?

目前這個限制沒有官方提供的直接繞過方式——在 Pro、Max 方案上,一個會呼叫連接器的 artifact 就是無法產生公開連結,這不是某個設定選項,而是架構本身的限制。比較實際的變通方向有兩個:第一,如果分享對象數量不多,可以考慮把即時查詢的結果定期匯出成靜態快照(例如每天固定時間重新產生一次),改用一般的靜態 artifact 搭配公開連結分享,犧牲即時性換取可分享性;第二,如果即時性是硬性需求,可能得考慮升級到 Team 或 Enterprise 方案,但這代表分享對象必須先加入你的組織,無法對完全外部、沒有帳號的人開放。

實務上也有第三方工具嘗試填補這個空缺(例如透過額外的 MCP 伺服器,把 artifact 內容發布成獨立的公開連結),但這類工具不是 Anthropic 官方提供的機制,使用前需要自己評估資料安全性與穩定性,不能假設它跟官方原生功能有一樣的保障。

這條「連接器跟公開連結互斥」的限制,是不是代表 artifact 裡的連接器功能本身還不夠成熟,之後可能會取消這個限制?

從目前這條限制背後的邏輯來看(公開連結要求免登入、連接器要求每個查看者用自己的身分讀取資料),這不太像是一個「功能還沒做完、以後會補上」的暫時性限制,而更像是這兩個功能本質上互相矛盾之下,刻意做出的設計選擇——除非未來出現某種新機制,能在「訪客不用登入」跟「資料要照訪客身分分別讀取」這兩個互相衝突的要求之間找到新的解法(例如訪客打開連結後,額外要求他們臨時登入自己的帳號來完成連接器授權),否則這條限制不太容易單純透過「功能成熟度提升」就自然消失。

比較實際的心態,是把這條限制當成目前架構下的既定規則來規劃工作流程,而不是預期它會在近期被拿掉——如果之後真的有新機制解決這個矛盾,通常會是一個新的、獨立的分享模式(例如「訪客登入後才能查看」的中間型態),而不是讓「完全公開、免登入」跟「即時連接器資料」這兩者直接畫上等號。