AI News HubLIVE
站內改寫2 分鐘閱讀

獨家:LucidLink釋出MCP伺服器,讓AI代理共享訪問分散式檔案

LucidLink推出基於Model Context Protocol的伺服器Beta版,使其分散式檔案系統能夠被AI代理訪問,支援跨雲、本地和邊緣環境。該伺服器解決了多代理系統中資料移動和狀態持久化的問題,允許代理、應用和人類從同一檔案工作,無需重複複製資料。

來源SiliconANGLE AI作者: Paul Gillin

LucidLink Corp.,一家基於物件儲存技術構建雲網路附加儲存系統的公司,今天將其分散式檔案系統技術擴充套件到了人工智慧代理領域,釋出了Model Context Protocol(MCP)伺服器的公開測試版。該伺服器允許AI代理跨雲、本地系統和邊緣環境訪問共享檔案。

LucidLink表示,其MCP伺服器可連線任何MCP相容的代理或編排器到LucidLink檔案空間。目標是賦予多代理系統一個持久、可寫的共享狀態層,使代理、應用程式和人類能夠從同一檔案工作,而無需重複複製或行動數據。

公司指出,資料移動問題正變得日益緊迫,因為企業正從單代理演示轉向涉及多個代理和人工稽核的生產工作流。在這些場景中,問題已不僅僅是連線代理到工具或資料來源,而是跨會話、節點和框架保留上下文、輸出和工作狀態。

“過去10年,我們一直在為需要協作處理共享資產的團隊解決分散式資料挑戰,”聯合創始人兼執行長Peter Thompson說。但隨著公司看到客戶開始將代理連線到與分散式人類團隊相同的系統,他們需要“共享、持久的上下文”,而這些檔案通常位於代理執行位置以外的地方。

MCP伺服器旨在透過該協議(正成為代理間通訊的事實標準)暴露LucidLink現有的分散式流檔案系統。該伺服器可與Anthropic的Claude、OpenAI的Agents SDK、開源LangChain、LlamaIndex和CrewAI框架以及其他MCP相容框架配合使用。

Thompson表示,代理的底層訪問模式與人類使用檔案的方式沒有根本區別。不同之處在於,代理工作流依賴檔案作為記憶體、上下文和輸出。“對於處理特定任務的代理,其輸出成為一個markdown檔案,需要作為另一個代理的上下文,”他說。

這在工作負載跨越多個位置或基礎設施環境時會產生永續性問題。資料可能位於本地、多個雲或邊緣。將其移入單獨的AI平臺可能會帶來延遲、治理和合規性問題,尤其是對於受監管行業的公司。

“這些大型企業面臨的最大問題是資料存在於多個地方,”Thompson說。“去查詢、移動、整合資料,然後以非共享的方式提供訪問,會打破工作流。”

針對大檔案最佳化

LucidLink的技術最初是為媒體制作、工程和其他資料密集型環境中處理大檔案的分散式團隊開發的。該平臺包括塊級流式傳輸、全域性檔案鎖定和零知識AES-256加密。公司表示擁有超過6,000名客戶,管理超過95 PB的資料。

這些能力現在被定位為代理AI的基礎設施。全域性檔案鎖定可防止多個代理寫入共享檔案時發生衝突。零知識加密意味著LucidLink或任何雲提供商都不持有客戶加密金鑰。公司還表示,同一名稱空間可跨三大超大規模雲、本地和隔離環境工作。

LucidLink並未將MCP伺服器定位為向量資料庫、資料湖或Apache Iceberg等分散式表格式的替代品。Thompson表示,向量資料庫處理檢索,而他的公司專注於基於檔案的寫入路徑,該路徑保留輸出並使其可供工作流中的下一個代理使用。

“檔案就是上下文,”他說。例如,一個代理可能從影片檔案建立轉錄,而另一個代理則同時使用轉錄和原始影片作為後續步驟的上下文。如果檔案位於共享的LucidLink檔案空間中,下一個代理可以在許可權允許的情況下立即訪問它們。

Thompson承認代理工作流在企業環境中仍然罕見。“少數客戶絕對處於前沿,但許多其他客戶現在正試圖弄清楚,”他說。

儘管如此,他說狀態管理已成為實際障礙。“如果他們處理不好,就得不到預期的輸出,”他說。“他們還發現,要使一切工作正常,存在大量額外開銷。”