夜雨聆风选型做完了，下一步不是写代码——是验证你选的到底对不对
本篇你将学到：
用 Dify 搭原型验证模型选型——实测对比 Qwen-Max、DeepSeek-V3、Qwen2.5-7B
设计三个验证实验：模型准确率对比、Token 消耗实测、编排边界测试
验证结论反推方案修正——模型换不换、Token 预算调不调、Prompt 怎么改
Dify → LangChain → Agent SDK 工具选型框架——先验证对，再选工具做深
前四篇做完了一件事：MumuMall 智能客服从一句"加个 AI 客服"，变成了 Spec 三层 + 模型选型 + 成本预估 + 云端架构图。
这时候最容易踩的坑是什么？方案评审通过了，直接让开发团队开始写代码。两周后交付，发现 Qwen2.5-7B 在生鲜退换货场景下准确率根本达不到预期的 90%。Token 预估也比测算的多了一倍。编排逻辑里意图判断路由错了——用户说"我的虾到了但死了"，意图判断给了"知识咨询"而不是"转人工"。
问题不是方案写错了。问题是写完方案没有验证。
传统架构师验证方案靠评审——一群人坐会议室里盯着你的架构图，提问题。评审能发现逻辑漏洞，但发现不了"这个模型在你的 FAQ 上准确率到底多少"和"Token 消耗是不是真的和你预估的一样"。
这篇就做一件事：选型做完了，先用最小的成本验证它。验证完了再决定要不要进生产。
不是教你怎么用 Dify，是用 Dify 验证你的方案
Dify 是用来做什么的？很多人以为它是 Agent 开发平台。架构师不这么看。
架构师眼里，Dify 是方案验证工具。验证四件事：
第一，模型选型对不对。你在第四篇选了 Qwen-Max 做主模型、DeepSeek-V3 做备选——但在 MumuMall 的真实 FAQ 上，这两个模型到底表现差多少？用 Dify 接两个模型，同一批 FAQ 问题跑一遍，看实际准确率和响应时间。
第二，Token 预估准不准。你在第四篇算了 MumuMall 日均 5000 次咨询的 Token 消耗——但那是在"假设每次对话 3 轮、每轮 1500 Token"的前提下。真实对话中，用户可能追问 5 轮，每轮上下文不断膨胀。Dify 跑 50 条真实对话，看实际 Token 消耗是不是在你预估的 1.5 倍以内。
第三，知识库够不够。MumuMall 的产品文档、FAQ、退换货政策已经上传到 OSS 了。但用户问的不一定是文档里有标准答案的问题。比如"我买的虾到了但死了"，这个问题需要 RAG 检索生鲜售后政策 + LLM 判断严重程度 + 可能直接转人工——知识库检索到的文档片段能不能支撑这个链路？检索命中率多少？
第四，编排逻辑通不通。你在架构图里画了意图判断 → 知识检索/工单操作/转人工三条分支。但用户输入"我的订单 TN-001 的物流怎么还没更新，我要退款"——意图判断应该走工单查询还是转人工？真实测试才能发现边界情况。
这四件事，Dify 10 分钟搭好原型就能验证。不用等开发排期。
验证实验：用 Dify 快速跑一轮——方法论
注意：以下数据不是真实跑出来的，目的是介绍评测验证方法。实际项目中请用自己的数据照此方法验证。
验证实验的目标不是"拿一个准确率数字"，而是回答三个问题：
这么多模型选哪个？（模型对比）
预估的费用靠不靠谱？（Token 实测）
编排逻辑在边界情况会不会翻车？（编排边界测试）
下面逐一介绍这三个实验怎么做。
实验一：模型对比——如何客观比较候选模型
场景覆盖：选取若干条有代表性的客服问题，覆盖主要业务场景（如退换货政策咨询、物流状态查询、促销规则、生鲜售后、投诉）。场景覆盖越全，结论越有参考价值。
对比维度：在 Dify 里对同一个 Workflow 切换不同模型（如 Qwen-Max、DeepSeek-V3、自建开源模型），同一批问题各跑一轮。对比维度至少包括：
维度 | 说明 | 为什么重要 |
准确率 | 回答是否正确、完整 | 核心指标——达不到业务底线直接淘汰 |
响应延迟 | 端到端首Token时间 + 完整回复时间 | 客服场景对延迟敏感，用户等不了太久 |
单次Token消耗 | 平均每次对话消耗的 Token 数 | 决定成本，注意区分输入Token和输出Token的计费差异 |
长尾场景表现 | 低频但关键的问题能不能答对 | 促销规则、生鲜售后等长尾场景往往才是用户投诉来源 |
结论分析方法：
不是比谁的跑分高，而是找业务目标下的最优性价比。准确率差不多时，成本差异可能是数量级的
自建开源模型要同时评估：部署成本（GPU机器/云资源）、运维人力、是否可以接受更长的响应延迟
核心原则：不能只看公开 Benchmark，必须在自己的数据上验证。这是架构师选型区别于"网上看测评"的分水岭
实验二：Token 消耗实测——用采样对话反推真实成本
为什么需要实测：成本预估的公式通常是 日均咨询量 × 平均轮次 × 单轮 Token × 单价，但三个乘数都可能和实际偏离——简单的 FAQ 可能比预估更省 Token，复杂投诉和售后场景的 Token 消耗可能轻松翻倍。不实测就直接给客户报价，上线后超预算谁来负责？
操作方法：
按业务比例抽样：根据各场景的咨询占比（如简单 FAQ 占大头、复杂投诉占小头），抽若干条典型对话在 Dify 上实际跑完，记录每个场景的单次 Token 消耗
分场景统计：按正常场景（简单 FAQ）、复杂场景（投诉/售后）、多轮追问场景分别统计实测 Token，计算加权平均值
与预估值对比：找出偏差最大的场景，分析是 Prompt 太长、上下文膨胀、还是模型输出冗余
修正报价模型：用加权实测值替换预估公式中的单轮 Token 数，重新计算月费。如果偏差较大，及时调整给客户的报价
常见的坑：
简单查询的 Token 通常低于预估，但占大头的场景偏低掩盖不了长尾场景的偏高
多轮对话的上下文累积效应很容易被低估——每一轮都要把历史对话带进去
RAG 召回的知识片段也会计入输入 Token，检索结果越长越贵
实验三：编排边界测试——找出意图路由的翻车现场
编排逻辑在正常 case 下通常都能跑通，真正出问题的是边界情况。比如：
"我的虾到了但死了，我要退款"——走知识检索（给退换货政策）还是转人工（生鲜售后强情绪升级）？
"我昨天买的今天降价了能退差价吗"——走知识检索（搜索价格保护政策）还是转人工？
操作方法：
构造边界用例集：根据 Spec 中写的边界条件，针对性地构造用户的模糊输入。重点覆盖：多意图叠加、情绪化表达、业务规则边缘
逐条记录路由结果：对比预期路由和实际路由，标记所有偏差
偏差归因：
是模型没理解？→ 可能是基础能力不够
是 Prompt 没覆盖？→ Spec 写了但 Prompt 没同步更新，这是最常见的翻车原因
是编排逻辑本身有歧义？→ 两个分支都能算对，需要重新定义边界
关键认知：边界测试不通过不一定说明模型不行，往往暴露的是 Spec 到 Prompt 的翻译损耗——架构师在 Spec 里写清楚的规则，工程师写 Prompt 时漏掉了，或者写得不够明确。这是验证流程最有价值的地方。
验证完了，下一步选什么工具
经过 Dify 验证，你会得到：
模型选型结论（哪个模型/哪个规格在准确率和成本之间达到最佳平衡）
Token 消耗的修正系数（在预估基础上该上调还是下调）
编排 Prompt 的优化清单（哪些边界场景需要补强）
修正完了，团队准备开始写代码。这时第二个问题来了——用什么工具写？
Dify 验证很快，但生产环境不一定用 Dify。四种工具的选型框架：
工具 | 适合阶段 | 选型逻辑 |
Dify | 原型验证 + MVP | 10 分钟搭原型、改动即时生效。但流量上来后 Workflow 编排灵活度有限——自定义 Tool 的调试和版本管理偏弱 |
LangChain | 深度定制 | 需要自定义 RAG 策略（不同品类不同知识库）、自定义 Memory 策略（用户画像驱动的个性化回答）时，拖拽式搞不定，需要切 LangChain |
Agent SDK（Claude/OpenAI） | 标准化生产 | 如果主模型选的是 Claude 或 GPT，直接用官方 SDK 做 Agent 编排，稳定性最好。但国产模型路线暂不适用 |
Coze/HiAgent/百炼 | 多平台分发 | 客服要同时接入微信、抖音、Web 时，多平台一键发布有优势。单渠道不需要 |
通用推荐路径：Dify 做原型验证（当前阶段）→ LangChain / 官方 SDK 做生产落地。不一开始就上 LangChain——Dify 验证的改动成本是分钟级，LangChain 是小时级。先验证对，再选工具做深。
架构师在方案设计完的第一步不是写代码，是验证。
验证四件事：模型在你的数据上准确率多少、Token 消耗和预估差多少、知识库检索命中率够不够、编排边界会不会误判。
验证结论要改方案：模型选型可能换、Token 预估要上调、Prompt 要补边界规则。这不是方案失败——是方案变精确了。
选工具不是越强越好：Dify 验证快但生产受限，LangChain 灵活但改动慢。先验证再选工具——用 Dify 把方案跑对了，再决定用什么跑生产。
本篇产出：Dify 验证报告（模型对比 + Token 实测 + 编排边界测试）+ MumuMall 方案修正 + 工具选型推荐。
下一篇：方案验证完了，该上生产了。一个 Agent 够不够？什么时候该拆成多个？部署到阿里云——ECS 选什么规格、弹性伸缩配什么策略、高可用怎么验证？这些不是运维决定的，是架构师决定的。
