Monitoring production agent lifecycle with AWS DevOps Agent and AgentCore Evaluations

使用 AWS DevOps Agent 和 AgentCore Evaluations 监控生产代理生命周期 | 人工智能

使用 AWS DevOps Agent 和 AgentCore Evaluations 监控生产代理生命周期

生产环境中的多代理系统会以传统监控无法发现的方式出现各种问题。例如，代理无法调用其基础模型（FM）并返回空响应。这可能是因为代理执行角色缺少 AWS 身份和访问管理（IAM）权限，但不会引发 500 错误。如果监督代理的提示范围设置不当，错误率不会上升，但会将 20% 的请求路由到非预期的专家代理，而基础设施指标仍显示正常。

基础设施监控和代理有效性监控需要不同的方法。Amazon CloudWatch 指标可以显示系统是否正确执行，但无法说明代理是否帮助用户完成目标。代理可能成功调用 Amazon Bedrock，无错误地调用所有工具并返回响应，但完全误解用户需求。基础设施问题通常表现为代理行为减少，而非明显错误。当权限被撤销或服务限流时，代理可能遇到静默问题。例如，预订代理停止完成预订，但日志显示工具执行成功，因为问题出现在调用链中较深的位置，未触发异常。

在多代理系统中，这些问题会叠加，单个用户请求会触发监督代理，将其工作路由到多个专家代理，每个专家代理都有自己的工具和模型调用。通常没有固定的执行图可供监控，故障可能发生在多个交接点，且其在系统中的传播路径并不总是可预测。

我们构建了一个生产环境中的航空公司预订系统，该系统包含四个专用代理，结合使用 Amazon Bedrock AgentCore Evaluations 进行持续代理质量评估，以及 AWS DevOps Agent 实现基础设施事件的自主调查。Amazon Bedrock AgentCore 是一个平台，可用于大规模构建、连接和优化代理，支持任何框架或模型。AgentCore Evaluations 解决了质量监控的空白，通过持续评分实时交互，发现基础设施指标完全无法检测到的错误工具选择、任务失败和质量退化问题。AWS DevOps Agent 解决了第二个问题，能够自主追踪跨服务边界的服务故障，关联 IAM 策略、调用日志和编排追踪，无需人工调查。这两个层次共同表明代理是否正常工作，以及基础设施是否支持其运行。

关键技术

该系统使用了多个 AWS 服务：

• Amazon Bedrock 提供对来自 Anthropic、Meta、Mistral 和 Amazon 等领先 AI 公司的基础模型的 API 访问。在基于 AgentCore 运行时构建的航空公司预订系统中，Amazon Bedrock 负责语言理解。有关 AWS 区域支持的模型信息，请参阅 Amazon Bedrock 中的 按 AWS 区域划分的支持模型。

• AgentCore 运行时负责代理编排和管理交互生命周期，内置 OpenTelemetry 指标实现可观测性。

• 通过 Fullstack AgentCore Solution Template (FAST)，团队可以快速部署一个与 AgentCore 后端连接的安全 React 前端。

• AgentCore 评估是集成在 AgentCore 运行时中的质量评估框架。它通过 LLM 作为裁判的方法论持续对智能体交互进行评分，提供包括帮助性、正确性、目标完成度等质量维度的指标。

• AWS DevOps Agent 是一种自主调查工具，可作为您的基础设施的值班工程师。当发生故障时，它会自动分析 Amazon CloudWatch 日志，跨服务边界追踪故障，并提供带有修复建议的根本原因分析。

• Strands Agents 是一个开源 SDK，采用模型驱动方法构建 AI 智能体，支持包括蜂群（Swarm）、图（Graph）和工具作为智能体（Agents-as-Tools）在内的多智能体协作模式。

• OpenTelemetry 是一个开源可观测性框架，提供标准化的仪器化工具用于收集追踪、指标和日志。AgentCore 运行时使用 OpenTelemetry 将监控数据发送到 Amazon CloudWatch，实现系统范围内的一致可观测性。

• 蜂群模式（Swarm Pattern）是一种多智能体编排方法，监督智能体根据任务需求动态将工作路由到专用智能体。与固定工作流不同，蜂群支持基于运行时决策的自适应执行路径，这使其在处理复杂任务时非常强大，但监控起来具有挑战性。

双层监控：质量与基础设施

监控架构回答两个问题：智能体运行良好吗？基础设施健康吗？

Amazon Bedrock AgentCore 评估：持续质量监控

AgentCore 评估对智能体交互的实用性、正确性和目标完成度进行实时评分。系统会按可配置比例抽样生产请求并在后台进行评估。每个评分都附带解释，说明该评分基于对话上下文、使用的工具和任务需求的依据。

当质量指标下降时，系统会分析近期低分会话的模式，识别常见故障模式。如果智能体对特定请求类型持续选择错误工具，或以不具帮助性的方式提供正确信息，模式分析将揭示这些问题。随后生成具体建议：特定提示词修改、工具选择调整或编排逻辑优化。

AWS DevOps Agent：自主基础设施调查

AWS DevOps Agent 跨指标、日志和错误模式监控系统健康状况。当发生故障时，智能体会自主进行调查。它会提取相关 Amazon CloudWatch 日志，构建受影响资源的拓扑图，跨服务（IAM、Amazon Bedrock、您的智能体运行时）关联错误，追踪故障路径，并提供具体修复建议。除了发送包含 Amazon CloudWatch 链接的警报外，它还会通过将空白智能体响应连接到缺失的 IAM 权限，或将超时激增与特定区域的 Amazon Bedrock 限流关联，完成调查。

各层如何协同工作

AgentCore 评估体系用量化质量指标取代直觉判断，使团队能够衡量变更的实际影响。AWS DevOps Agent 通过自主调查基础设施事件（在事件发生时立即进行），自动化了以往需要人工协作分析的大量工作。两者结合创建了持续反馈循环，实现监控、分析、改进、部署的闭环，满足生产环境多代理系统的需求。

航空预订系统：为何难以监控

为了完整演示这套架构，我们构建了一个处理复杂动态查询的航空预订系统：在单次对话中完成多城市预订、忠诚度计划权益应用、公司差旅政策合规性检查。这种用例正好体现了让生产环境监控变得困难的多代理协调特性：并行操作、多数据源、顺序依赖以及错误会产生实际后果的严格正确性要求。

考虑这样一个请求："请帮我预订3月15日从西雅图到波士顿的航班，然后3月18日从波士顿到迈阿密。第二段航程使用我的同伴证书，并确保两段航班都符合公司差旅政策。我是金卡会员，请应用所有符合条件的升舱权益。"

在单次对话中处理这个请求需要同时搜索两条独立航线，同时从不同数据源获取忠诚度状态和证书信息。预订必须按正确顺序执行，因为同伴证书只有在选定航班并知晓舱位等级后才能应用。将证书错误地应用于不符合条件的航班会令用户沮丧，预订违反公司政策的航班会造成金钱浪费。

我们使用Swarm模式（图1）构建了四个专用代理。监督代理接收请求并作为入口点，使用思考工具规划子任务，将工作路由给其他代理，这些代理可以相互交接任务。航班代理负责搜索航线并处理多城市连接。用户代理获取忠诚度状态、证书和用户资料数据。预订代理创建、修改和取消预订，在提交更改前进行验证。

在Swarm架构中，代理共享工作内存并动态交接任务。每个专家代理根据发现的信息决定下一步由谁执行，而非遵循预定的执行计划。监督代理只是入口点。当请求开始处理后，控制权会传递给最适合处理下一步的对等代理，而非通过中央路由器返回。如果航班搜索未找到直达航线，航班代理会自行执行连接搜索，找到可预订选项后将任务交接给预订代理。如果用户的证书不适用，用户代理会调整并继续传递任务。这种架构能处理结构不可预测的请求，但这也意味着没有固定的调用图可供监控。

故障可能发生在任何交接点，由于执行路径会根据运行时决策发生变化，因此每次故障路径也会不同。从外部来看，质量故障和基础设施故障可能几乎完全相同，但它们需要截然不同的应对方式。从外部观察，质量故障和基础设施故障的表现形式相同。AgentCore 评估能够捕捉第一种类型：所有操作均正常执行但代理仍导致用户失败。AWS DevOps Agent 负责处理第二种类型：基础设施在静默中发生故障，并表现为性能退化。

图1：Swarm 多代理模式

双重监控架构

下图展示了这些组件如何连接。

图2：完整系统架构，包含 React 前端、AgentCore 运行时、Amazon CloudWatch 和 AWS DevOps Agent

我们构建了一个托管在 AWS Amplify 上的 React 前端，通过 Amazon Bedrock AgentCore Identity（Amazon Bedrock AgentCore 的一项功能）连接到 Amazon Bedrock AgentCore 运行时，由四个代理组成的蜂群处理用户请求。AWS Amplify 托管对话界面，Amazon Simple Storage Service（Amazon S3）处理会话存储，Amazon Bedrock AgentCore Identity 管理前端与运行时之间的身份验证。

监控数据来源于单一源头：托管四个代理蜂群的 Amazon Bedrock AgentCore 运行时。Amazon Bedrock AgentCore Observability（Amazon Bedrock AgentCore 的一项功能）直接对运行时进行监控，以 OpenTelemetry 格式捕获追踪数据和指标并转发至 Amazon CloudWatch。Amazon Bedrock AgentCore Evaluations 则从这些运行时追踪数据中提取信息，对实时交互进行评分，评估结果同样流入 Amazon CloudWatch。这意味着操作指标、分布式追踪和质量评分都会集中到同一位置。

第二层监控系统连接到相同的后端。当发生事件时，团队成员可通过签名的 Webhook 将事件提交给 AWS DevOps Agent。该代理会提取 Amazon CloudWatch 日志和指标，自主进行分析，并在无需用户在不同工具间切换的情况下返回分析结果和修复建议。

入门指南

开源实现：我们基于 FAST 构建了该系统，该系统的完整源代码（包括 CDK 基础设施、评估仪表板和 AWS DevOps Agent 集成）可在 GitHub 仓库中获取。我们参考了 fullstack-solution-template-for-agentcore（FAST）中的 AgentCore 评估指南。

要使用 Amazon Bedrock AgentCore 评估功能，您需要：

• AgentCore CLI（https://github.com/aws/agentcore-cli）
• 具备 bedrock-agentcore 和 Amazon CloudWatch 权限的 AWS 凭证
• bedrock-agentcore Python SDK（Boto3 客户端）

第一层：Amazon Bedrock AgentCore 评估，代理是否正常运行？

生产环境代理中的静默质量问题会影响团队效率、用户信任和业务成果。AgentCore 评估通过持续将实时交互与结构化质量维度进行评分，能够在故障刚发生时立即捕捉这些失败。

视频1：提取会话、追踪和跨度的评估指标；在仪表板上查看指标以了解代理性能；通过探索会话追踪和跨度执行按需评估；运行 AI 引擎识别低评分会话中的模式；上传提示以获取 AI 生成的改进建议

Amazon Bedrock AgentCore 提供了 16 个内置评估器，按其评估内容和运行时机进行分类。其中包含 13 个 LLM-as-a-Judge 评估器，用于对交互进行评分并提供详细解释，使团队能够验证判断并明确了解交互为何获得特定评分；另外还有 3 个确定性轨迹匹配器。

评估器

| 定义 | 评估级别 | |------|----------| | 目标成功率 | 通过端到端分析整个对话，评估 AI 助手是否在对话会话中成功完成用户目标。 | 会话 | | 连贯性 | 评估响应的逻辑一致性和连贯性，检查是否存在自相矛盾、逻辑漏洞或推理缺陷，但不评估事实准确性。 | 轨迹 | | 简洁性 | 测量助手沟通效率，评估响应是否以最少的词句提供必要信息，避免冗余解释。 | 轨迹 | | 正确性 | 评估响应对给定任务的事实准确性，关注内容和解决方案是否准确，与风格或呈现方式无关。 | 轨迹 | | 忠实性 | 评估响应是否与对话历史保持一致，识别当前响应与同一对话中先前交互之间的冲突。 | 轨迹 | | 有害性 | 检测响应中的潜在有害内容，包括侮辱、仇恨言论、暴力、不当性内容和刻板印象。 | 轨迹 | | 有用性 | 从用户视角评估响应是否有效帮助用户推进目标，判断响应是否使用户更接近目标。 | 轨迹 | | 指令遵循 | 评估响应是否遵循用户输入中的明确指令，关注是否遵守特定指示，与整体响应质量无关。 | 轨迹 | | 拒绝 | 检测助手是否拒绝处理或满足用户请求，识别直接拒绝或间接回避请求任务的行为。 | 轨迹 | | 响应相关性 | 评估响应是否有效解决特定问题或请求，衡量响应对给定输入的聚焦度和相关性。 | 轨迹 | | 刻板印象 | 检测响应中的偏见和刻板印象内容，识别对特定人群的歧视性假设或泛化。 | 轨迹 | | 工具参数准确性 | 评估助手在调用工具时是否正确使用上下文信息，验证工具参数是否准确源自对话上下文。 | 工具 | | 工具选择准确性 | 评估助手是否为特定情境选择合适的工具，判断所选操作是否在对话特定时刻合理且最优。 | 工具 | | 轨迹任意顺序匹配 | 验证预期工具是否存在于实际轨迹中，不考虑顺序。 | 轨迹 | | 轨迹精确顺序匹配 | 验证实际工具是否与预期工具完全按顺序匹配，不允许多余工具。 | 轨迹 | | 轨迹顺序匹配 | 验证预期工具是否按顺序出现在实际轨迹中，允许在轨迹中插入额外工具。 | 轨迹 |

表1：AgentCore 评估支持的内置评估器指标

#### 在线评估：持续生产监控

在线评估通过持续采样可配置比例（0.01–100%）的跟踪记录，并异步地根据您选择的评估器对样本进行评分，从而实时监控代理与用户的实时交互。这种异步、事件驱动的设计使评估能够与生产流量并行运行，而不会增加面向用户的响应延迟。

Amazon Bedrock AgentCore 通过 OpenTelemetry 将评估指标实时发送至 Amazon CloudWatch。如果您已经在收集用于可观测性的跟踪记录，那么在线评估可以在不进行代码修改或重新部署的情况下，将质量评分与现有运营指标一同展示。您可以设置 Amazon CloudWatch 警报，当质量指标低于预设阈值时立即触发，从而在影响大量用户之前捕获潜在的质量问题。

在我们的航空公司预订系统在线评估中，我们选择了三个 Amazon Bedrock AgentCore 内置评估器，它们从整体上覆盖了代理质量的关键维度：Helpfulness（帮助性）、Correctness（正确性）和 Goal Success Rate（目标成功率）。我们选择这些指标是因为它们代表了对终端用户最重要的三个代理性能维度。这三个指标共同构成了一个平衡的评估体系，既反映了单次响应的质量，也体现了整体交互的有效性。这为团队提供了关于代理优势领域和需要改进方向的可操作洞察。

| 指标 | 重要性 | 示例场景 | |------|--------|----------| | Helpfulness（帮助性） | 超越正确性的用户满意度衡量。识别技术上准确但无用的响应。优化用户体验而不仅是准确性。检测代理提供过多或过少信息的情况。 | ✅ 高帮助性：代理提供清晰、可操作且有上下文的答案。<br>❌ 低帮助性：代理对简单问题给出过于技术化的正确回答。 | | Correctness（正确性） | 保障可靠性和可信度。捕捉幻觉和事实错误。对需要准确性的领域（金融、医疗、法律）至关重要。建立用户对代理的信任。 | ✅ 高正确性：代理提供准确数据和有效推理。<br>❌ 低正确性：代理编造事实或提供错误计算。 | | Goal Success Rate（目标成功率） | 衡量实际业务价值。捕捉多轮对话的有效性。识别代理卡顿或无法完成任务的情况。与用户意图和业务目标保持一致。 | ✅ 高目标成功率：用户想预订航班，代理完成预订。<br>❌ 低目标成功率：用户想预订航班，但代理仅提供航班选项。 |

设置在线评估配置的工作流程：

在线评估在生产环境中后台运行，不会中断现有流程，自动按配置比例采样会话，并将结果写入 Amazon CloudWatch Logs，且不影响生产延迟。

设置在线评估配置的工作流程图

为什么不多使用指标？

• 避免指标过载：过多指标会让人难以识别关键问题。
• 降低评估成本：每个评估器都会增加调用延迟和成本。
• 聚焦可操作洞察：这三个指标覆盖了用户最关心的维度。
• 支持快速迭代：团队可以快速理解并基于这些指标采取行动。
• 其他评估器（Faithfulness、Instruction Following、Tool Use Quality）可供使用但默认未启用：团队可根据具体需求添加这些评估器。

评估仪表板显示代理质量评分摘要

图3：评估仪表板展示各会话的平均评分，并按评分范围（0.0–1.0）进行分布分析

评估仪表板将原始的Amazon CloudWatch日志和OpenTelemetry追踪数据转化为可视化的代理实际运行表现视图（图3）。无需在多个日志组中筛选数千条JSON日志条目来拼凑单个会话的完整情况，仪表板通过可视化界面直接呈现会话时间线、追踪层次结构和评估评分。您可以按日期范围过滤会话，并深入单个追踪查看代理具体耗时位置或遇到的错误。您还可以针对特定会话运行按需评估，使用内置或自定义评估器进行分析。

#### 负责任的AI防护机制

Correctness和Faithfulness等评估器可以在事后捕获幻觉或不准确的输出，但由于在线评估是基于会话样本异步运行的，有问题的响应仍可能在评分前到达用户。对于生产环境的代理系统，Amazon Bedrock Guardrails提供了互补的内联防护层，该机制在每次响应返回前都会执行。核心功能包括：内容过滤以阻止有害或不适当的内容、拒绝主题检测以防止代理回应超出范围的查询（例如在航空场景中提供医疗或法律建议）、基于检索源材料的上下文相关性检查以标记未基于源数据的响应，以及敏感信息脱敏以隐藏工具输出中可能出现的PII（如信用卡号或护照信息）。

对于航空预订代理这样的系统，这些控制措施解决了异步评估无法应对的实时风险：模型生成看似合理但未被任何工具返回的航班价格、代理提供其无权承诺的退款政策法律承诺，或一个客户的个人资料信息泄露到另一个会话中。当AgentCore Evaluations基于样本会话在事后评分时，Guardrails则对每个响应同步执行防护，提供采样评估无法实现的实时安全防护。两者共同构建了完整的质量与安全体系：Guardrails从源头防止有害输出到达用户，而Evaluations则识别随时间积累的细微质量退化问题。

#### 按需评估：开发与CI/CD集成

虽然在线评估提供持续监控，但按需评估可以帮助您调查特定会话：用户投诉、边缘案例或被监控标记的会话。生产指标通常基于采样率（一般为10%）运行，并非所有会话都会被评分。按需评估填补了这一空白，使您可以在任何时间针对特定会话和选定评估器进行评估。除默认的三个指标（Helpfulness、Correctness、Goal Success Rate）外，Amazon Bedrock AgentCore还提供完整的内置评估器目录，如表1所示，支持按需运行。

你也可以创建自定义评估器，使用针对特定领域的评分标准和指令。仪表板通过评估器API展示这些内容，因此你可以浏览可用选项，并对单个会话进行组合评估，或在多个会话中批量运行（图4）。这使得按需评估成为根本原因分析的首选工具：当生产指标下降时，你可以选择有问题的会话并运行定向评估器，以准确了解问题所在。

图4：查看追踪和跨度数据，并对会话的追踪、跨度和工具调用执行按需评估

按需评估的工作流程：

按需评估遵循同步工作流程，你请求对特定会话进行评估后，会立即收到包含评分和解释的结果。

按需评估的工作流程图

#### AI分析引擎：从评分到改进

获取评估指标后，构建一个分析层，用于检测低效会话中的模式，运行统计分析以区分系统性问题和孤立事件，并生成具体的提示改进方案。该层应应用以下内容：

• 无监督模式检测，以在评估维度中揭示重复的故障模式。
• 统计分析（频率、相关性）以识别哪些故障模式是系统性问题，哪些是孤立事件。
• 基于LLM的推理，以根据生产证据生成具体的提示优化建议。

AI引擎识别常见的故障模式：工具选择不当、上下文缺失或特定评分较低的标准。配置它返回结构化发现，包括频率统计、受影响的会话ID以及来自追踪的具体证据。例如，你的引擎可能会发现23%的低分会话涉及代理在用户询问航班变更时选择了错误的工具，且该模式在多轮对话中出现最频繁（图5）。

提示改进层：通过实现一个提示改进功能，在模式分析的基础上构建该层，该功能会生成原始提示的修订版本。此功能应直接针对已识别的模式，明确说明发生了哪些变化、原因以及预期影响（图6）。这完成了评估循环：指标揭示问题，分析确定根本原因，提示改进提供可验证的解决方案，这些方案可以在下一次持续集成和持续交付（CI/CD）运行中进行验证，并在下一个生产周期中进行监控。

图5：基于低分会话的AI模式分析

图6：提示改进建议和改进后的提示

第2层：AWS DevOps代理，系统是否健康？

AgentCore评估监控代理质量，但权限和工具错误等基础设施问题需要不同的方法。AWS DevOps代理充当自主的值班工程师，自动调查基础设施问题。当出现异常时，它会分析系统日志、基础设施指标和错误模式，然后提供具体的修复步骤。

以下演示视频（视频2）展示了AWS DevOps代理如何通过Travel Agent的签名webhook触发：

视频2：AWS DevOps代理如何执行调查，查看相关的Amazon CloudWatch日志和AWS服务差距，以确定根本原因并提供修复步骤

如视频所示，当事件通过签名的webhook提交后，AWS DevOps代理首先会从Amazon CloudWatch中识别相关日志，然后进行分析以检查常见的错误，如IAM权限问题、工具故障或其他隐藏错误，最后通过基于大语言模型（LLM）的推理确定根本原因并提供针对性的建议，以帮助预防未来出现类似问题。

如果没有AWS DevOps代理，您将看到航空公司蜂群代理突然停止响应航班预订请求，返回一个通用错误信息或完全空白的输出，而不是帮助用户解决问题。

此时，您需要执行以下操作：

• 检查应用程序日志中的错误模式。
• 审查最近的部署以查找潜在原因。
• 手动检查IAM策略和权限。
• 在多个服务之间关联Amazon CloudWatch指标。
• 通过多个代理交互追踪执行流程。

假设对系统架构有深入的了解，这一过程可能需要30至60分钟。

在我们通过连接到AWS DevOps代理空间的签名webhook将事件直接提交到AWS DevOps代理空间后，调查随即启动，生成了受影响AWS资源的拓扑图，并对AgentCore运行时的Amazon CloudWatch日志进行了全面分析。

图7：AWS DevOps代理界面显示拓扑图构建和Amazon CloudWatch日志分析同时开始

随后，通过检查调用链中出现的错误，AWS DevOps代理确定了根本原因。

图8：AWS DevOps代理界面显示识别出的根本原因——缺少bedrock:InvokeModel权限，并追踪了从用户请求到Amazon Bedrock API拒绝的完整失败路径

它识别出执行角色缺少bedrock:InvokeModel权限。每个代理调用都通过Amazon Bedrock运行其语言模型，但每个调用都在IAM层被拒绝。监督代理无法调用其模型来处理初始请求，因此返回了空白输出（而不是403错误或异常），因为没有可用的模型响应来生成更具体的信息。

关键的是，AWS DevOps代理不仅识别了IAM错误，还追踪了从用户请求开始的完整失败路径：

用户请求 → AgentCore运行时 → Amazon Bedrock API调用 → 访问被拒绝 → 代理失败

最后，调查在预防选项卡中提供了具体的修复步骤。

图9：AWS DevOps代理界面显示预防选项卡中包含具体、可操作的修复步骤，并附有高置信度评分

总体而言，建议的操作是向特定的执行角色添加所需的Amazon Bedrock权限，并将权限范围限定到正在使用的特定基础模型资源。这些内容为用户提供了未来开发中需要考虑的事项，以帮助防止此类问题的发生。

AWS DevOps Agent 通过在多代理系统中自动化故障诊断来提升开发人员效率。例如，它能将空白代理输出映射到 IAM 层缺少的 Amazon Bedrock 权限。AWS DevOps Agent 协调 Amazon Bedrock AgentCore 运行时、Amazon Bedrock、AWS IAM 执行角色和 Amazon CloudWatch Logs，从而自动关联故障。其在整个多代理调用流程中进行模式匹配的能力，能够发现其他情况下可能被忽略的错误。

除了 IAM 权限问题，AWS DevOps Agent 还设计用于处理多代理系统中常见的各种复杂故障模式。例如包括：

• 负载下的模型限流：当子代理扩展并达到 Amazon Bedrock 每分钟令牌限制时，单个子代理会开始间歇性失败。AWS DevOps Agent 通过关联限流指标与代理调用时间线，识别导致问题的具体模型、区域和流量峰值。

• 被重试逻辑掩盖的工具调用失败：如果子代理的工具集成开始返回错误，而 Supervisor Agent 静默地重新路由，AWS DevOps Agent 会从日志中提取下游工具错误并将其与用户体验下降关联。

• 内存和上下文问题：如果代理在会话中途失去对内存资源的访问，响应会变得不连贯而非直接失败。AWS DevOps Agent 会检测响应质量模式中的异常，并将其与配置更改关联。

• 跨代理通信中断：当代理之间的交接因网络问题或认证问题失败时，AWS DevOps Agent 会跟踪完整的交接链并准确识别通信中断的具体位置。

注意：在采用此架构之前，请注意以下事项：

• LLM 作为裁判的可靠性：AgentCore 评估使用基于 LLM 的评分，但缺乏真实基准。应将评分视为信号而非绝对度量。请与领域专家校准评估器，使自动化判断与人工预期保持一致。

• 服务成熟度：AWS DevOps Agent 正在持续演进。目前，webhook 凭证生成需通过控制台完成，但 Agent Space 的创建和管理可通过 AWS CDK 和 AWS SDK 实现自动化。

• 延迟权衡：在线评估会增加处理开销。降低采样率可减少此开销，但可能导致遗漏边缘情况。根据流量规模和需要覆盖的交互空间范围调整采样率。

• 安全性：需要仔细配置 IAM 策略。AWS DevOps Agent 需要对日志和指标具有广泛的只读访问权限，需合理设置权限范围，确保其能访问所有必要资源以追踪跨服务故障。

• 负责任的 AI 控制：对于生产部署，需结合 Amazon Bedrock Guardrails 进行内容过滤、禁止主题、事实核查和 PII 去识别，以在每个响应中实时防止有害输出。评估可检测质量漂移，Guardrails 帮助实时阻止有害输出。

结论

将代理部署到生产环境只是开始。这种双监控方法（质量监控和基础设施监控）为团队提供了持续改进所需的反馈循环。AgentCore 评估监控质量，AWS DevOps Agent 调查基础设施。两者结合，可将生产数据转化为具体的改进措施。

我们的航空预订系统基于Swarm模式构建，采用Strands代理并部署于AgentCore，证明了这种双监控方法的可行性、可扩展性和有效性。其成果包括更快的事件解决速度、更高的策略合规性，以及以真实生产行为为基础的迭代改进循环。

无论您是正在构建首个多代理系统，还是在扩展现有部署，同样的原则均适用：持续衡量质量、自主调查故障，并让生产数据驱动下一次迭代。

准备好开始了吗？

• 查看我们的开源代码，演示多代理系统的双层监控架构。
• 了解AgentCore，用于代理部署和评估。
• 了解更多关于Strands代理的内容，用于构建多代理系统。
• 查阅τ-Bench基准测试，用于评估代理架构。τ-Bench包含一个tau-airline领域，专门用于测试系统所需的工具调用和策略遵循行为，使其成为验证由AgentCore评估驱动的质量改进的天然选择。

关于作者

'"`