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承認代理工作流在企業環境中仍然罕見。“少數客户絕對處於前沿,但許多其他客户現在正試圖弄清楚,”他説。

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