企业模型升级不应“推倒重来”：用路由、评测与回退保持业务应用可演进

在企业 AI 项目中，最常见的技术债之一，是将某个模型的名称、提示词风格、工具参数和业务规则混在同一套实现中。

短期内上线很快，长期却很被动。新模型出现时，团队无法判断替换范围，只能重新调提示词、重测知识库、重做工具调用，最终宁愿不升级。

企业不想被单一大模型绑定，应该从应用可演进性出发，而不是从“多接几个模型”出发。

今日实际搭建的“企业模型路由与升级建议助手”，就是一个围绕该问题的最小演示。

1. Demo 做了什么，没有做什么

该智能体已在好易创建、保存编排并非公开发布。

它接收业务场景、任务类型、质量/时延要求、数据边界和回退要求，输出模型路由和升级验证草案。

它没有做以下事情：

• 不连接企业真实模型网关；
• 不读取客户知识库或业务数据；
• 不自动调整生产模型；
• 不修改提示词、MCP 配置或密钥；
• 不作出模型效果、成本或合规保证。

这些边界让 Demo 保持在“方案规划”层，而不是伪装成已完成的生产治理系统。

2. 最小编排为什么只有两个节点？

图结构为：

开始节点
  -> 模型路由规划与升级校验

工程上，节点数越多不一定越好。当前重点是验证路由建议的逻辑，因此采用单一核心节点，并在内部明确 Planner、Generator、Evaluator 的职责。

• Planner：分类业务任务，识别质量、时延、数据和回退约束。
• Generator：生成应用解耦、候选路由、评测、灰度与回退建议。
• Evaluator：检查是否将候选写成生产事实，是否遗漏测试、回退和人工确认，是否虚构模型表现。

核心节点配置了 deepseek-v4-pro，它来自当前账号读取到的可用模型列表。选择它是为了处理多约束结构化分析，不代表实际企业应用必须使用该模型。

3. 先分层，后路由

可将企业应用的模型使用方式分成以下层次：

从这个角度看，模型路由不只是“轻量模型和强模型之间切换”，而是要让任务、数据、工具和风险边界匹配。

4. 要迁移的不只是模型

很多团队替换模型时，遗漏了四类依赖：

• 提示词：不同模型对指令结构和上下文长度的表现不同；
• 知识库：模型改变后仍需验证召回、引用和回答一致性；
• MCP/API：工具调用参数、异常处理和重试策略需要复测；
• 用户体验：输出格式、时延、错误提示和会话连续性也属于验收范围。

因此，建议为每个关键应用保存测试资产：

正常问题
资料缺失问题
冲突资料问题
越界问题
工具参数错误问题
高风险动作问题

只有把这些样本保留下来，新模型才有可比较的业务基线。

5. 发布和回退应成为标准动作

模型升级的流程建议固定为：

候选模型登记
-> 测试环境验证
-> 结果评审
-> 小流量灰度
-> 管理员确认
-> 正式发布
-> 运行监控
-> 异常回退

任何一步都不建议由智能体自己直接执行。尤其是涉及人事、审批、合同、财务、医疗等场景，模型输出应保持在辅助分析、材料草稿和风险提示范围内。

6. 本次测试情况

本次正常问题使用“员工制度问答和材料初稿应用，希望未来升级模型但不重做知识库和提示词”的场景。

草稿调试已发起，但流式对话没有在当前等待窗口内返回结果。因此当前只能确认编排与发布完成，不能确认对话输出验收通过。越界测试也待平台对话链路恢复后补做。

模型不断更新是常态。企业真正需要的是一种不依赖某个模型长期不变的应用结构：数据和能力资产独立、测试标准保留、升级过程可验证、生产变更可回退。