它想解决什么问题：换个 AI 工具，记忆就"清零"
如果你同时用过 Claude Code 和 Codex，大概率经历过这种别扭：Claude Code 擅长拆任务、写方案，Codex 上手快、执行利落，但两边的记忆、技能、工作区各管各的——换个工具，就得把背景、规范、踩过的坑重新交代一遍。项目 Cindy（github.com/makecindy/cindy）想干的正是这件事：不是「再做一个编程 Agent」，而是做一个「宿主」，把散落各家的 harness 和多家的模型，统一编排进同一个 Agent 运行时里。
先看一组数据（2026-10-27 实测，GitHub REST API）：6,788 星、今日单日 +1,296 星、817 个 fork、TypeScript、Apache-2.0 协议，7 月 22 日建仓，最近一次推送就在当天凌晨。官方一句话定位是「Consider it done. The open-source AI agent that works out of the box.」——想到，就能做到；开源、开箱即用的 AI Agent。
定位：不是"再做一个编程 Agent"，而是"宿主"
它和普通「编程 Agent」最大的区别，是「宿主」这个身份。下面五条能力，把它和「单点最强的编程 Agent」区分开来。
本地运行，用的是真实资产
Agent 直接跑在你自己的机器上，操作的是真实的文件、你已登录的应用，而不是一个与世隔绝的云端沙箱。这一条决定了它更接近「替你干活的助手」，而不是「一个只能聊天的网页」。
首批 harness：Claude Code + Codex
第一批接入的 harness 是 Claude Code 和 Codex，原生的 harness 还在开发中。所谓 harness，可以理解成「驱动 AI 干活的执行框架」，Claude Code 和 Codex 就是两家主流的框架。
模型与 harness 自由混用、任务中途切换
模型与 harness 可以自由组合，任务做到一半也能切换，而 workspace、memory、skills、tools 这四样东西保持连续，不随切换而中断。这是它最核心的一条承诺。
一个任务，多组「harness × 模型」分工
一个任务可以被多组「harness × 模型」分工完成——让一组组合做计划、另一组并行执行、第三组负责评审。把「规划者」和「执行者」做成不同模型、不同 harness，本身就降低了「同一个模型既当运动员又当裁判」的自评偏差。
跨设备执行：浏览器、电脑、手机
它支持驱动浏览器、电脑、手机，并能从 IM（即时通讯）和日程里直接接收任务。你可以从聊天窗口或日历上把活派给它，它再调度到对应设备上跑。
六大"可塑形"面：把 Agent 能力拆成模块
官方把 Cindy 的能力拆成六个面（Yours to shape），这六个面是理解它和同类产品差异的钥匙。
Memory：跨 harness 共享的记忆
记忆跨 harness 共享，纠正它一次就长期生效，不会因为换个 harness 就「失忆」。这是「连续性」承诺在记忆维度的落地。
Skills：教一次，到处复用
技能教一次就能到处复用，团队共享的技能库还在开发中。相当于把「怎么做事」沉淀成可复用的技能包。
Automation：周期任务自排自跑
周期任务可以自己排期、自己跑、自己汇报，无需人盯。适合定时抓数据、定时生成周报这类重复劳动。
MCP：接入你的业务系统
通过 MCP（Model Context Protocol，AI 与外部工具对接的通用协议）接入你已有的内部工具和业务系统，让 Agent 能调用真实业务能力。
Plugins：开放插件市场
开放的插件市场正在建设中，未来第三方可以往里塞能力。
Source：Apache-2.0 可审计
源码采用 Apache-2.0 协议，可审计、可 fork。对在意安全与透明度的团队来说，这是一条硬性的可验证承诺。
架构：开源的是客户端，服务端在另一个仓库
看代码之前，有一处边界必须先说清楚。
pnpm monorepo 的结构
仓库是 pnpm monorepo 结构，根目录下是 apps/（Electron 桌面端 + Expo/React Native 移动端 + 工具二进制）、packages/（auth、device-link、agent orchestration、model providers 等共享能力）、docs/、i18n/ 等目录，工程约定文件（AGENTS.md、CLAUDE.md、DESIGN.md、CONTRIBUTING 等）一应俱全。
服务端闭源：评估风险的边界
README 里有一句很关键的话：后端服务在独立的仓库里，不属于这个 monorepo。也就是说，开源的只是客户端，「开箱即用」依赖官方云服务（cindy.app）提供托管能力。即便你授权了自己已付费的 Claude Code / Codex 的 Coding Plan（不重复计费），编排层和账户层仍然跑在官方服务端。一句话概括：这是一个「可审计的客户端 + 不可审计的服务端」的组合，评估风险要按这个真实边界来。
供应链上的细节，值得单独说一句
有几个工程细节做得比较扎实，单独拎出来说。
工具二进制按平台下载
apps/*-bin 目录不提交任何二进制文件；claude-code、codex、ripgrep 这些依赖由 pnpm install 按平台下载，避免把大体积二进制塞进 Git 仓库。
sha256 校验 + 固定版本
Android platform-tools 采用固定版本 + sha256 校验后再打包进 Windows 发行版，这是把「安装期拉取」的供应链风险压到最低的常见做法。
日更级的 beta 发布节奏
v0.1.118-beta（10-27）、v0.1.117-beta（10-26）、v0.1.115（10-23）连续放出，属于日更级的 beta，正式版与 beta 并存。
四种接入方式，任选其一
想用它，有四条路，按自己的情况挑。
官方托管服务
注册 Cindy 云账户，用量透明扣除。最省事，但依赖官方服务端。
复用已有的 Coding Plan
授权你已有的 Claude Code / Codex 计划，在 Cindy 里继续用，不重复计费。对已经订阅了这两家付费计划的人来说，这条路最省。
自带 API Key
直连你自己的模型供应商，把模型层掌握在自己手里。
本地模型
支持跑本地模型，适合对数据出域敏感的场景。
对想搭自己 AI 工作台的人，能抄走什么
Cindy 有几条方法论，比它这个产品本身更值得借鉴。
把「连续性」写成硬指标
模型与 harness 解耦、任务中途可换，但 workspace、memory、skills、tools 连续——这恰恰是多 Agent 场景里最容易断裂的一环（换模型等于换人设、换上下文）。把「上下文连续性」写进自己工具的选型硬指标，比追求单点最强更实在。
计划 / 执行 / 评审的异构分工
让不同模型、不同 harness 分别做计划、执行、评审，用「评审者与执行者异构」降低同模型自评偏差。这对任何想用多 Agent 协作的团队都有参考价值。
能力六面叙事框架
Memory / Skills / Automation / MCP / Plugins / Source 这套六面拆解，是一套干净的对外叙事模板，也正好是一张「一个 AI 助手该具备哪些能力」的能力清单。
「开箱即用」的最小闭环
「一句提醒 + 真实资产 + 跨设备 + 从 IM/日程接活」构成的最小闭环，不追求单点最强，而追求入口最省事。对面向运营、客服、跟单这类业务角色的团队，比「最强编程 Agent」更贴业务。
脚本分发规范对标
工具二进制按需下载 + sha256 校验的做法，可以作为多平台脚本分发的规范参考。
两个不能忽视的风险
漂亮归漂亮，真要上手之前，这两个信号值得冷静看一下。
2,050 个 open issues 异常偏高
对一个 6,788 星的项目来说，2,050 个 open issues 这个数字异常高（作为参照，同期的同类新项目 open issues 多在几十到两百出头的量级）。这通常是「消费级体验冲量 + 质量债」的信号——体验做得好、传播快，但问题积压也多。结论是：不建议直接引入生产链路。
服务端闭源 + 日更 beta
客户端 Apache-2.0 不等于全链路开源，「自己托管」目前还不具备完整前提；日更 beta 意味着 API 和协议仍可能漂移，真要对接得锁版本。
同日上榜的其它新项目，做个对照
同一天榜单上还有几个新项目，放到一起看能更清楚 Cindy 的位置。
JetBrains/thinkrail：把意图写进 SPEC.md
JetBrains 官方的 agentic IDE（3,171 星，TypeScript，Apache-2.0），核心思路是「Specs as ground truth」——代码旁维护 SPEC.md 文件图谱，让意图跨会话存活。它的「隔离工作区 = git worktree」和「MCP 调用前先问」两处设计，也很有代表性。
nightly-labs/openbot：给 AI 队友配持久身份
local-first 桌面工作区（1,646 星），给每个 AI 队友配独立的持久身份、工作区与会话。它自带一条安全告示：当前是 development preview，Agent 以 danger-full-access + 免确认运行——这条「免确认 Agent 不进生产」的警示，比项目本身更值得记住。
pollen-robotics/microduck：一只微型双足鸭子
12,524 星的 Rust 项目，定位是一句「A Tiny biped duck robot」——微型双足鸭机器人。和 Cindy、thinkrail 同量级，但零 Agent 属性，属于「技术视野」范畴，与业务无直接交集。
电商团队怎么用
如果你在做电商运营，这套东西更现实的价值不在「自己部署一个 Agent」，而在它的两个思路。
把「上下文连续性」当成选型硬指标
电商团队日常在客服、选品、跟单之间切换多个 AI 工具，最容易断的就是上下文。把「换工具、换模型但不丢记忆和技能」当成硬指标去要求你手上的工具，比追求单个模型最强更实在。
用异构分工降低自评偏差
选品方案让一个模型列，跟单执行让另一个跑，再让第三个做交叉检查，能明显降低「同一个模型自说自话」的偏差。
什么时候别碰它
想要稳定投产的人，再等等
如果你想要的是一个能立刻接入生产、稳定跑业务的方案，现在还不是时候——2,050 个 open issues、服务端闭源、日更 beta 这三点叠加，说明它更适合「看方法论、攒思路」，而不是「今晚就上线」。
小结
Cindy 的价值不在「又一个编程 Agent」，而在它把两件容易断的事做成了产品承诺：模型与 harness 解耦、任务中途可换，但上下文连续；以及把「计划 / 执行 / 评审」拆成异构组合分工。对想搭建自己 AI 工作台的开发者和电商团队来说，它是一份值得借鉴的设计样本；对想「开箱即用、稳定投产」的人来说，还得再等等。