Show HN：Airbyte Agents – 为跨多个数据源的智能体提供上下文
15 分•作者: mtricot•3 个月前
我是 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？
- 您是如何跨系统匹配实体的？
我们也希望听到任何关于如何改进产品、是否存在明显遗漏的看法、评论或想法。目前，我们很高兴能继续前进！
查看原文
I’m Michel, co-founder and CEO of Airbyte (<a href="https://airbyte.com/" rel="nofollow">https://airbyte.com/</a>). We’ve spent the last six years building data connectors. Today we're launching Airbyte Agents (<a href="https://docs.airbyte.com/ai-agents/" rel="nofollow">https://docs.airbyte.com/ai-agents/</a>), a unified data layer for agents to discover information and take action across operational systems.<p>Here’s a quick walkthrough: <a href="https://www.youtube.com/watch?v=ZosDytyf1fg" rel="nofollow">https://www.youtube.com/watch?v=ZosDytyf1fg</a><p>As agents move into real workflows, they need access to more tools (e.g. Slack, Salesforce, Linear). That means a ton of API plumbing: authentication, pagination, filters, handling schema, and matching entities across systems.<p>Most MCPs don’t fix this. They’re thin wrappers over APIs, so agents inherit their weak primitives and still get it wrong most of the time, especially when working across tools.<p>An even deeper issue is that APIs assume you already know what to query (think endpoints, Object IDs, fields), whereas agents usually start one step earlier: they need first to discover what matters before they can even start reasoning.<p>So we built Airbyte Agents to be a context layer between your Agents and all of your data. The core of this is something we call Context Store: a data index optimized for agentic search, populated by our replication connectors. All that work on data connectors the last six years comes in handy here!<p>This gives agents a structured way to discover data, while still allowing them to read and write directly to the upstream system when needed.<p>What got us working on this was an insane trace from an agent we were migrating to our new SDK. It was supposed to answer "which customers are at risk of leaving this quarter?" The trace had 47 steps. Most were API calls. The agent first had to find a bunch of accounts, then map them to the right customers, then look for tickets, bla bla... and when the Agent finally responded, the answer sounded ok, but was wrong. Not only that, it was excruciatingly slow. So we had to do something about it.<p>That 47-step agent is one example of a question where Airbyte Agents does particularly well. Other examples: - “Show me all enterprise deals closing this month with open support tickets." - “Find every support ticket that doesn’t have a Github issue opened”<p>Some of these might sound simple, but the quality of the answer changes dramatically when the agent doesn’t have to assemble all that context at runtime.<p>Once we had an early version of the product, I spent a weekend building a benchmark harness to see if it worked. Also for fun, I like writing benchmarks :). I compared calling the Airbyte Agent MCP vs calling a bunch of vendor MCPs directly. I tested retrieval, and search.<p>For the sake of simplicity, I used token consumption as a unit of measure. I think that’s a good proxy for how well agents are working. A failing agent (like the one that took 47 steps), will churn through lots of tokens while getting nowhere, while a successful one will get straight to the point.<p>Here's what I found when measuring: for Gong, it used up to 80% fewer tokens than their own MCP, for Zendesk up to 90% fewer, for Linear up to 75%, and for Salesforce up to 16% (Salesforce’s own SOQL does a good job here).<p>Of course there is the usual obvious bias: we are the builders of what we are benchmarking. So we made the test harness public: <a href="https://github.com/airbytehq/airbyte-agents-benchmarks" rel="nofollow">https://github.com/airbytehq/airbyte-agents-benchmarks</a>. Feel free to poke at it, and please tell us what you find if you do!<p>It's still early and some parts are rough, but we wanted to share this with the community asap. We'd love to hear from people building agents:
- Are you indexing data ahead of time, or letting the agent call APIs live?
- How are you matching entities across systems?<p>Would also love to hear any thoughts, comments, or ideas of how we could make this better, and if there are obvious things we’re missing. For now, we’re excited to keep building!