Bedrock AgentCore多代理系统可解释性与有用性评估指南

当多智能体系统从实验阶段迈向生产环境时，一个关键挑战随之浮现：如何确保这些系统在真实场景中始终保持有用、准确和可解释。企业在越来越多地采用多智能体系统来解决复杂的现实问题——这些问题需要跨数据源、跨工具、跨业务约束进行推理。从供应链规划到财务分析再到客服运营，这些系统远超简单的问答范畴。它们协调多个专业化智能体来做出决策、执行工作流并生成可操作的建议。

尽管大语言模型能够生成流畅的回复，但企业应用需要更深入的保障——智能体必须可靠地遵循指令、选择正确的工具、尊重约束条件，并为其输出提供清晰的推理依据。

Amazon Bedrock AgentCore 是一个用于大规模构建、连接和优化智能体的平台，支持任何框架或模型。Amazon Bedrock AgentCore Evaluations 是 Amazon Bedrock AgentCore 的一项功能，旨在作为一项全托管能力来解决这一挑战，用于评估智能体在开发和生产环境中的表现，使团队能够从多个质量维度衡量准确性、任务成功率和行为。传统的评估方法仅关注模型回复质量，对于智能体系统而言是不够的——因为正确性取决于工具选择、工作流执行以及对业务约束的遵守。除了评估之外，智能体系统的生产部署还需要负责任 AI 的控制措施。Amazon Bedrock Guardrails 提供了可配置的安全防护措施，包括内容过滤、禁止话题检测和基础验证，这些与评估框架相辅相成。评估在执行后评估智能体质量，而护栏在执行过程中强制执行安全约束。在这篇文章中，我们重点介绍如何将这一评估框架付诸实践，包括 Amazon Bedrock AgentCore Evaluations 对内置评估器和自定义评估器的支持。内置评估器为常见质量维度提供预定义的评估，例如有用性、任务成功率和指令遵循，使团队能够快速建立智能体性能基线，无需额外设置。然而，企业用例需要更深入的领域特定验证。自定义评估器解决了这一问题，允许你定义业务感知检查。

我们还特别关注将可解释性作为一等评估维度加以探讨。本文演示了内置评估器如何评估通用回复的清晰度，并展示如何使用自定义评估器来验证智能体是否明确阐述决策理由、引用支撑数据或工具输出，以及解释成本与服务水平之间的权衡等。通过组合这些评估器，我们展示了 AgentCore Evaluations 如何超越表面层面的回复质量，提供关于智能体如何以及为何得出决策的结构化、可衡量的洞察。

为了让这些概念具体化，以下章节将逐步介绍参考架构和实现，展示这些组件如何在实践中协同工作。

在本文中，我们使用了一家名为 AnyCompany Retail 的虚构全球零售公司作为案例这是一家在电子商务渠道、区域配送中心、配送中心和数千家实体门店开展业务的多国零售商。AnyCompany 经常面临库存不平衡问题：某些地区在促销期间面临缺货，而另一些地区则库存过剩。运输团队还必须在配送速度、承运商运力和成本之间取得平衡。该公司希望构建一个智能体助手，帮助规划人员优化库存分配、推荐配送调整、分析库存健康状况，以及模拟路线或履约场景。

你将使用 Strands Agents SDK、Amazon Bedrock AgentCore MCP Server 和 Amazon Bedrock AgentCore Evaluations 来构建和评估一个多智能体供应链决策系统。该解决方案使用 Strands Agents，包含一个编排智能体和四个专业子智能体：优化智能体、配送智能体、路线智能体和分析智能体。每个智能体都在启用 Amazon Bedrock AgentCore memory 和 Amazon Bedrock AgentCore Observability 的 Amazon Bedrock AgentCore 运行时上运行。

编排智能体接收规划人员的请求，并将工作委托给作为工具暴露的专业智能体。优化智能体调用 MCP 工具，这些工具由返回优化决策的模拟 Amazon API Gateway REST 接口提供支持。配送智能体调用推荐 API 来建议跨配送中心、门店和数字渠道的库存再平衡。路线智能体调用物流 API 来推荐承运商和路线选项，分析智能体回答供应链诊断问题。该解决方案使用 Amazon Bedrock 上的基础模型来运行智能体循环。关于模型在各区域的可用性，请参阅 Amazon Bedrock 中的按 AWS 区域划分的支持模型。

该解决方案使用内置评估器来评估通用质量维度，如有帮助性和任务完成度。它还提供自定义评估器来评估供应链特定行为，如约束满足、路线可行性、SQL 正确性、库存基础验证和解释质量。AnyCompany 可以同时评估回复的语言质量和智能体决策的业务有效性。

该解决方案支持 Amazon Bedrock AgentCore Evaluations 的按需模式和在线模式。按需模式适用于开发基准测试、回归测试和持续集成持续交付（CI/CD）门禁。在线模式用于持续生产监控和告警。两种模式都能帮助你闭环并根据用户反馈采取行动。用于按需评估的相同自定义评估器（如供应链解决方案中的约束满足、路线可行性、SQL 正确性和可解释性评估器）可以与 OnlineEvaluationConfig 对象配合重用，该对象引用评估器的 Amazon Resource Names（ARN），并指定采样率（例如，1%–10% 的生产追踪），以及可选的会话过滤器。该服务随后自动从 AgentCore Observability 读取追踪、评分并将结果流式传输到 Amazon CloudWatch 仪表板和告警。在本文中，你将使用按需模式来测试解决方案。

以下架构图说明了我们解决方案的各个组件。

图 1：多智能体供应链决策解决方案的架构

在本文中，你将使用三层评估方法来评估多智能体系统，逐步建立企业信任。该方法遵循清晰的递进路径：从用于通用质量的内置评估器开始，然后添加用于业务准确性的自定义评估器，最后叠加用于信任和可审计性的可解释性评估器。

第一层使用无需设置的内置评估器。我们应用有用性作为通用基线，外加第二个针对每个智能体主要故障模式的智能体专用评估器：编排器的工具选择准确性、优化器和配送器的回复相关性、路线的指令遵循、analytics 的忠实度。

第二层添加编码领域特定业务规则的自定义评估器：优化的约束满足、配送的数据基础验证、路线的路线可行性、分析的 SQL 正确性，以及编排的计划一致性。这些验证业务有效性：建议是否尊重了预算限制、使用了真实库存数据，并产生了可操作的正确输出？

下表映射了你将在此实现中为每个智能体选择的两个内置评估器和自定义评估器。第二个内置评估器针对每个智能体的主要故障模式，而自定义评估器编码验证操作正确性的领域特定业务规则。

我们评估方法的第三层将可解释性评估器作为跨智能体的独立横向检查应用。这些评估器独立评估智能体是否阐述决策理由、引用工具输出的支撑证据、解释哪些约束条件塑造了回复、阐明竞争目标之间的权衡、澄清为何调用特定的子智能体，以及在数据不完整时披露假设。通过将可解释性分离为自己的评估层，我们可以独立衡量透明度。一个建议可能是准确的但无法解释的（通过自定义评估器但未通过可解释性），这为团队提供了可操作的信号，说明智能体是需要更好的推理阐述还是更好的决策逻辑。

下面的表格定义了本文实现的六个独立可解释性评估器，它们作为跨切层应用于各个 Agent。这些评估器用于判断 Agent 是否阐明了推理过程、引用了证据、解释了约束条件和权衡方案，以及披露了假设。它们与准确性分开衡量，以便团队能够区分「无法解释但正确」与「解释充分但错误」的响应。

在部署此解决方案之前，请使用以下工具设置开发环境。

安装 AWS Command Line Interface (AWS CLI)

安装 AWS Serverless Application Model (AWS SAM) CLI v1.100.0+

安装 Docker v20.x+

安装 Node.js v18.x+

安装 Python v3.11+

Strands Agents 的实现还需要以下依赖，这些依赖被打包在 Dockerfile 中：

strands-agents # Strands Agents 多 Agent 框架

strands-agents-tools # Strands Agent 工具和实用程序

requests # 用于 API 调用的 HTTP 库

bedrock-agentcore # Amazon Bedrock Agent Core 功能

boto3 # AWS SDK for Python (Boto3)

部署并运行解决方案

该解决方案可从我们的 GitHub 仓库下载，提供单步部署以在您的 AWS 环境中部署和访问该解决方案：

# Edit terraform.tfvars: set vpc_id and runtime_subnet_azs
cd terraform
cp terraform.tfvars.example terraform.tfvars
terraform init
terraform apply

输出内容包括运行时 ARN、AnyCompany Retail API URL、评估器 API URL 和 memory ARN。

请按照以下步骤运行解决方案：

test_client/ 文件夹包含一个 Python 脚本，用于调用已部署的 Supply Chain Agent，包含 20 个示例查询（每个子 Agent 5 个）以验证端到端功能。每个类别作为多轮对话会话运行，会话 ID 在最后打印，用于评估器 API。

cd test_client
pip install -r requirements.txt
cd terraform
terraform output supply_chain_arn

运行所有查询（共 20 个，4 个会话）

cd test_client
python test_agent.py --runtime-arn "<supply_chain_arn>" --region <your_region>

运行特定子 Agent 类别

#Only optimization queries (1 session, 5 turns)
python test_agent.py --runtime-arn "<supply_chain_arn>" --category optimization
#Only routing and analytics (2 sessions, 5 turns each)
python test_agent.py --runtime-arn "<supply_chain_arn>" --category routing analytics

测试客户端打印每个查询和完整的 Agent 响应。最后打印会话 ID，用于评估器。

创建并运行评估

test_evaluators/ 文件夹包含用于对 Agent 会话运行评估的脚本。这些评估异步运行，结果以 markdown 文件形式保存到 S3。

您必须首先按前所述调用 Supply Chain 决策多 Agent 解决方案，以生成带有追踪记录的 Agent 会话，并记下测试客户端运行结束时打印的会话 ID。最后，在运行解决方案后等待 3-5 分钟，让追踪记录传播到 CloudWatch。

cd test_evaluators
pip install -r requirements.txt
cd terraform
terraform output evaluators_api_url

创建自定义评估器

python test_evaluator.py --api-url "https://<evaluators-api-url>" create

这将注册自定义评估器并打印其 ID。保存这些 ID 以便与 run 命令配合使用。

传入逗号分隔的评估器 ID 列表（自定义或内置）。至少需要 1 个：

# Run custom + built-in evaluators
python test_evaluator.py --api-url "https://<evaluators-api-url>" run \
--agent-id "supply_chain_orchestrator_agent-<id>" \
--session-id "<session-id-from-test-client>" \
--evaluators " sc_optimization_constraint-<id>,sc_distribution_groundedness-<id>,Builtin.Correctness,Builtin.GoalSuccessRate"

API 立即返回 202。结果异步保存到 S3，路径为：

s3://<amzn-s3-demo-agent-source-bucket>/evaluations/<session-id>/<timestamp>/EvaluationResults.md

python test_evaluator.py --api-url "https://<evaluators-api-url>" delete \
--evaluator-ids "sc_optimization_constraint-<id>,sc_distribution_groundedness-<id>"

运行优化评估

现在您已经了解了评估框架并已部署解决方案，让我们走一遍针对优化 Agent 的重点端到端评估。此演示展示了如何将自定义业务准确性评估器（第 2 层）与可解释性评估器（第 3 层）相结合，以评估优化决策的正确性和透明度。

第 1 步：运行优化查询

首先，仅使用优化类别调用测试客户端以生成重点会话：

cd test_client
python test_agent.py --runtime-arn "<supply_chain_arn>" \
--category optimization \
--region <your_region>

这将运行 5 个优化查询作为多轮对话会话。Agent 处理诸如「未来 30 天 prod-001 的最佳库存水平是多少？」之类的请求。每个查询都需要优化 Agent 调用 MCP 工具、检索需求预测，并生成遵守预算、库存覆盖率和仓库容量约束的补货建议。运行结束时，测试客户端打印优化会话 ID。

第 2 步：运行约束满足评估器（第 2 层：业务准确性）

生成优化会话后，运行自定义约束满足评估器，以验证 Agent 的补货建议是否遵守业务规则。此评估器同时检查三个约束条件：

预算：增量持有成本是否在剩余预算范围内（budget_limit − budget_used）？

库存覆盖率：建议水平是否 ≥ 需求预测（避免缺货）且 ≤ 2× 需求（避免过剩）？

仓库容量：建议水平是否在可用仓库空间内？

运行评估器以及内置的 Helpfulness 和 Response Relevance 评估器：

cd test_evaluators
python test_evaluator.py --api-url "https://<evaluators-api-url>" run \
--agent-id "supply_chain_orchestrator_agent-<id>" \
--session-id "<optimization-session-id>" \
--evaluators "sc_optimization_constraint-<id>,Builtin.Helpfulness,Builtin.ResponseRelevance"

API 立即返回 HTTP 202。评估异步运行。结果保存到 S3：

s3://<amzn-s3-demo-agent-source-bucket>/evaluations/<optimization-session-id>/<timestamp>/EvaluationResults.md

第 3 步：运行可解释性评估器（第 3 层：信任和可审计性）

在确认优化 Agent 生成了满足约束的建议后，下一个问题是：它是否解释了推理过程？建议可能准确但不透明。这样的建议通过约束评估器，但未能阐明为什么选择特定的库存水平。

使用第 1 步中的相同优化会话 ID，现在运行适用于优化 Agent 的两个可解释性评估器：

决策理由质量 — Agent 是否解释了为什么做出该建议？（例如，「建议 1,500 单位，因为需求预测为 1,200，我们的目标安全系数为 1.25 倍」）

约束推理 — Agent 是否解释了哪些约束条件影响了最终响应？（例如，「预算允许最多 1,800 单位，但仓库容量限制我们只能到 1,600，因此我们建议 1,500」）

python test_evaluator.py --api-url "https://<evaluators-api-url>" run \
--agent-id "supply_chain_orchestrator_agent-<id>" \
--session-id "<optimization-session-id>" \
--evaluators "sc_decision_rationale-<id>,sc_constraint_reasoning-<id>"

这些评估器独立评估透明度。它们与准确性分开衡量。

解读组合结果

通过对同一优化会话运行所有三个评估器，您可以在两个维度上获得 Agent 质量的完整图景：

表 3：跨质量维度的评估覆盖范围

这种分层方法能够实现有针对性的改进。如果约束满足分数高但可解释性分数低，则 Agent 的决策逻辑是正确的，但沟通需要改进。相反，如果可解释性高但违反了约束条件，则 Agent 的推理阐述得很好，但应用了错误的逻辑。每种失败模式都有不同的修复路径，评估框架使这种区分变得可衡量。

为避免持续产生费用，在试用完解决方案后，在您的 AWS 账户中进行单步清理。

terraform destroy

在这篇文章中，我们演示了如何使用 Amazon Bedrock AgentCore Evaluations 构建并评估一个多智能体供应链决策系统，重点验证智能体行为不仅具备功能性，同时要有帮助性、准确性和可解释性。通过 AnyCompany Retail Group 场景，我们展示了编排智能体与专业子智能体如何协作解决复杂问题，如库存分配、配送规划、路径优化和供应链诊断，同时与企业数据源和 API 进行集成。如架构图所示，智能体系统中的正确性远超响应质量本身，它取决于选择正确的工具、执行正确的工作流、遵守业务约束，以及将输出锚定在数据之上。

通过将内置评估器与自定义评估器相结合，团队可以系统性地验证通用响应质量和领域特定的决策准确性。引入以可解释性为重点的评估器，还能进一步确保智能体清晰表达其推理过程、引用支持数据，并以业务用户能够信任和采取行动的方式解释权衡取舍。这种评估驱动的方法使团队能够使用真实执行数据进行持续改进，在生产部署前建立质量门控，并提供一个可扩展的框架，用于交付一致的、透明的和业务对齐的多智能体系统。

要开始使用，请探索 Amazon Bedrock AgentCore Evaluations，并将这些模式应用到您自己的多智能体应用程序中。在 GitHub 上的 Amazon Bedrock AgentCore samples 仓库中找到完整的源代码。首先从启用可观测性开始，为您的用例定义关键评估维度，并逐步引入内置和自定义评估器来衡量最重要的事项。

了解更多内容，请访问 Amazon Bedrock AgentCore 服务页面，或直接在 Amazon Bedrock 控制台中开始使用。

使用 Amazon Bedrock AgentCore Evaluations 构建可靠的 AI 智能体

使用 Amazon Bedrock AgentCore 在 AWS 上构建高度可扩展的无服务器 LangGraph 多智能体系统

评估 AI 智能体：亚马逊构建智能体系统的真实经验总结