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 提供了任何模型层自身都无法实现的受管控基础：一个可以在企业 IT 运营中大规模编排、管控和审计 AI 智能体的可信框架。

模型可用性因 AWS 区域而异。请参阅 Supported models by AWS Region in Amazon Bedrock。

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

在本文中，我们将探讨 DXC 如何在 Amazon Bedrock 上为 DXC OASIS 构建有韧性、灵活的模型基座。我们还将展示 DXC 在基座所提供的功能与框架必须提供的功能之间划定的界限。自 2026 年 3 月正式发布以来，DXC OASIS 在 56 个已度量的用例中平均将解决时间缩短了 95%。

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

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

— Dan Gray，DXC Technology GIS 总裁

解决方案概述

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

设计目标包括：

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

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

工程师和操作人员通过客户Amazon Virtual Private Cloud (Amazon VPC) 内的 Amazon Route 53 和 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 上的 130 个客户环境，采用按租户划分的命名空间和 GitOps 发布方式。构建底层基座包括以下任务：

通过 Amazon Bedrock 建立受治理的多模型访问。
将韧性融入架构的每一层。
将每个工作负载路由到最合适的模型。
划定底层基座与上层挽具之间的界线。

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

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

将韧性融入架构的每一层

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

韧性控制措施	对 DXC OASIS 的作用
不依赖单一提供商	每个模型都通过 Amazon Bedrock 模型推理访问。提供商停用或弃用只需一次路由决策，而无需重建系统，且框架会在切换上线前确保模型之间的行为差异得到验证。
无服务器模型层	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 文档中的智能提示词路由。

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

开放模型与闭源模型并用

Amazon Bedrock 同时支持开放权重模型和专有模型，因此 DXC 可以将前沿推理能力与客户能够在同一套 Guardrails 下进行适配和部署的开放权重模型相结合。

划分基座与框架之间的界限

每个企业智能体都需要六项能力。其中一些是 Amazon Bedrock 直接提供的基座能力。另一些则只有框架才能提供，因为它们依赖于 DXC 的运营环境和问责模型。这一界限也是智能体安全成败的关键。对模型输入和输出的 Guardrails 是必要的，但只有框架才能限制智能体被允许执行的操作。下表划分了这条界限。

能力	Bedrock 提供的内容	框架补充的内容
编排	框架可以调用、封装或扩展的基础服务层。	跨工具、系统和多步骤工作流的监督者与能力智能体委派，基于开源的 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 看到的告警是一项业务风险：Flight Operations 的排班可能在 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。