一句话结论
Everything Agent-CLI to Claude Code 的核心不是“给 Claude 再接一个 API”，而是把被网页登录和官方 CLI 壳隔离的能力，重新恢复成 Claude Code / LikeCode 可调度的外部 worker。
01 · 它到底在解决什么问题
| 真实困境 | 为什么普通 API 思路不够 | 这个项目的回答 |
|---|---|---|
| 很多能力绑定在网页登录和官方 CLI 上 | 你有额度、有订阅，但没有对等公开 API | 把官方 CLI 当执行面，把主工作流留在 Claude Code / LikeCode |
| 同一任务里想混用多个模型 | 原生单 provider / 单模型路径切换摩擦大 | 让不同 provider CLI 变成不同 worker |
| 不想开七个终端来回切 | 上下文、文件、审稿、review 都会断裂 | 把不同 CLI 编排进一个统一 workflow |
所以它最适合被理解成：多模型 CLI 编排层，而不是又一个“模型聚合 API”。
02 · 它的架构为什么值得看
Claude Code / LikeCode
->
umbrella skill: usecli:*
->
provider wrapper
->
official provider CLI
->
web-login entitlement / subscription / free quota这条链路有两个特别关键的设计点：
- Claude Code / LikeCode 继续做 control plane，不把主工作台让出去。
- 外部模型能力不再被当作“聊天标签页”，而是变成可以被调度的命令型 worker。
在这个模型下，`codex`、`gemini`、`qwen`、`grok` 可以进入同一个 review / planning / doc-generation loop；而 `cursor / qoder / trae` 这类还没确认稳定命令面的工具，也能先以 scaffold repo 的方式占位。
03 · 仓库家族怎么分层
| 仓库 | 角色 | 当前状态 |
|---|---|---|
everything-agent-cli-to-claude-code | umbrella repo，放定位、命名、workflow、registry、总入口 | 已补 README 与 wrapper smoke test |
gemini-plugin-cc | Gemini provider bridge | 已补最小 smoke test |
qwen-plugin-cc | Qwen provider bridge | 已补最小 smoke test |
grok-plugin-cc | Grok provider bridge | 已补最小 smoke test |
cursor-plugin-cc | Cursor scaffold bridge | 已补“可测试 placeholder” |
qoder-plugin-cc | Qoder scaffold bridge | 已补“可测试 placeholder” |
trae-plugin-cc | Trae scaffold bridge | 已补“可测试 placeholder” |
这种拆法的好处是：总仓库讲控制面和统一命名，子仓库讲 provider 细节和本机差异。这样后面往 skill、workflow、自动评审链扩展会更稳。
04 · 我们现在怎么验证这条线
目前已经不是纯概念页，而是有最小可跑的验证闭环，而且总仓库现在还多了一个 provider-ready demo matrix 入口。
| 验证对象 | 脚本 | 说明 |
|---|---|---|
| umbrella wrapper | projects/everything-agent-cli-to-claude-code/tests/test_wrappers.sh | 验证 `codex / gemini / qwen / grok` wrapper 的 help、参数拼装与 workflow 输出 |
| plugin family matrix | projects/everything-agent-cli-to-claude-code/tests/test_plugin_family.sh | 顺序调用同一 projects/ 根目录下的 `*-plugin-cc` smoke test，检查这条推荐链不是只停在 umbrella repo README 里 |
| provider-ready demo surface | projects/everything-agent-cli-to-claude-code/examples/README.md | 把每个 wrapper 对应的最短 proof、 stronger demo path、以及应该先读哪条 workflow 文档压成一个入口矩阵 |
| Gemini provider | projects/gemini-plugin-cc/tests/test_wrapper.sh | 验证 wrapper 命令构造 |
| Qwen provider | projects/qwen-plugin-cc/tests/test_wrapper.sh | 验证 `qwen-oauth` 参数面 |
| Grok provider | projects/grok-plugin-cc/tests/test_wrapper.sh | 验证 headless prompt 调用 |
| Cursor / Qoder / Trae scaffold | 各自 tests/test_wrapper.sh | 验证 placeholder 也具备统一参数面和探测输出 |
这一步很关键：哪怕仓库还处在 scaffold 阶段，也先把“命令契约”和“占位状态”测起来。现在连整条 `*-plugin-cc` 家族都能从 umbrella repo 一次顺着验过去，所以未来从 placeholder 升级到真实 CLI 接入时，至少不会从零开始补质量基线。
05 · 为什么它同时是可用仓库和架构样本
| 读法 | 先看什么 | 你会得到什么 |
|---|---|---|
| usable repo | tests/test_wrappers.sh、tests/test_plugin_family.sh、examples/README.md、examples/workflows/multi-model-review.sh、bin/usecli-*.sh | 确认这不是只会讲概念的 umbrella repo，而是已经有最小 wrapper、family smoke matrix、provider-ready demo matrix 和 workflow proof |
| architecture sample | docs/repo-strategy.md、registry/plugins.md、docs/workflows/multi-model-review.md | 看懂为什么主工作台留在 Claude Code / LikeCode，而 provider CLI 留在外部 worker 层 |
所以这条线的价值不只在“现在能不能跑”，也在于它已经给出了一个很清楚的 control-plane 拆法：总仓库负责统一命名、workflow 和外层故事，provider 细节继续下沉到 `*-plugin-cc` 家族。
06 · 它和站内 CLI Agent 专题的关系
CLI Agent 专页 回答的是“有哪些路线、该怎么分类”；而这一页回答的是“如果我真想把多个 provider CLI 接回一个主工作流，工程上该怎么搭”。两页放在一起，前者给你地图，后者给你施工方案。