S21-J04 · 框架对比与生态

适用读者：要在 LangGraph / Spring AI / Dify 之间选型的人。
前置：S21-J03。
覆盖旧文：719(3416) 661(198) + 1 卡 = 3,711 点（本系列最大篇）。
覆盖扩展：E-S21-010（选型五问）、E-S21-018（框架演进风险）。
上一篇：S21-J03 · 工作流与可视化编排
下一篇：S21-J05 · CLI 与 GUI Agent。

1. 一句话结论

框架解决的是"拼装"而不是"能力"：选型看语言栈、部署形态、以及"你愿意被锁多久"。

框架	语言/形态	强项	代价
LangGraph	Python/JS	图式编排、状态管理	学习曲线
Spring AI	Java	与企业 Spring 栈一体	生态较新
Dify / Coze	可视化平台	快速上线、非技术可参与	定制受限
自研 pipeline	任意	完全可控	维护成本

2. 选型五问（E-S21-010）

① 团队主语言？（Java → Spring AI；Python → LangGraph）
② 需要可视化给非技术同事用吗？（要 → Dify/Coze）
③ 需要私有化/合规吗？（要 → 自建或私有部署）
④ 流程是固定还是探索？（固定 → 编排；探索 → Agent）
⑤ 能接受框架 API 变动吗？（不能 → 核心链路自研）

"第 ⑤ 问最容易被忽略"：框架抽象层越厚，出问题时越难看穿——核心链路（检索、工具执行、权限）建议自己可控。

3. 框架能力的四个分层

层	是否该用框架
模型调用	✅ 用（省去适配）
提示词/结构化输出	✅ 用
工具执行与权限	⚠️ 自己控（安全边界）
编排与状态	视复杂度（简单自研更清晰）

判据："这段代码出问题时，我能看到底层吗？" 看不到 → 移到自研层。

4. 框架演进风险（E-S21-018）

风险	应对
API 破坏性变更	锁版本 + 抽象适配层
项目停更	优先选有大厂/社区支撑的
迁移成本	核心逻辑与框架解耦

"怎么降低锁定"：把"模型调用/工具执行/状态存储"包成自己的接口，框架只做实现之一。

5. 五个误区

误区	真相
"上框架就生产就绪"	框架只解决拼装
"框架越全越好"	抽象越厚越难排障
"流行框架不会变"	迭代很快
"自研一定更好"	维护成本高
"可视化平台不能做生产"	固定流程完全够

6. 自检

四种形态的强弱项？
选型五问？
哪一层建议自研？为什么？
如何降低框架锁定？
"抽象越厚"的风险是什么？

7. 下一篇

S21-J05 · CLI 与 GUI Agent

选型讲完，下一篇讲"Agent 怎么操作真实环境"。

本篇属于系列《S21 · Agent 工程与 MCP》。旧文来源：A-719/661 + 1 卡；扩展点 E-S21-010/018。