HPE Zerto 智能体式故障排查将云端 AI 引入本地恢复

HPE Zerto 推出了一套具备三种智能体角色的智能体式故障排查系统，但其最重要的特征在于这些智能体的运行位置。HPE Zerto 智能体式故障排查运行时位于每位客户的环境内部。它在本地分析实时灾难恢复信号，同时将选定的推理和知识查询发送至 Amazon Web Services。

这种划分挑战了一个假设：有用的企业智能体必须将运营数据转移到集中式云应用中。HPE Zerto 则将编排层部署在被调查的基础设施旁边。Amazon Bedrock 提供模型访问、知识检索、防护机制及配套控制能力，但并不承载完整的故障排查工作流。

该系统于 2026 年第二季度投入生产。HPE 和 AWS 表示，随后超过 20% 的 Zerto 客户采用了该系统。双方还称，该系统覆盖的工作流中，支持工单减少了 10%。这些数据来自两家公司，尚未获得独立验证。

这一架构成果的意义不止于单一恢复产品。灾难恢复环境汇集了敏感日志、不断变化的配置、严格的访问控制以及极高的时间压力。无法看到当前状况的助手只能提供泛泛建议；拥有不受限制访问权限的智能体则会带来另一种运营风险。

HPE Zerto 试图在这两种结果之间找到狭窄的平衡点。其智能体获得对本地信息的结构化访问，按技术领域划分调查任务，并通过一个控制型编排器返回精炼答案。核心问题在于：随着实际环境日益复杂，这种架构能否保持上下文、安全性和可预测的行为。

HPE Zerto 智能体式故障排查始于客户环境内部

决定性的变化不在于聊天界面，而在于智能体运行时被部署在它必须调查的系统和证据旁边。

HPE Zerto Software 支持跨混合云和多云基础设施的灾难恢复、持续数据保护及网络韧性。运营人员使用该产品监控受保护工作负载、恢复准备情况、复制健康度以及服务级别协议风险。

对此类环境进行故障排查，传统上需要从多个位置获取信息。管理员可能需要检查告警、查看组件日志、审阅配置数据、检索产品文档，并将发现与运行手册进行比对。在发生故障时，这些来源之间的每一次切换都会增加延迟，也会增加遗漏相关证据的可能性。

新系统在现有的 Zerto 管理界面中嵌入了聊天体验。运营人员可就保护组状态、近期告警、配置实践、复制延迟、升级失败或当前系统问题提问。该助手还可呈现健康问题并引导缓解措施。

根据联合发布的架构说明，HPE 将智能体层作为一个 pod 部署在客户的本地环境中。Pod 是作为一个应用单元运行的、可部署容器组。在这一设计中，它承载本地智能体运行时。

该运行时采用 Strands Agents，这是 AWS 为构建模型驱动智能体开发的开源框架。会话历史保留在本地存储，智能体则通过本地 Model Context Protocol 服务器访问实时 Zerto 信息。

Model Context Protocol，即 MCP，定义了 AI 应用调用工具并获取上下文数据的标准方式。HPE 将现有 Zerto Manager API 封装在 MCP 服务器中，使智能体能够以结构化方式访问当前环境信息。

这与将每一条日志和配置记录复制到远程聊天机器人中存在实质区别。Zerto 智能体可请求调查所需的本地事实，而运行时始终位于设备内部。HPE 表示，只有模型推理请求和 Amazon Bedrock Knowledge Bases 查询会通过 HTTPS 离开本地网络。

这一差异需要谨慎表述。该系统并非完全与云端断开，也不是离线模型部署。Amazon Bedrock 仍会处理模型请求，其托管知识服务则检索相关产品信息。本地设计控制的是编排和运营访问，而不是消除外部处理。

这一边界构成了本文的核心张力。本地运行的智能体可以保持与敏感证据的紧密联系，但其推理仍依赖远程模型服务和经过审慎设计的出站请求。因此，系统的实用性取决于哪些上下文跨越这条边界、它们如何被过滤，以及返回的建议能否始终以事实为基础。

此次发布还将 AI 辅助进一步深入恢复工作流。它不再仅限于解释文档。该系统可以检查当前状况并组织针对具体问题的调查，这既提升了其运营价值，也增加了得出错误结论的代价。

中枢辐射式设计让一个智能体保持控制权

HPE Zerto 将故障排查任务分配给专门智能体，同时保留一个编排器作为委派和最终响应的单一控制点。

该架构采用一个编排器智能体和至少两个专门的子智能体。编排器直接处理常规问题，并在问题需要专业分析时委派更深入的调查。

其中一个子智能体专注于 Zerto Manager，也称为 ZVM。它调查服务崩溃、网络问题和升级失败等领域。其工具可访问相关环境数据，而领域技能则用于识别技术知识和可辨识的日志模式。

另一个子智能体专注于 Zerto Replication Engine，即 VRA。它处理复制问题、跨站点网络、安装失败和延迟。该智能体拥有自己的工具、指令、领域知识和工作上下文。

这种划分体现了一项重要的工程选择。将所有日志、工具、指令和对话细节交给一个通用智能体，可能会产生包含相互竞争信号的过大上下文。这也会使故障难以隔离，因为同一组件同时承担路由、分析和响应生成。

HPE 转而采用中枢辐射式结构。编排器位于中枢，专门智能体则作为辐射节点运行。子智能体向父级汇报，而不是彼此直接调用。

AWS 将这种多智能体模式描述为“智能体即工具”：协调智能体通过受限接口调用专业智能体。每个专业智能体均可使用独立的提示词、上下文、模型和工具集。

对于 Zerto 而言，这种分离带来三项实际益处。首先，日志密集型调查不会将原始诊断材料塞满编排器的上下文。专业智能体只会返回包含发现的简短报告，而非完整的工作过程。

其次，每个智能体都可被独立测试。工程师可以评估 VRA 专家是否选择了正确的工具，而无需让每一项测试都经过无关的 ZVM 行为。这种分离可让回归问题更容易定位。

第三，编排器仍负责生成最终答案。HPE 表示，它会在向用户呈现结果前移除密钥和原始日志。单一输出路径也让产品拥有一个统一的位置来应用响应规则。

中枢辐射式结构限制了横向自主性。如果某个专业智能体发现另一组件拥有问题的根源，它会将这一观察结果返回给编排器，而不会独立调用同级智能体。

这一约束降低了递归式智能体对话在未形成决策前持续消耗 token 的可能性。它还为可观测性创建了可追溯的序列。每一次委派都在同一个控制点开始和结束。

其代价是潜在的路由摩擦。编排器必须准确识别问题何时需要专业处理，并选择合适的智能体。专业智能体也必须压缩其发现，而不能移除对最终诊断至关重要的证据。

HPE 为这些职责采用不同的模型配置。常规工作可由编排器处理，而推理密集型调查可使用更强的模型。该公司表示，它最初评估了更大的模型以验证可行性，随后从响应质量、延迟和成本三个维度比较替代方案。

这种多模型方法避免将每项请求都视为同样困难的任务。检查一个保护组的状态，并不需要与解读跨日志和网络状态的长时间故障序列相同的推理预算。

它还将模型选择从一次性的采购决策转变为持续的工程流程。随着基础模型不断变化，HPE 可重新评估哪种模型适合每个智能体，而无需围绕某个特定供应商的工作流重建整个产品。

实时恢复数据既是优势，也是风险

当系统能够查询当前基础设施时才真正有用，但正是这种访问能力让事实锚定、权限和工具选择变得至关重要。

故障排查智能体需要的不只是产品手册。文档可以解释告警的含义，却无法揭示某个特定复制引擎是否发生延迟、哪条网络路由正在故障，或近期配置变更是否影响了恢复准备情况。

HPE 通过本地 MCP 服务器将其智能体连接到实时运营数据。该服务器将选定的 Zerto Manager API 公开为结构化工具。智能体无需要求语言模型解读原始数据转储，而可以调用已定义的操作并接收类型化结果。

公开的 MCP 规范通过约定的客户端—服务器接口，将工具、资源和提示词分离开来。对于企业软件而言，这种结构可将现有产品 API 转换为智能体可访问层，而无需重写底层运营服务。

类型化访问有所帮助，但并不能保证诊断正确。智能体仍须选择合适的工具、提供有效参数、解读返回信息，并将其与相关文档联系起来。

HPE 将本地工具与 Amazon Bedrock Knowledge Bases 相结合。检索增强生成，即 RAG，会在模型生成答案前检索相关源材料。其目标是让建议以经批准的产品文档和运行手册为依据，而非仅依赖模型记忆。

Amazon 的知识库服务负责管理文档检索，并可返回与查询相关的源材料。在 Zerto 的设计中，这些外部知识补充了通过 MCP 获得的本地环境状态。

这些信息来源之间的区别至关重要。产品文档描述预期行为；本地 API 描述客户的当前状态。可靠的故障排查要求智能体在两者之间进行比较，而不能将通用流程与有关当前事件的证据混淆。

考虑一个复制延迟问题。文档可能将带宽限制、网络中断、工作负载变化或设备健康状况列为可能原因。本地工具必须确定客户环境中实际存在的条件。有效的响应应缩小可能范围，而不是重复完整列表。

HPE 表示，专业代理还会使用包含已知日志模式的领域技能。这些技能为模型提供结构化指导，以识别与特定组件和故障相关的信号。

系统随后需要在内部保留溯源信息。工程师应能够区分由实时数据支持的发现，以及由模型推断得出的假设。已发布的 AWS 文章描述了遥测、评估和结构化输出，但并未披露向管理员展示的完整引用行为。

访问控制带来了另一个压力点。宽泛的 MCP 工具可能暴露超出问题所需范围的运营信息。狭窄的工具可减少暴露，却可能遗漏诊断所必需的上下文。因此，工具边界的设计不仅是集成任务，更是一项安全与产品决策。

按租户标记请求增加了另一层控制。该架构使用与每个租户关联的 AWS Identity and Access Management 角色标签。CloudWatch、DynamoDB 和 Lambda 支持对租户使用情况的监控及限额执行。

Amazon Bedrock Guardrails 会在模型推理前后检查提示词和输出。AWS 文档称，其护栏控制措施可以筛选特定内容、检测提示词攻击、限制被禁止的话题，并掩盖敏感信息。

这些过滤器能够降低特定风险，但无法验证每一项运营结论。响应即使仍处于获批主题范围内，也可能建议错误的修复措施。护栏负责内容边界，而评估和产品逻辑必须解决技术正确性问题。

因此，不应将 HPE 的本地架构简单理解为一项隐私主张。本地编排减少了集中式收集，并让工具执行更贴近实际环境。但它并未消除对出站数据控制、授权设计、模型风险测试，或在高影响事件中进行人工判断的需求。

HPE Zerto 已测试的响应、工具路径、延迟与令牌

HPE 将评估视为一个运营系统，而不是发布前进行的一次准确性测试。

代理评估很困难，因为最终响应只是一个可观察到的结果。代理可能在选择错误工具、使用无关证据，或采取成本过高的路径后，仍然给出看似合理的答案。这种行为在条件稍有变化时就可能失效。

HPE 使用 PyTest 和 Strands Agents 评估软件开发工具包构建测试。随着代理、模型和提示词发生变化，它创建了可重复运行更广泛测试套件的作业。

第一类测试覆盖基础查询。每项测试提供单个请求并评估响应。这种方法适用于具有明确预期结果或既定评分标准的稳定问题。

第二类测试评估多轮对话。用户模拟模型会在初始查询后与代理互动，并对完整对话进行评估。这种形式检验系统是否会请求缺失信息，以及能否在多次交互中保持上下文。

第三类测试生成动态测试。Strands 实验生成器根据选定标准创建案例，使 HPE 能够探索固定测试集中未涵盖的场景。动态生成拓宽了覆盖范围，不过生成的测试仍需要有意义的标准和审查。

每项测试可应用四种评估器。响应评估器根据预定义要求为答案评分。轨迹评估器则检查代理是否选择了适当工具，并遵循可接受的路径。

延迟评估器会根据阈值检查完成时间。令牌评估器检查用量是否保持在既定边界内。这些指标共同反映了生产环境中诊断质量、响应时间和推理消耗之间的权衡。

对于运营代理而言，轨迹评估尤为重要。即使系统通过不安全或不可靠的步骤得出结论，最终措辞也可能看起来正确。对路径进行测试可以揭示：代理是否跳过了实时验证、调用了无关 API，或在已有当前数据的情况下仍依赖文档。

评估套件同样支持多模型设计。HPE 可以使用相同的响应、轨迹、延迟和令牌标准，对比小型模型与大型模型。这使模型替换成为一项基于实证的决策，而非笼统假设更大的模型始终表现更好。

该系统使用 Server-Sent Events 将调查进展流式传输至界面。SSE 是一种 Web 机制，可让服务器通过单个连接持续向浏览器发送更新。用户能够在专业代理检查问题时看到进度。

HPE 表示，流式传输改善了用户体验，因为操作人员不再在毫无反馈的情况下等待。在灾难恢复场景中，可见的进度也有助于区分持续进行的调查与冻结的界面。

不过，如果流式活动只展示步骤而不解释其证据价值，便可能制造虚假的信心。工具调用列表并不等同于经过验证的诊断。界面必须展示足够的进度以建立信任，同时避免将内部推理变成一种表演。

同样的谨慎也适用于 HPE 的采用率主张。该公司报告称，超过 20% 的客户正在积极使用该系统，适用的支持案例减少了 10%。这些结果表明产品确实被使用，但公开文章并未定义“积极使用”、统计窗口或所涵盖的工作流群体。

支持案例减少也可能有多种解释。代理可能成功解决问题、将用户引导至现有文档、改变案例分类方式，或减少部分升级请求。独立的解决率和结果数据将提供更清晰的视角。

对于考虑类似设计的工程团队而言，经验并不是四种评估器就能解决可靠性问题，而是生产代理需要在多个层面具备可衡量的行为。答案质量、工具选择、响应速度和资源使用都可能彼此独立地失效。

可搜索的工程知识库遵循相关原则。当文档保持有序、及时更新，并与工程师正在开展的工作相连时，检索会变得更有价值。

云恢复平台如今面临界面问题

竞争压力正从单纯的复制功能，转向谁能够解读恢复状态，并在事件发生期间指导操作人员。

HPE Zerto 所处的市场已经包含云原生恢复服务。Amazon Elastic Disaster Recovery 会将受支持的本地和云工作负载复制到 AWS 账户中的暂存区域。操作人员可以为演练或真实事件启动恢复实例。

AWS 恢复服务强调持续复制、时间点恢复、非中断测试和故障恢复。它与 AWS 基础设施紧密集成，并面向恢复至 Amazon EC2 的场景。

Microsoft Azure Site Recovery 为受支持的虚拟机和物理服务器管理复制、故障转移和故障恢复。其恢复平台涵盖 Azure 到 Azure 的复制，以及以 Azure 为恢复目标的多种本地场景。

这些服务并不与每一种 Zerto 部署直接对应。HPE Zerto 支持更广泛的混合运营模式，并维护自身的产品架构。这里相关的比较并不是复制功能清单。

新的压力在于这些功能之上的运营界面。恢复系统会生成告警、配置状态、复制指标和演练结果。代理可能将这些信息转化为引导式调查，而无需每位管理员都知道每个信号位于何处。

HPE 的先发行动使其有机会围绕专有运营上下文建立代理行为。其专业代理可以编码组件特定的日志模式，并使用已与 Zerto Manager 和复制引擎关联的 API。

云服务提供商拥有不同的优势。他们控制各自云中的基础设施、遥测、身份服务、恢复 API 和托管 AI 平台。他们可能构建能够直接访问更广泛原生信号集合的代理。

这构成了 HPE Zerto 方法的主要对手：本地控制的故障排查与以云为中心的运营智能之间的较量。这并不只是 HPE 与 AWS 或 Microsoft 之间的竞争，因为 AWS 为 Zerto 的系统提供模型支持。这是一场关于控制与上下文应位于何种架构位置的竞争。

本地控制使编排更贴近受保护基础设施，并能支持具有严格数据驻留政策的环境。以云为中心的系统可以利用集成遥测和托管服务，而无需在每家客户的设备中维护代理运行时。

HPE 的架构结合了两种路径。代理和运营工具保留在本地，而模型推理与文档检索则使用 AWS。这种混合安排试图在不放弃托管基础模型的前提下，将最敏感的执行边界保留在本地。

该方法也让 HPE 承担了完全托管的云服务可以避免的部署责任。本地 Pod 必须持续兼容产品发布、客户网络政策、身份验证系统和受限的出站连接。对故障排查代理本身进行故障排查，成为运营负担的一部分。

隔离网络环境构成了最严峻的限制。HPE 表示，灾难恢复基础设施通常处于隔离网络中、对延迟敏感，或受数据驻留要求约束。然而，所述系统仍需要 HTTPS 访问权限来执行模型推理和知识查询。

因此，严格断开连接的部署无法完全按所述方式使用该架构。其他客户可能允许受到严格控制的出站流量，但安全团队仍需检查目标地址、请求内容、身份控制、保留行为和故障模式。

延迟也跨越两个位置。针对 Zerto 的工具调用保持在本地，而推理请求则会发送至 AWS。复杂调查可能需要在模型决策与本地工具结果之间进行数个循环。流式传输可以让等待过程可见，但无法消除对网络的依赖。

该架构的战略价值取决于这种混合妥协是否优于替代方案。如果它能在不集中化原始运营数据的前提下提供可靠、基于证据的指导，它将为企业软件供应商提供一种可复用模式。如果网络限制或事实依据错误占据主导，买家可能会偏好更简单的辅助功能或完全托管的云运营。

下一项考验是引导式诊断能否成为值得信赖的运营能力

三个信号将表明 HPE Zerto 的代理式故障排查是否正在成为可靠的基础设施，而不只是一个有吸引力的支持界面。

第一个信号是解决质量的证据。采用率和支持工单数量是有用的起点，但它们无法说明用户是否选择了安全的补救措施，或是否更快地解决了事件。

HPE最终应公布受支持工作流的结果指标。可参考的信号包括成功自助解决、与代理交互后的升级、重复事件、管理员接受度，以及审查中发现的错误。在可比较的统计周期内衡量，将使这些结果更具意义。

如果经独立审查的结果显示，该系统能够在多样化的客户环境中准确诊断问题，那么本地代理式运维的理由将更有说服力。若支持需求减少却没有可靠的解决数据支撑，已公布的性能叙事仍不完整。

第二个信号是从咨询类任务向更广泛能力的扩展。HPE将为用户执行任务列为系统目标之一。公开架构主要说明了协助、调查、健康状况告警和缓解建议。

从提出建议转向执行操作，会改变风险模型。错误的解释会消耗时间，而错误的配置变更则可能影响保护能力或恢复准备状态。能够执行操作的代理需要受限权限、审批机制、完整的审计追踪、幂等操作以及可靠的回滚路径。

因此，任何允许系统修改配置的发布都应受到密切关注。具有明确确认步骤的有限、可逆操作，将增强HPE架构的可信度。缺乏已公布控制细节的大范围自主修复，则会增加不确定性。

第三个信号是该代理在连接受损和重大事件期间的表现。日常支持问题通常具备稳定的网络访问和中等紧迫性。勒索软件事件或基础设施中断，则可能破坏代理所依赖的身份、网络或云端路径。

当Amazon Bedrock不可用、知识查询超时、本地工具返回过期数据，或编排器无法完成调查时，HPE需要明确系统行为。安全降级应区分证据缺失与基础设施健康，并引导运维人员转向既有的恢复流程。

该公司的内部使用提供了另一处测试场景。HPE表示，其工程师使用该系统调查常见问题，其质量保证团队则将其整合进测试工作流。这些用户能够在客户于危机中依赖相同行为之前，暴露潜在的失败模式。

该架构已经包含若干合理约束。专业代理承担边界明确的职责。禁止点对点递归。编排器控制最终输出。本地API提供当前数据，而重复评估会检查响应和工具调用轨迹。

这些控制措施都无法让语言模型的推理变得确定无疑。系统仍需跨越不断变化的软件版本、客户拓扑、日志格式、模型发布和文档运行。因此，持续评估必须在产品部署后继续跟进。

对于企业买家而言，关键问题不是代理能否总结一条告警，而是系统能否展示其答案来源、遵守运维权限、识别缺失证据，并在不确定性演变为行动之前进行升级。

开发者应关注工具边界。设计良好的MCP服务器可以让代理使用现有API，但每一项暴露的操作都会扩大系统权限。产品团队应以设计公共API和管理角色同等的严谨态度来设计工具。

知识工作者可以从此次部署中得到更广泛的启示：当AI能够将可信的参考资料与当前工作语境相连接时，它会变得更有用。这一收益依赖于来源质量、访问边界，以及对检索事实与生成判断的清晰区分。

HPE Zerto已将这一理念带入企业计算中最不容出错的场景之一。该系统将本地编排、实时灾难恢复数据、专业代理和托管云端推理整合到同一条运维路径中。

如今，证据必须超越采用率。关注HPE是否公布解决结果、引入受控操作，并记录降级模式下的行为。这些信号将决定HPE Zerto代理式故障排查模型是否会成为其他基础设施供应商应当效仿的模式。