解決代理型數據缺口：介紹 Airbyte Agents

為了讓 AI 代理從簡單的聊天介面轉向真實世界的業務工作流，它們需要訪問操作數據——即存儲在 Slack、Salesforce、Linear 和 Zendesk 中的那種數據。然而，提供這種訪問權限很少像插入一個 API 那麼簡單。

大多數目前的實作依賴於 Model Context Protocol (MCP) 伺服器，這些伺服器通常只是現有 API 的薄層封裝。雖然這很有用，但這種方法迫使代理繼承了這些 API 的限制：複雜的身份驗證、分頁、僵化的架構（schemas）以及對特定 Object IDs 的需求。其結果是一個「代理循環」（agentic loop），AI 在處理 API 管道工作上的花費時間比實際進行數據推理的時間還要多。

問題所在：47 步追蹤

Airbyte 的共同創辦人兼 CEO Michel Tricot 通過一個真實世界的案例，強調了當前代理設計中的一個關鍵失效點。一個被指派回答看似簡單問題的代理——"哪些客戶在本季度有流失風險？"——導致了包含 47 個不同步驟的追蹤紀錄。

其中大多數步驟都是重複的 API 調用：尋找帳戶、將其映射到客戶，以及搜尋支援工單。等到代理得出結論時，過程異常緩慢，且最終答案是錯誤的。這之所以發生，是因為代理通常被迫在運行時（runtime）去發現重要的資訊，導致了高 Token 消耗量以及高度的幻覺或錯誤機率。

介紹 Airbyte Agents 與 Context Store

為了解决這個問題，Airbyte 推出了 Airbyte Agents，這是一個統一的數據層，旨在於代理開始推理之前為其提供必要的上下文（context）。此架構的核心是 Context Store。

與實時 API 調用不同，Context Store 是一個針對代理搜尋進行優化的數據索引，由 Airbyte 現有的複製連接器（replication connectors）庫所填充。這將數據發現的負擔從代理的運行時轉移到了預先索引的層級。

此架構允許代理：

高效發現數據：使用結構化索引來尋找相關實體，而無需猜測 API 端點。
減少延遲：消除組裝上下文所需的數十次連續 API 調用。
保持直接訪問權限：雖然索引處理了發現工作，但當需要執行特定操作時，代理仍然可以直接讀取和寫入上游系統。

性能基準測試：以 Token 作為成功的指標

為了驗證這種方法，Airbyte 開發了一個基準測試框架，將 Airbyte Agent MCP 與各種特定於供應商的 MCP 進行比較。使用 Token 消耗量作為效率的指標（Token 消耗越少通常表示通往正確答案的路徑越直接），結果非常顯著：

Zendesk: 最多減少了 90% 的 Token。
Gong: 最多減少了 80% 的 Token。
Linear: 最多減少了 75% 的 Token。
Salesforce: 最多減少了 16% 的 Token（注意到 Salesforce 的原生 SOQL 已經非常高效）。

這些增益的主要驅動因素之一，特別是在 Zendesk 的案例中，是數據過濾的能力。雖然某些社群 MCP 返回整個 API 響應（每條記錄平均 9KB），但 Airbyte 的實作允許代理僅檢索所需的最小數據量。

社群觀點與技術挑戰

這次發布引發了關於代理型數據訪問未來的技術對話。社群討論中出現了幾個關鍵主題：

「為 AI 打造 ETL」的爭論

一些觀察者指出，這種方法本質上是將數據工程重新帶回 AI 的前沿。正如一位評論者所說，「你建立了一個 ETL 管道並稱之為代理。」這強調了一個更廣泛的趨勢：AI 工程師通常缺乏理解 ETL 管道權衡的數據工程背景，而他們的應用程式卻日益渴求數據。

數據新鮮度與同步

一個反覆出現的擔憂是操作數據的波動性。如果代理依賴於索引（Context Store），則存在數據過時的風險。挑戰在於如何平衡增量複製（incremental replication）與對實時準確性的需求——即確定代理何時應該信任索引，何時必須執行實時 API 讀取。

授權與安全

隨著代理獲得跨多個系統查詢數據的能力，數據授權的複雜性也隨之增加。確保代理僅能訪問用戶被允許查看的數據（例如跨 Salesforce 和 GitHub 等不同系統），對於任何統一的上下文層來說，都是一個不容小覷的障礙。

總結

Airbyte Agents 代表了從「實時 API 尋找」到「索引化上下文檢索」的轉變。通過利用六年的連接器專業知識，Airbyte 正在嘗試將多源數據檢索的混亂過程轉變為結構化、高效的操作。對於開發代理的開發者來說，目標很明確：縮短問題與數據之間的距離，減少「管道」工作，讓 LLM 專注於推理。