問題不在AI Agent——現有系統和API並非為AI設計

在企業環境中，AI Agent面臨的最大挑戰之一是如何與大量遺留API互動。這些API通常以工程師十多年前的命名習慣命名，名稱如getProcInfo3，描述常常為空或僅寫著“見文件”。這樣的API對於大型語言模型（LLM）來說幾乎不可讀。MCP Bridge為解決這一問題推出了兩個關鍵元件：混合搜尋最佳化和AI增強（AI Enrichment）。

混合搜尋機制

起初，團隊嘗試了純向量搜尋，將每個工具的名稱和描述嵌入並儲存在pgvector中。這在教科書式資料集上表現良好，但面對企業API時，相似嵌入但不同意圖的工具（如get_customer、get_customer_full、get_customer_with_orders）會導致失敗。隨後嘗試的全文搜尋（Postgres FTS）在精確匹配上更好，但無法理解Agent意圖與工具描述之間的詞彙差異。最終採用的混合方法：首先由Postgres FTS進行第一輪篩選（採用BM25風格排名），然後由pgvector在第一輪候選結果及更廣泛的語義池上進行第二輪搜尋，最後由一個小型重新排序器將兩個有序列表合併為一個分數。重新排序器還會考慮Agent的近期上下文——如果Agent正在處理客戶資料，那麼與客戶相關的工具排名更高。

真正的難題：資料本身

然而，即使搜尋機制設計精良，源資料的質量決定了最終效果。以getProcInfo3(custId, opt) → object為例，簽名幾乎沒有資訊量，而返回的JSON響應卻包含了豐富的訊號：custId、billingAddress、accountStatus、primaryContact、assignedManager。正是響應形狀揭示了工具的實際功能——客戶賬戶查詢。

團隊考慮過要求客戶重新命名API，但這在小範圍內可行，對於擁有70個遺留服務的客戶而言則不可能。因此，他們構建了AI增強（AI Enrichment）。

AI增強的工作原理

MCP Bridge可以被指向任何相容OpenAI的聊天補全端點（內部使用Azure OpenAI，也支援Anthropic和本地Llama）。啟用增強後，平臺會為每個工具收集：名稱、描述（常為空）、引數模式、響應型別定義（來自OpenAPI、WSDL或.proto），以及對於不透明API，透過探測或生產流量捕獲的響應樣本。然後傳送一個結構化提示，要求模型生成更清晰的名稱、1–2句描述工具用途，以及3–5個標籤或別名。輸出會經過驗證（無幻覺引數，輸入輸出型別無語義漂移）。增強後的後設資料與原始模式共同儲存，工具呼叫仍使用原始名稱和模式，只有發現層使用增強版本。

關鍵的訊號是響應形狀。僅憑名稱和描述，模型無法區分getProcInfo3和getProcInfo4；一旦看到響應（或樣本），功能就變得清晰。對於SOAP服務，WSDL通常提供響應型別；對於無文件API，MCP Bridge可以一次性探測或從追蹤中提取。

重要的一點：增強是按服務選擇性開啟的，原始模式被保留，Agent永遠不會看到重新命名的引數。這樣避免了與源API的無聲偏離。

效果與工程細節

在一個真實客戶（匿名）的SOAP服務上，原始getProcInfo3被增強為get_customer_account_details，描述為：“獲取客戶賬戶資訊，包括賬單地址、賬戶狀態、主要聯絡人和指定客戶經理。適用於支援、計費或銷售前的賬戶狀態驗證。”並帶有別名。

在該客戶的服務上，Agent任務套件中的工具選擇準確率從41%提升至89%。而REST服務因已有合理名稱，提升幅度較小（71%到88%）。

工程方面：嵌入向量在增強描述變更時重新生成，但保留原始嵌入，檢索時兩者加權組合（原始×0.3 + 增強×0.7）效果最佳。重新排序器是一個小型交叉編碼器，基於手工標註的數百個（意圖、工具、標籤）三元組訓練。成本控制：每晚僅對變更的服務重新增強，200個操作的服務完整增強約花費30美分。管理UI展示命中率指標，幫助識別哪些工具被頻繁發現，哪些被忽略，從而優先增強。

結語

MCP Bridge的下一步是響應後處理（Response Post-Processing），這將在未來發布。混合搜尋和AI增強的程式碼已在docs.mcp-bridge.ai上提供。