返回
Featured image of post 【workbuddy】+OC Ferry 免费模型使用!!!

【workbuddy】+OC Ferry 免费模型使用!!!

OC Ferry 是个开源小工具,把 OpenCode 的免费模型接进 WorkBuddy 用。这篇讲清它的原理、可行性,以及怎么用——其实就是点两下。

一句话:OC Ferry 是个开源小工具,作用是把 OpenCode 的免费模型接进 WorkBuddy 用。项目地址 HRuiCcc/RuiC-oc-ferry,MIT 协议。

一、它的原理

WorkBuddy 支持填自定义模型(写在 ~/.workbuddy/models.json),填进去就走你自己的配额。OpenCode 那边有一批免费模型额度。看着挺简单 —— 在 WorkBuddy 里加个接口地址不就完了?

不行,卡在一个地方:

OpenCode 的免费额度,只认从 OpenCode 自己内部发出的请求。

你把这个接口地址抄出来、用别的工具去调,服务端会发现"来源不对",直接拒绝 —— 官方原话就是 opencode's free tier can only be used from within opencode。

所以 OC Ferry 的做法很直接:它不抄接口,而是在你电脑上放一份隔离的 OpenCode 运行时,让请求真的从 OpenCode 里面发出去。

1
WorkBuddy  →  本机 127.0.0.1:41980  →  适配器  →  隔离的 OpenCode  →  免费模型

围绕这条链路,它干三件事:

  1. 挑 —— 把 OpenCode 里真正免费的模型选出来。判断标准是价格字段(输入/输出/缓存读写)全为 0,不是名字里有没有 free
  2. 测 —— 挨个测它能不能给 WorkBuddy 干活。重点是能不能产生工具调用(Agent 场景的命门);只回文本的也不算失败,会降级成「可用 · 仅对话」并把工具关掉
  3. 接 —— 把测通的写进你的 models.json,再起一个只监听本机的转发口,供 WorkBuddy 调用

二、可行性分析

技术可行性:成立 ✅

关键就在"隔离运行时"这一层 —— 如果它是直接转发密钥,这个方案从第一天就不成立。工程细节上也做得比较实在:检测 3 路并发(一轮约 60 秒),判定结果按模型缓存(成功留 6 小时),所以重启基本是秒开,不会每次都全量重测。

安全可行性:比预期周全 ✅

  • 网络面:只监听 127.0.0.1:41980,所有请求要带 Bearer 密钥,带 Origin 头的直接 403 —— 这个口不给浏览器用
  • 权限面:模型只能吐一段 JSON 信封表达"我想做什么",真正的执行权始终在 WorkBuddy 手里。任何本机动作都会被拒绝或转交成外部工具调用 —— 模型永远不会自己动手
  • 写配置:改 models.json 前先备份、加锁、原子替换;只动它自己标记过的条目,你手写的一条都不碰
  • 退出清理:从托盘退出时,把自己导入的条目摘干净

后两条是我最看重的 —— 这决定了它是"能放心常驻的小工具",而不是"会污染你配置的黑盒"。

使用可行性:分平台 ⚠️

  • 装完即用,不需要另外装 Node.js(打包后用的是 Electron 自带的 Node)
  • Windows 版安装时会写入开机自启(--hidden,开机只常驻托盘、不弹窗),等于"一直连着"
  • 关窗口 ≠ 退出:关掉窗口它继续在托盘跑
  • 要留意:官方 Release 目前只发布了 macOS(Apple 芯片) 的安装包;想在 Windows 上用,得走非官方 fork Chemingitch/RuiC-oc-ferry-windows,或者自己 build

风险与边界 ❌

作者在 README 里专门写了一节「诚实交代」,照搬几条关键的:

  • 免费模型和额度由上游决定,随时可能变
  • 检测通过只代表"这一次能按协议产生动作",不代表完整工作流都验证过
  • 启动后会自动发检测请求,会消耗少量免费额度
  • 界面上显示的耗时是完整请求用时,不是首字延迟;剩余额度上游不提供,查不到
  • 系统代理只支持手动 HTTP/HTTPS,不支持 PAC / SOCKS
  • macOS 包未做 Apple 公证,首次打开可能要右键「打开」;若提示"已损坏",先核对 sha256,再执行 xattr -dr com.apple.quarantine "/Applications/OC Ferry.app"

三、值不值得用

值得一试,但别当主力。

结论
适合想给 WorkBuddy 加一条免费备用通道的人;手上已经有 OpenCode;macOS 用户(体验最顺)
不适合指望它当生产力主力的人(免费池不稳);Windows 且完全不想折腾的人
心态当成体验通道 / 应急通道,而不是日常主力模型

三条红线:别拿它跑重要工作流;别把额度当成无限;模型有权限边界,重要操作自己盯一眼。

四、怎么用

其实就点两下。

安装包打开后,首次启动会自动扫描免费模型 + 逐个检测 + 自动导入一次。之后想重新来一遍:

  1. 点 「检测全部」 —— 重新扫描并检测模型
  2. 点 「导入 WorkBuddy」 —— 把结果写进配置

完事。WorkBuddy 的模型列表里就会多出一批 OC · 名字 的模型,选中即用。

左边是 OC Ferry 跑通的日志,右边是导入后 WorkBuddy 的模型列表

上图左边是跑通的日志(ready at http://127.0.0.1:41980/v1; 12 free models; probing 12),右边是导入后 WorkBuddy 里的模型列表 —— 多出一批带 OC · 前缀的免费模型,选中即用。

几个注意点:

  • 要用就让它常驻 —— 关窗口它继续在托盘跑,但从托盘退出会把导入的条目摘掉(保留你手写的)
  • 只想重测某一个:进它的详情,点「只重测这一个」
  • 主题切换:工具栏右上角,系统 / 浅色 / 深色三档,选择会记住

下载

  • 主仓库:https://github.com/HRuiCcc/RuiC-oc-ferry
  • Windows 非官方 fork:https://github.com/Chemingitch/RuiC-oc-ferry-windows

小结

一个 120 星、10 月 10 号才创建的小项目,但把"能不能用"这件事想得比很多大项目清楚:用隔离运行时绕过官方限制,用执行权归属守住安全边界,用缓存解决"每次都要重测"的体验问题。

免费的东西都不稳定,这一点它自己也承认。但作为一条"积分不够时的备用通道",它的可行性是成立的。

项目地址:https://github.com/HRuiCcc/RuiC-oc-ferry (MIT) 封面/配图来自项目仓库 docs/screenshots

评论区 正在连接 GitHub Discussions…
使用 Hugo 构建
主题 Stack 由 Jimmy 设计