问题描述：

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是
• 我的开源项目完整开源，无未开源部分： 是
• 我的开源项目已链接认可 LINUX DO 社区： 是
• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

为什么我做了 Multi CLI Studio

大家好，我是这个项目的开发者。

这段文字不是一份很正式的产品介绍，更像是我想认真说明一下：我为什么会去做这个项目，它到底想解决什么问题，以及我觉得它现在比较有价值的地方是什么。

先说结论

我做 Multi CLI Studio，不是因为我想再做一个“AI 壳子”。

我真正想解决的问题是：

现在我们在本地使用 AI 编码工具时，工作流太割裂了。

你可能会同时用 Codex、Claude、Gemini，也可能会同时开 CLI、开网页、开编辑器、开终端。每个工具都有自己的长处，但它们之间通常是断开的。上下文断开、状态断开、操作断开，最后人反而要花很多精力在“切工具”和“补上下文”上。

我想做的是一个更统一的桌面工作台，让这些事情至少能在一个地方发生。

我遇到的真实问题

我在日常开发里很明显地感受到几件事：

1. 不同 CLI 的能力真的不一样

有的更适合直接改代码，有的更适合规划和解释，有的在 UI、推理、长文本处理上更顺手。

问题不是“谁最好”，而是：

很多时候你就是需要多个工具配合。

如果每次切换都要换终端、换页面、换上下文，那效率会掉得很快。

2. 会话和项目状态总是散的

终端里有终端的上下文，网页聊天里有网页聊天的上下文，自动化脚本有脚本自己的状态，Git 变更又在另一个地方看。

这些东西其实都围绕同一个项目，但现实里它们常常互相不知道对方在干什么。

3. 自动化和日常对话是割裂的

很多重复任务，其实应该能沉淀成“流程”或者“任务模板”，而不是每次重新写一遍 prompt。

但现有工具里，聊天、命令执行、自动化编排经常是三套东西，很难自然地衔接起来。

所以我想做什么

我希望有一个本地桌面应用，可以把这些能力放进一个相对统一的工作区里：

• CLI 终端交互

• 模型对话

• Provider 管理

• 自动化任务

• 工作流编排

• 本地状态持久化

这就是 Multi CLI Studio 现在在做的事。

这个项目想解决什么问题

如果用更直接的话说，我想解决的是下面这几个问题：

1. 降低多工具切换成本

不是要求用户只选一个 AI 工具，而是承认“你本来就会同时用多个”，然后尽量把切换成本降下来。

2. 让上下文尽量留在本地工作区里

终端会话、模型对话、自动化执行记录、工作流状态，尽可能放在一个桌面应用里统一管理。

3. 让模型切换变成正常操作，而不是重开一套流程

比如在同一个会话里按回合切换模型，而不是每次换模型都要另开一个页面、另起一段上下文。

4. 让重复性 AI 协作任务可以沉淀下来

一些重复性的事情，不应该永远停留在“重新发一遍 prompt”这个阶段，应该逐步变成任务、工作流和自动化。

我觉得这个项目现在比较有意思的亮点

这里我不想写得太夸张，只说我自己觉得比较实在的部分。

1. 跨 CLI 不是附属功能，而是核心思路

这个项目的出发点不是“先支持一个 CLI，再顺手兼容别的”。

相反，我一开始就默认：

真实开发里，本来就会跨 CLI。

所以这个项目的很多设计，都是围绕“如何在多个工具之间保留连续性”来做的。

2. 终端、聊天、自动化是在同一个产品里思考的

这三块通常在很多产品里是分开的，但我觉得它们本来就应该互相连得更紧。

你在聊天里形成的判断，可能会变成终端操作；你在终端里的重复工作，可能会沉淀成自动化；自动化执行后的结果，又应该能回到对话和工作区里。

3. 本地优先

我比较看重本地工作流的完整性。

这个项目不是那种强依赖云端后端才能成立的形态。很多状态都直接保存在本地，包括 SQLite 和 JSON 数据。

这意味着它更像一个真正的桌面开发工具，而不只是一个网页外壳。

4. 不只是“能聊”，而是更接近“能工作”

我不太想把它做成纯聊天工具。

我更关心的是：

• 这个工具能不能围绕项目工作区运转

• 能不能感知终端、Git、任务、工作流

• 能不能把一次次 AI 协作慢慢沉淀成稳定流程

它现在适合谁

我觉得这个项目目前比较适合下面几类人：

• 本来就在同时用多个 AI 编码工具的人

• 希望把 CLI 工作流和模型对话整合在一起的人

• 想把重复 AI 任务逐步沉淀成自动化的人

• 更偏好本地桌面工作流的人

如果你只想要一个非常简单、非常轻量的单模型聊天框，那这个项目未必是最合适的。

但如果你已经感受到多工具协作带来的混乱，那你应该能比较快理解我为什么做它。

这个项目现在还不完美

这个我也得坦白说。

它现在仍然在快速迭代，很多地方还在打磨，包括：

• 交互细节

• 模型和 CLI 的兼容细节

• 自动化和工作流的体验

• 不同平台下的稳定性

我不想假装它已经“非常成熟”。

但它已经足够让我把一些原本分散的工作流，收回到一个更顺手的桌面环境里，这对我来说已经是很大的价值。

我希望它最终变成什么

如果说得朴素一点，我希望它最终能变成一个：

真正适合日常开发使用的本地 AI 工作台。

不是只会展示回答，而是能够围绕项目、终端、模型、自动化和上下文一起工作的那种工具。

最后

如果你也在同时使用多个 AI CLI，或者你也觉得现在的 AI 开发工作流太散了，那我很欢迎你看看这个项目。

我做它的出发点很简单：

不是为了做一个看起来很新潮的 AI 产品，而是想认真解决一个我自己每天都在遇到的问题。

如果它也刚好解决了你的问题，那就太好了。

然后下面分享一些这个项目的细节图片：

1. 首页：就是常规的数据展示

index1480×894 132 KB

2. 终端交互，我们该系统的核心功能，支持跨CLI执行，结构化输出我们的CLI的各类型信息，支持常规Slash命令，如$-skill, @文件，模式切换等

terminal1480×894 122 KB
image1480×860 151 KB
image1480×860 161 KB
image1480×860 68 KB
image1480×891 137 KB

3. 支持不同模型提供商的简单对话

chat1480×891 140 KB

4. 模型提供商管理（类CC Switch的方式）

provider1480×890 77.8 KB

5. CLI自动化任务，目的是我们想每天使用它来定时执行一些任务，然后支持设定我们任务目标设定，然后根据预期交付结果去检查交付，然后定制化一些执行过程细节，然后就是结果通知

automationJob_Index1480×892 117 KB
image1480×886 79.3 KB
image1480×860 89.8 KB
image1480×860 72.5 KB
8da6faa84e2f9b9fdf305602b35265391260×2800 220 KB

6.自动化工作流，允许配置工作流去使用不同CLI 每个节点进行操作，并且我们现在御三家都支持session resume，所以其实对我们工作流来说很友好，我经常下班前写了些任务，然后扔给它自己执行，明天早上查看就行

automation_workflow1480×890 148 KB
image1480×892 160 KB

7.配置详情，主要查看各个CLI的信息以及邮件通知

settings1480×895 108 KB

V0.0.3更新： 引入了完整的Git支持，终端/运行时终端支持，新的Setting页面，包含更多细节的展示（主要参考desktop-cc-gui 补齐功能）

image1480×890 155 KB
image1480×887 111 KB
image1480×892 109 KB
image1480×892 71.9 KB

V1.0.1 更新

1.重构输入界面

QQ17765677994552960×1720 341 KB

2.添加文件打开方式

QQ1776567824406930×382 45 KB

3.完善git 面板的拉取/推送/同步/获取模态框样式

QQ17765679477372960×1720 262 KB

4.添加启动脚本

QQ1776568005569894×612 51.1 KB

---

V1.1.0

添加SSH 远程支持，完整的CLI调用，环境检测，文件树，Git功能

QQ17765945084442960×1720 256 KB

添加智能体支持

QQ17765945488322960×1720 418 KB
QQ17765945822152960×1720 413 KB

---

V1.1.5更新

###1.Headerless 边框设计
image1480×860 111 KB

2.引入Review Code/Speed/New Session/Tool Approval 会话设置

image988×374 47 KB

3. 优化上下文与用量使用统计，根据返回的context_windows 实时计算当前session id的占比（精准）

image892×223 25.2 KB

引入会话管理页面，管理全局的session

image1480×860 102 KB

V1.1.7

1.添加了Plan Step Card展示

b37d5e1aac63b30938d2c2983f975cb91480×860 138 KB

2.添加了提示词管理以及对话插入

image1480×860 71.5 KB

3.SubAgent添加侧边栏展示

image1256×286 34.6 KB

V2.1.1

1.添加了Hooks 支持

image1480×860 157 KB

2. 模型对话支持流媒体；修复Plan Step Card的正确渲染正在做的loading步骤；文件树样式更新，引入更多的icon支持文件类型；优化MCP/项目 Setting页面UI

image1480×860 107 KB

---

链接

- Github: GitHub - Austin-Patrician/multi-cli-studio: Multi CLI Studio is a Tauri desktop workspace for people who do not want to be locked into a single AI coding CLI or a single model vendor. · GitHub

- 下载: Releases · Austin-Patrician/multi-cli-studio · GitHub
（macos 端需要本地运行打包）

欢迎大家一起使用起来，求Star

网友解答：

---

--【壹】--：

强啊兄弟，这个项目的设计理念很有水平了，加油

---

--【贰】--：

插个眼,期待一手完整版,等佬友开发完,

---

--【叁】--：

后续会尝试适配WSL ，并且适配ssh，支持远程服务

---

--【肆】--：

好的，等待佬的强势更新，支持佬，先码住。

---

--【伍】--：

image993×765 20.2 KB
clone下来项目，npm install相关的包，然后执行npm run tauri:build就可以啦

---

--【陆】--：

太强了佬友，感谢佬友分享，star+ 1

---

--【柒】--：

我平时也比较高频使用御三家的cli, 老是遇到蹬codex 解决不了很多UI问题，然后得手动掏出我们的gemini cli来使用，确实会繁琐一点

---

--【捌】--：

终究做需求的时候还是人拿捏的比较准哪个更符合自己的习惯，效果也会比较好一点

---

--【玖】--：

hie强的强啊佬，马上观摩学习一下！！！

---

--【拾】--： austin_zhang:

终端交互，我们该系统的核心功能，支持跨CLI执行，结构化输出我们的CLI的各类型信息

这样挺不错哎，目前看协作的话要比ccg更灵活些，有点类似以前那个ai聊天室了

---

--【拾壹】--：

佬，这个能用在wsl上吗？我的东西基本都安装在wsl里面

---

--【拾贰】--：

OKOK 感谢佬友指导，我来操作 试试看

---

--【拾叁】--：

同一个项目在不同CLI之间切换确实挺磨人的，学习了

---

--【拾肆】--：

插个眼，实在是太需要了，期待一手适配！！

---

--【拾伍】--：

太狠大佬，太懂现在ai使用者的需求了，赶紧下下来膜拜一番

---

--【拾陆】--：

支持佬友的开源项目，下载下来试试学习一下

---

--【拾柒】--：

感谢支持！ 希望可以对佬友有点帮助哈!!!

---

--【拾捌】--：

观摩学习，太强了，佬。
tauri 技术栈，我喜欢。

---

--【拾玖】--：

这执行力，太猛了佬友，这个是真的方便，有没有大佬打包一份Mac端的呀，不太会本地运行打包