[音乐]

大家好，谢谢各位参加这次会议。如果我的声音有点沙哑，请见谅。我连续做了三场演讲：周三的一场，昨天的一场主题演讲，以及今天这场研讨会形式的会议。我是文森特，接下来我将谈论“可变评估”（Malleable Evals），即从静态衡量人工智能到适应性系统的转变。现在，让我简单介绍一下我是谁、做什么。我自称“友好的极客”（Friendly Can Car，注：此处为演讲者自创或口误，结合上下文指代爱折腾的人），我使用人工智能和技术，总是处于前沿地带。

对于那些没看过我主题演讲的人来说，我确实喜欢活在边缘，做一些有趣的事情。比如这张照片，是我在2013年使用VR头显时的样子，那时候人们甚至还没听说过VR。那副头显上贴着警告标签，说每次只能使用5分钟。结果我用了3个小时，之后又吐了3个小时。所以，在技术领域，尤其是处于前沿的事物，往往会有些粗糙、怪异。但在我看来，这挺有趣的。

当我们谈到评估（Evals）时，先做个铺垫：我在Comet的工作涉及评估，我从事评估研究，与大学合作，为大型企业和组织进行基准测试和运行评估，客户包括Uber、Netflix，甚至英国的银行。但最近有一种说法，甚至是个玩笑，说“评估已经有点死气沉沉了”。这虽是个玩笑，但也有一定道理。我希望借此机会引导大家进行思维转变，不仅解释评估本身，更要探讨代理式人工智能（Agentic AI）领域正在发生什么，以及如何将这些洞察转化回评估实践中。

当我们思考软件工程这一实践时，我们是如何衡量事物的呢？我们通常从“这个东西旨在做什么”开始。我们会准备一组示例，编写单元测试。我们可能会进行手动回归测试，比如：“嘿，当我们执行A和B时，有时会发生C，而C是不利的。比如，让我们不要那样做，不要让人们戴上VR头显后就呕吐。”我们还可以利用CI/CD流水线，确保产品发布后能按预期工作。

但在工程领域，我们更多地进行的是混沌工程（Chaos Engineering）和可观测性实践。对于那些不熟悉“混沌工程”这个词的人来说，它基本上意味着尝试各种随机操作，故意破坏系统，享受与技术互动的乐趣，看看能在多大程度上拉伸系统的极限，以及它能走多远。

当我们把这种思维应用到传统的人工智能和数据分析领域时——包括最近的2025年——我们会做静态基准测试。例如，我会问：“我的AI在风险合规方面表现如何？”我会问它很多问题，确保它不会谈论向我推销金融服务，因为那是绝对禁止的。我们会手工打造一组问题和示例，坐在那里微调系统，确保它在部署AI系统或模型之前绝对完美。我们会进行某种离线评估，循环运行这些测试。

但我们缺失了混沌工程的空间。我们缺失了“接下来会发生什么”、“我们如何搞砸它”以及“我们能在多大程度上拉伸这个系统”的认知。我认为这是该领域一个诚实的空白，这也是为什么我们如此执着于基准测试和评估。如果你去任何学术界的AI会议，人们谈论的全是基准测试。我曾创建一个关于“LLM如何看待加法”的基准测试。虽然这很好，但它如何真正帮助到我呢？

最终，你会得到一堆庞大的数据集，试图部分解释代理（Agent）发生了什么，直到出错为止。而出错只是时间问题，一旦出错，你就得回到原点，试图弄清楚发生了什么。原因在于，我们的AI应用并非静态的，但我们却像对待静态软件一样对待它们。是的，发布软件时我们可能会更改单元测试，这很快，但现实是，软件本身也正变得“可变”。

回想我昨天的主题演讲，我是OpenClaw的核心贡献者之一，它的“测试框架”（Harness）会自行改变。框架会发生变化。如果你想创建技能或做其他事情，它会适应。那么，在这种软件以闪电速度交付的过程中，你的基准测试如何跟上这种变化？你的基准测试如何适应这一空间？

这里有一篇论文，我不记得它何时发表，但其中关于“LLM评估的自适应测试”这一概念，或许有些革命性。如果我们的基准测试能随着应用一起变化，会发生什么？虽然不是我写的，但有人做了这件事，这很好。但这引出了一个核心问题：为什么静态基准测试是静态的？为什么我们不采用更自适应的方式进行测试？

这可能很好，这是一种更有选择性的测试，让我们更聪明地测试。但这仍然引领我们踏上这段旅程。我认为这是一种思维转变。现在，让我们回顾一下人工智能领域的现状。如果我们专注于LLM领域，我们曾有过“提示工程”（Prompt Engineering）。那是一个世界，人们说：“嘿，我要无限滚动，打磨指令。我会把随机词砸进AI里，希望它能改善。”

如果我在构建银行应用或创意应用，我会塞入各种随机词，看看另一端输出什么，看看能否激发创意。这在某种程度上类似于……我不想贬低医学，但就像：“嘿，我要制造一种治疗肝病的药物，结果它治愈了疼痛。哦，好吧，现在这是止痛药了。太棒了。”

我们对提示工程做的也是同样的事情，只是把词砸进去，希望它能产生变化。不知为何，这在2023年左右“死”了，但人们仍然在做。这有点……

后来我们进入了上下文工程的世界，我认为这使得评估变得稍微相关了一些，因为情况变得更加复杂，涉及多个步骤。数据开始涌入，搜索成为一种功能，我们开始利用检索增强生成（RAG）和工具调用等技术引导智能体的方向。最精彩的部分在于，如果你是一个大型智能体系统的组织，你可以将这个智能体拆解为各个部分。例如，你可以拥有一个执行销售代理功能的MCP工具，并测试该部分是否按预期工作，确保其正常运行。

这种工具调用并将大型智能体拆解为部分的过程，使评估变得更具可控性且更易于理解，但仍未完全切中要害。那么2025年我们该往何处去？我们可以看到代码变得廉价，令牌（tokens）唾手可得，这提高了软件和应用开发的效率。更重要的是，模型变得极其强大，许多人尚未充分认识到，当前运行的许多AI应用，其底层模型能完成令人惊叹的任务。

我曾深入研究优化问题，发现这些被视为通用系统的模型能解决ARC-AGI等难题。ARC-AGI包含许多对人类来说极难、但机器能通过模式识别解决的谜题。LLM实际上具备这种模式识别能力并开始解题。这引出了“意图工程”的概念，即机器能基于意图自我优化。我们看到OpenClaw及其他平台（如Claude和Codex中的智能体）正在尝试理解并适应用户，以提供更好的体验。

然而，当机器具备意图时，评估变得更加复杂，因为每个人的体验都不同。我们如何围绕这种方法和理解构建测试？这加剧了对评估的需求。尽管有人开玩笑说评估和可观测性已死，但现实中，人们比以往更想了解智能体应用各层内部的运作情况，以消除“不安全”或“未知”的模糊感。我们需要将这些转化为有意义的指标。

回顾之前的幻灯片，我们从静态基准测试和离线评估，转向基于意图的结果。我们需要定义智能体中的模糊性和个性，并思考这对组织的意义。研究表明，我们可以像在学校评估艺术作品一样建立评分标准。我们还可以从追踪数据中自我策展测试套件。如果智能体80%的时间行为一致，但客户群发生变化，他们的提问方式也会改变，智能体内部也会随之变化。

为什么我们不测量这种变化？为什么不将这些追踪数据反馈给智能体，告知用户或所有者测试套件已失效并自动更新？我们可以实现始终在线的评估优化。一旦智能体基于追踪数据而非静态基准进行测试，评估就可以作为一种持续服务运行。最后，我们可以实现“遥测闭环”。

我有一篇关于此的论文：当编写软件、MCP或智能体系统时，如果编排工具能感知遥测数据（如故障点和成本），并设定条件，它就能自我修正。我们看到编排工具在遇到错误时能自行修复并继续运行。这不再是预测错误，而是聪明地利用数据让智能体自我愈合。我称之为“评估钙化”问题，除非我们采取更智能的方法，否则情况只会越来越糟。希望大家深入思考这一概念。

你可以尝试像 Kapathy 的自动研究这样的研究输出。这是一种非常基础的自动优化，使用 Python 实现。你设定一个目标，设定一个指标，它就会自行调整，自我微调。你可以对任何事情都这样做，对吧？比如，你可以用它来找出制作最美味烧烤或最便宜烧烤混合料的最佳比例，它可以是任何事物，对吧？你只需设定一个奖励信号。但关键在于，你的用户会有一个明确的意图点，你希望朝着这个点进行优化。

那么，我们如何让机器自我纠正，并将此视为一种评估呢？这样，我们的评估就不再是数据集或起点，而是我们想要达到的最终状态，然后我们让机器去执行工作。我们有一种评估方式，其中只有智能体，我们只定义最终状态。所以在结束前，我想再强调一点，以便我们提前结束并回答问题或其他事项。

你可以想象这样一个场景：80% 的内容是静态的，即以有意图的方式定义的，但那 20% 的内容将不断变化。正是这 20% 的内容会让你的业务陷入困境。可能会有人提出奇怪的问题，或以极其怪异的方式使用你的智能体，这对你来说将是绝对的灾难。

那么，你如何创建智能体来管理和维护这 20% 的内容，时刻关注它，并相应地调整和改变你的评估标准呢？我认为人们需要开始将评估视为代码、软件或活生生的智能体，而不是静态的数据集；不是某个时间点的快照，而是一种自我优化、不断成长的解决方案。

基本上就是这样。我原本打算进行更深入的演示，展示我们在 Comet 中如何应用这一概念，但最终状态尚未完全完成，将在接下来的几周内完善。但我希望给大家提供一些不是销售性质的内容，让你们能够在概念上将其映射到自己世界中的问题空间。

因此，如果你从事软件开发或人工智能智能体的工作，我认为你需要开始意识到，智能体会自行发生转变，问题空间和数据集也会发生变化。你也需要以智能体的思维方式来处理这个问题。谢谢。

[掌声]

[掌声]

[音乐]