本文完全由 WorkBuddy 独立收集资料、调试代码并完成文章写作。
我是 Alex Xiang，前百度/微博工程师，现在专注于 AI 工程与工具产品。更多文章欢迎关注微信公众号「字与码」。
把 Octop 从 v1.0.2 升到 v1.0.3b2，重新编译跑通，顺手把同赛道的项目全扫了一遍，用 GitHub 接口拿了一组当天快照。
最刺眼的数字是这个：Octop 11,463 star，在我扫的 15 个项目里排最后一名。排第一的 OpenClaw 有 393,688，差 34 倍。排在它前面的还有 dsh（26.9 万）、Hermes Agent（26 万）、Dify（16 万）。
但如果把问题换成「哪个能装进自己服务器，给一个十人团队天天用」，顺序会整个翻过来。因为 star 数统计的是「有多少人觉得这事有意思」，不是「有多少人真的把它跑起来了」。这两个数字在这条赛道上几乎没有相关性。
01
先把赛道分开，再谈谁强
把所有项目塞进一张表按 star 排名，是这类文章最常见的糊弄办法。它们解决的问题根本不同：
| | |
|---|
| 个人助手 / 多用户对话平台 | 装一台，人和 agent 在那个界面或 IM 里长期对话 | OpenClaw、Hermes Agent、Octop、LibreChat、AnythingLLM |
| 可视化 Agent / 工作流平台 | | Dify、Langflow、Coze Studio、FastGPT |
| 编码 Agent | | OpenHands、Cline、Goose、Aider |
| 内核 / 框架 | | |
第一类是「产品」，第三类是「工具」，第四类是「零件」。拿零件和产品比功能，比出来的是废话。
所以下面的对比只在同一类内部横比，跨类只比「工程成熟度」这一项。
02
15 个项目的一组硬数据
数据来源是 GitHub REST API，2026-11-02 17:20 抓取。代码量取 /languages 接口的字节数合计，只统计代码文件，除以 35 大致等于行数——这是估算口径，不是 cloc 的精确结果。
最后一行是闭源的 WorkBuddy，没有可比数据，放在表里只作基准参照。它是商业产品：专家、技能、连接器、资料库、定时任务、企业微信集成、小程序发布。Octop 的内置技能里写死了 ~/.workbuddy/credentials/，两者的专家包结构（IDENTITY/SOUL/USER.md + manifest.json + skills/）完全同构——这条代码级证据我在上次的文章里已经写过。
同一时点、同一口径下的 star 分布。差距最大处有 34 倍。
03
技术栈：三条路线已经分完
TypeScript 一条：OpenClaw、dsh、Cline、OpenHands、LibreChat、FastGPT、Coze Studio。共同点是把 UI 当主战场，TypeScript 占比普遍 85% 以上，其中 Cline 是 97.9%。
Python 一条：Dify、Langflow、Hermes Agent、LangGraph、Octop。后端逻辑、模型编排、RAG 都在这边。
Rust 独一份：Goose，Rust 71.8% + TypeScript 23.5%。它的卖点是单二进制分发和本机执行，不用先装一个 Python 环境。
两条主流路线的实际差别在上手环节最明显：Python 系要处理虚拟环境和依赖冲突，TypeScript 系要处理 Node 版本和原生模块编译。今天升级 Octop 就撞了两个——完整 clone 因为网络断了三次，前端 vite build 在 D 盘直接报 winapi error #5，只能把工程复制到 C 盘构建。
技术栈的选择最终会变成这类具体的麻烦：装环境、编译原生模块、处理构建路径。图：Pexels
04
智能体架构：四种骨架
网关 + 插件（OpenClaw）：本地跑一个 Gateway 守护进程，管会话、工具、事件、渠道连接，Control UI / CLI / TUI 三个客户端接进来，再通过 Channels 层接 30 多个消息平台。模型和 agent harness（Claude、Codex、本地模型）都是可替换插件。它的架构原则写得很清楚：可信网关、不可信执行、策略由代码强制。
插件树 + 能力接缝（dsh）：Cordis 容器驱动，一切皆插件，官方有一篇论文讲这套时空可组合的编程范式。Bundle 组织插件，UI 用 slot 注册扩展点，LiveShare 做会话共享。但它明确标注是开发者预览，「未来将出现破坏兼容性的变更」，当前版本号 0.2.2-alpha。
单进程 + 后端抽象（Hermes Agent）：一个 gateway 进程同时服务 TUI 和 Telegram/Discord/Slack/WhatsApp/Signal。它的差异化在记忆：内置学习闭环，任务完成后自动创建技能、技能在使用中自我改进、FTS5 全文检索历史会话再用 LLM 摘要召回。
内核 + 多用户封装（Octop）：主仓不含 agent loop，内核在四个独立包（octop-harness / gateway / memory / browser），HarnessAgent 最后调 LangChain 的 create_deep_agent。外层补的是多用户、权限、专家、技能包、IM 通道这些平台能力。
剩下三个是「前端壳 + 后端服务」：Dify 和 Langflow 是可视化画布加执行引擎，Cline/OpenHands 是编辑器或容器里的执行器。
05
代码规模与参与人数
按代码字节分三档：
大型（>100 MB）：OpenClaw 490 MB、Hermes Agent 167 MB。这两个是真正的重工程。OpenClaw 有 124,140 个提交，Hermes 有 4,879 名贡献者——后者的数字比 Dify 的 1,595 还多一倍。
中型（20–100 MB）：Dify 91、Langflow 58、LibreChat 75、dsh 72、Coze Studio 37、FastGPT 33、Cline 32。
小型（<20 MB）：Octop 18、OpenHands 16、Goose 15、AnythingLLM 11、LangGraph 7.1、Aider 1.7。
贡献者数量分布更有意思：
- Hermes 4,879、OpenClaw 3,737：社区驱动，人多到可以开子项目
- Dify 1,595、Goose 676、OpenHands 590：公司主导 + 外部贡献
- LibreChat 422、Langflow 400、Cline 350、LangGraph 294、AnythingLLM 284、FastGPT 205、Aider 182
- Octop 74、dsh 66、Coze Studio 62
dsh 这个数字值得单独说：26.9 万 star，只有 66 个贡献者。这不是矛盾，是「DeepSeek 官方出品 + 开发者预览」的典型形态——热度来自品牌和期待，代码还集中在内部团队手里。判断它能不能上生产，看贡献者数比看 star 有用。
把这张图叠到上一张上，错位最明显的就是 dsh：star 排第二，贡献者排倒数第二。
06
热度：三个数字，三种含义
star 高 + 贡献者多（OpenClaw、Hermes）：真实社区，生态会自己长出来。
star 高 + 贡献者少（dsh、Octop）：品牌或话题驱动的关注，实际参与门槛还在组织内部。dsh 是 DeepSeek 出品，Octop 是腾讯云出品，都是「大厂开源、外部还没进来」的阶段。
star 中 + 贡献者中等（Dify、Langflow、Cline）：成熟商业项目，社区稳定但没有爆炸性增长。
还有一个容易被忽略的数字：Aider 最近一次推送是 5 月 22 日，Coze Studio 是 7 月 29 日。其余 13 个项目全都在 11 月 2 日当天有推送。这不是判决书，但选型时必须先点开 commits 页面看一眼——一个五个月没动的仓库，issue 里大概率已经积了一层没人管的报错。
07
上手难度
按「从零到第一次跑通」的实际步骤排：
一条命令：dsh（npx @deepseek-ai/dsh web，浏览器开 3080 端口）、Aider（pip install aider-chat）、Hermes（安装脚本，再跑 hermes setup）。
装个扩展：Cline 是 VS Code 插件，装完填 API Key 就能用。Goose 提供桌面版和 CLI。
需要理解概念：Dify、Langflow、Coze Studio 要先搞懂「应用 / 工作流 / 知识库 / 插件」这几个概念怎么组合，界面友好但心智负担不小。
要动手编译：Octop 从源码跑要走 venv + 前端构建 + 拷贝产物三步，Windows 上还要绕大小写冲突（BackendFlag.tsx 和 backendFlag.ts 仅差一个字母，rollup 会认错文件）。这条路的门槛不在技术，在耐心。
1440×900 的原始截图裁掉了四周空白，只留登录卡片。这台机器上跑的就是这个版本。
要看代码才懂：LangGraph 和 dsh，不读文档基本没法开始。
08
二次开发难度
这是 star 数完全测不出来的维度，但对企业选型最致命。
| | |
|---|
| OpenClaw（Plugin SDK + ClawHub）、dsh（一切皆插件，有 ADR 文档） | |
| Hermes（Skills Hub + MCP）、Octop（技能包可导出 ZIP、MCP 网关）、Cline | |
| Dify、Langflow、Coze Studio、FastGPT | |
| Octop、OpenHands、LibreChat、Goose | |
| | |
许可这块必须单独说。15 个项目里有三个不能按「开源」简单对待：Dify 和 FastGPT 的 GitHub 许可识别是 NOASSERTION——它们用的是带附加条款的 Apache 2.0，比如多租户运营要额外授权、不能移除官方品牌；n8n 用的是 Sustainable Use License，限制商业用途，严格说不算开源。真要商用，先读 LICENSE 文件，别信 README 里的「open source」四个字。
09
灵活性与功能边界
最灵活：LangGraph（你写什么它就是什么）、dsh（插件树可以替换几乎每一层）、OpenClaw（模型和 harness 都是可换插件，30 多个 IM 通道随便接）。
开箱能力最全：Dify（RAG + 工作流 + 多租户 + 日志）、Octop（多用户 + 专家 + 技能包 + IM 通道 + 定时任务 + 云端协同）、Hermes（记忆闭环 + 定时任务 + 六种终端后端 + 40 多个工具）。
最克制：Aider（就是终端里结对编程，1.7 MB 代码，不做平台梦）、AnythingLLM（文档聊天 + 无代码 flow）。
这里有个反向规律：代码量和灵活性不成正比。Aider 用 1.7 MB 做到了这件事里最难替代的一项（终端内的精准重构），Octop 用 18 MB 堆出了多用户平台；而 490 MB 的 OpenClaw 覆盖的是「所有设备 + 所有聊天软件」，那是另一种复杂度。
10
结论：按你的身份对号入座
| | |
|---|
| | 本地优先，直接接你天天用的 IM，记忆和技能会自己长 |
| 团队要一个自托管的 AI 工作台（多用户、权限、专家） | Octop | Octop 是国内这条路上唯一把「多用户 + 专家 + 技能包 + IM」凑齐的；LibreChat 成熟但重心在聊天前端 |
| | 拖拽即用，但注意 Dify/FastGPT 的许可边界 |
| Cline（编辑器内）、OpenHands（任务级）、Goose（本机通用） | |
| LangGraph（稳）、dsh（新，但破坏性变更会来） | dsh 现在是 0.2.2-alpha，别在这上面押生产 |
| | 闭源 SaaS，能力最全，代价是不能自托管、数据不在自己手里 |
最后说一句 Octop 的实话。它在这 15 个项目里 star 最少，理由很实在：2026 年 7 月才建仓，四个月做到 1.1 万 star，74 个贡献者，代码 18 MB。它不是「弱项目」，是「新项目」。判断它的方式不该是看排名，而是看它有没有解决你的问题——如果你的需求是「一台服务器、十几个同事、每人有自己的专家和技能、能从企微里直接用」，那这个池子里能直接拿起来用的，确实没几个。
11
参考资料
- GitHub REST API 快照，2026-11-02 17:20 抓取（star / fork / issue / contributors / languages）
- OpenClaw README 与官方架构文档（openclaw/openclaw）
- DeepSeek Harness README.zh.md 与架构文档（deepseek-ai/deepseek-harness）
- Hermes Agent README 与文档站（NousResearch/hermes-agent）
- Octop v1.0.3b2 源码实测，本机 Windows 11 + Python 3.12.15 + Node 22.22.2
- WorkBuddy 能力清单仅作定性对照，无公开仓库数据
