一个开源 Agent，凭什么同时驾驭 Claude Code 和 Codex？

凌晨一点，程序员老张的电脑上开着两个终端。

左边跑着 Claude Code，右边跑着 Codex。同一段重构，他想让两个模型各写一版，对比一下再决定用谁。

然后他发现：上下文不互通、记忆不共享、两边的工具链各玩各的。折腾到两点，他放弃了，手动复制粘贴两份代码，在脑子里对比。

这个场景，可能是今年开发者最痛的日常。

直到 cindy 出现在 GitHub Trending 上——一个"开箱即用"的开源 AI Agent，上线不到一个月，2101 颗星，279 个 fork。

它想解决的问题：harness 比模型更割裂

过去两年，AI 编程工具的竞争焦点是模型：GPT-4 还是 Claude，谁强用谁。

但 2026 年的开发者发现，真正锁死你的是 harness——那层把模型、文件系统、终端、权限绑在一起的壳。Claude Code 的记忆，Codex 不认；Codex 的规则文件，Claude Code 不读。

cindy 的答案很直接：把多个 harness 收编进一个 Agent。首个支持的 harness 就是 Claude Code 和 Codex，原生 harness 正在开发中。你的 workspace、记忆、技能、工具全部连续，模型和 harness 可以在任务中途自由切换。

换句话说：老张不用再开两个终端了。

最狠的设计：任务中途换引擎

普通 Agent 是"选一个模型，跑到结束"。cindy 允许同一个任务里换 harness × model 组合：

一个任务，可以由不同组合的 Agent 并行规划、执行、审查。

规划阶段用便宜的大模型铺思路，执行阶段切到 Claude Code 干重活，审查阶段换 Codex 挑毛病——这在传统工作流里是三个工具、三份上下文，在 cindy 里是一个任务的三段流水线。

这正是它 README 里说的"Orca multi-agent orchestration"（架构文档）要解决的核心问题：Agent 之间如何共享状态、如何交接上下文、谁来当仲裁者。

桌面 + 手机，一个 Agent 通吃

技术选型上，cindy 没有走 CLI 路线，而是直接做了客户端矩阵：

• 桌面端：Electron 应用，打包了 claude-code、codex、ripgrep 等二进制，按平台下载（monorepo 结构）
• 移动端：Expo / React Native，能在手机上接活
• 还能驱动你的浏览器、电脑和手机，从 IM 和定时任务里收指令

客户端是 Apache-2.0 开源的，但后端服务在独立仓库里，不在开源范围。这个"客户端开源、服务端闭源"的组合，和很多 AI 公司的玩法一致——代码给你审计，云服务留给自己。

商业模式：不让你重复掏钱

模型从哪来？cindy 给了四条路（定价页）：

1. 登录官方服务，按用量透明计费
2. 复用你已有的 Claude Code / Codex Coding Plan，不重复计费
3. 填自己的 API Key
4. 本地模型，完全离线

第二条最聪明。它不跟 Claude Code 抢订阅费，而是抢"壳"的位置——你反正已经付了 Coding Plan 的钱，在 cindy 里继续用，还能白得统一记忆和调度能力。如果需要在多个模型间做对比测试，像 likeai520.cc 这样也可以省掉不少折腾，一个 Key 通吃多个模型。

开源社区的玩法：Memory、Skills、MCP

cindy 的可扩展性设计很完整：

• Memory：纠正它一次，以后就记住，跨 harness 共享
• Skills：教一次工作方式，到处复用
• Automation：重复性任务自己排期、自己跑、自己汇报
• MCP：把内部系统和业务工具接进去
• Plugins：开放插件市场（制作中）

开源治理也规范：Apache-2.0 协议，每个 commit 要求 DCO 签名，不接受 CLA，社区贡献走 PR 进 main。

这会改变什么？

如果把 Claude Code、Codex 比作"浏览器"，cindy 想当那个"操作系统"——模型可以换、harness 可以换，但记忆、技能、工作流是你的，跟着你走。

老张们终于不用再在两个终端之间来回切了。真正的问题是：当 Agent 的"壳"开始比"引擎"更有黏性，下一场竞争的战场，就从模型能力挪到了状态管理。

这或许是 AI 编程工具链走向成熟的信号：模型不再是壁垒，工作流才是。

参考：cindy GitHub 仓库、cindy.app 官网、waku-agent（同批热门本地优先 Agent）