平台与框架选型：自建、框架还是低代码
前面几页讲的是「怎么做」：管线怎么搭（RAG 与 Agent / RAG 进阶）、循环怎么编排（LangGraph）、界面怎么操作（GUI Agent）。这一页讲「用什么做」——LLM 应用的技术栈早就分层了，选型不是挑一个产品，而是在每一层各做一次决定，而且这些决定可以混搭。
一、先拆层：一次选型其实是六个决定
| 层 | 要决定什么 | 常见选项 |
|---|---|---|
| 模型层 | 自托管还是云 API；单模型还是多模型路由 | 云 API / vLLM、Ollama 自建 / 按任务分流到不同模型 |
| 编排层 | 业务逻辑用什么组织 | 裸代码 / LangChain / LangGraph / CrewAI / 低代码平台 |
| 工具与集成层 | 外部能力怎么接 | 原生 function calling / MCP / 自研 HTTP 工具 |
| 数据与检索层 | 知识放在哪、怎么查 | pgvector / Milvus 等向量库、关系库、对象存储（见 RAG 进阶） |
| 可观测与评测层 | 怎么知道它好不好 | Trace、评测集、CI 门禁（见 Agent 评测） |
| 交付层 | 用户从哪进来 | Web / IM / API / 嵌入现有业务系统 |
- 分层选型的核心好处：不必「全家桶式」站队。完全可以在低代码平台上做原型，同时把知识库放在自己的 PostgreSQL + pgvector 里，模型调用走云 API，Trace 用独立服务；
- 反过来，最容易踩的坑就是被某个平台的「一站式」宣传带跑，把模型、流程、数据、前端全绑在一处，半年后想换代价巨大（见第六节）。
二、五条路线放在一起看
| 路线 | 代表形态 | 适合 | 强项 | 短板 |
|---|---|---|---|---|
| 直接调 API | 裸 SDK + 自己写循环 | 单轮问答、简单流水线、验证阶段 | 依赖最少、行为完全可控、无框架负债 | 持久化/中断/可观测都要自己写 |
| 代码框架 | LangChain / LlamaIndex / LangGraph / CrewAI | 需要进 CI、需要精细控制的生产系统 | 可测试、可版本化、能力上限高 | 需要工程能力，抽象多、学习曲线陡 |
| 低代码 Agent 平台 | Dify / Coze / n8n / Flowise 一类 | 快速验证、非工程同学参与、流程相对标准 | 上手快，内置知识库、渠道与运维 | 复杂逻辑表达受限，深度定制天花板明显 |
| 云厂商托管 | 各家云的智能体平台 | 已深度使用该云、合规与运维要求高 | 与云上身份/网络/审计打通，运维负担小 | 生态绑定，跨云迁移成本高 |
| 直接买成品 | 各类开箱即用的 AI 功能 | 需求高度标准化（如通用客服） | 上线最快，无需研发投入 | 几乎不可定制，数据与体验受制于人 |
- 一句话判断：越靠近「核心业务差异化」的部分，越要掌握在自己手里（代码）；越靠近「通用管道」的部分，越可以用现成的（平台/托管）。
三、决策七问：把路线问出来
按顺序回答七个问题，路线基本就定了：
| # | 问题 | 指向 |
|---|---|---|
| 1 | 团队有没有服务端工程与运维能力？ | 没有 → 低代码/托管；有 → 可上代码框架 |
| 2 | 是否要求私有化部署 / 数据不出境？ | 是 → 排除纯 SaaS，选自托管或私有化版本 |
| 3 | 业务复杂度是哪种？ | 单轮问答 → 裸 API；固定流水线 → 框架或平台；需要循环/中断/恢复 → LangGraph 这类编排运行时 |
| 4 | 生命周期多长？ | 两周验证 → 低代码；三年演进 → 代码 + 自建数据与评测 |
| 5 | 要不要深度嵌入现有系统（权限、审计、单点登录）？ | 要 → 代码框架，平台很难吃到内部身份体系 |
| 6 | 成本结构怎么算？ | 人力贵 → 平台；调用量大 → 自建模型层/缓存更划算 |
| 7 | 能不能接受被锁定？ | 不能 → 见第六节的五条纪律 |
- 典型组合：「内部工具、要接公司权限、长生命周期」→ 代码框架 + 自建向量库 + 云 API；「市场活动页上的问答 Bot、两周上线」→ 低代码平台；「客服场景、客服团队自己维护话术」→ 低代码平台 + 人工审核。
四、低代码平台内部也有分工
别把「低代码平台」当成一个东西，三类平台解决的是不同问题：
| 类型 | 代表 | 定位 | 什么时候选它 |
|---|---|---|---|
| LLM 应用平台 | Dify 一类 | 面向 LLM 应用：知识库（RAG）、工作流编排、工具/插件、可私有化部署 | 要做「一个 AI 应用」，且需要知识库与渠道管理 |
| Bot / 对话平台 | Coze 一类 | 上手门槛最低，Bot 分发与 C 端渠道强，中文生态成熟 | 快速做一个对话机器人试水、重运营轻集成 |
| 通用自动化工具 | n8n 一类 | 自动化编排是主线，AI 只是其中一类节点；自托管友好 | 要把 AI 塞进已有的业务流程里（几十个系统对接） |
- 判断口径：要「AI 应用」选 LLM 应用平台；要「把 AI 嵌进现有自动化」选通用自动化工具；要「最快做个 Bot 看看反应」选 Bot 平台；
- 平台迭代极快、功能边界每个月都在变，具体能力请以各平台官方文档为准，别照抄二手对比文章。
五、代码框架内部怎么挑
| 框架 | 主要长项 | 注意 |
|---|---|---|
| LangChain | 生态最大、模型与工具集成最全、RAG 组件丰富 | 抽象层次多，学习曲线陡，版本变化快 |
| LangGraph | 编排运行时：持久执行、流式、人机协同、时间旅行 | 定位底层，不替你决定 Agent 架构（见 LangGraph） |
| LlamaIndex | 以数据与检索为中心，文档密集型应用顺手 | 偏数据侧，通用编排不是它的主线 |
| CrewAI / AutoGen 一类 | 多智能体角色协作，快速搭角色分工原型 | 多智能体成本高、调试难（见 Agent 架构通论） |
- 选型建议：先裸跑，再引入。 用裸 API 手写一遍循环，你会真正看清痛点在哪（是工具描述不行、还是缺持久化、还是缺可观测），然后针对性引入一个框架，而不是一上来就抱住全家桶；
- 警惕「为了用框架而用框架」：框架把细节藏起来，前期快，后期 debug 时你连状态在哪都不知道；
- 顺带一句：框架之间不是互斥的，LangChain 负责模型与工具集成、LangGraph 负责编排，是官方推荐的组合方式。
六、避免锁定的五条纪律
- 提示词与流程当作代码管理：放文件、进 Git、可版本化、可 diff。写进平台表单里的提示词不可回滚、不可评审；
- 业务逻辑不要写进平台专属节点：判断、校验、写库这类逻辑放在自己的服务里，平台只负责编排与展示；
- 模型调用收敛到一层适配器：所有调用走同一个封装，换模型/换供应商只改一处（顺带把重试、限流、成本计量也放这层）；
- 数据自己持有：文档源、切分结果、向量、评测集放在自己的存储里。知识库是 RAG 系统的核心资产，托管在别人那里等于把资产交出去；
- 评测集自己维护并定期回归：换模型、换平台、升版本时，它能告诉你效果到底是变好还是变差（见 Agent 评测 的门禁思路）。
七、成本：TCO 怎么看
| 成本项 | 容易被低估的点 |
|---|---|
| 模型调用 | 上下文越长越贵；Agent 循环是 N 次调用叠加（见 AI 工程化） |
| 嵌入与检索 | 一次性嵌入成本 + 向量库的常驻内存/存储 |
| 平台订阅 | 按席位/按调用量计费，规模上来后可能超过自建人力成本 |
| 开发与维护人力 | 真正的隐形大头：需求变更、效果调优、故障排查都是持续投入 |
| 基础设施 | GPU（自托管时）、向量库、数据库、可观测存储 |
| 迁移与重写 | 选错路线半年后推倒重来的代价，往往比当初省下的多得多 |
- 粗略判断：短期（< 3 个月）且人力紧张 → 平台订阅划算；长期且调用量大 → 自建的边际成本更低，但要预留运维人力；
- 别只比单价：把「两小时内能不能定位一次线上效果劣化」算进去，可观测欠账会以人力形式连本带利还回来。
八、常见失败模式
| 症状 | 根因 | 先查 |
|---|---|---|
| 平台上跑得挺好，一接内部系统就卡住 | 平台吃不到内部权限/网络 | 该不该把这块逻辑挪到自建服务 |
| 换模型后效果断崖 | 提示词硬编码了某个模型的偏好 | 有没有评测集能定位退化点 |
| 平台费用越涨越快 | 调用量与席位双增长 | 重新估算自建 vs 订阅的拐点 |
| 想换平台发现迁不走 | 提示词/知识库/流程全在平台里 | 复盘第六节的五条纪律 |
| 框架升级后大面积报错 | 抽象层变动 + 没有回归测试 | 关键链路是否有端到端测试 |
| 早期选了最重的方案 | 未验证需求就先建平台 | 回到第三问：生命周期与复杂度 |
| 多智能体跑起来很炫但很贵 | 每次 handoff 都是一次调用 | 是否能用固定流程替代 |
九、踩坑清单
- 没拆分层次就整体选型：把模型、编排、数据、交付绑成一个决定，后面每一层都换不动；
- 被「一站式」宣传带跑：核心知识与业务逻辑落在平台里，退出成本失控；
- 提示词只存在平台表单里：无法评审、无法回滚、无法做 AB 对比；
- 未验证需求就建平台：先用裸 API 跑通最小闭环，确认有人用再投入；
- 低估维护人力：把 LLM 应用当成「上线即完成」，实际效果调优是长期工作；
- 没有模型适配层：换模型要改几十处调用点，且无法统一做限流与计量；
- 知识库托管在平台侧：数据资产与平台绑定，迁移时等于重建；
- 没有评测集就换栈：换完不知道变好还是变差，只能凭感觉；
- 为炫技上多智能体：固定流程能解决的，别用多个角色来回调用；
- 只看 token 单价做成本决策：忽略了人力、迁移与可观测的长期成本。
十、检查清单
- [ ] 已按六层（模型/编排/工具/数据/可观测/交付）分别做过决定
- [ ] 核心业务逻辑与平台解耦，提示词与流程进 Git 可版本化
- [ ] 模型调用收敛到统一适配层（含重试、限流、成本计量）
- [ ] 文档源、向量、评测集保存在自有存储中
- [ ] 有可回归的评测集，换模型/升版本时能验证效果
- [ ] 成本按「调用 + 订阅 + 人力 + 基础设施 + 迁移」五项估算过
- [ ] 明确知道各层的替换路径（最坏情况下怎么迁走）
- [ ] 可观测（Trace 与关键指标）从第一天就接上，而不是出事后补
- [ ] 复杂度匹配：没有为单轮问答上重框架，也没有为长流程硬塞低代码平台
状态与参考
- 状态：已收录（2026-09-04）。本文给选型框架与纪律，不绑定具体版本；平台与框架迭代极快，落地前请以各官方最新文档为准；
- 关联：LangGraph 编排（编排层）、RAG 与 Agent 与 RAG 进阶（检索层）、MCP（工具与集成层）、AI 工程化（模型层与成本）、Agent 评测与可观测（评测层）、Agent 安全与治理（合规与审计要求）、Agent 架构通论（复杂度判断）、客户端技术全景与选型（客户端侧的选型方法可对照阅读）；
- 提醒：文中出现的平台与框架名称仅作路线示例，排名无先后；具体能力边界、计费方式与私有化支持情况请查阅官方文档，二手对比文章的结论往往滞后数月。
定完路线，回到 Agent 架构通论 检查复杂度判断是否成立；路线落地后，用 Agent 评测与可观测 把效果管起来。