第19章:评估与监控 Evaluation and Monitoring
本章探讨了AI智能体系统化评估其性能、监控目标进展以及检测运行异常的方法论。尽管第十一章概述了目标设定与监控,第十七章讨论了推理机制,本章重点关注智能体的有效性、效率以及对需求的持续、通常是外部的测量。这包括定义指标、建立反馈循环以及实施报告系统,以确保智能体的性能在操作环境中符合预期(见图1)。

图1:评估与监控的最佳实践
实际应用与使用案例
最常见的应用与使用案例:
- 实时系统中的性能跟踪: 持续监控部署在生产环境中的智能体的准确性、延迟以及资源消耗(例如,客户服务聊天机器人的问题解决率、响应时间)。
- 智能体改进的 A/B 测试: 系统化地比较不同版本或策略的智能体性能,以并行方式识别最佳方法(例如,对物流智能体尝试两种不同的规划算法)。
- 合规性与安全审计: 生成自动化审计报告,跟踪智能体在道德准则、法规要求以及安全协议方面的合规性。这些报告可以由人工或其他智能体验证,并在发现问题时生成关键绩效指标(KPI)或触发警报。
- 企业系统: 为治理企业系统中的智能体型人工智能,需要一种新的控制工具,即 AI“合同”。这种动态协议对 AI 委派任务的目标、规则和控制进行编码。
- 漂移检测: 监控智能体输出的相关性或准确性,检测由于输入数据分布变化(概念漂移)或环境变化导致性能下降的情况。
- 智能体行为中的异常检测: 识别智能体采取的异常或意外行为,这可能表明错误、恶意攻击或不希望出现的行为的产生。
- 学习进展评估: 对于设计为学习的智能体,跟踪其学习曲线、特定技能的提升或在不同任务或数据集上的泛化能力。
实操代码示例
为 AI 智能体开发综合评估框架是一项具有挑战性的任务,其复杂性堪比一个学术学科或一篇重要的出版物。这种难度源于需要考虑的多种因素,例如模型性能、用户交互、伦理影响以及更广泛的社会影响。然而,为了实际实施,可以将重点缩小到对 AI 智能体高效运行至关重要的关键使用案例。
智能体响应评估: 这一核心过程对于评估智能体输出的质量和准确性至关重要。它涉及确定智能体是否能够根据给定输入提供相关、正确、逻辑、无偏见且准确的信息。评估指标可能包括事实正确性、流畅性、语法精确性以及对用户意图的遵循。
def evaluate_response_accuracy(agent_output: str, expected_output: str) -> float:
"""计算智能体响应的简单准确性得分。"""
# 这是一个非常基础的精确匹配;实际应用中会使用更复杂的指标
return 1.0 if agent_output.strip().lower() == expected_output.strip().lower() else 0.0
## 示例用法
agent_response = "The capital of France is Paris."
ground_truth = "Paris is the capital of France."
score = evaluate_response_accuracy(agent_response, ground_truth)
print(f"响应准确性得分: {score}")
Python函数evaluate_response_accuracy通过对AI智能体的输出与预期输出进行严格的、不区分大小写的比较来计算基本的准确性分数。在比较之前会移除字符串的首尾空格,若完全匹配则返回分数1.0,否则返回0.0,表示二元的正确或错误评估。这种方法虽然适用于简单检查,但无法处理诸如改写或语义等价的变体。
问题在于其比较方法。该函数对两个字符串执行严格的逐字符比较。在以下示例中:
- agent_response: "The capital of France is Paris."
- ground_truth: "Paris is the capital of France."
即使移除空格并转换为小写,这两个字符串也不完全相同。因此,函数会错误地返回准确性分数0.0,尽管两句话表达了相同的含义。
简单的比较在评估语义相似性时显得不足,仅在智能体的响应与预期输出完全匹配时才有效。更有效的评估需要先进的自然语言处理(NLP)技术来辨别句子之间的意义。在实际场景中,为了全面评估AI智能体,通常需要更复杂的指标。这些指标可以包括字符串相似性度量(如Levenshtein距离和Jaccard相似度)、关键词分析(检查特定关键词的存在与否)、语义相似度(使用嵌入模型的余弦相似度)、基于LLM的评估(稍后讨论,用于评估细微的正确性和帮助性),以及基于RAG的指标(如真实性和相关性)。
延迟监控:
在AI智能体的响应或操作速度至关重要的应用中,延迟监控是不可或缺的。该过程用于测量智能体处理请求并生成输出所需的时间。过高的延迟会对用户体验和智能体的整体有效性产生负面影响,尤其是在实时或交互式环境中。在实际应用中,仅将延迟数据打印到控制台是不够的。建议将此信息记录到持久存储系统中。可选方案包括结构化日志文件(例如JSON)、时间序列数据库(例如InfluxDB、Prometheus)、数据仓库(例如Snowflake、BigQuery、PostgreSQL)或可观测性平台(例如Datadog、Splunk、Grafana Cloud)。
追踪LLM交互的Token使用情况:
对于基于LLM的智能体,追踪Token使用情况对于管理成本和优化资源分配至关重要。LLM交互的计费通常取决于处理的Token数量(输入和输出)。因此,高效的Token使用可以直接降低运营成本。此外,监控Token数量有助于发现提示工程或响应生成过程中的潜在改进空间。
## 这是概念性代码,实际的Token计数依赖于具体的LLM API
class LLMInteractionMonitor:
def __init__(self):
self.total_input_tokens = 0
self.total_output_tokens = 0
def record_interaction(self, prompt: str, response: str):
# 在实际场景中,使用LLM API的Token计数器或分词器
input_tokens = len(prompt.split()) # 占位符
output_tokens = len(response.split()) # 占位符
self.total_input_tokens += input_tokens
self.total_output_tokens += output_tokens
print(f"记录交互:输入Token={input_tokens}, 输出Token={output_tokens}")
def get_total_tokens(self):
return self.total_input_tokens, self.total_output_tokens
## 示例用法
monitor = LLMInteractionMonitor()
monitor.record_interaction("What is the capital of France?", "The capital of France is Paris.")
monitor.record_interaction("Tell me a joke.", "Why don't scientists trust atoms? Because they make up everything!")
input_t, output_t = monitor.get_total_tokens()
print(f"Total input tokens: {input_t}, Total output tokens: {output_t}")
本节介绍了一个概念性的 Python 类 LLMInteractionMonitor,用于跟踪大型语言模型交互中的令牌使用情况。该类包含输入和输出令牌的计数器。其 record_interaction 方法通过分割提示和响应字符串来模拟令牌计数。在实际实现中,将使用特定的 LLM API 分词器来精确计算令牌数量。随着交互的发生,监视器会累积输入和输出令牌的总数。get_total_tokens 方法提供了这些累计总数的访问权限,这对于成本管理和优化 LLM 使用至关重要。
使用 LLM 作为评判者的“帮助性”自定义指标: 评估 AI 智能体“帮助性”等主观质量的挑战超出了标准的客观指标范围。一种潜在框架是使用 LLM 作为评估者。这种 LLM-as-a-Judge 方法基于预定义的“帮助性”标准评估另一个 AI 智能体的输出。利用 LLM 的高级语言能力,该方法提供了对主观质量的细致入微、类似人类的评估,超越了简单的关键词匹配或基于规则的评估。尽管仍在开发中,但该技术在自动化和扩展定性评估方面展现了潜力。
import google.generativeai as genai
import os
import json
import logging
from typing import Optional
## --- 配置 ---
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
## 将您的 API 密钥设置为环境变量以运行此脚本
## 例如,在您的终端中输入:export GOOGLE_API_KEY='your_key_here'
try:
genai.configure(api_key=os.environ["GOOGLE_API_KEY"])
except KeyError:
logging.error("错误:未设置 GOOGLE_API_KEY 环境变量。")
exit(1)
## --- 用于法律调查质量的 LLM-as-a-Judge 评估标准 ---
LEGAL_SURVEY_RUBRIC = """
您是一位专家级法律调查方法学家和严谨的法律审查员。
您的任务是评估给定法律调查问题的质量。
请提供一个从 1 到 5 的整体质量评分,并附上详细的理由和具体反馈。
重点关注以下标准:
"""
{
"overall_score": 5,
"rationale": "The survey evaluation rubric is comprehensive, clear, and well-structured. It provides precise criteria for assessing legal survey questions, ensuring neutrality, relevance, and appropriateness for the target audience.",
"detailed_feedback": [
{
"criterion": "Clarity & Precision",
"score": 5,
"feedback": "The rubric is perfectly clear and unambiguous. Each scoring level is well-defined, and the terminology used is precise."
},
{
"criterion": "Neutrality & Bias",
"score": 5,
"feedback": "The rubric avoids any leading language and is entirely objective, ensuring unbiased evaluation of survey questions."
},
{
"criterion": "Relevance & Focus",
"score": 5,
"feedback": "The rubric is directly relevant to the evaluation of legal survey questions and maintains focus on the specific aspects of survey quality."
},
{
"criterion": "Completeness",
"score": 5,
"feedback": "The rubric provides all necessary context and details for thorough evaluation, leaving no critical information omitted."
},
{
"criterion": "Appropriateness for Audience",
"score": 5,
"feedback": "The rubric is tailored for professionals with legal knowledge, using accessible yet precise language suitable for the intended audience."
}
],
"concerns": [],
"recommended_action": "Approve as is"
}
尝试以下代码:
try:
logging.info(f"正在向模型 '{self.model.model_name}' 发送请求以进行判断...")
response = self.model.generate_content(
full_prompt,
generation_config=genai.types.GenerationConfig(
temperature=self.temperature,
response_mime_type="application/json"
)
)
# 检查内容是否因内容审核或其他原因导致响应为空。
if not response.parts:
safety_ratings = response.prompt_feedback.safety_ratings
logging.error(f"LLM响应为空或被阻止。安全评级: {safety_ratings}")
return None
return json.loads(response.text)
except json.JSONDecodeError:
logging.error(f"无法将LLM响应解码为JSON。原始响应: {response.text}")
return None
except Exception as e:
logging.error(f"在LLM判断期间发生了意外错误: {e}")
return None
## --- 示例使用 ---
if __name__ == "__main__":
judge = LLMJudgeForLegalSurvey()
# --- 良好的示例 ---
good_legal_survey_question = """
您在多大程度上同意或不同意瑞士现行的知识产权法能够充分保护符合联邦最高法院规定的原创性标准的AI生成内容?
(请选择一个:非常不同意,不同意,中立,同意,非常同意)
"""
print("\n--- 评估良好的法律调查问题 ---")
judgment_good = judge.judge_survey_question(good_legal_survey_question)
if judgment_good:
print(json.dumps(judgment_good, indent=2))
# --- 有偏见/不良的示例 ---
biased_legal_survey_question = """
您是否同意像《联邦数据保护法》(FADP)这样过于严格的数据隐私法正在阻碍瑞士的关键技术创新和经济增长?
(请选择一个:是,否)
"""
print("\n--- 评估有偏见的法律调查问题 ---")
judgment_biased = judge.judge_survey_question(biased_legal_survey_question)
if judgment_biased:
print(json.dumps(judgment_biased, indent=2))
# --- 模糊/含糊的示例 ---
vague_legal_survey_question = """
您对法律技术有何看法?
"""
print("\n--- 评估模糊的法律调查问题 ---")
judgment_vague = judge.judge_survey_question(vague_legal_survey_question)
if judgment_vague:
print(json.dumps(judgment_vague, indent=2))
这段Python代码定义了一个名为 LLMJudgeForLegalSurvey 的类,用于使用生成式AI模型评估法律调查问题的质量。它使用 google.generativeai 库与Gemini模型交互。
核心功能包括将调查问题连同详细的评估标准发送至模型。评估标准包括五个方面:清晰性与精确性、中立性与偏见、相关性与重点、完整性以及适合目标受众。每个标准都会分配一个1到5的评分,并要求输出详细的理由和反馈。
judge_survey_question 方法将构建的提示发送到配置的Gemini模型,并请求格式化为定义结构的JSON响应。预期的输出JSON包括总体评分、总结性理由、每个标准的详细反馈、问题列表以及建议的行动方案。该类处理AI模型交互过程中可能出现的错误,例如JSON解码问题或空响应。脚本通过评估法律调查问题的示例来演示其操作,展示AI如何根据预定义标准评估质量。
在结束之前,让我们审视各种评估方法,分析它们的优点和缺点。
| 评估方法 | 优点 | 缺点 |
|---|---|---|
| 人工评估 | 能捕捉微妙行为 | 难以扩展,成本高且耗时,因为需要考虑主观的人为因素。 |
| LLM作为评判者 | 一致、高效且可扩展 | 可能忽略中间步骤,受限于LLM的能力。 |
| 自动化指标 | 可扩展、高效且客观 | 在捕捉完整能力方面可能存在局限性。 |
智能体轨迹
评估智能体的轨迹至关重要,因为传统的软件测试方法不足以满足需求。标准代码测试通常会产生可预测的通过/失败结果,而智能体的运行具有概率性,这需要对最终输出以及智能体的轨迹——即解决问题所采取的步骤序列——进行定性评估。评估多智能体系统尤为困难,因为它们始终处于动态变化中。这需要开发超越单个性能评估的复杂指标,以衡量沟通和团队协作的有效性。此外,由于环境本身也并非静态,评估方法(包括测试用例)需要随着时间进行调整。
这包括审查决策质量、推理过程以及整体结果。实施自动化评估尤为重要,特别是在原型开发阶段之后。分析轨迹和工具使用情况包括评估智能体为实现目标所采取的步骤,例如工具选择、策略以及任务效率。例如,一个智能体在处理客户产品查询时,理想的轨迹可能包括意图确定、数据库搜索工具使用、结果审查以及报告生成。智能体的实际行为会与预期的或称为“真实值”的轨迹进行比较,以识别错误和低效之处。比较方法包括完全匹配(要求与理想序列完全一致)、顺序匹配(正确的动作按顺序出现,允许额外步骤)、任意顺序匹配(正确的动作以任意顺序出现,允许额外步骤)、精确度(衡量预测动作的相关性)、召回率(衡量捕获关键动作的数量)以及单工具使用(检查是否执行了特定动作)。指标的选择取决于具体的智能体需求,高风险场景可能需要完全匹配,而更灵活的场景可能采用顺序匹配或任意顺序匹配。
评估 AI 智能体主要涉及两种方法:使用测试文件和使用评估集文件。测试文件采用 JSON 格式,表示单一、简单的智能体模型交互或会话,适用于活跃开发期间的单元测试,重点在于快速执行和简单会话复杂性。每个测试文件包含一个会话,包含多个轮次(turns),其中每轮次包括用户与智能体的交互,包括用户查询、预期工具使用轨迹、中间智能体响应以及最终响应。例如,一个测试文件可能详细描述用户请求“关闭卧室中的设备_2”,并指定智能体使用 set_device_info 工具,参数包括 location: Bedroom, device_id: device_2, 和 status: OFF,以及预期的最终响应“我已将设备_2的状态设置为关闭”。测试文件可以组织到文件夹中,并可能包含一个 test_config.json 文件,用于定义评估标准。评估集文件使用称为“评估集”的数据集来评估交互,包含多个可能较长的会话,适合模拟复杂的多轮对话和集成测试。一个评估集文件由多个“评估”(evals)组成,每个评估表示一个独特的会话,包含一个或多个“轮次”,包括用户查询、预期工具使用、中间响应以及参考最终响应。例如,一个评估集可能包括一个会话,用户首先询问“你能做什么?”然后说“掷两次10面骰子,然后检查9是否是质数”,定义预期的 roll_die 工具调用和 check_prime 工具调用,以及最终响应总结骰子结果和质数检查。
多智能体系统:评估一个由多个智能体组成的复杂 AI 系统类似于评估一个团队项目。由于涉及许多步骤和交接,其复杂性成为一种优势,可以检查每个阶段的工作质量。可以评估每个单独“智能体”在其特定任务中的表现,同时也必须评估整个系统的整体表现。
为此,需要通过具体示例提出关于团队协作的关键问题:
- 智能体是否有效合作? 例如,在“航班预订智能体”成功预订航班后,是否能够正确传递日期和目的地信息给“酒店预订智能体”?如果合作失败,可能会导致酒店被预订到错误的时间段。
- 他们是否制定了良好的计划并严格执行? 假设计划是先预订航班,然后预订酒店。如果“酒店智能体”在航班确认之前尝试预订房间,则偏离了计划。还需要检查智能体是否陷入困境,例如无休止地搜索“完美”的租车而无法进入下一步。
- 是否为正确的任务选择了合适的智能体? 如果用户询问旅行期间的天气,系统应该使用一个提供实时数据的专业“天气智能体”。如果系统使用了“通用知识智能体”,并给出诸如“夏天通常很暖和”这样的泛泛回答,则选择了错误的工具。
- 增加更多智能体是否提升了性能? 如果新增一个“餐馆预订智能体”到团队中,是否使整体旅行规划更好、更高效?或者是否引发冲突并拖慢系统,表明存在可扩展性问题?
从智能体到高级承包商
最近,有人提出(Agent Companion,gulli 等人),从简单的 AI 智能体进化到高级“承包商”,从概率性、通常不可靠的系统转向设计用于复杂、高风险环境的更具确定性和责任感的系统(见图2)。
当今的常见 AI 智能体通常依赖简短且定义不明确的指令运行,这使得它们适合进行简单的演示,但在实际生产环境中却表现脆弱,因为模糊性往往会导致失败。“承包商”模型通过在用户与 AI 之间建立严格且形式化的关系来解决这一问题,这种关系基于明确且双方共同认可的条款,就像人类世界中的法律服务协议一样。这种转变由四个关键支柱支持,共同确保了任务的清晰性、可靠性以及对以前超出自主系统能力范围的任务的稳健执行。
首先是形式化合同这一支柱,它是一份详细的规范,作为任务的唯一真实来源。它远远超越了简单的提示。例如,针对财务分析任务的合同不会仅仅要求“分析上季度的销售情况”,而是要求“提供一份20页的 PDF 报告,分析 2025 年第一季度欧洲市场销售情况,包括五个具体的数据可视化图表、与 2024 年第一季度的对比分析,以及基于供应链中断数据集的风险评估。”该合同明确定义了所需的交付成果、其具体规格、可接受的数据来源、工作范围,甚至包括预期的计算成本和完成时间,从而使结果可以客观验证。
其次是动态协商与反馈生命周期这一支柱。合同不是静态的命令,而是对话的开始。承包商智能体可以分析初始条款并进行协商。例如,如果合同要求使用智能体无法访问的特定专有数据源,智能体可以反馈说:“指定的 XYZ 数据库无法访问。请提供凭证或批准使用替代的公共数据库,这可能会稍微改变数据的粒度。”这一协商阶段还允许智能体标记模糊或潜在风险,在执行开始前解决误解,从而防止代价高昂的失败,并确保最终输出与用户的实际意图完全一致。

图 2:智能体之间的合同执行示例
第三个支柱是以质量为中心的迭代执行。与设计为低延迟响应的智能体不同,承包商优先考虑正确性和质量。它遵循自我验证和自我纠正的原则。例如,对于代码生成合同,智能体不仅会编写代码,还会生成多种算法方法,编译并运行这些方法以对照合同中定义的一组单元测试进行验证,按照性能、安全性和可读性等指标对每种解决方案进行评分,并仅提交通过所有验证标准的版本。这种生成、审查和改进自身工作的内部循环,直到满足合同规范为止,是建立对其输出信任的关键。
最后,第四个支柱是通过子合同进行分层分解。对于具有显著复杂性的任务,主承包商智能体可以充当项目经理,将主要目标分解为更小、更易管理的子任务。它通过生成新的、正式的“子合同”来实现这一点。例如,一个“构建电子商务移动应用程序”的主合同可以由主智能体分解为“设计 UI/UX”、“开发用户认证模块”、“创建产品数据库架构”和“集成支付网关”的子合同。这些子合同每一个都是完整的、独立的合同,具有自己的交付成果和规范,可以分配给其他专业智能体。这种结构化的分解使系统能够以高度组织化和可扩展的方式处理庞大而复杂的项目,标志着 AI 从简单工具转变为真正自主且可靠的解决问题的引擎。
最终,这种承包商框架通过将形式化规范、协商和可验证执行的原则直接嵌入智能体的核心逻辑,重新定义了人工智能的交互方式。这种系统化的方法将人工智能从一个有潜力但常常不可预测的助手提升为一个可靠的系统,能够自主管理复杂项目并具备可审计的精确性。通过解决模糊性和可靠性方面的关键挑战,该模型为人工智能在信任和责任至关重要的任务关键领域中的部署铺平了道路。
Google 的 ADK
在结束之前,让我们看一个支持评估的框架的具体例子。使用 Google 的 ADK 进行智能体评估(见图 3)可以通过三种方法进行:基于网页的用户界面(adk web)用于交互式评估和数据集生成;使用 pytest 的程序化集成,用于测试管道的整合;以及直接使用命令行界面(adk eval),适用于常规构建生成和验证过程的自动化评估。

图 3:Google ADK 的评估支持
基于网页的用户界面支持创建交互式会话并保存到现有或新的评估集,同时显示评估状态。通过 pytest 集成,可以通过调用 AgentEvaluator.evaluate 来运行测试文件,指定智能体模块和测试文件路径。
命令行界面通过提供智能体模块路径和评估集文件支持自动化评估,同时可以选择指定配置文件或打印详细结果。在较大的评估集中,可以通过在评估集文件名后列出具体的评估项并用逗号分隔来选择执行特定的评估。
概览
定义(What)
智能体系统和大型语言模型(LLMs)运行在复杂、动态的环境中,其性能可能会随着时间的推移而下降。由于其概率性和非确定性特性,传统的软件测试不足以确保其可靠性。评估动态多智能体系统是一个重大挑战,因为它们及其环境的不断变化需要开发适应性测试方法和复杂的指标,以衡量协作成功,而不仅仅是个体性能。部署后可能出现数据漂移、意外交互、工具调用以及偏离预期目标等问题。因此,需要持续评估以衡量智能体的有效性、效率以及对操作和安全要求的遵守情况。
设计意图(Why)
标准化的评估和监控框架提供了一种系统化的方法来评估和确保AI智能体的持续性能。这包括定义准确性、延迟和资源消耗(如 LLM 的 token 使用量)等明确的指标,还包括分析智能体轨迹以理解推理过程的高级技术,以及使用 LLM 作为裁判进行细致的定性评估。通过建立反馈循环和报告系统,该框架支持持续改进、A/B 测试以及异常或性能漂移的检测,从而确保智能体与其目标保持一致。
使用原则(Rule of Thumb)
在实时生产环境中部署智能体时,实时性能和可靠性至关重要时使用此模式。此外,当需要系统地比较智能体的不同版本或其底层模型以推动改进时,以及在需要遵守法规或处理高风险领域的合规性、安全性和伦理审计时使用此模式。该模式还适用于智能体的性能可能因数据或环境变化(漂移)而下降的情况,或者需要评估复杂的智能体行为,包括操作序列(轨迹)和主观输出(如帮助性)的质量时。
图解 (Visual Summary)

图 4:评估和监控设计模式
关键要点
- 对AI智能体的评估不仅限于传统测试,还需在真实环境中持续衡量其有效性、效率及对需求的遵守情况。
- 智能体评估的实际应用包括实时系统的性能跟踪、改进的 A/B 测试、合规性审计,以及检测行为中的漂移或异常。
- 基础的智能体评估涉及响应准确性的评估,而实际场景则需要更复杂的指标,例如针对 LLM 驱动智能体的延迟监控和令牌使用跟踪。
- 智能体轨迹,即智能体采取的一系列步骤,对于评估至关重要,通过将实际行动与理想的、基于事实的路径进行比较来识别错误和低效之处。
- ADK 提供了结构化的评估方法,通过单独的测试文件进行单元测试,以及通过综合评估集文件进行集成测试,两者均定义了预期的智能体行为。
- 智能体评估可以通过基于网页的用户界面进行交互式测试,通过 pytest 编程方式实现 CI/CD 集成,或通过命令行界面实现自动化工作流。
- 为了使人工智能在复杂、高风险任务中可靠运行,我们必须从简单的提示转向正式的“合同”,明确定义可验证的交付成果和范围。这种结构化协议允许智能体进行协商、澄清模糊点,并迭代验证自身工作,从而将其从不可预测的工具转变为可问责且值得信赖的系统。
结论
总而言之,有效评估 AI 智能体需要超越简单的准确性检查,转向对其在动态环境中表现的持续、多方面评估。这包括对延迟和资源消耗等指标的实际监控,以及通过智能体轨迹对其决策过程进行复杂分析。对于诸如“有用性”这样的细微特性,像 LLM-as-a-Judge 这样的创新方法变得至关重要,而 Google 的 ADK 等框架则提供了用于单元和集成测试的结构化工具。随着多智能体系统的出现,评估重点转向协作成功和有效合作。
为了确保在关键应用中的可靠性,评估范式正从简单的基于提示的智能体转向基于正式协议的高级“承包智能体”。这些承包智能体基于明确、可验证的条款运行,能够协商、分解任务并自我验证工作,以满足严格的质量标准。这种结构化方法将智能体从不可预测的工具转变为可问责的系统,能够处理复杂、高风险任务。最终,这种演变对于在关键领域部署复杂的智能体型 AI 至关重要。
参考文献
相关研究包括:
- ADK Web: https://github.com/google/adk-web
- ADK Evaluate: https://google.github.io/adk-docs/evaluate/
- 关于基于 LLM 的智能体评估的调查, https://arxiv.org/abs/2503.16416
- Agent-as-a-Judge: 使用智能体评估智能体, https://arxiv.org/abs/2410.10934
- Agent Companion, gulli 等: https://www.kaggle.com/whitepaper-agent-companion