cindy
熟读唐诗三百首，不会作诗也会吟。——孙洙
她不住在云端：Cindy 把一整支 agent 团队安在了你的桌面上
「开箱即用」这四个字，通常是最贵的四个字
软件行业有个老习惯：把「开箱即用」写进第一行宣传语，然后在第三页开始列出十七步配置。
所以当我看到 Cindy 的描述时，第一反应是怀疑。英文一句「Consider it done」，中文一句「想到，就能做到」，两边都没有讲功能，只讲了一个状态：你说完，事情就办完了。
支撑这句话的，是紧随其后的三个限定词，而且每一个都很具体：开源、开箱即用、在你自己的电脑上干活。
项目地址：https://github.com/makecindy/cindy
第三点是最容易被忽略、也最要紧的一点。她跑在你自己的机器上，用的是你真实的文件、你真实登录着的应用。这不是一句部署方式的说明，这是一个立场：agent 要干活，就得进到工作现场，而不是站在门外递纸条。
她是谁
一句自我介绍：Cindy 是一个开箱即用的开源 AI agent。她把多种 harness、模型和工具收进同一个 agent 里，在你的项目和 app 里把真活干完。第一天就能用，之后随你改。
这句话里有个词需要停一下：harness。
在 AI 编程这个语境里，harness 指的是那层把模型包起来、给它工具、给它循环、让它能连续行动的外壳。Claude Code 是一个 harness，Codex 也是一个 harness。它们各自有各自的脾气、各自的工具集、各自的上下文管理方式。
Cindy 做的第一件事，是把这些外壳当成可替换的零件，而不是不可让渡的立场。
一个不太常见的抽象
文档说得很清楚：第一批支持的 harness 是 Claude Code 和 Codex，更多还在加，一个原生 harness 也在做。
然后是那句真正的设计宣言：模型和 harness 可以自由混搭，并且能在任务中途切换，而你的工作区、记忆、技能和工具保持连续。
这句话如果只读一遍，会觉得是营销话术。读第二遍会发现它在拆一个很硬的技术约束——大多数 agent 工具把「会话状态」和「运行时」绑死了，换模型等于重开一局。而这里把四样东西抽出来，做成了与运行时无关的公共层：
工作区、记忆、技能、工具。
只要这四样是连续的，上面换谁在思考，就不影响下面正在做的事。
更极端的一句在后面：一个任务甚至可以由不同 harness 与模型组合的 agent 来规划、并行执行、再评审。
想象一下这个画面。规划的是一个模型，执行的是另外三个并行跑在不同 harness 上的实例，最后来验收的又是另一个。它们共用一个工作区，看得见彼此留下的文件，记得住同一段上下文。
这已经不是「一个助手」了，这是一支有工种的施工队。
她还能伸手到屏幕外面
文档提了一句很容易被略过、但野心很大的能力：她能驱动你的浏览器、你的电脑、你的手机，也能从 IM 和定时任务里接活。
浏览器、电脑、手机，三个层级。前两个是「操作界面」，第三个是「操作另一台设备」。而 IM 和定时任务这两条入口，意味着她不必等你打开 app——活可以自己找上门。
一个 agent 的价值，很大程度上取决于它能不能被「叫醒」。只能被对话框叫醒的 agent，本质上还是一个更聪明的搜索框。
随你改，改的是六样东西
文档里有一节叫「Yours to shape」，直译是「随你塑形」。它先给了一句判断：开源不只是看得见，而是改得动。
然后列了六件事，每一件都对应一个具体机制：
记忆。 纠正她一次，从此她就按对的来，而且这份记忆跨 harness 共享。
技能。 教她一种工作方式，一次就够，到处复用。把技能交给团队这件事，正在做。
自动化。 周期性的工作自己排期、自己跑、自己回来汇报。
MCP。 把你内部工具和业务系统接进她的可及范围。
插件。 改造功能、界面和交互，通过一个开放市场共享，这一项也在做。
源码。 审计、fork、扩展，改进按 Apache-2.0 回贡。
六条里，前两条是「她记得住」，中间三条是「她伸得够远」，最后一条是「你能拆开看」。
值得留意的是「正在做」这个标注出现了两次。一份文档愿意在功能列表里标出未完成项，说明它把「已经能用的」和「打算做的」分得很开。
这个仓库里到底有什么
它不是一个单体应用，是一个 pnpm monorepo，装的是客户端——桌面端、移动端，以及它们共享的包。
| 路径 | 装的是什么 |
|---|---|
apps/desktop |
Electron 桌面客户端 |
apps/mobile |
Expo / React Native 移动客户端 |
packages/* |
共享的客户端能力：认证、设备连接、agent 编排、模型提供方等 |
apps/*-bin |
随桌面应用分发的工具二进制 |
最后一行有个细节值得说：这些二进制一个都没有进仓库。claude-code、codex、ripgrep 会在 pnpm install 时按平台下载；Android 的 platform-tools 则在 Windows 打包前拉取，指定固定版本并做 sha256 校验。
这个做法同时解决两个问题：仓库不会因为塞了几个几十兆的二进制而臃肿；每一个二进制都是可追溯的确定版本，而不是「某人某天扔进来的那一份」。
另外还有一句明确的边界声明：后端服务不在这个仓库里，它住在另一个仓库，不属于这个 monorepo。
把客户端开源、把服务端留在外面，这是一个很清醒的切法。客户端是你需要审计、需要改、需要 fork 的部分；服务端是运营与成本所在。两者混在一起，开源就变成了一种负担而不是承诺。
两种身份：登录，或者不登录
| 模式 | 账号要求 | 能用到什么 |
|---|---|---|
| 托管服务 | 需要 Cindy 云账号 | 使用完整的托管服务 |
| 跳过登录 | 不需要 Cindy 账号 | 使用本地 agent，应用状态显示为「未登录」，服务端能力不可用 |
第二条值得专门解释，因为文档专门解释了两遍：登录页上的「Skip Sign-In」，是在没有 Cindy 账号的情况下跑本地 agent，它不等于「连接到一个本地服务器」。在这个状态下，所有依赖服务端的能力都不可用。
这个区分看着像咬文嚼字，其实是诚实。它把「本地能干什么」和「云端能干什么」的边界摆在明面上，而不是让你在使用中慢慢撞墙。
把模型带进来的四种方式
这是这类工具最现实的一节：钱怎么算。
文档给了四条路。登录官方 Cindy 服务，用量透明扣减；授权你本来就在付费的 Claude Code / Codex Coding Plan，在 Cindy 里继续用，不产生重复账单；接自己的 API key；或者用本地模型。
第二条是整段话里最值得鼓掌的一句。「不产生重复账单」意味着它没有把你的既有订阅当成竞争对手，而是当成一种可以复用的凭证。对一个还没形成付费习惯的市场来说，这个选择比任何功能都更能降低试用门槛。
跑起来：三道前置，四条命令
前置条件只有三行，但每一行都可能绊人：
- Node.js 22.x
- pnpm 10.x，而且明确写了 11 还不支持
- Git LFS
第三条是最容易被忽略的。仓库里必然有大文件走 LFS，忘了拉，克隆下来就是一堆指针文件。
最小启动路径：
1 | git lfs pull |
在克隆并进入目录之后，这两条就够了。剩下的贡献者配置、依赖更新、访问权限要求，文档指到了贡献指南里。插件的安装走 SkillHub 或者手动。
开发入口：一个不该踩的默认值
桌面端有两个启动命令，差别只在区域：
1 | # 中国大陆的 Cindy 账号 |
远程开发用的是你自己的 Cindy 云账号和现有的登录状态，所以你可以在开发客户端的同时接着已有的会话干活。中国大陆账号用 cn，其他人用 global——文档还专门补了一句：不要依赖内部的默认值。
这句提醒很有意思。它说明默认值确实存在，而且确实不该被依赖。一个会写「别信默认值」的文档，通常是被默认值坑过的人写的。
默认连官方服务器，这是故意的
很多开源客户端的第一反应是「自己搭一个后端」，Cindy 的选择相反：客户端默认连接官方云服务，端点清单放在两个配置文件里，桌面端的自动更新也走官方 CDN。
文档把这个决定解释得很直白：这是有意为之——外部开发者不需要自己托管一套服务，用你自己的账号登录开发版，直接对着官方服务器开发与测试。
这个决定省掉的是一整条自建链路的维护成本。代价是开发环境的网络依赖变强了，但换来的是「克隆完就能跑通真实链路」。
还有一个细节能看出团队的谨慎：Skill Hub 迁移用了两个不同的清单字段。已发布的客户端继续用旧的 skillhubApiBaseUrl，也就是那个已废弃的 XD 代理；当前客户端用 cindySkillHubApiBaseUrl。而当新端点缺失时，当前客户端刻意不回落到旧字段。
不回落是一种态度。回落看起来更稳健，实际会让一个配置错误悄悄变成一次降级运行，等到发现问题时已经过去了很久。宁可报错，不要含糊。
遥测：默认有，但拆得掉
官方分发的构建里带了 TapDB 的使用分析，用于产品层面的聚合统计，收集的是设备、系统、app 版本这类元数据，登录后与账号 ID 关联。
文档同时划了三条不碰的线：不收集聊天内容、不收集文件内容、不收集工作目录数据。登录云账号期间，客户端会发一个在线心跳，内容只有账号 ID、平台和版本。崩溃转储留在本地，不会自动上传。
然后是给「从源码构建的人」的准备：你不必保留分析。
移动端默认就是关的——构建时如果不注入 TapDB 的 clientId 和 clientToken，对应的分析模块就是一个空实现。桌面端可以彻底剥掉，只要删掉渲染进程入口里那一行 initTapdb() 调用，实现代码在对应的 analytics 目录里。
这段话的信息量在于它给了精确坐标。不是「可以关闭」，而是「删哪一行」。
一起干活的规矩
贡献走 PR，进 main 分支。先读贡献指南，再用 PR 模板。
有一条硬性要求：每个 commit 都需要 DCO 签署，也就是 git commit -s；每个 PR 上有 DCO 检查强制执行，而且不需要签 CLA。
DCO 而不是 CLA，这个选择本身就表明了倾向。CLA 要求你把版权授权给项目方，DCO 只要求你声明「这个提交是我写的，我有权提交」。前者对企业有利，后者对贡献者友好。一个 Apache-2.0 的项目选 DCO，逻辑是自洽的。
安全问题单独走一条路：私密上报，不要开公开 issue。另有一条很朴素但总有人犯的规矩——永远不要把凭证或授权文件提交进工作树。
许可：一句授权，加一串例外
仓库源码整体走 Apache-2.0。单个源文件不带逐文件的许可头，以仓库根目录的 LICENSE 为准。
但紧接着是一段很重要的澄清：模型权重、数据集、提示词、商标以及其他被单独标识的材料，可能有各自的许可条款，不会被仓库级的 Apache-2.0 自动覆盖。第三方开源组件保留各自的版权与许可，归属声明和 SPDX 物料清单在 docs/legal/ 下管理，按产物拆分的输出在 docs/legal/notices/ 里。
这段话说的是常识，但很少有项目愿意把它写成正文。因为写出来就等于承认：这个仓库的「开源」不是一整块，它有边界，边界之外的每一块都要单独看。
最后
回到那句 slogan。
「Consider it done」之所以敢写，是因为它背后有一串很具体的支撑：本地运行、真实文件、真实登录态；harness 与模型解耦，可以中途换人；工作区、记忆、技能、工具在换人时不断；记忆能跨 harness 共享；自动化能自己排期；连账单都替你想过了——你已经付过的订阅，在这儿继续用。
这些加在一起，才凑得出「开箱即用」四个字的分量。
而她真正有意思的地方，是那个最不显眼的抽象：把「谁来思考」和「怎么干活」拆成两个独立的维度。一旦拆开，agent 就不再是一个模型的名字，而是一支可以临时组队、随时换人的施工队。
工具的形状，最后会塑造你思考的形状。当你习惯了一支能换人的队伍，你就不会再问「哪个模型最好」，你会问「这件事该派谁去」。