Skip to main content

9.6.9 框架选型指南

本节定位

学完一圈框架以后，真正重要的问题终于来了：

到底该选哪个？

这不是一个“背答案”的题，而是一个“按任务结构做判断”的题。 这节课要做的，就是把这个判断过程讲清楚。

学习目标​

  • 学会用任务结构去判断框架，而不是看热度
  • 建立几条最实用的选型维度
  • 看懂一个最小选型打分示例
  • 知道什么时候甚至应该先别上框架

为什么框架选型本质上是架构决策？​

因为框架一旦选定，后面很多东西都会跟着走：

  • 代码组织方式
  • 团队学习成本
  • 调试方式
  • 可观测性接入方式
  • 上线和维护复杂度

所以它不是一个无关紧要的小依赖，而更像：

你决定系统要按什么方式长出来。

这也是为什么“哪个最火”通常不是最重要问题。

先看最关键的五个选型维度​

任务是不是复杂状态流？​

如果你的系统有：

  • 明显分支
  • 回路
  • 回退
  • 显式中间状态

那图工作流型抽象更有价值。

系统是不是知识 / 检索驱动？​

如果核心难点在：

  • 文档摄取
  • 索引
  • 检索
  • 查询组织

那知识导向框架会更自然。

任务是不是天然像角色协作？​

如果任务本来就像：

  • 调研
  • 写作
  • 审核

这类团队分工，角色型框架更顺手。

团队更在意什么？​

例如：

  • 更高控制力
  • 更低学习成本
  • 更快原型速度
  • 更稳的长期维护

项目现在是 demo 还是长期系统？​

这个区别非常关键。

  • demo 更看重搭得快
  • 长期系统更看重结构清晰和可维护

一个最小选型打分示例​

这个例子不是为了给你“标准答案”，而是教你：

先把任务维度摊开，再做判断。

Agent 框架选型决策图

读图提示

选框架时先不要问“哪个最火”，而要问任务更像哪一类：复杂状态流、知识检索、角色协作、快速 Demo，还是长期可维护系统。图中的分叉就是选型依据。

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.05
llamaindex -> 6.2
crewai -> 6.4

这段代码真正重要的不是分数​

真正重要的是你开始会问：

  • 我的系统到底更看重什么？
  • 为什么这个维度权重更高？

这才是选型思维本身。

几个典型任务下的直觉选型​

如果你做的是复杂状态流 Agent​

更优先考虑：

  • 图 / workflow 型框架

因为你更需要：

  • 显式状态
  • 条件边
  • 回退和重试

如果你做的是知识库 / RAG 主线​

更优先考虑：

  • 检索与知识组织导向框架

因为你的关键问题是：

  • 文档怎么进系统
  • 检索怎么组织

如果你做的是角色型多 Agent 原型​

更优先考虑：

  • 团队 / 角色协作型框架

因为这时最重要的是：

  • 分工表达自然
  • 角色关系清楚

什么时候不该着急上复杂框架？​

一个很常见但容易被忽略的情况​

如果你的项目只是：

  • 一个模型
  • 一个工具
  • 一条线性流程

那很多时候：

  • 手写
  • 轻量封装

就已经很够了。

为什么这反而可能更好？​

因为框架会带来：

  • 学习成本
  • 抽象成本
  • 调试成本

如果系统本身还很小，框架反而可能是额外负担。

所以可以先记住：

不是每个项目都需要“框架感”。

团队因素为什么不能忽略？​

框架不是只服务单个开发者，它还会影响整个团队：

  • 新人上手难不难
  • 社区资料多不多
  • 出问题时好不好查
  • 后面是否容易维护

一个技术上很强的框架，如果团队没人熟、资料也少，真实成本可能会很高。

所以“团队匹配度”是选型时非常现实的维度。

几个最常见的错误选型方式​

看谁最火​

这几乎是最常见的误区。

看 demo 最炫​

demo 好看，不代表适合长期系统。

还没想清任务结构，就先选框架​

这会让你后面变成“拿框架套问题”，而不是“按问题选抽象”。

想让一个框架包办所有问题​

现实里很多系统本来就可能是混搭：

  • 检索层一种风格
  • 工作流层另一种风格

一个更实用的选型顺序​

比起“先列框架”，更建议你这样走：

  1. 先写出任务主线
  2. 画出状态流或工作流草图
  3. 标出知识、工具、角色三类需求谁更重
  4. 再选匹配抽象

这样你选框架时，依据就会清楚很多。

小结​

这一节最重要的不是选出一个“唯一正确框架”，而是学会：

先看任务形状，再看框架形状。

当你开始按状态流、知识组织、角色协作、团队约束这些维度去思考时，框架选型就不再只是跟风。

练习​

  1. 用你当前的项目，给“状态流 / 知识组织 / 角色协作 / 上手难度”四个维度分别打权重。
  2. 想一想：为什么简单项目硬上复杂框架，长期反而可能更慢？
  3. 用自己的话解释：为什么说框架选型是架构决策，而不是库选择？
  4. 如果你的团队特别看重可控性和可观测性，你会优先选什么风格的框架？