Fuad Ali：为 AI 智能体建立持续改进的反馈循环

我是 Arize 的产品经理 Fuad Ali。这场工作坊演示如何建立智能体改进反馈循环：收集追踪记录、识别失败、将失败转成测试、提出修复并运行实验。我也会讨论人在这个循环中应在哪些地方发挥判断作用。

智能体故障难以理解，因为它可能沿许多非确定性路径行动，而组织可能在不同职能中运行数千个智能体。追踪记录、客户反馈和人工标注能够提供证据，说明发生了什么，以及哪些地方需要改进。

设想一个购物助手告诉客户商店没有任何桌游。这样的生产故障可能在凌晨 4 点把工程师叫醒。我们的目标是建立持续发现和调查问题的流程，同时让人在需要判断的地方参与。

演示使用 Wonder Toys，这是一个在本地运行的聊天式购物助手，里面故意放入了一个错误。它可以搜索商品并将追踪记录发送到 Arize AX。工作坊还需要 LLM 供应商密钥和应用开发工具；跟着操作是可选的。

团队通常从追踪开始：能看到智能体调用、工具和故障。下一步是评估，也就是判断智能体是否做了正确的事。更难补上的环节，是大规模阅读追踪记录、将失败保存为回归测试，以及证明修复没有破坏其他功能。

这个循环从追踪记录进入 Signal，再依次产生数据集、评估、修复和实验。Signal 审查追踪记录并提出问题和修复建议；人确认发现并审核变更。新的证据与反馈随后可以用于后续运行。

玩具购物助手使用 FastAPI、Next.js、ChromaDB 和智能体 SDK。故意植入的过滤器错误造成搜索问题。追踪工具将请求路径发送到平台，让团队检查模型调用、工具调用、输入、输出和延迟。

例如，用户请求“展示适合 9 岁儿童的玩具”时，追踪树会显示智能体调用、模型调用和商品搜索。属性包括时间、元数据和数据库返回结果。这些细节很有价值，但人工逐条阅读数千条追踪记录并不现实。

AX CLI 和插桩工具可以为工具调用及其参数、结果、模型调用和 token 数量创建追踪跨度。相关记录也可以组合成会话，使多轮客户互动比单次孤立请求更容易理解。

Signal 是一个按计划读取项目追踪记录的智能体。演示中的默认周期是每 6 小时一次。连接 GitHub 仓库后，它可以将生产证据与源代码对照、聚合同类问题并提出修改。

在演示中，Signal 发现了多余的搜索重试和三次连续模型调用，延迟约为 14 至 17 秒。底层错误是格式不一致：商品类别以小写、连字符连接的标识保存，而模型提供的是带大写字母和空格的可读名称。

由于没有进行格式归一化，类别搜索返回空结果，智能体随后扩大搜索范围。Signal 提出的修复结合了仓库分析和追踪证据。团队可以利用该问题创建评估器、收集失败样例并打开拉取请求，但发现本身仍需要验证。

托管智能体模板可以调查追踪记录或检查成本，团队也能配置自己的智能体、任务和技能。Ali 介绍了连接 GitHub 或应用监控等数据源，并按计划或报警触发调查，例如在延迟飙升时启动。

Signal 将相关证据归为一个问题，而不是重复提交数百个问题。审核人员可以解决或忽略发现。把确认过的失败加入数据集，可以随着新用例和新故障模式出现，逐步形成回归测试样例。

评估将预期行为明确写下来。确定性代码检查成本低，适合检查 JSON 是否有效、字段是否存在或工具参数是否正确等明确条件。模型评判者可以分析更定性的结果，但需要额外模型调用成本。

对于更开放的目标，智能体可以充当评判者，检查更广泛的运行轨迹，成本通常更高。Ali 还介绍了返回类型化选项或分数的小型决策模型，认为它是另一种相对便宜的追踪分类方式。采样率和评估器选择都需要设计。

追踪证据和评估结果为编码智能体提出修复提供上下文。人仍可以在审核拉取请求、决定哪些失败样例进入数据集，以及定义什么是好结果方面发挥重要作用。高风险场景可能尤其需要在合并前仔细审核。

演示中，Ali 从 Signal 发现的搜索重试问题创建评估器。生成的提示会检查运行轨迹，并标记不必要的重复商品搜索。评估器可以用于新到来的追踪记录、触发报警，也可以监控自身成本。

一个不再必要的评估器以后可以停用，例如当某种故障已经在开发阶段得到可靠覆盖时。问题不只是是否对所有生产追踪运行全部评估：决策还应考虑成本和剩余风险。

实验阶段要回答两个问题：拟议修复是否解决了故障，是否破坏了其他功能？即便对提示词做小改动，也可能意外影响其他工具。应使用失败样例和其他回归样例重新运行智能体，并对输出评分。

Ali 展示了一次结果为 88.9% 的实验，他认为对演示来说可以接受。阈值应由团队决定，并不构成普遍保证。智能体可以用修订后的版本回放样例，衡量重试次数、延迟和其他检查结果。

审核人员可以检查实验输出，并对不同意的结果作标注。这些标注成为后续工作的额外上下文。同样的检查也可以纳入 CI/CD，但团队应谨慎选择模型和采样率，避免验证成本过高。

修复之后，线上评估器可以继续检查新追踪记录，失败结果也可以加入数据集。Signal 可按计划或报警再次运行。人仍需确认问题真实存在、审核代码，并决定是否合并及部署新版本。

基于置信度的路由可以把不确定的判断送入人工标注队列。Ali 举了一个垃圾信息示例：将置信度介于 0.3 和 0.7 的 4.6% 样例交给人处理后，剩余部分的准确率为 99.5%。他提醒，阈值取决于具体任务。

更长期的目标是让循环更加自动化，但安全运行实验会带来依赖问题。简单演示可以自行启动数据库；真实系统可能需要模拟数据、限制工具、容器或其他隔离方式。外部依赖会让测试复杂得多。

Ali 描述了从问题一键进入实验并准备所需环境的目标。发现和证据也可以通过 Slack、本地智能体、API 和 CLI 等工具提供给用户。拉取请求应附带失败追踪记录，让审核人员能够核实诊断。

评估器本身也需要维护。几乎总是通过的检查可能不再值得消耗 token，而表现不佳的评估器则可能需要改进。让评判者与人的预期一致，是不同于单纯获取分数的另一项工作。

Ali 的核心建议是让智能体承担大量阅读数据的工作，同时把人的注意力留给最重要的判断。追踪记录、评估分数、人工反馈和证据应保持关联，使下一轮改进能够使用同一份上下文。

问答中，他区分了对 Signal 产品本身的评估和对客户智能体的评估。重试次数、延迟等量化问题相对容易衡量，定性结果则更难定义。单个样例可能造成过拟合，也未必能代表更广泛的使用场景。

对于生成追踪过滤条件的智能体，团队可以观察完整用户会话：用户是否再次提问，或创建了更多过滤条件？产品经理也可以标注查询和结果是否合适。将这些观察与新样例结合，有助于改进评判提示和测试集。

罕见故障仍可能造成灾难性后果，因此仅有高通过率并不够。Ali 区分了 CI/CD 中的回归检查和针对线上追踪的评估。他建议尽量在部署前捕获问题，再根据成本与风险决定生产环境的采样率。

评估器和监控智能体也会产生追踪记录。Arize 可以评估这些记录，包括用 Signal 检查 Signal，但这一过程的收益会递减。拉取请求合并率等代理指标只能提供有限信息；没有客户提供的真实依据，更多分数未必证明真正价值。

Ali 对低延迟决策模型在执行过程中进行检查感兴趣，而不只是事后评估。更低成本可能让更多团队能够对追踪记录分类。对于困难的多模态判断，置信度分数可以帮助将不确定样例交给人，但不能消除对判断的需求。

自定义托管智能体可以将追踪数据与 Datadog 等来源的应用指标和日志结合。团队应连接需要的数据源、适当限定权限，避免用无关上下文淹没智能体；排查问题时信息并非越多越好。

改进循环的成本取决于运行框架、供应商、频率和提供的上下文。团队可以比较改进成本与收益，调整评估采样和上下文，或通过现有 API 配合自己的编码智能体使用。