只有 33 个 star 的 Agent 客户端被 OpenAI 送 1200 美元，我们是怎么做到的？

距离上次在 V2EX 分享我们的项目已经过了快 3 个月了。

在上周，我们维护的开源项目diodeme/Gold-Band通过了 openai 的开源开发者活动，获得了 openai 赠送给我们的价值 1200 美元的六个月 gpt pro 20x 会员。很多社群的朋友好奇为什么我们项目只有 33 个 star 也能被选中，于是我准备专门写一篇帖子，向大家重新介绍下我们的项目，并在文末分享下我申请开源活动时是怎么填的。

产品介绍

github 地址： https://github.com/diodeme/Gold-Band

一句话介绍我们的项目：

一个跨端的桌面客户端。 以 ACP+工作流的方式编排 agent ，同时兼具市面上主流 acp 客户端的交互体验。

虽然产品已经大变样，但是一些底层能力还是共通的，本次介绍就不针对技术细节做展开了

我们的项目用 tauri2 实现桌面壳，rust 实现后端，应用本体仅50+MB，启动后应用本身常驻内存 200MB，多会话并行时内存占用在 300MB 左右（这里所指不计入 agent 自身的内存占用）

至于我们为什么要做这个产品：其实最开始的用意，我们只是想做一个工作流。

因为我们发现市面上所有的顶尖模型，在单次完成后，让其再 review 一遍都会发现非常多的功能和质量缺口，也就是说在当前时点，所有模型都无法达到一个良好的一次完成率（除非你的需求本身很简单）。

而如果使用 skill 等方式强化 agent 内部的 loop 能力，又会发现在一个 session 中上下文窗口不断累积，造成模型注意力偏移，要么就是越走越偏，要么就是谎报完成。

所以当时我们有一个朴素的理念，这种长程的对抗式校验–>修复循环，必须要用工程手段来解决。而在研发过程中，我们发现如果想让这个应用用的舒心，就不能让用户一直在不同应用间切来切去，所以我们最后逐渐发展成了现在这个可以即能直接对话、又能工作流编排的一站式 acp 客户端。现在我们客户端的迭代也是用客户端自身来做的，使用轻量工作流，晚上睡觉前运行起来，第二天早上就能得到一个质量相当不错的结果了，而代价就是你的 token 燃烧速度肯定是要比直接 vibe coding 快一些的。

使用教程

其实我们的应用大家下载下来应该就会使用了，因为主线流程和 codex 或其他主流 acp 客户端的交互逻辑是差不多的，接下来我再结合真实截图带大家过一下整体流程。

会话前

添加好 agent ，确认角色和 skill

在运行模式中配置自己准备运行的工作流

快速对话页可以选择运行模式，并决定是在 worktree 中还是主工作区发起会话，是直接发送还是定时任务发起。

会话中

实时查看会话，并观测过程中的各种指标

特殊的，当你停止正在运行的工作流时，会新增一个继续工作流按钮（如果你输入了消息则是继续并发送），此时发送消息会变成类似 direct 模式直接和 agent 对话，只有当你点击了继续工作流，才会继续交回给我们 runtime 接管。

会话后

可以查看每轮会话的 diff 快照，或在右侧工作区查看 git diff 、工作区文件，或选择提交、拉取、推送代码

个性化

在设置中给应用加上壁纸和头像

功能清单

太长可以不看，直接跳转下一章即可：

1.上下文管理：统一管理角色、skill 、mcp ，并带给任意一个接入我们应用的 agent 。

2.多 agent 支持：内置支持 claude 、codex 、cursor 、gemini 、codeBuddy 、goose 、qwen code 、opencode 、kimi code 、amp 、pi ，用户亦可以自己自定义任意一个 agent 接入。

3.定时任务：支持单次、重复、自定义 cron 等方式发起，支持多个定时任务在一个会话中延续。

4.工作流编排：支持在画布中用可视化方式编辑工作流，并给每个节点自定义角色、目标、模型、权限和验收方式。

应用内置两套默认工作流： 完整：需求–>方案–>开发–>审查–>测试–>验收–>清理 其中审查和测试失败会回到开发节点修复，验收不通过进入新的 round ，验收通过进入清理节点 轻量：需求–>开发&测试–>验收 用户亦可以自定义任意一个自己想要的模板。

5.会话交互：同一个输入框支持 1.直接和 agent 发起对话 2.使用预设的工作流编排多 agent 3.agent 自动编排工作流 三种方式发起对话

支持在 worktree 中发起会话。 支持上传文本附件、图片、支持选中 agent 文本作为引用。 支持会话消息排队发送并调整顺序。 支持每轮会话结束后实时查看该轮的 diff 。 支持实时查看会话用时、上下文窗口占用、token 输入输出缓存命中等观测指标。

6.源码管理： 支持在右侧工作区实时编辑、查看工作区文件，支持 md 预览、编辑一键切换。 支持在右侧工作区用 git 实时管理项目源码，支持 commit 、push 、fetch ，查看任意多个 commit 的 diff 汇总，管理 branch 、tag 、stash 、worktree ，实时查看、管理 github 的 pr 和 issue 。

7.个性化： 主题包、字体栈、壁纸、头像等。

这里是我目前能想到的，但不一定是全的，基本上我们就是在尽力对标 codex的使用体验，后续也会持续在体验上投入精力，让大家用的更好。

一些问题

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

codex 等客户端本质上还是一个 agent ，是给不喜欢 cli 模式的用户提供一个良好用户交互的桌面壳，可以说是我们客户端的下游，我们可以接入 codex cli ，并获得 codex 客户端中 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 。只要 Agent 支持 ACP ，Gold Band 就能用统一协议获得会话、工具调用、权限和状态等结构化能力，理论上更容易保持一致的适配体验，但最终还要看 ACP 生态的发展。

2. 产品形态: Orca 的产品形态仍然以终端、Worktree 和多窗口并行为主，更像面向 Agent 改造的 IDE/ADE ； Gold Band 则以结构化会话为核心，更接近 Codex App 这类 Agent 客户端。

3. 工作流编排: Orca 目前还没有类似 Gold Band 的固定 DSL 、可视化工作流和由 Runtime 自动推进节点的能力，主要依靠 Agent 通过 Skill 和 CLI 编排其他 Agent 。Gold Band 除了固定 WORKFLOW ，也有理念相近的 AUTO 模式，让 Agent 动态规划和编排后续工作流，但由 Runtime 校验并管理实际运行状态。也就是说工作流这里 orca 理念是 agent 自治，runtime 辅助，我们是 runtime 控制工作流，agent 更关注自己的工作。

其他能力方面，例如远程运行、SSH 、Worktree 、终端、移动端和 Git 集成等，Orca 目前会更成熟一些，后面我们也会追赶这部分的体验。

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

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

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

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

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

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

后续规划

我们项目目前除了开源，也会在企业内部进行推广，会有一个小团队兼职进行开发，维护力度上应该是可以保证的。

后面我们主要会优先把目前应用的一些已知 bug 解决，然后稳定应用的生命周期。

功能上目前在排的有：

1.接入 multica 等项目管理工具 2.接入企微、飞书、电报等 im 工具 3.桌面宠物

在研究的有：

1.侧边会话 2.跨端 agent 会话同步 3.更多个性化的主题、比如像素风格等等

Codex 开源活动申请攻略

申请链接见 https://openai.com/form/codex-for-oss/

这里有个很重要的点，就是这个活动申请其实并没有说明要求 star 最低多少

下面是规则里的要求：

所以其实任何一个项目都能去申请一下试试看，能不能过完全看 openai 那边审核的想法。 当然在申请界面还是需要你去写一些诸如 star 数的指标的

我们项目之所以 33 个 star 能够获取，我觉得可能还是因为我们在 agent 编排这里做出了一些特色。 然后这里一个项目下其实所有人都能申请，但是他不一定给你过，应该是会根据项目规模决定给几个维护者。以我们项目为例，我去申请第二天就过了，但是其他维护者去申请就没有过。

下面是我申请时写的内容，大家权当参考：

Why does this repository qualify ？

Gold Band is an AGPL-3.0 desktop client for Codex, Claude Code, and other ACP agents. It supports direct conversations, deterministic DSL-defined workflows, and AI-generated parallel workflows for complex tasks. Users can manage agents, Skills, MCP servers, permissions, artifacts, and run history in one place. Since launching in March 2026, it has received 32 stars and 2,859 release-asset downloads across 15 releases. It keeps long-running agent work open, inspectable, and provider-neutral.

  

How will you use API credits for your project?

We will use the API credits to continue developing Gold Band, ship new features, improve reliability and user experience, and support more agents and workflows. Our goal is to build an open-source desktop platform where developers can access, configure, and coordinate multiple coding agents in one place. The credits will help us iterate faster and make multi-agent collaboration practical for everyday development.

  

Anything else we should know? （这里舔了一下 openai ）

Throughout Gold Band's development, GPT has been our primary model, from GPT-5.2 through GPT-5.6 Sol, and the Codex app is now our main development tool. Codex has influenced both our implementation work and many of our interaction design decisions. Gold Band will remain open source and actively maintained. As we expand outreach and contribute more actively to the community, we will openly share how Codex supports the project and our development process.

  

最后的最后

感谢各位朋友看到这里 欢迎大家点点 star ，多多试用 也欢迎大家踊跃反馈 bug 、提 issue 、pr 该条帖子我会长期回复 如果我们的工具能帮助到大家一点，我就已经很高兴了

如果总结这几个月的开发过程，我想说的是：

开源的第一步是相信自己的产品很特别，第 2~99 步是认识到自己的产品并不特别，第 100 步是坚信自己的产品依然特别。

我现在也才刚走出我的第二步。