DXC OASIS落地：Bedrock承载多模型治理与受控智能体

摘要：DXC Technology 以 Amazon Bedrock 构建 DXC OASIS 的多模型基础设施，将模型访问与智能体编排明确分层。系统通过 PrivateLink、私有 EKS 运行时、IAM、KMS、Guardrails 和分权审批约束生产环境智能体，并可按任务在 Claude、Nova、Llama 与开放权重模型间路由。官方称，平台在 56 个实测用例中将问题解决时间平均缩短 95%，但该结果来自厂商案例，基准设计、任务复杂度和独立复测仍待验证。

---

DXC Technology 将 DXC OASIS 部署在 Amazon Bedrock 之上，把多模型访问、企业数据边界与智能体执行权限拆成两层：Bedrock 负责受治理的模型底座，DXC 自建的 harness 负责任务编排、知识上下文、权限控制、人工审批与审计追踪。

这一架构面向银行、医院和政府机构等强监管环境。DXC 称，系统自 2026 年 3 月正式可用后，在 56 个受测用例中把平均问题解决时间降低 95%；该数字来自项目方自身统计，尚缺少完整基线定义、样本分布和独立复测。

底座与执行框架为何必须分离

DXC OASIS 没有把“换一个模型”视为普通 API 参数变更，而是将其拆解为三个相对独立的决策：

1. 模型选择：当前可使用 Anthropic Claude、Amazon Nova、Meta Llama 以及开放权重模型。
2. 编排框架：当前 harness 基于开源 LangGraph，由监督智能体向 Linux、AWS、ITSM 等能力型智能体分派任务。
3. 部署目标：智能体运行时位于 Amazon EKS，模型推理通过 VPC 接口端点和 AWS PrivateLink 抵达 Bedrock。

这种解耦降低了迁移成本。模型供应商中断或模型下线时，理论上可以改用路由策略，而不必重建工作流与部署层。不过，统一 API 只解决接入问题，不意味着不同模型具有一致的行为。DXC 因此要求候选模型先通过 OASIS 任务测试，再进入生产路由。

多模型路由的工程机制

系统根据能力、延迟和成本选择模型，并采用 Amazon Bedrock Intelligent Prompt Routing 在同一模型家族内区分简单请求与复杂推理请求。简单任务可以转向低成本模型，复杂任务则交给能力更强的模型；提示词缓存用于减少重复前缀的计算与传输开销。

Custom Model Import 则允许客户或 DXC 引入自有模型，并继续使用统一的访问和治理链路。这里的关键不是“模型越多越好”，而是把路由策略与质量验证绑定。若没有针对具体任务的回归评测，仅因价格下降而自动切换模型，可能引入指令遵循、工具调用、输出格式或安全策略上的行为漂移。

私有网络与多租户隔离

DXC OASIS 的请求从客户 VPC 内的 Route 53 和 Application Load Balancer 进入，Agent Runtime 部署在私有子网的 Amazon EKS 上。模型调用通过 VPC Interface Endpoint 与 AWS PrivateLink 访问 Bedrock，不经过公网。

安全控制还包括：

• IAM 负责身份与访问控制；
• AWS KMS 与 TLS 1.2 分别处理静态和传输加密；
• Bedrock Guardrails 统一执行内容过滤、禁用主题和 PII 脱敏；
• CloudWatch、CloudTrail、VPC Flow Logs 与 OpenTelemetry 提供运行和审计记录；
• EKS 使用租户命名空间隔离，并通过 GitOps 管理发布。

Bedrock 本身是托管、无服务器模型层，因此 DXC 不需要维护 GPU 集群和模型服务调度。但这并不等于总成本更低：推理调用、上下文长度、智能体多轮工具调用、日志与观测数据仍会形成持续费用，私有端点也会带来云资源开销。

四级权限模型阻断生产误操作

DXC 的核心判断是，输入输出 Guardrails 只能过滤内容，不能限制智能体在真实系统中执行什么动作。因此，每个智能体人格从只读权限启动，再按任务逐步提升授权：

• Observe：只读取信息；
• Propose：生成方案，不执行；
• Act with approval：经人工批准后执行；
• Act within scope：只在预先定义范围内自动执行。

生产服务器处置流程采用“批准后行动”模式：指标智能体确认磁盘使用率并定位临时文件，Linux 智能体生成修复计划，但只有工程师明确确认后才会执行。系统同时记录执行对象、命令、批准人和时间戳。

这比单纯在提示词中要求“不要破坏系统”可靠得多，因为权限边界位于工具执行层。即便模型产生错误计划，运行时仍可阻止越权调用。工程上需要注意的是，人工批准不能只是聊天界面中的确认按钮，还应绑定不可篡改的执行计划、参数摘要、短期凭证和幂等机制，避免批准后参数被替换。

端到端可追溯性

OpenTelemetry 为每次智能体执行生成唯一 ID，串起意图、模型调用、能力智能体委派、工具执行和最终结果。DXC 不依赖智能体自行描述“做了什么”，而是由 harness 记录实际执行轨迹。

对于生产运维系统，这种外部证据链比模型生成的自然语言摘要更可靠。它可以支持事故复盘、权限追责和策略回归测试。不过，完整追踪也会增加存储、网络和日志治理成本，尤其当上下文、工具参数与模型原始输出全部保留时，需要考虑敏感信息脱敏与审计数据保留周期。

性能结果及其边界

根据 DXC 的案例数据：

| 任务 | 处理前 | 处理后 | 节省时间 | |---|---:|---:|---:| | 文件系统事故 | 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% |

DXC 还报告诊断准确率达到或超过 92%，但验证依据是对高级工程师判断的对照，而非公开标准测试集。官方样例还使用虚构的 AnyCompany Airlines 环境，因此结果更适合视为架构案例，而不是可泛化的模型能力榜单。

部署建议

企业若采用同类架构，可按以下顺序推进：

1. 先定义动作边界：明确哪些智能体只读、哪些可写、哪些必须人工批准。
2. 隔离模型底座与编排层：模型路由变化不应迫使工作流重构。
3. 建立模型准入测试：任何模型上线前，都要验证工具调用、拒答、输出格式与安全行为。
4. 执行外部审计：以运行时轨迹和系统日志作为事实来源，而非模型自述。
5. 按真实负载核算成本：把多轮推理、缓存、工具调用、日志和人工审批纳入总成本，而非只比较单次 Token 价格。
6. 逐步开放自治等级：先积累可核验轨迹，再从只读和批准后行动提升到限定范围内自动执行。

DXC OASIS 的价值不在于提出了新的基础模型，而在于展示了一套可复用的生产架构：多模型入口保持可替换性，私有网络与托管推理降低基础设施负担，而权限、审批和审计链决定智能体能否真正进入关键业务系统。

---

消息来源：AWS Machine Learning Blog (2026-11-11)

—— 完 ——

主题标签： #DXC OASIS 关注 #Amazon Bedrock 关注 #多模型路由 关注 #智能体治理 关注 #私有云部署 关注