9.6.9 框架选型指南
- 学会用任务结构去判断框架，而不是看热度
- 建立几条最实用的选型维度
- 看懂一个最小选型打分示例
- 知道什么时候甚至应该先别上框架
为什么框架选型本质上是架构决策？
Section titled “为什么框架选型本质上是架构决策？”因为框架一旦选定，后面很多东西都会跟着走：
- 代码组织方式
- 团队学习成本
- 调试方式
- 可观测性接入方式
- 上线和维护复杂度
所以它不是一个无关紧要的小依赖，而更像：
你决定系统要按什么方式长出来。
这也是为什么“哪个最火”通常不是最重要问题。
先看最关键的五个选型维度
Section titled “先看最关键的五个选型维度”任务是不是复杂状态流？
Section titled “任务是不是复杂状态流？”如果你的系统有：
- 明显分支
- 回路
- 回退
- 显式中间状态
那图工作流型抽象更有价值。
系统是不是知识 / 检索驱动？
Section titled “系统是不是知识 / 检索驱动？”如果核心难点在：
- 文档摄取
- 索引
- 检索
- 查询组织
那知识导向框架会更自然。
任务是不是天然像角色协作？
Section titled “任务是不是天然像角色协作？”如果任务本来就像：
- 调研
- 写作
- 审核
这类团队分工，角色型框架更顺手。
团队更在意什么？
Section titled “团队更在意什么？”例如：
- 更高控制力
- 更低学习成本
- 更快原型速度
- 更稳的长期维护
项目现在是演示还是长期系统？
Section titled “项目现在是演示还是长期系统？”这个区别非常关键。
- 演示更看重搭得快
- 长期系统更看重结构清晰和可维护
一个最小选型打分示例
Section titled “一个最小选型打分示例”这个例子不是为了给你“标准答案”，而是教你：
先把任务维度摊开，再做判断。
frameworks = { "langgraph": {"stateful_flow": 9, "knowledge": 6, "role_collab": 6, "ease_of_start": 6}, "llamaindex": {"stateful_flow": 5, "knowledge": 9, "role_collab": 4, "ease_of_start": 7}, "crewai": {"stateful_flow": 5, "knowledge": 5, "role_collab": 9, "ease_of_start": 8}}
weights = { "stateful_flow": 0.35, "knowledge": 0.25, "role_collab": 0.20, "ease_of_start": 0.20}
def score(framework_info, weights): return sum(framework_info[k] * weights[k] for k in weights)
for name, info in frameworks.items(): print(name, "->", round(score(info, weights), 3))预期输出：
langgraph -> 7.05llamaindex -> 6.2crewai -> 6.4这段代码真正重要的不是分数
Section titled “这段代码真正重要的不是分数”真正重要的是你开始会问：
- 我的系统到底更看重什么？
- 为什么这个维度权重更高？
这才是选型思维本身。
几个典型任务下的直觉选型
Section titled “几个典型任务下的直觉选型”如果你做的是复杂状态流 Agent
Section titled “如果你做的是复杂状态流 Agent”更优先考虑：
- 图 / 工作流 型框架
因为你更需要：
- 显式状态
- 条件边
- 回退和重试
如果你做的是知识库 / RAG 主线
Section titled “如果你做的是知识库 / RAG 主线”更优先考虑：
- 检索与知识组织导向框架
因为你的关键问题是：
- 文档怎么进系统
- 检索怎么组织
如果你做的是角色型多 Agent 原型
Section titled “如果你做的是角色型多 Agent 原型”更优先考虑：
- 团队 / 角色协作型框架
因为这时最重要的是：
- 分工表达自然
- 角色关系清楚
什么时候不该着急上复杂框架？
Section titled “什么时候不该着急上复杂框架？”一个很常见但容易被忽略的情况
Section titled “一个很常见但容易被忽略的情况”如果你的项目只是：
- 一个模型
- 一个工具
- 一条线性流程
那很多时候：
- 手写
- 轻量封装
就已经很够了。
为什么这反而可能更好？
Section titled “为什么这反而可能更好？”因为框架会带来：
- 学习成本
- 抽象成本
- 调试成本
如果系统本身还很小，框架反而可能是额外负担。
所以可以先记住：
不是每个项目都需要“框架感”。
团队因素为什么不能忽略？
Section titled “团队因素为什么不能忽略？”框架不是只服务单个开发者，它还会影响整个团队：
- 新人上手难不难
- 社区资料多不多
- 出问题时好不好查
- 后面是否容易维护
一个技术上很强的框架，如果团队没人熟、资料也少，真实成本可能会很高。
所以“团队匹配度”是选型时非常现实的维度。
几个最常见的错误选型方式
Section titled “几个最常见的错误选型方式”这几乎是最常见的误区。
演示好看，不代表适合长期系统。
还没想清任务结构，就先选框架
Section titled “还没想清任务结构，就先选框架”这会让你后面变成“拿框架套问题”，而不是“按问题选抽象”。
想让一个框架包办所有问题
Section titled “想让一个框架包办所有问题”现实里很多系统本来就可能是混搭：
- 检索层一种风格
- 工作流层另一种风格
一个更实用的选型顺序
Section titled “一个更实用的选型顺序”比起“先列框架”，更建议你这样走：
- 先写出任务主线
- 画出状态流或工作流草图
- 标出知识、工具、角色三类需求谁更重
- 再选匹配抽象
这样你选框架时，依据就会清楚很多。
学完这一页，至少保留这张证据卡：
- 问题形态
- 工作流图、检索应用、角色团队或实验
- 框架选择
- 它增加了什么抽象，以及隐藏了什么控制
- 追踪记录
- 状态、节点、tool 调用、消息或运行 id
- 失败检查
- 框架魔法隐藏状态、重试或权限问题
- 决策
- 只有在单代理循环清晰后才选择框架
这一节最重要的不是选出一个“唯一正确框架”，而是学会：
先看任务形状，再看框架形状。
当你开始按状态流、知识组织、角色协作、团队约束这些维度去思考时，框架选型就不再只是跟风。
- 用你当前的项目，给“状态流 / 知识组织 / 角色协作 / 上手难度”四个维度分别打权重。
- 想一想：为什么简单项目硬上复杂框架，长期反而可能更慢？
- 用自己的话解释：为什么说框架选型是架构决策，而不是库选择？
- 如果你的团队特别看重可控性和可观测性，你会优先选什么风格的框架？
项目交付参考与讲解
- 实用的权重分配应该从项目最大不确定性出发。RAG 重的应用可能更看重知识组织；长流程 Agent 可能更看重状态流；团队模拟任务可能更看重角色协作。
- 复杂框架套到简单项目上会拖慢进度，因为学习者要同时调业务逻辑和框架抽象。额外机制还可能隐藏真正失败点。
- 框架选择是架构决策，因为它会影响 state、可观测性、可测试性、团队协作、部署和未来迁移成本，不只是多一个 import。
- 如果特别重视可控性和可观测性，应优先显式 graph/workflow 设计、强 trace、清晰 state object，避免让运行循环变得难检查的抽象。