智能体运行框架设计：选择合适的模型

模型路由是运营控制问题，而不是排行榜竞赛。隐私与数据驻留要求首先确定允许使用的模型池；任务完成情况与输出质量决定其中哪些方案可行；之后才应优化 token 用量、延迟和成本。本地模型可以有效，但通常需要更充分的任务拆解、检索和确定性验证。

智能体运行框架才是生产单元

企业智能体不是一个配上很长系统提示词的模型，而是一套运行框架：请求接收、上下文组装、策略关卡、模型执行、工具访问、状态管理、验证、重试逻辑、可观测性和升级处理。模型只是这套系统中一个可替换的组件。

脱离运行框架进行模型比较，往往无法预测生产环境中的表现。模型可能在基准测试中表现出色，却难以适应企业的格式、权限、术语或工作流。另一个模型在开放式聊天中看似较弱，但当任务经过拆解、证据得到检索、输出按确定性约束检查时，却能可靠运行。

因此，选择“最佳模型”并不是恰当的抽象方式。我们要为明确的任务选择符合准入要求的执行路径。这条路径可能使用一个模型、多次专门调用、本地模型、托管模型，甚至完全不用模型。只有任务达到经验证的业务状态，执行才算成功。

架构应明确支持这种可替换性。基于线程的 AI 运营层将用户上下文与执行器分离，使模型更换时，路由、状态、授权和验证机制保持稳定。

第一关：隐私、数据驻留与合同准入

路由在质量测试之前就开始了。首先要问：模型端点是否获准接收这些数据并执行该操作？

我们为每类任务建立准入档案，涵盖：

数据分类，以及是否包含个人、机密、受监管或受出口管制的信息；
规定的处理与存储区域；
数据保留、日志记录、训练用途和删除条款；
次级数据处理方及跨境传输限制；
加密、身份和访问控制要求；
审计日志和事件通知义务；
工具是否可以读取或修改生产系统；
检索到的文档是否可以离开受控环境。

这些是路由约束，而不是上线后补上的一段政策说明。如果任务包含受限数据，路由器必须排除不满足准入档案的端点。脱敏有时能产生限制较少的衍生任务，但脱敏过程本身必须可靠、有日志记录，并针对涉及的格式进行测试。只替换姓名，却留下唯一账户编号或具有商业敏感性的事实组合，并不是真正的匿名化。

数据驻留也适用于外围运行框架。即使提示词发往获批的区域端点，只要追踪记录、向量索引、错误日志或人工审核队列存储在其他地方，问题仍未解决。我们检查完整数据路径：请求接收、临时文件、检索、推理、工具结果、可观测性、备份和支持人员访问。

这一关确定允许使用的路线，而不决定哪条路线最优。本地模型对某类任务可能是必选项，对另一类是可选项，对第三类则可能不适用。政策缩小选择范围，证据完成最终筛选。

第二关：先看任务成功，再看质量

在符合准入要求的模型池中，首先评估任务是否成功。工作流是否达到预期状态？研究任务可能要求答案有证据支持，且引用可查证；提取任务可能要求记录符合数据模式，并关联来源片段；运营操作则可能要求有效的模拟执行计划、经批准的修改和成功的回读核验。

任务成功的范围比回答质量更广。回答即使文笔出色，只要无法解析、引用不可获取的证据，或调用禁用工具，执行就算失败。反过来，简短的输出只要可靠完成流程，也可以是成功的。

我们用有代表性的实际工作构建评测集。每个案例包含输入、允许使用的证据、预期状态转换、硬性失败条件和评分标准。评测集应覆盖：

占任务量大多数的常见案例；
接近政策或质量阈值的边界案例；
缺失、过期、重复或相互矛盾的输入；
工具和依赖故障；
提示词注入或不可信内容的攻击尝试；
必须拒绝执行或升级处理的案例；
相关场景中的多语言或格式变化。

我们先评估硬性约束，再评估主观偏好。数据模式有效性、工具选择正确性、授权合规性、引用是否有证据支持，以及是否按要求拒绝执行，均采用通过或失败的判定。语义完整性、清晰度和实用性可以按标准评分。更流畅的文笔不能弥补经验证任务完成率的下降。

领域专用智能体技能有助于稳定评测，因为流程和必需检查被明确记录为可复用资料，而不必在每次对话中重新摸索。

第三关：token 用量、延迟与成本

只有路线满足任务成功和质量边界后，才优化效率。相关单位是每个经验证任务的成本，而不是每个输入 token 的价格。

更便宜的模型如果需要重试、审核或下游纠正，总成本可能更高。首次响应很快的模型，如果运行框架反复修复无效输出，端到端延迟仍可能很差。更大的上下文窗口可能诱使团队不加筛选地加载内容，增加成本和出错面。

我们衡量：

维度	运行框架层面的指标
成功	符合条件的尝试中，经验证完成任务的比例
质量	首次通过率、缺陷严重性和缺陷漏检率
token 用量	每次经验证完成任务的输入、缓存输入、输出和重试 token 用量
延迟	从触发到经验证状态的耗时中位数和尾部耗时
成本	每次经验证完成任务的推理、检索、工具、审核和返工成本
稳定性	跨时间、格式和任务类别的表现波动

归一化指数让内部比较更易理解，同时避免制造虚假的精确感。将当前获批路线的质量调整后成本和端到端延迟设为 Baseline = 100。只有较低的成本指数没有掩盖更低的任务成功率、更高的异常负载或更多的审核时间，候选方案才有价值。即使对外报告使用归一化数值，我们仍保留底层计数和定义供审计使用。

优化随后就能有的放矢。提示词缓存可减少反复输入的政策上下文；更短的检索片段可减少干扰；并行读取工具数据可缩短延迟；较小的模型可处理分类，而更强的路线处理存在歧义的综合分析；确定性代码甚至可以完全省去一次推理调用。

路由任务，而不是用户

按部门静态路由会浪费能力和资金。同一个人可能请求公开信息摘要、机密信息比较、对账和生产写入，而这些任务类别的准入、质量和操作权限要求各不相同。

我们依据任务封装中的信息进行路由：

task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batch

路由器应尽可能采用确定性逻辑。数据分类、数据驻留和操作权限属于政策决策，不应依赖模型猜测请求是否“看起来敏感”。分类器可以协助接收请求，但存在不确定性时，必须选择更安全的路线，或就具体问题请求澄清。

随后在获准分支内选择模型。路线记录包含政策版本、模型版本、提示词或技能版本、检索证据标识、工具调用、验证器结果和最终状态。这份执行回执让故障可诊断、比较可复现。

为什么本地模型需要不同的运行框架

讨论本地推理时，人们常以为只需把相同提示词从托管端点搬到本地硬件，实际很少如此。本地模型可以为范围明确的任务提供较强的隐私控制、可预测的边际成本、离线运行和低延迟。但与当时最强的托管方案相比，它们在指令遵循、工具选择、长上下文可靠性或多语言一致性方面也可能较弱。

正确做法不是掩盖这些差异，而是调整运行框架。

更彻底地拆解任务

每次只让模型执行一个范围明确的转换。将文档选择、提取、分类、撰写和验证分开。每个阶段都应有范围严格限定的输入与输出契约。拆解减少同时需要遵循的指令数量，并建立检查点，让确定性控制能阻止错误继续传播。

本地路线可以先识别相关章节，再按数据模式提取论断，随后将每项论断映射到来源片段，最后只依据已通过验收的论断起草。相比一个大型提示词，这需要更多编排，但更易评估和修复。

检索更少，但质量更高

把整个代码仓库或文档集合塞进上下文并不叫检索，而是把筛选问题转交给模型。本地路线受益于结构化索引、元数据过滤、时效性约束和简短的证据包。检索应返回来源标识及片段，让下游检查能确认答案有据可依。

构建带检索和网络搜索的本地 AI 助手中的实践模式说明，本地推理依赖外围工具与证据层，而不只是模型记忆。

采用确定性验证

尽可能使用数据模式、解析器、允许列表、数据库约束、计算、策略引擎和回读核验。模型可以提出修改建议；代码则应确认必填字段存在、标识可解析、总额一致、权限允许该操作，以及操作后状态与获批计划相符。

对于无法采用确定性方法的语义检查，应使用评审标准和独立审核路径。不要让同一次调用生成、评分并批准自己的输出。如果使用模型评估器，应按人工判断校准，并使其处于最终授权边界之外。

级联、回退与拒绝执行

有用的路由器不会把每个符合条件的任务都交给最强模型。它可以采用级联：从已达到该任务类别验收边界的最低成本路线开始，再在出现可观察的失败时升级处理。

升级信号应具体明确：修复后数据模式仍无效、证据缺失、来源冲突、经校准的置信度低、工具不可用、触及政策边界，或验证器失败。token 数量本身不是质量信号。模型口头表示不确定也不是，除非这类表述已针对该任务进行校准。

回退必须保持语义一致。如果主路线因无法满足数据驻留要求而失败，回退路线不能忽视驻留要求。工具调用不可用时，纯聊天路线不能假装操作已经发生。证据集过期时，更强的模型也无法让它变得最新。

当任务契约要求升级处理时，拒绝执行就是成功结果。我们将“正确拒绝或升级处理”计入任务成功指标。否则，路由压力会奖励那些超出证据或权限范围尝试执行的系统。

状态、版本与可复现性

模型和端点会变化。即使模型名称不变，新版本、服务配置、系统提示词、检索索引、工具定义或政策也可能改变行为。运行框架必须对整个执行契约进行版本管理。

我们至少记录：

任务和政策版本；
模型提供商、端点区域和模型版本；
提示词、技能和工具数据模式的版本；
检索查询、来源 ID 和时效性时间戳；
采样和超时设置；
验证器版本及结果；
重试、回退和人工审核事件；
最终操作和回读核验证据。

运营可复现性来自输入、配置、外部操作和验证证据，而不是不受限制地保留思维链。敏感追踪记录应遵守企业的数据最小化和保留规则。

调优项目专用智能体所述的流程纪律同样适用：只有变更、并发和故障模式可观测，持久工作区与可复用流程才有价值。

实用的选择流程

我们采用分阶段选择流程：

定义任务类别。将提取、综合分析、规划、操作和验证分开，不要平均成一个分数。
应用准入关卡。排除不满足隐私、数据驻留、合同或操作权限要求的路线。
构建评测集。使用有代表性、边界、对抗和必须升级处理的案例，并固定证据集。
在真实运行框架中运行路线。包括检索、工具、超时、重试和验证器。
检查硬性失败。拒绝违反数据模式、证据、授权或拒绝执行要求的路线。
评估任务成功和质量。同时审核平均表现及严重缺陷的尾部情况。
衡量总效率。比较每次经验证完成任务的 token 用量、延迟、推理成本、审核时间、重试和返工。
以影子模式或模拟执行试点。观察实际需求变化，同时禁止未经验证的写入。
按任务类别批准。记录路线、限制、回退方案和决策到期日。
持续重新评估。模型变更、表现漂移、新数据类别、重复异常或价格重大变化均应触发复审。

产出是一套有版本管理的路由政策，而不是永久排行榜。

决策规则

决策顺序是负责任的模型路由的核心。隐私、数据驻留和合同关卡决定什么被允许；经验证的任务成功和质量决定什么具备能力；token 用量、延迟和总成本决定剩余路线中什么更高效。

颠倒顺序会造成可预见的失败。成本优先的路由会把敏感任务交给不符合准入要求的端点，或让低质量输出陷入昂贵的审核循环。模型优先的路由会围绕偏好的供应商调整流程。基准测试优先的路由则会优化企业可能根本不执行的任务。

我们设计运行框架，让模型可以更换，而政策、状态和证据不随之瓦解。托管模型、本地模型和确定性服务各有用途。正确选择是满足准入要求、能完成明确任务、保持在质量边界内并证明结果的最小系统。