DXC拆分模型底座与Agent治理层

把 AI Agent 接到生产服务器上，难点很快就会从「模型能不能回答」变成「它到底有权做什么」。DXC Technology 的做法是拆成两层：Amazon Bedrock 统一提供模型访问与基础控制，DXC OASIS 负责调度工具、限制权限、执行审批和留下审计记录。

这套系统宣称，在 56 个已测量用例中，平均解决时间缩短了 95%。这个数字有吸引力，但更值得程序员借鉴的是架构边界：换模型可以是路由问题，生产操作的授权却必须由模型之外的系统掌握。

为什么接入多个模型，还要再造一层控制系统

DXC 为银行、医院和政府机构提供 IT 托管服务，拥有超过 115,000 名员工，业务覆盖 70 个国家。这类环境里的 Agent 一旦误操作，影响可能直接落到业务系统上。

他们把底层称为 substrate，可以理解成「受统一管控的模型接入层」。Amazon Bedrock 通过一致的 API 提供 Anthropic Claude、Amazon Nova、Meta Llama 和开放权重模型的访问，承担几项公共能力：

Amazon Bedrock Guardrails 处理内容过滤、个人身份信息（PII）脱敏和禁用话题策略；AWS PrivateLink 提供私有网络访问；无服务器扩缩容减少自行维护 GPU 基础设施的负担。原文还声明，提示词和模型输出不会共享给第三方模型提供商，也不会用于训练底层基础模型。

但这些能力不能决定某个 Agent 有没有资格删除文件。

上面的 harness，也就是 DXC 自建的执行控制层，才负责工具编排、操作策略、人工审批和完整审计。它还承载 DXC 积累了 60 年的操作手册与升级处理逻辑，把企业里的处理经验接进工作流。

输入输出合规，不能代替生产操作授权。

这个区分对日常 AI 编程同样有用。模型生成了一条格式正确、内容也没触发过滤的命令，不代表当前任务就允许执行它。权限判断必须落在工具调用和执行入口上，不能只靠提示词要求模型谨慎。

多模型解决选择问题，可靠性仍要逐层建设

DXC OASIS 从 2025 年初的原型开始建设，2026 年 3 月正式可用，正向 130 个客户环境扩展。运行时部署在 Amazon EKS，通过每租户独立的 namespace 和 GitOps 推进发布；原文没有说这 130 个环境已经全部落地。

访问链路经过 Amazon Route 53 和 Application Load Balancer，Agent 运行在客户 Amazon VPC 的私有子网中。监督 Agent 向能力 Agent 分派任务，后者访问知识库、AWS Secrets Manager、Amazon EventBridge 和 Amazon S3。模型调用则经过 VPC interface endpoint 和 AWS PrivateLink 到达 Amazon Bedrock，避开公共互联网。

安全与观测涉及 AWS IAM、AWS KMS、TLS 1.2、Amazon CloudWatch、VPC Flow Logs、AWS CloudTrail 和 OpenTelemetry。区域推理控制用于约束获准使用的 AWS Region，但模型在不同 Region 的可用性存在差异，不能把「统一 API」理解成所有区域都能调用同一批模型。

统一入口的收益是减少模型切换时的接线工作。某个提供商故障或模型退役，可以转成路由调整，不必重建整套应用。

不过，接口统一不代表行为统一。模型的能力、回答风格和失败方式仍然不同。DXC 要求候选模型先通过 OASIS 的任务集评估，再进入生产路由；这项工作属于执行控制层，API 不会替团队完成。

路由也有明确边界。原文中的 Intelligent prompt routing，通过单个无服务器端点预测回答质量，在同一模型家族内分流：简单提示词交给低成本模型，复杂推理交给更强的模型。不能据此推断它会自动在 Claude、Nova、Llama 之间完成任意跨家族选择。

Prompt caching 用于降低延迟与成本，Custom Model Import 则让 DXC 或客户自带的模型进入同一套治理和工具体系。至于具体用了哪些模型版本、路由阈值和缓存命中率，原文没有交代。

一次磁盘清理，怎样变成可审批的工作流

原文用虚构航空公司 AnyCompany Airlines 的演示环境，展示两层架构怎样配合。它管理混合部署的本地系统和 AWS 资源，案例不能直接当成真实客户事故记录。

流程从 FlightOps 服务器清理磁盘失败开始。CIO 看到的是业务影响：航班运行调度可能在 4 小时内受到影响；Linux 工程师看到的是可操作的技术告警。

工程师从仪表盘打开 AI Assist，相关指标随上下文进入对话。监督 Agent 制订计划，再委派 DXC OASIS Metrics、Linux System 和 ITSM 等能力 Agent，所有模型调用都经过 Amazon Bedrock。

Metrics Agent 确认磁盘已使用 99%，并引用知识库文章；Linux System Agent 将问题定位到一个 5 GB 的临时文件。到这里，系统完成了诊断，但还没有取得修改生产服务器的许可。

接下来，Agent 展示完整执行计划，工程师明确确认后才运行。原文称之为 act-with-approval：可以自由诊断，操作必须经过审批，而且审批要被记录。

执行后，OASIS 记录运行了什么、在哪台服务器上运行、谁批准、何时执行。审计依据来自执行控制层，而不是 Agent 对自己行为的描述。工程师还能把对话转成知识文章草稿，通过 Query Metrics 查看时间线、委派过程和 token 用量。

Agent 说自己做了什么，不能充当执行凭证。

演示还包含两类任务：ITSM Agent 排出前五类事故并建议改进措施，原文称人工处理需要 2–3 小时；Metrics Agent 按服务和区域拆解 90 天云成本趋势，并继续调查支出峰值。事故处理演示则给出从告警到解决不到 10 分钟的结果。

我的判断

我认同这套方案最关键的取舍：模型选择、编排框架和部署目标分别决策，操作权限另设边界。相比把模型调用、工具执行和审批揉进一个 Agent 循环，这种划分更方便单独替换和验证各层能力。

但文章由 AWS 与 DXC 联合撰写，成绩需要按证据范围看。正式可用后，OASIS 覆盖了 12 类运维角色，涉及 Linux、Windows、SAP、虚拟化、备份与补丁、AWS、Azure 和网络运维。作者报告，56 个用例的平均解决时间缩短 95%，经资深工程师判断验证的诊断准确率达到 92% 或以上。

这些是作者报告的测量结果。输入材料没有给出用例分布、计时口径、样本量、失败案例和成本变化，也没有提供提到的代表性测量表。因此，无法判断 95% 是否包含人工审批等待时间，更不能推出任意团队接入后都能得到同等收益。

同样，文章没有给出单模型与多模型、不同编排方案之间的对照数据。「哪些架构决策最有价值」仍是他们团队的经验之谈。

一般团队也未必需要复制 EKS、多租户和整套 AWS 服务。已有成熟模型网关时，可以先补执行权限和审计；只有少量固定任务时，单模型配合严格工具边界也可能更容易维护。多模型增加选择空间，同时增加评估负担，收益要靠自己的任务集验证。

原文明确说，DXC 正在评估 Amazon Bedrock AgentCore，并未说已经用它替换当前编排层。

能拿来做什么

• 给接触 Node 服务、云资源或生产主机的 Agent 先配置只读权限，再按具体任务开放写操作。DXC 的做法是每个角色从只读起步，逐级授予权限，权限扩大应当有明确依据。
• 将修改操作收口到受控执行入口，先展示完整计划，再记录批准人和实际执行结果。聊天记录可以辅助回溯，执行日志仍要由工具和系统生成。
• 为模型替换准备自己的任务集，覆盖诊断、工具选择和失败处理，再决定是否加入生产路由。不要把 API 能调用成功当成替换验收。
• 如果 AI 助手已接入监控或工单，优先打通「告警携带上下文、诊断引用依据、审批后执行」这一条流程，同时观察耗时、准确性和 token 用量，再决定是否扩大自动操作范围。