整个方案过于复杂，感觉可以设计一个docker yml配置每个技术栈参数来使用，项目目录和uv环境映射进去？
可以，而且这几乎是 OpenCode + OMO 生态里最值得投入精力去做的配置方向。在免费算力的约束下，复杂高效的调度不是“锦上添花”，而是让整个工作流持续运转的核心前提——因为任何单一免费源的额度或稳定性都不足以独立支撑一次真实的 Agent 会话。
🏗️ 架构分层：调度不能只靠 OMO 一层
直接让 OMO 去“感知”哪个免费模型还有额度是行不通的。OMO 的职责是按角色把任务分发给不同的 Agent，它并不天然知道某个 Provider 的免费池还剩多少。因此，完整的调度架构需要两层配合：
OpenCode（底座） └── OMO（角色层：Sisyphus / oracle / librarian / explore ...） │ 按角色指向不同的“模型别名” ▼外部路由层（额度感知 + 故障转移） ├── OmniRoute（cost-optimized combo） ├── API-Switch（按角色分组，统一端点） └── opencode-smart-model-selector（免费优先 + 自动降级） │ 背后挂多个免费 Provider ▼免费算力池 ├── OpenCode Zen（无需 API Key 的免费模型集） ├── Google Gemini 免费额度 ├── Groq / Cloudflare Workers AI / OpenRouter :free └── 本地 Ollama / LM Studio（最后兜底）
OMO 的 oh-my-openagent.json 负责角色到模型别名的映射，而“这个别名背后到底走哪个免费源、什么时候切换”由外部路由层接管。
🆓 免费算力源的分层清单
不要把所有免费源视为同质资源。按稳定性和质量，可以分成三个梯队来编排优先级：
第一梯队：低摩擦、可直接接入
来源 | 免费模型示例 | 限额要点 | 适用角色 |
OpenCode Zen | big-pickle、gpt-5-nano 等 | 无需 API Key，限时免费池 | 主对话、探索、快速任务 |
Google Gemini | Gemini 2.5 Flash | ~1000–1500 req/天（个人账号） | 多模态、视觉相关子任务 |
Groq | gpt-oss-120b / gpt-oss-20b | ~1000 req/天，低延迟 | 需要快速响应的 worker 角色 |
第二梯队：额度较宽裕，但有速率限制
来源 | 代表模型 | 注意事项 |
Cloudflare Workers AI | gpt-oss-120b、llama-4-scout | 10000 neurons/天，适合作为稳定的二线兜底 |
OpenRouter :free | nemotron-3-ultra-550b:free 等 | 20 req/分、50 req/天；免费档最强，但速率是硬约束 |
第三梯队：本地兜底（不走网络，不消耗任何额度）
本地 Ollama 或 LM Studio 加载一个 4B–9B 的小模型，作为所有免费池耗尽后的最后一道防线。它的价值不在于质量，而在于保证 Agent 循环永远不会因为“没有可用模型”而彻底中断。
注意：免费源的可达性因网络环境差异很大。有实测报告指出，Google Gemini 和 NVIDIA NIM 在部分网络下直连失败，OpenRouter 的某些 free 模型也存在限流或 503 不稳定情况。方案中必须预留探测与降级环节，不能假设所有源都随时可用。
🎭 OMO 角色 → 免费模型的映射策略
OMO 内置 11–14 个 Agent，但按模型需求可以压缩为三类角色，避免为每个 Agent 单独调参的复杂度：
角色层级 | 包含的 OMO Agent | 模型需求 | 免费源选择策略 |
主脑（思考/调度） | Sisyphus、oracle、metis、prometheus | 最强推理能力 | 优先级 1：OpenRouter nemotron-3-ultra:free（质量最高，但日限 50 次，需省着用）；优先级 2：Groq gpt-oss-120b；优先级 3：OpenCode Zen big-pickle |
工人（编码/构建） | build、atlas、OpenCode-Builder | 中等偏上，平衡质量与速度 | 优先级 1：Groq gpt-oss-120b（低延迟，适合高频编码）；优先级 2：Cloudflare gpt-oss-120b；优先级 3：OpenCode Zen 免费编码模型 |
打杂（探索/检索） | librarian、explore、sisyphus-junior | 速度优先，不要求深度推理 | 优先级 1：OpenCode Zen gpt-5-nano（免费且快）；优先级 2：Groq gpt-oss-20b；优先级 3：本地 4B 模型 |
这种映射的核心原则是：把额度最稀缺、质量最高的免费模型留给“主脑”，把高频、轻量的任务压到“打杂”层，用本地模型吸收所有溢出流量。
⚙️ 故障转移与额度感知：让路由层替你“切”
这是整个方案能否持续运转的关键。外部路由层需要具备三个能力：
1. 免费优先的 cost-optimized 策略。 OmniRoute 讨论中明确建议，免费优先场景应使用 cost-optimized 或 fill-first 策略，而不是 auto。原因是 auto 的 14 因子评分可能因为某个付费模型延迟更低而“聪明地”选中它，反而违背了免费约束。cost-optimized 会显式地把 $0 提供商排在前面，只有免费容量耗尽时才落到付费层。
2. 按角色拆分 Combo。 OmniRoute 本身没有“子 Agent 角色”概念，一个 combo 只是一个排好序的模型池。实现角色差异化路由的正确做法是：在 OmniRoute 侧为“主脑/工人/打杂”分别创建三个独立的 Combo，然后在 OMO 的 per-role 配置中分别指向它们。
3. 额度耗尽后的自动切换。 multiplexor 提供了另一种轻量思路：把每个免费 CLI/Provider 视为一个带 tier（free/included/local）和优先级的资源，用一个统一的评分函数 score = priority + tier_bonus 选路，并支持 multiplexor next 将当前源标记为 exhausted 后立即切到下一个。opencode-smart-model-selector 则内置了“免费模型优先”的极速模式和自动故障转移。选择其中一个接入 OMO 的角色别名即可，不必自建复杂的调度逻辑。
🧩 落地配置的分工
最终落地的文件分工应该非常清晰，不要让同一个文件承担两种职责：
oh-my-openagent.json（OMO 侧）：只负责角色 → 模型别名的映射。每个 Agent 的 model 字段填的是路由层暴露的别名，而不是具体的 Provider/model ID。例如 "oracle": { "model": "router/brain" }，"explore": { "model": "router/fast" }。OMO 的 model_profile 也指向这些别名。
路由层配置（OmniRoute / API-Switch / smart-selector）：负责别名 → 免费源优先级列表的映射，以及额度耗尽后的降级链。这是“免费算力调度”真正发生的地方。
opencode.jsonc（OpenCode 侧）：保持极简，只配置基础 Provider 连接和默认模型，把复杂路由全部下沉到外部层。
一个现成的起点是 my-opencode-config 向导，它会自动完成 OpenCode Zen + Gemini 免费额度的 OAuth 和 OMO 安装，并把 Agent 默认配置为使用免费模型。你可以用它先跑通基线，再在此基础上叠加 OmniRoute 或 API-Switch 的角色级 Combo。
⚠️ 必须纳入设计的边界
这套方案能“非常复杂高效”，但它的本质是用工程复杂度换取免费资源的利用率，而不是消除免费资源的固有约束。有三个边界需要在设计时就接受：
额度上限不会消失。 OpenRouter free 的 50 req/天、Gemini 的 1000–1500 req/天，在高频 Agent 会话中可能在几轮工具调用后就触顶。方案的价值在于触顶时自动切到下一个源，而不是让额度变大。
质量分层是必要的妥协。 把 nemotron-3-ultra:free 留给主脑、把 gpt-5-nano 留给探索，意味着打杂层输出的质量会明显低于主脑层。这在 Agent 编排中是合理的设计——探索任务不需要顶级推理——但需要对“哪些角色可以降质”有清醒的判断。
本地兜底的质量是保底而非替代。 4B–9B 本地模型在免费池全部耗尽时能维持 Agent 运转，但它的工具调用可靠性和推理深度与云端免费模型之间存在差距。它适合作为“最后一道防线”，不适合作为常规路径。
如果你愿意接受这些边界，OpenCode + OMO + 外部路由层的组合，确实可以构建出一个在零 API 成本下持续可用、按角色智能分配、额度耗尽自动降级的复杂调度配置。