最新

我是 Michel，Airbyte 的联合创始人兼首席执行官（<a href="https://airbyte.com/" rel="nofollow">https://airbyte.com/</a>）。过去六年，我们一直致力于构建数据连接器。今天，我们正式发布 Airbyte Agents（<a href="https://docs.airbyte.com/ai-agents/" rel="nofollow">https://docs.airbyte.com/ai-agents/</a>），这是一个统一的数据层，使代理能够跨业务系统发现信息并采取行动。 快速演示视频：<a href="https://www.youtube.com/watch?v=ZosDytyf1fg" rel="nofollow">https://www.youtube.com/watch?v=ZosDytyf1fg</a> 随着代理越来越深入地融入实际工作流程，它们需要访问更多工具（例如 Slack、Salesforce、Linear）。这意味着需要大量的 API 集成工作：身份验证、分页、过滤、处理模式以及跨系统匹配实体。 大多数多云平台（MCP）并不能解决这个问题。它们只是 API 的薄层封装，因此代理继承了它们的不足之处，并且在大多数情况下仍然会出错，尤其是在跨工具工作时。 一个更深层次的问题是，API 假设您已经知道要查询什么（例如端点、对象 ID、字段），而代理通常从更早的阶段开始：它们首先需要发现什么才是重要的，然后才能开始进行推理。 因此，我们构建了 Airbyte Agents，作为代理与所有数据之间的上下文层。其核心是我们称之为“上下文存储”（Context Store）的功能：一个为代理搜索优化的数据索引，由我们的复制连接器填充。过去六年我们在数据连接器方面所做的工作在这里派上了用场！ 这为代理提供了一种结构化的数据发现方式，同时仍然允许它们在需要时直接读写上游系统。 促使我们着手解决这个问题的是一个我们正在迁移到新 SDK 的代理的离谱的执行轨迹。它本应回答“哪些客户有在本季度流失的风险？”。该轨迹包含 47 个步骤，其中大部分是 API 调用。代理首先需要找到一系列账户，然后将它们映射到正确的客户，接着查找工单，等等……当代理最终给出答案时，听起来还可以，但却是错误的。不仅如此，速度还慢得令人痛苦。所以我们必须解决这个问题。 这个 47 步的代理是我们 Airbyte Agents 特别擅长回答的问题的一个例子。其他例子包括：“显示本月所有即将成交的企业级交易以及相关的未解决支持工单。”、“查找所有没有关联 Github issue 的支持工单。” 其中一些问题听起来可能很简单，但当代理无需在运行时拼凑所有这些上下文时，答案的质量会发生巨大变化。 在产品早期版本完成后，我花了一个周末构建了一个基准测试工具来验证其效果。出于兴趣，我也喜欢编写基准测试！我将调用 Airbyte Agent MCP 与直接调用一系列供应商 MCP 进行了比较。我测试了检索和搜索。 为了简单起见，我使用 token 消耗量作为衡量单位。我认为这是衡量代理工作效率的一个很好的指标。一个失败的代理（例如那个花了 47 步的）会消耗大量 token 却一无所获，而一个成功的代理则能直奔主题。 我在测量时发现：对于 Gong，token 消耗量比他们自己的 MCP 少了高达 80%；对于 Zendesk，少高达 90%；对于 Linear，少高达 75%；对于 Salesforce，少高达 16%（Salesforce 自己的 SOQL 在这方面做得很好）。 当然，存在显而易见的偏见：我们是基准测试的构建者。因此，我们公开了测试工具：<a href="https://github.com/airbytehq/airbyte-agents-benchmarks" rel="nofollow">https://github.com/airbytehq/airbyte-agents-benchmarks</a>。欢迎大家随意查看，如果您有任何发现，请告诉我们！ 目前仍处于早期阶段，有些部分还比较粗糙，但我们希望尽快与社区分享。我们非常希望听到构建代理的各位的反馈： - 您是提前索引数据，还是让代理实时调用 API？ - 您是如何跨系统匹配实体的？ 我们也希望听到任何关于如何改进产品、是否存在明显遗漏的看法、评论或想法。目前，我们很高兴能继续前进！