Sherry's Blog


  • 首页

  • 关于我

  • 标签

  • 目录

  • 吐槽

  • 文章列表

读完 Coze 开源版,我有几个问题没想通

发表于 2026-04-12 | 分类于 技术 , agent , 国内

编者按:先说点不那么“官方”的话

下面这篇是我让 Claude 做的一份调研,写得挺完整,但读下来总觉得措辞太“官方评测号”了一点,所以在正文之前我想先把自己的真实体感写下来,免得看完下面那堆表格之后还以为我真的被说服了。

第一,主数据库选 MySQL,我觉得挺抽象的。 在 2026 年新开一个开源项目,默认主库还是 MySQL 8.4,这个选择在我看来非常“十年前大厂标配”。不是说 MySQL 不能用,它当然能用——但是在一个对开发者友好、想走生态的项目里,PostgreSQL 几乎在所有维度上都是更合理的默认:JSON/JSONB 原生支持、丰富的扩展生态(pgvector、pg_trgm、全文检索)、更严格的 SQL 标准兼容、更好的并发控制、更现代的运维体验。同类项目里 Dify 用 PG、Langflow 用 PG/SQLite,FastGPT 用 MongoDB + pgvector,只有 Coze 还锁死在 MySQL。更讽刺的是,正因为 MySQL 的 JSON 能力不如 PG、没有 pgvector,Coze 才不得不额外引入 Milvus 做向量、Elasticsearch 做全文检索——一套本来用 PostgreSQL 单库 + 扩展就能搞定的事情,硬生生被拆成了三个中间件。这不像是“深思熟虑的选型”,更像是“字节内部本来就用 MySQL,那就继续用 MySQL,不够的地方再加组件补”。结果就是一个号称 “2 核 4G 就能跑”的轻量项目,docker-compose 里塞了 MySQL + Redis + MinIO + Elasticsearch + Milvus + etcd + NSQ,七个中间件起步。

第二,DDD + 防腐层这件事,我觉得没必要。 调研里把 “严格 DDD 四层分层 + crossdomain 防腐层” 当作 Coze 的架构亮点来写,但坦白说我持保留意见。DDD 在重业务、多团队、长生命周期的复杂企业系统里是有价值的——它帮你在业务边界清晰、领域专家稳定、需求变更可预期的前提下控制复杂度。但一个开源的 AI Agent 平台,业务边界本身就还在快速漂移(今天是 Agent,明天是 Workflow,后天是 MCP),这个阶段套一层严格 DDD + 防腐层,付出的是每次加功能都要穿四层目录、改一堆接口契约的摩擦,换来的是一个并不稳定的“边界”。对于想二次开发的外部贡献者来说,DDD 本身就是一种“隐性门槛”——你得先理解它的分层约定、防腐层的用意、领域对象和 DTO 的转换规则,才能动得了哪怕一个小改动。更务实的做法,应该是分层可以有、但别太重,允许扁平化的 feature module,把“理解成本”降到最低。目前这种写法更像是字节内部团队熟悉的工程范式被原样搬出来,而不是为开源社区的协作节奏设计过。

第三,商业模式这段我就不评具体数据了,但想吐个槽。 最近一两个月我在 X 上刷到的 Dify、Coze 相关广告密度高得有点离谱,而且这些广告有一个非常一致的叙事模板——“我们产品做得挺好的,只是底层模型还不太行”。我每次看到这种话术都觉得有点微妙。点进去看他们的产品,第一眼确实挺花哨的:工作流画布、插件市场、各种花式模板、一键发布到十几个渠道,视觉上信息量很大,给人一种”这东西很强”的错觉。但产品好看和产品好用是两回事,而”产品好用”和”底层模型够聪明”又是两回事。说实话,我自己没有在生产里长期用过 Dify 或 Coze,所以产品层面的判断我保留——但我下载过豆包,也用过一段时间各种号称”Agent 平台”的东西,越用越清楚一件事:在这个阶段,我更看重模型的智商,而不是外壳的花样。 模型智商是上限,产品壳子只是把这个上限包装出来。一个聪明的模型配一个朴素的壳,用起来会越用越顺;一个普通的模型配一个花哨的壳,用第一眼印象很好,用到第三天就开始觉得处处别扭。那些把”产品做得好”当作卖点、同时又在字里行间暗示”模型不够给力”的广告,本质上是在用产品的”密度”去掩盖模型的”厚度”——而这两者根本不是一个维度的东西。我不是说这些产品不好,我是说在模型还在高速迭代的当下,“产品壁垒”这个叙事被过度讲述了。真正的护城河在模型那一侧,产品这边目前还谈不上壁垒——谁今天做的工作流画布更好看一点,三个月后可能就被别人抄走了。

顺着这条线我多说两句。我最近真的在用 Manus,而且觉得它挺好用的——但仔细想,它好用的最大原因不是产品本身有多惊艳,而是它让你选最聪明的模型,GPT-5.4、Claude 4.6 这种直接接进去用。Manus 的产品壳子我觉得做得也还行,第一眼很简洁,能告诉你它能干什么、给你一堆 sample,落地路径很清楚——但你真用下来会发现,它骨子里还是”互联网时代的交互思维”:引导、教学、模板、弹窗、一步步带你走完一个漂亮的 demo 流程。这些东西不是坏事,但对一个开发者来说,其实有点多余。

我现在用得最顺手的 AI 工具,老实说就是 Claude Code。它几乎没有花哨的东西,就是个终端,加上一个足够聪明的模型,加上一小撮恰到好处的工具(文件编辑、命令执行、子 Agent)。对一个开发者来说,这已经够了。 你不需要有人牵着你走完一个 demo,你只需要把你想要的东西说清楚,剩下的交给模型。每个人的需求本来就是不一样的,预设的工作流再漂亮也只是把平均用户的平均需求凝固了下来——你稍微偏离一点,那个漂亮的壳就开始碍事。Claude Code 的克制反而是它最大的优点。

再对比豆包。豆包我也用过——坦白讲,不是智商低,但它给我的感觉确实是娱乐属性 > 解题属性。声音好听、能跟你唱歌、能跟你闲聊、交互做得非常顺滑,很明显背后是有大量人力在打磨”体验”的。这没什么问题,字节是做内容和用户产品出身的,他们最擅长的就是这件事。但当我真的想让它帮我解决一个具体问题的时候,那种”产品感”反而成了噪声——我不需要它先说一句俏皮话再回答我的问题,我需要它直接答对。

把这几个放到一起看,其实指向同一个判断:现在这一代所谓的 AI 产品,大部分还是”互联网思维往 AI 时代的过渡态”。 设计逻辑还是互联网那一套——先占领市场、先把 DAU 拉起来、先把壳子做得够密够花,模型智商的问题”以后再说”。这里面当然有客观原因,显卡买不到这种事我没什么好吐槽的,在有限显卡内能做到现在这个样子已经很不容易。但客观原因不改变一个事实:花哨产品的半衰期会非常短。 当模型继续变聪明,当推理成本继续下降,当底层能力再上一个台阶,今天这些精心雕琢的引导流程、工作流画布、模板市场,大概率会在一两年内被一个更朴素、更直接、让模型直接和用户对话的形态取代。到那个时候,真正留下来的产品不会是”产品壳最花”的那个,而是”最舍得把模型放到前台”的那个。

第四,后端选 Go,在 2026 年的 AI 项目里也挺抽象的。 这个其实跟 MySQL 是同一件事在另一层上的重复。看一眼当下 AI infra 的主流语言分布:TS 那边是 LangChain.js、Flowise、FastGPT、Vercel AI SDK、Mastra,以及几乎所有想做前后端类型共享的 Agent 框架;Python 那边是 LangGraph、LlamaIndex、Langflow、CrewAI、AutoGen,以及所有贴近模型和研究社区的项目;Rust 那边是 tokenizers、candle、mistral.rs、Qdrant、LanceDB 这些底层运行时。Go 在这个赛道里其实挺边缘的——它的传统强项(高并发网关、K8s 那类控制面)在 AI Agent 平台里不是瓶颈。真正的瓶颈在上下文管理、模型调用、工具编排、流式响应、以及”用类型优雅地描述一堆 JSON Schema”,这些事情 TS 做起来最顺手(前后端共享 Schema)、Python 做起来生态最全(所有模型 SDK 都是 Python 一等公民)、Rust 做起来性能最好且类型系统更强。Go 卡在中间:表达力不如 TS/Rust,生态不如 Python,性能也不是决定性优势。字节选 Go 的根本原因和选 MySQL 一样——CloudWeGo(Hertz / Kitex / Eino)整套都是 Go 写的,字节后端主力语言就是 Go,这套东西搬出来开源几乎是零成本。但对外部开发者来说,代价是:想改一行代码得先装 Go 工具链、学 Hertz 的路由风格、搞懂 Eino 的抽象,而这些东西在 AI 社区里的迁移价值接近零——你学会了 Hertz,下一个 AI 项目大概率还是用不上。

把前四点叠在一起,其实就能看出一个很清晰的信号:主库 MySQL、后端 Go、HTTP 框架 Hertz、LLM 运行时 Eino——每一层都选了”字节内部最顺手”而不是”外部社区最顺手”。 这四个选择任何一个单拎出来都能解释,但叠加之后就不再是巧合,而是一个设计目标的暴露:这个项目真正的目标不是”让开源社区共建”,而是”把字节内部的东西原样开源出去”。共建是附带的,不是主线。

一句话总结我的立场:Coze 开源这件事本身是好事,但它目前看起来更像是字节把内部的一套东西“原样”搬出来,而不是真的为外部开发者社区重新设计过一遍。 架构规整是一回事,规整得是否合适、是否对社区友好是另一回事。下面是 Claude 的完整调研,数据和引用都保留,仅供参考。


字节跳动 Coze 开源全景:架构解析与五大竞品深度对比

本文从技术架构和产品设计两个维度,将 Coze 与 Dify、FastGPT、Langflow、Flowise 四大竞品进行全面对比分析,涵盖代码设计、社区数据、开发者口碑、产品功能和商业模式。


引言

2025 年 7 月,字节跳动旗下 AI Agent 开发平台扣子(Coze)正式宣布开源,主要包括 Coze Studio(智能体开发平台)和 Coze Loop(运维优化平台)两大核心项目,均采用 Apache 2.0 许可证 [1][2]。开源发布后 48 小时内即获得超过 9,500 个 GitHub Star [3],截至 2026 年 4 月,coze-studio 已积累约 20,000 Star [4]。然而,与已拥有约 13.1 万 Star 的 Dify [5] 和约 14.5 万 Star 的 Langflow [6] 相比,Coze 作为开源新兵仍需快速补齐生态短板。

本文将从开源代码架构设计和产品设计两个核心维度,系统对比 Coze 与 Dify、FastGPT、Langflow、Flowise 五大平台的技术选型、功能特性与商业策略,为开发者和技术决策者提供选型参考。


一、技术架构对比

1.1 Coze 的 Go + DDD 架构

Coze Studio 后端选用 Go 语言,HTTP 框架为字节自研的 Hertz,AI/LLM 运行时基于同属 CloudWeGo 生态的 Eino 框架,工作流前端画布使用 FlowGram 引擎 [7]。前端采用 React + TypeScript,以 Rush.js 管理 monorepo,构建工具为 Rust 实现的 Rsbuild [7]。

架构层面,coze-studio 严格遵循领域驱动设计(DDD)的分层模型:API 层 → Application 层 → Domain 层 → Infrastructure 层,并专门设置了 crossdomain/ 作为防腐层(Anti-Corruption Layer),通过接口契约隔离不同领域之间的直接依赖 [8]。Coze Loop 则采用「模块化单体」架构,在 modules/ 下将 data、evaluation、observability、prompt 等模块各自包含独立的 DDD 四层结构 [9]。

存储方面,Coze Studio 使用 MySQL 8.4 作为主数据库、Redis 做缓存、MinIO 负责对象存储,并引入 Elasticsearch(SmartCN 中文分词)做全文检索、Milvus 做向量存储、etcd 做分布式配置管理,消息队列选用 NSQ。Coze Loop 则使用 ClickHouse 存储 Trace 数据,消息队列选用 Apache RocketMQ [9][10]。两个项目均支持 Docker Compose 一键部署,最低硬件要求仅 2 核 4GB RAM [2]。

1.2 竞品架构选型

Dify 采用 Python Flask 后端 + Next.js 前端 + PostgreSQL + Redis + Celery 异步任务队列的经典 Python Web 栈 [11]。在 v1.0 版本中引入了「蜂巢架构」(Beehive Architecture),以六边形架构理念实现组件独立开发、测试和部署 [12]。

FastGPT 走 TypeScript 全栈路线(Next.js + Chakra UI),主数据库使用 MongoDB,向量存储支持 PostgreSQL + pgvector 或 Milvus [13][14]。

Langflow 基于 Python FastAPI 构建,深度绑定 LangChain 生态,由 DataStax/IBM 支持 [6][15]。Flowise 同为 TypeScript 栈但后端用 Express.js,同样构建在 LangChain.js 之上 [16][17]。

1.3 架构对比总结

维度 Coze Studio Dify FastGPT Langflow Flowise
后端语言 Go (Hertz) Python (Flask) TypeScript (Next.js) Python (FastAPI) TypeScript (Express.js)
前端框架 React + TS (Rsbuild) Next.js Next.js + Chakra UI React + TS React
主数据库 MySQL 8.4 PostgreSQL MongoDB + PG Vector SQLite/PostgreSQL SQLite/PG/MySQL
向量数据库 Milvus 30+ 可选 [18] PG Vector / Milvus LangChain 兼容 LangChain 兼容
架构模式 DDD 严格分层 + 防腐层 蜂巢架构(六边形) Monorepo 单体 组件式 Monorepo 单体
最低配置 2 核 4GB 2 核 4GB(推荐 4 核 8GB) 4 核 8GB 未明确 未明确
部署方式 Docker Compose / Helm Docker Compose / Helm Docker Compose / Sealos / Helm Docker / pip / 桌面 Docker / NPM

二、GitHub 社区数据对比

从社区规模来看,开源 AI Agent 平台已形成清晰的三个梯队(数据截至 2026 年 4 月):

指标 Langflow Dify Flowise FastGPT Coze Studio Coze Loop
Star 数 ~145,000 ~131,000 ~51,700 ~27,700 ~20,000 ~5,400
Fork 数 ~8,500 ~21,500 ~24,000 ~7,000 ~2,900 ~744
贡献者 高活跃 462+ 活跃 活跃 66 较少
许可证 MIT Apache 2.0 + 附加限制 Apache 2.0 Apache 2.0 + SaaS 限制 Apache 2.0(纯净版) Apache 2.0(纯净版)
开源时间 2023 2023.5 2023 2023.4 2025.7 2025.7
企业支持 IBM/DataStax LangGenius($30M 融资)[19] Workday 收购 [17] LabRing/Sealos 字节跳动 字节跳动

数据来源:各项目 GitHub 仓库页面 [4][5][6][13][16]

Coze Studio 在仅 9 个月内积累 2 万 Star,增速可观,但 66 名贡献者和 385 次 Commits 反映出社区参与度尚处于早期 [4]。对比 Dify 的 462+ 贡献者 [5] 和 Langflow 的 17,000+ Commits [6],差距明显。


三、工作流引擎与知识库 RAG 实现

3.1 工作流引擎

Coze Studio 的工作流画布基于 FlowGram 引擎,节点类型通过 WorkflowNodeRegistry 注册,前后端通过 nodeDTOType 约定节点类型 ID。代码节点支持 Python 沙箱执行(内置 httpx、numpy),并提供了完整的自定义节点开发指南 [20][21]。

Dify 的工作流引擎在 v1.9.0 引入了基于队列的图引擎(Queue-based GraphEngine),支持 Workflow 和 Chatflow 两种模式,v0.8.0 起支持多分支并行执行 [22]。Dify 独有的 Human Input 节点(v1.13.0)可在工作流中插入人工审核环节 [22]。

3.2 知识库 / RAG 实现

各平台在知识库实现上分化显著。Coze Studio 使用 Milvus + Elasticsearch(SmartCN)构建 RAG Pipeline [7]。Dify 拥有最丰富的向量数据库支持(30+ 种后端),v1.9.0 推出的 Knowledge Pipeline 可在工作流画布上可视化编排 RAG ETL 流程,并引入了 Agentic RAG [18][22]。FastGPT 的 RAG 设计最具特色——采用 QA 问答对存储模型而非简单文本分块,检索时通过 RRF(Reciprocal Rank Fusion)融合重排序、向量搜索和全文检索结果 [14][23]。Langflow 和 Flowise 均依赖 LangChain 生态的检索组件 [15][16]。


四、插件生态与模型支持

Coze 商业版拥有数千款插件,但开源版目前仅包含约 18 个插件,且部分需要单独 OAuth 授权 [24]。模型支持通过 YAML 配置文件管理,支持 OpenAI、火山引擎 Ark、Azure、Ollama、DeepSeek、Qwen 等 20+ 提供商 [10][25]。

Dify 在 v1.0 进行了插件系统的根本性重构,定义了模型、工具、Agent 策略等五种插件类型,目前有 50+ 内置工具和 315+ 社区工具,支持热插拔 [26][27]。FastGPT 的插件系统以可复用的 Flow 节点为主,通过 OneAPI 统一模型接入 [14]。

在发布渠道方面,Coze 的多平台发布能力最强——支持一键发布到 TikTok/抖音、飞书、微信、Discord、Telegram 等多个渠道 [28]。Dify 以 Web App + API + 嵌入式组件为主 [5]。FastGPT 通过 OpenAI 兼容 API 对接各渠道 [14]。Langflow 和 Flowise 主要通过 API 集成 [15][16]。


五、开发者社区反馈

5.1 部署与二次开发体验

中文社区对 Coze 开源的评价呈现两极分化。正面评价集中在架构质量和协议优势 [1],但批评同样尖锐:有开发者指出开源版功能阉割严重——无 AI 创建 Agent、无触发器、无云端知识库、无长期记忆 [29]。知乎实测进一步发现开源版没有用户管理和多租户支持,模型配置依赖静态 YAML 文件而非在线管理界面 [30]。二次开发方面,Hertz 框架相对小众、网上资料较少,且源码中存在商业版残留逻辑 [31]。部署常见问题包括 MySQL 端口冲突、Elasticsearch 启动失败和国内 Docker 镜像拉取困难 [32]。

Dify 的口碑以「成熟但复杂」为主。v1.0.0 版本因 Bug 众多被大量用户吐槽 [33]。但 Dify 被普遍认为是正式企业项目的首选 [28]。FastGPT 的核心优势在知识库场景,但高级工作流的延迟问题突出 [34]。

5.2 安全性

值得注意的是,Langflow 在 2025 年曝出 CVE-2025-3248(未认证远程代码执行漏洞),生产环境部署存在顾虑 [35]。Flowise 被指出开源版与企业版代码分离不够清晰 [36]。


六、商业模式与许可证策略

五大平台的许可证策略反映了不同的商业意图。Coze 的 Apache 2.0 纯净版协议是最大的差异化优势——Dify 的协议禁止未授权的多租户 SaaS 部署 [37][30],FastGPT 同样限制 SaaS 场景 [13],只有 Coze 和 Langflow(MIT)允许完全自由的商业使用。

平台 许可证 SaaS 商用 云服务定价 企业支持
Coze Apache 2.0 ✅ 完全允许 Free / $9 / $39 月 [38] 字节跳动
Dify Apache 2.0 + 限制 ❌ 需商业授权 Free / $59 / $159 月 [39] $30M Pre-A 融资 [19]
FastGPT 自定义(限 SaaS) ❌ 需商业授权 按量计费 LabRing/Sealos
Langflow MIT ✅ 完全允许 云服务 2026.4 关闭 [15] IBM/DataStax
Flowise Apache 2.0 ✅ 但 RBAC/SSO 付费 Free / $35 / $65 月 Workday 收购 [17]

目标用户群体差异明显。Coze 定位于零代码/低代码的 C 端用户 [28]。Dify 瞄准生产级 AI 应用的开发者和企业团队,已服务 2,000+ 团队 [19]。FastGPT 深耕垂直知识库场景 [14]。Langflow 服务于 Python 开发者和 ML 工程师 [15]。Flowise 被 Workday 收购后转向 HR/财务 AI 场景 [17]。


七、选型建议与趋势展望

中文开发者社区已形成较为一致的选型共识 [28][33]:快速原型和 C 端应用选 Coze,企业级知识库选 FastGPT,全球化/多语言生产应用选 Dify,深度定制选 Langflow,多 Agent 编排选 Flowise。实际上,领先团队正在采用组合策略——如 FastGPT 做知识检索引擎 + Dify 做工作流编排 + Coze 做前端交互入口。

从技术趋势看,MCP 协议正在成为工具互通的标准——Coze、Dify、Langflow 均已支持 [5][7][15]。Agentic RAG 和 Human-in-the-Loop 是 2025-2026 年最重要的功能创新方向 [18][22]。可观测性正从可选项变为必需品——Coze Loop 的全生命周期管理和 Dify 的内置 LLMOps 仪表盘代表了两条不同的实现路径 [9][5]。

Coze 开源版当前最大的短板在于功能完整度和社区成熟度 [29][30]。但其 Go + DDD 的架构质量、极低的硬件门槛、纯净的 Apache 2.0 协议,以及字节跳动的工程资源支撑,使其在中长期具备冲击 Dify 领先地位的潜力。正如一位开发者在 GitHub Issue 中写道的那样——Coze 开源对整个行业生态的冲击力不可忽视 [40]。关键问题在于:字节跳动是否有耐心将开源版打磨到真正的生产级水平,而非仅仅作为商业版的引流工具。


参考文献

[1] 知乎, “扣子,正式拥抱开源!”, 2025. https://zhuanlan.zhihu.com/p/1933885813160117712

[2] Aibase, “Bytedance Announces Two Major Core Projects of Coze Officially Open-Source: Coze Studio and Coze Loop”, 2025. https://test-news.aibase.com/news/19989

[3] 知乎, “杀疯了!Coze 开源三天狂揽 9.5k Star,手把手教你私有化部署”, 2025. https://zhuanlan.zhihu.com/p/1933463428606964141

[4] GitHub, “coze-dev/coze-studio”, 2025-2026. https://github.com/coze-dev/coze-studio

[5] GitHub, “langgenius/dify”, 2023-2026. https://github.com/langgenius/dify

[6] GitHub, “langflow-ai/langflow”, 2023-2026. https://github.com/langflow-ai/langflow

[7] 博客园 JadePeng, “Coze Studio:字节跳动 Coze 的开源版本来了!第一时间深度解析”, 2025. https://www.cnblogs.com/xiaoqi/p/19005840/coze

[8] GitHub Wiki, “7. Development Standards · coze-dev/coze-studio”, 2025. https://github.com/coze-dev/coze-studio/wiki/7.-Development-Standards

[9] GitHub Wiki, “3. Architecture · coze-dev/coze-loop”, 2025. https://github.com/coze-dev/coze-loop/wiki/3.-Architecture

[10] 火山引擎开发者社区, “扣子(Coze)正式开源!全网最详细的部署教程拿走不谢~”, 2025. https://developer.volcengine.com/articles/7533499908662231091

[11] Oreate AI, “Analysis of Dify’s Technical Architecture”, 2025. https://www.oreateai.com/blog/analysis-of-difys-technical-architecture/

[12] Dify Blog, “Dify Rolls Out New Architecture, Enhancing Flexibility and Scalability”, 2025. https://dify.ai/blog/dify-rolls-out-new-architecture

[13] GitHub, “labring/FastGPT”, 2023-2026. https://github.com/labring/FastGPT

[14] 知乎, “使用 FastGPT 构建高质量 AI 知识库”, 2024. https://zhuanlan.zhihu.com/p/647960390

[15] DataStax, “About DataStax Langflow”, 2025. https://docs.datastax.com/en/langflow/index.html

[16] GitHub, “FlowiseAI/Flowise”, 2023-2026. https://github.com/FlowiseAI/Flowise

[17] Voiceflow, “Flowise: What It Is and Best Alternatives [2026 Review]”, 2026. https://www.voiceflow.com/blog/flowise-alternative

[18] DeepWiki, “Vector Database Integration | langgenius/dify”, 2025. https://deepwiki.com/langgenius/dify/4.4-vector-database-integration

[19] Business Wire, “Dify Raises $30 million Series Pre-A to Power Enterprise-Grade Agentic Workflows”, 2026. https://www.businesswire.com/news/home/20260309511426/en/

[20] GitHub Wiki, “10. Add new workflow node types (frontend) · coze-dev/coze-studio”, 2025. https://github.com/coze-dev/coze-studio/wiki/10.-Add-new-workflow-node-types-(frontend)

[21] GitHub, “coze-studio/CLAUDE.md”, 2025. https://github.com/coze-dev/coze-studio/blob/main/CLAUDE.md

[22] Dify Blog, “2025 Dify Summer Highlights”, 2025. https://dify.ai/blog/2025-dify-summer-highlights

[23] GitHub, “FastGPT dataset_engine.mdx”, 2024. https://github.com/labring/FastGPT/blob/main/document/content/docs/introduction/guide/knowledge_base/dataset_engine.mdx

[24] 36氪, “Coze开源了,为什么AI产品经理还是不会用?”, 2026. https://36kr.com/p/3408395792665993

[25] GitHub Wiki, “5. Model configuration · coze-dev/coze-loop”, 2025. https://github.com/coze-dev/coze-loop/wiki/5.-Model-configuration

[26] Dify Blog, “Dify v1.0.0: Building a Vibrant Plugin Ecosystem”, 2025. https://dify.ai/blog/dify-v1-0-building-a-vibrant-plugin-ecosystem

[27] GitHub, “langgenius/dify-plugins”, 2025. https://github.com/langgenius/dify-plugins

[28] Jimmy Song, “Open Source AI Agent Platform Comparison (2026): n8n, Dify, LangGraph, Coze, RAGFlow”, 2026. https://jimmysong.io/blog/open-source-ai-agent-workflow-comparison/

[29] 博客园 磊哥, “Coze开源版?别吹了!”, 2025. https://www.cnblogs.com/vipstone/p/19009069

[30] 知乎, “Coze 开源版 VS Dify:功能对比与实测体验分析”, 2025. https://zhuanlan.zhihu.com/p/1932752711188713920

[31] CSDN, “Coze开源深度解析:架构设计与二次开发经验分享”, 2025. https://blog.csdn.net/2401_85375151/article/details/152800914

[32] 博客园, “Coze开源本地部署教程”, 2025. https://www.cnblogs.com/hogwarts/p/19014935

[33] 知乎, “Dify、n8n、Coze、Fastgpt、Ragflow到底该怎么选?超详细指南~”, 2025. https://zhuanlan.zhihu.com/p/1908668807607751251

[34] 知乎, “FastGPT高级编排功能搭建AI Agent踩过的大坑”, 2024. https://zhuanlan.zhihu.com/p/712739030

[35] ZenML, “We Tried and Tested 8 Langflow Alternatives for Production-Ready AI Workflows”, 2025. https://www.zenml.io/blog/langflow-alternatives

[36] GitHub, “Build Flowise Open Source · Issue #4887”, 2025. https://github.com/FlowiseAI/Flowise/issues/4887

[37] GitHub, “dify/LICENSE”, 2025. https://github.com/langgenius/dify/blob/main/LICENSE

[38] TechWAN, “ByteDance’s AI Platform Coze Introduces Paid Plans Abroad”, 2024. https://techwan.org/article/2460.html

[39] Dify, “Plans & Pricing”, 2026. https://dify.ai/pricing

[40] GitHub, “大家来讨论下coze开源对其他同类开源产品的影响 · Issue #2”, 2025. https://github.com/coze-dev/coze-studio/issues/2

Why Most People Don't Need a Personal Knowledge Graph

发表于 2026-04-11 | 分类于 技术 , 感悟

Every few months a new wave of personal knowledge management tools sweeps through my timeline. Obsidian vaults with thousands of backlinks. Logseq graphs that look like neural tissue under a microscope. Zettelkasten disciples explaining how their “second brain” has finally freed them from forgetting. I find it all fascinating, and I am quietly convinced most people do not actually need any of it.

The pitch is seductive: capture everything, link everything, and your mind will become a searchable, navigable web. The trouble is that the human brain does not store memory the way a graph database does. A knowledge graph is a clean structure of nodes and edges, each one precise and typed. Memory is messier, warmer, and far more personal. It is shaped by who you are, what you felt, and what you happened to be looking at when the thought arrived.

Memory is not one thing. Some people think in propositions and crisp definitions. Some remember through sound and rhythm. Some rehearse by talking out loud. I am a scene‑based rememberer. What sticks for me is a picture—where I was sitting, what the light looked like, the texture of a particular afternoon. When I try to recall a concept, I do not search an index; I replay an episode. A conversation at a café, a paragraph on a specific page, the smell of rain during a lecture. The idea arrives wrapped in context, and the context is half the meaning.

Forcing that kind of memory into a tidy graph feels like pinning butterflies. You get a specimen, but the flight is gone. The graph can show me that Concept A links to Concept B, but it cannot reproduce the reason the link mattered to me in the first place—the small, private jolt of recognition that made me care. Strip away the scene and I am left with trivia I no longer have a reason to remember.

This is why I never got along with Obsidian. I tried, more than once. It is a beautiful piece of software and clearly a labor of love. But every time I sat down to “maintain” my vault, I felt like I was doing the paperwork of thinking instead of the thinking itself. Tagging, linking, renaming, reorganizing—the overhead kept eating the thing it was supposed to support. For a while I mistook the busyness for progress. Eventually I noticed that my best ideas were still coming from long walks, half‑finished drafts, and conversations I had not indexed anywhere.

There is also a quieter argument against the tools, and I think it is the more important one. The act of organizing by hand—slowly, with a pen or in a plain text file—is not a bottleneck to get rid of. It is the work. When I sit down and try to write out what I learned this week, I am forced to decide what actually matters. I drop the parts I cannot justify. I notice which ideas keep showing up next to each other. I simplify, rephrase, and sometimes discover that two things I thought were separate are really the same thing in different clothes. The friction is where the understanding happens. Automate it away and you get a larger archive and a smaller mind.

This is the part of the conversation where I have to talk about Karpathy, because a few days ago he posted about his “LLM Wiki” setup and the whole timeline tilted in response. The idea is elegant in the way his ideas usually are: you keep a folder of raw sources the model is never allowed to edit, you let an LLM agent maintain a second folder of markdown articles on top of those sources, and you give it a schema file—a CLAUDE.md or the equivalent—that tells it how to ingest new material, cross-link entities, and periodically lint the whole thing for contradictions and orphan pages. He mentioned that one of his research wikis has grown to around a hundred articles and four hundred thousand words, and that he rarely edits it by hand anymore. The day after, he dropped a gist meant to be copy-pasted into your own agent as a starting point. Within hours people were forking it, wiring it into Obsidian vaults, writing Medium posts with titles like “Karpathy just 10x’d everyone’s Claude setup,” and shipping GitHub repos called things like second-brain and llm-wiki. It has become a small genre.

I want to be honest about what is interesting here, because I do not think Karpathy is wrong in the way the loudest Obsidian evangelists are wrong. His framing actually concedes my main point: the tedious part of knowledge management is not reading, it is bookkeeping, and bookkeeping grows faster than the value it produces. That is exactly why I gave up on Obsidian. Where we part ways is on what to do about it. His answer is to hand the bookkeeping to a machine that does not get bored. Mine is to notice that the bookkeeping was mostly make-work in the first place, and to stop doing it. If the cross-references only existed because a human could not hold the material in their head, automating them does not make the material more yours—it just makes the scaffolding cheaper to maintain. You end up with a four-hundred-thousand-word wiki that an agent wrote on your behalf, and a vague feeling that you have read it, when in fact the model has.

There is a specific failure mode I want to name. When the wiki is maintained by an LLM, the canonical version of what you “know” lives outside your head, in prose you did not write. Querying it feels like remembering, but it is not—it is retrieval from a system whose compression choices you never made. For a scene-based rememberer this is especially bad, because the scenes never get encoded at all. There was no afternoon at the café. There was a diff in a markdown file. And the next time you want to recall the idea, there is nothing to replay, only something to look up. The copy-pasted gist is a beautiful piece of engineering and I understand why it went viral, but I think a lot of people are going to build one, feel productive for a month, and then quietly notice that their sense of having learned anything has gotten thinner, not thicker.

The thing worth stealing from Karpathy’s pattern, I think, is much smaller than the pattern itself. The useful primitive is the raw-sources folder: a flat pile of things you actually read, kept immutable, and occasionally grepped. That part costs nothing and preserves the context you might someday want to replay. Everything on top of it—the generated articles, the backlinks, the lint passes, the schema document—is optional, and for most people optional means “not worth it.” You can get eighty percent of the benefit by keeping the sources and writing the occasional essay in your own words when something refuses to settle.

Herbert Simon once said that a wealth of information creates a poverty of attention. Knowledge graphs, for all their elegance, tend to push in exactly the wrong direction. They make capture cheap and retrieval plausible, which encourages you to save more and decide less. But the scarce resource in adult life is not storage. It is the willingness to sit with a handful of ideas long enough to know what you think about them.

None of this is an argument against tools. If you are a researcher stitching together citations across a decade, a graph is probably indispensable. If your work genuinely has the shape of a network—legal precedents, drug interactions, an investigation with hundreds of named entities—then by all means, build the thing. What I am skeptical of is the default assumption that every knowledge worker needs a personal ontology, and that forgetting is a bug to be engineered out.

Forgetting is not a bug. It is a feature of a mind that has decided what matters. The things you cannot let go of are, almost by definition, the things worth keeping. A plain notebook, a few running documents, and the stubborn practice of writing in full sentences will take most people further than any graph ever will. Your brain already knows how it wants to remember. The job is to listen to it, not to overwrite it with somebody else’s schema.

So I will keep my notes simple. A handful of markdown files. A few drafts that grow in public. Long walks when something refuses to come clear. If that counts as a knowledge system, it is one with exactly one user, and the maintenance cost is the thinking itself—which, it turns out, is the only part I wanted in the first place.

1…345…24

54 日志
17 分类
44 标签
© 2026 Sherry