Day4 代理质量保障

作者：Meltem Subasioglu, Turan Bulmus 和 Wafae Bakkali

内容贡献者

Hussain Chinoy

Ale Fin Peter Grabowski

Michelle Liu

Anant Nawalgaria

Kanchana Patlolla

Steven Pecht

Julia Wiesinger

策划与编辑

Anant Nawalgaria

Kanchana Patlolla

设计师

Michael Lanning

目录

1. 简介 .......................................... 6

2. 如何阅读本白皮书 .................................. 7

3. 非确定性世界中的Agent质量 .................. 8

3.1 为什么Agent质量需要新的方法 .................. 9
3.2 范式转变：从可预测代码到不可预测的Agent .................. 11
3.3 Agent质量支柱：评估框架 .................. 13
3.4 总结与未来展望 .................................. 15

4. Agent评估的艺术：评估过程 .................. 16

4.1 战略框架：“由外向内”评估层次 .................. 17
“由外向内”视角：端到端评估（黑盒） .................. 18
“由内向外”视角：轨迹评估（玻璃盒） .................. 19
4.2 评估者：Agent判断的谁和什么 .................. 21
自动化指标 .................................. 22
LLM作为裁判范式 .................................. 23
Agent作为裁判 .................................. 25 人机协作（HITL）评估 .................. 26
用户反馈和评审者UI .................. 27
4.3 超越性能：负责任AI（RAI）与安全性评估 .................. 28
4.4 总结与未来展望 .................. 30

5. 可观察性：洞察Agent的内心世界 .................. 31

5.1 从监控到真正的可观察性 .................. 31
厨房类比：流水线厨师与高级厨师 .................. 31
可观察性的三个支柱 .................. 32
5.2 支柱1：日志 – Agent的日记 .................. 33
5.3 支柱2：追踪 – 跟随Agent的足迹 .................. 36
为什么追踪不可或缺 .................. 36
Agent追踪的关键要素 .................. 37
5.4 支柱3：指标 – Agent的健康报告 .................. 38
系统指标：生命体征 .................. 38
质量指标：评估决策能力 .................. 39
5.5 从原始数据到可操作见解：整合一切 .................. 41 5.6 总结与未来展望 ____ 43

6. 结论：在自主世界建立信任 _ 44

7. 参考

AI的未来是Agent化的。其成功取决于质量。

1. 简介

我们正处于Agent化时代的黎明。从可预测、基于指令的工具到自主、目标导向的AI Agent的转变，是几十年来软件工程中最深刻的转变之一。虽然这些Agent解锁了令人难以置信的能力，但它们固有的非确定性使它们变得不可预测，并打破了我们传统的质量保证模型。

本白皮书作为对新现实的实用指南，基于一个简单但激进的原理：

Agent质量是架构的支柱，而非最终的测试阶段。

本指南建立在三个核心信息之上：

• 轨迹即真相：我们必须超越仅仅评估最终输出。一个Agent的质量和安全性的真正衡量标准在于其整个决策过程。
• 可观察性是基础：你不能评价你看不见的过程。我们详细介绍了“三个支柱”的可观察性——日志、追踪和指标——作为捕捉Agent“思维过程”的必要技术基础。
• 评估是一个持续循环：我们将这些概念综合为“Agent质量飞轮”，这是一个将数据转化为可操作见解的操作手册。该系统使用可扩展的AI驱动评估者和不可或缺的人机协作（HITL）判断，以推动不懈的改进。

本白皮书面向构建这一未来的架构师、工程师和产品领导者。它提供了从构建有能力的Agent到构建可靠和值得信赖的Agent的框架。

如何阅读本白皮书

本指南的结构是从“为什么”到“是什么”，最后到“如何”。使用本节导航到与您角色最相关的章节。

• 对于所有读者：请从第1章开始阅读：非确定性世界中的Agent质量。本章建立了核心问题。它解释了为什么传统的问答系统对AI Agent无效，并介绍了定义我们目标的四个Agent质量支柱（有效性、效率、鲁棒性和安全性）。
• 对于产品经理、数据科学家和QA领导者：如果您负责衡量标准和质量评估方法，请关注第2章：Agent评估的艺术。这一章是您的战略指南。它详细介绍了“从外向内”的评估层次结构，解释了可扩展的“LLM作为裁判”范式，并阐明了人类在回路（HITL）评估的关键作用。
• 对于工程师、架构师和SRE：如果您构建系统，您的技术蓝图是第3章：可观察性。本章从理论转向实施。它提供了“厨房类比”（厨师与高级厨师）来解释监控与可观察性的区别，并详细介绍了可观察性的三个支柱：日志、跟踪和指标——构建“可评估”Agent所需的工具。
• 对于团队领导和策略师：为了理解这些部分如何构建一个自我改进的系统，请阅读第4章：结论。本章将概念整合成一个操作手册。它介绍了“Agent质量飞轮”作为持续改进的模型，并总结了构建可信AI的三个核心原则。

3. 非确定性世界中的Agent质量

人工智能的世界正在全速转型。我们正在从构建执行指令的预测性工具转向设计自主Agent，这些Agent可以解释意图、制定计划并执行复杂的多步骤动作。对于构建、竞争和部署在尖端的数据科学家和工程师来说，这种转型提出了一个深刻的挑战。使AI Agent强大的机制也正是使其不可预测的机制。

为了理解这种转变，可以将传统软件与一辆送货卡车相比，将AI Agent与一辆一级方程式赛车相比。卡车只需要进行基本检查（“引擎是否启动？是否遵循了固定路线？”）。赛车，就像AI Agent一样，是一个复杂、自主的系统，其成功取决于动态判断。对其评估不能是一个简单的清单；它需要持续的遥测来判断每个决策的质量——从燃油消耗到制动策略。 这种演变从根本上改变了我们对待软件质量的方法。虽然传统的质量保证（QA）实践对于确定性系统来说是稳健的，但对于现代AI的微妙和自发的行为来说是不够的。一个Agent可以通过100个单元测试，但在生产中仍然可能发生灾难性的失败，因为其失败不是代码中的错误；而是其判断上的缺陷。 传统的软件验证询问：“我们是否正确构建了产品？”它将逻辑与固定的规范进行验证。现代AI评估必须提出一个更加复杂的问题：“我们是否构建了正确的产品？”这是一个在动态和不确定的世界中验证质量、鲁棒性和可信度的过程。 本章将检查这个新范式。我们将探讨为什么Agent质量需要新的方法，分析使我们的旧方法过时的技术转变，并建立评估“思考”系统的战略“从外向内”框架。

3.1 为什么Agent质量需要新的方法

对于工程师来说，风险是需要被识别和缓解的东西。在传统软件中，失败是明确的：系统崩溃、抛出空指针异常或返回一个明确错误的计算。这些失败是明显的、确定性的，并且可以追溯到逻辑中的特定错误。

AI代理的失败方式各不相同。它们的失败往往不是系统崩溃，而是质量的微妙下降，这种下降源于模型权重、训练数据和环境交互的复杂相互作用。这些失败是隐秘的：系统仍在运行，API调用返回200 OK，输出看起来合理。但实际上是极其错误的，操作上危险，并且无声地侵蚀着信任。

未能理解这一转变的组织将面临重大的失败、运营效率低下和声誉损害。虽然算法偏差和概念漂移等失败模式在被动模型中就已存在，但代理的自主性和复杂性加剧了这些风险，使得它们更难以追踪和缓解。以下是表1中突出显示的这些现实世界的失败模式：

这些失败使得传统的调试和测试范例无效。你不能用断点来调试幻觉。你不能编写单元测试来防止意外偏差。根本原因分析需要深入的数据分析、模型重新训练和系统评估——这是一个全新的学科。

3.2 范式转变：从可预测的代码到不可预测的代理

核心技术挑战源于从以模型为中心的AI向以系统为中心的AI的演变。评估AI代理与评估算法本质上是不同的，因为代理是一个系统。这种演变是累积进行的，每个阶段都增加了一层新的评估复杂性。

1. 传统机器学习：评估回归或分类模型，虽然不无难度，但是一个定义明确的问题。我们依赖于诸如精确率、召回率、F1分数和RMSE等统计指标，与保留的测试集进行对比。问题复杂，但“正确”的定义是清晰的。

2. 被动大语言模型：随着生成模型的兴起，我们失去了简单的指标。我们如何衡量生成段落的“准确性”？输出是概率性的。即使输入相同，输出也可能不同。评估变得更加复杂，依赖于人工评分和模型间的基准测试。然而，这些系统在很大程度上仍然是被动工具，输入文本，输出文本。

3. 大语言模型+RAG（检索增强生成）：下一个飞跃引入了一个多组件管道，由Lewis等人在2020年的工作“用于知识密集型NLP任务的检索增强生成”中首创。现在，失败可能发生在LLM或检索系统中。智能体给出糟糕的答案是因为LLM推理不当，还是因为向量数据库检索到了不相关的片段？我们的评估范围从模型本身扩展到包括分块策略、嵌入和检索器的性能。

4. 活跃的AI智能体：今天，我们面临着深刻的架构转变。LLM不再仅仅是文本生成器；它是复杂系统中的推理“大脑”，集成到一个能够进行自主行动的循环中。这个智能体系统引入了三种核心技术能力，这些能力打破了我们的评估模型：

5. 规划和多步推理：智能体将复杂目标（“规划我的旅行”）分解成多个子任务。这创建了一个轨迹（思考 → 行动 → 观察 → 思考...）。LLM的非确定性现在在每一步都加剧。在第一步中，一个小的、随机的词组选择可能会让智能体在第四步时走上完全不同且无法恢复的推理路径。

6. 工具使用和函数调用：智能体通过API和外部工具（代码解释器、搜索引擎、预订API）与真实世界互动。这引入了动态的环境交互。智能体的下一步行动完全取决于外部不可控世界的状态。

7. 记忆：智能体维持状态。短期“临时”记忆跟踪当前任务，而长期记忆允许智能体从过去的交互中学习。这意味着智能体的行为会演变，昨天有效的输入今天可能会产生不同的结果，这取决于智能体“学习”到的东西。

8. 多智能体系统：当多个活跃智能体集成到共享环境中时，会出现最终的架构复杂性。这不再是单个轨迹的评估，而是系统级涌现现象的评估，引入了新的、根本性的挑战：

9. 涌现系统故障：系统的成功取决于智能体之间未经编排的交互，例如资源竞争、通信瓶颈和系统死锁，这些不能归因于单个智能体的失败。

10. 协作与竞争评估：目标函数本身可能变得模糊。在协作MAS（例如，供应链优化）中，成功是一个全局指标，而在竞争MAS（例如，博弈论场景或拍卖系统）中，评估通常需要跟踪单个智能体的性能和整体市场/环境的稳定性。 这种能力的组合意味着主要的评估单位不再是模型，而是整个系统轨迹。智能体的涌现行为源于其规划模块、工具、记忆和动态环境之间错综复杂的相互作用。

3.3 智能体质量支柱：评估框架

如果我们不能再仅仅依赖简单的准确率指标，而必须评估整个系统，那么我们应该从哪里开始呢？答案是采用一种名为“由外向内”的战略转变。

这种策略将AI评估建立在以用户为中心的指标和整体业务目标上，超越了仅仅依赖内部、组件级技术分数的做法。我们必须停止只问“模型的F1分数是多少？”而开始问，“这个Agent是否提供了可衡量的价值，并与我们用户的意图保持一致？”

这种策略需要一个全面的框架，将高级业务目标与技术性能联系起来。我们定义Agent质量通过以下四个相互关联的支柱：

图 2：Agent 质量的四大支柱

有效性（目标达成）：这是终极的“黑盒”问题：Agent 是否成功且准确地实现了用户的实际意图？这一支柱直接关联到以用户为中心的指标和业务关键绩效指标（KPI）。对于一个零售 Agent，这不仅仅是“是否找到了产品？”而是“是否推动了转化？”对于一个数据分析 Agent，这不仅仅是“是否编写了代码？”而是“代码是否产生了正确的洞察？”有效性是任务成功的最终衡量标准。

效率（运营成本）：Agent 是否很好地解决了问题？一个需要 25 步、五次失败的工具调用和三次自我纠正循环才能预订简单航班的 Agent 可以被认为是一个低质量的 Agent——即使它最终成功了。效率是通过消耗的资源来衡量的：总代币（成本）、系统时间（延迟）和轨迹复杂性（总步数）。

鲁棒性（可靠性）：Agent 如何处理逆境和现实世界的混乱？当 API 超时、网站布局改变、数据缺失或用户提供了模糊的提示时，Agent 是否能够优雅地失败？一个鲁棒的 Agent 会重试失败的调用，在需要时向用户请求澄清，并报告它无法完成的事情以及原因，而不是崩溃或产生幻觉。

安全与对齐（可信度）：这是不可协商的门槛。Agent 是否在其定义的道德边界和约束内运行？这一支柱涵盖了从负责任的 AI 指标（公平性和偏见）到防止提示注入和数据泄露的安全性。它确保 Agent 保持任务，拒绝有害的指令，并作为您组织的可信代理运行。

这个框架清楚地表明：如果你只看到最终答案，你就无法衡量这些支柱中的任何一个。如果你不计算步骤，你就无法衡量效率。如果你不知道哪个 API 调用失败，你就无法诊断鲁棒性故障。如果你无法检查 Agent 的内部推理，你就无法验证安全性。

一个全面的 Agent 质量框架需要一个全面的 Agent 可视化架构。

3.4 摘要及未来展望

Agent 的内在非确定性本质打破了传统的质量保证。现在，风险包括像偏见、幻觉和漂移这样的微妙问题，这些是由从被动模型到主动、以系统为中心的 Agent 的转变所驱动的，这些 Agent 计划并使用工具。我们必须将我们的重点从验证（检查规范）转移到验证（判断价值）。

这个框架需要从“外部到内部”的框架来衡量 Agent 质量在四个支柱上的表现：有效性、效率、鲁棒性和安全性。衡量这些支柱需要深入的可见性——看到 Agent 决策轨迹的内部。

在构建“如何”（可观察性架构）之前，我们必须定义“什么”：良好的评估是什么样的？

第二章将定义评估复杂 Agent 行为的策略和评判标准。第三章将构建所需的技术基础（日志记录、跟踪和指标），以捕获数据。

4. Agent 评估的艺术：评判过程

在第一章中，我们确立了从传统软件测试到现代 AI 评估的根本转变。传统的测试是一个确定性的验证过程——它询问，“我们是否正确地构建了产品？”与固定的规范相对。这种方法在系统的核心逻辑是概率性的情况下失败，因为非确定性的输出可能更可能导致质量微妙下降，这不会导致显式的崩溃，可能也不可重复。

与对比，代理评估是一个全面的过程，它提出了一个更加复杂和根本的战略问题：“我们是否构建了正确的产品？”这个问题是“从外到内”评估框架的战略基石，代表着从内部合规性判断到评估系统外部价值以及与用户意图一致性的必要转变。这要求我们评估代理在动态世界中运营的整体质量、鲁棒性和用户价值。

随着能够规划、使用工具并与复杂环境交互的AI代理的兴起，这一评估领域变得更加复杂。我们必须超越“测试”输出，学会“评估”过程的艺术。本章提供了进行此类评估的战略框架：评估代理从初始意图到最终结果的整个决策轨迹。

4.1 战略框架：“从外到内”评估层次结构

为了避免陷入组件级指标的海洋中，评估必须是一个自上而下的战略过程。我们称之为“从外到内”层次结构。这种方法优先考虑唯一真正重要的指标——现实世界的成功，然后再深入探讨为什么成功或失败的技术细节。这个模型是一个两阶段的过程：首先从黑盒开始，然后打开它。

“从外到内”视角：端到端评估（黑盒）

图 3：全面评估 Agent 的框架

第一个也是最关键的问题是：“Agent 是否有效地实现了用户的目标？”

这是“从外向内”的视角。在分析任何单个内部思维或工具调用之前，我们必须评估 Agent 最终的性能是否与其定义的目标相符。

此阶段的指标主要关注整体任务完成情况。我们测量：

• 任务成功率：一个二元（或分级）分数，表示最终输出是否正确、完整，并解决了用户的实际问题，例如，编码 Agent 的 PR 接受率，金融 Agent 成功数据库交易率，或客户服务机器人会话完成率。
• 用户满意度：对于交互式 Agent，这可以是一个直接的用户反馈评分（例如，点赞/踩），或客户满意度评分（CSAT）。
• 总体质量：如果 Agent 的目标是定量的（例如，“总结这 10 篇文章”），则指标可能是准确性或完整性（例如，“它是否总结了所有 10 篇？”）。 如果 Agent 在此阶段得分 100%，我们的工作可能就完成了。但在一个复杂的系统中，这种情况很少发生。当 Agent 产生有缺陷的最终输出、放弃任务或未能收敛到解决方案时，“从外向内”的视角告诉我们哪里出了问题。现在我们必须打开盒子看看原因。

💡 应用技巧：

要使用 Agent 开发工具包（ADK）构建输出回归测试，请启动 ADK 网页用户界面（adk web）并与您的 Agent 交互。当您收到一个理想的响应并将其设置为基准时，导航到“评估”标签并点击“添加当前会话”。这将整个交互保存为评估案例（.test.json 文件），并将 Agent 当前的文本锁定为真实最终响应。然后您可以通过 CLI（adk eval）或 pytest 运行此评估集，自动将未来的 Agent 版本与保存的答案进行比较，捕捉到输出质量的任何退化。

“从内向外”的视角：轨迹评估（玻璃箱）

一旦识别到失败，我们就转向“从内向外”的视角。我们通过系统地评估其执行轨迹的每个组件来分析 Agent 的方法：

1. LLM 规划（“思维”）：我们首先检查核心推理。LLM 本身是否存在问题？这里的失败包括幻觉、不合逻辑或离题的响应、上下文污染或重复的输出循环。
2. 工具使用（选择与参数化）：Agent 的好坏取决于其工具。我们必须分析 Agent 是否调用了错误工具、未能调用必要的工具、幻觉工具名称或参数名称/类型，或无必要地调用。即使它选择了正确的工具，也可能因为提供缺失的参数、不正确的数据类型或格式错误的 JSON 而失败。
3. 工具响应解释（“观察”）：在工具正确执行之后，Agent 必须理解结果。Agent 常常在这里失败，因为误解了数值数据、未能从响应中提取关键实体，或关键地，没有识别出工具返回的错误状态（例如，API 的 404 错误）并继续像调用成功一样操作。
4. RAG 性能：如果 Agent 使用检索增强生成（RAG），轨迹取决于其检索信息的质量。失败包括检索无关文档、获取过时或不正确的信息，或 LLM 完全忽略检索的上下文并仍然幻觉出一个答案。
5. 轨迹效率和鲁棒性：除了正确性之外，我们还必须评估整个过程：暴露出无效的资源分配，例如过多的 API 调用、高延迟或重复的努力。它还揭示了鲁棒性失败，例如未处理的异常。
6. 多智能体动力学：在高级系统中，轨迹涉及多个智能体。因此，评估必须包括智能体之间的通信日志，以检查是否存在误解或通信循环，并确保智能体在遵循其定义的角色时不会与其他智能体发生冲突。

通过分析跟踪信息，我们可以从“最终答案是错误的”（黑盒）转变为“最终答案是错误的，因为……”（玻璃盒）。这种诊断能力是智能体评估的全部目标。

🌟 应用技巧：

当你在ADK中保存一个评估案例（如前一条技巧所述）时，它还会保存整个工具调用序列作为真实轨迹。然后，你的自动化pytest或adk eval运行将检查此轨迹以进行完美匹配（默认情况下）。 要手动实现过程评估（即调试失败），请使用adk web UI中的跟踪标签。这提供了一个智能体的执行交互式图表，允许你直观地检查智能体的计划，查看它调用的每个工具及其确切参数，并将其实际路径与预期路径进行比较，以确定其逻辑失败的确切步骤。

4.2 评估者：智能体判断的谁和什么

清楚评估对象（即轨迹）是成功的一半，而另一半则在于如何作出判断。对于质量、安全性与可解释性这类复杂维度，往往需要采用综合性的混合评估方法。自动化系统能实现规模化评估，但质量评判的关键仍依赖于人类判断。

自动化指标

自动化指标以高效、可复现的特点，在回归测试和基准输出对比中发挥着重要作用：

• 文本匹配度（如ROUGE、BLEU），通过比对生成文本与参考文本的相似度进行评估；
• 语义相关度（如BERTScore、余弦相似度），从嵌入向量层面衡量语义层面的关联性；
• 任务型基准测试（例如TruthfulQA），针对特定任务场景设计标准化评估。

需要注意的是，度量本身虽有效却可能存在“幻影效应”——它们往往仅反映表面相似性，而难以触及深层推理与用户真实价值需求。

🌟 应用技巧：

将自动化指标作为CI/CD管道中的第一个质量关卡。关键是将其视为趋势指标，而不是质量绝对指标。例如，一个特定的BERTScore为0.8并不一定意味着答案“好”。

它们的真正价值在于跟踪变化：如果你的主分支在“黄金集”上始终平均为0.8 BERTScore，而一个新的代码提交将平均降至0.6，你将自动检测到显著的回归。这使得指标成为完美的、低成本的第一道防线，在升级到更昂贵的LLM-as-a-Judge或人工评估之前，在规模上捕捉明显的失败。

LLM-as-a-Judge范式

我们如何自动化评估像“这个摘要好吗？”或“这个计划合理吗？”这样的定性输出？答案是使用我们试图评估的相同技术。LLM-as-a-Judge范式涉及使用一个强大、最先进的模型（如谷歌的Gemini Advanced）来评估另一个智能体的输出。

我们向“法官”LLM提供智能体的输出、原始提示、“黄金”答案或参考（如果有的话），以及详细的评估标准（例如，“在1-5的范围内评估此响应的有用性、正确性和安全性，并解释你的推理。”）。这种方法提供了可扩展、快速且出人意料地细致的反馈，特别是对于中间步骤，如智能体“思想”的质量或其对工具响应的解释。虽然它不能取代人类判断，但它允许数据科学团队快速评估数千个场景的性能，使迭代评估过程可行。

🌟 应用技巧：

为了实现这一目标，应优先考虑成对比较而非单次评分，以减轻上述提到的精确偏差。首先，将您的评估提示集与两种不同的Agent版本（例如，您的旧生产Agent与您的新实验性Agent）进行匹配，为每个提示生成“答案A”和“答案B”。

然后，创建大语言模型（LLM）评判者，向一个强大的LLM（如Gemini Pro）提供一个清晰的评分标准和提示，迫使它做出选择：“给定此用户查询，哪个回答更有帮助：A还是B？请解释您的理由。”通过自动化此过程，您可以可扩展地计算新Agent的胜负/平局率。高“胜率”远比绝对（且往往嘈杂）的1-5分的小幅变化更能可靠地表明改进。一个用于LLM作为评判者的提示，特别是用于稳健的成对比较，可能如下所示：

You are an expert evaluator for a customer support chatbot. Your goal is to assess which of two responses is more helpful, polite, and correct.

[User Query]
"Hi, my order #12345 hasn't arrived yet."

[Answer A]
"I can see that order #12345 is currently out for delivery and should arrive by 5 PM today."

[Answer B]
"Order #12345 is on the truck. It will be there by 5."

Please evaluate which answer is better. Compare them on correctness, helpfulness, and tone. Provide your reasoning and then output your final decision in a JSON object with a "winner" key (either "A", "B", or "tie") and a "rationale" key.

代理作为裁判

虽然大语言模型可以评分最终响应，但代理需要对其推理和行动进行更深入的评估。新兴的“代理作为裁判”$^{4}$范式使用一个代理来评估另一个代理的完整执行轨迹。它不仅评分输出，还评估整个过程。关键评估维度包括： - 计划质量：计划是否逻辑结构合理且可行？ - 工具使用：是否选择了正确的工具并正确应用？ - 上下文处理：代理是否有效地使用了先前的信息？ 这种方法在过程评估中尤其有价值，因为失败往往源于有缺陷的中间步骤，而不是最终输出。

💡 应用技巧：

要实现代理作为裁判，考虑将执行轨迹对象的相关部分输入到您的裁判中。首先，配置您的代理框架以记录和导出轨迹，包括内部计划、选择工具的列表以及传递的确切参数。然后，创建一个专门的“评论代理”，并给出一个提示（评分标准），要求它直接评估这个轨迹对象。您的提示应该提出具体的过程问题：“1. 根据轨迹，初始计划是否合理？2. 工具$ {tool_A} $是否是正确的第一个选择，或者应该使用另一个工具？3. 参数是否正确且格式正确？”这允许您自动检测过程失败（如低效的计划），即使代理产生的最终答案看起来是正确的。

人机交互（HITL）评估

虽然自动化提供了规模，但它难以处理深层次的主体性和复杂的领域知识。人机交互（HITL）评估是捕捉自动化系统遗漏的关键定性信号和细微判断的必要过程。

然而，我们必须摒弃人类评分提供完美“客观真实”的想法。对于高度主观的任务（如评估创意质量或细微的语气），完美的注释者间一致性很少见。相反，HITL是建立人类校准基准的不可或缺的方法，确保代理的行为与复杂的人类价值观、情境需求和特定领域的准确性保持一致。 HITL过程涉及几个关键功能：

• 领域专业知识：对于专业代理（例如，医疗、法律或金融），您必须利用领域专家来评估事实正确性和遵守特定行业标准。
• 解释细微差别：人类对于判断定义高质量互动的细微品质至关重要，如语气、创造力、用户意图和复杂的道德一致性。
• 创建“黄金集”：在自动化变得有效之前，人类必须建立“黄金标准”基准。这包括整理全面的评估集，定义成功目标，并制定一套健壮的测试案例，涵盖典型、边缘和对抗性场景。

💡 应用技巧：

为了运行时安全，实现中断工作流程。在一个框架如ADK中，您可以配置代理在提交高风险工具调用（如execute_payment或delete_database_entry）之前暂停其执行。然后，代理的状态和计划行动将在审查者UI中显示，人类操作员必须手动批准或拒绝该步骤，然后代理才能继续执行。

用户反馈和审查者UI

评估还必须捕捉现实世界的用户反馈。每次交互都是有用性、清晰度和信任的信号。这种反馈包括定性信号（如点赞/踩）和产品内的定量成功指标，例如编码代理的拉取请求（PR）接受率，或旅行代理成功预订完成率。最佳实践包括： - 低摩擦反馈：点赞/踩、快速滑块或简短评论。

• 丰富上下文审查：反馈应与完整对话和代理的推理轨迹配对。
• 审查者用户界面（UI）：一个双面板界面：左侧为对话，右侧为推理步骤，对“不良计划”或“工具误用”等问题进行内联标记。
• 管理仪表板：汇总反馈以突出重复问题和风险。 没有可用的界面，评估框架在实践中就会失败。强大的UI使用户和审查者的反馈变得可见、快速且可操作。

💡 应用技巧：

将您的用户反馈系统实现为一个事件驱动的管道，而不仅仅是静态日志。当用户点击“不喜欢”时，该信号必须自动捕获完整的、上下文丰富的对话轨迹，并将其添加到开发者的审查者UI中的专用审查队列中。

4.3 超越性能：负责任的人工智能（RAI）与安全评估

评估的最后一个维度不是作为一个组件，而是一个强制性的、不可协商的门槛，适用于任何生产代理：负责任的人工智能和安全。一个100%有效但造成伤害的代理是完全的失败。

安全评估是一个专门的学科，必须融入整个开发生命周期。这包括：

• 系统性红队攻击：积极尝试使用对抗性场景来破坏代理。这包括生成仇恨言论、泄露私人信息、传播有害刻板印象或诱导代理进行恶意行为的尝试。

• 自动过滤与人工审查：实施技术过滤器以捕获政策违规，并将其与人工审查相结合，因为仅靠自动化可能无法捕捉到细微的偏见或毒性。

• 遵守指南：明确评估代理的输出是否符合预定义的伦理指南和原则，以确保一致性和防止意外后果。 最终，性能指标告诉我们代理能否完成工作，但安全评估告诉我们它是否应该。

💡 应用技巧：

将您的护栏实现为一个结构化插件，而不仅仅是孤立的功能。在这种模式中，回调是机制（ADK提供的钩子），而插件是您构建的可重用模块。 例如，您可以构建一个单独的SafetyPlugin类。然后，该插件将内部方法注册到框架的可用回调中： 1. 您的插件中的check_input_safety()方法将注册到before_model_callback。这个方法的任务是运行您的提示注入分类器。

1. 您的插件中的check_output_pii()方法将注册到after_model_callback。

这个方法的任务是运行您的PII扫描器。这种插件架构使您的护栏可重用、可独立测试，并干净地叠加在基础模型内置的安全设置（如Gemini中的设置）之上。

4.4 摘要及未来计划

有效的代理评估需要超越简单的测试，转向战略性的、分层的框架。这种“自外向内”的方法首先验证端到端任务完成（黑盒），然后再分析“玻璃盒”内的完整轨迹——评估推理质量、工具使用、鲁棒性和效率。

评估这个过程需要一种混合方法：可扩展的自动化，如LLM作为裁判，与不可或缺的、细微的Human-in-the-Loop（HITL）评估者的判断相结合。这个框架由不可协商的负责任的人工智能和安全评估层来保障，以构建可信赖的系统。

我们理解需要评估整个轨迹，但这个框架没有数据支撑只是纯粹的理论。为了实现这种“玻璃盒”评估，系统必须首先是可观察的。第三章将提供架构蓝图，从评估的理论转向可观察性的实践，通过掌握三个支柱：日志、跟踪和指标。

5. 可观察性：洞察代理的思维

5.1 从监控到真正的可观察性

在上一章中，我们确立了一个观点：AI Agent 是一种新型的软件。它们不仅仅是执行指令，它们还会做出决策。这种根本性的差异要求我们采取新的质量保证方法，将我们从传统的软件监控带入更深层次的观察领域。

为了理解这种差异，让我们离开服务器室，走进一个厨房。

厨房类比：普通厨师与高级厨师

传统软件就像一位普通厨师：想象一下一家快餐厨房。普通厨师有一张印有制作汉堡步骤的塑料卡片。步骤是严格且确定的：烤面包片30秒，烤肉饼90秒，加一片奶酪，两片黄瓜，一滴番茄酱。

• 在这个领域，监控就像一份清单。烤架的温度是否合适？厨师是否遵循了每一步？订单是否按时完成？我们正在验证一个已知且可预测的过程。

AI Agent 就像一位在“神秘盒子”挑战中的高级厨师：厨师被赋予一个目标（“制作一道令人惊叹的甜点”）和一个装有食材的篮子（用户的提示、数据和可用工具）。没有单一的正确食谱。他们可能会制作巧克力熔岩蛋糕、解构提拉米苏或藏红花浸泡的帕纳科塔。所有这些都可以是有效的，甚至是卓越的解决方案。

• 观察性就像一位美食评论家如何评判厨师。评论家不仅仅品尝最终的菜肴。他们想了解整个过程和推理。为什么厨师选择将覆盆子和罗勒搭配在一起？他们使用了什么技术来结晶姜？当他们意识到糖用完了会如何调整？我们需要看到他们的“思维过程”才能真正评估他们工作的质量。

这代表了 AI Agent 的一次根本性转变，从简单的监控到真正的观察性。重点不再仅仅是验证 Agent 是否活跃，而是理解其认知过程的质量。不再是询问“Agent 是否在运行？”，关键问题变成了“Agent 是否在有效思考？”。

观察性的三个支柱

那么，我们如何获取 Agent 的“思维过程”呢？我们无法直接读取其思想，但我们可以分析它留下的证据。这是通过在三个基础支柱上建立我们的观察性实践来实现的：日志、追踪和指标。它们是我们从品尝最终菜肴到批评整个烹饪表现的工具。

让我们逐一剖析每个支柱，看看它们是如何协同工作，为我们提供对Agent性能的批判性视角。

5.2 第一支柱：日志记录 – Agent的日记

什么是日志？日志是可观测性的原子单位。想象一下，它们就像Agent日记中的时间戳条目。每条条目都是关于一个离散事件的原始、不可变的事实：“在10:01:32，我被问了一个问题。在10:01:33，我决定使用get_weather工具。”它们告诉我们发生了什么。

超越print()：有效日志的要素

像Google Cloud Logging这样的全面托管服务，允许您在规模上存储、搜索和分析日志数据。它可以自动收集来自Google Cloud服务的日志，其日志分析功能允许您运行SQL查询，以揭示Agent行为的趋势。

一流的框架使这变得简单。例如，Agent开发套件（ADK）建立在Python的标准日志模块之上。这允许开发者配置所需的详细程度——从生产环境中的高级INFO消息到开发过程中的细粒度DEBUG消息——而无需更改Agent的代码。

关键日志条目的解剖结构

为了重建Agent的“思维过程”，日志必须富含上下文。结构化的JSON格式是黄金标准。

• 核心信息：一个好的日志会捕捉完整的上下文：提示/响应对、中间推理步骤（Agent的“思维链”，这是Wei等人（2022年）探讨的概念）、结构化的工具调用（输入、输出、错误）以及Agent内部状态的任何变化。
• 权衡：详尽性 vs. 性能：高度详细的DEBUG日志是开发者调试时的最佳帮手，但可能会过于“嘈杂”，在生产环境中造成性能开销。这就是为什么结构化日志如此强大的原因；它允许您收集详细的数据，但又能高效地过滤它们。

以下是一个展示结构化日志强大功能的实际示例，改编自ADK DEBUG输出：

// A structured log entry capturing a single LLM request
...
2025-07-10 15:26:13,778 - DEBUG - google_adk.google.adk.models.google_llm - Sending out request, model: gemini-2.0-flash, backend: GoogleLLMVariant.GEMINI_API, stream: False 2025-07-10 15:26:13,778 - DEBUG - google_adk.google.adk.models.google_llm - LLM Request:
System Instruction:
You roll dice and answer questions about the outcome of the dice rolls....
The description about you is "hello world agent that can roll a dice of 8 sides and check prime numbers."
Contents:
{"parts":[{text":"Roll a 6 sided dice"}], "role": "user"}
{"parts":[{function_call": {args:{sides:"6"},name:"roll_die"}]}, "role": "model"}
{"parts":[{function_response": {name:"roll_die", "response": {result":2}}]}, "role": "user"}

Functions:
roll_die: {'sides': {'type': <type.INTEGER: 'INTEGER'>}}
check_prime: {'nums': {'items': {'type': <type.INTEGER: 'INTEGER'>}, 'type': <type.ARRAY: 'ARRAY'>}}

2025-07-10 15:26:13,779 - INFO - google_genai.models - AFC is enabled with max remote calls: 10.
2025-07-10 15:26:14,309 - INFO - google_adk.google.adk.models.google_llm - LLM Response:
Text:
I have rolled a 6 sided die, and the result is 2.

应用技巧：

记录代理在行动之前和行动之后的意图是一种强大的日志记录模式。这立即阐明了失败尝试和故意不采取行动之间的区别。

5.3 第二个支柱：追踪 – 跟随代理的脚步

什么是追踪？如果日志是日记条目，那么追踪就是将它们连接成一个连贯故事的叙事线索。追踪跟随一个单一任务——从最初的用户查询到最终的答案——将单个日志（称为跨度）拼接成一个完整、端到端的视图。追踪通过显示事件之间的因果关系，揭示了关键的“为什么”。

想象一下侦探的软木塞板。日志是单个线索——一张照片、一张入场券。追踪就是连接它们的红线，揭示事件的全过程。

为什么追踪不可或缺

考虑一个复杂的代理失败案例，用户提出一个问题，却得到了一个无意义的答案。

• 独立的日志可能显示：ERROR：RAG搜索失败和ERROR：大语言模型响应验证失败。你看到了错误，但根本原因不明确。
• 追踪揭示了完整的因果关系链：用户查询 → RAG搜索（失败）→ 故障性工具调用（收到空输入）→ 大语言模型错误（被糟糕的工具输出所困惑）→ 不正确的最终答案

追踪使根本原因立即显而易见，对于调试复杂的多步骤代理行为来说，它是不可或缺的。

代理追踪的关键要素

现代追踪建立在像OpenTelemetry这样的开放标准之上。核心组件包括：

• 跨度：追踪中单个命名的操作（例如，一个llm_call跨度，一个tool_execution跨度）。
• 属性：附加到每个跨度的丰富元数据——prompt_id、latency_ms、token_count、user_id等。
• 上下文传播：通过唯一的trace_id将跨度连接在一起的“魔法”，允许后端如Google Cloud Trace组装完整的画面。Cloud Trace是一个分布式追踪系统，有助于你了解你的应用程序处理请求所需的时间。当代理部署在像Vertex AI Agent Engine这样的托管运行时上时，这种集成得到了简化。代理引擎处理生产中代理的扩展基础设施，并自动与Cloud Trace集成，以提供端到端的可观察性，将代理调用与所有后续的模型和工具调用链接起来。

5.4 第三支柱：指标 – 代理的健康报告

什么是指标？如果日志是厨师的准备笔记，而跟踪是评论家逐步观察食谱展开的过程，那么指标就是评论家发布的最终评分卡。它们是定量、汇总的健康评分，让您能够立即、一目了然地了解代理的整体性能。

关键的是，评论家并不是仅凭对最终菜肴的一次品尝就发明这些评分。他们的判断是基于他们所观察到的所有内容。指标也是如此：它们不是新的数据来源。它们是通过汇总您日志和跟踪中的数据随时间推移而得出的。它们回答了“平均来说，性能表现如何？”的问题。

对于AI代理来说，将指标分为两个不同的类别是有用的：直接可测量的系统指标和更复杂的评估指标。

系统指标：生命体征

系统指标是操作健康的基础性、定量度量。它们直接通过聚合函数（如平均值、总和或百分位数）从您的日志和跟踪中的属性计算得出。将这些视为代理的生命体征：它的脉搏、体温和血压。

要跟踪的关键系统指标包括： 性能：

• 延迟（P50/P99）：通过聚合跟踪中的duration_ms属性来计算中位数和99百分位响应时间。这告诉您典型的和最坏的用户体验。
• 错误率：包含错误=true属性的span的跟踪百分比。

成本：

• 每个任务的令牌数：所有跟踪中token_count属性的平均值，这对于管理大语言模型成本至关重要。
• 每次运行的API成本：通过结合令牌计数和模型定价，您可以跟踪每个任务的平均财务成本。

效率：

• 任务完成率：成功到达指定“成功”span的跟踪百分比。
• 工具使用频率：每个工具（例如，get_weather）作为span名称出现的次数，揭示了哪些工具最有价值。

这些指标对于运营、设置警报和管理代理群集的成本和性能至关重要。

质量指标：评估决策

质量指标是通过在第二章详细说明的判断框架之上应用原始可观察数据而得出的二级指标。它们超越了效率，评估代理的推理和最终输出质量本身。

这些指标不仅仅是简单的计数或平均值。它们是在原始可观察数据之上应用判断层得出的二级指标。它们评估代理推理和最终输出的质量。

关键质量指标的例子包括：

• 正确性与准确性：代理是否提供了事实正确的答案？如果它总结了文档，总结是否忠实于来源？
• 轨迹遵循度：代理是否遵循了特定任务的预期路径或“理想食谱”？它是否以正确的顺序调用了正确的工具？
• 安全性与责任感：代理的响应是否避免了有害、有偏见或不适当的内容？
• 帮助性与相关性：代理的最终响应是否真正对用户有帮助且与他们的查询相关？

生成这些指标需要不仅仅是简单的数据库查询。它通常涉及将代理的输出与“黄金”数据集进行比较或使用复杂的LLM作为评判者来根据评分标准对响应进行评分。

我们日志和跟踪中的可观察数据是我们计算这些分数所必需的必要证据，但判断本身的过程是一个独立的、关键的学科。

5.5 整合一切：从原始数据到可操作的见解

拥有日志、跟踪和指标就像拥有一位才华横溢的大厨、一个库存丰富的储藏室和一套评判标准。但这些只是组成部分。要经营一家成功的餐厅，你需要将这些组件组装成一个适用于繁忙晚餐服务的运行系统。本节将介绍这种实际组装——在实时运营中将可观察性数据转化为实时行动和洞察。

这涉及到三个关键的操作实践：

1. 仪表板与警报：区分系统健康与模型质量 单一的仪表板是不够的。为了有效地管理AI代理，你需要为系统指标和质量指标提供不同的视角，因为它们服务于不同的目的和不同的团队。

2. 运营仪表板（用于系统指标）：这个仪表板类别专注于实时运营健康。它跟踪代理的核心生命体征，主要用于站点可靠性工程师（SRE）、DevOps和负责系统正常运行时间和性能的运营团队。

3. 跟踪内容：P99延迟、错误率、API成本、令牌消耗。
4. 目的：立即发现系统故障、性能下降或预算超支。
5. **示例警报：**警报：P99延迟超过3秒，持续5分钟。这表明系统存在瓶颈，需要立即的工程关注。
6. 质量仪表板（用于质量指标）：这个类别跟踪代理有效性和正确性的更微妙、更缓慢变化的指标。对于负责代理决策和输出质量的PM、数据科学家和AgentOps团队至关重要。
7. 跟踪内容：事实正确性评分、轨迹遵循度、有用性评分、幻觉率。
   • 目的：检测代理质量在部署新模型或提示后的微妙变化。

8. 示例警报：警报：有用性评分'在过去24小时内下降了10%。这表明虽然系统可能运行良好（系统指标正常），但代理的输出质量正在下降，需要对其逻辑或数据进行调查。

9. 安全性与PII：保护您的数据 这是生产操作中不可协商的一个方面。日志和跟踪中捕获的用户输入往往包含个人身份信息（PII）。在长期存储数据之前，必须将强大的PII清洗机制集成到日志管道中，以确保符合隐私法规并保护您的用户。

10. 核心权衡：粒度与开销 在生产环境中，为每个请求捕获高度详细的日志和跟踪可能成本高昂，并会增加系统延迟。关键是要找到战略平衡。

11. 最佳实践 - 动态采样：在开发环境中使用高粒度日志（DEBUG级别）。在生产中，设置较低的默认日志级别（INFO），但实现动态采样。例如，你可能决定只跟踪10%的成功请求，但跟踪100%的错误请求。这为你提供了广泛的性能数据，用于指标，同时不会压倒系统，同时仍然捕获你调试每个故障所需的丰富诊断细节。

5.6 摘要及下一步

要信任一个自主代理，你必须首先能够理解其过程。在没有了解他们的食谱、技术和决策过程的情况下，你不会评判一位美食大厨的最终作品。本章已经确立，可观察性是我们了解代理的关键框架。它提供了“厨房内的眼睛和耳朵”。

我们已经了解到，强大的可观察性实践建立在三个基础支柱之上，它们共同将原始数据转化为完整的画面：

• 日志：结构化的日记，提供了每个步骤发生事件的详细、事实记录。
• 跟踪：连接单个日志的叙事故事，展示了导致事件发生的原因路径。
• 指标：综合报告卡，总结在规模上的性能，告诉我们事情进行得如何。我们进一步将这些指标分为关键的系统指标（如延迟和成本）和关键的质量指标（如正确性和实用性）。

通过将这些支柱组合成一个连贯的运营系统，我们从一个盲目飞行的状态转变为拥有一个清晰、数据驱动的对代理行为、效率和有效性的看法。

我们现在拥有了所有必要的部分：为什么（第一章中非确定性的问题），是什么（第二章中的评估框架），以及如何（第三章中的可观测性架构）。

在第四章中，我们将所有这些内容整合成一个单一的、可操作的剧本，展示这些组件如何形成“代理质量飞轮”——一个持续改进的循环，以构建不仅能够胜任，而且真正值得信赖的代理。

6. 结论：在自主世界建立信任

6.1 引言：从自主能力到企业信任

在本白皮书的开头，我们提出了一个基本挑战：具有非确定性和自主性质的AI代理打破了我们传统的软件质量模型。我们将评估代理的任务比作评估新员工——你不仅要问任务是否完成，还要问它是如何完成的。它是否高效？是否安全？是否创造了良好的体验？当后果是商业风险时，盲目飞行不是一种选择。

自那以后，我们的旅程一直是构建这个新范式信任的蓝图。我们通过定义代理质量的四个支柱：有效性、成本效益、安全性和用户信任，确立了建立新学科的需求。然后我们展示了如何通过可观测性（第三章）在代理的思维中获取“眼睛和耳朵”，以及如何通过全面的评估框架（第二章）来评判其性能。本文档为衡量什么以及如何观察它奠定了基础。接下来的关键一步，在随后的白皮书中介绍，“第五天：从原型到生产”，是将这些原则付诸实践。这涉及到将评估过的代理成功地在生产环境中运行，通过稳健的CI/CD管道、安全的发布策略和可扩展的基础设施。

现在，我们将所有这些内容整合在一起。这不仅仅是一个总结；这是将抽象原则转化为可靠、自我改进系统的操作剧本，弥合了评估和生产之间的差距。

6.2 代理质量飞轮：框架的综合

一个优秀的代理不仅能够执行任务，还能够自我改进。这种持续评估的学科是将一个聪明的演示与一个企业级系统区分开来的关键。这种实践创造了一个强大、自我强化的系统，我们称之为代理质量飞轮。

想象一下启动一个庞大、沉重的飞轮。第一次推动是最难的。但评估的有序实践提供了后续的持续推动。每一次推动都会增加动力，直到飞轮以不可阻挡的力量旋转，形成一个质量与信任的良性循环。这个飞轮是我们所讨论的整个框架的运营体现。

以下是各章节组件如何协同作用以构建动力的过程：

• 第一步：定义质量（目标）：飞轮需要方向。正如我们在第一章中定义的，一切始于四个质量支柱：有效性、成本效益、安全性和用户信任。这些支柱不是抽象的理想，而是赋予我们的评估工作意义并使飞轮与真实商业价值保持一致的实质性目标。
• 第二步：建立可见性工具（基础）：你无法管理你看不见的东西。正如我们在可观察性章节中详细阐述的，我们必须指导我们的Agent生成结构化的日志（Agent的日记）和端到端跟踪（叙事线索）。这种可观察性是基础实践，它产生了衡量我们四个支柱所需的大量证据，为飞轮提供了必要的燃料。
• 第三步：评估流程（引擎）：在建立可见性之后，我们现在可以评估性能。正如我们在评估章节中探讨的，这涉及战略性的“从外向内”评估，评估最终输出和整个推理过程。这是推动飞轮旋转的强大推力——一个混合引擎，使用可扩展的大语言模型作为裁判系统来提高速度，以及人工介入（HITL）“黄金标准”来确保真实性。
• 第四步：构建反馈循环（动力）：这是第一章中提到的“可评估性设计”架构得以实现的地方。通过构建关键的反馈循环，我们确保每次生产失败，一旦被捕获和标注，就会自动转换为“黄金”评估集中的永久回归测试。每一次失败都使系统变得更智能，加速飞轮旋转，推动不懈的持续改进。

6.3 构建可信Agent的三个核心原则

如果你从这个白皮书中没有学到其他东西，请记住这三个原则。它们代表了任何希望在这个新的Agent化前沿构建真正可靠自主系统的领导者的基础心态。

• 原则1：将评估视为架构支柱，而非最终步骤：还记得第一章中的赛车类比吗？你不会先造一辆一级方程式赛车然后再安装传感器。你需要从底层开始设计，加入遥测端口。Agent化工作负载需要相同的DevOps范式。可靠的Agent是“可评估性设计”的，从第一行代码开始就配备了生成日志和跟踪的必要工具。质量是架构选择，而非最终的QA阶段。
• 原则2：轨迹是真相：对于Agent来说，最终答案只是漫长故事中的最后一句话。正如我们在评估章节中确立的，衡量Agent逻辑、安全性和效率的真实标准在于其端到端的“思维过程”——轨迹。这是流程评估。要真正理解Agent成功或失败的原因，你必须分析这条路径。这只有通过我们在第三章中详细阐述的深度可观察性实践才能实现。
• 原则3：人是仲裁者：自动化是我们实现规模化的工具；人性是我们寻求真相的源泉。从大语言模型作为裁判系统到安全分类器，自动化是必不可少的。然而，正如我们在人工介入（HITL）评估的深入研究中所确立的，对“好”的基本定义、对细微输出的验证以及最终对安全和公平的判断必须基于人类价值观。人工智能可以帮助评分测试，但人类制定评分标准并决定“A+”究竟意味着什么。

6.4 未来是Agent化的——并且是可靠的

我们正处于Agent化时代的黎明。创建能够推理、规划和行动的AI的能力将是我们这个时代最具变革性的技术转变之一。但权力越大，责任越大，我们必须构建值得信赖的系统。

精通本白皮书中的概念——可以称之为“评估工程”——是下一波人工智能的关键竞争优势。那些继续将代理质量视为事后之想的组织将陷入一个充满承诺的演示和失败的部署的循环。相比之下，那些投资于这种严格、架构集成评估方法的组织将超越炒作，部署真正变革性的企业级人工智能系统。

最终目标不仅仅是构建能够工作的代理，而是构建人们信任的代理。正如我们所展示的，这种信任不是希望或偶然的结果。它是在持续、全面和架构稳健的评估熔炉中铸就的。

7. 参考文献

学术论文、书籍和正式报告

1. Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., ... & Rocktäschel, T. (2020). 基于检索增强的生成：用于知识密集型自然语言处理任务的进展。神经信息处理系统前沿，33，9459-9474。
2. Lin, S., Hilton, J., & Evans, O. (2022). TruthfulQA：衡量模型模仿人类错误陈述的能力。在计算语言学协会第60届年会（第一卷：长论文）上的论文（第3214-3252页）。
3. Li, D., Jiang, B., Huang, L., Beigi, A., Zhao, C., Tan, Z., … & Liu, H. (2024). 从生成到判断：大语言模型作为裁判的机会与挑战。arXiv预印本 arXiv:2411.16594。
4. Zhuge, M., Wang, M., Shen, X., Zhang, Y., Wang, Y., Zhang, C., … & Liu, N. (2024). 代理作为裁判：用代理评估代理。arXiv预印本 arXiv:2410.10934。 Amodei, D., Olah, C., Steinhardt, J., Christiano, P., Schulman, J., & Mané, D. (2016). 人工智能安全中的具体问题。arXiv预印本 arXiv:1606.06565。 Baysan, M. S., Uysal, S., İşlek, İ., Çiğ Karaman, Ç., & Güngör, T. (2025). LLM作为裁判：使用大语言模型自动评估搜索查询解析。大数据前沿，8。可在以下链接获取：https://doi.org/10.3389/fdata.2025.1611389。 Felderer, M., & Ramler, R. (2021). 基于人工智能系统的质量保证：概述和挑战。在软件质量：软件工程和云中软件质量的复杂性和挑战（第38-51页）。Springer国际出版社。 Hendrycks, D., Carlini, N., Schulman, J., & Steinhardt, J. (2023). 机器学习安全中的未解决问题。arXiv预印本 arXiv:2306.04944。 Ji, Z., Lee, N., Fries, R., Yu, T., Su, D., Xu, Y., … & Fung, P. (2023). 人工智能生成文本：任务、评估标准和方法的综述。arXiv预印本 arXiv:2303.07233。 Lin, C. Y. (2004). ROUGE：自动评估摘要的软件包。在ACL-O4研讨会“文本摘要分支”上的论文（第74-81页）。 美国国家标准与技术研究院。 (2023)。人工智能风险管理框架（AI RMF 1.0）。美国商务部。 Papineni, K., Roukos, S., Ward, T., & Zhu, W. J. (2002)。BLEU：机器翻译自动评估方法。在计算语言学协会第40届年会上的论文（第311-318页）。 Retzlaff, C., Das, S., Wayllace, C., Mousavi, P., Afshari, M., Yang, T., … & Holzinger, A. (2024)。人机交互强化学习：需求、挑战和机会的综述和立场。人工智能研究杂志，79，359-415。 Slattery, F., Costello, E., & Holland, J. (2024)。语言模型带来的风险分类。arXiv预印本 arXiv:2401.12903。 Taylor, M. E. (2023)。强化学习需要人机交互框架和方法。在2023年自适应和机器学习代理（ALA）研讨会上的论文。 Wei, J., Wang, X., Schuurmans, D., Bosma, M., Xia, F., Chi, E., … & Zhou, D. (2022)。思维链提示在大型语言模型中引发推理。神经信息处理系统前沿，35，24824-24837。 张，T.，基肖尔，V.，吴，F.，温伯格，K. Q.，& 阿特齐，Y. (2020). BERTScore：使用BERT评估文本生成。载于国际学习表示会议。

网络文章、博客文章及通用网页

Bunnyshell. (n.d.). LLM-as-a-Judge：AI如何更快、更智能地评估AI。检索日期：2025年9月16日，来自https://www.bunnyshell.com/blog/when-ai-becomes-the-judge-understanding-llm-as-a-j/. Coralogix. (n.d.). OpenTelemetry for AI：跟踪提示、工具和推理。检索日期：2025年9月16日，来自https://coralogix.com/ai-blog/opentelemetry-for-ai-tracing-prompts-tools-and-inferences/. 德拉普金，A. (2025年9月2日). AI出错：2023-2025年AI的错误、失误和幻觉。Tech.co。检索日期：2025年9月16日，来自https://tech.co/news/list-ai-failures-mistakes-errors。 Dynatrace. (n.d.). 什么是OpenTelemetry？一个用于日志、指标和跟踪的开源标准。检索日期：2025年9月16日，来自https://www.dynatrace.com/news/blog/what-is-opentelemetry/。 Galileo. (n.d.). LLM-as-a-Judge评估全面指南。检索日期：2025年9月16日，来自https://galileo.ai/blog/llm-as-a-judge-guide-evaluation。 Gofast.ai. (n.d.). 实际世界中的Agent幻觉：当AI工具出错时。检索日期：2025年9月16日，来自https://www.gofast.ai/blog/ai-bias-fairness-agent-hallucinations-validation-drift-2025。 IBM. (2025年2月25日). 什么是LLM可观察性？检索日期：2025年9月16日，来自https://www.ibm.com/think/topics/llm-observability。 麻省理工学院斯隆商学院教学与学习技术。 (n.d.). 当AI出错时：解决AI幻觉和偏见。检索日期：2025年9月16日，来自https://mitsloanedtech.mit.edu/ai/basics/addressing-ai-hallucinations-and-bias/。 ResearchGate. (n.d.). (PDF) LLM-as-a-Judge调查。检索日期：2025年9月16日，来自https://www.researchgate.net/publication/386112851_A_Survey_on_LLM-as-a-Judge。 TrustArc. (n.d.). 美国国家标准与技术研究院（NIST）人工智能风险管理。检索日期：2025年9月16日，来自https://trustarc.com/regulations/nist-ai-rmf/。 Gofast.ai. (n.d.). 实际世界中的Agent幻觉：当AI工具出错时。检索日期：2025年9月16日，来自https://www.gofast.ai/blog/ai-bias-fairness-agent-hallucinations-validation-drift-2025。 IBM. (2025年2月25日). 什么是LLM可观察性？检索日期：2025年9月16日，来自https://www.ibm.com/think/topics/llm-observability。 麻省理工学院斯隆商学院教学与学习技术。 (n.d.). 当AI出错时：解决AI幻觉和偏见。检索日期：2025年9月16日，来自https://mitsloanedtech.mit.edu/ai/basics/addressing-ai-hallucinations-and-bias/。