Everything Hard About Building AI Agents Today
47:02 Share

再花一分钟，以防万一，确保我们用尽我的每一个脑细胞，这应该不难，所以我们应该从你去生产环境时出现故障开始。

你试图弄清楚为什么它会失败，尤其是在你的AI系统中。这并非易事，并非微不足道。我知道你们两位都见过一些这种情况，你们有想法。让我们从这一点开始。所以我们专注于构建一个代理，它可以对生产环境中的警报进行根本原因分析。因此，你的PagerDuty或Slack中会触发警报。我们有一个代理可以查看你的生产系统、可观察性堆栈，

规划、执行任务、调用API，然后对这些信息进行推理，直到它将所有信息提炼成根本原因或至少是一组发现。我可以列举一些我们遇到的挑战。其中一个挑战是

基本事实，就像生产环境中缺乏基本事实一样。与代码或写作不同，你不能只下载一个像网络信息一样的语料库，然后在线训练。因此，你需要弄清楚代理是否成功解决了问题。你怎么知道呢？因此，你需要找到一些方法，例如用户反馈，但有时用户不知道。如果你去问工程师，你知道，这是根本原因吗？他们通常会说，这看起来不错，但我不知道它是否真实。

因此，验证也是一个次要问题。事实上，我们学到的是，你尽可能地将人从循环中移除，不仅是从工作中移除，还从审查过程、标记和反馈过程中移除。因为否则，你成功或失败，但你仍然依赖于他们，被他们阻止改进你的代理或你的AI系统。

最终，你想要实现的是一个循环，就像一个生产中失败的学习循环，并将它反馈到你的评估系统中。你希望这个循环非常快。这不能以天、周或月为单位。如果可以的话，它需要理想情况下以小时或分钟为单位。

-是的，我们可以深入探讨其中一些领域。-我是Shreya，我做两种类型的研究。顺便说一句，我是一个博士生。一个是关于使用LLM进行数据处理的研究。如果你有大量非结构化数据，如PDF、成绩单、文本数据，你如何提取语义见解并对其进行聚合和理解？事实证明，构建执行此操作的管道

与构建AI代理具有相同的挑战。它只是用于数据分析的AI代理。很乐意进一步讨论，但在这种情况下，构建评估意味着什么？它是否意味着包含工具的使用？你如何协调诸如检索和让LLM直接查看数据本身的方法？

当然，我认为使数据处理成为理解LLM以及人类和系统如何相互作用的一个非常有趣的培养皿的原因是，当你进行数据处理时，你不知道你试图理解的所有数据。

AI正在告诉你数据中有什么。因此，验证在这里非常困难。你不仅要验证转换（即提取的见解），还要验证它们是否被正确提取，它们是否存在于数据中，你是否没有遗漏任何东西。但是，如果你不知道数据中有什么，你怎么知道LLM是否错过了提取？所以这里有很多非常有趣的挑战。

然后，因为我觉得我们对所有这些问题的运作方式有相当丰富的了解，我正在与Hamil Hussain一起教授一门关于AI评估的课程。你如何构建你相信可以部署的AI应用程序？你如何围绕它们构建评估？

当你提到你的问题时，当生产环境中出现故障时你会怎么做？如果你在将其部署到生产环境之前没有考虑过这个问题，那将是一场噩梦。你需要有一些阻塞机制。你正在衡量的指标。它不能仅仅是，哦，有人说它失败了，然后你就举手投降，没有办法开始。你一开始就不应该到达那里。所以，你如何从零开始能够进行调试？感觉有点……

这里与你对数据内容不了解的模糊性重叠，因此你无法真正判断输出是否正确，然后在你的方面也是一样，我们并不真正了解根本原因是否已解决，因此这种模糊性在某种程度上就像，你如何弥合这一差距，你如何做到这一点，除了好吧，我认为它看起来不错，它是

是的，一种非常简化的看待方式是，如果我们在生产环境中，例如在云基础设施可观察性中，它就像很多信息。时间序列，有日志，有代码，有Slack中的聊天记录。你真正想要做的第一件事是信息检索，它是搜索。你正在获取分散在各处的非常稀疏的信息，并从中创建密集的宝石，例如根据当前问题得出的发现。

我认为我们尽可能地尝试去做，我很想知道Shreya是否在她使用的案例中也能做到这一点。我实际上想看看用例之间的区别，那就是我们尽量减少对代理工作流程部分的依赖。如果你在代理步骤之上构建代理步骤，如果底层是错误的，那么其上的一切都是错误的。

在我们的案例中，有时它仍然有效，因为代理可以走一条错误的轨迹，但仍然偶然发现一个好的发现，并将其带回来。

但我很好奇，在你看来，这是否有效，或者只是对用户来说是灾难性的失败？我们关注的大多数用例都更像是批处理ETL样式的查询。因此，我们正在构建一个名为doc ETL的系统，你可以将其视为在你的数据上编写map reduce管道，但LLM执行map操作。因此，map不是代码函数。它是一个……

每个文档都会执行的提示。LLM还执行reduce操作。因此，我们执行group by操作，并将所有文档发送到LLM，它在那里进行某种聚合。从这个意义上说，并没有立即想到检索。如果你可以……，检索可以被认为是一种优化。

理解你的MapReduce管道，你的问题表示为MapReduce，以绘制相关的见解，然后聚合和总结它们与查询的相关性。

你可以想象其中一些map可以是类似检索的执行。你可以使用嵌入在使用LLM从每个文档中提取媒体见解之前进行过滤。从这个意义上说，我认为

检索是一种优化，当然，这是我的数据库思维方式。所以很好奇，LLM是在哪一层发挥作用的？是规划MapReduce操作，还是在操作本身中？它在操作中。顶部有一层，它从完全自然的语言查询到MapReduce过滤器的管道

想想Spark，但每个操作都是LLM。好的，那是来自用户的自然语言。是的，从某种意义上说，我发现我们对此进行了一些用户研究。没有人真的想从NL到管道，因为你想把你的工作流程想象成一种……

数据流管道。无论如何，你正在为map、reduce、filter、cluster等操作编写提示，即你想要的数据操作。所以它是低代码，无代码。人们真正挣扎的是，你知道，他们已经实现了，比如说你为你的用例实现了你的应用程序，你的管道和doc ETL，你可以做到，它只会非常慢。是的。

它是如何从初始输出到改进管道的。

你如何甚至知道代理由于下游问题而失败，然后当你意识到某些事情失败时，你如何将该观察结果编码回提示中，就像你有点感觉，哦，这不太对，但要指定我们所说的桥接，即规范的差距，这是我们看到的每个用户在尝试参与非技术性工作时最难的部分，如果我理解正确的话，基本上是

我看到有些地方不对劲，但我不知道该如何修复。我试图通过调整一些提示来修复它，或者我正在更换模型，或者我正在做我认为可能有所作为的一切。是的。而且……

它可能会也可能不会起作用。它可能会也可能不会。尤其是在数据处理中，我认为这在你的案例中也可能是真的，当涉及到AI时，失败模式的尾部非常长。它们以所有这些定制的方式失败，并且跟踪所有这些并将其综合成，好的，我需要给LLM的三个具体指令是什么？如果你有非常详细的提示，LLM是很棒的。

它们对模糊的提示很糟糕。对于90%的模糊提示来说很好，但要获得最后的10%，你在这里给出例子，给出非常详细的说明。也许只是我。我不知道。我的意思是，边缘案例是一个非常好的案例，因为我认为很多团队都认为，好吧，这很容易。我只需要构建一个边缘，然后分叉这个开源的东西，它就会起作用。你达到了一定程度的性能，但是根据用例的不同，达到非常高的性能确实非常非常困难。

我也对HCI的视角感兴趣，因为我很好奇，你的用户有哪些控制界面？你得到了什么？因为如果你考虑一下mid-journey，有时最令人沮丧的事情是它只是获取，你每次都会得到一个随机的东西。所以它就像在赌场，就像老虎机一样，对吧？是的。

这可能会非常令人沮丧。但是如果你有inpainting，那么你突然可以获取图像并对其进行改进。或者即使使用新的ChatGPT图像生成，你也可以使用规范来指定你想要的内容。这是一个不同的HCI级别。我的意思是，聊天和界面不如更结构化的东西好，我想。

所以我很想知道，今天的这些界面是什么，以及你认为它们随着时间的推移会如何发展？是的，好的，现在如果你问ACI问题，我必须进行历史课。这是完美的房间。太好了。所以Don Norman，他写了很多关于设计的东西，是第一个提出这些头骨的人。他提出的执行和评估的头骨。任何产品，不是AI产品，任何界面都需要用户弄清楚

如何使用它。他们脑子里有一些潜在的……

意图。例如，像预订航班这样简单的事情。你从德国预订了飞往这里的航班。你需要在脑子里弄清楚这一点，查看谷歌航班界面，并将其绘制出来并执行，然后看看发生了什么，然后理解它。这种循环在80年代和90年代很难做到。我们解决了这个问题。但是AI带来的新东西

现在是这个差距，我称之为规范，因为这更容易让我理解。它分解为两件事。一个是你怎么与AI沟通？然后你怎么从AI泛化到你的实际数据或任务？因为你可以有一个非常好的规范。你有一个很棒的mid-journey提示，它被发送到AI，但是意图与AI之间存在差距，它错了，然后你就想，“哦，我的天哪，我做错了吗？”我认为我们作为一个社区首先要做的事情，这也是我们在研究圈子里讨论的事情，就是认识到这两个差距。两者都需要桥接，但我们需要做到这一点的工具需要有所不同。对于规范的差距，

至少在doc ETL堆栈中，我们正在构建工具来帮助人们进行提示工程，标记不良输出的示例并自动建议提示改进。目标只是获得一个非常完整的规范。

我们不会承诺该规范将按预期运行，因为我们都知道LLM会犯错误。我们的想法是单独的工具，如任务分解、代理工作流程、更好的模型将弥合泛化差距。你正在谈论的差距以及如何

我们已经有这么多年的人与计算机互动，我们找到了一种方法。对我来说预订航班并不难。那是在80年代。没错。界面已经过改进。但是现在当你将自然语言加入其中时，

它变得困难得多，因为A，我们不习惯它，B，它非常模糊。再次回到我说一个词时的那种模糊性，它可能意味着一个意思，你可能将其解释为另一个意思，而LLM可以，它就像去赌场，你玩老虎机。我认为这部分原因不仅仅是自然语言，

元素，而是拥有一个关于系统正在做什么的模型，如果你无法弄清楚这一点，那么你就卡在起跑线上。如果你使用光标并且正在进行一些代码……你知道软件开发，如果你理解它只是对你的代码进行rag，那么你就会有一个更好的心理模型，并且知道，好的，我可以引入这些文件，我可以索引这些文件，或者如果你知道你打开的选项卡……你知道权重更高，那么拥有该模型……

它会影响你如何提示代理。-绝对正确，还有历史。我知道我的剪贴板里有一些东西，或者我刚刚进行了一些编辑。是的，我不知道为什么感觉你需要知道这些东西才能引导。这非常困难。-我认为很多人犯的一个错误是，他们不是想幼稚化，而是想从用户那里抽象出来，只是认为，“好吧，这就像一个黑盒子。别担心。”但这使得使用他们的产品变得更加困难。因此，我们正在尝试的另一件事是，

有时给用户少一点，并给他们更多UX辅助功能，使我们能够从他们那里获得更多反馈。但这些是正交的，所以它可能会使产品略微难以使用。例如，我们可能会给你……这些是关键发现。

但在类似mid-journey的风格中，我们将提供给你一些按钮，上面写着“展开以获取更多信息”或“使用此发现进一步搜索”。因此，如果我们给你一些非常有用的东西，如果你点击并展开，我们就知道，好的，这实际上很好。如果你继续忽略我们给你的东西，那么我们就知道这是不好的。因此，我们得到了一些隐含的反馈。我不确定你是否也包含了类似的东西……是的，我们非常重视反馈的层次结构。所以……

最简单的方法是获得二进制，点击或不点击，是或否。然后能够通过开放式反馈来深入了解这一点。我们所做的一件相当成功的事情，以帮助人们为dog ETL管道编写提示，就是始终有一个开放式反馈

框，你可以在其中突出显示你认为不好的文档或输出，并随意表达为什么它有点偏离主题。哦，不错。你可以对其进行颜色编码或标记。它存在于数据库中。哇。每当你调用AI助手或你……我们还有一个提示改进功能

它几乎可以读取你所有的反馈并建议有针对性的改进。所以提示对用户可见吗？是的，提示是可见的。我认为我们还没有达到比编写提示更好的状态来进行转向，尤其是在数据处理方面。

我认为如果你有一个范围更明确的任务，那么他们可能不必编写提示。在你的任务中，你非常具体。你正在搜索人们的日志，帮助他们进行根本原因分析。但是假设你使用.etl来编写这些管道，你绝对必须编写提示。我想总是有一个权衡，即你给用户多少控制权。所以我们给他们一个控制界面，比如文本输入，他们可以在……

注入一些指导，无论是全局的还是上下文的。因此，对于特定类别或一类警报，我们可以注入一些指导。也许有一个SLO燃烧率警报。然后你可以附加一些上下文内容，他们会说，总是检查数据狗指标，总是检查最新的实时对话，总是检查系统，因为它总是以某种方式与故障有关。

有时你需要用户给你提供这些指导。他们的脑子里潜藏着如此多的上下文，他们需要以某种方式将其编码到你的产品中。它让我想起了当你下载手机上的新应用程序时，你会有一些时刻回到那里，存在这样一个差距，我不知道这个应用程序是如何工作的。所以你会四处滑动，按下按钮，然后你就会发现，哦，好的，很酷。我想我知道这里发生了什么。所以……

但现在我们正在使用文本，我们正在使用提示。因此，能够真正弄清楚最适合的界面

与人和文本交互，所以展开按钮非常重要，我真的很喜欢它，因为它会发出信号，它只会给你一点点，然后你就会知道，好吧，但问题是你不能给他们所有信息，然后你给他们一个摘要，足以让他们点击更多，是的，这是一个预告片

是的。很多时候它实际上甚至没有用。人们不会点击它，但这仍然是一个非常好的信号。是的。是的，这很有帮助。同样，像突出显示文本并能够随意表达一样。是的。我想到的是，当你拥有像突出显示文本然后进行意识流时，你如何将其重新整合到系统中，以便它从中学习并变得更好？

这就是为什么我认为你需要AI助手，因为用户无法记住所有失败模式的长尾。这就是为什么我们有一个反馈数据库。当用户需要改进提示或想要做一些新的事情时，我们可以向他们建议一个提示，因为我们已经知道他们关心的事情，因为我们阅读了他们的反馈。我们总是提供建议。

或对他们的提示进行差异化，然后他们可以点击接受或拒绝。所以它正在将其重新整合到提示和评估集中？是的。是的，这很有趣。目前，我们没有一个好的工作流程来进行评估集。我们仍然……

正在尝试我们认为最好的方法。例如生成合成数据或让用户，目前用户必须自己提供数据。-令人着迷的是，好吧，很酷。这里有成千上万的见解，因为我做了所有这些与输出的尝试。

我已经花费了我宝贵的人工时间来留下这些见解。现在，我们该如何处理它们，以确保它们被整合到我构建的下一个版本中？因此，拥有一个助手并能够建议，好吧，你可能不想这样做，因为记住你说你关心这个，以及任何没有奏效的提示。我认为，这不仅仅是在，

这不仅仅是数据处理存在这个问题。代码生成也是如此。mid-journey或图像生成也是如此。但是当你开始一个会话时，你几乎总是会进行一些探索性分析。在HCI中有一个术语来描述这一点，叫做认知工件。

它来自艺术家如何使用工具。例如，如果他们得到新的颜料或新的媒介，他们会在绘画之前玩弄它。我认为我们在新一代EI界面中构建的所有界面

就像竞技场，缺乏更好的术语，需要能够快速创建认知工件。例如，当你使用Cursor时，你想尝试一些东西，并且你想，如果它看起来不好或不起作用，你想能够丢弃它并继续前进。我认为这是当今最大的失败之一。是的，这是最大的失败之一。一些成本太高，无法进行实验，人们只是退出游乐场或……

通常根本没有游乐场可用。这真的让我觉得这是一个UI UX问题。它很大程度上在于产品如何使人们尽可能轻松地避免这些，哦，我知道Cursor上的一些小黑魔法，因为我知道它是一个rag，并且是选项卡。如果我复制粘贴了一些东西，那么它会做得更好。这应该不是像，

门控对吧，所以你如何在你的产品设计中设计一些东西，它非常

避免像哦，你必须知道如果你知道的话，这非常困难，真正使这些类型的id或界面混乱的是，有很多切入点可以弥合差距，对吧，有规范的差距，你需要尽可能充分地将你的意图外部化，并且有一个泛化差距，即

你需要确保你的提示有效，无论RAG如何，无论选择了哪些超参数。现在，人们依赖于为这两个差距提供提示。例如，你必须知道RAG是如何工作的，这样你才能给出适当的提示来弥合泛化差距。这太疯狂了。是的。好吧，我们故意做出的一个决定是分叉Wolf off。我们最初使用的是slack……

就像一个在你Slack中的代理，基本上是一个队友。我们实际上是从帮助台开始的，我们正在回答工程师的问题。所以一个工程师会像一个平台团队支持另一个工程师，带着问题进来，在工程师之间来回沟通非常困难，因为有很多闲聊，有很多来回沟通。通常情况下，这些问题需要立即得到解答。这是某人花了一整天时间做的事情。这是一个非常同步的参与。

而对于警报流来说，它更异步。它是一个系统生成的警报。你可以在你自己的时间调查它。因此，如果你使用Cursor和Devin，它有点相似，对吧？使用Cursor，你参与其中。这是你试图用Cursor解决的一天中最重要的事情。对于Devin来说，它有所不同，因为你说，为我编写这个代码，但这就像你交给实习生的一个辅助任务。我认为在我们的案例中，我们也试图将工程师不需要……

立即尝试解决的繁琐工作移除。所以它更像是一个环境背景代理，它只是为你完成所有这些工作。如果你查看，你会发现，好吧，它为我解决了20个警报。我不必去查看它们。你如何看待这种二分法或这两个世界之间的区别？因为我认为这些用例实际上是不同的。它们非常不同，你不能再依赖于人类的提示了。

工作，因为你不是人类关注的首要ID。没错。而且回到这一点，就像，你如何考虑我不希望它让人们需要知道Cleric工作的秘诀，对吧？或者像有些人因为知道这些事情并且了解AI的工作原理或RAG系统或其他任何东西而拥有更好的体验。而且

如果你能做到的话，你完全想避免这种情况，对吧？所以工程师经常来找我们说，“等等，所以你将比我更擅长解决这些问题吗？”他们在这些公司工作了很多年，我们并不声称这一点。我们只是看到在自动化方面有很多低垂的果实，我们可以为你用这些代理自动化这些果实，然后只是布置或准备你做出决定所需的所有关键内容。所以我们想利用他们的领域专业知识。他们是专家，我们只想让他们更容易。

所以他们应该评估的是发现和指标以及日志和依赖关系图以及所有他们已经很了解的东西。我们不希望他们必须理解我们产品的内部结构。我认为这是一个失败。但同样因为我们不是同步流程，你基本上看起来像AI正在引导自己找到答案，如果它找不到东西，它就会放弃，如果它走在正确的道路上，它会继续到一定程度。

但在大多数情况下，你只是在制作他们已经能够理解和直觉的东西。需要很长时间的事情可能只是从一个……

工具切换到下一个工具，收集数据，试图将两者结合起来，然后一旦你有了图片，你就可以开始真正使用你的专业知识，但在你到达拥有该图片的地方之前，这就是你所说的我们可以自动化的东西，没错，工程师经常会

进入控制台或终端并继续拥抱。每次都是一样的事情。当然，也有一些黑天鹅事件和非常棘手的问题，甚至AI也无法为你解决。但是工程师必须做很多垃圾和基本的机械性重复工作。记住，在很多情况下，他们有一份全职工作来编写软件，以使业务取得成功。这不仅仅是后台的调试和例行调查，对吧？是的。

我真的很欣赏这些。我一直忘记你用的词。我用的是“峡谷”，但你用的是……“海湾”。“海湾”。你知道，只要知道存在差距就够了。术语是什么并不重要。认识到这一点是有帮助的。是的，确实存在这样的差距。现在我开始思考所有存在差距的地方。所以也许有……

你一直在思考的其他地方，因为你说有两个差距，我认为我们已经详细讨论过一个了。另一个是什么？好吧，我认为现在有三个差距。在人工智能出现之前也是如此。三个分别是：指定、从你的规范推广到你的实际任务或数据，然后是理解、理解。

到底发生了什么？你如何驾驭法律？你甚至如何看待人工智能输出的长尾？你如何看待你的数据？它做对了吗？所有验证都属于理解，例如，

我们可以深入一个黑暗的兔子洞。但这是一个非常大的循环，对吧？就像在你理解之后，你需要再次指定。然后该规范需要推广。我认为，我认为每个IDE都会遇到这个问题。每个做中等复杂事情的产品都会遇到这个问题。

如果可以的话，我也很想讨论一下极端情况。其中一件事情是，我们与Adam Jacobs交谈过，他也在谈论DevOps中的这个问题，在许多我们知道存在模型崩溃效应的空间中。模型，你的AI系统，无论是什么。你不能保证你可以不断添加评估和场景来改进你的系统以达到100%。在某个时候，你可能会……

像解决一个问题，然后，你知道，另一个问题出现了。这是打地鼠游戏。这是打地鼠游戏。所以我不知道你是否有任何技巧，或者，你知道，

来自你一直在构建的产品？是的，我认为这是关于饱和度的。它不是100%。这是关于建立最小的评估集，然后达到添加更多内容、尝试新事物但没有任何变化的程度。就像那样，你完成了。你无法做得更好。就像你必须等待新的GBT模型。

我在参加的每一个HCI演讲中都会问这个问题，因为我认为在试图引导、试图改进模型或代理方面有很多工作要做，但存在一个上限。我认为我们还没有弄清楚是什么定义了达到上限。我真的很想知道你对你的用例是否有启发式方法。我们真的不知道上限在哪里。我们知道，如果你能与用户设定正确的期望，那么我们会……

我们有很多关于我们可以攻击并实际解决的警报类型的数据。这很好。所以我们从类似这样的事情开始，

我们要求他们或我们的客户导出过去两周的所有警报。然后我们尝试识别那些我们在评估中或其他公司或其他团队中已经解决的警报，我们对此非常有信心。所以几乎有三个类别。第一个类别是你非常有信心可以解决的警报，如果你部署我们的话。第二个类别是你需要在生产中学习的警报。你非常有信心可以学习这些。

但你不知道它在什么时间点到达第三个类别，那就是你永远无法解决这些问题。这非常依赖于客户。但从市场营销的角度来看，第一个类别是唯一真正重要的类别。如果这个类别足够大，那么他们就会说，好吧，让你参与生产是有价值的。这就是让你有权留在他们环境中的原因。

然后第二个类别是你想要扩展并真正证明你的价值的类别。并尝试找到第三个类别在哪里，你跨越到第三个类别的界限在哪里。但我认为你以这种方式思考是独一无二的，因为许多人甚至不知道第一个类别是什么，或者对其有一个特征描述。是的。

人工智能就像任何事情一样，对吧？你可以问它任何问题。它会给你一个答案。老实说，这是你能说的最糟糕的事情，因为客户会来找我们说，好吧，如果我部署你，你能为我做什么？如果你说，好吧，我们会弄清楚的，那么他们就会说，好吧，这还不够好。我需要知道你到底能解决什么问题。让我们进入生产环境几周，我会告诉你我们能为你做什么。是的，太棒了。

就是这样。所以我们非常关注这一点，在我们的评估中真正确定第一个类别，然后让飞轮运转起来，这个学习循环使第二个类别，学习到的警报集真正变得很高。我喜欢这个框架。我想我会把它复述给人们，并说Will正在这样做。

但我看到的问题是，甚至不知道，甚至对上限是什么没有合理的了解，也不知道你现在在哪里。它真的与数字无关。它与氛围有关。我非常赞成氛围，但关于对氛围的数字有一些置信区间。

而不是像总体上我们达到了97%或其他什么。每次我阅读一些案例研究或一些……我也做一些咨询，或者一些客户可能会说，哦，我们的准确率达到了94%。我说，这到底是什么意思？是的，证明一下。是的，我想知道的是，你真正想要解决的三到五个氛围是什么？或者如果你有明确定义的准确性指标，例如关闭时间或……然后……

给我你的样本置信区间。然后确保我们就在这些区间内。我真的很喜欢这个想法，嘿，有一个第三个区间，我们试图找出上限在哪里。我们不知道。我们不知道它到底在哪里。

你有没有发现它在时间量上是对数的，你达到了收益递减的点，你开始想，你知道吗？我可能不得不放弃这个。是的，一直如此。但这没关系。如果人工智能不能一直读懂你的心思，它仍然可以产生影响。让我们擅长使用人工智能的是知道我们何时可以使用它。是的，正如你所说，只要这个类别足够大，就像……

是的，有很多工作可以自动化。是的，只要你不浪费工程师的时间。如果这是一个以生产力为中心的产品，如果你不确定某事，你可以保持安静，那就没关系。因为如果你确实提示他们，它只需要有价值。这就像拥有无限数量的实习生，但如果他们没有什么好说的或要问的，他们就不会来找你。是的，这回到了我一直在思考的一个问题，那就是……

LLM对我的时间的无礼。就像我不需要一份五页的报告，而其中只有一句话对我真正有价值。

我认为有很多代理在那里是一个非常直白的AI。所以就像AI，到处都是星星和光彩。这非常普遍。但我认为人们真正想要的是，在后台为他们完成工作，对吧？你的待办事项列表正在被清除，无论是JIRA还是Linear还是其他什么。但你是否试图帮助人们进行提示，或者你将所有这些都抽象掉，你只是给他们警报？

不，我们给他们警报的调查结果。我们是根本原因。所以我们不直接让他们访问来调整提示。但我们确实为他们提供了控制界面，以便他们可以注入一些指导，并且它也可以是上下文相关的。但我们无法完全控制代理。这是因为回到这一点，就像你之前所说的那样，

他们不需要知道如何使用人工智能的黑魔法。他们只需要看到，因为这是一个完全不同的角色。你不想让他们现在不得不深入研究提示来弄清楚这是否是正确的做法，或者是否有更好的方法。我们一开始确实做过。我们意识到发生的事情是每个客户都会……

像特有的指令，这些指令不一定能推广。所以这是……你想要建立对每个人都有益的肌肉，这有点像复合效应。我们意识到

如果我们掌握了这种控制权，那么一开始会比较困难，因为用户的思维模型较差，但从长远来看，这对我们更有利。所以对于这个模型崩溃点，我们发现你可以达到一个良好的平台或基线，每个人都能从中受益，而通用模型，如GPD、下降和十四行诗，它们会有一些帮助，但是

但由于这些环境非常特殊，而且没有公共数据集，我不能只是要求你导出你整个公司的基础设施，对吧？什么也没有。因此，我们会将代理可以做什么进行情境化，但我们会集中进行。因此，根据性能指标，我们会说，哦，你的代理具有一组与其他代理不同的技能，但我们可以选择这些技能。

所以，也许如果你正在运行Datadog和Prometheus，并且你正在Kubernetes上运行，并且都是Golang，那么我们不会拥有适用于Python或这些特定于不适用于你的技术的技能包的代理技能集。因此，我们会尝试尽可能删除或垃圾收集内存或指令，以简化代理可以执行的操作。所以我们有很多这样的技术……

如果你查看我们的基本代理或我们的基本产品，它们是相同的，但我们会根据上下文对其进行一些修改。因此，每个客户的性能数字都可能更高。但这也很冒险，因为测量结果并不总是苹果对苹果，对吧？关于公开提示的另一件事是，如果你正在构建一个应用程序，通常当某些事情有点不对劲时，

人们首先要做的事情是去提示中做一些修改。这会使情况变得更糟。就像你已经做了很多年了，对吧？就像他们第一天看到提示，然后就像，它没有意义，对吧？这就像公开，在某种程度上，我认为提示就像代码。这就像向用户公开你的代码库，就像，

不，你不需要知道香肠是如何制作的，我认为这不是一个专有秘密酱汁或其他什么的问题，而是不要邀请他们做一些对他们有害的事情，而且如果你给他们那个界面，你就不能真正拿走它，是的，他们会觉得，好吧，我刚刚花时间做这件事，就是这样，是的，我可以想象一个世界，他们会花很多时间，最终会变成

哇，这实际上是浪费时间。这个本应节省我时间的工具现在却让我花费更多时间，因为我正在调整这些提示，并试图使系统尽可能好地工作。所以他们正在幕后浪费时间。这是真的。但有时用户会对他们自己定制的产品产生更高的依恋感和亲和力。如果你更改颜色，你放入暗模式，所有这些事情，在你意识到之前，你会喜欢这个产品，因为它属于你，对吧？

所以这是一个平衡，但我不会公开提示。也许只是一些颜色滑块或其他什么。这容易得多。实际上，当你谈到不同的代理属性时，它让我想起了你玩任何体育游戏的时候。

你拥有运动员，并且他们有那个圆圈，显示他们擅长什么和不擅长什么。这就是我想看到的不同Clerics，好吧，你拥有这个代理，它擅长Golang，但Python，不，技能不是Python，但它不需要它。这是好的一面。是的。

是的，你应该看看我们最新的营销。我们很快就会推出一些类似的东西。是吗？太酷了。我们应该让你加入品牌团队。我很喜欢。但无论如何，我们还要谈论什么？我记得还有更多项目在日程上。好吧，我也很好奇Shreya的观点，如果你在生产中看到来自用户的障碍，例如他们遇到的一些问题，他们是否会给你一个数据转储，或者这是如何工作的？你的端到端周期是什么？你从故障到使用新版本重新进入生产的速度有多快？是的。

我们没有大型AI管道。我们正在为人们构建编写AI管道的脚手架。所以它非常类似于软件工程。人们会说存在一个错误，例如这里存在一个无限循环。我说，好吧，我会修复它。它就像TypeScript。是的。

我没有什么好东西。他们需要弄清楚整个循环。我有一些研究项目。这是一个开源研究项目。所有内容都通过Discord或GitHub问题等方式传来。对于我与之合作的客户，因为他们实际上是公司，我发现他们实际上甚至无法

检测到是否有问题。这甚至不是他们的用户抱怨的问题。他们处于如此早期的阶段，他们只是说，救命，我们做对了吗？我应该部署它吗？但这可能只是那些报名参加咨询或那些甚至没有信心做到这一点的人。

但我认为我与之交谈的每个人都必须有一些指标。无论它们是否与用户的想法和说法非常密切相关，都没关系。但拥有某些东西可以查看是第一步。间接地，它还会给你带来另一个好处，如果你已经为你的代码添加了监控，那么添加新的评估就会容易得多。

但人们会考虑，哦，像必须向那里添加评估。这是一件大事，因为是的，这就像添加可观察性和监控非常困难。我认为有，有生产故障，然后有两个部分。一个是，你如何评估发生了什么？所以我们从跟踪开始。对于单个运行，你可以看到代理做了什么，例如它调用的工具、推理是什么、提示以及所有这些东西。

然后我们的下一步是如何将其转换为测试期间的新场景？我们遇到的问题是，手动进行跟踪审查非常费力。所以你进入这些跟踪，它处于非常低的级别。因此，我们构建了一个摘要或后处理过程，它完全是，好吧，它就像部分AI，部分确定性，但它会沿着许多维度将所有这些东西压缩和聚类在一起。所以我们会看到，

对于大多数故障发生的任务的主要组。假设一项任务是分析日志，你知道，对于数据日志，或者下一项任务是在过去几个小时或几天内查看警报通道中的对话。经常重复出现特定任务。

然后我们尝试对它们进行聚类。然后我们查看指标或，你知道，代理是否成功调用了这些API？我的意思是，即使是从工程的角度来看，是否存在API故障？它是否进入循环？它是否在查找或解决这些任务时效率很高？像许多这些指标一样，你不需要人类的反馈。它完全可以，你可以直接解析信息。

然后，我们根据这些信息构建了这些热图。然后是热图，行基本上是任务以及代理做了什么，列是指标。然后你可以看到它只是亮了起来。代理真的只是在这件事上很糟糕。它在Datadog中查询指标方面很糟糕。你不是唯一一个制作热图的人。当你看到它时，你会想，好吧，我们之前为什么不做这个？你是第三个告诉我这件事的人。

是的，然后很容易编写评估，因为你就像好吧，我只需要一个评估，它可以知道，然后我们遇到的下一个问题是创建这些评估有时需要整整一周的时间，因为你需要实时生产基础设施，所以然后我们都像呃

这是一个更深层次的话题，但就像模拟生产环境的模拟环境。所以我在问你是否可以从你的用户那里获取数据转储，因为在我们的案例中，我们无法做到。因此，我们必须在评估层、模拟层上进行创新。这非常有趣。人们确实会将他们的管道和一些数据发送给我们。所以这对我们来说很容易调试。但我认为模拟的想法非常有趣。是的，我真的很喜欢这个。但它也感觉非常定制。

你是说针对用例？是的。甚至不仅仅是Datadog模拟。Datadog日志检索模拟与你 guys拥有的其他代理不同。你可能必须在某种程度上为每个代理构建一个环境。或者为每个代理构建一些规范。当然。所以我们做的事情有点类似于SWE代理使用SWE工具包所做的事情。

因此，你可以拥有，在可观察性层有很多相似之处。所以有指标，但有大约20个不同的指标系统。但是像折线图或查看指标的想法与时间序列并没有什么不同，对吧？是的。所以你希望你的代理能够在该系统之上的层面上运行。

当然，技术有一些特性，但是如果你将这些特性抽象掉，那么这些特性之间就可以转移。所以如果你擅长Datadog日志，你可能擅长OpenSearch日志。你不需要改变太多。你不需要改变太多。这很好。因此，通常你可以进入，你可以为新的日志系统插入一个MTP。只要集成工作正常，它就会具有良好的性能。它不会是10分之10。可能有一些独特的东西。拥有模拟也使其更好。很多

我告诉很多人，如果你想测试某事物的可靠性，只需在许多不同的日志上运行它即可。但是，像，略微不同的术语。我不知道。无论是什么。然后，就像，确保你的答案是一样的。很多时候事实并非如此。

你可以对这些输出进行某种异常检测，以找出，好吧，它给你的常见故障是什么？现在如果你有这个环境，这就会变得非常容易。我们最初所做的是，我们会启动实际的环境，例如实际的GCP项目、实际的集群。这么多。几乎每个人现在都在做这件事，这有点在这个领域。我不确定是否有人在使用模拟方法，但是……

这并不令人惊讶，但在事后看来很明显，这些系统擅长自我修复。Kubernetes想要启动应用程序。所有开发都在软件中，以确保它工作正常，而不是损坏。保持系统处于损坏状态……

这是持续的，因为测试需要是确定性的。否则，你运行一次代理，再次运行它就会失败。但是，如果整个世界在过去五分钟内发生了变化，因为时间序列不同，日志不同。- 你完蛋了。是的，它毫无价值。- 是这个环境发生了变化，还是我的代理？然后你就像只是怀疑，然后你需要一个系统来监控环境。

所以这非常困难。有时你需要用数据填充这些环境，并且你意外地加载了错误的数据。然后现在你需要删除你的帐户并重新配置它们。这太慢了。因此，我们还采用了由LLM模拟的API的另一种方法。但这也会产生不确定性。所以这也是一个非常非常具有挑战性的方向。所以这就是我们采用模拟方法的原因。我们创建了这些伪造品。模拟方法的缺点是它不是完美的……

模拟或复制这个Datadog，对吧？我们不能拥有每个API，因为那样我们就相当于在构建Datadog，对吧？但你只需要让它达到，有一个80-20规则，它足够好，代理会被它愚弄。一些最新的模型，代理实际上在模拟中意识到

我的联合创始人分享的LinkedIn上有一张截图，它发现它在一个模拟中，它就像，它放弃了一项调查，因为它就像，这看起来像一个模拟环境，或者我不记得是否正确，但类似的东西，或者像测试环境。哇。然后你必须改变

pod名称，你必须更改日志以使其更逼真，但这很酷，如果你像提前提示代理一样，这是一个模拟，但你的一些东西不起作用，这就是我们正在做的，这就是我们正在做的，但我不知道这是否会适得其反，但我们现在正在这样做，它会像是的，我很好，没有生产系统，这是

你基本上必须告诉Neo，你在道场里，但你要去街上。但你现在正在训练，但要像你要去街上一样认真地训练。这真的很奇怪。而且迭代循环的速度之快也很酷。因此，你能够弄清楚事情……

当你学习一次后，它是否会在所有不同的代理中复制？是的。这是问题的一部分。另一部分是如何改进代理以实际解决问题，对吧？所以然后你必须考虑一下，如果你需要跨越多个服务的因果关系，你是否要添加知识图或服务图，或者你是否需要一个学习系统？你必须扩展或引入代理的其他组件。是的。

所以我不希望深入讨论所有这些事情，但这就是真正的工作所在。我不知道你是否能看到那只狗，那只狗灯？是的。是合法的。那里还有两只小狗。可爱，是的。它们是快乐的狗。英语是你的母语吗？

英语是我的母语。看起来不像吗？好吧，现在我们正在剪掉这些东西。