一句话看懂
同样叫“多账号工作台”，有人要切 ChatGPT 订阅号，有人要换模型供应商，有人要离开电脑后继续操作，还有人想统一调度多个 Agent。亦仁先把 Cockpit、CC Switch 与两个同名 OpenCodex 拆到不同层，群友再补上 Cindy、Codeg、Orca、Herdr 和一套跨设备自建方案。真正可复用的不是工具清单，而是先定位第一痛点，再决定该改账号、供应商、访问方式，还是整个编排层。
当时在场
一场真实发生的群聊
- 亦仁
- 二歪2y
- Bob
- 张立行
群聊现场
他们当时具体说了什么
保留原始称呼和发言顺序；每组之间的说明是编辑整理，不是群友原话。
先把账号切换与供应商切换分开
亦仁先分享三类工具的对比整理。二歪2y随后用“不同账号”和“不同供应商”概括了其中最容易混淆的两层。
Codex 当主工作台时，要加更多号怎么选：Cockpit、CC Switch、OpenCodex
前几天群里面讨论，整理了下。
CC Switch 的定位更像，让一个 agent 产品后端接不同供应商，他的产品定位在'不同供应商'。
Cockpit Tools 的定位是，让一个 agent 产品后端接供应商的不同账号。他的定位是'不同账号'。
问题继续上移到多 Agent 与多设备编排
当需求从切号扩展到多模型、多设备和移动端，讨论不再停留在配置切换工具，而是转向开箱即用的工作台与可自定义的 Agent 开发环境。
感觉心动老板黄一孟做的就是解决这个问题的
郑州生财圈友参与搞的 Codeg 多智能体编码工作台：把所有 AI 编码智能体收进同一个地方——并让它们协同工作。
多 agent 多账号工作台，基本还是得走 cli + hook + 外部脚本，很多脏活累活。
本质上是 agent development environment 这一层的工作。
开箱即用的方案就类似于 orca、cindy。
追求自定义可以用 herdr + herdweb + 自定义脚本（同时解决手机端的问题）。
我自己是基于 codex，派活给 cursor cli/Ocra，ocra 中用不同模型并发，主控放在 codex 会话线程中。
MAC 与 WIN 用 GITHUB 与 TAILSCALE 作桥梁。
MAC 存知识 + 活跃主项目，WIN 挂多硬盘，存数据，做运行机
讨论速览
这场讨论的关键信息
- 25 条
- 整理页记载的消息
- 13 条
- 本页公开选录的原话
- 68 分钟
- 14:59—16:07 的讨论跨度
- 4 层
- 账号、供应商、访问与编排
下面是基于来源材料做的整理，和上面的原话分开呈现。
1. 真正的第一步，是判断你准备改哪一层
这场讨论最有用的地方，不是列出更多工具名，而是把看似相同的“多账号工作台”拆成不同问题。切换订阅身份关注账号与登录状态；接入 Grok、DeepSeek 或中转服务关注模型供应商与请求路径；人在外面继续操作关注远程访问；让多个 Agent、模型和设备协同，则已经进入编排层。
四层可能同时出现，但解决顺序不同。只想在两个订阅号之间切换的人，没有必要先搭一套多 Agent 平台；已经有多台机器、多个执行器和移动端需求的人，也不应期待一个切号器承担统一调度。先写出第一痛点，可以显著减少工具重叠和配置互相覆盖。
- 账号层回答“以哪个身份使用”，供应商层回答“请求发往哪里”。
- 访问层回答“人不在机器前怎样继续”，编排层回答“多个执行者怎样协作”。
- 工具名相同也可能属于不同层，群聊特别提醒了两个 OpenCodex 项目不要混淆。
2. 把“换人、换路”当心智模型，不要当文件说明
亦仁的材料用 auth.json 表示“我是谁”、用 config.toml 表示“请求打到哪”，这个比喻适合解释账号与供应商的区别，但不能照字面理解成 Codex 只认两份文件。OpenAI 官方文档显示，CODEX_HOME 默认是 ~/.codex，里面还可能有历史记录、日志、缓存、会话、技能和其他状态。
认证也不一定只落在 auth.json。官方文档说明，Codex 可以用 ChatGPT 登录或 API Key；缓存凭据既可能使用文件，也可能进入系统钥匙串，甚至只保存在当前进程内。配置还存在命令行参数、Profile、项目配置等叠加层。因此，第三方工具若只替换一个文件，不代表它隔离了全部状态。
- 不要复制、提交或发送 auth.json；它在文件存储模式下包含访问令牌。
- 使用 CODEX_HOME 做隔离时，要理解它覆盖的是一整套状态目录，而不只是登录票。
- 切换后是否需要重启，应按具体客户端和工具的当前说明验证，不能仅凭一次群聊经验下结论。
3. 从工具切换上升到工作台，代价也会一起上升
亦仁在讨论中把需求继续推演到单一工作台、多账号、多模型、多设备和移动端。群友提出 Cindy、Codeg、Orca、Herdr 与自定义脚本，说明问题已经从“改一份配置”变成 Agent 开发环境：需要处理任务调度、会话连续性、机器分工、远程接入和结果验收。
Bob 给出的样本很具体：Codex 会话做主控，把任务派给其他 CLI；Mac 与 Windows 通过 GitHub 和 Tailscale 连接；一台机器放知识和活跃项目，另一台做数据与运行机。这是个人已采用的架构描述，不等于读者复制后会得到同样结果，但它提供了一个值得复用的设计动作：先分配角色，再选连接方式。
- 开箱即用的工作台减少脚本工作，但需要接受它的产品边界与配置方式。
- 自建方案自由度更高，也会把运行维护、权限管理和故障恢复交给自己。
- 多设备不是简单增加机器，还要定义代码、数据、知识和任务状态分别放在哪里。
4. 一个更稳妥的试用顺序
先备份当前可用配置，并记录登录方式、模型来源和任务入口；然后一次只解决一个问题。如果第一痛点是切账号，先验证两个身份能否明确区分且会话不串；如果第一痛点是换供应商，先用一个无敏感数据的小任务验证模型、协议和基础地址；如果是远程访问，先验证断线重连和权限边界。
只有当单点方案稳定后，再把它接进多 Agent 或多设备工作台。验收时不要以“工具显示在线”作为成功，而要看任务是否完成、身份是否正确、产物是否落到预期位置，以及失败后能否回到原有官方配置。这样即使最终更换工具，也不会把账号、配置和会话一起变成不可解释的状态。
- 每一步保留回退点，并且只允许一个工具成为同一配置层的主控。
- 先跑只读或低风险任务，再逐步开放代码写入、远程控制和自动调度权限。
- 用有效产出、错误率和恢复时间评估方案，不用账号数或 Token 消耗量代替结果。
讨论时的事实核对
按第一痛点定位方案层级
| 第一痛点 | 所在层 | 群聊提到的方向 | 最小验收 |
|---|---|---|---|
| 多个订阅号之间切换 | 账号层 | Cockpit 或独立 CODEX_HOME | 身份明确、会话不串、可回退 |
| 在 Codex 入口使用不同模型来源 | 供应商层 | CC Switch 或同类配置方案 | 模型与请求目标正确，原配置可恢复 |
| 离开电脑后继续操作 | 访问层 | RyensX/OpenCodex 或远程控制 | 断线后可重连，权限范围清楚 |
| 多 Agent、多模型、多设备统一协作 | 编排层 | Cindy、Codeg、Orca、Herdr 或自建 | 任务可追踪，产物位置与失败恢复明确 |
群聊里的关键表达
他的产品定位在'不同供应商'。
本质上是 agent development environment 这一层的工作。
MAC 与 WIN 用 GITHUB 与 TAILSCALE 作桥梁。
可以怎么行动
- 把自己的第一痛点写成一句话，并标注它属于账号、供应商、访问或编排中的哪一层。
- 备份当前可用配置，记录登录方式、模型来源和回退步骤，再引入一个候选工具。
- 用无敏感数据的小任务验证身份、请求目标、产物位置和失败恢复，不只看工具是否在线。
- 单层验证通过后再叠加远程访问或多 Agent 编排，并为每台设备定义明确角色。
- 涉及第三方登录、订阅共享或中转服务时，先核对当前服务条款和组织合规要求。
