加载失败
Airbyte（开源数据集成/ETL 平台）这次展示的是 Airbyte Agents，目标是把数据库、SaaS 和内部系统的多源数据变成 agents 可用的上下文。讨论里大量提到 MCP（Model Context Protocol，一种把外部工具和数据源接入模型的协议），因为它决定了 agent 如何搜索、读取字段以及控制返回内容。帖子里的基准测试把 Airbyte 的做法和 Salesforce、Zendesk、Gong 等 vendor 或社区 MCP 实现对比，重点看检索步数、token 消耗和搜索结果是否过于臃肿。评论者还把问题延伸到数据工程：很多 AI 应用并不缺模型，缺的是清晰的数据访问层、过滤能力，以及处理数据新鲜度的管道。
不少评论把 Airbyte Agents 看作 Airbyte 向 AI 时代的顺势升级。有人直接把它类比为 MCP gateway，认为它可以成为 agent 访问企业数据源的关键中间层。也有人指出，很多 AI 应用“数据很饿”，但做应用的人未必懂 ETL 和数据建模，因此 Airbyte 的数据工程经验正好补上这一块。实际使用者也提到已经在公司里用 Airbyte 或 PyAirbyte 接入数据源，说明它不只是概念，而是有现成的生产基础。
另一组评论集中讨论 MCP 的实现细节，以及它和 Airbyte 方案在效率上的差别。帖子作者补充，很多 vendor 并没有官方 native MCP，只能拿社区实现来比，因此测试更多是趋势判断；Salesforce 因为 SOQL 搜索能力较强，差距相对最小。Zendesk 的社区 MCP 则被指出会把完整 API response 直接塞进搜索结果，平均每条记录约 9KB，极易污染 context。相比之下，Airbyte 通过过滤只返回必要字段，能明显降低 token 消耗和上下文膨胀。
评论里反复提到，agent 的难点往往不是“能不能连上数据”，而是“能不能快速找到正确的数据”。很多 API 的 search 太弱，agent 只能在分页结果里反复翻找，甚至要跑几十步以上；因此有人认为 search API 应该主动给 agent 提示，比如告诉它该过滤哪个字段、哪些值最值得先查。也有人分享内部系统的做法：与其让 agent 直接面对复杂搜索，不如先把数据同步到 DB，再开放给 agent 查询。另一个现实问题是数据时效性，尤其是运营数据变化很快时，旧副本和索引可能导致错误答案，所以增量复制还是直接回源读取仍是难题。
MCP（Model Context Protocol）: 一种把外部工具、搜索和数据源标准化接给模型的协议，让 agent 能更一致地读取上下文。
ETL: Extract-Transform-Load，数据抽取、转换并加载到可查询系统的流程，是多数据源接入的基础。