[开场音乐]

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同步数据，这是有原因的。 notably，假设你正在与某个API对话…我现在不想点名任何API，但有很多是这样的：有些API，假设你想从会计系统获取一百张发票，一个API请求你就得到这些发票，你拥有所有需要的数据；但还有其他API，你只获取一百个ID的列表，然后对于每个ID，你必须去获取发票详情，这些详情可能不完整，你必须以不同方式调用。所以，你可能最终需要，比如，100个API请求，这非常低效。因此，为了让我们的客户获取这些数据，并使其持续更新，Merge总是在后台同步，并以标准化格式准备好数据，供我们的客户随时检索。然后我们进行持续同步，我们只是比较数据差异，并通过webhook向我们的客户发送更新，比如“嘿，新数据，数据被删除”之类的。

Ryan Donovan：好的。你们不是在那里每天轮询这些100个不同的ID之类的。

Gil Feig：正是。我们区分初始同步和后续同步，初始同步不幸地可能会冲击服务器，如果它们没有良好的访问模式。我们试图与这些API提供商密切合作，以改进他们的访问模式。显然，我们运行这些东西的成本也非常高。

Ryan Donovan：是的，你们选择webhooks而不是像Kafka或事件驱动系统，有什么原因吗？

Gil Feig：我们也认为Kafka是事件驱动系统。主要是因为我们广泛的客户群通常熟悉webhooks。他们倾向于连接很多东西。我们有客户，你知道，接收我们的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前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搜索，模糊——，你知道，只是，文本匹配类型的查找，然后还有一个更语义化的搜索端点，用于每个数据模型。当然，还有像——你需要丰富的webhooks。我可以列举无数。比如，我们需要知道什么数据被删除了，而不必重新同步完整的数据集——还有很多那样的东西。

Ryan Donovan：是的。人们通过轮询或各种基于事件的系统进行的更新——比如，什么改变了。

Gil Feig：是的，正是。而现在，你知道，你面临这个困境，尤其是当数据被删除时，这——由于GDPR和所有一切——使其成为一个巨大的痛苦，因为如果某物从系统中删除，你无法知道，因为没有更新。唯一知道的方法是重新思考整个数据集，或者希望他们有某种形式的webhook可以让你知道数据被删除了。

Ryan Donovan：哦。又一个GDPR问题。令人惊讶的是GDPR能触及多少事情。

Gil Feig：是的。它影响业务的每个方面。

Ryan Donovan：是的。

Gil Feig：老实说，为了最好，但这很难做。

Ryan Donovan：嗯，女士们先生们，又到了节目的时间，我们向那些来到Stack Overflow、分享知识、分享好奇心并为自己赢得徽章的人表示敬意。今天，我们向一个全新的、新鲜的 lifeboat 徽章获得者致敬——有人发现了一个得分负三或更低的下沉问题，他们丢了一个答案，把问题提了上来，并为自己赢得了20分。所以祝贺Abhijit回答了“Python中的复数”。如果你对此好奇，我们会在节目笔记中提供。我是Ryan Donovan。我编辑博客，在Stack Overflow主持这个播客。如果你有问题、担忧、评论等，请发邮件到podcast@stackoverflow.com。如果你想直接联系我，你可以在LinkedIn上找到我。

Gil Feig：非常感谢你的邀请。我是Gil Feig，再次，Merge的联合创始人兼CTO。你可以随时联系我，在X上@ Gil Feig，还有，随时给我发LinkedIn连接请求。

Ryan Donovan：好的。谢谢大家收听，我们下次再聊。

订阅播客 在您喜欢的收听服务上获取The Stack Overflow Podcast。 Apple Podcasts Overcast Pocket Casts Spotify RSS feed