企业接入多模型以后一个非常常见的状态是管理员没有明确配 ↓ 平台新模型上线 ↓ 用户自动就能用了这对个人用户很方便对企业治理却不一定合适。GitHub 8月26日开始逐步执行 Copilot 的 Global Model Policy并计划在 9月1日前完成 rollout。核心变化是以前没单独配置过的模型 新上线的GA模型会继承企业的全局默认策略。GitHub 同时明确Open-weight模型默认禁用 需要数据保留、且不在GitHub数据保留协议覆盖范围内的模型默认禁用管理员已经显式 Enabled / Disabled 的模型不会被全局策略覆盖。这个机制真正值得企业 Agent 平台借鉴的不是“GitHub多了一个设置”。而是模型治理必须区分“明确选择”和“继承默认”。如果系统里只有enabledtrue/false很多治理问题根本表达不出来。两态模型不够最简单publicenumModelState{ENABLED,DISABLED}问题是你无法知道是谁决定的 是企业策略 组织策略 团队策略 还是平台默认真正需要的是Decision Source一个更完整的状态publicenumModelPolicyState{EXPLICIT_ENABLED,EXPLICIT_DISABLED,INHERIT_ORG,INHERIT_ENTERPRISE,INHERIT_DEFAULT}再保存publicrecordModelPolicyDecision(StringmodelId,ModelPolicyStatestate,StringdecidedBy,StringpolicyVersion,InstantdecidedAt){}这样 UI 才能真正解释为什么这个模型现在可用为什么“继承”必须显示出来假设Model A今天可用。管理员以为之前有人批准过实际只是默认策略Enabled下个月企业把默认策略改成DisabledModel A 立刻不可用。如果 UI 只显示Enabled团队会非常困惑。所以可用状态最好拆成Effective State Policy Source例如{model:model-a,effective:ENABLED,source:ENTERPRISE_DEFAULT,explicit:false}GitHub现在有4种可见状态公开说明里最终模型会显示类似Enabled Disabled Delegate to enterprise teams/apps or organizations Delegate to default policy这本质上就是Override Inheritance传统 IAM 和 Feature Flag 里非常常见。模型治理也应该这么做。企业模型目录至少要有这些字段publicrecordModelCatalogEntry(StringmodelId,Stringprovider,ModelClassmodelClass,booleanopenWeight,DataRetentionClassretention,SetStringregions,SetStringcapabilities,RiskLevelriskLevel){}不是只存name price context_length因为企业决策通常取决于数据是否保留 是否开源权重 在哪个区域 能否调用工具 是否支持代码执行我会把Data Retention单独建模publicenumDataRetentionClass{ZERO_RETENTION,CONTRACT_COVERED,PROVIDER_STANDARD,UNKNOWN}规则UNKNOWN →默认不可用而不是新模型先开 发现问题再关Open-weight为什么要单独一类GitHub 当前默认把 open-weight 模型排除在自动启用之外。这不意味着open-weight 不安全而是它的治理属性不同。企业可能要额外考虑部署位置 许可证 模型来源 权重供应链 运行环境 安全责任所以模型目录最好把Distribution Model也纳入策略。一个Policy Rulemodel_policy:default:enableddeny_if:-data_retention:UNKNOWN-region_not_allowed:truerequire_explicit_approval_if:-open_weight:true-tool_use_risk:HIGH这比一个总开关细得多。新模型上线时不要直接继承“可用”模型供应商更新速度很快。平台每周可能新增Model A Model B Model C如果全局默认是 Enabled理论上用户无需任何 Review 就能开始使用。更安全的企业策略通常是GA模型 可继承 高风险模型 必须显式 Preview 必须显式 Unknown Retention 禁止Model Lifecycle也要进入治理publicenumModelLifecycle{PREVIEW,GA,DEPRECATED,RETIRED}不同状态不同 Policy。例如preview:default:disabledga:default:inheritdeprecated:new_sessions:falseretired:allowed:falseDeprecated不能只发邮件通知如果一个 Agent 配置锁死model-x模型进入 Deprecated平台要知道哪些Agent依赖它所以需要Model → Agent Dependency Graph一个依赖表createtableagent_model_binding(agent_idvarchar(128)notnull,agent_versionvarchar(64)notnull,model_idvarchar(128)notnull,routing_profilevarchar(128),primarykey(agent_id,agent_version,model_id));模型状态变化时可以直接算影响面。Policy变更前必须做Simulation例如企业准备Default Enabled → Default Disabled不要直接保存。先模拟会影响多少用户 多少Agent 多少自动化 哪些模型会变状态输出{models_changed:14,agents_impacted:38,scheduled_tasks_impacted:112,users_impacted:912}管理员确认后再执行。这其实就是主线第22篇会继续展开的Policy SimulationDurable Decision非常重要GitHub 明确表示显式Enabled / Disabled 不会被全局默认覆盖这叫Durable Override企业内部也应该如此。如果 Security 明确禁用model-x以后 Platform Admin 改defaultenabled不能把它重新打开。Override要保存ReasonpublicrecordModelOverride(StringmodelId,booleanenabled,Stringreason,StringticketId,StringapprovedBy,InstantexpiresAt){}很多 Override 不应该永久。例如临时PoC可以30天后过期到期重新 Review。模型权限最好按Audience分层Developer Data Analyst Finance Legal Security不同团队对模型能力和数据边界要求不同。所以Enterprise Default之下还可以有Org / Team Overlay例如enterprise:default:enabledlegal:deny:-retention:PROVIDER_STANDARDsecurity:allow_explicit:-high_cyber_capability但继承层级不能无限深如果Enterprise → Org → Team → App → User每层都有 Override最终没人知道状态从哪来。我会限制成Enterprise → Organization → Application三层以内。User 个人偏好不能突破管理员策略。Effective Policy必须可解释APIGET /models/{id}/effective-policy返回{model:model-a,effective_state:DISABLED,reason_chain:[{level:enterprise,state:ENABLED},{level:organization,state:DISABLED,reason:data-retention-policy}]}不要只返回403 Model unavailable管理员排障会轻松很多。每次Run都要保存Effective Model PolicyAgent RunpublicrecordModelExecutionRecord(StringrunId,StringrequestedModel,StringeffectiveModel,StringpolicyVersion,StringpolicyDecisionId){}以后出事故能知道当时为什么允许这个模型Policy Drift也需要告警模型 Metadata 可能变化数据保留政策 区域 生命周期 能力如果 Catalog 变了现有 Policy 应重新评估。例如Retention: CONTRACT_COVERED → UNKNOWN应该立即Re-evaluate Effective Access不是等管理员下个月手工看。发布新Agent也要检查Model PolicyAgent 配置models:primary:model-afallback:model-b发布前检查primary允许 fallback允许 目标Tenant都允许不要等生产 Failover 才发现备用模型被禁。Fallback最容易绕过治理正常Model A经过批准。出故障后自动切Model B但 B 可能数据保留不同 区域不同 风险不同所以 Fallback Policy 必须独立校验。Primary Allowed ≠ Fallback Allowed一个Model Routing GatepublicbooleancanRoute(TenantContexttenant,ModelCatalogEntrymodel,TaskRiskrisk){returnpolicyEngine.evaluate(tenant,model,risk).allowed();}Router 只能从Allowed Model Set里做价格/性能优化。最少测试这10种情况1. 新GA模型继承默认策略 2. Explicit Disabled不被默认Enabled覆盖 3. Open-weight模型要求显式批准 4. Unknown Retention默认拒绝 5. Org策略覆盖Enterprise默认 6. 用户不能突破Org禁用 7. 模型Deprecated后新Run禁止 8. Fallback模型独立鉴权 9. Policy变更Simulation正确计算影响 10. Model Metadata变化触发Re-evaluate企业多模型治理最危险的状态不是一个模型被禁用了而是大家都以为它是“有人批准后开启” 实际只是继承了默认值。GitHub 这次 Global Model Policy 把“显式选择”和“继承默认”分开是一个很值得照搬的设计。模型越来越多以后企业真正需要管理的不是一张允许 / 禁止列表。而是一套Model Metadata Inheritance Explicit Override Policy Version Impact Simulation Execution Audit这才是多模型平台能够长期运转的治理基础。