解决智能体数据缺口：介绍 Airbyte Agents

为了让 AI 智能体从简单的聊天界面转向真实的业务工作流，它们需要访问运营数据——即存储在 Slack、Salesforce、Linear 和 Zendesk 中的数据。然而，提供这种访问权限很少像接入一个 API 那样简单。

大多数目前的实现依赖于 Model Context Protocol (MCP) 服务器，这些服务器通常只是现有 API 的薄封装。虽然有用，但这种方法迫使智能体继承这些 API 的局限性：复杂的身份验证、分页、僵化的模式以及对特定 Object IDs 的需求。其结果是一个“智能体循环”，即 AI 花费更多时间在处理 API 管道工作，而不是真正对数据进行推理。

问题所在：47 步追踪

Airbyte 的联合创始人兼 CEO Michel Tricot 通过一个现实世界的例子，强调了当前智能体设计中的一个关键失效点。一个被要求回答一个看似简单问题——“哪些客户在本季度有流失风险？”——的智能体，最终产生了一个包含 47 个不同步骤的追踪记录。

其中大部分步骤都是重复的 API 调用：查找账户、将其映射到客户，以及搜索支持工单。等到智能体得出结论时，过程极其缓慢，且最终答案是错误的。发生这种情况是因为智能体通常被迫在运行时发现重要信息，这导致了高昂的 Token 消耗以及产生幻觉或错误的极高概率。

介绍 Airbyte Agents 和 Context Store

为了解决这个问题，Airbyte 推出了 Airbyte Agents，这是一个统一的数据层，旨在为智能体在开始推理之前提供必要的上下文。

该架构的核心是 Context Store。

与实时的 API 调用不同，Context Store 是一个针对智能体搜索优化的数据索引，由 Airbyte 现有的复制连接器库进行填充。这使得数据发现的负担从智能体的运行时转移到了预索引层。

这种架构允许智能体：

高效发现数据：使用结构化索引来查找相关实体，而无需猜测 API 端点。
降低延迟：消除为了组装上下文而进行数十次连续 API 调用的需求。
保持直接访问：虽然索引负责发现，但当需要执行特定操作时，智能体仍然可以直接读取和写入上游系统。

性能基准测试：以 Token 作为成功的衡量标准

为了验证这种方法，Airbyte 开发了一个基准测试工具，将 Airbyte Agent MCP 与各种特定于供应商的 MCP 进行对比。使用 Token 消耗作为效率的衡量标准（Token 消耗越少通常意味着通往正确答案的路径越直接），结果非常显著：

Zendesk: Token 消耗减少了高达 90%。
Gong: Token 消耗减少了高达 80%。
Linear: Token 消耗减少了高达 75%。
Salesforce: Token 消耗减少了高达 16%（注意到 Salesforce 的原生 SOQL 已经非常高效）。

这些提升的一个主要驱动因素，特别是在 Zendesk 的例子中，是过滤数据的能力。虽然一些社区 MCP 返回整个 API 响应（每条记录平均 9KB），但 Airbyte 的实现允许智能体仅检索任务所需的最小数据。

社区观点与技术挑战

此次发布引发了关于智能体数据访问未来的技术对话。社区讨论中出现了几个关键主题：

“为 AI 构建 ETL”的争论

一些观察者指出，这种方法本质上是将数据工程重新带回了 AI 的前沿。正如一位评论者所指出的，“你构建了一个 ETL 流水线并称之为智能体。”这凸显了一个更广泛的趋势：AI 工程师往往缺乏理解 ETL 流水线权衡的背景知识，但他们的应用却日益对数据产生渴求。

数据新鲜度与同步

一个反复出现的问题是运营数据的波动性。如果智能体依赖于索引（Context Store），则存在数据过时风险。挑战在于如何平衡增量复制与实时准确性的需求——即确定智能体何时应该信任索引，何时必须进行实时的 API 读取。

授权与安全

随着智能体获得跨多个系统查询的能力，数据授权的复杂度也随之增加。确保智能体在不同系统（如 Salesforce 和 GitHub）中仅访问用户被允许查看的数据，对于任何统一的上下文层来说，都是一个不容忽视的挑战。

总结

Airbyte Agents 代表了从“实时 API 搜寻”到“索引化上下文检索”的转变。通过利用六年的连接器专业知识，Airbyte 正在尝试将多源数据检索的混乱过程转变为结构化、高效的操作。对于构建智能体的开发者来说，目标很明确：缩短问题与数据之间的距离，减少“管道”工作，以便让 LLM 专注于推理。