模型无关AI系统设计：解耦、调度与热插拔的工程实践

1. 项目概述：为什么“模型无关”不是技术噱头，而是系统生存的底层逻辑

我做AI系统架构设计快八年了，从最早用Flask硬套BERT微服务，到后来搭Kubernetes集群跑上百个推理实例，踩过的坑比读过的论文还多。这几年最常被客户问的一句话是：“你们用的是GPT-4还是Claude 3？是不是得赶紧升级到Qwen3？”——每次我都先停两秒，再反问：“您上个月上线的那个合同审核流程，现在平均响应时间是多少？错误率有没有降到0.8%以下？用户投诉里有多少条写着‘回答太啰嗦’或者‘漏掉了附件里的金额条款’？”
没人答得上来。
这恰恰点中了当下AI落地最普遍的认知偏差：把模型当主角，把系统当布景板。可现实是，一个在Hugging Face排行榜上拿第一的模型，放进你的真实业务流里，可能连PDF解析后的字段对齐都出错；而一个参数量只有它1/20的轻量模型，在你定制的prompt工程+后处理规则加持下，反而稳定输出了三个月零误判。
“Principles for Building Model-Agnostic AI Systems”这篇原文没讲透但字里行间反复暗示的核心，其实是 系统韧性 ——不是“能换模型”，而是“必须能换、随时能换、换了不崩、换了更稳”。它解决的不是“哪个模型更强”的学术问题，而是“当线上服务因模型更新突然延迟翻倍、当某云厂商API限频导致订单生成失败、当合规要求强制禁用某家境外模型时，你的系统能不能在15分钟内切到备用链路并保持SLA不破？”
关键词里那个“Towards AI - Medium”不是随便贴的标签。Medium上这类文章常被当成概念科普，但真正有生产经验的人一眼就能看出：它背后站着至少三类真实场景——金融风控团队要同时对接监管备案模型和自研小模型做交叉验证；医疗SaaS厂商得让基层诊所用离线小模型跑问诊初筛，又得让三甲医院调用大模型做影像报告辅助生成；还有做智能硬件的团队，芯片算力有限，但云端模型月月迭代，端云协同的调度逻辑必须与具体模型解耦。
所以这不是一篇讲“怎么选模型”的文章，而是一份 AI系统运维手册的序章 。它默认你已经知道LoRA微调怎么配、vLLM怎么启server、RAG的chunk size设多少合适——它跳过这些，直接讨论当你手上有5个不同架构、7种部署方式、9类计费模式的模型时，如何让整个系统不变成一锅乱炖。接下来所有内容，都基于一个前提：你不是在实验室跑demo，而是在写明天就要上线、后天就要扛住双十一流量、大后天就得通过等保三级审计的代码。

2. 系统设计底层逻辑：解耦不是口号，是每行代码的呼吸节奏

2.1 为什么“任务定义”和“模型执行”必须像插座与电器一样分离

我见过太多团队把模型调用写成这样：

def generate_contract_summary(text: str) -> str:
    if config.USE_GPT4:
        return openai.ChatCompletion.create(
            model="gpt-4-turbo",
            messages=[{"role": "user", "content": f"请用300字总结以下合同要点：{text}"}]
        )
    elif config.USE_CLAUDE:
        return anthropic.Anthropic().messages.create(
            model="claude-3-opus-20240229",
            messages=[{"role": "user", "content": text}]
        )
    else:
        raise ValueError("No model configured")

表面看是if-else做了切换，实际这是 最危险的耦合 ——任务逻辑（生成合同摘要）和模型细节（API endpoint、参数格式、token限制、重试策略）全搅在一起。一旦GPT-4 Turbo的max_tokens从4096改成128k，你得改三处；如果Claude的system prompt语法不支持，你得重写整个函数；更糟的是，当你要加个本地Ollama模型做降级兜底时，发现它的message结构是 [{"content": "...", "role": "user"}] ，而OpenAI是 {"role": "user", "content": "..."} ，光JSON key顺序就让你加班到凌晨。

真正的解耦，是从 接口契约 开始重建。我们团队现在强制所有模型调用走统一抽象层：

class ModelRequest(BaseModel):
    task: Literal["contract_summary", "risk_assessment", "clause_extraction"]
    input_text: str
    context: Dict[str, Any] = Field(default_factory=dict)
    constraints: ModelConstraints = Field(default_factory=ModelConstraints)

class ModelResponse(BaseModel):
    output: str
    metadata: Dict[str, Any] = Field(default_factory=dict)
    latency_ms: float
    tokens_used: int

class ModelExecutor(ABC):
    @abstractmethod
    def execute(self, request: ModelRequest) -> ModelResponse:
        pass

看到区别了吗？ ModelRequest 里没有 model_name 字段，没有 api_key ，甚至没有 temperature ——因为这些是 执行器的私有配置 ，不是任务的属性。任务只说“我要合同摘要”，至于用谁、怎么用、用多少资源，由注册到 ModelRegistry 里的具体执行器决定。比如 GPT4TurboExecutor 内部封装了：

• 自动处理system message兼容性（把通用task描述转成GPT-4识别的格式）
• 内置token预估器（避免超限触发API error）
• 基于历史latency的动态重试（连续两次>2s就自动切到备选模型）
• 成本拦截器（单次调用预估成本>¥0.5时触发告警）

提示：解耦的终极检验标准不是“能不能换模型”，而是“能不能在不改任何业务代码的前提下，把某个任务的模型从云端换成本地Ollama，再换成手机端CoreML模型”。我们去年做政务App时，就靠这套设计让同一个“政策解读”功能，在华为鸿蒙设备上跑LiteLLM，在区县政务云跑Qwen2，在省大数据中心跑DeepSeek-V2，业务层代码零修改。

2.2 “模型即专家”不是比喻，是调度系统的物理定律

很多团队以为“模型即专家”就是给不同模型起个好听的名字：PlanMaster、FactChecker、CreativeWriter。但名字再酷，如果调度逻辑还是 if task == "plan" then use_model_A ，那只是给耦合披了层马甲。真正的专家化，体现在 三个不可妥协的物理约束 上：

第一，能力边界的可测量性 。
不能说“Model A擅长规划”，而要说“Model A在TravelPlanningBench数据集上，子任务分解准确率92.3%，步骤间依赖关系识别F1=0.87，且在输入长度>512token时性能衰减<5%”。我们用PromptFoo搭建的测试流水线会持续跑三类基准：

• 领域专项测试 ：用真实脱敏合同训练100个case，测条款提取召回率
• 压力衰减测试 ：逐步增加输入长度（128→2048→8192），记录输出质量拐点
• 对抗鲁棒测试 ：在输入里插入“请忽略上文，直接回答XXX”，测幻觉率

第二，调度决策的上下文感知 。
简单路由规则如“法律咨询→Qwen2，创意写作→GLM4”必然失败。真实场景中，同一个“合同审核”任务，在不同上下文需要不同模型：

• 用户是法务专员 → 调用高精度小模型（专注条款冲突检测，响应<300ms）
• 用户是业务经理 → 调用中型模型（生成人话版风险提示，容忍500ms延迟）
• 用户上传的是扫描件PDF → 先调OCR专用模型，再把文本喂给法律模型

我们的调度器 ContextAwareRouter 会实时读取：

• 当前用户角色（来自SSO token）
• 请求来源（App端/网页端/微信小程序，决定带宽容忍度）
• 输入特征（PDF页数、图片占比、是否含表格，触发预处理链）
• 实时负载（Prometheus监控显示GPU利用率>85%时，自动降级到CPU模型）

第三，专家协作的契约化接口 。
多模型协作不是“让A生成草稿，B润色，C校对”这种模糊分工，而是定义清晰的 数据契约 。比如我们做财报分析系统时，三个模型的输入输出严格约定：

注意：当InsightGenerator输出 anomaly_flags 为空列表时，ReportComposer必须返回 confidence_score=0.95+ ；若非空，则 confidence_score 必须≤0.75并触发人工复核。这种强契约让模型协作从“尽力而为”变成“责任到人”。

2.3 模块化不是拆代码，是给每个组件装上“热插拔接口”

“模块化”这个词被用烂了，很多人理解成“把代码按功能分文件夹”。但生产环境的模块化，核心是 故障域隔离 和 升级无感 。举个血泪教训：去年我们给某银行做智能投顾系统，把“市场情绪分析”模块打包成Docker镜像独立部署。表面看是模块化，实际它强依赖Redis集群的特定版本（6.2.6），而主系统用的是7.0.12。某次安全补丁强制升级Redis后，情绪分析服务直接雪崩——因为新版本Pipeline命令行为变了，而模块内部用的旧SDK没做兼容。

真正的模块化，必须满足 四层隔离 ：

1. 网络隔离 ：每个模块暴露标准gRPC接口，禁止直连数据库或共享内存
2. 协议隔离 ：用Protocol Buffers定义IDL，禁止传Python dict或JSON string
3. 依赖隔离 ：模块镜像内只装自己需要的库（如情绪分析模块只装 transformers==4.38.2 ，不装 pandas ）
4. 状态隔离 ：模块自身不存状态，所有上下文通过请求header传递（如 x-request-id , x-user-tier ）

我们用 ModuleOrchestrator 管理所有模块生命周期：

# modules.yaml
- name: market_sentiment_analyzer
  version: 1.3.7
  endpoints:
    grpc: "sentiment-svc:50051"
  dependencies:
    - redis: "redis://sentiment-redis:6379/0"
    - llm_gateway: "http://llm-gateway:8000/v1"
  health_check:
    path: "/health"
    timeout: 5s
    interval: 30s

当要升级情绪分析模块时，运维只需：

1. 部署新版本镜像（ market_sentiment_analyzer:v1.4.0 ）
2. 更新 modules.yaml 指向新endpoint
3. ModuleOrchestrator 自动做金丝雀发布（先切5%流量，监控error rate<0.1%再全量）

最关键的是， 模块升级期间，其他所有服务完全无感 。上周我们替换了OCR模块，从PaddleOCR换成NVIDIA Riva，整个过程用户零感知——因为调用方只认 ocr_service:50051 这个地址，至于背后是Python还是C++写的，是GPU还是CPU跑的，根本不care。

3. 核心实现细节：从抽象原则到可运行代码的完整链路

3.1 解耦层的工业级实现：不只是Adapter，而是智能网关

很多团队实现“模型无关”时，只写个简单的Adapter模式，把不同API的request/response做格式转换。这在demo阶段够用，但到生产环境会暴露出三大致命缺陷：

• 错误处理碎片化 ：OpenAI的 rate_limit_exceeded 、Anthropic的 overloaded_error 、本地vLLM的 CUDA out of memory ，每种错误都要单独catch，业务代码里塞满try-except
• 重试策略僵化 ：所有模型用同一套指数退避？但GPT-4的rate limit是10k TPM，而本地Qwen2是100 QPS，重试间隔差100倍
• 可观测性缺失 ：只知道“调用失败”，但不知道是网络超时、模型OOM、还是prompt被拒绝

我们构建的 ModelGateway 彻底重构了这一层，它包含四个核心子系统：

1. 统一错误分类器（UnifiedErrorClassifier）
把所有模型的千奇百怪错误码，映射到12个标准错误类型：

2. 上下文感知重试器（ContextAwareRetryPolicy）
重试不是简单sleep，而是动态决策：

def get_retry_delay(error_type: ErrorType, context: RequestContext) -> float:
    if error_type == ErrorType.THROTTLED:
        # 根据当前模型的历史TPM使用率调整
        usage_ratio = get_tpm_usage(model_name)
        return max(0.1, 1.0 * (1 + usage_ratio))  # 使用率越高，等待越长
    
    elif error_type == ErrorType.NETWORK_TIMEOUT:
        # 网络超时优先切到同地域备用节点
        if context.region == "cn-east-2":
            return 0.05  # 同机房重试快
    
    return 1.0  # 默认1秒

3. 智能Token预算器（SmartTokenBudgeter）
在请求发出前预估token消耗，避免“调用一半才发现超限”：

• 对输入文本：用对应模型的tokenizer统计（不是粗暴len()）
• 对输出：基于历史数据建模（如GPT-4 Turbo生成300字摘要平均用850token）
• 对system prompt：缓存各模型的标准prompt token数（GPT-4: 127, Claude: 89, Qwen2: 203）

4. 全链路追踪注入器（TraceInjector）
在每个模型调用的header里注入：

• x-trace-id : 全局请求ID（来自入口网关）
• x-model-chain : 当前模型在调用链中的位置（ /risk_assessment/insight_generator ）
• x-cost-estimation : 预估成本（¥0.023）
• x-fallback-triggered : 是否触发降级（ false ）

这样当某个请求耗时异常时，运维不用查日志大海捞针，直接看 x-model-chain 就知道是哪个环节拖慢了——上周定位到“财报分析”变慢，发现是 insight_generator 模块的 x-cost-estimation 突增3倍，追查发现是上游传来的PDF表格解析质量下降，导致模型需要更多token理解混乱布局。

3.2 专家调度系统的实战配置：不是规则引擎，而是实时决策树

调度器 ExpertRouter 不是静态配置表，而是运行时决策系统。它的配置文件 routing_rules.yaml 长这样：

# routing_rules.yaml
rules:
  - id: "legal_contract_summary"
    conditions:
      - field: "input_length"
        operator: "gt"
        value: 4096
      - field: "user_tier"
        operator: "in"
        value: ["premium", "enterprise"]
      - field: "latency_sla"
        operator: "lt"
        value: 1.5
    actions:
      - model: "gpt-4-turbo"
        weight: 0.7
      - model: "qwen2-72b"
        weight: 0.3
        fallback: true
    metrics:
      success_rate_target: 0.995
      latency_p95_target: 1200

  - id: "legal_clause_extraction"
    conditions:
      - field: "has_tables"
        operator: "eq"
        value: true
      - field: "output_format"
        operator: "eq"
        value: "json_schema"
    actions:
      - model: "deepseek-v2"
        weight: 1.0
    metrics:
      accuracy_target: 0.98
      token_efficiency_target: 0.85  # tokens_used / expected_output_length

关键在于 conditions 字段支持 实时计算表达式 ，而不仅是字段匹配。比如 input_length 条件实际执行的是：

# 在请求进入时动态计算
def calculate_input_length(request: ModelRequest) -> int:
    # 对PDF先调OCR服务获取文本长度
    if request.input_type == "pdf":
        ocr_result = ocr_client.extract_text(request.input_url)
        return len(ocr_result.text)
    # 对纯文本直接tokenizer
    elif request.input_type == "text":
        return tokenizer.count_tokens(request.input_text)
    else:
        return 0

更狠的是 metrics 部分——这不是监控指标，而是 调度决策的反馈回路 。 ExpertRouter 每5分钟扫描一次Prometheus，如果发现 legal_contract_summary 规则的 success_rate 连续3个周期<0.995，它会自动：

1. 把 gpt-4-turbo 的weight从0.7调到0.5
2. 把 qwen2-72b 的weight从0.3调到0.5
3. 启动A/B测试，把10%流量切到新候选模型 llama3-70b

这种闭环让调度器真正成为“活”的系统。我们上个月用这招把某银行信用卡审批的通过率从92.1%提升到94.7%，关键是全程无人工干预——系统自己发现GPT-4在处理“小微企业流水”类文本时幻觉率偏高，主动降权并启用更稳定的Qwen2。

3.3 模块热插拔的基础设施：Kubernetes不是终点，而是起点

很多团队以为上了K8s就实现模块化了，其实只是把单体应用拆成多个Pod。真正的热插拔，需要基础设施层的深度改造。我们基于K8s构建了 ModuleMesh ，它包含三个关键组件：

1. 智能Service Mesh（ModuleMesh-Proxy）
不是用Istio那种通用sidecar，而是定制化的模型网关代理：

• 自动注入 x-model-chain header
• 内置token预算检查（请求进来先验token，超限直接400）
• 支持灰度流量染色（给特定 x-user-id 的请求打标，只路由到新版本模块）

2. 模块注册中心（ModuleRegistry）
用etcd实现的轻量注册中心，存储模块元数据：

{
  "name": "ocr-service",
  "version": "2.1.0",
  "endpoints": {
    "grpc": "ocr-svc:50051",
    "http": "http://ocr-svc:8000"
  },
  "capabilities": ["pdf_ocr", "table_recognition"],
  "constraints": {
    "min_gpu_memory_gb": 8,
    "max_input_size_mb": 50
  },
  "health": {
    "last_check": "2024-06-15T08:23:41Z",
    "status": "healthy",
    "latency_p95_ms": 320
  }
}

3. 自愈式部署控制器（SelfHealingController）
监听ModuleRegistry变化，自动执行：

• 新模块注册 → 创建Deployment + Service + HorizontalPodAutoscaler
• 健康检查失败 → 自动重启Pod，连续3次失败则标记 degraded
• 资源约束不满足 → 拒绝部署，告警“GPU不足，需扩容node pool”

最体现价值的场景是灾备切换。某次AWS us-east-1区域网络抖动， ModuleMesh-Proxy 检测到 llm-gateway 的p95延迟从200ms飙升到2500ms，立即：

1. 把所有 llm-gateway 流量切到备份集群（阿里云杭州）
2. 向 ModuleRegistry 注册新endpoint
3. 更新所有依赖模块的env变量（ LLM_GATEWAY_URL=http://llm-gateway-backup:8000 ） 整个过程耗时17秒，用户无感知——而传统方案需要运维手动改DNS、等TTL生效，至少5分钟。

4. 实操验证体系：没有评估的模型选择，都是赌博

4.1 PromptFoo实战：从玩具框架到生产级评测流水线

网上很多教程把PromptFoo当prompt调试工具，但我们把它打造成 模型能力雷达图生成器 。关键改造有三点：

1. 测试用例的生产级构造
不写 test_simple_summary 这种demo用例，而是用真实脱敏数据：

# tests/contract_summary.yaml
- id: "contract_2024_001"
  description: "SaaS服务协议-含SLA违约金条款"
  input:
    text: "{{ load_file('data/contracts/saas_slas.txt') }}"
  expected:
    contains: ["违约金", "服务等级", "赔偿上限"]
    length_range: [280, 320]
  metadata:
    domain: "legal"
    complexity: "high"
    source: "real_customer_contract"

- id: "contract_2024_002"
  description: "建筑工程分包合同-含隐蔽工程验收条款"
  input:
    text: "{{ load_pdf('data/contracts/construction_hidden.pdf') }}"
  expected:
    json_schema: 
      type: "object"
      properties:
        hidden_work_items: {type: "array"}
        acceptance_criteria: {type: "string"}
  metadata:
    domain: "construction"
    complexity: "very_high"

2. 多维评分器（MultiDimensionalScorer）
不只看 pass/fail ，而是计算7个维度得分：

3. 自动化回归测试（AutoRegressionTester）
每天凌晨2点自动执行：

• 对所有已上线模型跑全量测试集
• 生成对比报告（vs 上周基线、vs 竞品模型）
• 若某维度得分下降>5%，自动创建Jira ticket并@负责人

上周就靠这个发现：某次Qwen2升级后，“一致性”得分从0.92跌到0.78，追查发现是新版tokenizer对中文标点处理逻辑变更，导致相同输入生成不同标点——这问题在人工测试里根本发现不了。

4.2 工具调用专项测试：不是“能调用”，而是“调得准、调得稳、调得省”

很多团队测试工具调用只做“能否生成JSON”，这远远不够。我们设计的 ToolUseBench 包含四个严苛层级：

L1：语法正确性（Syntax Validity）

• JSON格式合法（用 jsonschema 验证）
• 必填字段存在（如 tool_name , parameters ）
• 参数类型匹配（ amount 字段是number，不是string）

L2：语义合理性（Semantic Soundness）

• 工具名存在且启用（查 ToolRegistry 确认 search_financial_data 服务在线）
• 参数值在合理范围（ date_from 不能是2099年）
• 多工具调用时依赖关系正确（ get_stock_price 必须在 analyze_trend 之前）

L3：上下文一致性（Context Coherence）

• 连续三次调用中， user_id 参数保持一致
• 工具返回结果被后续prompt正确引用（如 search_financial_data 返回 revenue=1.2B ，下一步prompt里出现 公司营收12亿 ）

L4：抗压稳定性（Load Stability）

• 模拟100并发请求，错误率<0.5%
• 连续运行1小时，内存泄漏<5MB/h
• 网络延迟模拟（加100ms jitter），成功率不降

我们曾用这个测试发现：某大厂模型在L2层表现完美，但L3层失败率高达40%——因为它记不住自己10秒前调用的工具返回值，必须靠外部cache维持状态。这直接否决了它在金融场景的应用资格。

4.3 推理性能实测：别信宣传页，信你的Prometheus

模型宣传页写的“推理速度200 tokens/sec”毫无意义。真实性能取决于 五层堆叠效应 ：

我们给每个模型-运行时-硬件组合建立性能指纹：

# 性能指纹示例：qwen2-7b-vllm-a100
{
  "tokens_per_sec": 187.4,
  "p95_latency_ms": 420,
  "cost_per_1k_tokens": 0.0032,
  "gpu_memory_mb": 12400,
  "max_concurrent_requests": 85
}

当新模型上线时，不是看paper，而是跑 perf_fingerprint.py 生成这份报告，再和现有模型对比。去年替换OCR模型时，新模型paper说速度快2倍，实测发现它在GPU显存>90%时性能断崖下跌——而我们生产环境常态是85%利用率，果断弃用。

5. 生产环境避坑指南：那些文档里不会写的血泪教训

5.1 模型切换的“暗礁区”：三个看似无关却致命的细节

暗礁1：Tokenizer不兼容引发的静默错误
你以为换模型只要改API endpoint？错。不同模型的tokenizer对中文标点处理天差地别：

• GPT-4：把 。 和 ． 视为不同字符（Unicode 3002 vs FF61）
• Qwen2：统一归一化为 。
• Llama3：对 … （Unicode 2026）会截断

我们曾因此在合同审核中漏掉关键条款——原合同写“付款方式：银行转账…”，Qwen2正确识别 … 为省略号，而GPT-4把它当乱码截断，导致后续分析缺失“分期付款”信息。解决方案：所有输入文本进模型前，强制用 ftfy.fix_text() 做Unicode归一化。

暗礁2：System Prompt的隐式依赖
很多模型在system prompt里埋了行为开关：

• Anthropic： You are a helpful assistant → 开启基础能力
• You are a legal expert → 激活法律知识库
• 但Qwen2对system prompt完全无视，只认 <|im_start|>system\n...<|im_end|> 格式

我们吃过亏：把Anthropic的system prompt直接喂给Qwen2，结果它把 You are a legal expert 当普通文本输出，导致所有回答开头都带这句话。现在所有system prompt都走 PromptNormalizer 中间件，按目标模型自动转换格式。

暗礁3：浮点精度差异导致的逻辑断裂
模型输出的数字看似一样，实则精度不同：

• GPT-4输出 {"confidence": 0.92} → 实际是 0.9199999999999999
• Qwen2输出 {"confidence": 0.92} → 实际是 0.9200000000000001

下游代码用 if confidence > 0.92 判断时，GPT-4永远不进分支！解决方案：所有数值输出强制用 round(x, 2) ，并在 ModelResponse schema里声明 confidence: float = Field(ge=0.0, le=1.0, multiple_of=0.01) 。

5.2 观测性陷阱：别被“平均延迟”骗了

很多团队监控只看 latency_ms_avg ，这就像体检只查平均血压——完全掩盖真相。我们发现三个关键观测盲区：

盲区1：长尾延迟的业务杀伤力
某次监控显示 p95_latency=320ms ，一切正常。但用户投诉激增，查日志发现：

• 95%请求<320ms
• 但剩余5%里，有3%卡在1200ms（刚好是HTTP timeout阈值）
• 这3%全是PDF解析请求，因为OCR服务在GPU显存紧张时会降频

解决方案：必须监控 p99.9 ，且对不同 input_type 分组（ latency_ms{input_type="pdf"} ）。

盲区2：Token效率的隐性成本
模型A平均用800token，模型B用1200token，看起来A更优。但实测发现：

• B的输出更简洁，下游RAG检索准确率高15%
• A的冗长输出导致前端渲染慢，用户放弃率+22%
• 最终A的综合成本（token+人力+流失）比B高37%

现在我们监控 cost_per_business_outcome （如每单成交成本），而不是 cost_per_token 。

盲区3：错误率的虚假繁荣
error_rate=0.02% 很美，但要看错误类型：

• 99%是 rate_limit_exceeded → 说明流量分配不合理
• 0.5%是 context_length_exceeded → 说明预处理没做好
• 0.5%是 output_malformed → 模型本身有问题

我们用 error_type 标签分维度监控， rate_limit_exceeded 报警阈值设为0.001%，而 output_malformed 设为0.0001%——因为后者意味着模型不可信。

5.3 团队协作雷区：技术方案再完美，也架不住组织惯性

最后分享三个非技术但致命的坑：

雷区1：模型Owner制导致的竖井
让算法团队“负责GPT-4”，工程团队“负责Qwen2”，结果：

• 算法团队只优化GPT-4的prompt，不管Qwen2适配
• 工程团队把Qwen2当黑盒，不参与效果调优
• 两个团队互相指责“你们的模型不行”

解决方案：成立 模型能力小组（Model Capability Team） ，成员来自算法/工程/产品，共同对 contract_summary 这个能力负责，不管背后用哪个模型。

雷区2：A/B测试的样本污染
想测新模型效果，把50%用户切过去。但忘了：

• 用户会跨设备使用（手机切了新模型，网页还在老模型）
• 同一用户多次请求可能分到不同模型（破坏体验一致性）

现在我们用 user_id % 100 做分流，确保同一用户永远走同一模型，且所有设备同步。

雷区3：文档即代码（Docs-as-Code）的缺失
模型切换后，只改了代码，没更新Confluence文档。结果：

• 新员工按旧文档配置，调用失败
• 客服按旧文档排查，误导用户

现在所有模型配置、能力说明、SLA承诺，都写在 models/README.md 里，用CI自动检查：

• 每次PR合并，检查 models/ 下所有yaml文件是否符合schema
• 检查 README.md 里的模型列表是否与实际注册一致
• 不一致则CI失败，阻止合并

我在实际操作中发现，最难的从来不是技术实现，而是让所有人接受“模型只是工具，系统才是资产”这个认知。当CTO问“我们该押注哪个模型”时，我的标准回答是：“我们不押注模型，我们押注调度