用 AgentCore Evaluations 验收 AI 智能体质量

#用 AgentCore Evaluations 验收 AI 智能体质量

你的人工智能（AI）智能体在演示里能工作，让利益相关者印象深刻，处理了测试场景，看起来可以上生产。然后你部署了它，情况变了。真实用户遇到错误的工具调用、不一致的响应，以及测试期间没有人预料到的失败模式。

结果是，预期的智能体行为与生产中的实际用户体验之间出现缺口。智能体评估带来了传统软件测试并未设计来处理的挑战。因为大语言模型（LLM）是非确定性的，同一个用户查询在多次运行中可以产生不同的工具选择、推理路径和输出。这意味着你必须反复测试每个场景，才能理解智能体的实际行为模式。一次测试通过只告诉你可能发生什么，而不是通常发生什么。如果没有对这些变化进行系统测量，团队就会困在手工测试和被动调试的循环里。这会消耗应用程序接口（API）成本，却看不清改动是否提高了智能体性能。这种不确定性使每一次提示词修改都有风险，并留下一个根本问题没有回答：“这个智能体现在真的更好了吗？”

在本文中，我们介绍 Amazon Bedrock AgentCore Evaluations，一项用于在开发生命周期中评估 AI 智能体性能的全托管服务。我们说明该服务如何跨多个质量维度测量智能体准确性。我们解释面向开发和生产的两种评估方法，并分享构建可有信心部署的智能体的实践指导。

为什么智能体评估需要新方法

当用户向智能体发送请求时，多个决策按顺序发生。智能体决定调用哪些工具（如果有），执行这些调用，并根据结果生成响应。每一步都引入潜在失败点：选错工具、用错误参数调用正确的工具，或把工具输出综合成不准确的最终答案。与你测试单个函数输出的传统应用不同，智能体评估需要测量整个交互流上的质量。

这给智能体开发者带来可以按以下做法应对的具体挑战：

• 定义评估标准：什么构成正确的工具选择、有效的工具参数、准确的响应，以及有帮助的用户体验。
• 构建代表真实用户请求和预期行为的测试数据集。
• 选择能够在重复运行中一致评估质量的评分方法。

这些定义中的每一项都直接决定你的评估系统测量什么，把它们弄错就意味着为错误的结果做优化。没有这项基础工作，团队希望智能体做什么与他们能够证明智能体做什么之间的缺口，就会成为真实的业务风险。弥合这一缺口需要一个持续评估循环，如 _图 1_ 所示。团队构建测试用例，针对智能体运行它们，给结果评分，分析失败，并实施改进。每一次失败都变成新的测试用例，循环在智能体的每一次迭代中继续。

_图 1：智能体评估过程遵循测试用例、智能体执行、评分、分析和改进的持续循环。失败变成新的测试用例。_

然而，端到端运行这个循环，需要评估逻辑本身之外的大量基础设施。团队必须整理数据集，选择并托管评分模型，管理推理容量和 API 速率限制，构建把智能体追踪转换成可评估格式的数据流水线，并创建仪表板来可视化趋势。对运行多个智能体的组织，这种开销会随每一个智能体成倍增加。结果是，智能体开发团队最终花在维护评估工具上的时间，多于根据评估结果采取行动的时间。这就是 Amazon Bedrock AgentCore Evaluations 要解决的问题。

介绍 Amazon Bedrock AgentCore Evaluations

该服务最初在 AWS re:Invent 2025 以公开预览发布，现已正式可用。它负责评估模型、推理基础设施、数据流水线和扩展，使团队可以专注于提高智能体质量，而不是构建和维护评估系统。对内置评估器，模型配额和推理容量完全托管。这意味着评估许多智能体的组织不会消耗自己的配额，也不必为评估工作负载单独预配基础设施。

AgentCore Evaluations 使用 带生成式 AI 语义约定的 OpenTelemetry（OTEL）追踪 端到端检查智能体行为。OTEL 是用于从应用采集分布式追踪的开源可观测性标准。生成式 AI 语义约定用语言模型交互特有的字段扩展它，包括提示词、补全、工具调用和模型参数。建立在这一标准之上后，该服务可以一致地用于用任何 Strands Agents 或 LangGraph 构建、并用 OpenTelemetry 和 OpenInference 插桩的智能体，采集有意义评估所需的完整上下文。

评估可以用不同方法配置：

1. 以大语言模型为裁判（LLM-as-a-Judge），由一个 LLM 对照带有明确标准的结构化量规评估每次智能体交互。
2. 基于标准答案（Ground Truth）的评估，可用于把智能体响应与预定义或模拟数据集比较。
3. 自定义代码评估器，你可以把一个 Lambda 作为评估器，带上自己的自定义代码。

在 LLM-as-a-Judge 方法中，裁判模型检查完整交互上下文，包括对话历史、可用工具、已用工具、传入的参数和系统指令，然后在给出分数之前提供详细推理。每个分数都带有解释。团队可以用这些分数核验判断，准确理解一次交互为何得到特定评级，并识别本应有何不同。这种方法超出简单的通过／失败判断，提供结构化评估和透明推理，使质量评估达到人工评审无法匹配的规模。

三项原则指导该服务如何做评估。证据驱动的开发用定量指标取代直觉，使团队可以测量改动的实际影响，而不是争论提示词修改是否“感觉更好”。多维评估独立评估智能体行为的不同方面。这样就能精确定位需要改进的地方，而不是依赖单一汇总分数。持续测量把开发期间建立的性能基线直接连接到生产监控，确保质量在真实条件演变时仍然成立。这些原则贯穿智能体生命周期，从第一轮开发测试到持续的生产监控。

智能体生命周期中的评估

智能体从原型到生产的历程产生两种不同的评估需求。在开发期间，团队需要受控环境，以便比较备选方案、在整理好的数据集上测试智能体、复现结果，并在变更到达用户之前验证它们。智能体上线后，挑战转向大规模监控真实交互，用户会遇到任何部署前测试都没有预料到的边界情况和交互模式。_图 2_ 说明评估如何支持这一历程的每个阶段，从最初的概念验证，到影子测试、A/B 测试和持续生产监控。

_图 2：从概念验证到生产，评估在部署前验证智能体。随着智能体成熟，评估支持影子测试、A/B 测试和大规模持续监控。_

AgentCore Evaluations 把两种互补方法映射到这些生命周期阶段，如 _图 3_ 所示。在线评估处理持续的生产监控，而按需评估支持开发和持续集成与持续交付（CI/CD）工作流中的受控测试，包括对照标准答案的评估。

_图 3：在线评估持续监控生产流量，而按需评估支持开发期间的受控测试。_

用于生产监控的在线评估

在线评估通过持续抽取可配置比例的追踪，并对照你选择的评估器评分，来监控实时智能体交互。你定义要应用哪些评估器，设置控制生产流量中多大比例被评估的抽样规则，并设置适当的过滤器。该服务负责读取追踪、运行评估，并在由 Amazon CloudWatch 支持的 AgentCore Observability 仪表板 中呈现结果。如果你已经在为可观测性采集追踪，在线评估会在现有运营指标旁边增加带解释的质量分数，无需改代码或重新部署。_图 4_ 展示这一过程如何工作。

生产中的质量问题常常以传统监控错过的方式出现。运营仪表板可能在延迟和错误率上全是绿色，而用户体验却在悄悄变差，因为智能体开始选错工具或提供帮助更少的响应。持续质量评分通过把评估指标与运营指标一起跟踪，捕捉这些静默失败。因为 AgentCore Observability 运行在 CloudWatch 上，你可以创建自定义仪表板并设置告警，在分数低于阈值的那一刻得到通知。

用于开发的按需评估

按需评估是为开发和 CI/CD 工作流设计的实时 API。团队用它在部署前测试变更，把评估套件作为 CI/CD 流水线的一部分运行，跨构建做回归测试，并用质量阈值把守部署。开发者选择一个完整会话，并通过提供 ID 指定确切的跨度（span，追踪内的单个操作）或追踪。该服务考虑完整会话对话，并对照生产中使用的同一组评估器为单个跨度／追踪评分。常见使用场景包括验证提示词变更、比较备选模型的性能，以及防止质量回退。


图 5：按需评估使开发者能够准备追踪数据集，通过 CI/CD 流水线或开发环境调用评估，并使用由 Amazon Bedrock 基础模型支持的内置或自定义评估器获得分数。

因为两种模式使用相同的评估器，你在 CI/CD 中测试的就是你在生产中监控的，从而在整个开发生命周期中给出一致的质量标准。按需评估提供架构决策和系统改进所需的受控环境，而在线评估在智能体上线后继续维持质量监控。两种模式合在一起，在开发与生产之间形成持续反馈环，并且都使用同一组评估器和评分基础设施。

AgentCore 如何评估你的智能体

AgentCore Evaluations 把智能体交互组织成三层层次，决定可以评估什么以及以何种粒度评估。一次 会话 代表用户与你的智能体之间的完整对话，把来自单个用户或工作流的所有相关交互归为一组。在每个会话内，一条 追踪 捕获单次往来中发生的一切。当用户发送一条消息并收到响应时，这一来回产生一条追踪，其中包含智能体为生成答案所采取的每一步。每条追踪又包含称为 跨度 的单个操作，代表智能体执行的具体动作，例如调用工具、从知识库检索信息或生成文本。

不同评估器在这一层次的不同层级上运行，某一层的问题看起来可能与另一层的问题很不一样。该服务提供 13 个预配置的内置评估器，分布在这三个层级上，每个测量智能体行为的一个不同方面（_图 6_）。你可以定义使用 LLM-as-a-Judge 的自定义评估器，以及可以在会话、追踪和跨度层级上工作的自定义代码评估器。

_图 6：内置评估器在会话、追踪和工具层级上运行。每一层测量智能体行为的不同方面。标准答案可以作为断言、预期响应和预期轨迹，用于会话、追踪和工具层级的评估。_

独立评估每一层，有助于团队诊断问题起源于工具选择、响应生成还是会话级规划。智能体可能用准确参数选择了正确工具，然后在最终响应中把工具输出综合得很差。只有当每一层单独评估时，这种模式才会变得可见。智能体的主要用途指导优先使用哪些评估器。客户服务智能体应聚焦 _有帮助性_、_目标成功率_ 和 _指令遵循_，因为在既定护栏内解决用户问题直接影响满意度。带检索增强生成（RAG）组件的智能体最受益于 _正确性_ 和 _忠实性_，以确保响应基于所提供的上下文。工具密集的智能体需要较高的 _工具选择准确性_ 和 _工具参数准确性_ 分数。建议先从与智能体用途对齐的三到四个评估器开始，随着理解加深再扩大覆盖。

理解评估器之间的区别

有些评估器自然会相互作用，因此分数应放在一起读，而不是孤立地看。听起来相似的评估器常常测量根本不同的东西，理解这些区别对诊断很重要。

• _正确性_ 检查响应在事实上是否准确，而 _忠实性_ 检查它是否与对话历史一致。例如，智能体可以忠实于有缺陷的源材料，但仍然是错的。
• _有帮助性_ 问响应是否推动用户走向其目标，而 _响应相关性_ 问它是否针对最初被问的内容。例如，智能体可以详尽地回答了错误的问题。
• _连贯性_ 检查推理中的内部矛盾，而 _上下文相关性_ 检查智能体是否拥有正确的可用信息。例如，一个揭示生成问题，另一个揭示检索问题。

有些评估器还彼此依赖或互相权衡。例如：

• 只有当智能体选择了正确工具时，_工具参数准确性_ 才有意义，因此应先处理较低的 _工具选择准确性_。
• _正确性_ 常常依赖 _上下文相关性_，因为没有正确信息，智能体无法生成准确答案。
• _简洁性_ 和 _有帮助性_ 常常冲突，因为简短响应可能省略用户需要的上下文。

内置评估器附带预定义的提示词模板、选定的评估器模型，以及标准化评分标准，配置固定以保持各次评估之间的一致性。它们使用跨区域推理，自动从你所在地理范围内的 AWS 区域选择计算，提高模型可用性和吞吐量，同时把数据保存在发起区域。自定义评估器在此基础上扩展，支持你自己的评估器模型、评估指令、标准和评分模式。它们对行业特定评估特别有价值，例如医疗或金融服务中的合规检查、品牌语气一致性核验，或执行组织质量标准。自定义代码评估器让你引入一个 AWS Lambda 函数来执行评估。这也允许你对智能体做确定性评分。

对于要求全部处理都在单个区域内的使用场景，自定义评估器也提供对推理配置的完全控制。构建自定义评估器时，你定义带占位符的指令，这些占位符在发送给裁判模型之前会被实际追踪信息替换。可用信息的范围取决于评估器的层级：会话级评估器可以访问完整对话上下文和可用工具，追踪级评估器看到先前轮次加上当前助手响应，工具级评估器聚焦于其周围上下文中的特定工具调用。AWS 控制台提供把任何现有内置评估器的提示词模板作为起点加载的选项，使创建自定义变体变得直接（_图 7_）。

图 7：创建自定义评估器时，AgentCore Evaluations 控制台提供把任何内置评估器的提示词模板作为起点加载的选项。

构建多个自定义评估器时，使用 互斥且完全穷尽（MECE） 原则来设计评估套件。每个评估器应有独特、不重叠的范围，同时合在一起覆盖你关心的全部质量维度。例如，不要创建两个都部分评估“响应质量”的评估器，而要把它们分成一个评估事实依据、另一个评估沟通清晰度。此外，在编写评估器指令时，把裁判模型的角色确立为性能评估者，以防止把评估和任务执行混淆。使用清晰、按顺序的指令和精确语言，并考虑包含一到三个相关示例，带有代表你预期标准的匹配输入／输出对。评分方面，在通过／失败场景选择二元量表（0/1），或在更细致的评估中选择有序量表（例如 1–5），不确定时先用二元评分。该服务把输出标准化为先有原因字段、后有分数字段，因此裁判模型总是先给出推理再赋一个数字。避免加入你自己的输出格式指令，因为它们可能使裁判模型混淆。

基于代码的自定义评估器

内置评估器和自定义评估器都使用 LLM-as-a-Judge。AgentCore Evaluations 还支持第三种方法：基于代码的评估器，其中一个 AWS Lambda 函数可以用你的自定义代码作为评估器。

当你有不需要语言理解就能核验的启发式评分方法时，基于代码的评估器很合适。LLM 评估器可以判断响应是否“听起来正确”，但不能可靠地确认某个具体的工资单数字 8,333.33 美元是否逐字出现在响应中，或生成的请求 ID 是否遵循 PTO-2026-NNN 格式。对这些确定性检查，自定义代码更快、更便宜、更可靠。有四种情况特别适合基于代码的评估器：

• 精确数据验证：智能体被期望从数据源返回特定值，例如账户余额、交易 ID 或价格。
• 格式合规：响应必须符合结构约束，例如长度限制、必需短语或输出模式。
• 业务规则执行：需要精确解释的策略，例如响应是否正确应用了分层折扣规则，或是否引用了正确的法规条款。
• 高产量生产监控：Lambda 调用成本只是 LLM 推理的一小部分，当每个生产会话都需要大规模持续评分时，基于代码的评估器是合适选择。

#### 创建基于代码的评估器

基于代码的评估器配置为一个带有你自定义逻辑的 AWS Lambda 函数。AgentCore 把智能体的 OTel 跨度作为结构化事件传给你的函数，并期望返回一个结果。你的函数从跨度中提取它需要的任何信息，并返回一个分数、一个标签和一段解释。

一旦 Lambda 已部署，并被授予允许 AgentCore 服务主体调用的权限，你就把它注册为 AgentCore 的评估器。注册之后，评估器 ID 可以用于按需评估。

设置 AgentCore Evaluations

配置该服务包括三步。选择你的智能体，选择你的评估器，并设置抽样规则。开始之前，使用 AgentCore Runtime 部署智能体，并通过 OpenTelemetry 或 OpenInference 插桩建立可观测性。GitHub 上的 AgentCore 示例仓库 提供可运行的示例。

配置在线评估

通过 AgentCore Evaluations 控制台创建新的在线评估配置。在这里，你指定要应用哪些评估器、要监控哪个数据源，以及使用什么抽样参数。对于数据源，选择一个现有的 AgentCore Runtime 端点，或为未托管在 AgentCore Runtime 上的智能体选择一个 CloudWatch 日志组。然后选择评估器并定义抽样规则。

图 8：用于创建在线评估配置的 AgentCore Evaluations 控制台，包括数据源选择、评估器分配和抽样规则。

你也可以使用 CreateOnlineEvaluationConfig API 以编程方式创建配置，需要唯一的配置名称、数据源、评估器列表（最多 10 个）和 IAM 服务角色。enableOnCreate 参数控制评估是立即开始还是保持暂停，executionStatus 决定配置在启用后是否主动处理追踪。当配置正在运行时，它引用的任何自定义评估器都会被锁定，不能修改或删除。如果需要更改评估器，请克隆它并创建新版本。在线评估结果以 JSON 格式保存到专用的 CloudWatch 日志组。

监控结果

启用配置后，通过 Amazon CloudWatch 中的 AgentCore Observability 仪表板监控结果。智能体级视图显示汇总的评估指标和趋势，你可以下钻到特定会话和追踪，查看单个分数以及每个分数背后的推理。

图 9：AgentCore Observability 仪表板在智能体级显示评估指标和趋势，并可下钻到单个会话、追踪、分数和裁判推理。

下钻到单条追踪会显示该次特定交互的评估分数和详细解释，使团队可以核验裁判推理，并理解智能体为何得到特定评级。

图 10：追踪级视图直接在单条追踪上显示评估分数和解释，展示裁判模型对每个指标的推理。

使用按需评估

对于开发和测试，你可以使用按需评估分析特定交互：选择你要检查的追踪或跨度，应用所选评估器，并收到带解释的详细分数。结果直接在 API 响应中返回，每次调用最多 10 次评估，每个结果包含跨度上下文、分数和推理。如果一次评估部分失败，响应会同时包含成功和失败结果，并带有错误代码和消息。按需评估适合测试自定义评估器、调查特定质量问题，以及在部署前验证修复。

用标准答案评估智能体

以大语言模型为裁判的评分告诉你，按通用语言模型的标准，响应是否看起来正确和有帮助。标准答案评估更进一步，让你指定答案、本应调用的工具，以及会话本应达成的结果。这帮助你测量智能体的实际行为与参考输入有多接近。这在开发期间特别有价值，因为你拥有关于正确行为是什么的领域知识，并想测试特定场景。

AgentCore Evaluations 支持三类标准答案参考输入，每一类由一组特定评估器使用：

这些输入是可选且相互独立的。不需要标准答案的评估器，例如 Builtin.Helpfulness 和 Builtin.ResponseRelevance，可以与标准答案评估器放在同一次调用中，每个评估器只读取它需要的字段。你可以同时提供全部三类参考输入以做全面评估，或只提供与给定场景相关的子集。

bedrock-agentcore Python SDK 为标准答案评估提供两个接口：用于评估已有会话的 EvaluationClient，以及用于自动化数据集评估的 OnDemandEvaluationRunner。

评估客户端：评估已有会话

当你已经在 CloudWatch 中记录了智能体会话，并想评估特定交互时，评估客户端是合适选择。你提供会话 ID、智能体 ID、所选评估器、用于 CloudWatch 跨度检索的回溯窗口，以及可选的参考输入。客户端获取该会话的跨度并提交评估。这很适合开发分析、调试特定智能体失败，以及在提示词或模型变更后验证已知交互。

评估客户端对多轮会话同样适用。当你传入多轮对话的会话 ID 时，客户端获取该会话的全部跨度并评估完整对话。轨迹评估器核验所有轮次上的工具使用，目标成功断言应用于会话，正确性评估器把每个单独响应对照其对应的预期答案评分。

按需评估数据集运行器：自动化数据集评估

当你想通过为每个场景调用智能体、采集 CloudWatch 跨度，并在单一自动化工作流中给结果评分，从而在整理好的数据集上系统评估智能体时，按需评估数据集运行器是合适选择。你定义一个包含多轮场景的数据集，带有每轮和每场景的标准答案，并提供一个运行器为每一轮调用的 agent_invoker 函数。运行器管理会话 ID，并处理调用、跨度采集和评估之间的全部协调。

按需评估数据集运行器很适合 CI/CD 流水线，其中同一数据集针对每次构建运行；也适合提示词或模型变更后的回归测试，以及发布前对大量测试用例的批量评估。

两个接口共享相同的评估器和参考输入模式，因此你可以先用评估客户端针对现有生产会话交互式地开发和验证标准答案测试用例，再把这些相同场景提升到评估运行器数据集中，做系统的回归测试。AgentCore 示例仓库 中的动手教程，使用一个示例智能体，在单轮和多轮场景中端到端演示两个接口，并覆盖全部三类标准答案参考输入。

最佳实践

智能体的成功标准通常结合三个维度：响应质量、用户收到响应的延迟，以及推理成本。AgentCore Evaluations 聚焦质量维度，而延迟和成本等运营指标可通过 CloudWatch 中的 AgentCore Observability 获得。以下最佳实践围绕前面描述的三项评估原则组织，并反映大规模做智能体评估时出现的模式。

证据驱动的开发

1. 用合成数据和真实数据为智能体性能建立基线，并严格实验。在每次改动前后测量，使改进基于证据而不是直觉。用你已有的测试用例尽早开始测试，并持续构建语料。_图 1_ 中描述的评估循环确保失败随时间变成新的测试用例。
2. 对每次改动都做有统计严谨性的 A/B 测试。无论你是更新系统提示词、更换模型还是添加工具，都在部署前后用同一组评估器比较性能。
3. 按类别组织重复试验（每个问题至少 10 次），以基准化可靠性并识别专业化机会。重复运行之间的方差揭示智能体在哪里一致、在哪里需要改进。

多维评估

4. 尽早定义成功是什么样，使用反映智能体实际用途的多维标准。考虑哪些评估层级最重要（会话、追踪或工具），并选择映射到业务目标的评估器。
5. 评估智能体工作流中的每一步，而不只是最终结果。独立测量工具选择、参数准确性和响应质量，给你在问题实际发生处修复它们的诊断精度。
6. 让主题专家参与设计指标、定义任务覆盖，并进行人在回路中的评审以保证质量。主题专家的输入使评估器基于真实世界的预期，并捕捉仅靠自动评分会错过的盲点。
7. 先用内置评估器建立基线测量，然后随着需求成熟创建自定义评估器。与主题专家校准自定义评估器评分，使自动判断与你领域中的人类预期对齐。

持续测量

8. 通过把生产行为与测试基线比较来检测漂移。在关键指标上设置 CloudWatch 告警，以便在回退到达广大用户之前捕捉它们。
9. 记住，测试数据集会随你的智能体、用户以及你遇到的对抗场景演变。随着生产中出现边界情况和要求变化，定期更新它。

排查常见评估模式

1. 前面描述的评估器关系帮助你诊断性地解释分数。以下模式针对你在扩展应用时可能遇到的特定场景，并给出解决步骤。
2. 如果你注意到所有评估器分数都低，问题通常是基础性的。先查看上下文相关性分数，以确定智能体是否能访问它需要的信息。检查智能体的系统提示词是否清晰和完整；含糊或矛盾的指令会影响每一个下游行为。核验工具描述是否准确说明何时以及如何使用每个工具。
3. 如果你注意到相似交互的分数不一致，这通常指向评估配置问题，而不是智能体问题。如果你在使用自定义评估器，检查指令是否足够具体，以及每个分数等级是否有清晰、可区分的定义。考虑降低自定义评估器模型配置中的温度参数，以产生更确定的评分。
4. 如果你看到工具选择准确性高但目标成功率低，说明智能体选择了合适的工具，但未能完成用户目标。这种模式表明，你可能需要额外工具来处理某些用户请求，或者智能体难以处理需要多次顺序工具调用的任务。同时检查有帮助性分数；智能体可能正确使用了工具，但解释结果很差。
5. 如果评估缓慢或因限流而失败，降低抽样率，以评估更小比例的会话。减少评估器数量。对自定义评估器，为所选模型申请配额提升，或切换到默认配额更高的模型。

结论

在本文中，我们展示了 Amazon Bedrock AgentCore Evaluations 如何帮助团队从被动调试转向对 AI 智能体的系统质量管理。作为全托管服务，它负责评估模型、推理基础设施和数据流水线，否则团队需要为每个智能体构建和维护这些内容。按需评估锚定开发工作流，在线评估提供持续的生产洞察，质量在整个智能体生命周期中成为可测量、可改进的属性。评估器关系和诊断模式提供的框架，不只是给智能体打分，而是用于理解质量问题发生在哪里、为什么发生，以及改进努力应聚焦何处。

要详细探索 AgentCore Evaluations，请观看 AWS re:Invent 2025 的公开预览发布会议，其中有带现场演示的演练。访问 GitHub 上的 Amazon Bedrock AgentCore 示例仓库 获取动手教程。关于配置和 API 用法的技术细节，见 AgentCore Evaluations 文档。你也可以查看 服务限制 和 定价。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/build-reliable-ai-agents-with-amazon-bedrock-agentcore-evaluations