【开源推广】【长期支持】Gold Band -- 想成为你最后一款Agent桌面客户端

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是


• 我的开源项目完整开源，无未开源部分： 是


• 我的开源项目已链接认可 LINUX DO 社区： 是


• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是


• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

大家好，Gold Band已经更新半年了，公司内部也有很多同事都在用。我自己日常的需求也都是用Gold Band来完成了。现在想再次向大家简单介绍一下我们的产品。希望能够被更多朋友知道。

大家想知道长什么样，可以直接点击我们的线上demo地址体验一下UI设计。

https://gold-band.dion.blue/zh/demo#task-025?project=e-projects-code-ai-ji–a40d4379&run=run-001

tips：线上demo做了分辨率自适应，推荐用桌面端浏览器打开网页体验。线上demo受限，实际品质低于客户端，最终效果以客户端为准。

先说一下亮点

一句话介绍我们的客户端

主流agent客户端的体验+完整的工作流设计

适配 日常开发 和 大型需求的长时间无人值守开发

一句话说明你为什么要用我们客户端：

兼容主流acp agent，一个交互设计，多套harness切换。

完善的工作流设计，长程任务更稳定，更可观测，不依赖模型抽奖式分发。

1、多agent支持，主流agent一个客户端搞定，再也不用每个厂家用一个客户端了。

目前支持：claude code、codex、cursor、gemini cli、codebuddy、goose、qwen code、opencode、kimi code、amp、pi。

你也可以自定义接入所有支持acp协议的agent。

2、支持 直接会话、工作流、auto模式三种模式，胜任各种场景的任务。

3、工程化管理的工作流

每个节点可以单独配置模型、角色 和 结果判定方式。工作流支持回到过去的会话进行修复，支持发起新的round实现需求。

4、针对大型任务长程处理的AUTO模式

由节点拆分子任务并分发，每个子任务在worktree上处理，完成后由merge节点进行合并，由accept节点进行验收，然后根据当前结果再进行新的一轮分发。

tips：auto模式我们进行了多次实验，token消耗、用时都要优于codex的goal模式。后续会整理一个更典型、可复现的复杂需求进行公开对比。

下图为一个典型的auto模式工作流：

5、主流agent客户端有的能力我们基本都有

skill管理、mcp管理、角色管理、定时任务、需求管理（对接multica）、壁纸、头像、字体、主题、文件查看\编辑、源码管理、浏览器、im远程干预与通知（目前仅支持企微），主流agent客户端有的能力我们基本都有

6、轻量级客户端

使用tauri2+rust开发，安装包仅几十M，多会话并行客户端内存占用约300M左右。

再说一下问题

1.提供windows、macos、linux三版本客户端，但目前主要保证win10\win11的使用体验，amd mac和intel mac其次，linux版本目前还未进行完善测试。

2.目前核心能力使用是稳定的，但是交互设计上还是有一些小bug，我们正在疯狂解决、迭代中。

3.工作流和auto模式因为主要基于对抗式验证和loop思想进行需求实现，所以在耗时和token消耗上对比直接命令agent干活，肯定是有所增加的。但是工作流和auto模式也能帮助你减少返工次数。有时候慢就是快，多就是少。

4.移动端远程控制还没加上，该功能我们想把整个客户端按client → p2p/relay → host 架构重构一轮，所以可能需要等待一段时间。终端能力还没加上，这个会在最近的版本加上。

最后说一些提问

和 Coding Agent 内部的工作流区别是什么？

coding agent 内部的工作流主要还是两种

1.主 agent 编排子 agent 2.脚本编排 agent

可以这么说，我们和 coding agent 内部的工作流最大的不同是在于他们是编排session，而我们是编排harness，

而这里 harness 代表一套核心能力的差异，比如非常垂类的 harness ，只用来服务于某个特定领域，那只要它支持 acp ，就可以接入进来作为我们的一个节点；比如说最近很火的 deepseek harness ，可以实现各种个性化需求，也可以作为我们编排的一个节点；比如 codex cli ，他内置了一套 browser 和 computer 的 mcp 使用工具，那就很适合把 codex cli 作为一个专门的验收节点，比如说pi agent，极简的harness带来非常快的速度，那就很适合用于开发节点。

也就是说，我们这里的工作流节点的差异可以是一整套 harness 的差异，而不只是 session 上下文的差异，harness 在未来会更适合作为解决不同领域问题的能力单元。

和 Codex 等 agent 客户端的区别是什么？

codex 等客户端本质上是围绕某个固定agent构建的，给不喜欢 cli 模式的用户提供一个良好用户交互的agent桌面壳，可以说是我们客户端的下游，我们可以接入 codex cli ，并获得 computer use ，内置 browser use 这些能力。

我们的优势：我们属于 agent 的上层，可以切换使用不同架构的 agent ，而 codex 的主体 agent 架构是不变的。

我们的劣势：我们无法侵入 agent 内部设计，比如说 codex 可以很轻易地在 loop 循环中让用户的 prompt 实现“引导方向”这个能力，而我们的客户端就比较难实现，即使可以实现，成本也会比较大。

和 AIONUI 等其他 acp 客户端的区别是什么？

我们实现这个项目的初衷是为了做工作流，acp 客户端的能力是后面附加的，所以最大的差异也是我们实现了比较完整的工作流系统，不只是简单的调度一下，还涉及到验收标准，前文摘要，工作流的停止、继续，auto 模式下的节点归并等工程能力。而像 AIONUI 的桌面宠物，团队对话等能力我们目前还没有。其他的一些常见通用能力双方都具备。

和 orca 的区别是？

主要有三点区别：

1. 
   

   Agent 接入方式不同：Orca 主要直接运行各类 Agent CLI；Gold Band 主要通过 ACP 协议连接 Agent，因此可以用统一方式获得会话、工具调用、权限和状态等结构化能力。

   
   


2. 
   

   产品形态不同：Orca 更偏向终端、Worktree 和多窗口并行，更像面向 Agent 的 IDE / ADE；Gold Band 则以结构化会话为核心，更接近 Codex App 这类 Agent 桌面客户端。

   
   


3. 
   

   工作流理念不同：Orca 更偏向 Agent 自治、Runtime 辅助，由 Agent 通过 Skill 和 CLI 编排其他 Agent；Gold Band 则更偏向 Runtime 控制工作流，由 Runtime 管理节点推进、停止、失败处理和运行状态，Agent 更专注于当前节点的任务。

   
   

其他方面，比如远程运行、SSH、Worktree、终端、移动端和 Git 集成等，Orca 目前会更成熟一些，这部分也是我们后面会继续补齐的。

后续规划

我们的后续规划主要分为四个方向

1.优化客户端交互体验，解决一些已知的UI bug，让大家用起来更加顺手

2.完善工作流的工程化和易用性设计，包括任意节点重跑，自然语言创建工作流等

3.使用工作流和auto模式实现一个典型的极复杂需求，用于向大家说明我们的编排的有效性（我们团队已经在工作中的各个场景证明了工作流的有效性，但是可能这些场景离大家太远，所以需要更典型的场景来证明，如果大家有一些想法，也可以帮忙提供参考，我们来花token，来实现）。

4.client → p2p/relay → host 架构重构，重构后预计支持以本地、远程目录作为工作空间，并支持多端client操控一个host等。

感谢大家看到这里，欢迎大家多多star，试用，提issue。大家的意见对我特别重要，再次谢谢大家。