面向生产环境评测人工智能智能体:Strands Evals 实践指南
本文说明如何用 Strands Evals 评测生产智能体:用例、实验与评测器,在线与离线任务函数,多轮用户模拟,以及接入持续集成的质量门禁。

目录
#面向生产环境评测人工智能智能体:Strands Evals 实践指南
把人工智能智能体(AI agents)从原型推进到生产环境,会遇到传统测试无法处理的问题。智能体在设计上灵活、自适应,并且感知上下文,但让它变得强大的这些特质,也让系统化评测变得困难。
传统软件测试依赖确定性输出:同样的输入,每次都得到同样的预期输出。人工智能智能体打破了这一假设。它们生成自然语言,做出依赖上下文的决策,即便输入完全相同,输出也会变化。你如何系统化地评测一个非确定性的对象?
在本文中,我们说明如何使用 Strands Evals(https://github.com/strands-agents/evals)系统化评测人工智能智能体。我们会走过核心概念、内置评测器、多轮模拟能力,以及接入时的实践方法和模式。Strands Evals 为使用 Strands Agents SDK 构建的人工智能智能体提供结构化评测框架,包含评测器、模拟工具和报告能力。无论你需要核验智能体是否使用了正确的工具、是否产出有帮助的响应,还是是否把用户引向目标,该框架都提供基础设施,用来测量并跟踪这些特质。
评测人工智能智能体为何不同
当你问智能体“东京天气怎么样?”,存在许多有效响应,没有唯一绝对正确的答案。智能体可能用摄氏或华氏报告温度,可能带上湿度和风,也可能只关注温度。这些变化都可以是正确且有帮助的,这正是传统基于断言的测试不够用的原因。除了生成文本,智能体还会采取行动。设计良好的智能体会调用工具、检索信息,并在整段对话中做决策。只评测最终响应,会漏掉智能体是否采取了恰当步骤才到达该响应。
即便正确的响应也可能不够。一段响应可能事实准确但没有帮助,或者有帮助但并不忠于来源材料。没有单一指标能覆盖这些不同的质量维度。对话又增加一层复杂性,因为它们随时间展开。在多轮交互中,较早的响应会影响后来的响应。智能体可能单独处理每一次查询都很好,却无法在整段对话中维持连贯上下文。孤立地测试单轮,会错过这些交互模式。
这些特点要求评测依靠判断,而不是关键词比对。基于大语言模型(large language model,LLM)的评测应对这一需求。把语言模型用作评测器,可以评估有帮助程度、连贯性和忠实度这类难以机械检查的特质。Strands Evals 接受这种灵活性,同时仍提供严格、可重复的质量评估。
Strands Evals 的核心概念
Strands Evals 遵循一种对写过单元测试(unit tests)的人应当熟悉的模式,但把它改造成人工智能智能体所需的、基于判断的评测。该框架引入三个一起工作的基础概念:用例(Cases)、实验(Experiments)和评测器(Evaluators)。
图注:高层架构(High-Level Architecture)
一条用例(Case)代表单个测试场景。它包含你要测试的输入,例如用户查询“巴黎天气怎么样?”,以及可选的预期输出、称为轨迹(trajectories)的预期工具序列,还有元数据。用例是评测的原子单位。每一条定义一个你希望智能体正确处理的场景。
from strands_evals import Case
case = Case(
name="Weather Query",
input="What is the weather like in Tokyo?",
expected_output="Should include temperature and conditions",
expected_trajectory=["weather_api"]
)一项实验(Experiment)把多条用例与一个或多个评测器捆在一起。可以把它看成传统测试里的测试套件。实验编排评测过程。它取出每条用例,在其上运行你的智能体,并应用已配置的评测器为结果打分。
评测器是裁判。它们检查智能体产出的内容(实际输出和轨迹),并与预期比较。与简单的断言检查不同,Strands Evals 中的评测器主要基于大语言模型。它们使用语言模型,对质量、相关性、有帮助程度以及其他无法归结为字符串比较的特质做出细致判断。
把这些关注点分开,有助于框架保持灵活。你用用例定义测什么,用评测器定义怎么测,框架通过实验处理编排和报告。每一块都可以独立配置,因此你可以搭建针对自身需求的评测套件。
任务函数:把智能体接到评测上
用例定义场景,评测器提供判断。但你的智能体实际上如何接到这套评测系统?这就是任务函数(Task Function)的作用。
任务函数是你提供给实验的可调用对象。它接收一条用例,并返回将该用例跑过你的系统后的结果。这一接口支持两种根本不同的评测模式。
图注:任务函数模式(Task Function Patterns)
在线评测是在评测运行期间实时调用你的智能体。你的任务函数创建智能体,把用例输入发给它,捕获响应和执行轨迹,再把它们返回以供评测。在开发期间你想立刻测试改动,或者在持续集成与持续交付(continuous integration and delivery,CI/CD)流水线中你需要在部署前核验智能体行为时,推荐使用这一模式。
from strands import Agent
def online_task(case):
agent = Agent(tools=[search_tool, calculator_tool])
result = agent(case.input)
return {
"output": str(result),
"trajectory": agent.session
}离线评测使用历史数据。任务函数不调用智能体,而是从日志、数据库或可观测性系统中取出先前记录的轨迹。它把这些轨迹解析成评测器期望的格式,再返回以供判断。当你需要评测生产流量、做历史分析,或用同一组真实用户交互比较智能体版本时,这一模式很合适。
def offline_task(case):
trace = load_trace_from_database(case.session_id)
session = session_mapper.map_to_session(trace)
return {
"output": extract_final_response(trace),
"trajectory": session
}无论你是在测试新的智能体实现,还是在分析数月的生产数据,同一套评测器和报告基础设施都适用。任务函数把你的数据源适配到评测系统。
用于全面评估的内置评测器
任务函数把智能体输出接到评测系统之后,你就可以决定要测量质量的哪些方面。Strands Evals 附带十个内置评测器,每一个用来评估智能体质量的不同维度。
图注:评测器类型(Evaluator Types)
基于量规的评测器
最灵活的评测器让你用自然语言量规(rubrics)定义自定义标准。
- 输出评测器(OutputEvaluator)评判智能体产生的最终响应。你提供一份量规,也就是对“好”的描述,评测器使用大语言模型按该标准给输出打分。当你想为自己的用例定义具体标准、做一般质量检查时,这很合适。
from strands_evals.evaluators import OutputEvaluator
output_evaluator = OutputEvaluator(
rubric="Score 1.0 if the response correctly answers the question and is well-structured. "
"Score 0.5 if partially correct. Score 0.0 if incorrect or irrelevant."
)- 轨迹评测器(TrajectoryEvaluator)把范围扩展到检查智能体采取的动作序列(通常是工具调用)。除了看最终答案,你还可以核验智能体是否以合理顺序使用了恰当工具。评测器包含三个用于比较实际轨迹与预期轨迹的内置评分函数:精确匹配、按序匹配和任意顺序匹配。这些评分器作为工具提供给评测用的大语言模型,它会根据你的量规选择最合适的一个。
- 交互评测器(InteractionsEvaluator)处理多个组件互相通信的多智能体系统。它评测智能体或系统组件之间的交互序列。当你的架构包含编排器、子智能体或复杂工具链时,这很有用。
语义评测器
有些质量维度足够常见,Strands Evals 提供了带有精心设计的提示和评分刻度的预构建评测器。
- 有帮助程度评测器(HelpfulnessEvaluator)从用户视角评估响应,使用从“完全没有帮助”到“超出预期”的七点量表。它评估响应是否真正处理了用户需求,而不只是技术上是否正确。
- 忠实度评测器(FaithfulnessEvaluator)检查响应是否扎根于对话历史。这对检索增强生成(Retrieval Augmented Generation,RAG)系统尤其重要,因为你需要确保智能体不编造信息。五点量表从“完全不”忠实到“完全是”。
- 有害性评测器(HarmfulnessEvaluator)做安全检查,帮助判断响应是否包含有害、不当或危险内容。它提供二元的是/否判断,便于明确决策。
工具级评测器
当智能体使用工具时,你常常不仅要评测最终结果,还要评测单次工具调用的质量。
- 工具选择准确性评测器(ToolSelectionAccuracyEvaluator)在上下文中检查每一次工具调用,判断在给定对话状态下选择该工具是否合理。它回答:“在对话的这一刻,调用这个工具是否合理?”
- 工具参数准确性评测器(ToolParameterAccuracyEvaluator)更进一步,检查传给每个工具的参数是否正确且恰当。它帮助抓住一类细微错误:选对了工具,但调用时参数错误或不完整。
会话级评测器
- 目标成功率评测器(GoalSuccessRateEvaluator)采取最宽的视角,评测整个对话会话,判断用户最终是否达成目标。对面向任务的智能体,成功由结果定义,而不是由单次响应定义。
选择合适的评测器
选择取决于对你的应用什么最重要。客服智能体可能优先考虑有帮助程度和目标成功。研究助理可能强调忠实度。先从覆盖核心质量维度的一小套评测器开始,然后随着你了解智能体如何失败再增加。
为多轮测试模拟用户
前面提到的评测器适合单轮交互:你提供输入,得到输出,再评测它。多轮对话提出更难的挑战。真实用户不按脚本走。他们追问、改变方向、表达困惑。你如何测试这一点?Strands Evals 包含行动者模拟器(ActorSimulator),它创建由人工智能驱动的模拟用户,与你的智能体进行多轮对话。
图注:用户模拟器流程(User Simulator Flow)
行动者模拟器从定义用户想达成什么的测试用例开始。由此,它使用大语言模型生成一份现实的用户画像,包括性格特质、专业水平、沟通风格和具体目标。这份画像塑造模拟用户在整段对话中的行为。
from strands_evals import Case, ActorSimulator
from strands import Agent
case = Case(
input="I need help setting up a new bank account",
metadata={"task_description": "Successfully open a checking account"}
)
user_sim = ActorSimulator.from_case_for_user_simulator(
case=case,
max_turns=10
)交互期间,模拟用户向你的智能体发送消息,接收响应,并决定下一句说什么。这个循环持续到目标达成(以发出一个特殊停止标记来表示),或达到最大轮数。
agent = Agent(system_prompt="You are a helpful banking assistant.")
user_message = case.input
while user_sim.has_next():
agent_response = agent(user_message)
user_result = user_sim.act(str(agent_response))
user_message = str(user_result.structured_output.message)然后你可以把得到的对话记录交给会话级评测器,例如目标成功率评测器,以评估你的智能体是否成功帮助模拟用户达成目标。你不必手工编写多轮脚本,而是定义目标,让模拟器生成现实的交互模式。它可能提出意料之外的追问、表达困惑,或把对话带向你没有预料的方向,从而抓住脚本测试可能错过的边界情况。
评测层级:理解层次结构
无论使用模拟对话还是真实对话,不同评测器在不同粒度上运作。Strands Evals 使用轨迹提取器(TraceExtractor)把会话数据解析成每个评测器所需的格式。
会话级评测看的是从头到尾的完整对话。评测器收到完整历史和工具执行,并理解整个上下文。目标成功率评测器在这一层工作,因为判断目标是否达成需要理解整段交互。
轨迹级评测聚焦单轮,即每一对用户提示和智能体响应。这一层的评测器收到到该点为止的对话历史,并评判这一次具体响应。有帮助程度、忠实度和有害性评测器在这里工作,因为这些特质可以逐轮评估。
工具级评测下钻到单次工具调用。每一次工具调用都在上下文中评测,可以访问可用工具、到目前为止的对话,以及传入的具体参数。工具选择和工具参数评测器在这一粒度上运作。
你可以利用这种层次设计,组合同时在多层检查质量的评测套件。在单次评测运行中,你可以核验单次工具调用是否合理、响应是否有帮助,以及总体目标是否达成。
基准事实与预期行为
在许多不同的评测层级上,评测器都可以从用于比较的参照点中受益。Strands Evals 通过用例上的三个预期字段,为一等公民式的基准事实(ground truth)提供支持。
expected_output 字段指定智能体应该说什么。当存在正确答案或标准响应格式时,这很有用。expected_trajectory 字段定义智能体应该采取的工具或动作序列。你可能要求客服智能体在做更改之前先检查账户状态,或要求研究智能体在综合之前查询多个来源。并非每条用例都需要每个字段。你根据评测目标所关心的内容定义预期。提供预期值后,评测器同时收到预期结果和实际结果,从而可以在独立质量评估之外做基于比较的评分。
把各部分合在一起
我们走一遍典型评测工作流,看这些概念如何合到一处。
图注:评测流程(Evaluation Flow)
首先,你定义测试用例,也就是你希望智能体处理好的场景。它们可以来自真实用户查询、合成生成,或你已经识别出的边界情况。
from strands_evals import Experiment, Case
from strands_evals.evaluators import OutputEvaluator, TrajectoryEvaluator
from strands_evals.extractors import tools_use_extractor
cases = [
Case(
name="Weather Query",
input="What is the weather like in Tokyo?",
expected_output="Should include temperature and conditions",
expected_trajectory=["weather_api"]
),
Case(
name="Calculator Usage",
input="What is 15% of 847?",
expected_output="127.05",
expected_trajectory=["calculator"]
)
]接下来,你用适当的量规或设置配置评测器。
output_evaluator = OutputEvaluator(
rubric="Score 1.0 if the response is accurate and directly answers the question. "
"Score 0.5 if partially correct. Score 0.0 if incorrect or irrelevant."
)
trajectory_evaluator = TrajectoryEvaluator(
rubric="Verify the agent used appropriate tools for the task."
)然后,你创建一项把用例和评测器捆在一起的实验。
experiment = Experiment(
cases=cases,
evaluators=[output_evaluator, trajectory_evaluator]
)最后,你用任务函数运行评测并检查结果。
def my_task(case):
agent = Agent(tools=[weather_tool, calculator_tool])
result = agent(case.input)
return {
"output": str(result),
"trajectory": tools_use_extractor.extract_agent_tools_used(agent.messages)
}
reports = experiment.run_evaluations(my_task)
for report in reports:
report.display()评测报告(EvaluationReport)提供总体分数、按用例的分解、通过/失败状态,以及每个评测器的详细理由。你可以在控制台交互式展示结果,导出为 JSON 做进一步分析,或接入持续集成与持续交付流水线。对更大的测试套件,Strands Evals 支持可配置并行度的异步评测:
reports = await experiment.run_evaluations_async(my_task, max_workers=10)大规模生成测试用例
前面的工作流假设你已经有测试用例。随着智能体能力增长,手工创建全面的测试套件很繁琐。Strands Evals 包含实验生成器(ExperimentGenerator),它使用大语言模型,根据高层描述创建测试用例和评测量规。
from strands_evals.generators import ExperimentGenerator
from strands_evals.evaluators import OutputEvaluator
generator = ExperimentGenerator(
input_type=str,
output_type=str,
include_expected_output=True
)
experiment = await generator.from_context_async(
context="A customer service agent for an e-commerce platform",
task_description="Handle customer inquiries about orders, returns, and products",
num_cases=20,
evaluator=OutputEvaluator
)生成器会创建覆盖指定上下文不同方面、难度适当的多样化测试用例。它也可以生成针对该任务定制的评测量规。在早期开发中,当你想要广泛覆盖、但还没有识别出具体失败模式时,生成的用例尤其有价值。随着评测实践成熟,用针对已知边界情况手工编写的场景补充生成的用例。
把评测接入你的工作流
当评测成为常规开发工作流的一部分时,它最能带来价值。开发期间,在你做出改动时频繁运行评测。快速反馈帮助你尽早抓住回归,并理解改动如何影响不同质量维度。
在持续集成与持续交付流水线中,把评测作为部署前的质量门禁。设定构建必须达到的分数阈值。这有助于阻止质量回归进入生产。对于生产监控,使用离线评测定期评估真实用户交互。这会揭示开发测试可能错过的模式:不寻常的查询、你没有预料的边界情况,或智能体行为的逐渐漂移。随时间跟踪评测结果。趋势指标帮助你理解质量是在改善还是在下降。
智能体评测的最佳实践
- 从小处开始并迭代:先用少量覆盖最关键用户场景的测试用例。当你观察到智能体在实践中如何失败,再增加针对这些具体失败模式的用例。一套能抓住真实问题的聚焦测试套件,比覆盖很差的大套件更有价值。
- 让评测器匹配你的质量目标:选择直接测量对你的用例重要事项的评测器。面向客户的智能体可能优先使用有帮助程度评测器和目标成功率评测器,而研究助理可能更看重忠实度评测器。避免把每个可用评测器都加进去的诱惑,因为这会增加成本,也可能冲淡焦点。
- 写出清晰、具体的量规:基于量规的评测器好不好,只取决于你提供的量规。避免“好的响应”这类含糊标准,改用具体、可测量的标准。加入高分、中分和低分各是什么样的例子。在跑完整评测之前,先在样例输出上测试你的量规。
- 结合在线评测与离线评测:开发期间用在线评测,对代码改动获得快速反馈。再用生产轨迹的离线评测作为补充,抓住只在真实用户行为中出现的问题。两种方法揭示不同类型的问题。
- 设定有意义的阈值:根据你实际的质量要求定义通过/失败阈值,而不是任意数字。如果用户需要 0.95 的准确度,0.8 的阈值就没有意义。分析评测结果,理解哪些分数与良好的用户结果相关,再据此设定阈值。
- 随时间跟踪趋势:单次评测运行提供快照,趋势才揭示走向。保存评测结果,并跨版本跟踪关键指标。逐渐退化比突然失败更难注意到,但同样有损害。
- 投入于测试用例的多样性:覆盖智能体将遇到的全部输入范围:常见查询、边界情况、对抗性输入和多轮对话。用实验生成器做广泛覆盖,再用针对已知弱点手工编写的用例补充。
- 在多个层级评测:会话级成功可能掩盖工具级问题,反过来也一样。智能体可能通过低效或不正确的中间步骤达成用户目标。组合在会话、轨迹和工具层级检查质量的评测套件,才能得到完整图景。
结论
构建可靠的人工智能智能体,需要的不只是直觉和抽查。它需要系统化评测,随时间在多个维度上跟踪质量。Strands Evals 通过专门针对智能体评测独特挑战而设计的框架,帮助提供这一基础。
任务函数把智能体调用与评测逻辑分开,既能在开发期间做在线测试,也能对生产轨迹做离线分析。基于大语言模型的评测器提供质量评估所需的判断。层次化评测层级允许在多种粒度上评估,从单次工具调用到完整对话会话。用户模拟器则把多轮测试从编写脚本变成对现实用户行为的模拟。
这些能力帮助你用证据而不是假设,对人工智能智能体建立信心。你可以测量改动是改善还是降低质量,在回归到达生产之前抓住它们,并向干系人证明你的智能体达到了已定义的质量标准。
我们鼓励你为智能体评测需求探索 Strands Evals。示例仓库(https://github.com/strands-agents/samples/tree/main/07-evals)包含你可以改用于自己用例的实践示例。从代表最重要用户场景的几条测试用例开始,加入匹配质量标准的评测器,并把评测作为开发工作流的一部分来运行。随时间扩展测试套件以覆盖更多场景。系统化评测是帮助你有信心交付人工智能智能体的基础。
PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/evaluating-ai-agents-for-production-a-practical-guide-to-strands-evals
- #智能体评测
- #Strands Evals
- #质量门禁
- #持续集成
- #生产验收


