本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 自从去年底 DeepSeek V3.2 发布后，我就从代码补全爱好者逐步转变成了 vibe coder。在最初的那个月里，我陆续使用了很多 coding agents，只有 2 个给我带来过惊喜：Claude Code 和 OpenCode。前者主要是因为它的模型强大和功能完善，后者则是它可以组合多种模型且可以自由定制。 而在我逐渐因为费用问题转向 OpenCode 后，我陆续给它添加了很多功能，例如给模型配置多个 key，以及给 agent 配置多个模型，在遇到 429 等限速时可以切换到其他可用的 key 或模型。可是当我想把这个 PR 推给上游时，却石沉大海。而我为了保持这个功能可用，不得不每天同步上游改动并修复冲突。那时我才关注到，OpenCode 已经是一个有几千 issues 和 PR 的超大项目了，而它的团队显然已经无法正常维护这个开源社区了。 为了响应国家号召，不让吃饭用的核心工具被卡脖子，于是我在今年春节期间开始了造轮子的历程。 Phil Karlton 曾说过「计算机科学中最难的两件事是缓存失效和命名」，而最初的几小时我全花在了选名字上。在定下 Chord 的那一刻，我已经解决了一半的难题。 后续的选择就容易多了： 在形态上，我毫不犹豫地选择了终端应用：VSCode 插件寄生于 VSCode 生态，过多的限制会让开发不自由；桌面应用的兼容性和开发难度较高，且资源占用过多；而终端是最能跨平台的方案，且能在小内存的 VPS 上运行。 至于编程语言，我自然选择了熟悉的 Go，毕竟出了问题也要自己能懂才好改。 然后我就让 OpenCode 帮我收集其他 coding agents 的资料和源码，让 Claude Code 出架构设计方案，再用 OpenCode 进行实现，仅花了约 3 天就完成了最小可用版。 至此，就像编译器自举一样，Chord 也开始了自迭代的过程，一周后就已经比 OpenCode 更顺手，成为了我的主力开发工具。 虽然代码可以靠 AI 自进化，但当自己的角色转变成产品经理后，每天都需要关注最新的技术，做大量的调研和抉择。也是在这期间，我定下了 Chord 最重要的调性：省钱+高效。 为了省钱，我参考了 Dynamic Context Pruning Plugin 、 RTK 和 Headroom 等很多开源项目去做上下文剪裁，通过分析历史会话来调整最佳阈值，以确保缓存稳定性和上下文剪裁达成成本最优的平衡。 为了高效，我参考了 Claude Code 在还未结束流输出时，就提前执行安全的工具调用，以及当 shell 命令运行过久时自动移到后台，让模型可以并行处理其他的事项。 个中的很多细节，没做过是永远不知道里面的门道的。我也很庆幸在开发 Chord 的过程中，收获了大量的经验和令我满意的结果——使用 deepseek-v4.1-flash 模型跑同一个 DeepSWE v1.1 任务 ，Chord 0.8.1 在当下最流行的 coding agents 中用时最短、成本最低： 工具 耗时 成本 Chord 0.8.1 6m37s ￥0.348 deepseek-harness 0.1.5-rc.1 9m50s（1.49 倍） ￥0.527（1.51 倍） pi 0.85.1 10m22s（1.57 倍） ￥0.576（1.65 倍） codex 0.154.0 17m01s（2.57 倍） ￥0.929（2.67 倍） mini-swe-agent 2.4.6 18m29s（2.79 倍） ￥0.835（2.40 倍） claude code 2.1.272 22m25s（3.39 倍） ￥1.104（3.17 倍） 当然，省钱和高效只是 coding agent 的基本要求，用户体验才是最让产品经理头疼的。我的方法也很简单：哪里用着不爽，我就解决哪里。这里举 3 个当时几乎没有任何 TUI coding agent 做好的事项： 在长会话中定位一条消息不该这么麻烦：面对上千条消息，我经常需要跳转到开头或结尾，也可能想看看上一条模型回复，或是复制消息内容；这其实是很容易能做到的事，可是在终端上却不好设计交互。于是我引入了 Vim-like 键盘操作：gg 跳到开头，G 跳到结尾，括号跳转消息，yy 复制消息。虽然操作的问题是解决了，可是如果后台随时保存上千条消息的渲染结果，那么对内存的压力也是很大的。于是我又设计了缓存和窗口机制，只预加载附近的消息。 等待可以接受，不知道在等什么才难受：也许每个人都遇到过模型响应很慢的时候，可是界面上一动不动的，不知道是网络问题，还是模型输出太慢，还是卡在了执行上。解决方案也很简单——把一切用户关心的状态都暴露出来：在状态栏加上请求时间、字节数和事件数的展示；在接收工具调用时，实时展示已接收到了多少字符数；工具执行时，展示其执行时间。 图片不应该只剩下一个占位符：输入了图片，在终端上可能就显示成 [image1] 之类的占位符；如果输入了多张图，或者有多个并行的任务在开发时，很难记住这些图是啥。其实很多现代化的终端其实是支持显示图片的，于是我也加上了图片预览和查看的功能。不过也因此带来了缓存失效、刷新闪烁等问题，需要参考社区的方案一点点去解决。 由此可见，并不是有 AI 就能做好所有的事，底层的细节仍然是要靠程序员的经验和知识才能打磨好的。 体验的问题每天都可能遇到新的，我就不再详述了，但是还有 2 个技术我想分享一下：编辑文件和上下文压缩。 作为 coding agent，它最重要的能力就是编辑文件了。这个工具耗费的输出 tokens 很多，因此速度往往较慢；而一旦调用失败，不但需要花费更多的时间重试，而且也很浪费 tokens。 初期我主要是参考 Claude Code 的实现，但实际使用时却发现编辑错误实在太多了。我观察了一下失败的情况，发现大致有这几类： 前置检查要求模型在编辑文件前先读取文件内容。但模型可能没有用 read 工具读取文件内容，而是用 grep 、 head 等其他方式获取了内容；虽然内容正确，但是被前置检查拒绝了。 前置检查要求文件在读取后如果又被更改了，需要重新读取才能编辑。而在多 agents 并发开发时，它们可能同时修改同一个文件，但修改的区域可能完全不一样，却仍然会被前置检查反复拦截。 模型输出稍微有一点差错，比如空白、标点有差异，虽然 99% 匹配，但是因为找不到完全一致的内容而被拒绝。 对前 2 个问题，我放开了部分前置检查，采用后台静默备份文件，并在结果中提示模型存在的风险和备份路径的方案。而对于少部分差异导致的问题，我则做了模糊匹配，如果只有一个最相似的片段，则采用这个片段作为兜底，并在结果中提示模型做了什么兼容性处理。 感谢在开发 Chord 的前期， linux.do 上大量公益站给我提供了天量的 GPT 5.4/5.5 模型。然而经长期使用发现，GPT 5.x 模型在使用 Claude Code 风格的 edit 工具（参数包含 old_string 和 new_string ）时，失败率较高。 考虑到 GPT 模型可能大量使用 Codex 来进行后训练，于是我改为采用 Codex 风格的 apply_patch 工具（参数是 diff 格式），发现它的成功率就提升了。而实测其他家的模型则仍然更适合 edit 工具。 再后来，我发现事情没这么简单：OpenAI 的 Response API 还独家提供了对 custom tools 的支持，和传统 JSON 格式的工具调用不一样，它是可以自定义语法格式的，而且可以像正文和思考内容一样流式输出。于是我又进行了一番改造，让编辑过程也可以实时展示并语法高亮了，这体验就高级多了。 Chord 最初的上下文压缩实现也基本借鉴自 Claude Code，可是这套压缩机制往往会遇到 2 个无法避免的问题： 压缩过程太慢了，经常需要等待 5 分钟左右。如果按 50 tokens/s 来算，5 分钟也就输出 15000 tokens，对于摘要大小而言好像是合理的时间。 压缩后任务目标或已探索的中间结果容易丢失，导致长程任务失败。 为了解决第一个问题，我设计了异步压缩方案：达到阈值时，agent 可以继续当前的工作；同时发起一个异步的模型调用来生成摘要。当摘要生成完后，agent 准备发起下个请求时，将发起异步调用时点之前的消息替换成压缩摘要，后续的消息附加在后面，这样就可以在不阻塞 agent 工作的情况下完成压缩了。 而第二个问题则是从 Codex 的方案进行了借鉴：让模型及时保存自己的工作进度到笔记中，并提供一个压缩工具让模型主动调用。这样模型会在笔记中建立它的长期规划目标、当前的任务进度和已发现的事实等事项；而在发生上下文压缩时，笔记中的内容会自动注入第一条用户消息，因此目标和进度就不会丢失了。我用这套机制跑了 5 个超过 10 小时的长程任务，都在无人干预的情况下正确完成了。而且它还有一个省 token 的优点：模型如果发现后续任务不依赖当前的上下文，可以在任务边界处主动压缩上下文，以丢弃掉大量不再使用的上下文。 在做 Chord 之初，我以为 coding agent 最重要的就是省钱和高效；而在做了半年后，我觉得更重要的是那些不太显眼的细节。 Chord 不是我一次性规划出来「最好」的工具，而是在我每天的使用中逐渐进化出来的产物。它未必适合所有人，但如果你也习惯在终端里开发，对现有的工具不满意，欢迎到 Chord 的仓库 下载试试。 比起一句「支持」，我更想知道你觉得哪不好用？毕竟，它就是这样诞生的。 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/20 10:55:25