填补预演与生产环境的差距
上述案例揭示了“在预演中有效，在生产环境中失效”的巨大鸿沟。这类错误通常由团队未意识到的边缘情况引发，导致智能体在缺乏验证的情况下做出高风险操作。为了解决这一问题，Arize 展示了其可观测性平台如何追踪智能体在真实生产环境中的行为源。通过集成 Arize，开发者可以实时监控智能体的决策路径，识别如价格验证缺失等逻辑漏洞。>
演示环境与基础配置
本次技术分享以 Arize AI 平台上的一个玩具购买代理（Agent）为例，展示如何构建自学习循环。演示中涉及向 Agent 询问产品信息或执行购买操作，但明确强调不涉及真实信用卡交易。为了复现这一场景并观察追踪数据（Traces），用户只需执行四个核心命令：克隆代码仓库、进入目录、配置 API 密钥以及运行开发服务器。具体而言，用户需要获取 Arize 的 API Key 和 OpenAI 的 API Key（用于运行 OpenAI Agents SDK），随后通过 npm run dev 启动服务。一旦配置完成，用户在界面中的点击操作将自动生成追踪数据并实时流入 Arize 平台。这一简单的设置流程旨在让听众快速进入状态，为后续深入探讨新功能和故障排查奠定基础。
典型边缘案例与调试困境
在演示的玩具购买场景中，存在一个特定的价格门控（Price Gates）Bug。虽然大多数查询能正常工作，但当用户要求购买“30 美元以下的生日礼物”时，Agent 往往会返回超过该价格的商品。这是一个典型的边缘案例（Edge Case），因为特定的逻辑门控未被正确触发。在没有代码仓库上下文和追踪数据支持的情况下，这种在“黑盒”系统中仅发射遥测数据的错误极难被发现。Agent 本身无法识别此问题，反而会自信地返回完全错误的产品列表。核心挑战在于：如何为尚未见过的边缘情况编写评估（Eval）？ 传统的调试手段难以应对这种动态生成的错误，因此需要引入新的自动化机制来识别和修复此类问题。
Arize Signal：自动化的持续监控与修复
Arize 推出的新功能 Signal 是一个内置于平台沙盒中的自动化 Agent，只需在项目设置中开启一个开关即可启用。Signal 的核心机制是在后台持续运行，读取所有进入的生产环境追踪数据。它能够根据根本原因对失败案例进行聚类，并在多次运行中去重相同的故障。由于 Signal 具备完整的工具调用能力，它可以连接到 GitHub 仓库和 DataDog 等下游数据源。基于追踪这一“真相来源”，Signal 能够自我反思并检查 Agent 的代码及下游数据，撰写调查报告、确定严重性等级、收集证据，甚至直接创建并提交 Pull Request (PR)。这标志着软件工程进入“阶段三”：Agent 不仅消费自身的遥测数据，还能分析自身代码并提出基于证据的修复方案。
Arize Skills：赋能本地编码 Agent 按需分析
除了自动化的 Signal，Arize 还发布了 Arize Skills，允许开发者在本地编码环境（如 Cursor、CodeX 或 Codeium）中直接查询 Arize 的追踪数据。这是一种按需（On-demand）的方法，与 Signal 的“始终在线”模式形成互补。例如，开发者可以在 Codeium 中直接指令 Agent：“读取我的追踪数据”。此时，本地编码 Agent 能够同时访问代码库和 Arize 中的追踪记录，从而进行更深入的错误分析。Arize Skills 涵盖了多种功能，包括基于失败案例创建数据集、读取追踪数据进行分析以及运行评估器。这种双路径策略既提供了自动化的持续洞察（Signal），也赋予了工程师在开发过程中即时利用遥测数据修复问题的能力。
环境搭建与基础追踪配置
在演示开始前，参与者需完成仓库克隆及API密钥的配置。由于现场网络状况不稳定，部分用户可能遇到Git clone安装缓慢的问题，但一旦仓库加载完成，即可进入核心流程。参与者需确保在.env文件中正确填入OpenAI API Key等必要凭证，随后通过执行 npm install 和 npm run dev 命令启动应用。这一过程旨在建立基础的观测能力，即追踪（Tracing）。
"Your interactions with this chatbot are being traced to Arize."
启动后，所有与“Wonder Toys”聊天机器人的交互数据都会被实时追踪并传输至Arize平台。在Arize的Trace视图中，用户可以清晰地看到Agent的工作流全貌：从启动Agent工作流、响应请求、搜索产品，到最终返回结果。这种可视化的追踪数据构成了基线价值主张（Baseline Value Prop），即解决“能否追踪”和“能否理解Agent内部发生了什么”的核心问题。通过观察具体的Trace数据，开发者能够直观地看到Agent在每一步的操作细节，为后续的自动化评估和优化提供数据基础。
Signal 聚类分析与自动修复提案
在建立追踪链路后，Arize的Signal功能开始在后台持续运行。Signal会对流入的Trace数据进行聚类分析（Clustering Analysis），自动识别应用程序中出现的各类问题。系统会将这些问题分类展示在表格中，并显示其随时间的趋势变化。
"Signal has kind of this clustering analysis of different issues that it's seeing across your application."
演示中展示了一个具体的案例：Signal检测到由于Python序列化问题导致Agent输入损坏。更关键的是，该功能不仅发现问题，还自动创建了Pull Request（PR）以尝试修复。用户只需点击即可进入PR查看代码变更。此外，Signal还会生成详细的调查票据（Ticket），包含对当前Agent行为的概述、假设的原因分析、基于单个Trace的证据支持，以及建议的修复方案。这种机制体现了自愈软件（Self-healing Software）的理念：Agent在后台消费遥测数据，自动生成证据并提出修复建议。虽然代码审查仍保留给人类以控制风险，但这一流程极大地加速了从发现问题到提出解决方案的闭环。
自学习闭环的四步验证流程
整个演示的核心逻辑围绕构建Agent的自我改进循环（Self-improvement Loop）展开，具体分为四个关键步骤：检测、调查、修复和验证。
- 检测（Detect）：在用户报告之前，主动发现失败或回退情况。例如，检测到价格过滤功能的异常。
- 调查（Investigate）：结合平台上的Evals和真实的Trace数据，深入分析问题根源。在案例中，Signal通过关联用户关于“价格低于$30”的查询与检查价格过滤的代码路径，定位了Bug。
- 修复（Fix）：利用Cloud Code的技能分析Trace数据，识别出代码中价格过滤逻辑的错误，并生成修复建议。
- 验证（Verify）：虽然本次演示因设置复杂未深入展开，但这是闭环的最后一步，用于确认修复是否有效。
"The core loop running on a real agent which detects the issue... investigates, and proposes a fix."
通过这一流程，开发者能够利用真实用户的交互数据（Real Traces）来驱动Agent的持续优化。Signal不仅是一个监控工具，更是一个能够消费遥测数据并自动生成修复提案的智能体。这种从被动监控到主动自愈的转变，展示了AI Agent在复杂应用中的自学习潜力。
利用 Arize Signal 实现自动化监控与背景修复
在构建自学习循环时，Arize Trace Goal 或 Arize Signal 能够解决手动干预的问题。Signal 可以在后台并行运行，无需用户时刻盯着键盘，它会根据自定义的分类体系（taxonomy）和追踪数据进行调整。此外，Signal 支持配置警报触发机制，例如当特定评估的触发率超过阈值（如 1% 的错误率）、出现延迟激增或成本飙升时，系统会自动触发警报。这种自动化机制允许团队在 CI 环境中运行自定义的 Harness Judges（裁判），对拉取请求进行实验和优化，从而在无需手动干预的情况下实现持续改进。
从 LLM as a Judge 到 Harness as a Judge 的范式转移
评估代理的核心挑战在于如何处理“未知”问题。传统的 LLM as a Judge 模式基于固定的评分标准（rubric），适用于已知问题的检测，如摘要任务或幻觉评估。然而，正如演讲中提到的价格过滤案例所示，生产环境中往往存在预先未知的错误模式。因此，行业正转向 Harness as a Judge 这一自适应分析方法。该方法通过观察代理的实际执行轨迹来动态调整测试标准，例如判断工具选择是否合理、参数是否有效或上下文是否正确。这种转变使得评估不再局限于静态的输入输出打分，而是能够捕捉那些未被预先定义的错误。
Harness as a Judge 的自适应分析与外部系统集成
Harness as a Judge 的核心优势在于其能够直接读取追踪树（trace tree）并在沙箱环境中运行，无需编写样板代码或进行复杂的列映射。其评分标准通常仅由自然语言句子构成，能够直接验证代理行为。与 LLM as a Judge 不同，Harness as a Judge 可以连接外部系统以获取上下文。例如，在权限检查场景中，LLM as a Judge 仅凭输入输出无法判断用户是否有操作权限，除非将所有用户数据硬编码到提示词中。而 Harness as a Judge 可以调用外部 API，验证代理的行为是否符合用户的实际访问权限。这种能力使其从简单的模型打分转变为一种具备工具调用能力的代理式流程（agentic flow），从而有效捕获未知风险。
Agent Experiments：基于真实失败案例的自动化测试闭环
在发现并定位问题后，如何安全地部署修复方案是关键。Arize 推出的 Agent Experiments 允许团队通过 CI 自动化测试修复效果，而非依赖手动部署到开发环境。该功能利用 Arize Signal 从历史追踪数据中提取代理实际失败的案例（如之前提到的预算约束搜索失败案例），构建包含 25 个示例的测试数据集。通过将开发中的代理端点暴露出来，直接使用该失败案例集进行回归测试，团队可以自动验证修复是否生效。这种方法确保了基于真实追踪数据的闭环优化，使得每一次代码提交都能经过实际失败场景的严格检验。
利用 Agent Playground 进行实验验证
在构建自学习循环时，核心挑战在于如何确保提出的修复方案真正有效。通过 Arize AI 的 Agent Experiments（Agent实验）和 Playground，开发者可以将修复后的代码部署到开发环境并暴露为端点。随后，将数据集输入流式传输给 Agent 以获取响应，并使用与生产环境相同的评判标准（Judge Rubric）对结果进行评分。这种机制允许开发者并排对比修复前后的 Agent 表现，从而判断是否有效解决了边缘案例。除了功能正确性，实验还涵盖了延迟、成本等操作指标（Operational Metrics）的量化分析。这种工作流类似于传统的数据集实验，但关键在于它提供了一个闭环视角：在修复前和修复后查看特定评判器（如价格正确性评判器）的表现，从而量化实验结果。
结论
Arize AI 通过 Signal、Skills 及 Agent Experiments，构建了从监控到修复的自学习闭环。其核心优势在于 Harness as a Judge 范式，能基于真实 Trace 数据自动聚类未知边缘案例（如价格过滤失效），并生成带证据的修复 PR，实现从被动监控向主动自愈的转变。该方案有效解决了传统 LLM as a Judge 无法应对动态生产环境缺陷的短板。
然而，闭环验证环节在演示中未深入展开，且代码审查仍需人工介入以控制风险。该体系适用于具备完整追踪数据及 CI/CD 集成能力的团队，旨在通过自动化手段加速故障定位与修复验证。