kkocdko

@Chicagoake 确实不合理，都应当标注才对

请问对比现有流行项目 https://github.com/shunf4/proxychains-windows 有什么优势呢

楼主的描述有误导性。这和 GitHub 官方没有任何关系。

我感觉它还不如送的 glm 5.3 flash 呢

首先鄙视楼上的某几位抬杠/风凉话/嘲讽的睿智人。能不能好好说话？不会说话就回墙内泥巴地里撒泼打滚去。
---

我认为楼主说得有点道理。历史总是反复的。重复发明曾经存在的东西，这也是经常发生的事。

而且，本地机器配置普遍高于这种免费 VPS 。能做的事也是明显更多的。

然而很多人可能没有两台机器。开一个 VPS 来做这件事，确实有存在的价值。

一方面是安全性，agent 曾经多次干出删除用户数据的事情。

另一方面，“在本地机器使用”会占用机器，用户需要让出。对此 codex 的 computer use 在 mac 上用无障碍接口后台运行，我觉得也是不错的做法。之前借用同事的机器，用起来虽然很耗 token 还很慢，但效果不错。

另外，开 vps 的这个“免配置”的特点，也能吸引很多下沉用户。我这么说吧，在这个年代，很多人用电脑的水平还不如 agent 呢。各种环境千奇百怪，不可控，让 llm 去处理环境问题，又会消耗大量时间。有一个标准的环境，能让情况大幅改善。

或许可以用 tasker 来写。tasker 里有 nfc 相关的触发器。

没事的，你还用脚垫了一下呢。前阵子我骑共享单车摔了，放包里给砸了个角，还不是照样用。

相比之下应该更关心你的脚怎样了（

和之前养龙虾差不多道理

按照我的经验，你使用的模型应该不是 openai 的模型。

openai 的模型，对于 codex 的调用方式有做后训练，它更加适应这个环境。这与 api 转换（ chat completion api / responses api ）无关。

例如，deepseek v3 的时候，转换并接入 codex 就经常出现类似问题，忽然停下来不动，或者工具调用格式错误。v4f 之后，官方声称是配了 codex ，很多人以为只是提供了 responses api ，其实不止于此。v4f 对 codex 的调用方式有做后训练，适配性明显更好。

如今，glm-5.3-flash 对 codex 的适配也很好。但 qwen 3.8 flash 就明显不太行，依然经常出现调用错误和停顿问题。

如果要追求最佳的兼容性，那么，只能选择 opencode 。它比较传统，对于各种来源的模型的宽容度最好。