跳到主要内容

workflow、MCP、RAG 里，哪些是通用模式，哪些只是工具习惯

我最怕学完之后只会某个平台的手法​

这条资源覆盖 Coze、Dify、LangChain、LangGraph、MCP、RAG，实用性很强，但也最容易带来一个问题：

你最后记住的是某个平台怎么点，而不是某类系统问题本来该怎么解决。

所以我会强迫自己做一层拆分：哪些东西拿到别的平台还成立，哪些只是当前工具的操作习惯。

workflow：可迁移的是状态流，不是画布本身​

我认为 workflow 最值得带走的，是下面这些通用模式：

  • 把大任务拆成可检查的多步
  • 明确每一步需要什么输入和产出什么状态
  • 在分支、重试、人工介入这些点上保留控制感

这些东西，不管你在 Coze、Dify 还是 LangGraph 里做，底层问题都一样。

反过来，下面这些更像工具习惯：

  • 某个平台的节点命名方式
  • 某个画布的拖拽交互
  • 某种平台特有的 DSL 或配置项

如果我学完 workflow 之后，离开原平台就讲不清任务状态怎么流转，那我学到的多半只是工具操作。

MCP：可迁移的是能力协定，不是某个 Server 的打包方式​

MCP 里最值得迁移的，不是“某个 MCP Server 怎么装”，而是它背后的分工思路：

  • 能力怎么被声明
  • Agent 怎么发现可用能力
  • 调用接口如何和业务实现解耦
  • 为什么工具接入不该继续靠 ad hoc 的胶水逻辑

这些是能跨产品复用的。

更像工具习惯的，则包括：

  • 某个 Server 模板怎么写
  • 某个平台的认证、启动、注册命令
  • 某个具体 SDK 的打包细节

我会把这些放在“会用”层，而不是“学会了 MCP”层。

RAG：可迁移的是检索链路，不是某个向量库默认配置​

RAG 最值得拿走的是整条检索增强链路的判断：

  • 文档如何切分
  • 召回如何做
  • 是否需要 rerank
  • 生成时如何约束答案和来源
  • 最后怎么评估效果

这些问题不因为你换成别的向量库或检索框架就消失。

更偏工具习惯的，是：

  • 某个向量库的具体建表方式
  • 某个平台知识库的默认切块参数
  • 某种前端配置界面的操作路径

这些当然要会，但它们不该冒充 RAG 的核心能力。

一个最实际的自检方法​

我会用一个很直接的问题检查自己有没有抽象成功：

如果现在不准我提 Coze、Dify、LangChain、LangGraph 这些名字，我还能不能把 workflow、MCP、RAG 各自解决的问题说清楚。

如果不能，那说明我学到的还是工具习惯，不是可迁移模式。

我真正想从这条资源里拿走什么​

对我来说，这条资源最值钱的不是“把所有生态都见过”，而是借这些生态训练一种能力：

看到一个新平台时，能迅速分辨：

  • 它在解决哪类通用问题
  • 它只是把旧问题换了个交互形式
  • 它有哪些地方值得迁移到自己的项目里

只有做到这一点，这类覆盖面很广的资源才不会变成“平台见闻合集”。