从“凭感觉”到可信赖的评估体系

演讲者 Ankur Duggal 指出，许多开发者在构建 Agent（智能体）时往往依赖“直觉”而非严谨的工程化评估。他通过现场投票揭示了这一现状：虽然不少开发者会人工检查输入输出以确保 Agent 行为正确，但真正建立了系统化评估（如使用 LLM 作为裁判或代码级评测）的比例较低，而完全信任其评估覆盖度并准备持续迭代的开发者更是寥寥无几。这种“凭感觉”（vibes）的开发方式在初期能确保 Agent 按预期运行，但在生产环境中存在巨大风险。

构建全链路数据闭环以驱动 Agent 修复

要解决 AI Agent 的不可控问题，核心在于建立一个包含多维度数据的统一分析空间。开发者需要整合 Agent 的运行轨迹（Traces）、人工标注反馈（Annotations）以及 应用性能监控数据（APM Traces），以便全面掌握系统的运行状态与潜在故障点。更重要的是，必须将 代码库（Codebase） 纳入这一闭环，通过分析失败的具体工具调用路径，精准定位需要修改的代码区域。这种整合并非为了展示复杂性，而是为了让 编码 Agent（Coding Agent） 能够自动执行诊断与修复工作。无论是使用 Cloud Code、Cursor 还是 CodeEx，关键在于将这些分散的数据源连接起来，使 AI 能够基于完整上下文自动进行路径优化、工具调用修正及代码重构。

金融建议场景中的合规与逻辑缺陷分析

为了演示这一流程，演讲者展示了一个简单的金融 Agent 案例。当被问及是否应该投资塔塔汽车（Tata Motors）时，该 Agent 直接给出了肯定的投资建议。这一结果存在严重问题，因为 Agent 不具备提供财务建议的资质，且开发者也不愿承担由此引发的法律风险。在互动环节中，观众提出了多种可能的改进方向：有的认为 Agent 应在给出结论前提出更多问题以获取更多信息；有人建议通过增加上下文和提示词工程来改善回答质量；还有人指出缺乏 基于事实的验证机制（Validation），导致无法判断答案的正确性。此外，一个关键缺陷被指出：Agent 完全不了解用户的财务背景，这使得任何个性化的投资建议都显得盲目且危险。这些问题表明，修复方案并非单一维度，而是需要从交互逻辑、数据验证和用户画像等多个层面入手。

通过 CLI 与 Skills 自动化诊断修复流程

针对上述复杂问题，演讲者演示了如何利用命令行界面（CLI）和 Skills 功能来自动化修复过程。首先，通过一行命令安装 CLI 并创建连接到 Arize 平台的 Profile，从而拉取历史轨迹、评估结果和人工标注数据。随后，在 Cloud Code 中配置相应的 Skills，使编码 Agent 能够访问这些分析工具。演讲者强调，虽然演示中使用了“跳过权限确认”的选项以简化流程，但在实际生产中应遵循严格的安全规范。通过向 Claude 等模型发出指令，让编码 Agent 自动拉取特定 Agent 的轨迹数据并进行深度分析。这一过程旨在模拟人类专家的诊断思路，让 AI 自主发现如“缺乏追问机制”或“缺少护栏（Guardrails）”等问题，并生成相应的代码修改建议。最终目标是让 Agent 学会在特定领域（如金融）设置响应边界，避免越权提供建议，从而实现从被动监控到主动修复的闭环。

利用追踪数据与人工分析定位问题

在评估代理（Agent）性能时，首要步骤是识别现有问题。演讲者指出，可以通过分析任何评估结果或标注数据来发现潜在缺陷。核心策略是进行自主分析，并据此构建未来的评估体系以防止同类问题再次发生。为了演示这一过程，演讲者展示了如何手动排查追踪（Traces）数据。

"Find out what issues exist that we can determine from any... do your own analysis and tell me what eval maybe I can build out in the future to make sure that I don't run into any of these issues again."

在演示中，演讲者向代理询问关于英伟达（Nvidia）的投资建议。通过查看之前的运行记录，可以清晰地看到代理的完整执行路径：包括监督者智能体、金融数据智能体的交互，以及所有的LLM调用和工具调用。这种细粒度的追踪信息让开发者能够迅速定位问题所在，理解代理内部的决策逻辑和失败环节。

技能赋予CLI权限以自动化运维

针对如何设置评估或追踪的问题，演讲者解释了“技能”（Skills）背后的机制。技能的本质是授予代理对底层命令行界面（CLI）的访问权限。这意味着代理不再仅仅是一个对话模型，而是能够直接操作系统工具。

"So what it does, it actually goes ahead and downloads a lot of those traces um into the into your local system... what you're actually giving it access to is the CLI underneath."

通过集成不同的CLI，代理可以执行多种复杂任务：查找数据集、下载数据、与平台UI交互以设置评估，甚至持续监控代理失败情况。它可以通过API请求或直接操作来完成这些工作。这种能力使得自动化成为可能，代理可以代替人类在平台上构建数据集、运行实验并监控状态，极大地提升了运维效率。

自动诊断揭示四大关键缺陷

当代理（Claude）完成对之前查询的分析后，生成了详细的诊断报告。结果显示系统存在严重问题。最惊人的发现是约44%的代理交互产生了错误的摘要，这是一个极高的失败率。此外，报告还指出了其他几个关键缺陷：大量编造的答案（Fabricated answers）、冗余的工具调用以及静默的工具失败。这些错误不仅浪费资源，还可能导致严重的信任危机。

"One of the biggest alarming things right out of the gate is about 44% of our agent interactions are resulting in a bad summary. That's really bad."

更严重的是，当工具调用失败时，代理往往选择幻觉式回答而非披露错误。这表明问题不仅在于评估指标的设计，还涉及提示词（Prompt）层面的改进。代理需要被教导在工具失效时如何正确响应，而不是试图掩盖事实或编造数据。

基于诊断结果构建评估与实验闭环

针对上述发现的问题，演讲者演示了如何指导代理进行修复。策略是构建特定的评估指标并运行实验来验证改进效果。具体行动包括：建立“工具成功但静默失败”的评估指标，以及修复数值 groundedness（基于事实依据）的问题。

"So what we could do is... let's go ahead and build number one, which was the tool success silent failure eval, and fix numeric groundedness..."

为了实现这一目标，演讲者调用了Arize平台的相关技能：数据集技能（Dataset Skill）、评估器技能（Evaluator Skill）和实验技能（Experiment Skill）。代理被指示根据推荐进行修改，并针对最初导致失败的跨度数据运行实验。通过对比修复前后的表现，可以确保代理在特定失败案例上能够正确通过测试。虽然这一过程需要时间让代理“烹饪”（处理），但它展示了从发现问题、自动诊断到构建评估闭环的完整自动化工作流。

案例演示：Claude Agent 自动修复跨国股票查询 Bug

演讲者 Ankur Duggal 展示了如何使用 Cloud Code（基于 Claude）自动诊断并修复应用中的特定错误。起初，用户遇到无法查询非美国市场（如韩国、日本或中国）股票的问题，系统报错且不支持跨市场比较。Claude 首先定位了问题代码区域（主要集中在韩国相关逻辑），构建了一个测试数据集，并运行实验进行迭代修复。这一过程展示了从发现问题到生成可执行补丁的完整自动化闭环。

实验结果呈现出明显的迭代改进过程。初始基线版本存在 Bug，通过生产环境追踪数据验证其通过率仅为 0%。Claude 随后尝试了第一次快速修复，即通过添加国家名称进行标准化处理，但该方案失败。原因是调用的工具本身已过时，仅靠数据层修复无法解决底层兼容性问题。最终迭代中，Claude 更新了稳定版工具并修正逻辑，将成功率提升至约 90%。尽管未达到 100%，但相比初始状态有了显著改善，证明了 Agent 在定位根因和逐步优化方面的有效性。

"It started with the initial one, which was the baseline... resulted in 0% passing rate"（初始基线版本导致通过率为零）

实验运行环境与评估器配置灵活性

关于实验和评估的运行位置，用户拥有高度自定义权。在演示场景中，实验最初在本地机器上运行以节省资源或便于调试，随后也可部署至云端或在 Arize 平台本身进行评估。评估器（Evaluator）的配置是核心环节，演讲者构建了两种类型的评估机制：基于代码的评估器和基于 LLM 作为裁判（LLM as a judge）的评估器。由于代码数据设置失败，最终主要依赖 LLM 作为裁判来对比 Agent 的表现。

这种架构允许用户根据需求选择评估模型。用户不必局限于 Claude 或 OpenAI，可以自由选择任何偏好的模型提供商，包括本地开源模型。这种灵活性至关重要，因为 AI 市场变化迅速，用户可能希望使用最新发布的模型或成本更低的模型进行日常评估。同时，对于关键 Agent 的质量把控，用户也可以选择最高端的模型作为“裁判”，以确保评估结果的权威性。"evals are top of the line because ultimately they know their agent's only going to be as good as their evals"（评估器必须是顶级的，因为 Agent 的表现取决于评估器的质量）。

数据源整合：从代码库到 APM 日志的全景修复

当用户询问是否必须使用特定的 Cloud Code Agent 时，演讲者澄清：任何类型的 Agent 都可以用于执行 Bug 修复任务，Arize 提供的 Skill（技能）优势在于能够聚合多维度的上下文信息。传统的修复往往仅基于“输出错误”这一表象，而 Arize 的 Skill 允许 Agent 获取更深层的诊断数据。

Agent 不仅访问代码库，还能整合 APM（应用性能管理）工单、Jira 系统中的其他 Ticket 以及 Arize 追踪数据。这些追踪数据揭示了 Agent 在运行时的具体路径、失败点以及相关的评估和标注信息。"You're making those fixes based on... here's where it failed. Here's why it failed."（修复是基于知道它在哪里失败、为何失败的深度洞察，而非仅仅基于输出错误）。这种全方位的数据整合使得 Agent 能够进行更精准、更具上下文意识的代码修改，而不仅仅是盲目试错。

Phoenix 开源版支持与质量判断标准

针对功能可用性，演讲者确认 Phoenix（Arize 的开源版本）同样支持 Skills 和 MCP（Model Context Protocol），用户可以将这些技能连接到编码 Agent 以获取相同的信息流。虽然企业版在在线评估的格式化、仪表盘展示等方面提供更多便利功能，但核心的 Agent 辅助修复能力在开源版中已具备。

最后，关于如何界定“坏摘要”或低质量输出，演讲者指出这依赖于预先配置的评估器。在演示中，Claude 判断摘要质量不佳是基于之前设定的特定评估逻辑。"This is basically the summary eval that I'd created... taking a look at the information we've gathered throughout our entire agent"（这是创建的摘要评估器，它查看在整个 Agent 过程中收集的所有信息）。这意味着质量判断并非主观随意，而是由结构化的评估规则和数据上下文共同决定的客观过程。

技能预设与持续监控的辩证关系

针对观众提出的“为何不直接通过设置技能来确保摘要质量，而需要运行评估”的疑问，演讲者澄清了技能的预设目标与监控机制的区别。确实应当通过更新提示词、技能和编码工作流，使代理能够始终提供高质量的摘要。然而，技能并非一劳永逸的解决方案。由于模型回归或用户提问方式的变化（例如两个月后出现的新问题模式），代理的表现可能会退化。因此，评估和监控的核心目的在于检测性能下降并及时干预。通过设置技能来优化代理是基础，但必须配合持续的观察系统，以确保在环境变化时仍能维持最佳表现。这种“设置-监控-反馈”的闭环是保持代理长期有效性的关键，而非单纯依赖初始的技能配置。

解决代码代理的“过度聚焦”偏差

在讨论编码代理（如 Claude Code）时，观众指出一个常见现象：即使提供了丰富的追踪信息和技能指引，代理往往过度关注代码格式化（linting）问题，而忽略了更深层的逻辑错误。演讲者确认了这一观察的准确性，并解释了其构建技能体系的初衷：引导代理聚焦于实际的核心问题。例如，当追踪数据显示代理调用了错误的工具时，这显然不是格式问题。通过提供详细的上下文和推理能力引导，技能可以帮助代理理解“这不是由 linting 引起的错误”。在实际应用中，这种引导显著减少了代理在细枝末节上的纠缠，使其能够更准确地识别和修复导致功能失效的根本原因。这种对代理注意力的引导是提升其解决复杂问题能力的重要手段。

评估成本透明化与采样策略优化

关于运行评估的成本问题，演讲者强调平台提供了完整的追踪历史和成本可视化。每次运行 LLM 评估都会产生额外费用，因此用户需要清楚了解这些开销。为了控制成本并提高效率，平台支持采样策略（Sampling）。用户不必对 100% 的追踪数据或调用进行全量评估，而是可以针对特定区域或样本集运行评估。这种灵活性允许团队在资源有限的情况下，依然能够对关键路径进行深度监控。通过 UI 或编码代理设定基本需求（如采样比例），用户可以在保证评估覆盖关键风险点的同时，避免不必要的成本浪费。这种精细化的成本管理是大规模部署 AI 代理时不可或缺的环节。

自动化工作流的核心价值与基准测试的局限性

演讲者总结道，AI 代理的强大之处在于自动化端到端的工作流。从观察问题、定位根源、创建数据集，到构建修复方案并测试验证，代理能够完成大部分重复性工作。然而，人类仍需作为最终审核者，确保修复不仅解决了表面问题（如 linting），而且真正提升了代理性能而非导致退化。针对观众询问的“是否存在通用的基准数据集或可视化来比较不同 LLM 在评估中的性价比”，演讲者给出了否定的回答。他指出，如果使用开箱即用的评估来评判定制化的代理，最终只能得到平庸的结果。因为每个 AI 代理都是为特定场景量身定制的，通用的基准测试无法反映其个性化表现。因此，用户必须自行进行分析和评估设计，以找到最适合自身工作流的模型和策略。这种“定制化”思维是构建高性能 AI 系统的关键。

基准测试的通用性与局限性

在评估大型语言模型（LLM）或智能体时，基准测试（Benchmarks） 通常被视为一种有效的衡量工具。它们能够直观地展示一个模型在通用标准下的表现，帮助开发者判断其是否属于“好”的范畴。然而，这种通用的评估方式存在明显的局限性。基准测试虽然能证明模型的整体能力，但它无法直接回答一个更为核心的问题：这个模型是否适合我的具体业务场景？对于开发者而言，真正的目标不是寻找一个在通用榜单上得分最高的模型，而是找到最契合自身用例的特定解决方案。因此，依赖单一的通用基准数据往往会导致误判，必须结合具体的应用场景进行更细致的考量。

垂直领域的定制化评估策略

现实情况是，“好”的定义高度依赖于具体的应用领域。不同的行业对模型的能力要求截然不同。例如，在构建金融领域的智能应用时，可能需要侧重考察模型在处理复杂数值、合规性以及行业术语理解上的表现。而如果应用场景进一步细化，比如涉及金融与法律交叉领域（Law in Finance），模型则需要具备更专业的法律知识库和逻辑推理能力。这意味着，即使是同一行业，细分场景的不同也会导致模型选型策略的差异。评估标准必须量身定制，没有一种通用的“最佳”模型适用于所有情况。开发者需要根据自身构建的具体目标，选择经过特定领域微调或验证的模型版本。

演讲总结与问答环节

基于上述观点，演讲者认为关于模型评估的核心逻辑已基本阐述完毕。关键在于从通用基准转向场景化定制。在演讲的最后部分，主讲人 Ankur Duggal 表示内容主要围绕这一核心观点展开。他向观众开放了提问环节，愿意回答任何关于模型评估或应用开发的剩余疑问。这一互动环节旨在解决听众在实际操作中可能遇到的具体困惑，确保理论框架能够落地到实际开发场景中。演讲在观众的掌声中结束，标志着关于“让智能体烹饪（Let Your Agent Cook）”这一主题的深度探讨告一段落。

结论

该演讲证实，通过整合追踪数据、代码库与APM日志构建自动化闭环，能显著提升Agent的自主诊断与修复效率。案例显示，利用Skills引导编码代理可解决跨国股票查询等具体Bug，将成功率从0%提升至约90%，并识别出44%的摘要错误及幻觉问题。然而，通用基准测试无法反映定制化Agent的真实表现，评估必须基于特定场景设计。

尽管自动化流程有效，但仍存在局限：代理易过度关注格式而非逻辑错误；技能配置非一劳永逸，需持续监控以防性能退化。最终结论强调，开发者应摒弃对通用基准的依赖，转向构建场景化的评估体系与持续监控机制。人类审核仍是确保修复质量的关键环节，唯有结合定制化数据与人工干预，才能建立可信赖的Agent生产环境。