Palantir Rubix 基础层：企业 Agent 的安全、高可用与混合部署

很多 AI 方案在 Demo 阶段只关注 Prompt、模型和工具，到了生产阶段才发现真正困难的是基础设施：权限、网络、节点故障、升级、回滚、数据驻留和长期运维。

Palantir Architecture Center 把 Rubix 描述为承载 AIP、Foundry 和 Apollo 的强化型、可自动扩展、高可用 Kubernetes 基础层。Rubix 的学习价值在于，它把 Agent 如何运行放回基础设施工程，而不是停留在模型调用层。

Rubix 解决什么问题

企业平台通常要同时满足数据和服务隔离、高并发和自动扩展、节点故障后的恢复、不同环境的部署一致性、严格的身份与审计、零停机升级，以及本地、云端和边缘部署。

对 Agent 来说，还要额外考虑工具执行是否被隔离、Agent 是否会访问敏感数据、外部动作是否可追踪、重试是否造成重复写入、长任务是否能在会话中断后继续，以及模型服务不可用时能否降级。

安全默认：先假设环境会被攻击

Rubix 的安全设计建立在一个务实假设上：任务关键软件必须默认安全，平台应预期会遭受攻击，并尽可能自动执行防护。

工作负载隔离

不同服务和任务不应共享不必要的权限或资源。需要执行高权限运维任务的工作负载，应与普通应用驱动的执行分离。

在 Agent 系统中，可以对应为：

Agent 推理进程
工具执行进程
外部系统连接器
数据处理任务
管理与升级任务

这些组件不应因为都属于同一个 Agent 就拥有相同权限。

加密、认证、授权和日志

服务之间的交互至少要做到加密传输和存储、调用方身份可验证、目标服务执行授权检查、请求和结果进入不可随意修改的日志，以及关键配置不能被任意运行时覆盖。

对于 Agent，日志还要记录 Prompt 版本、模型版本、工具参数、用户身份和外部写入结果，否则出现错误时只能看到一句模型回答不对。

高可用：把故障当成正常状态

Rubix 的高可用思想不是保证节点永远不坏，而是让服务在节点被替换、网络波动或实例消失时仍能恢复。

节点周期和短生命周期

通过周期性替换节点来减少持久化风险，并迫使服务具备故障恢复能力。无论具体周期如何配置，这种思想都值得借鉴：不要让系统依赖某个永远不重启的实例。

Agent 运行时应尽量做到会话状态可持久化、工具任务可恢复、中间结果可重放、工作目录可重新挂载、请求具有幂等键，并且失败后不会重复执行危险动作。

Agent 的故障分类

故障	处理方式
模型超时	重试、切换路由或降级
工具超时	查询任务状态，不直接重复写入
节点重启	从检查点恢复
数据源不可用	使用缓存或转人工
权限变化	重新授权，不绕过策略
外部系统部分成功	查询最终状态并补偿

自动扩展：不仅是 CPU 扩展

普通 Web 服务常按 CPU、内存或请求数扩展。Agent 系统还要考虑并发会话数、Token 消耗、工具队列长度、GPU 或模型服务容量、长任务占用时间、外部 API 限速，以及预算和租户配额。

如果只按请求数扩容，长上下文和多工具任务可能快速消耗资源。更稳妥的设计是为不同任务设置队列、超时、优先级和预算。

Apollo 与 Rubix：Day 2 运维

Rubix 提供底层运行基础，Apollo 负责更高层的部署、安装、升级、回滚和环境管理。它们共同解决软件上线之后怎么办。

为什么 Day 2 比 Day 1 更难

Day 1 是第一次部署，通常有明确脚本和环境。Day 2 要处理多个服务的依赖升级、部分节点失败、旧版本与新版本同时运行、配置和数据迁移、回滚、不同客户环境差异，以及运行中的会话和任务。

蓝绿发布

蓝绿升级的基本思路是：先建立新的绿色环境，让它与当前蓝色环境并行运行并观察；确认健康后逐步转移流量，再销毁旧节点。

对 Agent 发布来说，蓝绿环境可以同时比较模型版本、Prompt 和工具 schema、Ontology 定义、评估结果、延迟和成本，以及真实动作成功率。不要只看 HTTP 200，Agent 的健康状态还要包括工具调用、结构化输出、权限检查和业务结果。

混合云和边缘部署

企业可能需要把不同组件部署在不同位置：敏感数据留在本地，模型推理放在受控云环境，低延迟控制在边缘执行，审计与管理回传中心平台。

设计时要提前画出：

数据驻留位置
模型调用位置
工具执行位置
身份与密钥位置
审计日志位置
升级和回滚路径

如果这张图画不出来，Agent 还不能进入生产设计。

面向 Agent 的安全架构模板

用户 / 上游系统
        ↓ 身份认证
Agent Orchestrator
        ↓ 策略检查
工具网关 / Ontology API
        ↓ 最小权限
隔离的工具执行环境
        ↓
外部系统或计算资源

每个阶段都要记录请求身份、权限结果、输入摘要、工具版本、执行结果和副作用。

高风险动作要单独分层

读取库存属于低风险，生成采购建议属于中风险，创建采购单属于高风险，修改付款或合同则可能属于极高风险。

让同一个 Agent 直接拥有全部动作权限，是架构偷懒。应该通过审批、双人确认、额度、环境和时间窗口限制高风险动作。

生产验收清单

可用性

• 单节点故障是否影响任务？
• 模型超时是否有明确降级？
• 长任务是否可恢复？
• 外部写入失败是否可补偿？

安全

• Agent、用户和工具身份是否区分？
• 敏感字段是否按角色过滤？
• 高风险动作是否需要确认？
• 日志是否能还原完整链路？

发布

• 模型和 Prompt 是否版本化？
• 是否有固定评估集？
• 是否支持灰度和蓝绿？
• 回滚后未完成任务如何处理？

成本

• Token、GPU、外部 API 和重试是否计量？
• 是否有租户和项目配额？
• 长任务是否可能无限运行？

常见误区

只用容器解决安全

容器隔离只是基础，还需要身份、网络、密钥、动作权限、日志和治理。

重试所有失败

读操作可以重试，写操作必须先确认幂等和最终状态。

把模型切换当普通配置变更

模型切换可能影响工具调用、JSON 格式、拒答、延迟和业务结果，应纳入评估和发布流程。

忽略环境差异

开发环境能访问的网络、模型和数据，生产或边缘环境可能完全不可用。

参考资料

• The Rubix substrate
• AIP、Foundry 与 Apollo
• Palantir Architecture Center

Rubix 的真正启发是：企业 Agent 的智能只占系统的一部分。要让它成为可靠产品，还需要把隔离、高可用、部署、升级、回滚和审计当作一等能力。