a16z对话27岁华人CEO：AI Agent具有极大的杠杆效应

Z Highlights

• LLMs的魔力在于，它们非常灵活，可以适应许多不同的情境，并且拥有基本的智能。

• 我们认为，随着时间的推移，UI和UX将变得越来越自然语言化，因为这就是Agent系统的思维方式，或者说这基本上是大语言模型（LLMs）训练的基础。

• 如果你要让某人接受AI Agent，他们实际上是在进行某种程度的“信任飞跃”，因为对很多人来说，这是一个非常陌生的领域。

AI Agent重塑客户体验

Jesse Zhang：如何实际构建一个Agent？我们的观点是，随着时间的推移，它将越来越像基于自然语言的Agent，因为这就是大语言模型（LLMs）训练的方式。

从长远来看，如果你拥有一个超级智能的Agent，它实际上就像一个人类一样，你可以向它展示东西，向它解释，给它反馈，它会在脑海中更新信息。

你可以想象有一个非常能干的人类团队成员，他们刚加入时，你教他们一些东西，他们开始工作，然后你给他们反馈，并向他们展示新的资料。

最终，它会朝这个方向发展——变得更加对话化，更加基于自然语言，人与人之间的交流方式将变得更自然。而且人们不再使用那些复杂的决策树来捕捉需求，这种决策树虽然可以起作用，但容易崩溃。

过去我们不得不这样做，因为我们没有大语言模型。但现在，随着Agent的不断进步，用户体验（UX）和用户界面（UI）将变得更加对话化。

Derrick Harris：大家好，欢迎收听A16z AI播客。我是Derrick Harris，今天的节目中，我将与Decagon的联合创始人兼首席执行官Jesse Zhang以及a16z的合伙人Kimberly Tan一起讨论。Kimberly将主持讨论，Jesse将分享他在构建Decagon公司及其产品方面的经验。

如果你不太了解，Decagon是一家为企业提供AI Agent以协助客户支持的初创公司。这些Agent既不是聊天机器人，也不是单一API调用的LLM封装，而是经过高度定制的先进Agent，能够根据公司的具体需求处理复杂的工作流程。

除了解释为什么他们创建Decagon以及它是如何架构以处理不同的LLM和客户环境之外，Jesse还谈到了按每次对话收费的商业模式的好处，以及AI Agent将如何改变客户支持负责人所需的技能。

还值得一提的是，Kimberly最近写了一篇博客文章，标题是《RIP to RPA, The Rise of Intelligent Automation》，我们在本期节目中也简要讨论了这篇文章。

这篇文章是了解自动化在商业流程中如何起飞的一个很好的起点，我们将在节目说明中提供链接。最后提醒一下，本文内容仅供参考，不应被视为法律、商业、税务或投资建议，也不应用于评估任何投资或证券，且不针对任何a16z基金的投资者或潜在投资者。

Jesse Zhang：简要介绍一下我自己。我出生并成长在博尔德，从小参加了很多数学竞赛之类的活动。在哈佛学习计算机科学，之后创办了一家公司，也得到了a16z的支持。我们最终被Niantic收购。

然后我们开始打造Decagon。我们的业务是为客户服务构建AI Agent。最开始，我们做这件事，是因为我们希望做一些对我们自己来说非常贴近的事情。

当然，大家都不需要被教导AI Agent在客户服务中的作用，对吧？我们都曾经在与航空公司、酒店等的电话中等待过。所以这个想法就从这里产生了。

我们与很多客户进行了交流，具体了解应该构建什么样的产品。对我们来说，特别突出的一个点是，随着我们对AI Agent的了解加深，我们开始思考未来当有很多AI Agent时，情况会是怎样。我认为每个人都相信未来会有很多AI Agent。

对我们来说，值得思考的是，那些围绕 AI 代理工作的员工会做些什么？他们会有什么样的工具？他们会如何控制或查看与他们合作或管理的Agent？

所以这就是我们围绕这个问题来构建公司的核心。我认为，这也是我们目前与众不同的地方，因为我们为这些AI Agent提供了各种工具，帮助我们合作的人员构建、配置这些Agent，让它们不再是一个“黑箱”。这就是我们打造品牌的方式。

Derrick Harris：是什么激发了你的灵感，因为你上一家公司是一个面向消费者的视频公司，是什么促使你转向企业软件领域的？

Jesse Zhang：很好的问题。我认为，在选择话题时，创始人通常会比较“话题无关”，因为实际上，当你接触到一个新领域时，你通常是比较天真的。因此，从一个全新的视角看待事物有其优势。所以当我们在构思时，几乎没有什么话题是限制的。

我认为，对于更多量化背景的人来说，这是一个很常见的模式，包括我自己。试过了消费产品之后，你会更多地倾向于企业软件，因为企业软件的问题更具体。

你有实际的客户，他们有实际的需求和预算之类的东西，你可以针对这些进行优化并解决问题。而消费者市场虽然也很有吸引力，但它更多是基于直觉的，而不是通过实验来推动。对我个人而言，企业软件更适合我。

Kimberly Tan：首先，我们可以从这个问题开始，Decagon今天处理的最常见的支持类别是什么？能否详细讲一下你们是如何利用大语言模型（LLMs）来解决这些问题的，以及现在可能做得到的，而以前做不到的事情？

Jesse Zhang：如果你回顾一下之前的自动化，你可能会使用决策树来做一些简单的事情，确定要走哪条路径。但我们都用过聊天机器人，那是相当让人沮丧的体验。

通常你的问题无法通过决策树完全解决。所以你最终会被引导走一条与问题相关，但并不完全符合的问题路径。现在，我们有了大语言模型（LLMs）。LLMs的魔力在于，它们非常灵活，可以适应许多不同的情境，并且拥有基本的智能。

当你将这一点应用于客户支持时，或者说客户提问时，你就能够提供更个性化的服务。这是第一点，个性化的程度大大提升。这就解锁了更高的指标。你能够解决更多的问题，客户更满意，客户满意度提高。

接下来的自然步骤是：如果你有了这种智能，你应该能够做更多人类能够做的事情。人类能做的事情是，他们可以实时拉取数据，可以采取行动，可以通过多个步骤进行推理。如果客户提出一个相对复杂的问题，可能是“我想做这个和那个”，而AI只准备好处理第一个问题。LLM足够智能，能够识别出这里有两个问题。首先，它会解决第一个问题，然后帮助你解决第二个问题。

在LLM出现之前，这基本上是不可能做到的。所以我们现在看到，技术在能够做的事情上有了一个阶跃式的提升，这就是因为LLM的出现。

Kimberly Tan：在这个背景下，你是如何定义AI Agent的？因为“Agent”这个词被广泛使用，我很好奇在Decagon的上下文中，它究竟意味着什么？

Jesse Zhang：我会说，Agent更多是指多个LLM（大语言模型）系统协同工作的一个系统。你有一个LLM调用，基本上是通过发送一个提示，然后得到一个回应。对于一个Agent来说，你希望能够将多个这样的调用连接起来，甚至可能是递归的。

比如说，你有一个LLM调用，它决定如何处理这个消息，然后它可能引发其他调用，这些调用会拉取更多的数据，执行行动，并迭代用户所说的内容，甚至可能提出后续问题。所以对我们来说，Agent可以理解为它几乎是一个LLM调用、API调用或者其他逻辑的网络，它们共同工作以提供更好的体验。

Kimberly Tan：在这个话题上，或许我们可以多谈谈你们实际构建的Agent基础设施。我觉得有一个非常有趣的点是，市面上有很多关于AI Agent的演示，但我认为很少有真正能够在生产环境中稳定运行的例子。而且从外部很难知道，什么是真实的，什么不是。

所以在你看来，今天的AI Agent在哪些方面做得很好，而在哪些方面仍然需要技术突破才能让它们变得更加稳健和可靠？

Jesse Zhang：我的看法实际上有些不同，判断一个AI Agent是仅仅是一个演示，还是“真正工作”的区别，并不完全在于技术栈，因为我认为大多数人可能使用的是大致相同的技术。我认为一旦你在公司发展的过程中走得更远，比如像我们公司已经成立了一年多，你就会创造出一些非常具体的、符合你用例的东西。

但归根结底，大家都可以访问相同的模型，也能使用相似的技术。我认为一个AI Agent能否有效工作的最大区分因素，其实在于用例的形态。一开始很难知道这一点，但回过头来看，你会发现有两个属性对一个AI Agent能够超越演示，进入实际应用非常重要。

第一个是你解决的用例，ROI（投资回报率）必须是可以量化的。这非常重要，因为如果ROI无法量化，那么就很难说服人们真正使用你的产品并为此付费。以我们为例，量化的指标就是：你解决了多少比例的支持请求？因为这个数字是明确的，人们就能理解——哦，好吧，如果你解决得更多，我可以将这个结果和我目前的支出、花费的时间进行对比。所以，如果有了这个指标，另一个对我们来说非常重要的指标是客户满意度。因为能够轻松量化ROI，人们才会真正去采纳它。

第二个因素是，用例必须是逐步递增的。如果你需要一个Agent在一开始就能达到超人水平，解决几乎100%的用例，那也非常困难。因为正如我们所知道的，LLMs是非确定性的，你必须有某种应急方案。幸运的是，支持用例有一个很好的特点，那就是你总是可以将问题升级给人工客服。即使你只能解决一半的问题，对人们来说，这也是非常有价值的。

所以我认为，支持这个用例具有这样一个特点，使得它非常适合AI Agent。我认为还有很多其他领域，人们可以创建令人印象深刻的演示，你甚至不需要仔细看，就能理解为什么AI Agent会有用。但如果需要一开始就完美无缺，那就很困难了。如果是这种情况，几乎没有人愿意尝试或使用它，因为它不完美的后果可能非常严重——比如安全问题。

比如说，人们做模拟时，总会有这样的经典想法：“哦，如果LLMs能读取这个就太好了。”但很难想象有人会说：“好吧，AI Agent，去做吧。我相信你能做到。”因为如果它犯一个错误，后果可能非常严重。

Jesse Zhang：这个通常由我们的客户来决定，实际上我们看到差异性非常大。在一个极端的情况下，有些人真的会让他们的Agent看起来像人类，因此会有一个人类头像、一个人类名字，回应也很自然。另一方面，Agent则直接表明自己是AI，明确告诉用户这一点。我认为我们合作的不同公司对此有不同的立场。

通常情况下，如果你处在一个受监管的行业，你必须明确说明这一点。我觉得现在很有意思的是，客户的行为正在发生变化。因为我们的许多客户收到了大量社交媒体的反馈，比如“天哪，这是我试过的第一个聊天体验，竟然感觉如此真实”或者“这简直是魔法”。这对他们来说非常好，因为现在他们的客户也在学到，嘿，如果是AI体验，实际上可能比人类更好。过去并不是这样的，因为过去我们大多数人都经历过那种电话客服体验：“好吧，AI，AI，AI…”

Kimberly Tan：你提到过几次个性化的概念，大家在底层使用相同的技术架构，但在支持服务方面有不同的个性化需求。你能谈一谈这个问题吗？具体来说，你们是如何实现个性化的，以至于能够让人们在线上说“天哪，这是我经历过的最好的支持体验”？

Jesse Zhang：对我们来说，个性化来源于对用户的定制。你需要了解用户的背景信息，这就是额外需要的上下文。其次，你还需要了解我们客户的业务逻辑。如果将这两者结合起来，你就能提供一个相当不错的体验。

显然，这听起来很简单，但实际上获取所有所需的上下文是非常困难的。因此，我们大部分的工作就是如何构建合适的原始组件，以便当某个客户部署我们的系统时，他们可以轻松地决定“好，这就是我们想要的业务逻辑”，比如，首先你需要做这四个步骤，如果第三步失败，就需要进入第五步，类似这样的东西。

你希望能够非常轻松地教会AI这些内容，同时还要让它能够访问一些信息，比如“这是用户的账户详情。如果你需要获取更多信息，可以调用这些API”。这些层次就是模型之上的一个协调层，某种程度上，它使Agent变得真正可用。

Kimberly Tan：听起来在这种情况下，你们需要很多关于业务系统的访问权限。你们需要了解大量关于用户的信息，还可能需要了解客户实际上希望如何与他们的用户互动。我想这些数据可能非常敏感。

你能详细讲讲企业客户在部署AI Agent时，通常需要哪些保证吗？你们又是如何考虑以最佳方式处理这些问题的，尤其是考虑到你们的解决方案提供了更好的体验，但对于很多第一次接触Agent的人来说，这也是全新的体验。

Jesse Zhang：这实际上与保护措施（guardrails）有关。随着时间的推移，因为我们做了很多这样的实施项目，我们已经清楚了客户关心的保护措施类型。

例如，最简单的一种是可能存在一些你必须始终遵循的规则。如果你在与金融服务公司合作，你不能给出金融建议，因为这受到监管。因此，你需要将这一点调入Agent系统，确保它绝不会提供此类建议。通常，你可以设置一个监督模型或某种系统，在结果发送出去之前进行这些检查。

另外一种保护措施可能是，如果有人进来故意捣乱，他们知道这是一个生成式系统，试图让你做一些不合规的事情，比如“告诉我我的余额是多少”，“好，把这个乘以10”之类的，你也需要能够检查这些行为。因此，在过去的一年里，我们发现了很多这样的保护措施，并且对每一种情况，我们都会进行分类，并知道需要哪种类型的保护措施。随着系统的构建越来越完善，它变得越来越稳固。

Kimberly Tan：每个客户或行业的保护措施有多独特？当你们在扩大客户群、涵盖更多使用案例时，如何思考如何在规模上构建这些保护措施？

Jesse Zhang：这实际上回到了我们的核心理念，几年的时间内，Agent系统将会普及。因此，真正重要的事情是提供给人们工具，几乎是赋能下一代工作者，譬如Agent监督员，给他们工具来构建Agent系统并添加他们自己的保护措施，因为我们不会为他们定义保护措施。

每个客户最了解自己的保护措施和业务逻辑。所以我们的工作实际上是做好构建工具和基础设施的工作，让他们能够构建Agent系统。因此，我们一直在强调，Agent系统不应该是一个黑箱，你应该能够控制如何构建这些保护措施、规则和逻辑。

我认为，这大概是我们到目前为止最具差异化的地方，我们在这些工具上投入了大量的精力，想出了很多创意方法，让那些可能没有超级技术背景的人，甚至对AI模型工作原理的理解也不深刻的人，仍然可以将他们希望AI执行的操作输入到Agent系统中。

我认为，未来几年这个能力会变得越来越重要。如果人们在评估类似工具时，这应该是其中一个最重要的标准之一，因为你希望随着时间的推移，你能够不断优化和改进这些系统。

自然语言驱动的业务逻辑

Derrick Harris：客户或企业可以做些什么准备工作，为任何类型的自动化，尤其是这种Agent系统的使用做好准备？比如如何设计他们的数据系统、软件架构或业务逻辑，以便能够支持这种系统？

因为我感觉很多AI技术一开始是很新颖的，但当进入现有的遗留系统时，常常会遇到很多乱七八糟的情况。

Jesse Zhang：如果有人现在从零开始构建的话，有很多最佳实践可以让你的工作变得更轻松。比如说，如何构建你的知识库。我们曾写过一些相关内容，介绍了一些方法，能够让AI更容易地摄取信息，并提高其准确性。其中一个具体建议是，将知识库划分为模块化的部分，而不是用一大篇文章包含多个答案。

在设置API时，可以使它们更适合Agent系统，并以一种方式设置权限和输出，使得Agent系统能够轻松地摄取信息，而不需要进行大量计算来寻找答案。这些是一些可以采取的战术性措施，但我不会说有什么是必须做的，才能使用Agent系统。

Derrick Harris：良好的文档总是很重要的，本质上就是在有效组织信息。

Kimberly Tan：听起来，如果你们试图教人们如何引导Agent系统以最符合其客户或具体用例的方式进行操作，那么在UI和UX的设计上可能需要大量的实验，或者说是要在这个全新的领域开辟新天地，因为这和传统软件非常不同。

我很好奇，你们是如何思考这个问题的？在Agent优先的世界中，UI和UX应该是什么样的？你们认为未来几年它会如何变化？

Jesse Zhang：我不会说我们已经解决了这个问题。我认为我们可能找到了一个适合当前客户的局部最优解，但这仍然是一个持续的研究领域，对我们和许多其他人来说都是如此。

核心问题回到我们之前提到的，就是你有一个Agent系统。首先，如何能清楚看到它正在做什么，它是如何做决策的？然后，如何利用这些信息来决定需要更新什么，以及应该给AI什么反馈。这些就是UI元素汇聚的地方，尤其是第二部分。

我们认为，随着时间的推移，UI和UX将变得越来越自然语言化，因为这就是Agent系统的思维方式，或者说这基本上是大语言模型（LLMs）训练的基础。

从极限角度看，如果你有一个超智能的Agent，它基本上就像一个人一样，你可以向它展示东西，向它解释，给它反馈，它就会在自己的“脑海”中更新。你可以想象一下有一个非常能干的人加入你的团队，你教给他一些东西，他开始工作，然后你不断给他反馈，可以向他展示新的东西，新的文档、图表等等。

我认为在极限情况下，它会朝着这个方向发展：事情变得更加对话化，变得更加基于自然语言，人们不再像过去那样用复杂的决策树来构建系统，捕捉你想要的东西，但这种方法很容易崩溃。我们过去不得不这样做，因为那时没有LLMs，但现在随着Agent系统越来越强大，UI和UX将变得更加对话化。

Kimberly Tan：大约一年多前，也就是Decagon刚开始的时候，人们普遍认为，LLM非常适用的很多用例，实际上也只是一些所谓的“GPT封装器”，即公司只需要通过一个API调用一个基础模型，就能立即解决他们的支持问题。

但显然，随着公司选择使用像Decagon这样的解决方案，而不是直接采用那种方式，事实证明情况并非如此。我想知道你能否解释一下，为什么情况会这样？究竟是什么让人们在内部构建时遇到的挑战比预期的更复杂？他们对这个概念理解有何误区？

Jesse Zhang：作为“GPT封装器”并没有错，你可以说Purcell就是一个AWS封装器之类的。通常，当人们使用这个术语时，意味着贬义的意思。

我个人的看法是，我认为如果你正在构建一个Agent系统，按定义，你肯定会利用LLMs作为工具。所以你实际上是基于现有的东西来构建，就像你通常基于AWS或GCP来构建一样。

但真正遇到麻烦的地方是，如果你在LLM上构建的软件不够“厚重”或不够复杂，以至于没有让人感觉到存在差异化，那就会有问题。

对我们来说，回顾一下，我们卖的东西基本上是软件。我们其实就像一个普通的软件公司，只不过我们把LLMs作为软件的一部分和工具之一来使用。但当人们购买这种产品时，他们主要是想要软件本身。他们想要能够监控AI的工具，想要能够深入挖掘AI每一场对话的细节，想要能够给反馈，能够不断构建和调整系统。

所以，这就是我们的软件的核心内容。即使是Agent系统本身，人们遇到的问题是，做一个演示很酷，但如果要把它变得适合生产并真正面向客户，你就得解决很多长期存在的问题，比如防止“幻觉”现象、应对那些试图搞破坏的不良行为者。我们还得确保延迟足够低，语气合适等等。

我们和很多团队谈过，他们做了一些实验，构建了初步版本，然后他们会发现：“哦，确实，我们不想成为那些在后期不断构建这些细节的人。”他们也不想成为不断为客户服务团队添加新逻辑的人。所以，这时候，选择和别人合作似乎更合适。

Kimberly Tan：你提到了一些长期存在的问题，比如需要应对不良行为者等等。我相信很多听众在考虑使用AI Agent时，都会担心引入LLMs后会出现新的安全攻击路径，或者引入Agent系统后可能带来新的安全风险。你们是如何看待这些问题的？以及在处理Agent时，确保依然具备顶级企业安全的最佳实践是什么？

Jesse Zhang：在安全方面，有一些显而易见的措施可以采取，这些我之前提到过，比如你需要有保护措施。核心问题是，人们对LLMs的担忧是它们不是确定性的。

但好消息是，你实际上可以将大部分的敏感和复杂操作放在一个确定性的墙后面，当它调用API时，计算就在那发生。所以你并不会完全依赖LLM来处理，这样就能避免很多核心问题。

但是，依然会有一些情况，比如，不良行为者的干扰或者有人试图让系统产生幻觉等。我们观察到，在很多我们合作的大客户中，他们的安全团队会进入，基本上就是对我们的产品进行“红队”测试，花几周时间不断地向系统发起各种可能的攻击，试图找出漏洞。随着AI Agent变得越来越普及，我们可能会看到这种情况越来越多，因为这是测试系统是否有效的最佳方法之一，就是通过红队测试，给它丢一些东西，看看能否突破防线。

现在也有一些初创公司在开发红队工具，或者让人们能够自己进行这类测试，这也是我们目前看到的一种趋势。很多我们合作的公司，在销售周期的后期阶段，他们会让自己的安全团队，或者是与外部团队合作，对系统进行压力测试。对于我们来说，能够通过这样的测试是必须的。所以，最终归结起来就是这样。

Derrick Harris：这是你们鼓励客户做的吗？因为在我们讨论AI政策时，我们提到过一个重要的方面，就是应用层，强调将责任放在LLM的使用者和运行应用的人身上，而不是单纯把责任归咎于模型本身。就是说，客户应该进行红队测试，识别具体的用例和攻击路径，确定哪些漏洞需要保护，而不是仅仅依赖OpenAI或其他公司已经设置好的安全防护。

Jesse Zhang：完全赞同。我还认为，可能会有一波新的通知需求出现，类似于现在大家都在做SOC 2认证、HIPAA认证之类的，不同行业都有要求。通常，当你销售普通的SaaS产品时，客户会要求渗透测试，我们也必须提供我们的渗透测试报告。对于AI Agent来说，未来可能会有类似的需求，可能会有人为其命名，但这基本上是测试Agent系统是否足够强大的新方式。

Kimberly Tan：有一件事很有趣，显然大家对所有大型实验室推出的新模型突破和技术突破都非常兴奋。作为一家应用AI公司，你们显然没有自己做研究，而是利用这些研究并围绕它构建大量软件，以便交付给最终客户。

但你们的工作建立在迅速变化的技术基础之上，我很好奇，作为一家应用AI公司，你们是如何在能够预测自己的产品路线图、构建用户需求的同时，又能保持对新技术变化的关注，并理解它们如何影响公司的？更广泛来说，面对类似情况的应用AI公司，应该采取什么样的战略？

Jesse Zhang：其实你可以把整个堆栈分成不同的部分。比如LLMs，如果从应用层来看，LLMs就位于底层。你可能会有一些工具位于中间，帮助你管理LLMs，或者做一些评估之类的工作。然后，最上层的部分基本上就是我们构建的，实际上它也像标准的SaaS一样。

所以，我们的大部分工作其实跟普通软件没太大区别，除了我们有一个额外的研究组件——LLMs变化太快了。我们需要研究它们能做什么，它们擅长什么，应该用哪个模型来执行某个任务。这是一个很大的问题，因为OpenAI和Anthropic都在推出新技术，Gemini也在逐渐进步。

因此，你必须有自己的评估机制，了解哪个模型适合在哪种情况下使用。有时候你还需要进行微调，但问题是：何时进行微调？什么时候微调才是值得的？这些大概是我们主要关注的与LLMs相关的研究问题。但至少到目前为止，我们并没有感到SaaS在快速变化，因为我们现在并不依赖于中间层。所以，基本上是LLMs在发生变化。它们变化的频率并不高，即使发生变化，通常也是一次升级。比如Claude 3.5 sonnet几个月前更新了一次，那时我们就想：“好吧，我们要不要换成新的模型而不是继续用旧的？”

我们只需要运行一系列的评估，一旦换成了新的模型，就不再去想它了，因为你已经在使用新模型了。然后，o1版本出来了，情况也是类似的，想想它能用在哪些方面。在我们的案例中，o1对大多数面向客户的使用场景来说有点慢，所以我们可以把它用于一些后台工作。归根结底，我们只需要有好的系统来做模型的研究。

Kimberly Tan：你们多久评估一次新的模型，决定是否更换？

Jesse Zhang：每次有新模型出来时，我们都会评估。你必须确保即使新的模型更智能，也不会破坏你已经建立的某些用例。这是有可能发生的。比如，新的模型整体上可能更智能，但在某些极端情况下，它在你某个工作流程中的A/B选择上表现不佳。这就是我们进行评估的目的。

我认为总的来说，我们最关心的智能类型，应该是我所说的“指令跟随能力”，我们希望模型能够越来越擅长执行指令。如果是这种情况，那对我们来说是绝对有利的，非常好。

看起来最近的研究更多集中在推理类型的智能上，比如更好地进行编程、更好地进行数学运算等。这对我们也有帮助，但没有指令跟随能力的提升那么重要。

Kimberly Tan：你提到的一个非常有趣的点，我也认为对于Decagon来说非常独特，那就是你们在内部建立了大量的评估基础设施，以确保你们确切知道每个模型在你们提供的一组测试下的表现。

你能详细讲讲这个吗？这个内部评估基础设施有多重要，具体是如何让你们和你们的客户都对Agent的表现充满信心的？因为其中一些评估也是面向客户的。

Jesse Zhang：我认为这非常重要，因为如果没有这些评估基础设施，我们很难快速迭代。

如果你觉得每次更改都有很大可能性会破坏某些东西，那么你就不会快速做出改变。但是，如果你有了评估机制，那么，当有大的变化、模型更新或者有新的东西出现时，你可以直接将它与所有的评估测试对比。如果评估结果良好，你就可以感觉到：好，我们做出了改进，或者可以放心发布而不必太担心了。

所以，在我们的领域，评估需要客户的输入，因为客户才是决定某些东西是否正确的人。当然，我们可以检查一些高层次的问题，但通常是客户提供具体的用例，并告诉我们正确的答案是什么，或者它必须怎样，必须保持什么样的语气，必须说什么。

评估就是基于这些来进行的。所以，我们必须确保我们的评估系统足够稳健。最开始我们是自己构建的，它的维护并没有那么困难。我们也知道有一些评估公司，曾经探索过其中一些，也许在某个时刻，我们会考虑是否采用它们，但目前来说，评估系统已经不再是我们的痛点。

Kimberly Tan：今天一个很流行的话题是多模态，意思是AI Agent应该能够跨越所有人类今天使用的形式进行互动，不论是文本、视频、语音等。我知道Decagon最初是以文本为主的。从你的角度来看，多模态对AI Agent有多重要？你认为它成为主流甚至是标准的时间框架是什么时候？

Jesse Zhang：它很重要，从公司的角度来看，添加一种新的模态并不是特别困难。虽然并不简单，但核心是：如果你解决了其他问题，比如我提到的那些——例如构建AI、监控它并且有适当的逻辑，那么添加一种新的模态并不是最难的事情。因此，对我们来说，拥有所有模态是非常有意义的，它能扩展我们的市场。我们基本上是模态不可知的，我们为每种模态都构建了自己的Agent。

一般来说，限制因素有两个：第一，客户是否准备好采用新模态？我认为从文本开始非常有意义，因为这是人们最积极采纳的方式，而且对于他们来说风险较低，容易监控，也更容易理解。另一个大模态是语音。显然，我认为市场中仍然有空间，用户对语音的接受度还需要提高。目前，我们看到一些早期的尝试者已经开始采用语音Agent，这很令人兴奋。另外一方面是技术上的挑战。大多数人都会同意，语音的标准更高。如果你和某人在电话中交谈，你需要语音延迟非常短。如果你打断对方，他们需要自然地回应。

由于语音的延迟更低，你必须在计算方式上更加巧妙。如果你是在聊天中，回应时间是五到八秒，你几乎不会注意到，感觉非常自然。但是如果在电话中，回应时间也需要五到八秒，那么就会显得有点不自然了。因此，语音的技术挑战会更多。随着这些技术挑战的解决，以及市场对于采用语音的兴趣增加，语音作为一种新模态才会变得主流。

飞跃信任的商业模式

Kimberly Tan：在我们继续之前，我想再谈一下AI Agent的商业模式。在你们第一次构建AI Agent或与客户讨论他们使用的系统、处理的数据和他们的顾虑时，有没有什么让你感到意外的事情？有哪些非直观的或者令人惊讶的事情是Decagon为了更好地服务企业客户所必须做的？

Jesse Zhang：我认为最令人惊讶的是，当我们刚开始时，人们愿意和我们聊的程度。毕竟我们当时只是两个人。我们俩之前都创办过公司，所以认识了很多人，但即便如此，对于每一个创业者来说，想要获得引荐对话时，如果你说的内容并不特别吸引人，那对话通常都比较冷淡。

但当我们开始谈论这个用例时，实际上我觉得挺令人惊讶的，人们对于谈论这个话题的兴奋程度。因为这个想法看起来是如此显而易见。你可能会想，既然这是一个显而易见的想法，应该已经有别人做了，或者已经有解决方案，或者别人已经想出了某种解决方案。但我认为我们赶上了一个好时机，那个用例确实很大，大家真的很关心。正如我之前提到的，那个用例非常适合采用AI Agent并将其推向生产环境，因为你可以逐步实施，能够追踪投资回报率。

这让我感到很惊喜，但显然，在此之后还有很多工作要做，你必须与客户合作，必须建立产品，必须弄清楚该走哪条路。在最初的阶段，这确实是一个令人惊讶的发现。

Derrick Harris：Kimberly，我觉得我应该提到你写的那篇《RIP to RPA》的博文，里面涉及了很多自动化任务和创业公司的内容。你认为在这些自动化任务中，或者说解决方案没有那么理想，所以大家总是在寻找更好的方法，是否有这样的现象呢？

Kimberly Tan：是的我确实这么认为。我想说几件事。首先，如果一个想法对大家来说显而易见，但没有明确的公司来解决它，或者没有人指着某个公司说“你应该用这个”，那么这意味着这个问题实际上没有得到解决。

从某种意义上说，它是一个完全开放的机会，适合公司去开发解决方案。因为，正如你所说，我们从一开始就作为投资者关注Decagon。我们看着他们走过了创意迷宫，当他们确定了支持这个方向并开始和客户沟通时，很明显，所有客户都迫切希望能有某种原生的AI支持解决方案。这也是我之前提到的问题之一，很多人认为这只是一个GPT的包装而已。但是Decagon从一开始就获得的客户兴趣让我们很早就意识到，很多这些问题比人们预期的要复杂得多。

我认为这种现象在各个行业中都有出现，无论是客户服务，还是某些垂直行业中的专业自动化。我认为有一个被低估的点是，正如Jesse之前提到的，能够明确衡量自动化任务的投资回报率（ROI）。因为，如果你要让某人接受AI Agent，他们实际上是在进行某种程度的“信任飞跃”，因为对很多人来说，这是一个非常陌生的领域。

如果你能够自动化一个非常具体的流程，而且这个流程要么是显而易见的盈利生成流程，要么是以前在业务中构成瓶颈的流程，或者是一个随着客户增长或收入增长而线性增加的主要成本中心，那么就会更容易让AI Agent被接受。能够将这样的问题转化为一个更加产品化的过程，使其能够像传统软件一样进行规模化，这是非常有吸引力的。

Kimberly Tan：在我们继续之前，我有最后一个问题。我记得Jesse，之前我们讨论时，总是认为企业在采纳软件或AI Agent时，最大的挑战会是“幻觉”（hallucinations）。但你曾告诉我，这实际上并不是最主要的问题。你能否详细阐述一下，为什么关于幻觉的看法有些误解，实际上人们更关心的是什么？

Jesse Zhang：我认为人们确实关心幻觉问题，但他们更关心的是能够提供的价值。几乎所有我们合作的企业都关注相同的几个问题，几乎是完全一样的：你能解决多少比例的对话？我的客户有多满意？然后，幻觉问题可能会归入第三类，即准确性如何。一般来说，在评估时前两个因素更为重要。

假设你正在与一个新的企业对话，并且在前两个方面做得非常好，那么公司领导层和团队中的每个人都会非常支持，这时候你就能得到很多支持。他们会觉得，“天哪，我们的客户体验不一样了，每个客户现在都有自己的个人助理，可以随时联系我们，我们给他们提供了很好的答案，他们非常满意，且支持多语言，全天候服务。”这只是其中一部分，同时你还节省了大量成本。

所以，一旦达成这些目标，就会得到很多支持，并且在推动工作时也会有很多顺风。当然，幻觉问题最终还是需要解决，但这并不是他们最关注的事情。解决幻觉的方式就是我之前提到的那些方法——人们会对你进行测试。可能会有一个概念验证的阶段，你实际上会运行真实的对话，他们会有团队成员在进行监控和检查准确性。如果这个环节没有问题，那么通常就可以顺利通过。

此外，正如我之前提到的，针对敏感信息，你可以设立一些严格的保护措施，比如你不一定需要让敏感内容生成化。所以，幻觉问题是大多数交易中的一个讨论点，它并不是不重要的议题，你会经历这个过程，但它从来都不是对话的重点。

Kimberly Tan：现在转到AI Agent的商业模式，今天有一个大话题，就是如何为这些AI Agent定价。

历史上，很多SaaS软件是按座位数定价，因为它们是针对单个员工的工作流软件，用来提高员工的生产力。但AI Agent并不像传统软件那样与单个员工的生产力挂钩。

所以很多人认为，按座位数定价的方式可能不再适用。我很好奇你们在早期是如何思考这个困境的，最终是如何决定为Decagon定价的，同时，你们认为随着AI Agent变得越来越普遍，未来软件定价的趋势会如何发展？

Jesse Zhang：我们对这个问题的看法是，过去软件按座位定价，