代理模型双路线：工程仿真响应面与AI助手本地云端路由

1. 先把“代理模型”这词拆开，它其实是两条完全不同的技术路线

“代理模型”这四个字，在技术圈里被用得相当混乱。我在不同场合听到它，指的东西能差出十万八千里：做结构优化的工程师说的是surrogate model，做 AI 应用的人说的是“用一个模型去代表另一个模型的行为”，还有一部分人干脆把它和“AI 代理助手里挂哪个模型”混为一谈。这四种说法虽然在中文里都叫代理模型，但背后的数学、工程约束和落地方式完全是两套体系。

这篇东西我打算把这两条线拆开讲清楚。第一条线是传统工程仿真里的代理模型，也叫响应面、元模型、近似模型，核心用途是用一个计算便宜的函数去替代昂贵的数值仿真，让优化迭代从“跑一次算三天”变成“跑一次算三秒”。第二条线是 AI 代理系统里的模型层设计，也就是大家最近常聊的“本地模型加云端模型怎么分工、怎么按任务切换、怎么在成本和效果之间找平衡”。

写这篇的动机很简单。我过去两年既做过叶轮机械的气动优化代理模型，也搭过内部 AI 代理助手的模型路由层，发现两边的人互相看不懂对方在说什么，而真正踩的坑其实高度相似：采样不充分导致模型外推崩溃、精度指标好看但实际用起来不灵、模型切换之后行为漂移。这些问题在两条线上反复出现，只是换了个名字。所以下面我按“概念澄清 — 算法选型 — 实操落地 — 问题排查”的顺序，把两条线都过一遍，该给参数给参数，该给代码给代码。

不管你是做仿真优化的工程师，还是在搭 AI 代理助手的应用开发者，或者只是被“代理模型”这个词搞懵了想弄明白它到底指什么，下面这些内容应该都能对上号。

2. 工程仿真里的代理模型：用便宜函数替掉昂贵仿真

2.1 为什么需要代理模型，算一笔时间账就懂了

先举个具体的场景。假设你在做一个换热器的翅片参数优化，设计变量有六个：翅片高度、翅片间距、厚度、开窗角度、开窗长度、开窗数量。如果每个变量取五个水平做全因子试验，组合数是 5 的 6 次方，也就是 15625 组。用三维 CFD 算一组稳态工况，网格量算 300 万，在一台 32 核的机器上大概要 40 分钟。全部算完需要 15625 × 40 分钟，约等于 434 天，单机跑一年半。这就是所谓的“维数灾难”加“计算成本墙”。

代理模型的思路是：我不需要知道每一个点的精确值，我只需要在有限的、精心挑选的样本点上算出精确值，然后用一个光滑的、可解析求导的函数去拟合这些点，之后所有的搜索、寻优、敏感性分析都在这个便宜函数上做。上面那个例子，通常取 60 到 120 个样本点就能建出一个可用精度的代理模型，算力需求从一年半压缩到两三天。

注意：代理模型的精度上限由样本点决定，它不会凭空产生信息。如果你采样区域没覆盖最优解所在的区域，再好的算法也救不回来。这一点后面会反复提到。

代理模型这个词在工程优化语境下还有几个常见别名：响应面模型（Response Surface Model）、元模型（Metamodel）、近似模型（Approximation Model）。它们的细微差别在于，响应面早期专指二次多项式拟合，元模型偏向统计学背景，代理模型则是现在最通用的叫法，泛指一切替代高保真求解器的近似手段。

2.2 主流算法选型：多项式、克里金、神经网络该怎么选

选算法这件事，很多人一上来就问“哪个最准”，这个问法本身就有问题。正确的问题是：我的样本量有多少、设计变量几维、输出是标量还是场、我需不需要解析梯度。把这四个问题的答案写下来，选型基本就定了。

我自己的经验是：样本量在 200 以下、变量不超过 15 维，优先上克里金。原因是它给出的不只是预测值，还有预测方差，这个方差在后续的自适应加点里能直接当“哪里还没探索够”的指标用，相当于白送了一个探索策略。样本量上千之后再考虑神经网络，否则网路参数比样本还多，过拟合跑不掉。

维度超过 30 维的时候，所有代理模型都会开始退化，这时候要做的事情不是换算法，而是先做变量筛选或者降维。我做过一个 46 维的案例，直接用克里金，交叉验证 R² 只有 0.71，完全不能用。后来先用 Sobol 指数筛掉 28 个影响极小的变量，剩下 18 维重训，R² 直接上到 0.94。降维的收益远大于换模型。

2.3 采样策略：模型好不好，八成看采样

采样方法决定了你花出去的每一次高保真计算是否“值回票价”。常见的几类：

• 拉丁超立方采样（LHS）：把每个维度均分成 N 个区间，保证每个区间恰有一个样本。优点是空间填充性好、实现简单，是最常用的默认选择。缺点是有随机性，不同随机种子出来的结果质量差别不小，建议跑多次取“最大最小距离”最大的那一组。
• Sobol 序列 / Halton 序列：低差异序列，比 LHS 更均匀，尤其是维度高的时候优势明显。做敏感性分析时我基本都用 Sobol。
• 正交数组：适合因子水平实验，但对非线性响应不友好，现在用得少了。
• 自适应采样：先建一个粗模型，再用采集函数挑下一个点，迭代加点。样本效率最高，但流程复杂，需要有并行计算资源配合。

样本数量的经验公式，工程上常用的是10d 到 20d，d 是变量维数。但这个公式太粗糙。更靠谱的做法是先取 10d 建一个初始模型，看交叉验证的 R²，如果低于 0.85 就接着加点，每次加 5 到 10 个点，直到连续两轮 R² 提升小于 0.01 就停。我在实际项目里用这个策略，平均能比一次性采样省掉 30% 左右的高保真计算次数。

提示：采样点的选取要结合物理边界。比如翅片厚度有加工下限，你采样时越过这个下限，模型会去拟合一个根本造不出来的形状，白白浪费采样预算。

3. 工程代理模型落地：从数据到可用于优化的模型

3.1 完整流程走一遍：以气动优化为例

我把整个流程拆成六步，每步的关键动作和容易翻车的地方都标出来。

第一步，确定设计变量和取值范围。这一步看着简单，实际上最容易出问题。变量范围定太窄，最优解在边界外面；定太宽，模型在大部分区域精度都不够。我的做法是先跑一次单变量扫描，每个变量在预估范围内的三个水平上算一算，看响应变化幅度，把明显没影响的区间砍掉。这样一圈下来，变量范围通常能压缩 30% 以上。

第二步，做实验设计生成样本。用 LHS 生成初始样本，变量维数 d，样本数取 10d。生成之后不要直接用，先做一次最小距离检查，把距离过近的点对找出来，手动扰动其中一个。我见过两个样本点在归一化空间里距离只有 0.03 的情况，那基本等于算了两遍同一个点。

第三步，批量跑高保真计算。这一步是纯算力活，但要注意三个细节：一是所有算例的收敛准则必须一致，不能有的算到 1e-4 有的算到 1e-5；二是网格无关性要提前验证好，不同样本用不同网格量会导致响应里混进数值噪声，模型会去拟合这个噪声；三是做好算例管理，样本点坐标和结果文件的对应关系一定要有表，不然后面全乱。

第四步，训练代理模型并交叉验证。这是核心环节，下面单独用一节讲。

第五步，在代理模型上做优化。因为模型便宜，可以用遗传算法、粒子群、贝叶斯优化随便跑，几十万次评估也就几秒钟。这一步的产出是一批候选最优解，不是最终解。

第六步，用高保真计算验证候选解。这一步绝对不能省。我见过太多次代理模型说某个点性能提升了 8%，实际算出来反而降了 3% 的情况。验证通过才叫收敛，验证不通过就把这个点作为新样本加进去重训，再来一轮。

3.2 精度验证：R² 只是入门指标，别只看它

评估代理模型质量，常用的三个指标：

• 决定系数 R²：衡量模型解释了多少响应方差。公式是 R² = 1 - SS_res / SS_tot。工程上一般认为 R² > 0.9 可用，> 0.95 算好。但这个指标有个致命弱点，它对样本内的拟合很敏感，样本点一多就容易虚高。
• 均方根误差 RMSE：单位跟响应量一致，直观。判断标准是 RMSE 要小于响应量变化幅度的 5%。
• 最大绝对误差 MAE_max：最坏情况下的偏差。做安全相关的优化时，这个指标比 R² 重要得多。我一般要求 MAE_max 不超过响应范围的 10%。

比这些更关键的是验证方式。样本量小于 50 用留一交叉验证（LOO），大于 50 用 5 折或 10 折交叉验证。绝对不能只看训练集上的 R²，那个数字没什么意义。

还有一个我踩过的大坑：交叉验证 R² 很高，但模型在实际优化中给出的最优解完全不可信。原因通常是样本分布不均匀。比如你的 LHS 采样在某个角落恰好点很密，那边 R² 贡献很大，把整体指标拉高了，而真正的最优区域样本稀疏，模型在那儿根本不靠谱。

解决方法是按区域分段看指标。把设计空间粗分成几块，统计每块的局部误差，哪块差就在哪块补样本。这个操作听起来麻烦，但比全局指标靠谱得多，我现在基本是标准动作。

3.3 从模型到优化：采集函数和加点策略

建好模型之后，怎么用它找最优点，有两种路线。一种是直接把模型当黑箱，扔给遗传算法跑；另一种是用贝叶斯优化框架，用采集函数引导搜索。后者样本效率高得多，尤其是在高保真计算特别贵的时候。

贝叶斯优化的核心是采集函数，常见三种：

• 期望改进 EI：EI(x) = (μ(x) - f_best) · Φ(z) + σ(x) · φ(z)，其中 z = (μ(x) - f_best) / σ(x)，Φ 和 φ 分别是标准正态的分布函数和密度函数。它同时考虑预测值和不确定性，平衡开发和探索，是最常用的默认选择。
• 改进概率 PI：只算 μ(x) 超过当前最优的概率，形式简单但探索能力弱，容易早熟。
• 置信上界 UCB：μ(x) + κ·σ(x)，κ 是调节系数。κ 大偏探索，κ 小偏开发。实际调参时 κ 从 2 开始试。

下面是一段简化版的克里金代理模型加 EI 加点的 Python 示例，用 sklearn 和 scipy 就能跑：

import numpy as np from sklearn.gaussian_process import GaussianProcessRegressor from sklearn.gaussian_process.kernels import Matern, ConstantKernel from scipy.stats import norm from scipy.optimize import minimize # 假设 X_train 已归一化到 [0,1]^d，y_train 是标量响应 kernel = ConstantKernel(1.0) * Matern(length_scale=np.ones(X_train.shape[1]), nu=2.5) gp = GaussianProcessRegressor(kernel=kernel, alpha=1e-6, normalize_y=True, n_restarts_optimizer=5) gp.fit(X_train, y_train) f_best = y_train.min() def neg_ei(x): x = x.reshape(1, -1) mu, sigma = gp.predict(x, return_std=True) sigma = max(sigma[0], 1e-9) z = (f_best - mu[0]) / sigma ei = (f_best - mu[0]) * norm.cdf(z) + sigma * norm.pdf(z) return -ei # 多起点局部优化，避免落入局部极值 best_x, best_val = None, np.inf for _ in range(20): x0 = np.random.rand(X_train.shape[1]) res = minimize(neg_ei, x0, bounds=[(0, 1)] * X_train.shape[1]) if res.fun < best_val: best_val, best_x = res.fun, res.x print("下一个采样点：", best_x)

这段代码里有几个参数值得说一下。nu=2.5的 Matern 核是我最常用的，它比 RBF 核更宽容，对响应里的轻微不光滑不敏感；alpha=1e-6是给数值稳定性加的白噪声项，如果你的高保真计算本身有收敛噪声，这个值要放大到 1e-4 量级；n_restarts_optimizer=5是核参数优化重启次数，维度高的时候要加到 10 以上，否则容易停在局部最优的超参数上。

注意：克里金训练的计算复杂度是 O(n³)，样本数超过 2000 之后训练会明显变慢。这时候要么改用稀疏高斯过程，要么换神经网络代理。别硬扛。

加点策略上，我一般混合使用两种点：一种是 EI 最大的点，用来找最优；另一种是预测方差最大的点，用来补足模型盲区。比例大概 3:1，也就是每加三个 EI 点，加一个纯探索点。这个配比在多数问题上表现稳定。

4. AI 代理助手里的模型层：本地和云端怎么分工

4.1 这两种“模型”到底有什么区别

说完工程代理模型，转到另一条线。AI 代理助手里说的“模型”，指的是大语言模型本身，而“代理”指的是围绕模型搭起来的一整套循环：接收任务、拆解步骤、调用工具、观察结果、再决定下一步。所谓“用本地模型加代理助手”，本质是在代理框架里，把一部分推理请求交给本地部署的小模型，把另一部分交给能力更强但更贵的远端模型。

这两条线的共同点其实很微妙：工程代理模型是“用一个便宜的函数近似一个昂贵的函数”，AI 代理的模型路由是“用一个便宜的模型处理一部分请求，把贵的模型留给真正需要的请求”。两者都在做同一件事——在效果和成本之间做分层。理解了这一层，很多设计决策就顺了。

为什么会有这个需求？因为把每个请求都丢给最强模型，成本是线性增长的，而且延迟也高。一个典型场景是内部知识问答助手，用户每天问几百个问题，其中可能有六成是“这个文档在哪”“这个字段是什么意思”这类简单查询，剩下四成才是真正需要多步推理的复杂问题。如果全都用最强模型，成本会是不分层方案的四倍以上，而实际效果提升可能只有几个百分点。

4.2 本地模型和远端模型各自适合接什么活

分工的边界不是拍脑袋定的，要按任务特征来。我按四个维度做了个对照表，可以当决策参考。

我自己搭过的那套助手，最终的分工是这样的：意图识别、实体抽取、回复格式整理全部走本地 7B 量级的模型；只有需要三跳以上推理、或者涉及跨文档比较的任务才路由到远端。实测下来这套分工承担了大约 65% 的请求，剩下的 35% 走高能力模型，整体成本降了六成左右，用户端感知到的答案质量没有明显下降。

有一个反直觉的发现：本地模型在“格式严格、答案封闭”的任务上，稳定性反而比大模型好。比如把一段自然语言转成固定的 JSON 结构，设定了严格的 schema 约束之后，小模型不会像大模型那样“自作主张”多加字段。因为它能力弱，反而更听话。这一点在做结构化输出时特别有用。

4.3 路由策略：怎么决定一个请求交给谁

路由是整个设计的核心。我按从简到繁排了四层策略，实际项目里通常组合使用。

第一层，规则路由。用关键词、请求长度、是否包含代码块这些表面特征做判断。比如请求里出现“帮我把下面这段转成表格”，直接走本地。规则路由快、可解释、零成本，缺点是覆盖不了复杂情况。但别小看它，实际项目里这层能处理掉三四成的请求。

第二层，轻量分类器路由。训练一个小分类模型，输入是请求文本，输出是“简单/复杂”二分类。这个分类器可以用历史日志标注出来，几百条样本就能训到不错的水平。它的延迟只有几毫秒，比让大模型自己判断“这题难不难”便宜得多。

第三层，级联路由。先让本地模型试，同时输出一个置信度。置信度高于阈值就直接返回，低于阈值就转给远端模型重做。这层的成本优势最大，因为大量简单请求根本不会碰到远端。难点在于置信度怎么算——常见做法是看输出长度、是否命中预设的不确定表达、以及多次采样的答案一致性。

第四层，预算与配额路由。给每个用户或每个会话设一个月度预算上限，接近上限时强制降级到本地模型。这层主要是成本控制手段，不涉及效果优化。

下面是级联路由的一个最小实现骨架：

def route(request, session): # 1. 规则层：命中直接返回 if hit_rule(request): return call_local(request) # 2. 分类层：预测复杂度 complexity = classifier.predict(request) # 0~1 if complexity < 0.3: return call_local(request) # 3. 级联层：本地先试，置信度不够再升级 if complexity < 0.7: local_out, conf = call_local_with_confidence(request) if conf >= CONF_THRESHOLD: # 经验值 0.75 起步调 return local_out return call_remote(request, context=local_out) # 4. 直接走远端 return call_remote(request)

CONF_THRESHOLD这个阈值要拿评测集调。调太高，本地能接的请求变少，成本上去；调太低，错误答案直接返回给用户，体验崩盘。我的经验是从 0.75 开始，每次降 0.05，同时监控用户追问率和人工纠错率，找到那个曲线拐点。

提示：路由层一定要有旁路开关。线上出问题时能一键把所有流量切回单一模型，这是保命设计。我就遇到过本地模型服务因为显存碎片导致推理超时，如果没有旁路，整个助手直接不可用。

4.4 多模型切换的工程实现要点

模型切换最容易出问题的不是技术，是行为一致性。同一个提示词，喂给不同的模型，输出的格式、语气、长度分布都不一样。用户会明显感觉到“这个助手今天怎么怪怪的”。

我处理这个问题有三个固定动作。

统一提示词模板和输出契约。所有模型共用一套系统提示词，并且在末尾强制约定输出格式。能上结构化输出约束的就上，让模型返回固定字段的 JSON，再由外层代码渲染成自然语言。这样模型换了，用户看到的呈现不变。

建回归评测集。准备 100 到 200 条覆盖主要场景的测试用例，每条有明确的期望行为（不是精确文本，而是关键信息是否出现、格式是否正确）。每次切换模型、改提示词、调路由阈值，都跑一遍。这个评测集是整个系统里最值钱的东西，比任何模型都值钱。

记录全链路日志。每次请求要记：走了哪条路由、用了哪个模型、首 token 延迟、总延迟、token 消耗、是否触发了降级、用户有没有追问。这几个字段攒够两周，你就能看出路由策略该怎么调。

配置化的做法我推荐把模型定义写成外部配置文件，代码里只读配置不写死模型名。这样加一个模型或者改一个路由规则，不用发版。形式上大概是：

models: local_small: endpoint: "http://127.0.0.1:8000/v1" context_window: 32768 cost_per_1k: 0.0 timeout_s: 15 remote_strong: endpoint: "https://api.internal.example/v1" context_window: 200000 cost_per_1k: 0.012 timeout_s: 60 routes: - name: format_task match: ["转成表格", "提取字段", "改写成"] target: local_small - name: default_cascade match: ["*"] target: [local_small, remote_strong] threshold: 0.75 fallback: on_timeout: remote_strong on_error: remote_strong max_retries: 2

把路由规则、模型参数、降级策略全放进配置，好处是运维和调优可以分离。运营同学想改个关键词匹配，不用等开发发版。

5. 踩过的坑和排查手册

5.1 工程代理模型的典型故障排查

这里重点说最后一条。代理模型的预测只在采样点包络范围内可信，一旦跑到外面，高斯过程会退回到先验均值，神经网络会给出完全离谱的值。所以每次优化完，我都会检查最优解到最近训练样本点的归一化距离，超过 0.15 就标记为“外推风险”，必须用高保真计算验证。

5.2 AI 代理助手的典型故障排查

5.3 几条通用的实操心得

第一，先量化再优化。不管是哪个方向的代理模型，动手之前先把基线数字拿在手上。工程侧是“跑一次高保真要多久、总共要跑多少次”，AI 侧是“每天多少请求、平均多少 token、成本多少”。没有基线数字，所有的优化都是盲猜。我见过团队花两周优化路由，最后发现省下的成本不到总成本的 8%，因为流量大头根本不在他们优化的那部分。

第二，精度指标要跟业务指标挂钩。工程侧的 R² 0.95 听着漂亮，但你要问的是：这个精度下，代理模型推荐的方案拿去实算，有多少比例真的比原方案好？我给自己定的门槛是这个比例要超过 70%，低于这个数就回去补样本。AI 侧同样，路由准确率 90% 不代表用户体验好，真正要看的是答案采纳率和追问率。

第三，留出验证预算。做代理模型的人容易陷入“模型够准了就不用验证”的思维陷阱。实际上不管模型多准，最终方案都必须用真实手段验证。我在项目排期时，会把总预算的 20% 留作验证用，这个比例看起来浪费，但比最后发现方案不可行要划算得多。

第四，日志先于优化。AI 代理助手这一侧，我最大的教训是初期没有把路由决策的日志打全，导致后来想优化时无据可依，只能重新埋点再等两周数据。现在我的做法是系统上线第一天就把全链路日志打通，哪怕优化暂时不做。数据攒着，机会来了随时能用。

第五，别迷信单一方案。我试过用神经网络代理完全替代克里金，结果是样本少的时候效果差一大截；也试过把 AI 助手的全部请求都路由给本地模型，结果复杂任务的完成率掉了三成。最后落地的方案都是混合的：工程侧是克里金加神经网络双模型，用交叉验证误差加权融合；AI 侧是规则加级联，本地和远端都留着。混合方案调起来麻烦，但鲁棒性明显更好。

最后再分享一个小技巧。做 AI 代理助手的时候，我在每次请求的返回里加了一个隐藏字段，记录这次走的是哪条路由、置信度是多少。这个字段不展示给用户，但在前端做“重新生成”按钮时特别有用——用户点重新生成，我就强制走一次更高级别的模型。这样既不浪费日常成本，又给了用户一个兜底手段，追问率降了不少。这个设计后来被我们内部好几个项目抄了过去，算是我个人比较得意的一个小改动。