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 授权，不产生重复账单；如果使用官方服务，则按用量扣费；自带密钥或本地模型则由用户自行承担。多代理并行评审会成倍增加令牌消耗，这是该类设计共有的成本权衡，具体数字需要实际使用后测量。

影响、局限与展望

对开发者而言，Cindy 的价值在于减少在多个代理工具之间的上下文搬运，并把评审环节制度化。对企业而言，Apache-2.0 的客户端、可审计的源码和“本地运行、使用真实文件”的模式有吸引力，但数据路径仍取决于所选的模型来源和是否使用官方云服务。

局限同样明显。第一，后端不开源，托管服务的行为无法审计。第二，让代理操作真实文件、已登录的应用和手机，权限面很大，提示注入和误操作的风险需要用户自己评估与隔离。第三，对上游 CLI（Claude Code、Codex）的依赖意味着上游接口或授权条款变化会直接影响 Cindy。第四，原生 harness、团队技能分发和插件市场都还在“筹备中”，路线图尚未兑现。后续值得关注的是：原生 harness 的发布、更多 harness 的接入、独立的第三方评测，以及安全模型的文档化。

采用建议

如果打算试用，建议先用“Skip Sign-In”模式在一个隔离的测试目录里运行本地代理，观察它对文件和应用的实际操作范围，再决定是否接入真实账号、真实仓库和常用应用。同时，先在小任务上比较单独使用 Claude Code 或 Codex 与通过 Cindy 编排两种方式的耗时、令牌用量和结果质量，用自己的数据补上公开基准的空白。