AI 编码 Agent 都是黑乎乎的终端？Juggler 用真实 GUI 和树状会话给你完全掌控

用了一段时间的 Claude Code、Codex 和 Cursor，你有没有觉得哪里不对劲？所有 AI 编码 Agent 的交互界面几乎都是一个模样——黑乎乎的终端窗口，往上滚动的对话历史，输出了上千行 Token 信息之后想找个之前的提醒比翻垃圾桶还费劲。

Juggler 的出现改变了这个局面。它是一个由 JUCE 框架的创造者 Julian Storer（Jules）亲手打造的开源 AI 编码 Agent，但和其他「又一款终端 Agent」不同，Juggler 带来了真正的图形界面、树状会话结构和插件化架构。

Juggler 使用 AGPL-3.0（应用层）/ Apache-2.0（SDK 层）开源许可证，Go + Wails 构建后端，前端用纯 HTML/JS，不依赖 Electron。

问题：终端交互的三大痛点

当你的 Agent 工作了 20 分钟后，终端里可能已经塞满了上千行 Token 数据、文件差异和错误信息。这时候你最想做的事情是：

1. 回溯查看之前某个决定是怎么做出的——但在线性聊天里，你只能上下翻页，还可能在滚动时弄丢当前的位置
2. 在不影响主流程的前提下尝试另一个方案——终端 Agent 不支持分支，你只能开启新会话从头再来
3. 查看具体某次工具调用的输入输出——所有信息混杂在一起，很难快速定位

这些问题不仅影响开发效率，更重要的是它们限制了你与 Agent 协作的方式。当 Agent 帮你写代码时，你本应是一个主动的协作者，而不是被动的信息接收者。

Juggler 的解决方案：从终端到图形界面

Juggler 对编码 Agent 的交互模式做了三个关键的改变。

1. 会话是一棵树，不是聊天日志

这是 Juggler 最核心的设计理念。在大多数 AI 编码 Agent 中，你的对话是一个线性记录——每一条消息按时间顺序排列，不能回溯、不能分岔。最多只能「回滚」到某个历史点。

Juggler 把会话变成了一个文档（Yjs document），而不是日志。任何一点都可以分支出一个子线程，子线程还能继续分支。你可以在树状结构中自由导航、回溯、对比两个分支的不同方案。

界面使用 Miller 列（Finder 的列视图模式） 来展示树状结构：最左侧是根会话，选中某个节点后右侧展开其属性和子节点。用过 Finder 列视图的人基本不需要学习就能上手。

2. 一切都是可见的

终端 Agent 会在屏幕上一闪而过大量信息，然后这些信息就永远消失了。Juggler 把「一切重要信息都变成可见的」作为设计原则：

• 工具调用可查看：每个 read-file、replace-text、bash 调用都有独立的 UI 卡片，可以看到完整的输入输出
• 属性面板：选中任意节点后，右侧面板展示该节点的详细属性、上下文 JSON 和状态
• 审批流程可视化：需要你批准的操作用清晰的 UI 展示，而不是混在终端输出里等你去找

3. 插件化到骨子里

Juggler 不是一个大而全的 monolithic 应用。它的扩展系统深入到各个层面：

// 一个简单的 Juggler 扩展示例（概念示意）
export default {
  name: 'my-custom-tool',
  execute: async (ctx, args) => {
    const result = await ctx.bash('npm test');
    return { success: true, output: result };
  },
  ui: (data) => `测试结果：${data.output}`,
};

所有可交互的元素都是 JavaScript 插件：

• Context items：每种项目类型（读取文件、替换文本、执行命令等）既是 LLM 的工具定义，又是 UI 渲染组件
• Strategies：plan、research 等高级循环策略也是插件，你可以写自己的策略
• Commands：/clear、/compact 等斜杠命令全部是插件

甚至最基本的 read、write、bash 工具也都是可替换的插件。

架构：轻量级，无 Electron

Juggler 的技术栈值得关注——它没有使用 Electron，而是选择了更轻量的方案：

这种选择带来了显著的性能优势：启动速度快、内存占用低、安装包小。macOS、Windows（通过交叉编译）和 Linux 均支持。

部署方式：桌面 + 远程

Juggler 的架构采用「本地 Web 服务器 + 多客户端」模式：

juggler   # 输出 Web UI 地址和二维码

同一个服务器可以连接多个客户端：原生桌面客户端、浏览器标签页、远程机器。这意味着你可以把服务器运行在开发机上，然后从任何地方用浏览器连接操作。

⚠️ 安全提醒：LAN 模式无密码保护，仅在信任的网络中启用。

在模型支持方面，Juggler 可以连接 Claude Code（通过 CLI 或 API）、OpenAI（codex plan 或 API）、Gemini、Ollama、OpenRouter、Z.AI、DeepSeek 等主流提供商，并且可以方便地添加更多 Provider。

实际使用体验

在我实际体验中，Juggler 最让我惊艳的场景是这样的：

场景：重构成一个模块的结构

我在重构一个 Go 服务的错误处理模块。从根节点开始：

1. Juggler 读取了 errors/handler.go（在工具卡片中展示了完整内容）
2. AI 建议了重构方案（作为一个节点）
3. 我让 Juggler 开了一个子线程来尝试方案 A
4. 回到主线程，再开另一个子线程尝试方案 B
5. 在两个分支之间来回对比差异
6. 最终选了方案 B，合并回主线程

在传统终端 Agent 里，这个过程需要开两个独立的终端窗口，而且没有办法对比两个方案的中间状态。Juggler 的树状结构让这一切变得自然。

局限与注意事项

Juggler 虽然理念先进，但目前仍处于早期阶段（GitHub 上约 15 颗星）：

• 生态尚不成熟：插件数量有限，社区贡献才刚刚开始
• 商用的 AGPL 限制：AGPL-3.0 要求修改版必须同样开源，商用需联系作者购买许可（SDK 层 Apache-2.0 不受影响）
• WAN 访问需要官方二进制（不是开源的），这是目前最大的功能限制
• Windows 需交叉编译，macOS 和 Linux 原生支持最好

总结

Juggler 不是「又一个 AI 编码 Agent」——它重新思考了开发者和编码 Agent 的交互方式。用真实 GUI 替代黑乎乎的命令行，用树状会话替代线性聊天日志，用插件化架构替代 monolithic 设计。

如果你已经厌倦了在终端中翻找数千行 Token 输出，或者希望更加主动地掌控 Agent 的工作流程，Juggler 值得一试。它可能不会取代 Claude Code 和 Cursor，但它的交互设计理念会影响整个 AI 编码工具的未来方向。

相关链接

• Juggler GitHub 仓库
• Juggler 官网
• JUCE 框架
• AGPL-3.0 许可证说明