AI Vibe Coding 24《跨租户与多环境治理：统一规则、分域执行》

当平台进入企业级阶段，你会同时面对三种复杂性：

• 多租户：不同业务线、子公司、区域团队共用平台；
• 多环境：dev/staging/prod 策略要求不同；
• 多监管：数据边界、审计要求、审批流程差异巨大。

如果治理只做“全局一刀切”，业务会抱怨不灵活； 如果治理变成“每租户一套”，平台会失控。

这一章解决的核心矛盾是：统一治理框架 + 分域执行策略。

学习目标

完成本章后，你将能够：

• 设计跨租户治理模型（全局策略、租户覆盖、环境覆盖）。
• 建立租户与环境的权限、数据、能力三层隔离。
• 通过配置分层与继承机制实现“共性复用 + 个性约束”。
• 打通跨租户审计与故障定位，避免“问题看得见但找不到根因”。

一、先统一治理模型，再做租户差异

错误做法：每个租户自己定义一套规则。

正确做法：三层治理模型。

1. Global Baseline：平台底线策略（安全、合规红线）。
2. Tenant Overlay：租户级差异策略（业务规则、审批路径）。
3. Env Override：环境级覆盖（实验放宽、生产收紧）。

1.1 组合规则顺序

policy_resolution_order:
  - global_baseline
  - tenant_overlay
  - environment_override
  - runtime_hotfix

但要注意：任何层都不能覆盖全局红线（deny-overrides）。

二、租户隔离：身份、数据、能力必须同时隔离

只做数据隔离不够，能力与身份也要隔离。

2.1 身份隔离

• Agent 身份绑定租户上下文（tenant_id 强制透传）。
• 跨租户调用默认拒绝，必须显式授权。

2.2 数据隔离

• 检索、缓存、向量索引按租户分区。
• 日志与审计可做跨租户汇总，但原文不可互见。

2.3 能力隔离

• 同一 capability 在不同租户可见级别不同。
• 高风险能力按租户白名单开放。

三、多环境治理：同一策略在不同环境要“同构不同强度”

常见问题：开发环境太松，生产环境太严，导致上线后行为漂移。

建议保持策略结构一致，只调整阈值和执行强度。

3.1 环境策略示例

environment_profile:
  dev:
    auto_run_max_level: L2
    hitl_sampling: 10%
  staging:
    auto_run_max_level: L1
    hitl_sampling: 30%
  prod:
    auto_run_max_level: L0
    hitl_sampling: 60%
    critical_actions: dual_sign_required

结构一致可以保证从 dev 到 prod 的迁移可预测。

四、配置分层：让变更可控而非“配置地狱”

跨租户平台很容易演变成海量 YAML 无法维护。

建议采用“继承 + 差量”模式：

• 全局模板定义默认值。
• 租户只配置差异字段。
• 环境再覆盖少量阈值。

4.1 差量配置示例

tenant: retail-cn
inherits: global-default
overrides:
  approval:
    L2: single_sign
    L3: dual_sign
  cost_budget:
    daily_usd: 600

差量越小，治理成本越低。

五、策略冲突与漂移检测

多层配置最怕两件事：

• 冲突：上层允许、下层拒绝，行为不可解释；
• 漂移：规则长期偏离基线，形成隐性风险。

5.1 检测机制

• 冲突检测：发布前静态分析规则图。
• 漂移检测：定期比较租户策略与全局基线差异。
• 风险打分：差异越多、影响越大，风险分越高。

六、跨租户观测：要“汇总看全局，钻取看租户”

平台层面至少要有两级看板：

1. 平台总览：成功率、违规率、成本、升级趋势。
2. 租户视图：按租户切分指标，定位异常来源。

6.1 建议指标

• TenantSuccessRate
• TenantPolicyViolationRate
• TenantCostPerAcceptedTask
• CrossTenantDriftScore

没有租户维度指标，你只知道平台有问题，不知道谁在出问题。

七、审计穿透：从全局事件追到租户决策

每条审计日志都应携带：

• tenant_id
• environment
• policy_version
• capability_id
• decision_trace

{
  "traceId": "trace_20260115_01",
  "tenantId": "retail-cn",
  "environment": "prod",
  "policyVersion": "global@2.4.0 + tenant@1.7.2",
  "decision": "deny",
  "reasonCodes": ["cross_tenant_access_blocked"]
}

这能保证审计既能看全局，也能精确回放单租户链路。

八、Foundation 接口建议

public sealed class PolicyContext
{
    public string TenantId { get; init; } = string.Empty;
    public string Environment { get; init; } = "prod";
    public string CapabilityId { get; init; } = string.Empty;
    public string PayloadDigest { get; init; } = string.Empty;
}

public interface IPolicyResolver
{
    ResolvedPolicy Resolve(PolicyContext context);
}

public interface ITenantIsolationGuard
{
    bool ValidateTenantBoundary(string tenantId, string resourceTenantId);
}

public interface IEnvironmentProfileService
{
    EnvironmentProfile GetProfile(string environment, string tenantId);
}

通过 Resolve + Guard + Profile 三层组合，治理能力可复用且可测试。

九、落地路线（建议 3 周）

第 1 周：模型与基线

• 明确 Global/Tenant/Env 三层模型。
• 制定全局红线策略与覆盖规则。

第 2 周：隔离与配置

• 接入租户身份透传与资源边界校验。
• 上线差量配置与冲突检测。

第 3 周：观测与审计

• 搭建平台总览 + 租户钻取看板。
• 打通审计穿透查询与回放链路。

常见坑

1) 租户策略可覆盖全局红线

会直接破坏平台安全底座。

2) 环境策略结构不一致

导致测试通过但生产失败。

3) 只做平台级监控

缺失租户颗粒度，定位效率极低。

4) 差量配置无生命周期管理

历史遗留覆盖越来越多，最终不可维护。

下一章我们进入《数据与知识边界治理：RAG、记忆与上下文的安全设计》，聚焦“模型看什么、记什么、忘什么”的体系化控制。