身份不明的发言人
杰伊·克雷普斯（首席执行官兼联合创始人）
谢恩·谢（投资者关系负责人）
雷切尔·泰西尔
科斯莫·沃尔夫（首席技术官）
肖恩·克洛斯（首席产品官）
拉杰什·坎达萨米（万豪国际集团）
请欢迎Confluent的首席执行官兼联合创始人杰伊·克雷普斯。大家好。
欢迎来到Current大会。我对此感到非常兴奋。这是我们第一次在新奥尔良举办，这是一个非常棒的城市。希望大家昨天有机会出去稍微看看这座城市。如果没有，希望在接下来的几天里我们能做些有趣的事情。我们会深入探讨Kafka、Flink，还会有一些很棒的产品发布。要知道，这是少数几次能让这些社区聚集在一起，讨论他们正在做什么、正在构建什么的机会之一。
通常，这些会议环节很棒，但走廊里的交流甚至更好。所以，我认为我们今天和明天的日程安排非常精彩。我今天要谈论的是我认为我们所有人都在思考的问题，即人工智能的兴起，以及我们如何构建智能系统，如何将这些系统与我们组织中现有的软件状态连接起来。我会将其与数据流式传输、实时数据以及基于这些数据采取行动的代理的世界联系起来。但为了引出这个话题，我想先谈谈我们目前所处的位置。
我认为，在某种意义上，我们正从商业智能的世界迈向人工智能的世界。我这么说是什么意思呢？我的意思是，如果你问一个组织“数据驱动意味着什么？”，如果你在10年前问这个问题，答案会有所不同。我认为当时的答案可能是，嘿，我们如何将所有数据放入数据湖仓、数据仓库？我们如何在报告和分析方面变得非常聪明？我们如何让数据科学家能够为高管解决正确的问题？这就是拥有良好商业智能的意义所在。
那就是当时数据驱动的含义。但如果我们思考一下今天它的含义，情况正在发生变化。这种变化在于，它不再仅仅是从数据中获取洞察，而是要采取行动。它关乎能够构建实际上代表企业在软件中采取行动的系统，从而闭合我们正在做的事情的循环。而这正是我们正在进入的时代。从某种意义上说，这并不是什么新鲜事。想想我们过去五年一直在构建的软件系统。
在某种意义上，很多系统都在做这件事，对吧？它们试图变得更智能，试图利用数据代表客户采取行动，试图实现个性化并提供更好的客户体验。所以，在某种意义上，这并没有什么不同，但在我看来，在某种意义上，它又真的有所不同。归根结底，人工智能系统是一个完全不同的世界。使用Claude或ChatGPT并问它们一些问题并得到答案是相当容易的。但实际上，构建一个将传统代码与人工智能结合起来，实际上接管某些业务流程、自动化大规模业务的某些部分，并且以足够高的质量使其能够投入生产并实现其目标的系统，要困难得多。
造成这种困难的部分原因是范式完全不同。想想情况发生了怎样的变化，最大的不同在于传统软件归根结底是一堆硬编码的规则。你知道，它是一堆逻辑。我们在精心设计这种逻辑、打包、抽象、提出模块和隔离部分系统方面变得非常擅长，因此我们可以支持这些极其复杂的业务逻辑堆。但归根结底，当你想到人工智能和基于人工智能的系统时，你并不是以同样的方式对其进行编程，也不是以同样的方式对其进行指定。这有点像你用数据引导它，把它推向某个方向，但归根结底，它是一个概率系统。
对吧？输出并不是精确指定的，或者至少我们所期望的输出不是。当你思考如何开发和验证这些系统时，这一点会以一种非常根本的方式体现出来。在传统软件中，你可以在不参考底层数据的情况下推理应用程序的正确性。你知道，你可以编写一组涵盖不同情况的单元测试。如果单元测试覆盖率足够好，你期望100%通过，即使你插入的可能只是一些无意义的文本，只是你用来验证的一些假数据。
这与人工智能系统有很大不同。归根结底，如果你正在构建一个支持客户的人工智能系统，如果你没有在真实的客户问题上，使用真正的支持人员帮助该客户时本可以获得的真实数据对其进行测试，那么你就不能说这个系统是有效的。如果你没有进行这样的测试，那么无论你查看多少逻辑、工作流程、规范或其他类似的东西，都无法说明该系统实际上在做它应该做的事情。
因此，从根本上说，评估的世界从主要检查逻辑转变为现在检查模型逻辑和数据在真实交互中的这种组合，并根据不精确的指标进行检查。它不会是100%完美的。你会有一系列评估告诉你，你更好了，达到了90%，95%，你在进步。这更多的是一种统计意义上的正确性。而且非常重要的是，你的开发周期现在与你使用的真实数据紧密相关。在某种意义上，在传统软件中，业务逻辑是王道。
这真的是一切，对吧？数据只是生活在生产环境中的东西，你将在这些人工智能系统中使用它，归根结底，数据，尤其是上下文数据，是最根本的东西。这是你引导模型的方式。这是它必须依赖的东西。把数据做好是让这一切真正有效的关键。那么，在这个世界里，你如何构建有效的系统呢？我们必须解决哪些重要问题？如果它在某些方面有所不同，我们必须如何调整我们正在做的事情？好吧，我会谈谈这方面的一些内容。
我提到这最终与上下文数据有关，这是问题的一个非常重要的部分。如果你考虑这些系统的成功，就输出质量而言，有两件事很重要：模型和它拥有的上下文数据。对吧？我会告诉你，其中一件事你有很大的控制权。模型是由相对少数的公司开发并推进的。你总是可以升级到下一个最好的模型，但你推动最先进技术的能力并不高。
散布在整个组织中，你想用于这些问题的上下文数据，正是你可以迭代改进的地方。这是你将系统从90%的足够好提升到100%的足够好的方法。这是你将系统从演示阶段推向生产阶段的方法，通过把数据做好。因此，擅长这一点是在这个领域取得成功的关键。当你问如何真正利用上下文数据时？我认为人们开始时会有一个基本的直觉，这是有道理的。当我们想到模型的上下文数据时，有一种叫做模型上下文协议（MCP）的东西。
如果我们将我们拥有的系统连接到一个代理，它应该能够获取它需要的上下文数据。因此，从某种意义上说，天真的方法是在我们所有的系统前都安装MCP。我们会给代理提供我们所有数据库和SaaS系统的登录信息，并说：“好吧，你自己弄明白。去理解这堆混乱的数据吧。”任何尝试过这种方法的人都知道它不太奏效。实际上事情并不是这样的。这不会给你带来你想要的结果。
这里的问题不在于MCP。MCP很棒，但MCP只是访问系统的一种方式。它实际上并没有修复系统中的数据。它并没有以对决策有用的方式对数据进行整理。因此，归根结底，我们正在访问的数据才是问题所在。如果你尝试这样做，会出现什么问题呢？有一系列挑战。最明显的一个是，你将这个新代理连接到一堆系统中，这会产生它们并非为其构建的操作负载和工作负载。
但这甚至不是真正的问题。更大的问题是访问控制，对吧？归根结底，如果我在为客户A服务，那么无论概率多小，都绝不能泄露客户B的数据，或者它绝不能访问它不应该访问的东西，并且必须对数据进行全面控制。归根结底，我们在现有应用程序和系统中的许多数据都隐藏在糟糕的API后面，或者与我们应用程序的模糊内部细节紧密相关。
当这个列的值为4时意味着什么？我不知道，但你可能需要查看代码库中的某个枚举才能真正理解它的含义。而且模型并不比人类更能直观地理解4的含义。对吧？归根结底，你必须拥有完整的上下文才能做出决策。因此，当你考虑利用这些数据时，你最终必须构建一个有用的数据集。你需要某种数据管道，从生产环境中提取数据，对其进行某种转换，将其构建成代理可能需要采取行动的适当上下文，并按需提供。
要知道，这归根结底是非常重要的模式。可能有些情况下你可以直接用MCP连接，但最常见的情况是处理这些上下文数据。这通常被称为上下文工程。这种从不同系统中提炼、处理数据，为在代理中使用做准备的想法。那么我们如何做到这一点呢？我们如何使其真正有效？如果掌握上下文数据是我们在人工智能领域取得成功的关键，我们该如何做到这一点？好吧，答案的明显起点是，我们如何在组织的其他地方构建这些数据管道？答案通常是批处理。
一个非常简单的起点是，你去数据仓库或数据湖仓，那里有一堆数据，构建一组处理步骤，为人工智能准备数据。作为我们分析流程的一部分，我们实际上在准备用于分析的数据方面相当成功。因此，我们会对数据进行大量丰富的处理以准备用于分析的数据。因此，我们可能最终会得到这样一种架构，在你的数据湖仓或仓库中运行一组迭代处理步骤。然后，你可能会将处理后的输出上传到某种实时服务数据库，以便代理可以进行实时查询。
这有什么问题呢？首先，有一些好处。我们在处理批处理数据方面实际上相当敏捷。我们可以相当迭代。因此，在某种意义上，我们已经解决了能够获取新数据、提炼数据、改进数据的问题。这种开发工作流实际上相当不错。但是当将其投入生产时，就变得有点困难了。首先，我们与实时服务系统的集成有些脆弱，我们一次上传大量的变更，希望不会搞垮那个系统。
任何构建过这种重新处理和索引管道的人都知道这可能有点不稳定。但这甚至不是大问题。最大的问题是这些数据是批处理的。最好的情况下，我们可能在四个小时后才知道事情的状态。更有可能是明天。对于为将要做出实时决策、作为业务一部分进行交互的系统提供上下文来说，这完全行不通。你会得到完全错误的答案。你可以用这样的类比：如果你要穿过一条繁忙的街道，如果你只能看到昨天汽车在哪里的照片，你愿意过马路吗？答案是否定的。
这将是非常危险的。但归根结底，如果你有某个软件系统要与你业务的当前实际状态进行交互，那么基于某个数据快照来做这件事，对于几乎所有重要的、有后果的用例来说都是不够好的。因此，你最终必须将其转变为实时的东西，即上下文数据是同步的东西。那么你如何做到这一点呢？我们在Current大会上，所以答案的一部分将是流式数据，对吧？这并不奇怪。
但这并不像“好吧，把所有东西都改成流处理”那么简单。你需要做一些事情才能提高效率。架构可以是这样的：你从Kafka捕获流数据，使用Flink之类的流处理工具进行流处理，然后以某种方式提供服务。但是要使这真正高效，我们需要做好几件事。首先，我谈到过迭代处理这些数据对我们的生产力至关重要，我们必须围绕它进行整个评估循环。
我说过，在数据湖仓中，批处理在开发方面确实有一些优势。我可以尝试不同的“原料”，提炼它们，改进它们。这种开发工作流实际上相当不错。但是当谈到将其投入生产时，就变得有点困难了。首先，我们与实时服务系统的集成有些脆弱，我们一次上传大量的变更，希望不会搞垮那个系统。
任何构建过这种重新处理和索引管道的人都知道这可能有点不稳定。但这甚至不是大问题。最大的问题是这些数据是批处理的。最好的情况下，我们可能在四个小时后才知道事情的状态。更有可能是明天。对于为将要做出实时决策、作为业务一部分进行交互的系统提供上下文来说，这完全行不通。你会得到完全错误的答案。你可以用这样的类比：如果你要穿过一条繁忙的街道，如果你只能看到昨天汽车在哪里的照片，你愿意过马路吗？答案是否定的。
这将是非常危险的。但归根结底，如果你有某个软件系统要与你业务的当前实际状态进行交互，那么基于某个数据快照来做这件事，对于几乎所有重要的、有后果的用例来说都是不够好的。因此，你最终必须将其转变为实时的东西，即上下文数据是同步的东西。那么你如何做到这一点呢？我们在Current大会上，所以答案的一部分将是流式数据，对吧？这并不奇怪。
但这并不像“好吧，把所有东西都改成流处理”那么简单。你需要做一些事情才能提高效率。架构可以是这样的：你从Kafka捕获流数据，使用Flink之类的流处理工具进行流处理，然后以某种方式提供服务。但是要使这真正高效，我们需要做好几件事。首先，我谈到过迭代处理这些数据对我们的生产力至关重要，我们必须围绕它进行整个评估循环。
我说过，在数据湖仓中，批处理在开发方面确实有一些优势。我可以尝试不同的“原料”，提炼它们，改进它们。这种开发工作流实际上相当不错。但是当谈到将其投入生产时，就变得有点困难了。首先，我们与实时服务系统的集成有些脆弱，我们一次上传大量的变更，希望不会搞垮那个系统。
任何构建过这种重新处理和索引管道的人都知道这可能有点不稳定。但这甚至不是大问题。最大的问题是这些数据是批处理的。最好的情况下，我们可能在四个小时后才知道事情的状态。更有可能是明天。对于为将要做出实时决策、作为业务一部分进行交互的系统提供上下文来说，这完全行不通。你会得到完全错误的答案。你可以用这样的类比：如果你要穿过一条繁忙的街道，如果你只能看到昨天汽车在哪里的照片，你愿意过马路吗？答案是否定的。
这将是非常危险的。但归根结底，如果你有某个软件系统要与你业务的当前实际状态进行交互，那么基于某个数据快照来做这件事，对于几乎所有重要的、有后果的用例来说都是不够好的。因此，你最终必须将其转变为实时的东西，即上下文数据是同步的东西。那么你如何做到这一点呢？我们在Current大会上，所以答案的一部分将是流式数据，对吧？这并不奇怪。
但这并不像“好吧，把所有东西都改成流处理”那么简单。你需要做一些事情才能提高效率。架构可以是这样的：你从Kafka捕获流数据，使用Flink之类的流处理工具进行流处理，然后以某种方式提供服务。但是要使这真正高效，我们需要做好几件事。首先，我谈到过迭代处理这些数据对我们的生产力至关重要，我们必须围绕它进行整个评估循环。
我说过，在数据湖仓中，批处理在开发方面确实有一些优势。我可以尝试不同的“原料”，提炼它们，改进它们。这种开发工作流实际上相当不错。但是当谈到将其投入生产时，就变得有点困难了。首先，我们与实时服务系统的集成有些脆弱，我们一次上传大量的变更，希望不会搞垮那个系统。
任何构建过这种重新处理和索引管道的人都知道这可能有点不稳定。但这甚至不是大问题。最大的问题是这些数据是批处理的。最好的情况下，我们可能在四个小时后才知道事情的状态。更有可能是明天。对于为将要做出实时决策、作为业务一部分进行交互的系统提供上下文来说，这完全行不通。你会得到完全错误的答案。你可以用这样的类比：如果你要穿过一条繁忙的街道，如果你只能看到昨天汽车在哪里的照片，你愿意过马路吗？答案是否定的。
这将是非常危险的。但归根结底，如果你有某个软件系统要与你业务的当前实际状态进行交互，那么基于某个数据快照来做这件事，对于几乎所有重要的、有后果的用例来说都是不够好的。因此，你最终必须将其转变为实时的东西，即上下文数据是同步的东西。那么你如何做到这一点呢？我们在Current大会上，所以答案的一部分将是流式数据，对吧？这并不奇怪。
但这并不像“好吧，把所有东西都改成流处理”那么简单。你需要做一些事情才能提高效率。架构可以是这样的：你从Kafka捕获流数据，使用Flink之类的流处理工具进行流处理，然后以某种方式提供服务。但是要使这真正高效，我们需要做好几件事。首先，我谈到过迭代处理这些数据对我们的生产力至关重要，我们必须围绕它进行整个评估循环。
我说过，在数据湖仓中，批处理在开发方面确实有一些优势。我可以尝试不同的“原料”，提炼它们，改进它们。这种开发工作流实际上相当不错。但是当谈到将其投入生产时，就变得有点困难了。首先，我们与实时服务系统的集成有些脆弱，我们一次上传大量的变更，希望不会搞垮那个系统。
任何构建过这种重新处理和索引管道的人都知道这可能有点不稳定。但这甚至不是大问题。最大的问题是这些数据是批处理的。最好的情况下，我们可能在四个小时后才知道事情的状态。更有可能是明天。对于为将要做出实时决策、作为业务一部分进行交互的系统提供上下文来说，这完全行不通。你会得到完全错误的答案。你可以用这样的类比：如果你要穿过一条繁忙的街道，如果你只能看到昨天汽车在哪里的照片，你愿意过马路吗？答案是否定的。
这将是非常危险的。但归根结底，如果你有某个软件系统要与你业务的当前实际状态进行交互，那么基于某个数据快照来做这件事，对于几乎所有重要的、有后果的用例来说都是不够好的。因此，你最终必须将其转变为实时的东西，即上下文数据是同步的东西。那么你如何做到这一点呢？我们在Current大会上，所以答案的一部分将是流式数据，对吧？这并不奇怪。
但这并不像“好吧，把所有东西都改成流处理”那么简单。你需要做一些事情才能提高效率。架构可以是这样的：你从Kafka捕获流数据，使用Flink之类的流处理工具进行流处理，然后以某种方式提供服务。但是要使这真正高效，我们需要做好几件事。首先，我谈到过迭代处理这些数据对我们的生产力至关重要，我们必须围绕它进行整个评估循环。
我说过，在数据湖仓中，批处理在开发方面确实有一些优势。我可以尝试不同的“原料”，提炼它们，改进它们。这种开发工作流实际上相当不错。但是当谈到将其投入生产时，就变得有点困难了。首先，我们与实时服务系统的集成有些脆弱，我们一次上传大量的变更，希望不会搞垮那个系统。
任何构建过这种重新处理和索引管道的人都知道这可能有点不稳定。但这甚至不是大问题。最大的问题是这些数据是批处理的。最好的情况下，我们可能在四个小时后才知道事情的状态。更有可能是明天。对于为将要做出实时决策、作为业务一部分进行交互的系统提供上下文来说，这完全行不通。你会得到完全错误的答案。你可以用这样的类比：如果你要穿过一条繁忙的街道，如果你只能看到昨天汽车在哪里的照片，你愿意过马路吗？答案是否定的。
这将是非常危险的。但归根结底，如果你有某个软件系统要与你业务的当前实际状态进行交互，那么基于某个数据快照来做这件事，对于几乎所有重要的、有后果的用例来说都是不够好的。因此，你最终必须将其转变为实时的东西，即上下文数据是同步的东西。那么你如何做到这一点呢？我们在Current大会上，所以答案的一部分将是流式数据，对吧？这并不奇怪。
但这并不像“好吧，把所有东西都改成流处理”那么简单。你需要做一些事情才能提高效率。架构可以是这样的：你从Kafka捕获流数据，使用Flink之类的流处理工具进行流处理，然后以某种方式提供服务。但是要使这真正高效，我们需要做好几件事。首先，我谈到过迭代处理这些数据对我们的生产力至关重要，我们必须围绕它进行整个评估循环。
我说过，在数据湖仓中，批处理在开发方面确实有一些优势。我可以尝试不同的“原料”，提炼它们，改进它们。这种开发工作流实际上相当不错。但是当谈到将其投入生产时，就变得有点困难了。首先，我们与实时服务系统的集成有些脆弱，我们一次上传大量的变更，希望不会搞垮那个系统。
任何构建过这种重新处理和索引管道的人都知道这可能有点不稳定。但这甚至不是大问题。最大的问题是这些数据是批处理的。最好的情况下，我们可能在四个小时后才知道事情的状态。更有可能是明天。对于为将要做出实时决策、作为业务一部分进行交互的系统提供上下文来说，这完全行不通。你会得到完全错误的答案。你可以用这样的类比：如果你要穿过一条繁忙的街道，如果你只能看到昨天汽车在哪里的照片，你愿意过马路吗？答案是否定的。
这将是非常危险的。但归根结底，如果你有某个软件系统要与你业务的当前实际状态进行交互，那么基于某个数据快照来做这件事，对于几乎所有重要的、有后果的用例来说都是不够好的。因此，你最终必须将其转变为实时的东西，即上下文数据是同步的东西。那么你如何做到这一点呢？我们在Current大会上，所以答案的一部分将是流式数据，对吧？这并不奇怪。
但这并不像“好吧，把所有东西都改成流处理”那么简单。你需要做一些事情才能提高效率。架构可以是这样的：你从Kafka捕获流数据，使用Flink之类的流处理工具进行流处理，然后以某种方式提供服务。但是要使这真正高效，我们需要做好几件事。首先，我谈到过迭代处理这些数据对我们的生产力至关重要，我们必须围绕它进行整个评估循环。
我说过，在数据湖仓中，批处理在开发方面确实有一些优势。我可以尝试不同的“原料”，提炼它们，改进它们。这种开发工作流实际上相当不错。但是当谈到将其投入生产时，就变得有点困难了。首先，我们与实时服务系统的集成有些脆弱，我们一次上传大量的变更，希望不会搞垮那个系统。
任何构建过这种重新处理和索引管道的人都知道这可能有点不稳定。但这甚至不是大问题。最大的问题是这些数据是批处理的。最好的情况下，我们可能在四个小时后才知道事情的状态。更有可能是明天。对于为将要做出实时决策、作为业务一部分进行交互的系统提供上下文来说，这完全行不通。你会得到完全错误的答案。你可以用这样的类比：如果你要穿过一条繁忙的街道，如果你只能看到昨天汽车在哪里的照片，你愿意过马路吗？答案是否定的。
这将是非常危险的。但归根结底，如果你有某个软件系统要与你业务的当前实际状态进行交互，那么基于某个数据快照来做这件事，对于几乎所有重要的、有后果的用例来说都是不够好的。因此，你最终必须将其转变为实时的东西，即上下文数据是同步的东西。那么你如何做到这一点呢？我们在Current大会上，所以答案的一部分将是流式数据，对吧？这并不奇怪。
但这并不像“好吧，把所有东西都改成流处理”那么简单。你需要做一些事情才能提高效率。架构可以是这样的：你从Kafka捕获流数据，使用Flink之类的流处理工具进行流处理，然后以某种方式提供服务。但是要使这真正高效，我们需要做好几件事。首先，我谈到过迭代处理这些数据对我们的生产力至关重要，我们必须围绕它进行整个评估循环。
我说过，在数据湖仓中，批处理在开发方面确实有一些优势。我可以尝试不同的“原料”，提炼它们，改进它们。这种开发工作流实际上相当不错。但是当谈到将其投入生产时，就变得有点困难了。首先，我们与实时服务系统的集成有些脆弱，我们一次上传大量的变更，希望不会搞垮那个系统。
任何构建过这种重新处理和索引管道的人都知道这可能有点不稳定。但这甚至不是大问题。最大的问题是这些数据是批处理的。最好的情况下，我们可能在四个小时后才知道事情的状态。更有可能是明天。对于为将要做出实时决策、作为业务一部分进行交互的系统提供上下文来说，这完全行不通。你会得到完全错误的答案。你可以用这样的类比：如果你要穿过一条繁忙的街道，如果你只能看到昨天汽车在哪里的照片，你愿意过马路吗？答案是否定的。
这将是非常危险的。但归根结底，如果你有某个软件系统要与你业务的当前实际状态进行交互，那么基于某个数据快照来做这件事，对于几乎所有重要的、有后果的用例来说都是不够好的。因此，你最终必须将其转变为实时的东西，即上下文数据是同步的东西。那么你如何做到这一点呢？我们在Current大会上，所以答案的一部分将是流式数据，对吧？这并不奇怪。
但这并不像“好吧，把所有东西都改成流处理”那么简单。你需要做一些事情才能提高效率。架构可以是这样的：你从Kafka捕获流数据，使用Flink之类的流处理工具进行流处理，然后以某种方式提供服务。但是要使这真正高效，我们需要做好几件事。首先，我谈到过迭代处理这些数据对我们的生产力至关重要，我们必须围绕它进行整个评估循环。
我说过，在数据湖仓中，批处理在开发方面确实有一些优势。我可以尝试不同的“原料”，提炼它们，改进它们。这种开发工作流实际上相当不错。但是当谈到将其投入生产时，就变得有点困难了。首先，我们与实时服务系统的集成有些脆弱，我们一次上传大量的变更，希望不会搞垮那个系统。
任何构建过这种重新处理和索引管道的人都知道这可能有点不稳定。但这甚至不是大问题。最大的问题是这些数据是批处理的。最好的情况下，我们可能在四个小时后才知道事情的状态。更有可能是明天。对于为将要做出实时决策、作为业务一部分进行交互的系统提供上下文来说，这完全行不通。你会得到完全错误的答案。你可以用这样的类比：如果你要穿过一条繁忙的街道，如果你只能看到昨天汽车在哪里的照片，你愿意过马路吗？答案是否定的。
这将是非常危险的。但归根结底，如果你有某个软件系统要与你业务的当前实际状态进行交互，那么基于某个数据快照来做这件事，对于几乎所有重要的、有后果的用例来说都是不够好的。因此，你最终必须将其转变为实时的东西，即上下文数据是同步的东西。那么你如何做到这一点呢？我们在Current大会上，所以答案的一部分将是流式数据，对吧？这并不奇怪。
但这并不像“好吧”那么简单。