• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Diodeme
V2EX  ›  程序员

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

  •  
  •   Diodeme · 13h 7m ago · 1284 views

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

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

    产品介绍

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

    一句话介绍我们的项目:

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

    image.png

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

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

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

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

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

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

    使用教程

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

    会话前

    添加好 agent ,确认角色和 skill image.png

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

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

    image.png

    会话中

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

    image.png

    image.png

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

    image.png

    会话后

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

    image.png

    image.png

    个性化

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

    功能清单

    太长可以不看,直接跳转下一章即可:

    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 最低多少

    下面是规则里的要求: image.png image.png

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

    image.png

    我们项目之所以 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 步是坚信自己的产品依然特别。

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

    Supplement 1  ·  10h 48m ago

    感谢v站大佬建议,附上邮件截图证明

    13 replies    2026-08-29 00:13:10 +08:00
    yuiffy
        1
    yuiffy  
       12h 23m ago
    不错哦,原来 openai 还有这种好事,等我有了合适的开源项目也去申请下
    keakon
        2
    keakon  
       12h 19m ago
    申请通过后,好像还是要国外信用卡才能开通吧?
    neilp
        3
    neilp  
       12h 18m ago
    其实 openai 送了很多. 我没有主动申请过, 但是它主动给我发了两个 x20 pro.
    Diodeme
        4
    Diodeme  
    OP
       12h 14m ago
    @keakon 对,这一步是比较麻烦,我是刚好有个朋友在国外,用朋友的卡开的
    Diodeme
        5
    Diodeme  
    OP
       12h 13m ago
    @neilp 这是大佬才有的待遇了
    Diodeme
        6
    Diodeme  
    OP
       12h 13m ago
    @yuiffy 嗯呐,可以试试的,参与别的开源项目也可以申请,不一定非要是自己维护一个
    hikarugo
        7
    hikarugo  
       11h 26m ago
    咱就是说,长篇大论之前,能不能先放个 OpenAI 赠送的证明?

    “距离上次在 V2EX 分享我们的项目已经过了快 3 个月了。” 一没有给出上贴地址,二你隐藏自己主题但回复列表却找不到上贴相关的内容。我通过站内搜索才找到 https://fast.v2ex.com/t/1216451 确认确实存在“上贴”,上贴就是很典型的推广非要放到程序员节点然后 0 回复惨案,这次就带上 OpenAI 蹭热点,so ,最关键的热点证明是起码的吧?你不能自己替“OpenAI 送价值”,再自己替“社群的朋友好奇”,最后引出“重新介绍下我们的项目”。

    最后,这种长篇介绍看了两句完全没有看下去的欲望,我很怀疑是不是 AI 写的。
    androidCoder
        8
    androidCoder  
       11h 23m ago
    @hikarugo 现在长篇大论,一律按 AI 处理。。
    Diodeme
        9
    Diodeme  
    OP
       10h 51m ago
    @hikarugo 感谢大佬提醒,这些问题是我考虑不周了,起因是我是先在 L 站发的帖子: https://linux.do/t/topic/2740096/6 ,询问大家怎么激活送的 pro 会员,下面有朋友说没想到我们 star 数比较少也能过,所以我也想着趁这次机会宣传下我们的项目。这里可以看我的帖子,或者我的邮件截图: https://static.dion.blue/2026/08/%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_17879085785851.png 。

    大佬说得对,这次我确实是抱着蹭热点的想法来推广的,因为前面几次宣传效果都不是很好,用的人都不是很多,我本身技术人员出身,也是第一次推广宣传,所以还不是很清楚该怎么做最好,有一些操作可能看起来比较迷,还请大佬见谅。

    另外这篇推文我原来也在想是否要放到发现创造里,但考虑里面涉及到一部分是分享开源活动申请的方法,所以最后还是放在程序员板块了。

    最后是这篇文章是我纯手敲的,连 AI 润色都没有,因为有一次在 L 站发帖子用了 AI 润色,被拒了,后面为了避免麻烦,都是手敲的了,欢迎大佬用各种方式鉴定。至于看了两句没有欲望看下去,那确实是我自身文章功底薄弱,如果真是 AI 写的,应该比现在好得多。

    后面再在 v 站发帖子,我会好好注意下这些问题的,感谢大佬的指教。👍
    Diodeme
        10
    Diodeme  
    OP
       10h 50m ago
    @androidCoder 大佬,我是纯手敲的,可以参考我上面的回复
    Diodeme
        11
    Diodeme  
    OP
       10h 45m ago
    @hikarugo 另外我的主题列表隐藏已关闭,这个我之前都忘记还设置了这个,感谢大佬提醒并附上了我上篇帖子的链接。🙇‍
    PowerDi
        12
    PowerDi  
       4h 43m ago
    这个跟 codeg 风格好像呀
    Diodeme
        13
    Diodeme  
    OP
       4h 0m ago
    @PowerDi 是有些相像,但我们目前除了常见的 acp 客户端的 ADE 式体验外,还有一个重点是通过由系统控制运行的工作流(人工定制或者 AI 自分发)去解决 agent 处理大任务时难审计难把控质量的问题。
    所以我们的场景除了常见的对话式解决日常需求,还有一个重点就是针对大规模的、长程任务的处理,希望能真的做到人只需要确认需求和方案,后面的完全由 ai 去一把实现。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   901 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 36ms · UTC 20:13 · PVG 04:13 · LAX 13:13 · JFK 16:13
    ♥ Do have faith in what you're doing.