8月9日，HN热榜上一款叫Juggler的开源项目冲到了280分、119条评论。作者不是某个VC烧钱的创业团队，而是一个人——Jules Storer（HN ID: julesrms），那个创造了JUCE的男人。
如果你用音频软件、做音乐插件、或者用过任何DAW（数字音频工作站），你已经在用JUCE。它是C++音频开发的事实标准框架，Adobe、Ableton、Korg、Roland都在用。Jules本人还是Tracktion DAW的创造者——最早一批数字音频工作站之一。
现在，这个写了30年C++的人，花了6个月时间，一个人造了一款AI编程Agent。
而他最不满意的，恰恰是当下所有AI编程工具的共同特征：它们都活在终端里。
▲ 图1
终端不是家，是牢笼
"用终端来做代码Agent的交互体验太糟糕了，"Jules在他自嘲式的项目介绍开头就这么说，"你需要编辑大段多行文本，需要扫描、导航、理解海量信息。终端不适合任何这些任务。"
这不是一个技术宅的无病呻吟。实际使用过Claude Code、Codex、Aider的人都知道那种体验：一个命令行窗口，一个不断滚动的文本流，你试图在几十次工具调用的淹没中找到那个关键的决策点，而LLM已经把上下文丢掉一半了。
Juggler的姿态很明确：我是真正的GUI应用，不是终端套壳。
Juggler的界面用了macOS Finder的"Miller列"设计——左边是根节点，向右展开属性、子节点、子线程。你看到的不是一个线性聊天记录（Jules管它叫"末日滚动"doom-scroll），而是一棵树。
会话不是聊天记录，而是CRDT文档
这才是Juggler真正的创新点：数据模型。
几乎所有现有Agent都把对话建模为消息列表——一条transcript，你可以往回滚但结构是线性的。Juggler把整个会话存储为一个Yjs CRDT文档（Conflict-free Replicated Data Type）。
什么意思？你的Agent会话不再是日志文件，而是可编辑、可分支、可协作的实时文档。
具体来说：
你可以创建子线程。 任何一个对话节点都能独立分支出一个新的探索路径。子线程还能再分子线程。你觉得Claude Code在某个问题上走了弯路？不需要reset整个会话，直接在出错的那一步前开出新分支，让Agent用不同策略重试。两个分支对比着看，哪个好留哪个。
会话是状态机，关机也能恢复。 因为整个会话是持久化在磁盘上的文档，你可以随时关掉应用，第二天打开，一切精确恢复到关闭前的状态。甚至Agent正在等你批准某个操作——那个审批对话框也会原样恢复。这在Headless服务器场景下尤其有用：服务器重启，Agent发现自己在干到一半的PR审核中，它停在原地等你。
多客户端同时连接。 Juggler本质上是一个本地Web服务器+桌面应用。桌面App是一个客户端，浏览器是另一个，手机是第三个。你在Mac上跑Juggler服务器，用iPad浏览器连上去看同样的会话——连审批操作都能在iPad上点。这套架构让"写代码的机器"和"监控进度的设备"可以分开。
一切皆插件
Juggler的另一个激进设计：核心引擎只管文档和编排，剩下的全是JavaScript扩展。
read-file、replace-text、bash——这些基本工具是插件。/plan、/research——LLM循环策略是插件。/clear、/compact——斜杠命令是插件。- 每个插件的UI也是插件——你可以给它加自定义面板、图表、可视化。
而且扩展SDK是Apache 2.0许可，你写的插件可以闭源商用。只有核心应用本身是AGPLv3。
这意味着Juggler不只是一种Agent，它是一个Agent平台。如果你有一个独特的编排思路需要自己的UI和控件，不用从头写一个IDE，直接在Juggler上扩展就行。
▲ 图2
技术栈：Go + Wails，干净得不像2026年的项目
Juggler用了Go后端+Wails窗口框架，前端是纯HTML/JS，没有Electron，没有TypeScript构建步骤。
安装包40MB。对，你没看错——一个功能完整的AI编程Agent，安装包跟一个小工具差不多大。Jules在介绍里特别强调了"No Electron"——不是因为他反JS，而是因为Wails把Go编译成原生应用，前端JS直接由Go HTTP服务器提供，零运行时开销。
它支持的原生桌面端：macOS（Intel+Apple Silicon）、Windows、Linux。Headless模式可以跑在无图形界面的服务器上。
支持的模型：Claude Code（CLI或API模式）、OpenAI（Codex计划或API）、Gemini、Ollama、OpenRouter、Z.AI、DeepSeek等等。添加新Provider只要写一个插件。
HN社区的集体共鸣
Juggler发到HN后不到12小时，就炸出了这个社区长期压抑的真实需求。
最高赞评论区有人感慨："都快3年了，AI编程这场狂欢居然还没有Reddit/Slack式的子对话线程——我们一直在线性滚屏里迷失。"
另一个人说："我在周末刚刚在找这样的东西。命令行工具很多，GUI的几乎没有。"
也有人提到ACP（Agent Communication Protocol）支持可以让Juggler成为自己的Pi替代品——毕竟Pi的用户群已经被插件生态锁定了，迁移成本高。Jules在回复中明确表示ACP兼容在路线图上。
最意味深长的一条评论来自一个走了相反方向的人："我做的东西跟你完全反着来——被Zed、Cursor和各种GUI Agent工具烦透了，自己写了个终端TUI Agent。"这种分裂恰恰说明AI编程工具还远没到"一个问题、一个答案"的阶段。
还有人在点赞JUCE的老用户情怀——"谢谢你创造了Tracktion（我2006年用的第一个DAW）和JUCE"。
对AI创业者的启示
Juggler的出现不是偶然。它是AI编程工具市场演进的一个必然分叉。
过去两年，AI Coding Agent领域基本被两个趋势主导：一是集成到IDE里的（GitHub Copilot、Cursor、Zed），二是活在终端里的（Claude Code、Codex、Aider、OpenCode、Pi）。前者牺牲灵活性换取即时性，后者牺牲可视化换取可编排。
Juggler指出了第三条路：Agent交互本身应该是一个可视化的工作台，不是聊天窗口，也不是终端面板。
这里的创业机会至少有三个层面：
第一，Agent的"操作界面"还没被定义。 就像1984年Macintosh定义了个人电脑的GUI范式，Juggler在尝试定义AI编程Agent的交互范式：树形会话、Miller列导航、可检查的工具调用属性面板。这会不会成为行业标准？至少Jules的履历值得认真对待——他定义的JUCE API至今仍是音频行业的骨架。
第二，"会话即文档"的产品思路可以迁移。 Juggler用CRDT把Agent会话建模为持久化文档，而不是瞬时的聊天记录。这意味着Agent会话可以版本控制、可以协作编辑、可以审计回溯。企业级AI编程工具的差异化，很可能就在"会话文档化"这个点上。
第三，插件平台是护城河。 Juggler选择AGPLv3许可核心+Apache 2.0许可扩展SDK的策略非常老练——核心开源建立信任和社区，SDK宽松许可鼓励商业插件开发。既不是完全封闭（像Cursor），也不是完全放任（像某些纯MIT项目）。这种"核心强传染、生态自由"的许可组合，可能是AI工具开源的甜点区。
一点冷静
当然，Juggler才发布不到24小时。GitHub上556个Star、42个Fork、385次Commit——对于一个刚发布的项目来说是很好的开局，但它还面临几个硬仗：
一是生态从零开始。Pi有1400+个MCP工具和几十个社区策略，OpenCode有一整套可插拔的MCP Provider架构。Juggler的插件体系虽然设计优雅，但现在几乎只有作者自己写的几个基础扩展。
二是DeepSeek等模型兼容性还有坑。评论区已经有人报bug：接DeepSeek V4 Pro报LLM错误。这在情理之中——六个月的一个人开发，多Provider兼容是第一版最容易出问题的地方。
三是GUI是否真的比终端更高效。这是一个没有定论的问题。VS Code的用户群体大到不需要回答这个问题，而vim/emacs的用户也活得很好。Juggler选择站在GUI这一边，市场会用装机量投票。
但有一个事实是确定的：当一个写了三十年C++、创造过行业标准框架的工程师，因为"受够了"而决定自己造一个AI编程工具时——这个领域的现有产品和用户体验，一定有系统性的不足。
Juggler不会干掉Claude Code或Cursor。但它在提醒整个行业：我们对AI编程Agent的交互应该是什么样子，想得还不够多。
*来源：GitHub - juggler-ai/juggler | juggler.studio | HN讨论*
本文由AI辅助创作，经人工审核编辑发布
更多一人公司案例与工具，微信搜索「AI创业内参」关注我们