API调用简化与AI驱动的未来：Merge如何统一第三方集成
引言
Ryan Donovan：大家好，欢迎来到Stack Overflow播客，这是一个讨论所有软件和技术话题的地方。我是主持人Ryan Donovan，今天我们将讨论第三方API以及如何将它们简化为单一调用，可能还会涉及一些AI方面的内容。今天的嘉宾是Merge的联合创始人兼CTO Gil Feig。欢迎来到节目，Gil。
Gil Feig：谢谢邀请，Ryan。很高兴来到这里。
从游戏到企业软件：Gil的技术之旅
Ryan Donovan：节目开始，我们想了解一下我们的嘉宾。你是如何进入软件和技术领域的？
Gil Feig：这是个好问题。我从12岁就开始编码，当时并不是因为我想构建企业级B2B SaaS应用。我12岁时在玩电子游戏，看到很多人在使用机器人程序，我就想：“为什么我要手动玩而其他人都在用机器人？”于是我开始接触机器人程序，并发现这其实是一个很深的社区。有库可以解决反机器人行为，比如随机出现的魔方求解。我深入其中，后来被接受进入负责核心库的团队，那时我大约13或14岁，这真正激发了我对软件的热情，从此再也没有停止。
Ryan Donovan：有趣。大多数人会说“我想制作更多游戏”，而你却说“我想少玩这些游戏”。
Gil Feig：正是如此。
Merge的使命：简化API集成
Ryan Donovan：这种对简化和自动化流程的热情引导你创立了Merge，对吗？如今，每个网络应用都只是后端API的集合。我见过并和一些试图简化API和数据访问的人交谈过，比如超级图、GraphQL等。你能谈谈Merge如何解决将多个入口点减少到单一入口点的问题吗？
Gil Feig：当然。我们解决这个问题的起因是，我们注意到在我公司和我的联合创始人的前公司，每个人都在重复构建相同的API，尤其是在B2B领域。当你需要集成，比如与会计软件QuickBooks集成，你想向客户推送发票；你还需要与Xero、NetSuite和Sage集成，因为你的客户使用不同的软件，你希望确保能支持广泛的客户基础。这就是Merge的由来。我们与所谓的“类别”集成，即软件垂直领域，如HR、工单、文件存储——文件存储尤其变得非常流行——会计等。我们有七个类别，并且增长迅速。本质上，我们创建一个有主见的、标准化的数据模型，包含所有这些平台之间的共同点，然后与所有平台集成并转换为一种格式。这显然比简单的字段映射更复杂。有些平台没有完整对象的概念，有些平台有大量新功能；因此，我们既有共同点，也有大量功能让你能够使用API的全部底层功能。
Ryan Donovan：我想深入探讨你提到的几个术语：有主见和标准化。
Gil Feig：是的。
Ryan Donovan：在数据模型中，这意味着什么？
Gil Feig：让我们以Jira和Asana这样的工单系统为例。例如，Jira可能有一个叫做“title”的字段，在项目或工单上，而Asana可能有一个叫做“name”的字段，对吧？这是最简单的例子，总是以类型的形式返回给我们的客户。但然后，你会有一些字段真的很特殊。在Jira中，你有“epics”。这些在其他平台中并不真正存在，因此我们必须找到方法来说“一个epic如何适应某种项目分组？”所以我们有一个通用的分组对象，上面有类型。这就是我们的思考方式。我们还提供所有 onboarding 流程；因此，我们的客户只需弹出一个iFrame，引导他们的客户完成 onboarding，这就是他们看到的Merge的全部。此时，他们的系统已连接，Merge正在拉取所有数据，我们对其进行标准化——即将其转换为我们的数据模型——这些数据模型是有主见的，因为我们必须决定，我们不能包含每个平台的每个字段，否则你会得到一个非常稀疏的API，其中有数千个字段，而每个集成只返回20个。通过这样做，我们让人们能够真正轻松地在其上构建产品和功能，并知道这些功能将在所有平台上具有广泛的覆盖范围。
Ryan Donovan：所以，无论什么平台，它都是一种一致的数据对象。
Gil Feig：正是如此。
Ryan Donovan：这种标准化或有主见的设计，有多少是手动的？
Gil Feig：几乎全部。如今，我们可以使用AI来帮助研究不同的API，但每个平台仍有大量细微差别。有些东西没有文档记录，人们实际使用平台的方式可能有某些行为令人惊讶。一个API可能向我们暴露一个名为“Epic”的字段，但它从未被填写，因为它已被弃用，或者是某些隐藏功能，人们以不同的方式处理。因此，这不仅仅是进行标准化。我们还必须理解平台行为。
数据同步与访问模式
Ryan Donovan：对于其中一些解决方案，我见过单一入口点会引发一连串调用，但我也可以看到缓存或构建共享数据存储的价值。你们决定走哪条路？
Gil Feig：Merge同步数据，这是有原因的。值得注意的是，假设你与某个API交谈…我现在不想点名任何API，但有很多是这样的：有些API，假设你想从会计系统获取一百张发票，一个API请求你就得到这些发票，你拥有所有需要的数据；但还有其他API，你只获取一百个ID的列表，然后对于每个ID，你必须去获取发票详情，而这些可能不完整，你必须以不同方式调用。因此，你可能最终需要发出100个API请求，这非常低效。因此，为了让我们的客户获取这些数据，并使其持续更新，Merge始终在后台同步，并以标准化格式准备数据，供我们的客户随时检索。然后我们进行持续同步，我们只是比较数据差异，并通过webhook向客户发送更新，比如“新数据，数据被删除”之类的。
Ryan Donovan：好的。你们不会每天轮询这100个不同的ID之类的。
Gil Feig：正是。我们区分初始同步和后续同步，初始同步如果API提供者没有良好的访问模式，可能会冲击服务器。我们试图与这些API提供商紧密合作，以改进他们的访问模式。显然，我们运行这些操作也非常昂贵。
Ryan Donovan：你们选择webhook而不是像Kafka或事件驱动系统的原因是什么？
Gil Feig：我们也认为Kafka是事件驱动系统。主要是因为我们的广泛客户群通常熟悉webhook。他们倾向于连接很多东西。我们有客户接收我们的webhook，然后将其转换为Kafka事件。所以，你可以这样做，但我们已经向上市场移动。我们现在向越来越大的公司销售，并且有客户要求它。所以，这绝对是我们正在考虑的事情。
API爆炸的驱动因素
Ryan Donovan：是的。我认为这是每个人都面临的问题。你认为是什么驱动了API的爆炸式增长，使得每个人都必须集成？
Gil Feig：我认为最大的原因是客户需求。你知道，10或15年前，很难找到API，即使有，也是基于相当糟糕的技术。随着人们使用更多平台，他们开始看到“我刚买的这个平台与我买的另一个平台集成”，这成为了市场期望。显然，在路线图方面，金钱说话。因此，当销售团队说“嘿，我们无法关闭这些客户，因为他们说我们不与他们使用的X平台集成”时，这完全驱动产品团队真正强调这些集成。这就是为什么我们看到公司加倍投入，变得更加开放，并理解在许多情况下，当你更加开放时，你成为事实的来源。因此，人们依赖你——他们被绑定在你身上，因为他们所有其他软件都紧密集成。
Ryan Donovan：对，我认为当前时代——驱动许多集成的是代理连接和工具使用，以及像MCP这样的设置来解决这个问题。你如何看待MCP访问与集中式API访问相比？
Gil Feig：首先，我认为MCP是我们都在等待的协议，对吧？每个人都在捣鼓AI，他们想“好吧，我想让它调用这个API”。所以你会写一个小工具来调用API，它工作了。虽然不是很好，但MCP出现了，我认为对每个人来说，都是“终于”的感觉。这并不是说这是一个重量级或极具创造性的协议；它只是我们都在等待的协议。我们只是希望世界能采用一些东西，因此我认为，有了MCP，我们现在有更简单的方法从代理进行这些第三方API调用。但我认为我们仍然看到的最大问题之一是MCP服务器：首先，它们构建得不是很好——很多是为了营销而构建的，当MCP风头正劲时，每个人都想要那个营销时刻，所以他们派一个工程师上去，用AI将他们的API转换为简单的包装器…有趣的是，你真的去测试一些非常流行的、大软件公司的MCP服务器，它们在基本请求上就失败了。所以我们对此感到兴奋。我认为，实际上，MCP真正起飞需要看到的最大变化是这些第三方API有更好的访问模式，因为最终，它们只能做底层API能做的事情，对吧？它们只是包装API调用并将其暴露给代理，因此，如果你尝试询问任何语义性的东西，比如“从我们的工单系统中获取情绪最差的工单”。它唯一可能做到这一点的方法是同步系统中的每个工单，然后对其进行向量化，或者如果数据集足够小，使用LLM上下文。但无论如何，你必须对数据进行完全同步，以支持任何超越“通过特定ID或名称获取某些东西”的问题。
Ryan Donovan：对。这很有趣。但这本质上是REST API的性质，或者无论它们在后端使用什么。你认为有可能出现一种新的AI驱动的API系统吗？
Gil Feig：我认为是可能的。你知道，我认为有方法可以暴露这个，甚至你只有一个端点，比如“发送一个LLM，发送某种查询或某种提示”。而我拥有——我们作为企业——我们所有的数据都被向量化了，因此当你询问这些时，我们可以跨数据搜索并回应你一些更经过思考的内容。但是，公司现在并没有很强的动力去做这件事，因为向量化所有数据并提供服务的成本非常高。
Ryan Donovan：是的。我的意思是，大多数API基本上只是数据库之上的薄层，我认为，像你向该数据库添加向量，你就可以拥有这个非常强大的LLM API。但然后你就有调用问题，对吧？
Gil Feig：是的，正是。我的意思是，这增加了全面的成本。我认为它很强大，但公司并不一定被提供所有这些功能所驱动。
Ryan Donovan：是的。我认为像——我前几天读到一篇文章，说95%的公司的AI努力都失败了。就像每个人都在尝试，但很多都不起作用，每个人都在摸索模式和最佳实践。
Gil Feig：是的，我认为完全正确。我也看到了那篇文章。那是95%的内部试点，有趣的是；我认为其中很大一部分也是因为公司只是派那些没有实验过、没有见过好样子的人去做，所以他们只是继续做，然后说“哦，它90%准确，但10%不够好——我们需要放弃这个”。而有方法可以克服那10%，我认为人们只是没有探索，从链式调用，以及让代理相互配合。所以，我对此感到兴奋，我们实际上在Merge一直在极力推动人们——就像我们在AI业务演进中的旅程是使用子代理链式调用LLM，以及所有这一切。
Ryan Donovan：嗯。这很有趣。但在我们深入之前，我想了解一下——你说他们试图弄清楚“好”是什么，这是我在思考AI和AI项目时一直在想的问题。你如何实际定义什么是“好”？
Gil Feig：是的。“好”因公司而异，这完全关乎风险承受能力，对吧？一辆自动驾驶汽车在左转时不能只有90%的准确率。而某些为某人提供周末计划样本的东西可以有90%的准确率，这没什么大不了的。
AI代理与代码生成
Ryan Donovan：你谈到的这些东西——改进的AI路径、链式调用、代理式的东西——你能多谈谈这个领域的概况吗？
Gil Feig：是的，我们在这里探索了很多不同的方法。你知道，有些直接与工具集进行链式调用。在代码中，我们尝试了一些可视化编辑器，然后我们尝试了一些像call code这样的方法，例如，你有这种代理式文件，它们根据需要选择相互调用。你告诉这个代理，“调用这个代理”——我们实际上发现这是最轻量级的方式，并且是非常愉快的工作。我们取得了良好的结果。我们正在为一个新的、更专注于MCP的AI产品进行一个新项目，我们现在正在生成许多连接器。这需要一些手动工作；它们从来不是100%足够好，但它让我们足够接近，确实节省了大量时间。
Ryan Donovan：嗯。我听说过一些关于——你知道，不是完全100%——有时解开AI技术债务所创造的东西需要更多努力。你发现是这种情况吗，还是就像你现在理解这些AI是如何工作的？
Gil Feig：所以，我确实认为理清那里发生的一切可能非常困难。但你可以使用AI来帮助解决这个问题，并在它向你显示结果之前使用AI来完成，对吧？因此，假设你使用AI生成这些AI连接器之一，对吧？你不一定需要说“好了，它生成了。让我现在去测试”。相反，下一个代理生成测试并在所有测试上运行，这些测试是在指南内构建的，也许你有一些静态测试运行。所以，这些测试的结果是反馈给一个代理，该代理去修复。因此，我们最终确实会遇到一些问题，但在所有代理都运行过代码之后，大多数问题都消失了。
Ryan Donovan：有没有什么事情需要人工完成，也就是说，只有人类才能完成这部分？
Gil Feig：这是个好问题。所以，好吧，这里有几个例子。有些实际上是测试和修改描述，以查看LLM正在捕捉什么，因为它可能因用例而异。你知道，你提出问题，LLM必须决定调用什么工具，而工具上的描述不佳，或者与产品本身用例不完全相关的描述，最终会选择错误的工具，或者根本不选择工具。因此，确实需要为你的用例大量修改这些。
Ryan Donovan：是的。我们刚刚发布了今年的开发者调查结果——截至本次录制大约一个月前——我们在AI方面发现的一件事是，人们使用得更多但信任得更少。这就像是意识到了这种准确度差距。你们在建立信任以减少不准确性方面做了什么？
Gil Feig：是的。我认为通常是让代理相互配合，让它们“斗争”直到达到相对可靠的解决方案。你知道，当生成的代码通过编写的静态测试时，你会获得信任。我意识到，当它通过AI也编写的测试时，你不会获得信任，因为这些测试通常是——你进去看它们，就像“assert 1 = 1”，你会说“好吧，那总是会通过的”。所以，我认为对我们来说，一直是不断修改提示，不断达到更好的状态，我们实际上看到代码输出足够好，这就是我们开始建立更多信任的方式。但是，我认为现在100%信任AI去编写一切是疯狂的，实际上，一个很好的例子是我们的新产品：我们生成了一些东西，它只是从一个端点公开返回一个API密钥。但是，显然，我们是软件工程师，我们进行代码审查，我们查看——我们立刻发现了那个问题。但这只是，你知道，它有时会做一些疯狂的事情，不仅仅是小错误，对吧？那可能真正意味着你业务的终结。
Ryan Donovan：对。是的。我的意思是，我认为当软件工程师与这些代码创建代理一起工作时，它可能非常强大；但我们在这里做了一个实验，我们让我们的初级作家尝试用代码生成工具创建一些东西，她创建了一个应用，但当她向软件工程师展示时，他们就像“这里到底发生了什么？”我看到，你知道，这些创业者认为他们可以只用代码生成工具开发代码并运行。
Gil Feig：是的。这很有趣——它让我想起，我不知道你是否是Twitter或X的重度用户，但Levels IO账户，你知道——这个人 vibe codes 了整个游戏，然后他吹嘘并谈论所有关于它的事情，然后被DDoS攻击，就像“我不知道该怎么做，这里发生了什么？”而任何软件工程师都会说“ quickly put it in front of CloudFlare”。但是，你知道，这些事情看起来真的很有趣。
Ryan Donovan：是的。我想知道，是否会有一种新的“提示最佳实践”——有人有一个巨大的模板，他们只是放在那里，思考所有OASP前10名并确保你修复它们？
Gil Feig：是的。就像Tea应用发生的事情…我不知道你是否也看到了。Tea是一个最近在应用商店爆火的应用；它是一个让女性分享她们与男性约会经历的地方。她们让女性在注册时上传身份证或自己的照片，全部发布到一个公共S3存储桶，并启用了目录列表——
Ryan Donovan：哦，我的天。
Gil Feig：所以，你可以看到每个文件，整个东西，你知道，数百万女性的身份证和照片，而且，你知道，男性对这个应用感到不安，所以他们，你知道——对于这样一个新手错误来说，这真是一个危险的情况。
Ryan Donovan：是的。
Gil Feig：顺便说一句，那都是 vibe coded 的。所以，这就是问题所在。
Ryan Donovan：是的，纯粹的 vibe coding 似乎确实是个问题。但我想知道，你知道——我们之前发布的另一篇文章像是，“当每个人都在编码时，你如何获得初级开发者？”对吧？就像，初级开发者是高级开发者的学徒，而现在初级开发者的角色可以由 vibe coding 填补。就像，你如何获得初级开发者？
Gil Feig：这是一个非常好的问题，我想问题是，你知道——我认为我们处于这个奇怪的中间时期，AI还不够好到完全取代他们。但是是的，我们最终可能会遇到那种奇怪的——你知道，当你看到国家的人口曲线，没有足够的漏斗上升到高级和staff角色时。所以，我们最好希望AI快速发展。也许我们确实需要一点像整个数学课那样的，“你不能使用计算器！”即使每个人都说“但我总是可以”，你知道？
Ryan Donovan：是的。你必须去那里，展示你的工作，你必须手写。另一方面，我认为有一个世界，每个人都是架构师，对吧？每个人都只是投入一个规范，而真正的编码变成了编写一个非常好的规范。
Gil Feig：是的。我的意思是，我认为这是真的，但即使是规范——AI也变得相当不错了，对吧？就像，显然，它不知道所有细节，但你用3句话描述你想构建的项目，它就很不错了。
Ryan Donovan：是的。我的意思是，这某种程度上说明了每个人都想解决相同的问题，对吧？每个人都像“给我一个白板应用”，然后就像“是的，伙计，有几十个那样的”。
Gil Feig：是的。显然，我们正在做的一些更深层次的事情，比如，我们现在正在重构整个数据层，对吧？比如，跨多个数据库拆分并添加Dynamo，只是添加大量不同的服务。是的。AI不擅长那个。
Ryan Donovan：嗯，好的。软件工程师在某个地方仍然有家。
Gil Feig：当然。
API的未来展望
Ryan Donovan：你谈到了MCP服务器——你们正在关注的“下一件事”。你认为API的未来会是什么？我知道我们已经触及了一些推测，但它的深层未来是什么？
Gil Feig：是的，所以，当涉及到实际协议和无论什么时，我认为它并不重要，对吧？就像，最终，我们试图跨系统传输数据。但重要的是，再次强调，访问模式，更具体地说。因此，我认为对于AI或API来说，要真正实现下一次进化并启用许多功能，我们需要更好的访问模式。我们需要能够在这些API上搜索数据，而不仅仅是模糊搜索。你确实在API中看到一些模糊或精确匹配搜索，但我们需要语义搜索。我们需要——甚至超越elastic，就像，如果每个人都有从向量化查找获取的端点，那将是不可思议的。我认为这些是我们需要去的地方。我不知道我们是否会再次去那里，只是因为对所有数据进行这种操作的成本极高——你可能需要开始为你的API收费，这使你在竞争市场中变弱。所以，我还不确定，但我们需要那些更好的访问模式；这是我能说的。
Ryan Donovan：是的。我认为人们一直在追求语义网，你知道，只要网络存在就一直如此。
Gil Feig：是的。是的，这是真的。
Ryan Donovan：所以，如果你要设计具有最佳访问模式的理想API，你的愿望清单上会有什么？
Gil Feig：嗯。好吧，它会有核心数据模型、批量操作，所有那些好东西。它永远不需要运行最终查询，对吧？你永远不想逐个模型获取——你应该获取页面，并且这些数据页面应该具有子模型和所有扩展的内容，如果需要的话，对吧？这些都应该是可定制的。GraphQL是一种实现方式。REST后端有expand参数，所以你可以做所有这些。然后两个补充将是一个elastic搜索、模糊——你知道，只是文本匹配类型的查找，以及每个数据模型的更语义化的搜索端点。当然，还有像——你需要丰富的webhook。我可以列举无数。比如，我们需要知道什么数据被删除了，而不必重新同步完整的数据集——还有很多那样的东西。
Ryan Donovan：是的。人们通过轮询或各种基于事件的系统进行的更新——比如，什么改变了。
Gil Feig：是的，正是。而现在，你知道，你面临这个困境，尤其是当数据被删除时——由于GDPR等——这变得非常痛苦，因为如果某些东西从系统中删除，你无法知道，因为没有更新。唯一知道的方法是重新思考整个数据集，或者希望他们有某种形式的webhook可以让你知道数据被删除了。
Ryan Donovan：哦。又一个GDPR问题。令人惊讶的是GDPR能触及多少事情。
Gil Feig：是的。它影响业务的每个方面。
Ryan Donovan：是的。
Gil Feig：老实说，这是为了最好，但很难做到。
结语
Ryan Donovan：女士们先生们，又到了节目的时间，我们向那些来到Stack Overflow、分享知识、分享好奇心并为自己赢得徽章的人表示敬意。今天，我们向一个全新的、新鲜的生命线徽章获得者致敬——有人发现了一个得分负三或以下正在下沉的问题，他们提供了一个答案，提升了问题，并为自己赢得了20分。所以祝贺Abhijit回答了“Python中的复数”。如果你对此感兴趣，我们会在节目笔记中提供。我是Ryan Donovan。我在Stack Overflow编辑博客并主持这个播客。如果你有问题、担忧、评论等，请发送电子邮件至podcast@stackoverflow.com。如果你想直接联系我，你可以在LinkedIn上找到我。
Gil Feig：非常感谢你的邀请。我是Gil Feig，Merge的联合创始人兼CTO。你可以随时联系我，在X上@ Gil Feig，也可以随时向我发送LinkedIn连接请求。
Ryan Donovan：好的。谢谢大家收听，我们下次再聊。