makecindy/cindy

解决什么问题

同时用 Claude Code 和 Codex 的人大概都有这个体验：两个 harness 各有一套工作区、各有一套上下文，你上周教会它的做法这周要重教一遍。一旦任务横跨文件、浏览器和手机，就得手动在几个会话间拼。Cindy 把这些 harness 收进一个跑在本机的 Agent 客户端，直接使用你真实的文件和已登录的应用，让上下文和工具在切换时不断档。

有什么不同

常见做法是选一个 CLI Agent 然后在外面写脚本，或者用 LangGraph 这类框架自己搭编排。Cindy 的赌注下在客户端层：harness 和模型可以自由搭配、任务中途切换，一个任务能由不同 harness × 模型的组合分别规划、并行执行和复核；记忆、技能和 MCP 连接是跨 harness 共享的，而不是绑定在某一个上。形态上它交付的是 Electron 桌面端加 Expo/React Native 移动端，和纯终端 Agent 是不同路数。

适合谁

适合想让 Agent 在自己机器上动真实文件和真实应用、并且在意能换 harness 或自带 API key 的开发者与技术型操作者。已经在付 Claude Code 或 Codex 订阅的人更划算，README 声称订阅可以沿用。不适合想要一个可嵌入服务端的无头 Agent 运行时的人——这是客户端，后端明确不在这个仓库里；也不适合只想引入一个轻量库而不是完整应用的人。

上手成本

需要 Node.js 22.x、pnpm 10.x（不支持 v11）和 Git LFS；Claude Code、Codex、ripgrep 的二进制会在安装时按平台下载。客户端默认连接 Cindy 官方云端接口和自动更新 CDN，自托管并不是受支持的路径。跳过登录后只能用本地 Agent，服务端能力不可用。官方发行版带 TapDB 统计（设备/系统/版本元数据，登录后与账号 ID 关联）和在线心跳，README 说明了从源码构建时如何去掉。README 对架构和构建流程写得很细，但对插件市场和团队技能共享的成熟度语焉不详，两者都标注为"in the making"。

点评

这是一个很年轻的项目：创建约三个月，四千星左右，只在 trending 榜上出现过一天（2026-10-24 单日 +471）。这是典型的短期冲高而非长期积累，且 Hacker News 上没有任何讨论，说明独立审视还很薄弱。多 harness 编排的思路确实比又一个聊天套壳有意思，Apache-2.0 加仅需 DCO 签名的贡献流程也很友好。但它的价值主张很大程度押在托管服务上，而仓库只是客户端，服务端那一半你看不到也跑不起来。如果你本来就重度使用 Claude Code 或 Codex，值得装来试一试；如果你要依赖它做正事，那它目前还算不上经过验证的基础设施。