主题
附录 02 工具选型矩阵
本附录的目标不是给出唯一正确答案，而是提供一种实用的选型思路：当你在做 AI Agent 项目时，如何从“看起来都能用”的一堆工具中，选出当前阶段最合适的一组，而不是一开始就把技术栈堆得过满。
1. 选型先看阶段，不要先看热度
同一个工具，在不同阶段的价值完全不同。 建议先明确你当前处于哪一阶段：
- 学习验证阶段：优先简单、快跑通。
- MVP 阶段：优先可解释、可调试、可演示。
- 工程化阶段：优先可观测、可治理、可扩展。
- 上线阶段：优先稳定性、权限控制、成本与运维能力。
如果阶段判断不清，常见后果就是：
- Demo 阶段用了过重的架构。
- 上线阶段还在用临时脚本拼接。
2. 模型选型矩阵
2.1 选型维度
建议至少比较以下维度：
- 推理能力。
- 成本。
- 延迟。
- 上下文窗口。
- 结构化输出稳定性。
- 工具调用支持度。
- 多语言表现。
- 企业接入与合规要求。
2.2 什么时候选更强模型
适合使用更强模型的场景：
- 复杂推理、多步决策。
- 长文综合。
- 高价值关键链路。
- 对输出质量和稳定性要求很高。
2.3 什么时候选轻量模型
适合使用轻量模型的场景：
- 分类、路由、标签提取。
- 格式修复。
- 低风险预处理。
- 高频但价值密度没那么高的请求。
2.4 什么时候选自托管模型
以下场景建议优先考虑自托管模型：
- 数据合规：金融、医疗、政务等行业，数据不允许出域，或需满足等保、HIPAA 等合规要求。
- 离线 / 内网环境：部署环境无法访问外部网络，或网络延迟不可控。
- 成本控制：调用频率高（日均 >10 万次），按 token 付费的云端方案成本远超自建 GPU 集群的摊销成本。
- 深度定制：需要微调模型以适配垂直领域术语、输出风格或特定任务。
决策矩阵
| 场景 | 云端 API | 自托管 | 混合方案 |
|---|---|---|---|
| 快速验证 / Demo | ✅ 首选 | ❌ 过重 | — |
| 数据不出域（合规强制） | ❌ 不满足 | ✅ 首选 | — |
| 内网 / 离线部署 | ❌ 不可用 | ✅ 唯一选项 | — |
| 高频调用（>10 万次/天） | ⚠️ 成本高 | ✅ 成本优 | ✅ 分流 |
| 需要微调 / 定制 | ⚠️ 部分支持 | ✅ 完全控制 | ✅ 主力自托管 + 云端兜底 |
| 多模型路由 | ✅ 丰富 | ⚠️ 需自建 | ✅ 灵活组合 |
风险提示
自托管不是"省钱银弹"，需要认真评估以下成本：
- 运维成本：GPU 驱动、CUDA 版本、模型服务的稳定性都需要专人维护。
- 硬件投入：推理卡（如 A10、L40S、RTX 4090）采购或租赁成本不低。
- 模型更新滞后：开源模型通常落后商业模型 3–6 个月，部分能力差距更大。
- Tool Calling 能力差距：自托管开源模型的函数调用 / 工具调用稳定性通常弱于 GPT-4o、Claude 等商业模型，需要更多 Prompt 工程和容错设计。
3. RAG 组件选型矩阵
3.1 向量库 / 检索层
比较维度建议包括：
- 接入复杂度。
- 查询性能。
- 混合检索支持度。
- 元数据过滤能力。
- 运维复杂度。
- 成本。
3.2 重排策略
选择重排前，先问：
- 当前问题真的是“召回不准”，还是“生成理解错”。
- 重排带来的收益是否值得额外成本和延迟。
适合加重排的情况：
- 文档量增长后召回噪音明显增多。
- 用户问题更复杂，需要更强语义区分。
3.3 文档处理链路
比较维度建议包括：
- 切片是否容易控制。
- 是否保留章节结构与元数据。
- 是否支持版本管理。
- 更新成本如何。
3.4 Embedding 模型选型
选择 Embedding 模型时，建议比较以下维度：
- 向量维度与检索性能。
- 多语言支持。
- 是否可本地部署。
- 推理速度与资源消耗。
常见 Embedding 模型对比
| 模型 | 类型 | 维度 | 多语言 | 本地部署 | 适用场景 |
|---|---|---|---|---|---|
| text-embedding-3-large | 商业 API | 3072 | ✅ | ❌ | 通用场景、快速接入 |
| text-embedding-3-small | 商业 API | 1536 | ✅ | ❌ | 成本敏感、轻量检索 |
| BGE-M3 | 开源 | 1024 | ✅（100+ 语言） | ✅ | 多语言 RAG、数据不出域 |
| Nomic-Embed-Text | 开源 | 768 | ⚠️ 英文为主 | ✅ | 英文场景、资源受限 |
| jina-embeddings-v3 | 开源 | 1024 | ✅ | ✅ | 长文档、多任务检索 |
| GTE-Qwen2 | 开源 | 1536 | ✅（中英） | ✅ | 中文场景、本地部署 |
自托管 Embedding 的优势在于：数据完全不出域、无按量付费、可根据领域数据微调。劣势在于：需要自行管理模型服务，且部分场景下效果不如商业模型。
4. 工作流与 Agent 框架选型矩阵
4.1 什么时候用轻量自建流程
适合：
- 节点很少。
- 分支不复杂。
- 团队规模小。
- 当前目标是先验证核心价值。
4.2 什么时候用专门工作流框架
适合：
- 节点数量增加。
- 需要状态机、重试、补偿、并发控制。
- 需要更强的可观测和回放能力。
- 团队需要多人协作维护流程。
4.3 什么时候用多 Agent 框架
适合：
- 角色拆分明确。
- 单 Agent 已经成为瓶颈。
- 团队能承担更高的调试和治理复杂度。
不适合：
- 只是为了“显得高级”。
- 还没把单 Agent、RAG 和 Eval 打稳。
5. 工具接入层选型矩阵
5.1 临时 API Wrapper
优点：上手快、适合 Demo。 缺点：复用差、边界治理弱、后期维护成本高。
5.2 标准化工具接入层
优点：契约统一、复用性高、权限边界更清晰。 缺点：前期设计成本更高。
5.3 MCP 风格接入
适合：
- 工具和资源种类变多。
- 多个 Agent 或多个工作流共享工具。
- 团队开始重视治理、审计和可调试性。
6. 观测与评测工具选型矩阵
6.1 观测工具关注点
建议比较：
- trace 能力。
- Prompt / 工具调用可视化。
- 指标聚合能力。
- 与现有日志系统集成成本。
- 脱敏与权限控制能力。
6.2 评测体系关注点
建议比较：
- 是否支持样本管理。
- 是否支持批量回归。
- 是否支持多指标对比。
- 是否方便和 CI / 发布流程集成。
7. 前端集成方案选型矩阵
7.1 聊天式界面
适合：
- 知识问答。
- 辅助咨询。
- 简单多轮澄清。
不适合：
- 多步骤执行任务。
- 高风险确认流程。
- 需要展示复杂状态机的系统。
7.2 任务面板 / 工作台
适合：
- 工作流系统。
- 自动化系统。
- 多节点任务跟踪。
- 人工审批与接管。
7.3 混合式界面
适合：
- 一部分需要自然语言交流。
- 一部分需要结构化进度和操作控制。
这通常是 Agent 产品更成熟的形态。
8. 自托管方案速查表
如果你决定走自托管路线，以下速查表帮助快速选型。
8.1 推理引擎对比
| 引擎 | 安装难度 | 推理性能 | GPU 要求 | OpenAI 兼容 API | 适合场景 |
|---|---|---|---|---|---|
| Ollama | ⭐ 极简 | 中等 | 可选（支持 CPU） | ✅ | 本地开发、快速验证 |
| vLLM | ⭐⭐⭐ 中等 | 高（PagedAttention） | 必须 | ✅ | 生产部署、高吞吐 |
| llama.cpp | ⭐⭐ 简单 | 中高（量化优化） | 可选（支持 CPU） | ⚠️ 需 server 模式 | 资源受限、边缘部署 |
| LocalAI | ⭐⭐ 简单 | 中等 | 可选 | ✅ | 多模型统一接口 |
8.2 开源 Embedding 引擎对比
| 模型 | 维度 | 多语言 | 推理速度 | 部署方式 |
|---|---|---|---|---|
| BGE-M3 | 1024 | ✅ 100+ 语言 | 中等 | HuggingFace / Ollama / TEI |
| Nomic-Embed-Text | 768 | ⚠️ 英文为主 | 快 | Ollama / HuggingFace |
| GTE-Qwen2 | 1536 | ✅ 中英 | 中等 | HuggingFace / vLLM |
8.3 向量库本地部署对比
| 向量库 | 安装难度 | 查询性能 | 扩展性 | JS/TS SDK | 适合场景 |
|---|---|---|---|---|---|
| ChromaDB | ⭐ 极简 | 中等 | 低 | ✅ | 本地开发、快速原型 |
| Qdrant | ⭐⭐ 简单 | 高 | 中 | ✅ | 中等规模生产环境 |
| Milvus Lite | ⭐⭐ 简单 | 高 | 高 | ⚠️ Python 优先 | 大规模向量检索 |
| pgvector | ⭐⭐ 简单 | 中高 | 中 | ✅（通过 pg 驱动） | 已有 PostgreSQL 的团队 |
8.4 API 代理层对比
| 方案 | 支持模型数 | 路由能力 | 负载均衡 | 适合场景 |
|---|---|---|---|---|
| Ollama 原生 | 中（主流开源） | ❌ 无 | ❌ 无 | 单机开发 |
| LiteLLM | 高（100+ 模型） | ✅ 灵活 | ✅ 支持 | 多模型统一网关 |
| LocalAI | 中 | ⚠️ 基础 | ⚠️ 基础 | 本地多模型服务 |
8.5 微调工具选型
| 工具 | 适合场景 | 硬件要求 | 难度 | 导出格式 |
|---|---|---|---|---|
| Unsloth | 消费级快速微调 | 8GB+ GPU | 低 | GGUF/HF/ONNX |
| Axolotl | 灵活配置、多方法支持 | 16GB+ GPU | 中 | HF/GGUF |
| LLaMA-Factory | 多模型多方法、WebUI | 8GB+ GPU | 低 | HF/GGUF |
| OpenAI Fine-tuning | 云端托管、零运维 | 无 | 最低 | 仅 OpenAI 使用 |
| Hugging Face TRL | 官方库、SFT/RLHF | 16GB+ GPU | 中高 | HF |
9. 一个实用的选型判断表
你可以在实际选型时使用下面的判断模板：
text
当前阶段：
目标场景：
最关键指标：效果 / 延迟 / 成本 / 稳定性 / 交付速度
团队规模：
运维能力：
安全要求：
是否需要人工确认：是 / 否
是否需要多系统集成：是 / 否
是否需要强观测能力：是 / 否
结论：当前最合适的技术组合是什么10. 常见选型错误
10.1 为了完整而完整
把热门组件都装上，不代表系统更强，只会让调试和维护成本上升。
10.2 为了快而长期偷债
Demo 阶段临时拼接可以接受，但如果到了工程化阶段还不收敛，就会形成很大技术债。
10.3 忽略团队真实能力
再好的栈，如果团队不会维护，也会变成负担。
10.4 只看效果，不看治理
真实业务里，权限、日志、评测、回滚和观测常常和效果同样重要。
10.5 前端方案选错交互范式
很多系统后端设计得不错，但因为前端仍然只有聊天框，导致整个产品看起来不可信、不可控。
11. 一页简版矩阵
学习验证阶段
- 模型：易接入、响应快为主。（自托管替代：Ollama + Qwen/Llama 本地跑通）
- RAG：先用最小链路。（自托管替代：ChromaDB + Nomic-Embed-Text）
- Agent：单 Agent 优先。
- 工具：少量 wrapper 即可。
- 前端：简单聊天界面。
MVP 阶段
- 模型：开始做轻重分层。（自托管替代：vLLM 部署主力模型 + Ollama 做轻量任务）
- RAG：加基础评测和引用。（自托管替代：Qdrant + BGE-M3）
- Agent：加入结构化输出和失败回退。
- 工具：开始整理契约。
- 前端：加入状态、引用和确认机制。
工程化阶段
- 模型：按任务路由。（自托管替代：LiteLLM 统一网关 + 多模型路由）
- RAG：优化召回、重排和压缩。（自托管替代：Qdrant/Milvus + BGE-M3 + BGE-Reranker）
- Workflow：节点化、可恢复。
- 工具：统一治理层。
- 观测：trace + 指标 + 发布门禁。
- 前端：任务工作台或混合式界面。
上线阶段
- 模型：成本、延迟、稳定性联动优化。（自托管替代：vLLM 集群 + LiteLLM 负载均衡）
- 工具：权限、审计、熔断、回退。
- 工作流：补偿、告警、回滚。
- 评测：回归门禁。
- 前端：人工接管、失败恢复、风险提示。
12. 面试表达
你可以这样讲：
“我做选型时不会从工具热度出发，而是先看阶段、场景、指标和团队能力。比如 Demo 阶段我会优先选能快速跑通且易调试的方案；到了工程化阶段，我会更关注观测、权限、回退和维护成本。这样技术栈不是越多越好，而是和当前目标匹配。”