对话记录

[开场音乐]

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账户，你知道——这个人凭感觉编码了整个游戏，然后他吹嘘并谈论它，然后被DDoS攻击，就像“我不知道该怎么办，这里发生了什么？”而任何软件工程师都会说“赶紧放到CloudFlare后面”。但是，你知道，这类事情真的很有趣。

Ryan Donovan：是的。我在想，你知道，会不会有一种新的“提示最佳实践”——有人有一个巨大的模板，他们只是放进去，考虑所有OASP前10名并确保你修复它们？

Gil Feig：是的。就像Tea应用发生的事情…我不知道你是否也看到了。Tea是一个最近在应用商店爆火的应用；它是一个让女性分享与男性约会经历的地方。她们让女性注册时上传身份证或自己的照片，全部发布到一个公共S3存储桶，并启用了目录列表——

Ryan Donovan：哦，天啊。

Gil Feig：所以，你可以看到每个文件，整个东西，你知道，数百万女性的身份证和照片，而且，你知道，男性对这个应用感到不满，所以他们，你知道——对于这样一个新手错误来说，这真是一个危险的情况。

Ryan Donovan：是的。

Gil Feig：顺便说一句，那全是凭感觉编码的。所以，这就是问题所在。

Ryan Donovan：是的，纯粹的凭感觉编码似乎确实是个问题。但我想知道，你知道——我们之前发布的另一篇文章像是，“当每个人都在编码时，你如何获得初级开发者？”对吧？就像，初级开发者是高级开发者的学徒，而现在初级开发者的角色可以由凭感觉编码来填补。那么，你如何获得初级开发者？

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：嗯。好的，它会有核心数据模型、批量操作，所有那些好东西。它永远不需要运行N+1查询，对吧？你永远不想逐个模型获取——你应该获取分页数据，这些数据页如果需要的话，应该包含子模型并且所有内容都展开，对吧？这些都应该是可定制的。GraphQL是一种实现方式。REST API有expand参数，所以你可以做所有这些。然后两个补充是弹性搜索、模糊——你知道，只是文本匹配类型的查找，以及每个数据模型的更语义化的搜索端点。当然，还有一些事情——你需要丰富的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：好的。谢谢大家的收听，我们下次再聊。