本文已收錄在Github，關注我，緊跟本系列專欄文章，咱們下篇再續！

• 🚀 魔都架構師 | 全網30W技術追隨者
• 🔧 大廠分佈式系統/數據中台實戰專家
• 🏆 主導交易系統百萬級流量調優 & 車聯網平台架構
• 🧠 AIGC應用開發先行者 | 區塊鏈落地實踐者
• 🌍 以技術驅動創新，我們的征途是改變世界！
• 👉 實戰乾貨：編程嚴選網

0 關鍵要點

• 隨着傳統關鍵詞搜索逐漸達到瓶頸，行業正轉向語義化、多模態、對話式和智能體（Agentic）AI 搜索。這種新型搜索能理解用户意圖與上下文，讓用户無需掌握技術或編寫應用，就能用自然語言獲取洞察。
• 基於 OpenSearch、LLM（大型語言模型）和 Model Context Protocol（MCP，模型上下文協議）構建的上下文感知型對話搜索解決方案，是下一代智能搜索的關鍵。MCP 負責在 AI 智能體與 OpenSearch 之間建立橋樑。
• AI 智能體是一類具備角色、任務與上下文管理能力的專用 AI 應用。典型的智能體系統包含 LLM（推理核心）、記憶模塊（維持上下文）、工具（擴展能力）和 RAG（檢索增強生成），可在交互中動態檢索相關信息。
• 所提架構由三層組成：智能體層（智能核心）、MCP 協議層（MCP 客户端與服務器通信）、數據層（索引、搜索與分析）。
• MCP 服務器支持多種部署方式，包括本地、遠程、混合（本地+雲）以及雲原生部署。不同模式可根據企業需求平衡安全、成本與性能。

1 引言

想象一位銷售主管用自然語言問系統：“請顯示本季度收入最高的十款產品，並預測下個月的銷售趨勢。” 系統能在幾秒內給出完整洞察，而不必等 BI 團隊數天出報告。

又或者你問：“為什麼我的應用延遲很高？” 系統不僅會返回日誌與指標，還會自動分析錯誤原因、性能瓶頸及最近的部署關聯。

這就是“下一代智能體搜索”的體驗。藉助 LLM 驅動的 AI 智能體，通過標準化協議（如 MCP）與數據系統交互，實現真正的對話式、上下文感知搜索。

本文將介紹 MCP 如何連接 AI 智能體與 OpenSearch 構建智能搜索系統；並回顧搜索技術的演進、架構組成及實際實現案例。

2 OpenSearch 與行業應用

OpenSearch 是一套開源搜索與分析系統，廣泛用於日誌分析、實時應用監控和網站搜索。截至目前，下載量近 9 億次，並有數千名貢獻者和 14 家核心成員，包括 AWS、SAP、Oracle 等。根據 DB-Engines 排名，OpenSearch 已躋身全球前五大搜索引擎。

從電商搜索到可觀測性平台，OpenSearch 在多個行業支持關鍵字、語義和日誌分析場景。下面看看搜索技術是如何一步步演進的。

3 搜索的演進：從關鍵詞到智能體

搜索技術演進：

3.1 關鍵詞搜索

又稱“詞法搜索”，是最傳統的搜索方式，即通過精確的詞或短語匹配。OpenSearch 默認使用 TF-IDF 或 Okapi BM25F 算法（即 Lucene 索引）。這種方法快速、確定且與語言無關，但忽略了用户意圖和上下文。

例如，搜索“男士黑色夾克”可能會返回包含“穿黑襯衫的男人”或“其他顏色夾克”的結果。

您可以在 Hugging Face 上的 OpenSearch AI 演示 中嘗試關鍵詞搜索，方法是選擇搜索類型為 "keyword search"。

3.2 語義搜索

語義搜索比關鍵詞搜索更智能，它在執行查詢時會考慮用户意圖與上下文。此方式將文本轉為向量嵌入（數值表示），形成 向量數據庫。OpenSearch 支持多種預訓練模型，可將文本、圖片、音頻、視頻等數據轉為向量。

在同樣的查詢下（如“男士黑色夾克”），語義搜索將僅返回真正相關的結果。

您可以在 Hugging Face 上的 OpenSearch AI 演示中嘗試關鍵詞搜索，方法是選擇搜索類型為 "vector search"。

3.3 多模態或混合搜索

多模態搜索結合關鍵詞與語義搜索結果，還能同時檢索文字與圖片等不同數據類型。用户可在同一結果中看到文本與圖片匹配的內容。

例如，在演示頁面，Hugging Face 上的 OpenSearch AI 演示，您可能會看到同時顯示關鍵詞和圖像的結果。&

3.4 對話式搜索

對話式搜索 允許用户用自然語言提問（如問答形式）。LLM 支撐這種交互，但需藉助記憶系統保存上下文：

• 可使用 ChatGPT、Claude 等 LLM 的會話內置記憶；
• 或使用外部數據庫（如 PostgreSQL、Redis、OpenSearch）or Agentic Frameworks (e.g., LangChain, Strands, LlamaIndex)保存長時記憶。

結合 RAG 技術，LLM 能連接外部數據源（如 OpenSearch），為查詢補充實時信息。

通常，用户明確説明需要搜索什麼，並從 OpenSearch 檢索數據。它最適合簡單到中等查詢和直接的信息檢索。

關鍵區別在於記憶（內置或外部）維護對話歷史以保持上下文連續性。同時，RAG 通過從外部數據源檢索相關信息來增強 LLM 響應，以提供更準確和最新的答案。

3.5 智能體搜索（Agentic Search）

智能體搜索 是對話式搜索的進化版。智能體具備記憶、推理、任務編排能力，可自主決定在 OpenSearch 上執行的步驟，如搜索、分析、關聯、執行等。

智能體可訪問多個數據源，通過 Model Context Protocol（MCP） 協調多種工具完成查詢任務。

OpenSearch 中的 智能體搜索 將幫助您用自然語言提問，如簡單英語。

智能體搜索是對話式搜索的超集。與對話式搜索不同，智能體將具有內置記憶能力，並使用 LLM 推理能力編排任務工作流，並在 OpenSearch 上做出查詢執行決策。這些任務包括搜索、分析、關聯和執行。智能體還將根據需要自主迭代工作流計劃。

智能體搜索可以通過編排多個工具來連接多個數據源，以進行信息檢索並增強響應。通過智能體搜索，用户可以保持對話完整，並通過 Model Context Protocol 在 OpenSearch 上執行 工具（又稱任務），這將在本文後續部分討論。

在深入探討下一代智能體搜索架構和實現細節之前，讓我們看看智能體如何在智能體 AI 應用架構中發揮關鍵作用。

4 什麼是 AI 智能體？

AI 智能體（專用 AI 應用）是配備了角色、任務和上下文管理能力的大型語言模型。一個典型的 AI 智能體集成了用於推理的 LLM、用於維持交互相關上下文的記憶、用於擴展能力的工具，以及用於選擇性知識檢索的 RAG，所有這些都旨在通過僅檢索相關信息並保留關鍵細節來高效管理 LLM 的有限上下文窗口。給定一個任務，智能體通過與可用工具的迭代推理來實現目標，同時動態管理進入上下文窗口的信息以優化響應生成。

Figure 2: AI 智能體的核心架構

讓我們回顧兩個流行的 OpenSearch 業務用例，以瞭解 OpenSearch 智能體搜索將如何幫助。

搜索用例：銷售分析師創建執行銷售報告銷售分析師（AI 智能體）負責為執行領導層創建每週銷售績效報告。AI 智能體利用分析管理器（LLM 編排器），它充當大腦並指導：分析什麼（按類別每週銷售、熱門產品、客户趨勢和營銷活動影響），在哪裏查找（銷售數據庫、庫存系統、營銷平台、客户分析），如何調查（生成查詢以聚合銷售數據、關聯活動並比較趨勢）一旦執行計劃準備就緒，AI 智能體通過 MCP 使用可用工具：銷售數據庫（Salesforce）查詢收入、訂單和產品績效電子商務平台（MySQL）API 檢索庫存水平和客户訂單詳情營銷平台（SAP ERP）API 審查活動績效並關聯銷售高峯AI 智能體還可能使用參考文檔（知識庫/RAG），例如：銷售報告模板和 KPI 定義數據庫模式和字段定義歷史銷售報告和季節性模式業務規則（例如，如何定義“活躍客户”）第 2 天，如果執行官（用户）需要參考第 1 天按類別的銷售摘要，AI 智能體會記住（記憶）第 1 天的發現，並繼續上下文感知的對話。

可觀測性用例：DevOps 工程師調查生產中斷DevOps 工程師（AI 智能體）負責調查和解決生產應用性能問題。AI 智能體利用事件管理器（LLM 編排器），它充當大腦並指導，調查什麼（慢查詢日誌、API 延遲指標、最近部署），在哪裏查找（應用可觀測性信息，如日誌、指標、跟蹤），如何調查（生成查詢以分析錯誤日誌與延遲指標和跟蹤，並將其與最近部署時間線關聯）一旦執行計劃準備就緒，AI 智能體通過 MCP 使用可用工具：OpenSearch 查詢應用日誌、指標和跟蹤GitHub API 審查最近代碼部署以進行關聯PagerDuty API（或其他）關聯相關警報AI 智能體還可能使用參考文檔（知識庫/RAG），例如：故障排除運行手冊系統架構設計文檔歷史事件和解決方案第 2 天，如果 DevOps 工程師（AI 智能體）需要參考第 1 天事件應用的補丁，AI 智能體會記住（記憶）第 1 天的發現，並繼續上下文感知的對話。

5 為什麼需要智能體？

LLM：昨日的大腦問題

大型語言模型功能模型（FMs）在大量語料庫上訓練，但沒有實時數據信息。因此，單獨使用 LLM 就像使用昨日的大腦。RAG 通過連接 LLM 到外部數據源（如 OpenSearch 或 RDBMS 等）來解決這個問題。

例如，如果 DevOps 工程師詢問實時應用性能指標或生產應用的洞察。LLM 單獨無法提供信息。LLM 需要使用現有數據存儲如 OpenSearch 來增強響應，提供實時洞察。

傳統 RAG 要求用户指定確切查詢，並從單一來源一步檢索。AI 智能體通過自主推理問題、通過 MCP 編排多個數據源（例如 OpenSearch、GitHub、CloudWatch）、關聯發現並迭代直到找到解決方案來增強 RAG。

會話記憶

LLM 單獨不存儲用户對話歷史。LLM 獨立處理每個提示，而不保留之前的交互。智能體可以通過各種記憶機制維護對話歷史，如短期和長期記憶。

因此，需要設置記憶與外部數據庫，並使用 RAG 技術保持對話。從 OpenSearch 3.3 開始，智能體記憶作為內置功能提供。現代 AI 智能體框架帶有內置記憶，無需維護單獨數據庫。

知識庫

LLM 沒有您公司的專有數據。您可以將公司數據作為知識庫提供給 LLM。LLM 使用此知識庫通過 RAG 技術增強其響應。

工具

每個智能體將有某些工具，通過利用 LLM 的推理和規劃能力來執行任務。例如，OpenSearch 提供了一套工具，執行搜索、分析、關聯和執行等任務。您也可以使用智能體框架實現自己的智能體工具。

6 開發 AI 智能體的挑戰

構建 AI 智能體是一項簡單任務，但將其與現有系統如數據庫和 Web 服務集成很複雜。每個用例都需要實現特定 API 或另一種與相應服務的集成方式。例如，數據庫使用 JDBC 連接，Web 服務使用 REST API 調用。

如前幾節所述，銷售助手智能體使用不同的連接器連接到不同數據源以執行全面分析。

Figure 3: 使用自定義連接器每個數據源的銷售助手智能體

MCP將幫助克服這種複雜性，提供單一和簡化的連接方式（通用方式）。

7 MCP：通用連接器

MCP 提供統一的 API 來連接不同服務，使 AI 智能體集成無縫。MCP 設置有兩個組件。

• Model Context Protocol：一個開源、標準化和安全的協議（基於 JSON-RPC 2.0），管理 MCP 客户端和 MCP 服務器之間的通信。想想它就像一個通用電源適配器或旅行電源適配器，您可以在不同國家的不同插座中使用它，適配器可以簡化輸入電源並提供所需的連接性和輸出。更多關於 MCP 的信息可以在這篇文章中找到。
• MCP Server：MCP Server 是一個特殊程序，作為 AI 模型和外部數據源之間的安全橋樑。它提供在相應服務上執行任務的工具。

Figure 4: 使用 MCP 的銷售助手智能體

8 OpenSearch 智能體搜索如何工作？

在本節中，我們選擇了本地部署模型來進行演示，以簡化設置。生產部署應使用託管混合或雲原生選項，以獲得更好的安全性和可擴展性。

Figure 5: OpenSearch 智能體搜索 – MCP 設置和流程

架構概述

• 智能體層 Claude Desktop 既充當對話界面（即智能體 AI 應用），又充當 MCP 客户端，可以下載到您的本地機器。如上圖所示，它通過互聯網與 Claude Sonnet 4.5 LLM 通信進行推理，並指示 MCP 從 OpenSearch 檢索信息。
• 協議層（MCP 客户端和服務器） MCP 客户端通過 'claude_desktop_config.json' 配置，將保存連接到 OpenSearch 的配置，並通過 MCP 協議啓動與 MCP 服務器的通信。MCP 服務器作為獨立服務運行，在 MCP 協議和 OpenSearch 之間架起橋樑。它將 OpenSearch 操作作為 MCP 工具公開，將協議消息轉換為 REST API 調用，並格式化結果以供 LLM 使用。
• 數據層 OpenSearch 存儲和索引數據，通過 MCP 服務器公開操作。

OpenSearch MCP 服務器設置

OpenSearch 從版本 3.0 或更高版本開始默認提供 MCP 服務器。您可以在本地機器上下載和安裝 OpenSearch MCP 服務器，或者也可以按照本文提供的實現指南進行操作。MCP 服務器在將 MCP 工具查詢轉換為 OpenSearch 原生 REST HTTP API 調用、提交翻譯後的查詢到 OpenSearch 並處理結果、將其格式化為 LLM 兼容響應方面發揮關鍵作用。

服務器還將 OpenSearch 操作（如搜索、分析等）作為 MCP 工具公開。默認情況下，它將提供在 OpenSearch 上執行任務的工具。可用的默認工具包括：

• ListIndexTool 列出 OpenSearch 中的所有索引，包括完整信息，如 docs.count、docs.deleted 和 store.size。
• IndexMappingTool 檢索 OpenSearch 中索引的索引映射和設置信息。
• SearchIndexTool 使用 OpenSearch 中的查詢領域特定語言 (DSL) 編寫的查詢搜索索引。
• GetShardsTool 檢索 OpenSearch 中分片的信息。
• ClusterHealthTool 返回集羣健康的基本信息。
• CountTool 返回匹配查詢的文檔數量。
• ExplainTool 返回特定文檔匹配（或不匹配）查詢的原因信息。
• MsearchTool 允許在一個請求中執行多個搜索操作。

9 MCP 服務器部署模式

通常，MCP 服務器安裝提供以下部署選項。

• 本地部署 MCP 服務器可以在個人工作站上與 Claude Desktop 一起運行。這種部署適合開發和測試。
• 遠程部署 外部服務提供商（例如 Salesforce、SAP 等）通過 MCP 服務器公開其系統，通常出於安全和治理原因。
• 託管混合（本地/雲）部署 組織在本地或雲環境中部署一個集中的“MCP Hub”。組織的 MCP Hub 將提供標準化、可擴展、受控的多數據源訪問。
• 雲原生部署 主要雲提供商如 AWS、GCP 和 Azure 提供自己的 MCP 服務。

請注意，您也可以根據需求實現自己的 MCP 服務器工具。

10 實現指南

本節演示如何配置 Claude Desktop 與 OpenSearch MCP 服務器以實現智能體搜索功能。我們將逐步指導安裝、配置，並使用兩個示例數據集（電商訂單和可觀測性數據）提供查詢示例。完整的源代碼和逐步設置説明可在 NextGenSearch-OpenSearch-MCP 獲取。

11 智能體搜索 – 用户和 MCP 交互流程

以下是用户和 MCP 交互步驟的高級流程，演示當用户發出查詢時，如何翻譯查詢，以及 MCP 如何從 OpenSearch 獲取並向用户呈現數據。

Figure 6: 用户和 MCP 交互流程

現在，讓我們看看整體架構如何實際運行。

12 演示：智能體搜索實戰

以下示例演示使用連接到 OpenSearch 的 Claude Desktop 進行 MCP 啓用的智能體搜索。

演示環境

對於此演示，我們使用 OpenSearch 作為安裝包提供的兩個默認數據集。請參考實現指南或 OpenSearch Dashboards 快速入門指南 獲取更多詳細信息。

• 示例電商訂單：用於客户行為分析的零售交易數據
• 示例可觀測性日誌、跟蹤和指標：用於系統監控查詢的日誌、跟蹤和指標

請注意，我們在本文/演示中使用簡單的英文數據。但您也可以為 OpenSearch 上的向量數據實現相同功能。

通用查詢：

讓我們看看使用此設置的一些通用自然語言查詢。首次使用時，您可能需要發出類似“使用 MCP 連接到我的 OpenSearch”的查詢，以便初始化 MCP 連接。

MCP 工具查詢：“List Tools”。

'List tools' 查詢將為您提供 MCP 配置下可用於 OpenSearch 的工具列表。

索引查詢：“List index or list indices of sales data and observability data”

這是一個 NLP 查詢，其中 LLM 理解我們的查詢上下文，並遍歷所有可用工具，選擇 ListIndexTool 作為列出 OpenSearch 中所有可用索引的適當工具。

集羣管理查詢：“Is the cluster healthy?”

這是一個平台運營查詢，用於檢查 OpenSearch 集羣健康。對於此查詢，LLM 使用 ClusterHealthTool 向用户提供響應。

Figure 7: MCP 通用查詢

現在，深入探討銷售數據上的分析洞察。

銷售分析師演示：商業洞察的對話式智能體搜索

銷售分析師：熱門產品類別查詢：

“Can you find the most popular category of products ordered last quarter?”

此查詢聚合並提供上季度產品訂單的最熱門類別結果。

銷售分析師 – AI 洞察查詢：

“Based on sales data, what is the interesting part to you?”

在此查詢中，我們利用純 AI 分析洞察銷售數據。

Figure 8: 銷售分析師 - 商業洞察查詢

銷售分析師 – 執行董事會 BI 查詢

“Can you create a graph based on sales data for the executive board?”

這是一個非常有用的場景，執行官無需依賴或等待他們的 BI 團隊提供銷售績效報告；相反，他們可以通過用簡單英語查詢來按需生成。

Figure 9: 銷售分析師 - 執行董事會 BI 查詢

注意：Claude Desktop 可以創建 React.js 代碼，可以轉換為儀表板。

Claude Desktop 還可以發佈公共儀表板。例如，這是上述儀表板的快速參考 above dashboard。

現在，讓我們看看 DevOps 角色以及他們如何利用整個 MCP 設置與 OpenSearch。

DevOps 演示：可觀測性數據的對話式洞察

DevOps 工程師花費大量時間通過在不同儀表板和工具之間切換以及使用自定義腳本來排查生產問題，增加平均檢測時間 (MTTD) 和平均恢復時間 (MTTR)。

此調查過程可能根據問題的複雜性持續數小時到數天。使用 OpenSearch 智能體搜索與 MCP，這些工作流程是對話式的。無需編寫完整的領域特定語言 (DSL) 查詢或在不同數據集和系統之間導航，工程師可以用簡單英語提出運營問題。

DevOps 工程師 – 應用性能調查查詢

“What's causing high latencies in my application?”

此查詢將掃描不同 OpenSearch 索引中可用的所有可觀測性數據，自動識別相關字段，並生成延遲問題的總結解釋。

DevOps 工程師 – 監控和可觀測性查詢

“Show me nodes with high CPU usage and their active tasks”

與延遲查詢相同，此查詢選擇正確的可觀測性字段，並返回高 CPU 節點的乾淨摘要”

Figure 10: DevOps 工程師 - 應用性能和可觀測性查詢

DevOps 工程師 - 可觀測性 - 關聯分析查詢

“Give me CPU-to-Latency Correlation insights dashboard”

如下面演示截圖所示，無需在兩個屏幕或儀表板之間切換或手動關聯。CPU 和延遲指標都被關聯，智能搜索提供關聯分析洞察的全面視圖。

Figure 11: DevOps 工程師 - CPU 到延遲關聯查詢和儀表板

有關上述關聯的快速參考，請參見 analysis published dashboard。

DevOps 工程師 – 可觀測性 – 異常檢測查詢

“Can you detect any anomalies in this observability data and create a dashboard?”

傳統可觀測性平台需要在您的數據上設置和訓練異常檢測模型，而 LLM 可以自動理解您的可觀測性信號，並使用簡單英語查詢識別異常。

Figure 12: DevOps 工程師 - 異常檢測查詢和儀表板

[點擊此處 展開上方圖像至全尺寸]

有關上述的快速參考，請參見 anomaly detection published dashboard。

13 結論

從關鍵詞搜索到智能體搜索的演進代表了組織與數據交互方式的根本轉變。雖然語義搜索理解用户查詢的意圖和上下文，但通過 MCP 和大型語言模型與 OpenSearch 的結合，我們正步入一個新的時代，在這個時代，搜索感覺更像是一場對話而不是查詢。

MCP 標準化協議消除了集成複雜性，使 AI 智能體能夠連接到不同數據源、思考上下文，甚至基於推理對發現的內容採取行動。隨着 AI 的持續演進，像 MCP 這樣的標準化協議與強大搜索引擎如 OpenSearch 的結合，將使智能、上下文感知的數據訪問對每個組織都變得可及。