大家下午好，我是 Encore。我要教大家如何让 Agent 变得“靠谱”。当然，这和烹饪食物无关——我也不知道为什么这么说，但总之我们要深入探讨一下。在正式进入主题之前，我想先问大家一个问题并进行一项投票。我相信很多人正在构建 Agent 或者已经上线了 Agent。我很好奇，在座有多少人目前是凭“感觉”（vibes）来发布产品的？
当我提到“凭感觉”，这并非贬义。我的意思是，你们通过检查答案、观察输出结果来确保 Agent 基于输入和输出生成的内容可能是正确的，从而判断其是否准确。在座有多少人是这样做的？好的，看来比例相当合理。
那么，又有多少人像设置评估体系那样正式地建立了 Eval（评估）机制？比如使用 LLM 作为裁判、基于代码的评估，或者某种形式的自动化评估设置。好的，这个比例稍微少一些，但也不算太少，其实还挺不错的。
接着问大家：有多少人对你们建立的评估体系足够信任？也就是说，你们的覆盖范围是否全面，是否有信心可以持续不断地推进和优化？哇，这个举手的人数相当令人印象深刻。这也正是我预期的结果。
说实话，要真正信任你的评估体系是很困难的，因为构建它并不容易。你往往不清楚自己到底在寻找什么，而且 Agent 的应用场景并非确定性的用例。因此，很难确切地知道我们需要评估哪些指标来确保 Agent 正常工作。
这是目前面临的最大问题之一：许多人起步时状态良好，依靠“凭感觉”开发。这确实能帮你快速启动并确保 Agent 按预期运行。但在现实中，你不能仅凭“嗯，这看起来是对的”这种直觉就将其上线发布。
因为在生产环境中，如果你没有建立实际的评估体系来发现故障点以及如何直接修复它们，你就不知道哪里出了问题、什么环节出错。所以，在进入评估之前，我想先退一步谈谈你的评估应该建立在什么基础之上——那就是 Trace（追踪数据）。
我们需要 Trace 的原因在于，如果你曾从事过传统软件工程工作，你一定知道什么是追踪。它用于 APM（应用性能监控），旨在确保系统的可靠性和正常运行。但在传统软件中，调试这些追踪数据非常容易，因为流程是确定性的。
大家可以看这里，路径非常清晰易懂，这基本上就是代码的样子：你有一个处理提交的方法。如果输入无效则报错；如果有效，则进入下一个列表并继续该流程。因此，仅凭这种路径历史，就很容易找出哪里出错了。
但在 Agent 中，不幸的是，你的代码通常只有一行：agent.run(query)。至于它最终会做什么——是调用工具、进行分析，还是进行内部思考？它的下一步最佳行动和实际最优路径是什么——在查看 Trace 之前，我们一无所知。
如果不看 Trace，你就不知道 Agent 到底在做什么。因此，Trace 有助于你定义这些行为。作为一个 decent（不错）的例子来说明 Trace 长什么样：你可以看到 Agent 的调用、LLM 的交互、你检索到的文档以及使用的工具。基本上，你能看到 Agent 执行过程中的每一步。
例如，在这里我们可以看到一个 tool.get_order_status（获取订单状态）的调用，但这是一个错误的工具。用户问：“我本该收到退款，我的退款在哪里？”如果我们回复说“您的退款已发放”，并基于订单状态告知他们情况，这并非用户所求。
用户想知道的是为什么退款还没到账。因此，我们可能需要调用不同的工具、执行不同的操作。即使只是意识到这里存在问题，也有许多不同的变数需要处理。稍后我们会深入探讨这一点。
当你理解 Trace 的作用，并想要调试 Agent 的问题时，首先要做的是识别这些问题——就像我们在上一张幻灯片中做的那样：发现工具调用错误。但下一步是什么？你需要找出不仅是在哪里出错，还要获取足够多的此类样本数据，以便用于实验和迭代优化。
当你想要回头针对这些案例进行测试时，你需要收集这些信息。那么实际的问题到底是什么？当然工具调用错了，但这是 LM 提示词需要改变吗？是需要添加护栏（guardrails）吗？还是需要更换工具？或者是该工具本身执行了错误的操作？
我们需要测试和验证的方面非常多。因此，我们可以针对这些点构建评估体系以持续监控用例。例如，如果你发现需要在此处设置护栏，该如何做？你需要确保该护栏能发挥作用——通过建立评估器来验证它是否有效防止了某些信息的泄露。
最后，你进行这些更改，运行我在开头提到的实验，然后将其部署到生产环境中。如此循环往复，不断重复这一过程。这就是改进 Agent 的标准流程：虽然漫长、手动且繁琐，但它确实有效。然而，我们希望迭代并改进这一过程。
我们不想花费数小时甚至数天去查找问题、追踪 Trace、找出所有不同的故障点，然后提出潜在解决方案并手动走完这八个步骤。我们希望将这些工作整合起来，将耗时缩短至几分钟内完成。
最好的方法就在这里：我们将来自不同来源的所有数据整合到一个特定的区域中。我们要从提取我们的 APM 和 Arize（阿赖耶智能平台）数据开始……
通过 Trace 数据，你可以获取智能体执行的所有信息。接着引入评估结果，查看问题究竟出在哪里；同时纳入人类标注者的反馈，他们能从理论上提供更多关于改进方向的见解。此外还要接入实际的 APM 追踪数据以监控系统状态，并引入代码库以便在特定工具调用失败时分析如何修改代码。这样就能确保智能体沿着正确的路径运行，调用合适的工具并修复故障模块。
所有这些数据最终汇聚到一个统一的空间中供编码智能体使用，无论是 Cloud Code、Cursor 还是 CodeEx 等工具均可连接。虽然听起来复杂且设置过程看似繁琐，但实际上只需几步即可配置完成：安装 CLI 并设定技能后即可就绪。智能体随即能访问大量信息和工具，例如对代码进行插桩以获取追踪数据至 Arize 等平台。
你可以在编码智能体内直接拉取这些 Trace、构建数据集、运行实验和评估，获得全流程体验。接下来我们将针对一个具体问题进行分析，并邀请听众猜测故障原因。该智能体是一个简单的金融助手，我曾询问是否应投资塔塔汽车，它给出了肯定的建议。
然而这并非我们想要的结果，因为我未获授权提供金融建议，也不希望惹上法律麻烦。有人猜测智能体应在给出确切答案前提出更多问题以获取信息，这是一个很好的推测。若采纳此建议，具体该如何实施？有人提到需要更多上下文、提问和细节；也有人指出缺乏验证机制。
确实，我们目前没有任何基准事实可供对比，无法确认答案的正确性，缺乏验证环节。此外还有听众提问：智能体是否了解用户的金融背景？在此案例中它并不知晓，而这正是其缺失的关键信息。该智能体存在诸多可修复之处，且没有唯一的标准答案，目前它仍处于混乱状态。
今天我们将通过演示来修复这些问题。首先设置 CLI 和技能，让编码智能体理解故障原因：拉取 Trace、分析已有评估和标注数据，甚至进行自主分析并提出改进建议。例如增加提问环节或添加护栏以防止不当的金融建议，从而通过多种方式实现修复目标。
启动时我打开新会话并进入正确的工作空间。设置 CLI 和技能非常简单，只需复制一行代码在终端安装即可（我此前已装好）。随后创建配置文件以连接数据存储端，此处为 Arize。该配置使智能体能拉取 Trace 数据及可视化信息，并获取评估与标注结果。
创建好配置文件后，需设置技能模块。根据所使用的编码智能体不同（如本次演示使用的 Cloud Code），可通过市场插件轻松完成配置。接下来我们将与 Claude 交互，让它查看这些 Trace 数据。在此过程中我使用了“危险地跳过权限”选项以简化演示流程，但这并非最佳实践。
我将寻找之前使用的提示词：“使用此技能并从该特定智能体拉取 Trace 数据”，以此让 AI 分析具体问题所在。
找出我们之前提到的，从任何评估或标注中存在的问题。进行你自己的分析，并告诉我未来可以构建什么样的评估体系，以确保不再遇到这些问题。这需要几分钟时间。在此期间，我将首先向你展示这些追踪数据的样子，以及如果你愿意的话，如何手动开始对其进行分类处理。
与此同时，让我们回到那个包含我们之前提出查询的实际代理程序中。我们将向它询问一个非常相似的问题，比如这次是否应该投资英伟达。这是一只更知名的股票。我们将获取数据并让它尝试提供相关信息。随着数据的流入，看起来我之前运行过这个程序。你可以看到它已经做了什么：你看到了我们提出的查询、最终生成的输出，我们可以稍后比较它与之前运行的相似程度。
你可以看到代理程序中实际发生的所有步骤：主管代理、金融数据代理，以及所有的 LLM 调用和工具调用。你可以立即获得大量信息，就像我们在初始幻灯片中所做的那样，来定位问题所在。现在看看 Claude 是否完成了？看起来还在运行中。我们就让它继续处理吧，这正是演示的重点。
在它运行时，大家有关于如何设置评估、追踪或相关内容的任何问题吗？有人想多了解一些吗？
好问题。是的，它会下载大量的追踪数据到你的本地系统中。让我展示它是如何访问系统的。当你赋予它这些技能的权限时，实际上是赋予了其底层 CLI 的权限。这意味着它可以集成不同的命令行工具：你可以设置和查找数据集、拉取数据，甚至通过 UI 在平台上代表你建立评估。
它可以持续监控代理何时失败、构建数据集并运行实验，基本上能做你在平台上能做的所有事情。有时它会下载数据，有时会发出 API 请求，这就是基本思路。关于 CLI 追踪还有其他问题吗？好的，让我们看看 Claude 完成了什么。哦，还在处理中。
我们可以看到它获取了跨度（spans），正在深入评估以找出问题所在。显然发现了一个关于数值可信度的大问题，正如之前有人提到的那样。我们还看到一些工具调用直接失败，出现了很多不同的错误。看起来它刚刚完成。
你可以看到一个完整的列表，显示代理出了什么问题以及如何修复。其中一个最令人担忧的问题是：44% 的交互产生了错误的摘要，这非常糟糕。另一个大问题是我们得到了很多捏造的答案，这与摘要错误一样严重。这可能相关也可能不相关，我们可以调试一下。
我们还看到工具被冗余调用的率相对较高，这浪费了时间、资源和金钱。这表明我们需要修复很多错误之处，而这仅仅是 Claude 自身分析的结果。它甚至能发现其他问题：静默的工具失败（声称成功但无实际响应），以及在工具失败时代理产生幻觉而不是披露事实。
这意味着我们不仅需要构建基于此的评估来理解工具何时失败，还需要进行提示词方面的更改以防止幻觉。它还会告诉你多种不同的事项以及它可以构建的评估体系。我们可以告诉它：首先建立“工具成功但静默失败”的评估，并修复数值可信度，确保回应始终基于实际参考点。
我们还将针对最初导致失败的跨度数据集进行测试，并使用 Arize 的数据集技能、评估器技能和实验技能。这里它将运行并建立这些评估。虽然我说得比较笼统，但本质上我是让它执行推荐的更改并为我们运行实验。这样我们可以对比失败点以确保修复有效。
在这个场景中，它会花些时间处理。为了节省大家的时间，我将展示之前的运行结果。因为这个过程需要时间，我不想让你们盯着屏幕看 Claude 发呆或做其他事情。让我们看看我之前实际运行过的地方……
让Alex，哦不，是Cloud Code继续回答我之前遇到的一些问题。其中一个问题是关于非美国股市的查询。有时我会尝试获取某些并非来自美国的股票信息，结果出现了错误，比如涉及韩国市场的情况。虽然这里看起来都是韩国的数据，但我们假设还有其他答案，可能是日本或中国等市场。用户希望能够在不同市场的股票之间进行比较，这显然是大家的需求，但我们此前并不支持这一功能。
Claude发现并定位了存在该问题的区域，尽管这里主要显示为韩国数据，但它成功找到了这些特定领域。随后，它为我构建了一个数据集，我可以利用该数据进行测试以确保功能正常运作。接着，Claude运行了一系列实验并做出了一些修改。它从初始的基线版本开始测试，由于存在缺陷，正如预期那样，通过率为0%，这与我们最初获取实际生产环境追踪数据时的情况一致。
它还尝试了一个快速修复方案，通过添加国家名称来标准化处理，但这次并未成功。原因是我调用的工具版本过旧，需要更新到稳定版。于是它进行了第三次迭代。从图表中可以看到，第一次尝试失败后，Claude返回并修正了问题，最终在最后一次迭代中将成功率提升至约90%。虽然尚未达到100%，仍需进一步调整，但相比之前已有显著改善。
这是一个很好的起步方式，让你从发现问题到实施修复都能顺畅进行。鉴于时间充裕，我想确认一下大家的状态和感受。各位是否有任何关于如何着手开始这一流程的问题？是的，这是一个很好的问题。他的问题是：实验、评估以及所有操作实际上是在哪里运行的呢？
在这方面，你有一定的自定义空间。在这个场景中，我将实验运行在我的本地机器上，我想这通常是大多数人的做法。之后，你可以选择将其托管在云端或其他任何你希望进行实验的地方。然后你可以在Arize平台上实际运行评估任务。在此案例中，我构建了“以LLM为裁判”的机制，让我们看看评估器本身。
我们可以看到我们构建了两个不同的评估器：一个是基于代码的，另一个是基于LLM的。实际上我是让Claude在平台上帮我构建出来的。最终采用“以LLM为裁判”是因为基于代码的数据设置遇到了一些困难，所以我们采用了两种方案。你可以看到LLM作为裁判是如何通过特定的提示词构建出来并运行，以便我们比较代理是否正常工作。
还有其他问题吗？刚才那个问题问得非常好。是的，这是一个非常棒的问题。评估的设置方式完全由你决定。当然，人们可以使用任何他们想要的模型。在当今这个AI模型几乎每隔一天就发布一个新版本的时代，没人愿意被限制在仅使用Claude或OpenAI。你可能想立即尝试最新发布的模型。
此外，有些人偏好成本稍低的模型，而另一些人则希望确保他们的评估处于顶尖水平。因为他们深知代理的质量取决于其评估体系，所以即使在生产环境中不使用最高端的模型，他们也会为评估选用顶级模型。因此情况各不相同，你拥有对自定义控制的完全权限。
例如在这里你可以看到，你有完整的模型提供商列表可供选择，甚至如果你愿意，也可以连接任何本地开源模型。是的，这个问题很好。她的问题是：如果我启动一个较小的代理来执行这些错误修复工作，这与使用Cloud Code相比如何呢？
实际上，你不必非要用Cloud Code。你可以使用任何你想要的代理类型。我们提供的优势在于一种技能，让你能够从追踪数据中提取信息来进行修复。你不是仅仅基于“我知道这是错的且输出不正确”来做出修改，而是基于更详尽的信息：知道哪里失败了、为什么失败以及如何修复。
因为你不仅拥有代码库的信息，还拥有其他APM工单或日志、Jira系统中的其他票证信息，以及实际的Arize追踪数据。这些数据能告诉你代理走过的路径、出错的位置、评估结果和标注信息等，从而提供更精准的修复依据。还有其他问题吗？是的。这些功能在Phoenix中可用吗？
这是一个很好的问题，答案是肯定的。他问的是这些功能是否在Phoenix中提供。Phoenix是Arize的开源版本。我相信在Phoenix中也具备技能和MCP功能，你可以将其连接到你的代理中，它同样能够提取相同类型的信息。当然企业版会有一些锦上添花的功能，例如以某种更易于格式化和设置的方式访问在线评估功能。
企业版还提供更丰富的仪表板和其他一些特性。但是的，在CLI中你可以连接技能到你的编码代理。好的，总结一下刚才的问题：你会如何分类某个结果是像“糟糕的摘要”这样的坏代理输出，还是好的？这是一个很好的总结。
她问的是：在我之前展示的环节中，Claude的回答指出有一个“糟糕的摘要”，我们如何判断什么是坏摘要或好摘要？在这种情况下，我实际上设置的是基于我之前建立的一个评估标准。因此我们可以查看这个评估器。让我看看具体是哪一个，我记不太清了，但我打算打开其中一个来确认是否正确。
如你所见，这基本上就是我创建的摘要评估器。它主要审视我们在整个代理运行过程中收集的信息以及提供给该代理的所有上下文内容。
总结代理并确保它引用了正确的要点，相应地回答问题等。这就是我们确定摘要好坏的方法。
如果我们一开始就设置技能来查看它是否能给出好的总结呢？就像我们设置技能而不是运行那样，让它一直给我们一个好的摘要。 >> 是的，很好的问题。所以她在问为什么我们不能只是设置技能来确保它给出好的摘要？当然可以，这正是你想要做的。你要确保更新你的提示词、技能和编码工作流，以便代理能给出最好的摘要。评估邮件只是用来帮助你确定问题所在、监控这些问题并确保它们不再重复，对吧？所以你设置了那个技能，很好，它工作了两个月。但两个月后，由于模型回归或人们以不同方式提问，你最终会得到不同的结果。你不希望性能因此下降，所以你需要能够监控和观察这一点。这就是评估的目的。这样解释清楚了吗？太好了。
我不确定我们还有多少时间，请继续 >> 稍后评估代理和 SOC。
所以你的问题是如果我在使用代理时遇到了 linting（代码风格检查）问题 >> 代理似乎更像是一个 >> 好问题。是的，所以他基本上是说嘿，你有没有遇到过这种情况：你给了 Claude 所有这些技能和追踪信息等各种数据，但最终大多数时候我看到使用 Cloud Code 或其他编码代理时，它们最终专注于 linting 而不是其他问题。我说的对吗？
是的，这是一个非常好的理解，这也是我们构建这些技能的原因，它们专注于确保代理不会过度关注那些实际被指出的问题。所以它们会获取所有追踪信息，从而理解嘿，这不会是一个基于 linting 的问题，因为你可以看到它调用了错误的工具，而这并不是由 linting 引起的。它具有推理能力来理解这一点。老实说，在使用这些技能时我没有看到那么多这种情况。太棒了。所以哦是的。
系统是否让理解变得容易？抱歉。 >> 好问题。是的，所以他的问题是它是否让人很容易理解运行这些评估的成本是多少？绝对可以。在平台上进行评估的一大好处是，你将能够获取你代理所做操作的完整追踪历史，这也带来了额外的好处：你可以直接看到一个不错的成本估算。因此你将能够理解你的代理实际上花费了多少，因为当然每次运行另一个大语言模型都会产生额外成本。所以你要确保它不会失控。
而且当然，构建评估（无论是在 UI 还是通过编码代理）真正好的地方在于你可以设置基本要求。嘿，我们希望采样特定数量的数据，这样我们就不必在所有 100% 的追踪和调用中运行它。你可以让它专注于特定领域，当然你也可以在编码代理或平台本身中进行规定。
作为对我们今天讨论内容的一个简要回顾，再次说明那个是错的哦我想我在这儿有。
基本上我想要给大家的要点是这些 AI 代理很棒，它们会做你要求做的几乎所有事情，但它们不是魔法。就像他说的，它们确实可能专注于 linting 或陷入小细节中，但它们最好的地方在于能自动化你的整个工作流程从头到尾。无论是观察问题所在、找到这些问题、实际拉取下来理解问题所在、创建数据集、构建精确修复方案，测试以确保它们有效。最后你可以作为人工手动确认嘿它不仅仅是回去修正 linting 更改，对吧？我们可以确保它做出的改变确实帮助改进了代理而不是导致性能下降。这就是我今天想展示的大致内容。
关于这个还有什么其他问题吗？在我可能再展示一点之前，哦还在完成我之前尝试做的事情。我希望它在这之后能做完。花了大约 14 分钟。但在完成期间，关于如何使用我们的代理自动化工作流程和改进你的代理还有什么其他问题吗？是的。
好问题。所以他的问题是我们要主要依赖 Claude 或任何这些编码代理来实际给出评估，看看事情是否运作良好吗？嗯是的你可以完全依赖 Claude 构建一切。你也可以手动做，或者要求 Claude 执行你想要的特定评估。所以在这种情况下当你看到那个整洁的表格时那实际上是由我和我团队在此之前设置的评估定义的。我们查看了嘿这些是我们知道在大多数以此工作流工作的代理中存在的潜在限制的具体领域，我们将它们设置为通用的因此我们得到了一个糟糕的摘要。我们有嘿代理健康吗？它给出的是正确的工具调用吗？对吧？我们知道这些是通用领域，但 Claude 能够做的是查看我们的实际追踪数据基于那些追踪理解我们今天陷入的实际问题是什么。
我们在生产环境中拥有实时代理，我无法手动遍历所有这些并找到它们但 Claude 可以或者 Claude Cursor CodeEx 等等对吧？这就是你能够赋予这些编码代理的最大超能力之一让它们为你做这件事。
我在这儿看到另一个问题，好问题。所以他的问题是是否有任何基准数据集我们可以看到或者任何类型的可视化能告诉我们嘿这是更高质量的 LLM 用于评估，更昂贵或更便宜？嗯现实来说没有 [笑声]那将是你必须为自己进行分析的东西你必须弄清楚因为最终我喜欢说的是如果你使用现成的评估来判断你的代理你将得到现成的结果而这正是你在构建定制化的 AI 代理时所不想要的，这些代理是为你个人定制的。同样适用于
基准测试确实很棒，它们能告诉你：“嘿，这是一个优秀的智能体。不，抱歉，是一个优秀的大语言模型。”但现实情况是，你真正关心的是：它是否适合我？这需要针对你的具体用例进行定制。例如，如果你是在构建金融领域的应用，可能会选用特定的模型；如果是用于法律或金融相关的场景，可能还需要稍微不同的模型。因此，具体选择取决于你的构建目标和应用场景。