深度专题七技术选型决策工程:七步法与决策树

专题定位:FDE 在 Design 阶段最频繁的决策就是"选什么"。本专题把技术选型从"凭感觉"变成"七步法 + 决策树"的工程化过程,覆盖模型、RAG、Agent、向量库、推理、部署的选型逻辑。

一、选型的本质:约束下的权衡

技术选型没有"最优",只有"在客户真实约束下的最合适"。

FDE 选型时面对的约束:

合规:数据能否出境、信创要求;
算力:几张什么卡;
预算:许可费、运维成本;
延迟:实时还是准实时;
团队能力:客户/自己团队能维护什么;
生态:有没有社区、文档、招得到人;
演进:未来能不能扩展。

选型第一原则:不选"最强最新",选"足够好、能落地、可维护、有生态"。

二、七步选型法

第一步:明确需求与约束

要解决什么业务问题(北极星);
硬约束清单(合规/算力/预算/延迟)。

第二步:列出候选

至少 2—3 个候选方案;
不要只看一个(避免先入为主)。

第三步:定义评估维度

功能满足度、性能、成本、合规、生态、可维护性、风险。

第四步:打分/加权

用决策矩阵,各维度打分加权;
量化对比,而非拍脑袋。

第五步:PoC 验证

对 top 候选做小规模 PoC;
用真实数据验证关键假设。

第六步:风险评估

每个候选的关键风险;
准备回退方案。

第七步:决策与记录

选定方案;
记录决策理由(ADR,Architecture Decision Record),未来可追溯。

可照抄(选型决策矩阵模板):
候选功能性能成本合规生态风险加权总分
方案A 9 8 7 10 9 低 8.5
方案B 8 9 9 8 7 中 8.2

候选	功能	性能	成本	合规	生态	风险	加权总分
方案A	9	8	7	10	9	低	8.5
方案B	8	9	9	8	7	中	8.2

三、模型选型决策树

数据能否出境?
├─ 否 → 国产/开源私有化
│   ├─ 中文为主 → Qwen/DeepSeek/GLM
│   └─ 算力足 → 72B;算力紧 → 7B/14B + 量化
└─ 是 → 闭源 API(GPT/Claude/Gemini)或开源
需要微调?
├─ 是 → 选有完整微调工具链的(Qwen/Llama)
└─ 否 → 直接用

通用能力 vs 成本:
├─ 顶尖能力 → 闭源大模型
├─ 性价比 → 中等开源 + 量化
└─ 边缘/低成本 → 小模型 + 量化

四、RAG 选型决策树

文档量级?
├─ 小(<10万) → pgvector(已有PG)/Qdrant
├─ 中(10万—千万) → Milvus/Qdrant/Weaviate
└─ 大(亿级) → Milvus 集群/专业方案

关系复杂(多跳)?
├─ 是 → GraphRAG(Neo4j)
└─ 否 → 向量 RAG

中文?
├─ 是 → bge 嵌入 + 中文向量库(Milvus)
└─ 否 → OpenAI embed + 通用库

准确度要求高?
├─ 是 → 混合检索 + 重排
└─ 一般 → 纯向量

五、Agent 框架选型决策树

生产级 / 需要状态审计?
├─ 是 → LangGraph
└─ 否(原型) → CrewAI

已绑定生态?
├─ OpenAI → OpenAI Agents SDK
├─ Google → Google ADK
├─ 微软 → Microsoft Agent Framework
└─ JS 栈 → Mastra

重检索?
└─ LlamaIndex Workflows

需要连接企业系统?
└─ 必须用 MCP

六、向量库选型对比

向量库	适用	优势	劣势
Milvus/Zilliz	大规模、生产、信创	国产、大规模、生态	运维复杂
Qdrant	中小规模、易部署	Rust 高性能、易用	超大规模稍弱
Weaviate	多模态、功能全	功能丰富	资源占用
pgvector	已有 PG、小数据	零额外组件	规模有限
ES/OpenSearch	混合检索、已有 ES	向量+关键词	向量性能不如专用

七、推理框架选型

框架	适用	优势
vLLM	通用生产	事实标准、生态、PagedAttention
TGI	HF 生态	易用
TensorRT-LLM	极致性能、全 NV	性能最强
SGLang	结构化生成	缓存、结构化

八、部署形态选型

数据能上云 & 流量波动大?
├─ 是 → 公有云弹性
└─ 否 → 私有化
强合规(政企/金融)?
├─ 是 → 私有化 + 信创
└─ 否 → 标准
边缘低延迟(工厂/门店)?
├─ 是 → 边缘部署
└─ 否 → 中心化

九、工具链选型实战:Coze vs Dify vs Trae

这是中国市场 FDE 常遇到的选型(低代码 AI 平台)。

Coze(扣子,字节)

低代码 Agent/工作流搭建;
适合:快速原型、非技术用户;
优势:字节生态、中文友好;
劣势:定制化、私有化受限。

Dify(开源)

开源 LLM 应用开发平台;
适合:需要私有化、定制的企业;
优势:开源、可私有化、灵活;
劣势:需自运维。

Trae(字节,IDE 式)

AI 原生 IDE/开发;
适合:开发者快速构建;
优势:开发体验好;
劣势:偏开发侧。

选型:非技术用户快速搭 → Coze;企业私有化 → Dify;开发者 → Trae。三者不互斥,可组合。

十、选型的反模式

反模式一:追新

选最新最酷的,不顾成熟度;
解:优先成熟有生态的。

反模式二:单点依赖

选了一个没有替代的,被绑架;
解:评估替代方案、抽象接口。

反模式三:过度设计

一开始就上最复杂方案;
解:从 MVD 开始,演进。

反模式四:忽视团队能力

选了团队维护不了的;
解:考虑可维护性。

反模式五:不记录决策

为什么这么选,没人记得;
解:写 ADR。

十一、选型清单模板(给 FDE)

每次选型,FDE 填一张:

业务需求与北极星;
硬约束(合规/算力/预算/延迟);
候选方案(≥2);
评估维度与打分;
PoC 结果;
风险与回退;
决策与 ADR。

本专题小结

选型本质=约束下权衡,不选最强选最合适;
七步法:需求→候选→维度→打分→PoC→风险→决策记录;
模型选型树:出境→国产/开源,中文→Qwen/DeepSeek/GLM,算力→规模+量化;
RAG 选型树:量级→向量库,关系→GraphRAG,中文→bge,准确→混合+重排;
Agent 框架树:生产→LangGraph,原型→CrewAI,生态→官方,企业系统→MCP;
向量库:Milvus(大规模/信创)/Qdrant/pgvector/ES;
推理:vLLM 通用,TensorRT-LLM 极致;
部署:云/私有/边缘/信创;
工具链:Coze(低代码)/Dify(开源私有化)/Trae(开发);
反模式:追新/单点/过度/忽视维护/不记录。

本专题来源😮'Reilly《AI Agents Stack 2026》、Milvus/Qdrant/LangGraph 文档、用户库《FDE工具链评测》《fde-delivery 80-tech-selection》、本书第 9 章。

一、选型的本质:约束下的权衡 ​

二、七步选型法 ​

三、模型选型决策树 ​

四、RAG 选型决策树 ​

五、Agent 框架选型决策树 ​

六、向量库选型对比 ​

七、推理框架选型 ​

八、部署形态选型 ​

九、工具链选型实战:Coze vs Dify vs Trae ​

十、选型的反模式 ​

十一、选型清单模板(给 FDE) ​

本专题小结 ​