Cindy：把 Claude Code 與 Codex 編排進同一個本地代理的開源用戶端

它是什麼：一個把多個編碼代理「編排」起來的本地用戶端

Cindy（makecindy/cindy）是一個開源的 AI 代理用戶端，口號是「Consider it done」。它的定位很明確：不再讓使用者在 Claude Code、Codex 等不同的編碼代理之間來回切換，而是把多種「harness」（代理執行框架）、多種模型和多種工具收攏到同一個代理裡，在使用者自己的電腦上，使用真實的檔案和已經登入的應用，完成真正的工作。倉庫採用 Apache-2.0 授權，是 pnpm 單體倉庫，包含 Electron 桌面端、Expo / React Native 行動端，以及共用的 packages（認證、裝置連線、代理編排、模型供應商等）。

需要先說清楚一件事：這個倉庫只是用戶端。README 明確寫明，後端服務位於另一個倉庫，不在本倉庫中。所以「開源」指的是用戶端原始碼，而不是整套雲端服務。閱讀這個專案時，應當把這一點放在最前面。

核心架構：harness × 模型 × 工具的三層解耦

從 README 的描述來看，Cindy 的設計重點是把三件事拆開： 第一層是 harness。目前首批支援的是 Claude Code 和 Codex，官方說明還會加入更多，並且正在開發自有的原生 harness。倉庫裡的 apps/*-bin 目錄存放隨桌面端發佈的工具二進位檔，其中 claude-code、codex 和 ripgrep 會在執行 pnpm install 時依平台下載，Android 的 platform-tools 則在 Windows 打包前以固定版本並校驗 sha256 的方式取得。也就是說，Cindy 並不是重新實作一個編碼代理，而是把現成的代理 CLI 當作可替換的「執行引擎」來內建和調度。

第二層是模型。模型和 harness 可以自由搭配，並且在任務進行中途切換。README 給出了四種接入方式：登入官方 Cindy 服務（用量透明扣費）；授權使用者已經在付費的 Claude Code / Codex Coding Plan，在 Cindy 裡繼續使用而不重複付費；自帶 API Key；或者使用本地模型。 第三層是跨執行引擎保持連續的「工作環境」：工作區、記憶、技能和工具在切換 harness 或模型時保持不變。這是整個設計裡最有價值、也最難做好的部分，因為不同代理對上下文、工具呼叫格式和技能描述的約定並不相同，要做到「換引擎不丟狀態」，需要一層自己的抽象。

多代理協作：規劃、並行執行、交叉評審

README 提到，一個任務甚至可以由不同的 harness × 模型組合分別承擔規劃、並行執行和評審。這與近來多代理工程裡常見的做法一致：讓一個模型做拆解，讓多個執行者在互不重疊的範圍內並行工作，再讓另一個不同來源的模型做獨立評審，以降低同一模型自我評審時的盲區。Cindy 把這種流程做成產品能力，而不是讓使用者手工拼腳本。

除了程式碼任務，Cindy 還能操作瀏覽器、電腦和手機，並能從即時通訊（IM）和排程中接收工作。這意味著它的目標不止是「寫程式的助手」，而是一個常駐的通用工作代理。

「可塑造」的部分：記憶、技能、自動化、MCP、外掛

專案用「Yours to shape」概括可擴充性：記憶（糾正一次，之後跨 harness 共享）、技能（教會一種工作方式，到處複用，團隊分發功能仍在開發中）、自動化（週期性任務自己排程、執行並回報）、MCP（把內部工具和業務系統接入）、外掛（透過開放市集分享，仍在籌備中；目前可透過 SkillHub 或手動安裝）以及原始碼本身（可稽核、可 fork、可回饋）。

部署與使用模式

登入介面提供兩種模式。一種是使用 Cindy 雲端帳號的託管服務；另一種是「Skip Sign-In」，不需要帳號即可執行本地代理，應用裡顯示為「未登入」，但依賴伺服器端的能力在該狀態下不可用。用戶端預設連接官方雲端服務，端點清單在 config/endpoint.json 和 config/endpoint.global.json 中，桌面端自動更新也走官方 CDN。

開發者建置時可用 pnpm restart:desktop:remote --region=cn 或 --region=global 連接自己的帳號進行開發。環境需求是 Node.js 22.x、pnpm 10.x（暫不支援 v11）和 Git LFS。Linux 使用者可參考倉庫中針對 Ubuntu、Arch Linux 和 Omarchy 的安裝文件。

效能與成本：目前沒有公開基準

這一點必須如實說明：README 沒有給出任何基準測試數據，也沒有延遲、成功率或成本的比較。因此無法對「比單獨使用 Claude Code 或 Codex 快多少、準多少」下結論。

可以確定的只有成本結構：如果使用既有的 Coding Plan 授權，不產生重複帳單；如果使用官方服務，則按用量扣費；自帶金鑰或本地模型則由使用者自行承擔。多代理並行評審會成倍增加 token 消耗，這是此類設計共有的成本取捨，具體數字需要實際使用後量測。

影響、侷限與展望

對開發者而言，Cindy 的價值在於減少在多個代理工具之間搬運上下文，並把評審環節制度化。對企業而言，Apache-2.0 的用戶端、可稽核的原始碼和「本地執行、使用真實檔案」的模式有吸引力，但資料路徑仍取決於所選的模型來源和是否使用官方雲端服務。

侷限同樣明顯。第一，後端不開源，託管服務的行為無法稽核。第二，讓代理操作真實檔案、已登入的應用和手機，權限面很大，提示注入和誤操作的風險需要使用者自行評估與隔離。第三，對上游 CLI（Claude Code、Codex）的依賴意味著上游介面或授權條款變化會直接影響 Cindy。第四，原生 harness、團隊技能分發和外掛市集都還在「籌備中」，路線圖尚未兌現。後續值得關注的是：原生 harness 的發佈、更多 harness 的接入、獨立的第三方評測，以及安全模型的文件化。