@CS6 说: @Botio-Kuo 主要是自己家裡買不起太貴的設備，都是在 HomeLab 實驗後再移到公司 server 上面進行比較大規模的驗證， 我們目前都是使用 liteLLM ，最近是在評估 omnirouter / bifrost ，有什麼好的經驗也可以分享一下 工作上還是只能氪金 codex + claude code 才能應付大規模的專案.... 這套比較像是拿來做一些打雜，還有不趕時間的小玩具/ ETL 自動化的整理之類的 谢谢大哥分享！ 试过 https://openwebui.com/ 吗？

@williamlouis 是的，我弟观察细微

@terry 真实心得回覆 我今天用 deepseek harness +deepseek v4.1 flash 做一个研究任务 ， 但一直失败， 后来我切换到codex和claude code 一样接入deepseek v4.1 flash， 也是一直提示失败，查询后原来是触发了风控，我也不知道哪个东西风控了。 一怒之下我用deepseek harness 切换到我的本地去审查 千问3.8 27b， 慢了点 但顺利完成 且质量还不错 越来越感受到本地部署的重要性了， 不然我今天的工作就卡在那边了。

分开执行者和监督者是成熟套路（actor/verifier），但收益取决于监督信号是否独立，不取决于实例数量。三点经验： 同模型 + 同上下文复制两个实例，大概率共享同一个盲点，错误会一起漏掉或一起被确认。要么用异构模型做 verifier，要么让监督者只看最终产物（黑盒评审），别让它读执行者的推理过程，否则容易被带偏。 成本约 1.5–2 倍 token 和更多延迟，只在「错误代价高 + 结果可验证」时划算。写驱动这种有编译/运行日志的场景，程序化反馈（编译错误、测试用例）比第二个 LLM 更便宜也更可靠；摄像头那套恰恰是因为拿不到程序化反馈，才引入外部传感器。 真正拖垮多 agent 的通常是上下文，不是算力。监督上下文越长越容易失焦，最好分阶段，每阶段只带必要信息。 至于「训练改善」要拆开看：第二个实例只是推理时的 verifier，不改变模型权重。要真正提升 DSH/Hermes 的能力，得靠可验证奖励（RLVR）、偏好数据或工具反馈回流，而不是两个实例互看。实用做法是分层：便宜的规则/测试先筛，LLM 只在不可判定的 case 上兜底。

2×R9700 的组合，按「先能跑、再提效」来配： 模型 本地主力：Qwen3.8-27B，INT4/AWQ 或 Q6_K。写 Luau 是 27B 的舒适区，别为了更大去挤上下文。 V4.1 Flash 不要想本地跑：它是 552B 总参数的 MoE，64G 显存连权重都放不下。它的正确位置是云端 API——做规划、难题和兜底；日常脚本生成走本地。 Qwen3.5-27B 是上一代，除非你已经有调好的量化，否则没有选它的理由。 框架 双卡优先 SGLang，用 TP=2 把 27B 切到两张卡，前缀缓存对「固定系统提示 + 示例」的 agent 循环收益最大。 注意 R9700 是 gfx1201（RDNA4），不是 7900XTX 的 gfx1100。论坛那套 SGLang 魔改是给 gfx1100 的，直接套会在 kernel/编译目标上出问题；先确认 ROCm 7.2 + sgl-kernel 有没有 gfx1201 的预编译。 如果 SGLang 一时走不通，退回 llama.cpp 的 --split-mode layer 两卡分层或 RPC 后端过渡。能出活，代价是长上下文和吞吐。 参数取向 --mem-fraction-static 留 0.85 左右给权重，其余给 KV，上下文按 128K 配。 MTP 投机能提吞吐，但论坛 Enigma 那篇实测里 MTP 会把 KV 池砍到 1/5（上游 bug）。现阶段先别开，或单独验证。 一句话：本地 Qwen3.8-27B + SGLang 双卡 TP 当主力，V4.1 Flash 走 API 当规划层，别在 64G 显存上追大 MoE。

@terry 我觉得codex做那种超级长链的任务，会很棒。。。 比如开发一个office 软件，又或者做一个移民火星的方程式

@AGI 说: @Thanaots 没有风险，自己搭建cpa就行了。如果你用codex，直接就不用反代了。 奥对。我干脆先用codex算了。这100刀也不算浪费。

看完YT 直接安裝了 非常好用

@terry 多谢！

GPT的额度我一般都不用，因为干不了啥活，懒得折腾，如果选Luna，和猪一样蠢。Terra干活也不如DeepSeek，额度消耗也快。如果选Sol那额度不忍直视。GPT6就更不用说了。但我觉得OpenAI还是搞对了路子，它的模型做出来是去打Anthropic的，它做到了。

@imbiplaza-asus 謝謝~ 其實AI從一開始就有建議我先轉md檔， 一次處理一個區塊， 只是我都丟給AI就叫他直接讀， 以後我會認真轉檔

@kop-wang 我也可能要这样了。。。。

不用非得 CC Switch / Codex++ 那种工具，那些只是"一键切换 provider"的便捷壳，单一目标配置直接改 ~/.codex/config.toml 最省事。 核心是给 Codex 挂一个本地 OpenAI 兼容端点。你先起一个本地服务（llama.cpp 的 llama-server、LM Studio、vLLM 都带 /v1 接口），记下端口，然后在 config.toml 里写： model_providers = { qwen_local = { base_url = "http://127.0.0.1:8080/v1" wire_api = "chat" } } model = "qwen3.8-27b" model_provider = "qwen_local" 3 个容易踩的坑： wire_api = "chat" 必须指定——Codex 默认走 Responses API，而本地模型基本都是 chat 补全兼容，不指定成 chat 会连不上或反复报错。 base_url 的端口和 model 名要跟你本地服务实际一致（llama-server 用 -m 指模型；vLLM 用 --served-model-name 定名）。 本地服务通常不校验 key，但 Codex 客户端仍要一个 key 变量才肯发请求——起服务时加 --api-key sk-xxx，再 export OPENAI_API_KEY=sk-xxx（或在 config 里用 env_key 指定）即可。 CC Switch / Codex++ 的价值只在"多个远端 + 本地之间快速切"；你只挂一个本地目标，手工写上面这几行就是最直接的方式。Qwen3.8 本身支持工具调用，这点没问题，跑起来后 Codex 的 tool call 能正常走 chat 模式。 另外提醒：Codex 是它自己的一套配置/记忆，跟 Hermes 的 skills 生态不通用；想复用知识得单独喂文档。

@terry Agent 這技術比較新, 相關的應用比較多 如雨後春筍般冒出, 東試西試的 機台中軟體一堆 等過一大陣子更熟悉了, 應該可以往前推進到專業的軟體環境了 我暫時先放牛吃草 讓Agents 自由點 當然量產機台環境就要很乾淨了, 以排除不可控的因素

跑這麼久 我都害怕我的顯卡過熱 目前還在研究怎麼壓溫度 大概只能用電風扇狂吹

@terry 说: @Thanaots 我觉得没啥必要，V4 Flash无法准确理解游戏要求，所谓的小孩编程，就是harness工程的一部分，V4 Flash更多是个工具。一定要用，可以用Pro，这点钱别省，接入DeepSeek Harness，让小孩试着玩玩。说实话，没经过训练有点耗钱，任何行业都有1万小时的说法，这个说法不精确，不过大致如此，就是堆时间，堆钱。 那就直接把现在成型的Hermes+ds v4直接换成ds harness+GPT Pro吗？这还有点麻烦。今天好不容易搞好了Hermes。还给儿子的roblox建立了一个房子，一个树和一个小人。不过房子的屋顶反过来了。 我回去试试，谢谢老特。

微信机器人应该可以连接吧

@Yu-Chen-Chang 说: 很好的分享，不過文章有點長，我直接讓ChatGPT比對我目前使用的架構。畢竟我使用的是能力比在地模型強的多的模型。但是觀念借鑒總是可以激發更好的靈感 我使用的是多agents來管理，核心只有一個agent bus，決定agent如何溝通。 文章，我也覺得太長了，因為九成九 HERMES 幫我寫的 你的方式也不錯，多 Agent 分工彈性強，我是想到什麼，就加什麼的，沒有特別的規劃，分享給大家 互相學習/吐草。