访谈内容
[Intro music]
Ryan Donovan: 大家好，欢迎来到Stack Overflow播客，这是一个讨论所有软件和技术话题的地方。我是主持人Ryan Donovan，今天我们将讨论第三方API以及如何将它们简化为单一调用，可能还会涉及一些相关的AI方面。今天的嘉宾是Merge的联合创始人兼CTO Gil Feig。Gil，欢迎来到节目。
Gil Feig: 谢谢邀请，Ryan。很高兴来到这里。
Ryan Donovan: 节目开始，我们想了解一下我们的嘉宾。你是如何进入软件和技术领域的？
Gil Feig: 这是个好问题。我从12岁就开始编程，当时并不是因为我想“去构建一些企业级B2B SaaS应用”，显然不是。我12岁时在玩电子游戏，看到很多人在使用机器人程序，我就想“为什么别人都用机器人程序，而我还在手动操作？”于是我开始接触机器人程序，并发现这实际上是一个很深的社区。有解决反机器人行为的库，可以解决随机出现的魔方等问题。我深入其中，后来被接受加入负责核心库的团队，那时我大约13或14岁，这真正激发了我对软件的热情，从此再也没有停止。
Ryan Donovan: 对，这很有趣。大多数人会说“哦，我想开发更多游戏”，而你却说“我想少玩这些游戏”。
Gil Feig: 正是如此。
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事件。所以，你可以那样做，但我们已经向上游市场移动。我们现在向越来越大的公司销售，并且有客户提出要求。所以，这绝对是我们正在考虑的事情。
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的性质。RPC或他们在后端使用的任何东西。你认为有可能出现一种新的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%的准确率，这没什么大不了的。
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 top 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还不够好到完全取代他们。但是是的，我们最终可能会遇到那种奇怪的——你知道，当你看到那些国家的人口曲线，没有足够的人向上流入高级和资深职位时。所以，我们最好希望AI发展得快一点。也许我们确实需要一点，就像整个数学课，“你不能使用计算器！”即使每个人都说“但我总是可以”，你知道？
Ryan Donovan: 是的。你必须去那里，展示你的工作，你必须，你知道，手写它。另一方面，我认为存在一个世界，每个人在某种程度上都是架构师，对吧？每个人都只是投入一个规范，而真正的编码变成了编写一个真正好的规范。
Gil Feig: 是的。我的意思是，我认为这是真的，但即使是规范——AI也变得相当不错了，对吧？就像，显然，它不知道所有细节，但你在3句话内描述你想构建的项目，它就很不错了。
Ryan Donovan: 是的。我的意思是，这某种程度上说明了每个人都想解决相同的问题，对吧？每个人都像“给我一个白板应用”，然后就像“是的，伙计，有几十个那样的”。
Gil Feig: 是的。显然，我们正在做的一些更深层次的事情，比如，我们现在正在重构整个数据层，对吧？比如，跨多个数据库拆分并添加Dynamo，只是添加大量不同的服务。是的。AI在这方面并不擅长。
Ryan Donovan: 嗯，好的。软件工程师在某个地方仍然有家可归。
Gil Feig: 当然。
Ryan Donovan: 你谈到了MCP服务器——你们正在关注的“下一件事”。你认为API的未来会是什么？我知道我们已经稍微触及了一些推测，但它的深层未来是什么？
Gil Feig: 是的，所以，当涉及到像实际协议之类的，我只是认为它并不重要，对吧？就像，最终，我们试图跨系统传输数据。但真正重要的是，再次强调，访问模式，更具体地说。因此，我认为对于AI或API来说，要真正实现下一次演进并启用许多功能，我们需要更好的访问模式。我们需要能够在这些API上搜索数据，而不仅仅是模糊搜索。你确实在API中看到一些模糊或精确匹配搜索，但我们需要语义搜索。我们需要——甚至超越elastic，就像，如果每个人都有从向量化查找中获取数据的端点，那将是不可思议的。我认为这类事情是我们需要前进的方向。我不知道我们是否会再次走向那里，仅仅因为对所有数据进行向量化的巨大成本——你可能需要开始为你的API收费，这使你在竞争市场中处于劣势。所以，我还不确定，但我们需要那些更好的访问模式；这是我能说的。
Ryan Donovan: 是的。我认为人们一直在追求语义网，你知道，从网络诞生之初就开始了。
Gil Feig: 是的。是的，这是真的。
Ryan Donovan: 所以，如果你要设计具有最佳访问模式的理想API，你的愿望清单上会有什么？
Gil Feig: 嗯。好吧，它会有核心数据模型、批量操作，所有那些好东西。它永远不需要运行最终查询，对吧？你永远不想逐个模型获取——你应该获取页面，这些数据页面应该有子模型，如果需要，所有内容都应该展开，对吧？这些都应该是可定制的。GraphQL是一种实现方式。REST API有expand参数，所以你可以做到所有这些。然后两个补充将是一个elastic search，模糊——，你知道，只是文本匹配类型的查找，以及每个数据模型的更语义化的搜索端点。当然，还有像——你需要丰富的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: 好的。谢谢大家收听，我们下次再聊。