⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/odysseus-ai-workbench/ 「芋道源码」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注微信公众号:【芋道源码】有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

2026 年 5 月 31 号,GitHub 上多了一个叫 odysseus 的仓库。五天后,它拿到了五万多个 Star。这个增速放在整个开源圈都少见,值得认真看看它到底是什么东西。

先说这个项目是什么

它不生产模型、不训练模型、不微调模型。它是一个工作台,把 ChatGPT 那种对话体验搬到你自己的机器上,数据不出门,不经过任何第三方服务器。

作者是 PewDiePie。他在 README 里写得很直白,这东西想做的是自托管版的 ChatGPT 和 Claude 界面体验,只是会多些瑕疵。

现在的仓库地址已经迁到 odysseus-dev/odysseus,Star 八万七千多,默认分支是 dev,许可证是 AGPL-3.0-or-later。这一点后面还会提到,因为它直接影响你能怎么分发。

odysseus-dev/odysseus 仓库首页,Star 87.6k

它底下接了三套正经的开源基础设施。Agent 能力跑在 opencode 上,Cookbook 的硬件扫描和模型推荐跑在 llmfit 上,Deep Research 模块脱胎于阿里通义的 DeepResearch 项目。这三样拼在一起,形成了一个我在别处没见过的组合。

应用的首屏与左侧导航

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

先扫硬件,再决定跑什么模型

Cookbook 是这个项目里我最想先讲的部分,因为它解决的是一整套最劝退人的流程。

打开它,第一步是扫你的硬件,CPU 型号、内存、VRAM 大小、GPU 支不支持 CUDA,全扫一遍。扫完之后,它从 270 多个模型里筛出能在你这台机器上跑的那一批,按适配度排序。点一个,自动下载,自动启动推理服务,接着在 Settings 里加一个 endpoint 就能用。

以前想跑个本地模型是什么流程呢。先去 HuggingFace 翻 GGUF 文件,再弄清楚 Q4_K_M 和 Q5_K_M 差在哪,然后配 llama.cpp 的参数,调半天还不一定跑得起来。Cookbook 把这堆操作压成了一个按钮。

也不是没有代价。它依赖 tmux 做后台下载,Windows 上得额外装 Git for Windows 才能用。macOS 上 vLLM 和 SGLang 完全跑不了,只能用 llama.cpp 和 Ollama。这些限制官方文档里都写了,不算暗坑,但装之前得知道。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序,支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

另外七个模块,各管一件事

Chat 是最基础的一个,标准对话式界面,跟 ChatGPT 和 Claude 的网页版长得差不多。后端支持 vLLM、llama.cpp、Ollama、OpenRouter、OpenAI 和 GitHub Copilot,想用哪个加哪个,切换很方便。

Chat 与 Agent 界面,左侧对话列表右侧聊天窗口

Agent 是能力最强也最需要小心的一块。它基于 opencode,能调 MCP 工具、读写文件、执行 shell 命令、上网搜索,还有持久记忆。你给它一个任务,比如把 Downloads 里所有 PDF 转成 Markdown 再按日期分类,它会自己规划步骤然后干活。

风险也在这里。开了 shell 权限之后,理论上存在被注入恶意命令的可能。官方文档写得很清楚,非管理员默认不给 shell 权限,部署时不要把端口暴露到公网。把能跑 shell 的 Agent 当玩具随便部署,早晚要出事。

Deep Research 负责联网做研究。输入一个问题,它自己去搜资料、读网页、做摘要,最后生成一份结构化报告,界面上能看到它一步步打开网页、提取信息、组织内容。作者拿一个问题实测了一轮,大概八分钟,翻了十几个网页,输出了一份带小标题的报告。质量中规中矩,但确实省了自己开网页的时间。

Deep Research 的研究步骤与来源面板

Compare 做的是模型盲测。输入一个 prompt,选两个模型同时发过去,结果并排展示,但你看不到哪个结果是哪个模型出的。自己判断完,点 reveal 才揭晓。这个设计把品牌偏见直接干掉了,很多时候所谓的「大模型排名」在具体任务上根本不成立。

Compare 的两栏盲测输出

文档编辑器支持 Markdown 和 HTML,带语法高亮。AI 能帮你改写、提建议,但不替你从头写。作者在 README 里的原话是,文字你自己写,AI 是来帮忙的。

文档编辑器的语法高亮与 AI 辅助

笔记与任务这块,快速笔记带提醒,有待办清单,还能设定时任务让 Agent 自动执行。通知渠道支持 ntfy、浏览器和邮件三种。

笔记与任务界面

邮件和日历是最后一块。邮件走 IMAP 和 SMTP,AI 会自动分类、做摘要、草拟回复,还能识别垃圾邮件。日历走 CalDAV 协议,能同步 Radicale、Nextcloud、Apple Calendar、Fastmail 这些服务,Agent 可以直接读写你的日程。

官方把这些之外的零碎功能归在一个 Extras 分组里,包含图库与图片编辑、主题、文件上传、网页搜索、预设、会话管理和两步验证。它们的共同点是平时想不起来,真要用的时候不希望没有。

实话实说,这一套是作者自己用得最少的,跟做得好不好没关系,大部分人早就有了用惯的工具。这个项目的野心是让你不需要别的工具,如果你正好在搭一个完全离线的个人工作环境,一个 docker compose 能把七八个应用全起来,那确实省事。

跑起来需要几步

作者的实测环境是 Ubuntu 22.04,用 Docker 部署。官方 Quick Start 是四条命令。

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
cp .env.example .env
docker compose up -d --build

容器起来之后打开 http://localhost:7000。首个管理员密码不是在界面上设的,是打命令从日志里取出来的。

docker compose logs odysseus

拿到密码用 admin 登录,改掉密码,再进 Settings 配置模型。从 clone 到第一次对话不到十分钟,在自托管项目里算顶级体验,比 Open WebUI 的初始配置还简单,因为模型下载和配置那部分被 Cookbook 包掉了。

没 GPU 也能用。接上 OpenAI 或者 OpenRouter 的 API key,Chat 和 Agent 照常跑,只是 Cookbook 的本地模型推荐对你没什么意义。

有两个平台差异要提前知道。macOS 上 Docker 用不了 Metal GPU 加速,官方给了 start-macos.sh 脚本让你原生跑,但即便如此 vLLM 和 SGLang 也不支持 macOS,只能用 llama.cpp 和 Ollama。Windows 那边有 launch-windows.ps1,另外 Cookbook 的完整功能依赖 Git for Windows 提供的 bash.exe。

还有一条容易忽略的。默认分支是 dev,也就是说你 clone 下来的不是最稳的那份代码,想要更克制的版本得显式切到 main。做生产部署的话,这个选择值得先想一下。

硬件是绕不过去的那道门槛

作者在自己视频里展示的是一台两万美元的多 GPU 机器,跑 Llama 3.1 70B 跟喝水一样简单。这不是普通人的配置。

常见一点的情况是这样。一张 3060 12GB 跑 8B 模型没问题,13B 模型要 4-bit 量化才能勉强跑起来。没有独显的笔记本,接 API 是唯一实用的选择。

这不是这个项目的问题,是大模型推理本身的限制。官方 README 里写得很清楚,应用本身很轻量,重的是本地模型服务那部分,取决于模型、运行时、GPU 和上下文长度。

代码质量与那场争议

作者自己承认,这个项目的代码绝大部分是 AI 生成的。他对着 Claude 和 GPT-4 描述想要什么功能,把代码贴进去,跑一下看效果,不行继续让 AI 改,很多代码还是在手机上写完的。

Star 随时间的增长曲线

结果是一个功能完整的 AI 工作台,加上六百多个社区 PR。社区的反应非常两极。一边觉得,一个没受过正规编程训练的人靠 AI 辅助做出了正经能用的产品。另一边觉得,代码质量堪忧,安全性打了折扣,作者的粉丝可能不了解风险就装上跑。

作者翻了几眼源码,两边说的都有道理。确实有些地方写得随意,异常处理不完整,模块耦合有点紧。但这也不是我见过最差的代码,说句实话,手写项目里不如这个的大把。社区进来之后重构速度很快,第一波 PR 就有人在整理架构、加测试、修安全漏洞。

项目采用 AGPL-3.0-or-later 。它对再分发的要求需要单独核对;如果你打算把它集成进自己的产品对外提供服务,先把许可证读完再动手。

我的判断

它不是一个完美的项目。代码有粗糙的地方,安全需要自己多加小心,部分功能处于能用但别太依赖的状态。

但它做了一件挺重要的事,把 AI 工作台从云端搬到本地,而且门槛低到普通用户能接受。Cookbook 单拎出来都值得一个独立项目,Agent、Deep Research、Compare 这些模块的整合方式,说明作者对「用户到底需要什么 AI 工具」是想过的。

Vibe Coding 这件事我的态度比较简单,代码是手段,产品是目的。粗糙可以打磨,现象级产品的第一版通常也都是能用就行。

选不选它看你的机器和你的洁癖。有好 GPU、对数据隐私有要求、想把对话体验装在自己电脑上,值得装一个。轻薄本想跑本地模型就先算了,接 API 用 Chat 模式已经够。

仓库地址是 https://github.com/odysseus-dev/odysseus

文章目录
  1. 1. 先说这个项目是什么
  2. 2. 先扫硬件,再决定跑什么模型
  3. 3. 另外七个模块,各管一件事
  4. 4. 跑起来需要几步
  5. 5. 硬件是绕不过去的那道门槛
  6. 6. 代码质量与那场争议
  7. 7. 我的判断