为什么要把 Claude Code 和 Codex 塞进同一个 Agent？这个开源项目 3 周拿了 2,240 星

GitHub Trending 最近被一个叫 Cindy 的项目刷了屏。

7 月 22 日建仓，8 月 21 日已经 2,240 星、309 fork。项目简介只有一句话：“Consider it done. The open-source AI agent that works out of the box.”（想到，就能做到。开箱即用的开源 AI Agent。）

看仓库名 makecindy/cindy，第一反应是"又一个套壳客户端"。但点进去读完 README，你会发现它想解决的是一个更别扭的问题：

为什么用 Claude Code 的人，换到 Codex 时，一切都要从头开始？

一个被忽略的隐性成本：工具切换

过去一年，AI 编程工具圈最火的两个 CLI 是 Claude Code 和 Codex。前者擅长长上下文推理，后者跟 GitHub 生态绑得深。很多开发者是"双持"的——复杂重构用 Claude Code，PR 流程走 Codex。

但双持有个没人愿意提的代价：

• 换工具 = 换一套工作区状态
• 换工具 = 记忆清零，之前纠正过的错误要再纠正一遍
• 换工具 = 技能（workflow 文件、习惯用法）全部重新配置

这些"隐性成本"没人给你开发票，但每一单都收。cindy 想干的事，就是把这张发票撕掉。

核心思路：harness 只是"执行引擎"，可以随意混搭

cindy 的架构里有一个关键概念：harness（可以理解成"执行引擎"）。

它首次支持的 harness 有两个：Claude Code 和 Codex。后续还在加，原生 harness 也在开发中（见项目 README）。

但注意它的设计理念——模型和 harness 可以自由混搭，任务执行到一半也能切换。切换时，你的工作区、记忆、技能、工具全部保持连续，不断线。

翻译成人话：你不用再纠结"这活儿该用哪个工具"。让 Claude Code 写主体逻辑，让 Codex 去处理 GitHub 集成，中间不用退出、不用搬家。

仓库本身就是个标准的 pnpm monorepo，结构很干净：

路径	内容
apps/desktop	Electron 桌面客户端
apps/mobile	Expo / React Native 移动客户端
packages/*	共享能力包：auth、设备互联、Agent 编排、模型提供商等
apps/*-bin	随桌面端分发的工具二进制（不提交仓库）

特别值得一提的是 apps/*-bin 的处理方式：claude-code、codex、ripgrep 这些二进制不提交到仓库，由 pnpm install 按平台自动下载；Android platform-tools 在 Windows 打包前拉取固定版本并做 sha256 校验。依赖供应链安全这件事，很多大厂项目都没它做得细。

更狠的一招：Orca 多智能体编排

如果只是"多引擎切换"，cindy 顶多算个聚合器。它真正的杀招在编排层——仓库里的架构文档专门有一份 deep-dive：docs/dev-rules/，里面重点描述了一个叫 Orca 的多智能体编排机制。

机制本身一句话就能说清：

一个任务，可以被不同 harness × 模型组合的多个 Agent 并行规划、并行执行、交叉审查。

举个例子：一个重构任务，Orca 可以让 Claude Code 负责规划方案，让 Codex 并行执行两个独立模块的改造，再造一个 Agent 用不同模型组合审查前两者的产出。

这跟"一个 Agent 从头干到尾"是两种物种。后者的瓶颈是单模型的上限；前者把"模型多样化"直接变成了系统能力——同一个任务里，最强的模型出方案，最快的模型干体力活，最谨慎的模型做质检。

不只是套壳：记忆、技能、自动化、MCP 一个不少

编排之外，cindy 把"Agent 该有的长期能力"也补齐了：

• Memory（记忆）：纠正它一次，以后就做对了，而且跨 harness 共享——在 Codex 里纠正过的规矩，切到 Claude Code 依然生效。
• Skills（技能）：教一次工作方式，到处复用；团队间共享技能正在开发中。
• Automation（自动化）：周期性任务自己排期、自己执行、自己回报结果。
• MCP：官方支持接内部工具和业务系统，不用等插件生态。
• Plugins：通过 SkillHub 安装，开放插件市场也在规划中。

这一套组合下来，它的定位就清楚了：不是"又一个 AI 聊天框"，而是给本地设备装一个长期的、跨工具的 Agent 基础设施。它能驱动浏览器、控制电脑、操作手机，还能从 IM 和日程表里接活。

隐私与安全：本地运行，遥测克制

Agent 类工具最敏感的永远是数据。cindy 的处理方式值得单独拎出来说：

• 本地优先：运行在你自己的机器上，用的是你真实的文件和已登录的应用。
• "Skip Sign-In"模式：不注册账号也能跑本地 Agent，只是不能用云端能力（README 中的模式说明）。
• 遥测克制：官方发行版内置 TapDB 统计，只收集设备/OS/应用版本级别的聚合元数据，不采集聊天内容、文件内容、工作目录数据；崩溃转储留在本机，绝不自动上传。
• 源码可审计：整个客户端仓库 Apache-2.0 开源，遥测代码就摆在 apps/desktop/src/renderer/analytics/ 里，不放心可以直接删掉 initTapdb() 调用重新编译（隐私说明）。

开源治理上也做得很"正规军"：每个 commit 要求 DCO 签名（git commit -s），PR 有自动 DCO 检查，不需要签 CLA（CONTRIBUTING.en.md）。

写在最后：Agent 客户端正在进入"联邦"时代

当然，cindy 还很年轻。仓库里挂着 1,004 个 open issues，后端服务闭源，中文文档的完善度也还在路上。但它的出现本身，标志着 AI 编程工具正在进入一个新阶段：

竞争的主战场，从"单模型谁更强"，变成了"谁能把多个模型编排得更好"。

过去一年，大家的默认假设是"选一个工具，一条道走到黑"。cindy 代表的思路是反过来的：工具是消耗品，能力才是资产——记忆、技能、工作区这些跨工具沉淀下来的东西，才是真正的护城河。

对开发者来说，这其实是好事：模型切换的自由度越大，议价权就越在自己手里——今天用 Claude 写主体逻辑，明天换 DeepSeek 跑批量任务，成本只是换一个 harness 的事。

工具会过时，但沉淀下来的工作方式不会。这大概就是"开源 Agent 联邦"最性感的地方。