DXC Technology 如何在 Amazon Bedrock 上构建多模型 AI 底座

本文由 DXC Technology 的 Nick Tamburro 联合撰写。

当 AI 智能体能够在银行或医院的生产服务器上执行操作时，获得一个能力强大的基础模型只是起点。近期公开的事件中，自主智能体采取了其运营者从未预期的破坏性操作，这表明真正的风险很少仅来自模型本身。真正的风险在于智能体拥有的权限超出了其任务所需，而架构中没有任何机制可以阻止它。要避免这种情况，首先要有一个在基础设施层面治理模型访问的底层基座。

Amazon Bedrock 提供了这一基座。通过单一托管接口，它为 DXC OASIS 提供了对多个基础模型的访问：Anthropic Claude、Amazon Nova、Meta Llama 以及开放权重模型系列。Amazon Bedrock Guardrails 在所有模型上统一执行内容过滤、个人身份信息（PII）脱敏和禁止话题策略。AWS PrivateLink 将推理流量保持在客户的虚拟私有云（VPC）内，而无服务器扩展避免了将自管理 GPU 基础设施作为故障点。由于这些是系统级控制而非附加组件，它们为 DXC Technology 提供了一个受治理的基础，实现了任何模型层都无法单独提供的能力：一个可信的 harness，可在企业 IT 运营中大规模编排、治理和审计 AI 智能体。

模型可用性因 AWS 区域而异。请参阅 Amazon Bedrock 中按 AWS 区域支持的模型。

DXC Technology 为全球一些监管最严格的组织运行托管 IT 服务：银行、医院和政府机构。DXC 在 70 个国家拥有超过 115,000 名员工，运营着韧性和治理不容妥协的关键任务系统。当 DXC 着手构建 DXC OASIS——用于关键任务 IT 运营的 harness 时，团队将问题分为两层。第一层是构建在 Amazon Bedrock 上的受治理模型基座。第二层是构建在其上的可信 harness：DXC 自己的编排、治理和保障层。

在本文中，我们探讨 DXC 如何在 Amazon Bedrock 上构建 DXC OASIS 之下具有韧性和灵活性的模型基座。我们还展示了 DXC 在基座提供的能力与 harness 必须提供的能力之间划定的界限。自 2026 年 3 月正式可用以来，DXC OASIS 在 56 个实测用例中将平均解决时间缩短了 95%。

在所有模型中，客户数据都保持在 AWS 数据边界内：提示和补全内容不会与第三方模型提供商共享，也不会用于训练底层基础模型。

“我们的客户运营着复杂的业务关键环境，在采用 AI 时需要兼顾选择和韧性。Amazon Bedrock 提供了对广泛模型生态系统的访问，并具备企业规模所需的治理、安全和运营控制。这种灵活性使我们能够为合适的任务使用合适的模型，随着技术演进进行调整，并专注于为客户交付可衡量的业务成果。”

— Dan Gray，DXC Technology GIS 总裁

解决方案概述

DXC OASIS 将“选用哪个模型”的问题与“工作如何完成”的问题分开。Amazon Bedrock 是基础：一个受治理的基础模型（FM）网关，可通过统一的 API 访问，并具备安全与网络控制，使流量始终留在 AWS 边界内。而 harness 则是 DXC 在其上构建的一切：跨工具与系统的编排、源自 60 年运行手册与升级逻辑的运营上下文、策略执行、人工监督关卡，以及对每个智能体操作的完整可审计性。

设计目标如下：

韧性：模型层不存在单点故障。
灵活性：根据成本、延迟和能力，将每项任务路由到最合适的模型。
监管主权：满足受监管租户的数据处理期望。
设计即安全：限定每个智能体可执行的操作，确保任何具有运营影响的操作都必须经过策略检查，并在需要时获得人工批准。

DXC 针对的主要风险是系统与任何单一提供商、框架或部署目标耦合。下图展示了 DXC OASIS 架构中的关键 AWS 服务。

工程师和操作人员通过 Amazon Route 53 和客户 Amazon Virtual Private Cloud（Amazon VPC）内的 Application Load Balancer 访问系统。DXC OASIS 智能体运行时在私有子网中的 Amazon Elastic Kubernetes Service（Amazon EKS）上运行。在那里，一个监督智能体将任务委派给能力智能体，后者利用知识库、AWS Secrets Manager、Amazon EventBridge 和 Amazon Simple Storage Service（Amazon S3）。每次模型调用都通过 VPC 接口终端节点和 AWS PrivateLink 离开子网以访问 Amazon Bedrock，因此推理流量不会经过公共互联网。AWS Identity and Access Management（AWS IAM）、AWS Key Management Service（AWS KMS）、TLS 1.2、Amazon CloudWatch、VPC Flow Logs、AWS CloudTrail 和 OpenTelemetry 在每一层提供安全与可观测性。

图 1：AWS 上的 DXC OASIS 架构

构建 DXC OASIS 基础

DXC 于 2025 年初开始将 DXC OASIS 作为原型构建。一个跨职能团队于 2026 年 3 月实现全面可用，并在 Amazon EKS 上以每租户命名空间和 GitOps 发布方式扩展至 130 个客户环境。构建基础涉及以下任务：

通过 Amazon Bedrock 建立受治理的多模型访问。
将韧性设计到架构的每一层。
将每个工作负载路由到最合适的模型。
划定基础与 harness 之间的界限。

通过 Amazon Bedrock 建立受治理的多模型访问

DXC OASIS 使用的每个模型（Anthropic Claude、Amazon Nova、Meta Llama 以及开放权重系列）都通过 Amazon Bedrock 模型推理访问。因此，提供商中断或弃用会变成一项路由决策，而不是系统重建。然而，统一访问并不等同于统一行为：模型在能力、响应风格和故障模式上各不相同。用一个模型替换另一个模型，既是一项保障活动，也是一项路由变更。在模型进入生产路由之前，由 harness（而非 API）根据 DXC OASIS 任务套件对其进行评估。更多信息，请参阅 Amazon Bedrock 入门。

将韧性设计到每一层

DXC OASIS 的韧性并非单一控制措施，而是多项措施的叠加。下表总结了各项韧性控制措施及其对 DXC OASIS 的作用。

韧性控制措施	对 DXC OASIS 的作用
无单一提供商依赖	所有模型均通过 Amazon Bedrock 模型推理访问。提供商故障或弃用只是一项路由决策，而非系统重建，且 harness 会在切换上线前确保模型间的行为差异。
无服务器模型层	Amazon Bedrock 为无服务器架构，Amazon EKS 控制平面由 AWS 托管，消除了单点故障。
影响范围遏制	Amazon Bedrock Guardrails 无论模型如何，均一致地应用内容过滤器、拒绝主题、PII 过滤器和上下文控制，从而遏制任何单一故障的影响范围。
私有加密路径	Amazon VPC 和 AWS PrivateLink 使模型流量不经过公共互联网。传输中采用 TLS 1.2，静态数据由 AWS KMS 保护。
弹性容量	Amazon EKS 自动扩缩容配合按租户命名空间，使新租户的接入成为一项容量规划工作。

除韧性之外，DXC OASIS 还解决了数据驻留和主权问题。区域推理控制和 AWS PrivateLink 将推理限制在经批准的 AWS 区域内，并使其不经过公共互联网，满足受监管租户的数据处理期望。

将每个工作负载路由到最合适的模型

DXC 基于 Amazon Bedrock 构建的战略原因是可选性。由于所有模型都位于同一 API 之后，团队根据成本、延迟和能力将每项任务路由到最合适的模型，并在新的前沿模型出现时采用它们，而无需重新改造系统。

模型选择作为工作负载决策

每项任务的能力、延迟和成本要求决定其使用哪个模型，而非系统约束。

智能提示路由 – 单一无服务器端点预测响应质量，并在同一系列模型之间路由请求。它将较简单的提示发送到成本较低的模型，将复杂推理发送到能力更强的模型。提示缓存进一步降低延迟和成本。有关更多信息，请参阅 Amazon Bedrock 文档中的智能提示路由。

自定义模型导入 – 通过自定义模型导入，相同的治理和工具可扩展到 DXC 或其客户自行引入的模型。

开放与封闭模型并存

Amazon Bedrock 支持开放权重模型与专有模型并存，因此 DXC 将前沿推理与客户可在同一套护栏下调整和部署的开放权重模型配对使用。

划清基础层与 harness 的界限

每个企业级智能体都需要六项能力。有些是 Amazon Bedrock 直接提供的基础层能力。另一些则只有 harness 才能提供，因为它们依赖于 DXC 的运营上下文和问责模型。这一边界也是智能体安全成败所在。对模型输入和输出的护栏是必要的，但只有 harness 才能限制智能体被允许做什么。下表划清了这一界限。

能力	Bedrock 提供的内容	harness 增加的内容
编排	harness 调用、封装或扩展的基础服务层。	基于开源 LangGraph 运行时构建的、跨工具、系统和多步骤工作流的监督者与能力智能体委派。
上下文	用于检索的知识库基础设施与提示缓存。	60 年的运行手册、升级逻辑和实时 IT 服务管理（ITSM）数据。
治理	AWS IAM、区域推理控制以及租户隔离的模型访问。	按请求执行策略、基于角色的授权以及字段级约束。
护栏	Amazon Bedrock Guardrails：内容过滤器、拒绝主题、PII 过滤器。	在底层过滤器之上执行运营策略：分层知识体系、有范围且可审计的智能体角色，以及针对智能体可执行操作的客户特定规则。
人工监督	不是底层功能。	四个权限层级（观察、提议、经批准后执行、在范围内执行），每个角色都从只读开始，外加审批关口和升级路径。
保障	加密、可审计的基础设施以及 VPC Flow Logs。	为每个操作提供 OpenTelemetry 追踪，每个操作都有唯一的执行 ID，实现从意图到操作的端到端可追溯性。

工作负载如何流经 DXC OASIS

为使架构更具体，以下用例来自 DXC OASIS 演示环境。该环境围绕 AnyCompany Airlines 构建，这是一家虚构的中型航空公司，运行混合的本地和 AWS 资产。

事件解决：诊断并修复一台处于风险中的生产服务器，从告警到解决在 10 分钟内完成。
问题管理：ITSM 智能体对前五大事件类别进行排名，并建议如何减少每一类，这项工作手动完成需要 2–3 小时。
云成本分析：对于 AWS 云工程师，Metrics 智能体按服务和区域分解 90 天的成本趋势，然后根据请求调查支出峰值。

事件解决工作流展示了底层与执行框架如何协同工作：

以业务术语呈现告警 – 一个运行手册未能清除 FlightOps 服务器上的磁盘空间。CIO 将该告警视为业务风险：航班运营调度可能在 4 小时内受到影响。与此同时，Linux 工程师看到同一告警，并带有采取行动所需的技术细节。
规划与委派 – 工程师从仪表板小组件打开 AI Assist，指标作为上下文带入聊天。一个监督智能体将请求分解为计划，并委派给能力智能体（DXC OASIS Metrics、Linux System 和 ITSM），所有模型调用均通过 Amazon Bedrock 进行。
有依据的诊断 – DXC OASIS Metrics 智能体确认服务器已使用 99%，并引用其答案背后的知识库文章。Linux System 智能体将问题追溯到一个 5 GB 的临时文件。
人工审批 – 智能体展示其完整执行计划，在工程师确认之前不会运行任何操作。在此工作流中，智能体在“经批准后执行”层级运行：它可以自由诊断，但未经明确且记录的批准，不能更改生产服务器。
受治理的执行 – 修复运行，DXC OASIS 记录运行了什么、在哪台服务器上、谁批准以及何时批准。审计追踪来自执行框架，而非智能体自己对所做操作的描述。
学习与观察 – 工程师可以将对话转化为知识文章草稿。Query Metrics 视图显示智能体时间线、委派流程以及答案背后的 token 使用情况。

结果

自 2026 年 3 月正式发布以来，DXC OASIS 智能体现已服务于 12 个运营角色，覆盖 Linux、Windows、SAP、虚拟化、备份与补丁、AWS、Azure 以及网络运营。在 56 个实测用例中，DXC OASIS 平均将解决时间缩短了 95%。下表展示了具有代表性的测量结果。

任务	之前	之后	节省时间
文件系统事件	53–90 分钟	3–6 分钟	~89–97%
数据库性能事件	2–3 小时	5–12 分钟	~90–97%
云策略验证	4–8 小时	15–30 分钟	~88–97%
补丁验证	45–90 分钟	5–10 分钟	~85–90%
复杂问题管理	2–6 天	8–10 分钟	~99%

诊断准确率达到 92% 或更高，并已对照资深工程师的判断进行验证。

经验教训与后续计划

四项架构决策被证明最有价值：

将模型选择与编排分离

通过将模型选择、编排框架和部署目标作为相互独立的决策，DXC 在某一层演进时无需重新平台化。

复合韧性控制

没有任何单一控制能让系统具备韧性。无服务器基础设施、模型层护栏、私有网络和人工监督关卡相结合，形成了纵深防御。

明确划分子层与执行框架的界线

明确哪些由云提供、哪些必须自行构建，既能避免工程不足（信任模型自我治理），也能避免过度工程（重建子层已提供的能力）。

在扩展自主性之前先限定其边界。每个 DXC OASIS 角色都从只读开始，更广泛的权限是有意逐级授予的。将自主性视为按任务授予而非默认具备，正是 DXC 能够放心让智能体面对生产系统的原因。

在扩展自主性之前先限定其边界

每个 DXC OASIS 角色都从只读开始，更广泛的权限是有意逐级授予的。将自主性视为按任务授予而非默认具备，正是 DXC 能够放心让智能体面对生产系统的原因。

展望未来，DXC 正在评估 Amazon Bedrock AgentCore 与当前编排层的结合，并随着新的前沿模型通过 Amazon Bedrock 提供，将系统扩展以支持更多受监管的工作负载。

结论

在本博文中，我们展示了 DXC Technology 如何在 Amazon Bedrock 中受治理的多模型子层上构建 DXC OASIS——面向关键任务 IT 运营的执行框架。将模型推理与运营编排分离，从一开始就将韧性、灵活性和监管合规性融入架构。其收益是可衡量的：在 56 个实测用例中，解决时间平均缩短了 95%。对于构建自有智能体系统的团队而言，经验教训是将子层（Amazon Bedrock 提供的部分）与执行框架（你在其上构建的部分）视为独立的层。尽早确定哪些能力属于哪一层。随着对自主 AI 的审视日益增加，这条清晰的界线，连同有边界、可审计的智能体权限，正是系统能够大规模赢得信任的关键。

要开始在 Amazon Bedrock 上使用多模型架构，请参阅 Amazon Bedrock 用户指南。如需进一步了解 DXC OASIS 如何将此架构应用于企业 IT 运营，请联系 DXC Technology。

关于作者

Nick Tamburro

Nick 是 DXC Technology 的 DXC OASIS 首席架构师，负责领导 DXC OASIS 平台的架构与工程工作。他专注于为受监管企业将受治理的多模型 AI 引入关键任务 IT 运营。

Asif Fouzi

Asif 是 AWS 的首席解决方案架构师，帮助 DXC 等全球系统集成商（GSI）利用最新技术进步推动业务发展。在为客户创新的工作之外，他喜欢弹吉他、旅行以及与家人共度时光。