智能体如何在你睡觉时自我改进

今天我会讲这个闭环是什么、如何构建，也会演示一个示例智能体，看看它是怎么工作的。这场工作坊有一个小时。大家知道工作坊有时会很忙乱，Wi-Fi 也可能断，所以我已经把所有内容准备在屏幕上，会带着大家走一遍。跟着操作是自愿的，不过我很推荐，因为我自己动手敲键盘时学得更好。如果你遇到问题也不用担心，Lori 也在现场，很乐意帮忙排查。听起来怎么样？好。

我是 Fuad，在 Arize 做产品。我们接触很多智能体。我猜你们都很熟悉智能体是什么、它们会怎样失败，以及它们具有非确定性。这是一个经典的工程问题，而智能体让它变得难上十倍，因为结果不确定。智能体能做很多事，而且做每件事又有许多不同方式，因此理解它们的失效模式更困难。

再加上智能体数量可能有成千上万：内部智能体、编程智能体、营销智能体，当然还有面向客户的智能体。所有这些都会给问题带来大量噪声。我们究竟怎样构建一个闭环，让智能体能够利用人类提供的反馈、客户反馈，以及实际证据（比如 trace）来改进？这就是我今天要讲的内容。Signal 是开箱即用的一个实现，我今天会重点演示。我们还有托管智能体平台，让你按自己的需求定义这些智能体的行为。数据集、评测、实验等也都会涉及。

这就是我们要解决的问题。抱歉放了这个梗图，Claude 的幽默感不太好，不过我觉得它挺能说明使用场景。在过去的软件工程世界里，SRE 大概会是第一张图里的那个人：典型情形是凌晨四点，PagerDuty 发来通知，你的智能体在生产环境里弄坏了什么东西。这里的例子是一个购物助手，它在生产环境里告诉所有客户：“我们不卖任何桌游。”这显然不是你想遇到的情况。

智能体还有更糟的失败案例。你们可能听说过加拿大一家汽车经销商发生的事：有人通过聊天机器人，以 5 美元买到了一辆车，我想好像是 Prius 之类的车。经销商当然没有兑现这笔交易，但现在这成了法务的问题。

智能体可能因为各种原因以许多不同方式失败，所以我们很需要进入图里的“之后”阶段，让智能体学会修复自身，并把反馈闭环构建进去。我也会谈谈在这样的世界里，人类还能在哪些环节发挥价值。

接下来是跟着操作所需的东西。就像我说的，跟做是自愿的，我会带大家走完整个流程。我们有一个小时，可以把剩余时间留给提问，也可以花一部分时间试试这个闭环。如果你有时间，我建议现在花大约 30 秒到一分钟，注册一个完全免费的 Arize X 账户。你需要一个 space ID 和 API key，我可以演示怎么获取。你还需要某种编程 API，或者——我说错了——一个 LLM API 提供商的密钥。

这就是我们的应用：一个通过聊天购买玩具的体验，叫 Wonder Toys，非常简单。你可以在聊天里询问有哪些商品，也可以直接聊天下单。整个应用都在我的电脑本地运行。这就是我们今天要用的智能体，我们会演示如何为它添加埋点、如何配置它，从而构建反馈闭环。

我先在这里停一下，给大家 30 秒试着完成前面的准备。还是自愿参加，我肯定不想因为 API key 卡住整场工作坊。好，主要就是三件事：把代码仓库跑起来、运行应用本身，并确保你有一个真正为智能体提供能力的 API key。这里说的不是 OpenAI 或 Anthropic 这样的模型提供商 API key。然后这一部分是安装一些 skills，让你的编程智能体能以更明确的方式使用我们的工具。Node 和 Python 是用来运行代码仓库的，就这些。好，为了不耽误时间，我继续讲。

通常从第一步开始：“好，我们在追踪智能体的行为。”这样它们失败时我们就知道了，也能知道它们调用了哪些工具，还能看到这次交互里智能体的整棵 trace 树。这是第一格。举手示意一下，现在有谁在追踪自己的智能体？好，确实有不少人，很好。

下一阶段是：“好，我知道智能体在做什么了，但它做得对不对？”我该怎样给它打分、评估它？在这个行业里我们把这些叫作 evals（评测）。我觉得有些团队已经走到这一格。有人在评估自己的智能体吗？你们有针对 trace 运行的评测吗？好，有几位。好，挺多的。没错。

接下来，总得有人去读这些 trace。我们想借助智能体来实现的，大致就是这件事。但现实地说，如果公司内部有编程智能体，根本不可能有人把所有 trace 都读一遍，对吧？或者，一个服务数百万客户的聊天机器人，也不可能有某一个人能读完所有 trace。

然后，你还希望能把这些失败保存成测试。每次出错时都把它记录下来，之后当作回归测试，这样就不会再把同一件事搞砸第二次。最后，你需要做出修复，并证明问题确实修好了。最后三个方框里有人已经做到这一步了吗？太棒了，好，有几位。

那要怎样把这些环节串起来？又该怎么让它们……

整体流程是：trace、Signal。Signal 是我们开箱即用的 SRE 智能体，我会在平台里给大家看。Signal 会读取 trace，从失败中创建数据集，自动为你提出一项评测，修复出错之处，然后运行实验，验证这个修复是否有效。

接下来由你审查这个修复，决定是否合并，然后进入下一轮闭环。每一步都会积累更多上下文，让智能体持续改进，也不断适应新的使用场景。比如说，我想给这个智能体增加一键结账功能。这个闭环带来的反馈不只会影响产品路线图，也会进入工程可靠性团队的工作。接下来我会带大家完整走一遍这个闭环。

今天演示的是 Wonder Toys 购物助手智能体。我们特意在里面埋了一个 bug，供演示使用——希望你们不会在自己的智能体里埋 bug。这个代码仓库里有好几种智能体框架，主要用到 FastAPI、Next.js、ChromaDB，以及一些智能体 SDK。它会把 trace 发送到 Arize AX。智能体有几个可用工具，其中有一个工具带着 bug，会错误地触发筛选器。

先来看看最基础的追踪体验。我们把 trace 配置做得很简单，不需要你手动埋点才能获取智能体信息。我们提供了 skills 来封装 CLI 和 MCP，帮助你快速开始追踪。主流模型提供商和智能体框架都已经支持自动埋点，而且全部开源，因此上手很容易。听起来你们很多人都熟悉追踪，所以应该很熟悉 trace 树长什么样。

用户问：“给我看看适合 9 岁孩子的玩具。”这会经过完整的请求路径：智能体被调用，调用模型，发起 LLM 调用，也能使用搜索商品等工具。你可以看到智能体在底层做什么的各种信息。这些属性会显示开始时间、结束时间、延迟、输入内容、传入的元数据、它处于计算图的哪个阶段、从数据库取回了哪些结果，以及智能体在每个阶段能访问到什么信息。

这些信息很有价值，但你大概不想凌晨四点读 trace。为了找出错误在哪儿，要在凌晨四点读成千上万条 trace，确实很难。我们想让智能体能够利用这些信息，看看怎样真正闭合自我改进循环。

刚才我演示了 trace。如果想添加埋点，我们用 AX CLI。它有引导式设置，很容易开始。你只需要一把来自 Arize 的 API key，它就会把那些繁杂的属性转换成刚才看到的漂亮 trace 树。每次工具调用都会生成一个 span，包含参数和调用结果；你还能看到模型调用、prompt token 数量，以及监控系统运行情况所需的基本信息。

它也支持分组。你可以查看一个会话，其中包含与同一客户多轮来回交互的内容，而不只是单独一条客户问答对应的 trace。接下来进入 Signal，这是平台里的第二步。

今天演示的基础操作是让 Signal 连接 GitHub 代码仓库。Signal 这个智能体会读取另一个智能体的 trace，也会读取那个智能体的源代码。它根据该智能体在生产环境里的实际 trace，以及代码里的智能体定义，提出针对所见问题的修复方案。

我快速展示一下。我们的 Wonder Toys 智能体正在发送 trace。我们能看到所有用户请求。我在今天下午 1 点演示前做了不少操作。还能看到一些基本指标：延迟、token 数量，以及这个项目的运行成本。这里有 Signal 标签页。Signal 会把它从 trace 中发现的问题聚类，并为这些问题识别、提出修复办法。

在这个智能体里，我们故意放入的 bug 会导致重复的搜索重试。Signal 根据进入项目的 trace 发现，商品搜索调用存在问题，导致连续发起三次 LLM 调用并造成高延迟。具体来说，部分筛选查询里的大小写处理不正确。

如果还记得开场的梗图，Signal 的作用就是避免你凌晨四点被叫醒。它会发现问题，对问题簇进行分析，撰写概述和分析，给你写出修复方案。之后你可以创建评测，自动捕捉今后出现的同类问题，并根据这些评测触发操作。比如未来 30 天内任何时候再出现这个问题，系统都会自动发出警报，团队可以立即分诊处理。

你也可以把失败案例加入数据集，保存这些失败模式的快照，以便未来做回归测试。这里还有 GitHub 图标，可以连接代码仓库、创建 PR 或 issue，也可以让 Signal 写 PR。我已经让它尝试过，所以你能看到 Signal 为修复问题做过的 PR 尝试。我点进这个会话看看。

这个智能体运行了 6 分钟，也根据 trace 在代码仓库里找到了根因：商品类别以小写、用连字符连接的 slug 形式储存，但组件传入的是人类可读的名称，采用标题式大小写并以空格分隔。比如搜索 car games 时，如果不做格式归一化，实际上一个结果也搜不到。于是智能体转而搜索每一件商品。你可以想象，这会让延迟飙升到 14 到 17 秒。

大家目前都跟得上吗？现在我们有一个智能体，发现了一个问题；Signal 替你读取 trace，并通过 GitHub 集成提出修复方案。接下来……

在托管智能体平台里，你可以使用我们的开箱即用模板。比如 Signal 会按计划检查项目 trace、聚类失败并提出修复方案。我们还有一个成本智能体，可以找出用昂贵模型做简单工作的情况，推荐更便宜的路由方式，并量化能节省多少钱。

不过有意思的是，你也可以从头创建智能体。Agent Studio 允许你选择智能体配置，将它指向持续接收 trace 的项目，为它指定任务，还可以给它连接 skills。比如刚才提到的 GitHub 就是一种数据源。也许你还使用第三方系统保存 RAG 相关信息，想检查智能体的权限，确保它调用的内容没有超出权限边界；你可以连接一个 skill 来做权限检查。你也可以连接 DataDog 之类的其他 APM 系统，拉取更多日志。

只要你有 API key，并且相应能力能由智能体运行框架调用，几乎没有什么限制。底层我们是在平台里用 Arize 托管沙箱来运行这些智能体。你也可以接入自己的运行框架和沙箱提供商，比如 Modal、Daytona、E2B 等。我们支持 Codex、Cursor、Cloud Code、OpenCode 等运行框架，之后还会陆续支持更多。

大家大致明白了吗？平台里有一个托管智能体来做这些事。你可以设置自己的自动化，由定时计划触发，也可以由警报触发。比如延迟一旦超过 10 秒，就自动启动这个智能体进行调查。调查智能体是其中一种，能够处理 SRE 场景；此外还有成本视角、产品分类视角。这个智能体平台能以很多方式处理你的 trace。好，我继续讲这些内容……

我认为“添加到数据集”这个流程是这里最重要的部分之一。因为要怎样实现持续改进？你得记录过去发生过哪些失败，并在今后用回归检查防止它们再次发生。把这些案例加入两个数据集，就能形成一种持续生长的固定测试集。

在发布代码之前，你会在代码里定义测试用例。大家都应该这么做，也希望现在都有智能体帮忙。但“持续生长的固定测试集”是个新颖的想法：随着你加入新的使用场景、发现新的失效模式，这些测试案例也会随之变化。它能帮助实现自我改进闭环，因为你不再受限于某个时点对失败和失效模式的单一定义；而是随着智能体在生产环境中出错，不断自然扩展对失效模式的定义。

可以这样想：每次骑自行车时，你都会注意到自己骑车方式上的一些问题。渐渐地，这些经验会深深印在记忆里，骑车就变得轻松自然，你甚至不会再去想骑车可能出现什么问题。我两个月前确实从自行车上摔下来，摔断了脚，所以才讲这个小故事。不过通常你不会再去想要把左脚放在左边的脚踏上，因为这已经融入你的学习过程。这就是我们想让智能体做到的事。

关于数据集，一旦你有了这些持续生长的固定测试案例，就要把这些案例里的预期行为明确编码下来。这就要用到评测……

如果你参加过 Arize 之前的工作坊，我们曾深入讲过评估器。评估器有很多种，我快速概括一下。代码检查运行成本很低，适合确定性检查：某个字段是否存在？是不是有效 JSON？是否符合精确规则？筛选器有没有生效？工具调用时参数对不对？这类检查都很容易做。

LLM-as-a-judge 评测也能处理需要定性、比较模糊地分析 trace 的场景。它会再调用一个 LLM，为另一个模型的 trace 结果打分。显然这会增加成本，因为每条记录要多调用一次模型。不过你可以自己设置采样和过滤，不必对 100% 的 trace 都运行评测。评测设计中有一些取舍，我们可以之后再讨论；这大致就是 LLM 裁判的用途。

对于更加开放的问题，还有“智能体作为裁判”的概念。你未必确定具体该评估什么，只知道一个目标，然后把目标是否达成的判断交给智能体。智能体可以自行设定评判标准和分数，也可以自行完成整个过程。这显然是成本最高的方法，因为底层会发生多次 LLM 调用。

决策模型大概已经出现一个月了。Arize 的 Lauer 发布了很多材料，介绍如何对它们做基准测试、它们如何运作，以及其中的取舍。我想说，和经典 LLM 相比，决策模型是对 trace 运行某些检查的一种非常便宜的方式。它们会给出类型化选择，比如“是/否”、选项或分数。

当你有了这样的评测信号，知道结果从定性上看方向对不对、有没有通过评测检查，也有了 trace 数据，这些就为编程智能体提供了非常丰富的上下文，让它来实现修复。在这个例子里，Signal 在 Arize 托管沙箱和编程运行框架中运行，替你实现这些修复。处于开发阶段时，你也可以通过 CLI 把实时 trace 拉到 Arize AX，立即作为上下文交给其他智能体，让它们帮你处理 PR。

此时就需要人类来做检查和平衡。我认为人最能发挥价值的环节之一，显然是验证修复、阅读 PR。也许有些团队不想逐个审查所有 PR；但如果是金融这样的高风险应用，我相信你会希望在人类读过 PR 后再合并。这是人类参与的一个高杠杆环节。

另一个环节是数据集整理。我们把失败案例加进数据集的流程留给人工，就是因为要判断这些发现是否足以加入测试集，仍需要人工步骤和判断。评测设计也一样：虽然智能体可以帮你编写评测，但人可以参与设计，因为你是在把自己对“什么是好”的品味传递给智能体……

这会打开 Alex，这是我们内部的智能体。我明天会专门做一场关于它的演讲。它能根据这些证据为我创建评测。根据这里 trace 中支持的证据，我们可以在 prompt 模板里明确今后预期的行为，以及怎样确保评测能够触发，并在出现错误时判为失败。

这是它生成的评测：“你是一个有帮助的 AI 机器人，负责检查商品搜索中的重复重试。检查完整执行轨迹，包括工具调用；判断是否有不必要的工具调用；如果 search product 被调用超过一次，就将其判定为一次冗余重试，并把分数和分类结果写到 trace 上。”

之后你可以在进入项目的新 trace 上运行这个评测，确保抓到问题。你可以监控、绘图、据此创建警报，也可以追踪评测本身的开支。随着时间推移，你的开发流程可能已经把它固化为回归检查，于是就不再需要在生产数据上部署这个评测。你不想把模型 token 花在每一条 trace 上。你可以查看一段时间内的成本，并停用这个评测。

接下来是：我们有了一个修复。Signal 发现了问题并分析了代码仓库，我们也创建了评测来捕捉下次出现的同类问题。我们还把……

这是一个内容非常丰富、很深入的领域，我就不花时间介绍所有现有框架和服务提供商了。今天早些时候 Phoenix 团队讲了他们在 Phoenix 中的 Harbor 集成。我们真正关心的是：证明修复有效，同时证明没有破坏其他东西。在非确定性系统里，即使只修改一点 system prompt，也可能影响其他你没想到会出问题的工具。这种连带问题必须防范。因此要证明修复确实有效，而且没有造成其他回归；这就是实验阶段。

Arize 支持多种实验类型。我刚刚跑的是一个“类别代码枚举修复”实验。你可以看到，这个实验正在运行实际的评测。我们有一个包含失败案例、持续生长的固定测试集，也有一个建议的修复。接下来我们要让智能体在这些失败案例上重新运行，并为结果打分。达到什么门槛由你决定。我的例子得分是 88.9%，我觉得相当不错，于是想：“可以发布了。”

达到门槛后，你就有结果可以证明智能体做出的修复有效。智能体也可以通过 AX CLI 替你运行这些测试。Signal 在发现失败案例并访问智能体代码后，可以把这些失败案例重新送入智能体，用第二版修复重放，再给结果打分。

所以，早上回来时，你不用凌晨四点爬起来处理。你拿到的不只是一个包含建议修复的 PR，还有验证结果告诉你：“这个修复已经通过验证。我重新运行了之前失败的测试，重新测量延迟和工具调用重试；现在不再重试工具，延迟也降低了。还有另外三项评测也不能退化，所以我也检查了它们，确认没有回归。”

随着这个固定测试集不断增长、加入新案例，实验会越来越稳健。在平台里，你可以查看实验结果、输出和评测。如果你不同意智能体给出的输出，可以为它添加注释；这些注释会成为下一轮运行的上下文。

大家大致清楚这个实验流程了吗？简单说，就是拿测试案例和你创建的评测作为基准，在修复进入生产环境之前验证它。你也可以把它放进 CI/CD 流程，具体如何配置由你决定。运行智能体可能很贵，所以要自行权衡。评测也一样：如果用 LLM 裁判，要谨慎选择模型、运行评测的时机和采样率，避免成本不断膨胀，或每次提交代码都花大量费用来验证修复。

等待你来处理的是确认这些问题是否真实。不能相信这个智能体报出的每一个问题。我建议把它当作起点，验证修复，并运用判断力确认问题是否确实存在。

把正确答案应该是什么写下来，也属于注释流程。你运行实验后得到新输出，可能觉得这不是完美答案，也不是智能体应该采取的完美轨迹；你可以用注释功能把自己的判断标准明确编码下来。

要不要合并修复由你决定。你可以自动合并这些 PR，但我会把这个决定留给你自行判断。然后是部署、升级新版本。比如我有了 V2，验证过了，确认问题真实、创建了评测、查看了分数、验证了修复，也认可并审查了代码，现在就该升级智能体了。

另一个很有意思的地方是可以明确使用置信度分数。特别是决策模型会返回明确的置信度，我们可以把低置信度结果自动路由给人工，进入注释队列。这样你不只是负责审查输出，还有一个基于所有低置信度结果自动准备好的工作队列。我们的某些基准测试显示，这些置信度分数表现不错；当然具体要看使用场景和行业特点。

我不会说所有人都该把 80% 置信度设为统一门槛。设定适合自己的阈值很重要；阈值确定后，就能把低置信度案例自动分配给人工注释。比如我们看到的垃圾信息测试中，有 4.6% 的案例置信度落在 0.3 到 0.7 之间，需要交给人处理；其余案例保持了 99.5% 的准确率。这是垃圾信息检测这个特定领域的一个例子，那里的置信度阈值可能更明确。具体仍取决于使用场景。

我认为我们对未来的愿景是运行完整的端到端闭环，几乎不需要人参与，直到某个时候需要你亲自测试，比如在界面里点击操作并验证某项功能。

实验设置有很多服务提供商和方式，比如 Harbor。大多数讨论都围绕着运行智能体需要多少依赖：实验时要连接模拟数据库吗？要禁用一些工具吗？要把整个系统放进 Docker 镜像里运行吗？能安全做到吗？我鼓励大家思考这些问题。我们的这个智能体很简单，直接完整运行它即可，没有外部依赖；它会启动自己的数据库，再把请求发进去。这可能是比较简单的场景。如果你的业务依赖很多外部系统，实验就会复杂得多。

我们的目标是实现从 issue 到实验的一键操作：“这里有个建议修复，帮我测试。请启动所需的全部基础设施来测试它。”

除此之外，我们也在改进 CLI，希望能让你在日常工作环境里连接 Signal。你可以在 Slack 里提及它来沟通，也可以通过 API、CLI 和 skills 使用本地智能体，让本地智能体汇总 Signal 发现的问题并进行检查。我们已经能从 issue 和相关 trace 直接起草修复，并把证据放在旁边。比如 PR 描述里会列出实际失败的五条 trace，方便你验证。

现在 Signal 也会替你提出评测方案，检查现有评测的健康状况。如果某项评测有 99.999% 的通过率，也许没必要继续花 token 跑它，可以把它退役。如果某项评测状态不佳，则应让它变得更稳健。我们还有一套评测对齐流程，确保裁判的判断符合你的预期，而不是输出你不认可的分数。

实验流程就是在智能体实际运行的地方，用数据集对它进行测试：可以像这个简单示例一样在笔记本电脑上跑，也可以在更复杂的基础设施上运行。

我很希望大家能开始尝试。这里有工作坊代码仓库的 URL，也有关于智能体实验的文档。这周还有几场相关演讲。明天下午 3:20 有一场关于智能体修复及其下游影响的演讲；我明天下午 3:45 还有一场，讲 Alex——我们的内部智能体。我们用 Alex 来构建 Alex，所以它是我们在智能体领域实践“用自己的产品做产品”的完美例子。我会讲这个智能体如何设计上下文和记忆，以及一路上的一些决策和经验。

trace 进入系统之后，只需点击一次就能启用 Signal，然后就能看到 trace 中问题和模式的聚类。

最后我想留给大家的要点是：读取海量数据这种艰苦工作，应该交给智能体来做。理解应该把人放在什么位置发挥最大作用，是这场演讲的主题。能自动化某件事，不代表就应该自动化；但应该用自动化来帮助审查者。比如把低置信度结果自动路由到审查队列，这非常重要。

还要确保所有上下文都反馈回同一个系统。我们今天代表 Arize 来演讲，当然会说 Arize 很棒；但真正重要的是把这些上下文记录在某个地方。只有把人工判断、评测分数和 trace 证据放在一起，为下一次运行提供上下文，才能形成自我改进闭环，发现新问题，而不是一直疲于应付旧问题。这就是我要分享的内容。非常感谢大家。我很乐意到大家身边，帮忙开始试用这些东西。你们可以去看看代码仓库、克隆下来……

评估这件事可以从两个角度来看。一个是我们如何评估 Signal 这个产品，例如它提出的 PR 有多大比例是正确的。这属于内部评估。你是想问我们如何评估自己的产品，还是泛指如何评估某种智能体应用？明天我们会有一场关于 Alex 评测的完整演讲。先简要回答：评测设计是——作为一名 AI 产品经理，我觉得自己的主要工作可能就是设计好的评测，确保真正测量了正确的东西。

简短来说，定性判断很难明确编码。像延迟、重试次数这样的指标更容易量化。例如 Signal 刚才发现的问题就相对简单：发现大小写不一致，有重试的证据，修复后测量延迟。这些都很容易做。定性结果要难得多，我觉得有几个方面可以参考。

首先，“好”的定义只能从你能提供的信号中逐渐浮现出来。我这里说的“信号”是广义上的依据。看一个例子，我可以判断对错；但不能让智能体只从一个例子里学习，否则它会对这一个例子过拟合，或者该例子无法推广到其他情况。因此，我前面说的持续生长的固定测试集和注释非常重要。

举个例子：Alex 可以生成筛选查询。在平台里搜索智能体或 trace 时，你可以自己输入筛选条件，也可以让 Alex 用 AI 帮你筛选。我们怎样衡量它的表现？这里没有唯一正确答案，因为它可能生成一个可执行的筛选器，能够解析 JSON、返回一些结果，但这些结果到底好不好？

我们会看用户的整个会话，而不只是问“这一轮的回复好吗？”用户后来又问了吗？他对结果满意吗？他又新建了多少个筛选器？这些都可以作为评估信号。

第二是注释：人工读一下查询，判断它是不是合理的筛选器、是否返回预期的评测结果，并由知道预期是什么的产品经理亲自标注。把这些信息与新的使用场景结合起来，就形成丰富的上下文，进而成为评测模板。你可以再用一个编程智能体把这些上下文整理进去，写出很好的 prompt 模板，本质上就是在优化 prompt：怎样让评测模板在最便宜的模型上也足够好，这样才能大规模运行？这就是我们的思路。

明天的演讲会讲得更具体，包括我们选择哪些模型，以及怎样判断某种场景值不值得运行评测。简而言之，这有点像事后归因：我们要确认自己定义的“健康”确实代表健康，也要定义系统在哪里算作失败。比如某个系统 99.9% 的时候都正确；但如果那 0.1% 的错误是灾难性的，且必须全部捕捉到，讨论就完全不同了。

评测还有两个用途：一类是在开发流程、CI/CD 或回归检查中运行，在代码部署之前执行；另一类是对线上 trace 运行。后一类就涉及成本与收益的权衡。

你可以建立一个包含固定案例的数据集，记录评测曾经失败的那 0.1% 情况。每次提交代码或 PR 合并前，都重新运行这些案例并查看评测分数。这样至少能确信这一组案例不会再次失败。然后再对生产 trace 以一定的采样率运行评测。

极端做法之一是忽略开发流程、评估所有生产数据，成本可能很高；另一个极端是完全忽略生产环境，只在开发阶段测试，试图用覆盖充分的数据集捕捉所有情况——这大概也做不到——之后就任由生产环境自行发展。我认为两个极端都不对，答案在中间，取决于评测的投资回报率，以及你选择的模型对成本的影响。

这是个很好的问题，而且越谈越抽象了。我希望你们没注意到它有多抽象：我们在好几个层面上都在用 Signal。简短回答是，你可以把整个闭环再运行一遍。我们有一个专门收集评测 trace 的项目，由 Arize 创建。评测本身也有 trace，你可以让一个智能体读取这些评测 trace，检查评测本身做得好不好。每个智能体也会产生自己的 trace。运行 Signal 时，你看到的就是 Signal 自己的 trace。

这里能看到“Signal，Arize 的自动审查者”，它的步骤、指令，以及它在底层实际调用的内容。它发起了几次 Bash 调用，也调用了我们的内部 MCP 来调查，然后把结果写成 issue。你甚至可以再运行一个 Signal 来检查 Signal。这就是我们内部评估的方式，也是我前面暗示的终极“用自己的产品做产品”。

我猜你更想问的是：这套方法何时会失效、什么时候值得使用？智能体运行框架上的改动在一定范围内有用。我明天谈 Alex 的评估时也会讲到：有些场景到了一定阶段就不需要继续评估了，因为成本的边际收益会递减。

以 Signal 为例，我们会监控 Signal，也会收到它的 trace，并设定一些评测分数标准。但有个阶段之后，我们并不比客户自己更清楚什么对他们有帮助。你可以启用 Signal，让它提出 PR，并用一些代理指标反馈，比如 PR 合并率、会话记录、会话是否交接、是否创建了数据集或评测。但除了这些指标，特别是 PR 合并率，我们其实很难知道更多。因此继续评估的边际收益会越来越低，因为你最终只是依赖智能体的会话记录，没有真实答案作为依据。你只是在凭感觉接受它的输出，还假装这增加了股东价值。我觉得这样没有意义。不过……

说实话，模型更便宜后，人们更愿意使用评测，我很高兴看到这一点。这对整个生态都很好：更多人会考虑评测，也会考虑给 trace 分类。我认为成本下降会大大推动这件事。

这或许和今天的主题不完全相关，但这是我个人的看法：这些模型很小，因此可以在设备本地做一些很有意思的事情，这一点让我非常期待。我们也在多模态评测方面做一些探索，因为多模态评测可能很复杂、延迟也高，而且往往需要定性判断。例如，判断生成图像是否符合审美，或智能体如何理解一个点击框，可能都很困难。但有了置信度分数，至少能更快地把案例转给人工。我认为决策模型也能在这方面发挥很大作用。是的，完全正确。

我刚才简要提过，你们也可以创建自己的智能体。我们当然提供开箱即用的 Signal 智能体。这里还可以看到一个 DataDog skill，能拉取警报相关的指标、日志和 APM trace。我们支持很多服务提供商，你也可以自己编写 skills。这样智能体就不只可以访问智能体 trace，还能访问下游系统的应用指标。基本上你可以把它连接到任何数据源。

当然，选择数据源也需要判断：只连接你需要的来源，确保权限正确、scope key 配置合理，不要让上下文过载。更多信息不总能帮助你分诊警报。我们支持这些能力。

大家总会给出一个不太让人满意的答案：“要看情况。”但确实要看情况。例如，你使用什么运行框架和底层服务提供商、运行频率是多少？这些都可以配置。我们也能帮助你监控成本。比如这里展示的是 Signal 的 trace，目前数据还在持续流入；就像你查看 Wonder Toys 的成本一样，也可以查看 Signal 的成本。

这样你就能理解投资回报率：如果这个购物助手花了我 8 美元，而用自我改进闭环改进它又花了 20 美元，值得吗？我没有一个硬性标准，比如应该把智能体预算的 5% 用于自我改进闭环；我觉得这确实要看情况。不过相关成本是透明的，你可以根据效果调整，让它更便宜或更贵。

一个调节因素是提供多少上下文：包括哪些 skills？增加的信息是否真有帮助，还是只会增加开支？另一个因素是评测设计，比如运行评测的频率、采样率等。

谢谢大家提出这么好的问题。接下来三天我都会在现场，我们也有 Arize 展位。欢迎来注册、亲自试试这个闭环。注册完全免费，使用也完全免费。