一天一个开源项目

一天一个开源项目（第250篇）：Cindy —— 开箱即用的开源 AI Agent，把你的电脑和手机连成一个人，并统一调度 Claude Code、Codex 与 Pi

Cindy 是一个开源的桌面加手机 AI Agent 客户端（Electron 加 Expo），不自己造引擎，而是把 Claude Code、Codex 和 Pi 收进同一个界面，再加上多设备接力、跨电脑共享模型供应商、手机远程桌面、伙伴与群聊、Orca 多智能体协同、插件与 Skill 体系。你的电脑就是服务器，不用租服务器也不用自己部署。Apache-2.0 协议，7000 多 Star，官方客户端免费但模型用量仍按供应商计费。

·约 20 分钟阅读·AI 工程
开源项目CindyAI AgentClaude CodeCodexElectronReact Native多设备开源

引言

你的工作电脑、家里的台式机、笔记本和手机，本来就该属于同一个人。

这是"一天一个开源项目"系列的第 250 篇文章。今天带你了解的项目是 Cindy（makecindy/cindy）。

当下的 AI 编程助手大多是"一台电脑上的一个终端"：Claude Code 在这台机器上，Codex 在那台机器上，换台设备就要重新开一个会话，手机上基本只能看。Cindy 想解决的就是这个断层：它不替换你已有的 Agent，而是把它们和你的设备连起来。

README 的第一句话是："Cindy 是一个开箱即用、可以自己塑造的开源 AI Agent。"副标题则是中文那句：想到，就能做到。

你将学到什么

  • Cindy 是什么，以及它为什么选择"整合已有引擎"而不是自造一个
  • 多设备接力、模型共享和手机远程桌面是怎么设计的
  • 伙伴（Bot）、群聊、Orca 多智能体协同分别解决什么问题
  • 插件与 Skill 体系，以及"存量插件兼容是红线"这样的工程治理
  • 隐私与遥测的实际情况（README 写得相当直白）
  • 仓库的结构、规则文档的组织方式，以及适用边界

前置知识

  • 了解 Claude Code 或 Codex 这类编程 Agent 的基本用法
  • 知道 MCP、Skill 大致是什么
  • 如果想读源码：了解 Electron、React Native / Expo 和 pnpm monorepo

项目背景

项目简介

Cindy 是一个 AI Agent 客户端，覆盖 macOS、Windows、Linux、iOS 和 Android。仓库里包含桌面端和手机端两个开源客户端及其共享包。

它的核心主张是三件事：

  1. 所有设备，一个 Cindy：在另一台设备上打开同一个任务、继续对话、访问它的文件
  2. 保留你喜欢的 Agent：Claude Code、Codex 和 Pi 并存，一个任务可以换引擎
  3. 在真实工具里做真事：操作你的文件、浏览器和应用，回答里可以带图表、交互控件和富 HTML

作者与团队

  • 组织：makecindy
  • 创建时间：2026-07-22
  • 贡献者：提交量靠前的有 dashhuang、zqchris、MagicLizi、DavidShenXD（各 1000 以上）
  • 官网：cindy.app
  • 版本节奏：从 v0.1.108 到 v0.1.118 在两周内连续发布，包含稳定版和 beta 版

README 里还说明了一件事：后端服务在另一个仓库，不属于这个 monorepo。开源的是客户端。

项目数据

数据取自 2026-10-27 的 GitHub，仅供参考：

  • ⭐ GitHub Stars: 约 7,100
  • 🍴 Forks: 约 850
  • 🐛 Open Issues: 约 2,080
  • 📦 最新版本: v0.1.118-beta（最近的稳定版是 v0.1.115）
  • 📄 License: Apache-2.0
  • 🌐 官网: cindy.app
  • 💻 语言构成: TypeScript 为绝对主体，另有 JavaScript、Swift、Python、Rust、Kotlin 等

主要功能

核心作用

Cindy 的定位是一个统一的工作界面，下面接着多个 Agent 引擎，旁边连着你所有的设备：

层内容
引擎Claude Code、Codex、Pi（一个精简、开源、可扩展、支持多家模型供应商的 Agent）
设备工作电脑、家用台式机、笔记本、手机，通过同一账号互联
工具文件、浏览器、应用、MCP、Skill、插件
角色伙伴（Bot）、群聊、多 Agent 协同团队

使用场景

  1. 在手机上接着做电脑上的事

    • 打开另一台设备上的任务，继续对话并访问其文件，不必把东西复制进新对话

  2. 借用另一台电脑上的模型

    • 使用配置在另一台电脑上的供应商，包括订阅、API 和本地模型

  3. 聊天不够用时直接操作整台电脑

    • 手机里内置远程桌面，可以打开应用、输入、操作

  4. 让一个"队长"带一队 Agent

    • 不同 Agent 分别负责规划、并行实现和独立评审，目标和验收标准共享

  5. 定时任务与聊天渠道接入

    • 用自动化建立例行工作，通过 Slack、Telegram 等渠道交办

快速开始

普通用户：到 cindy.app/download 下载客户端。Linux 用户可参考仓库里的 docs/linux.md（覆盖 Ubuntu、Arch Linux 和 Omarchy）。

登录页有一个 Skip Sign-In（跳过登录）选项：可以只用本地 Agent，此时应用会显示"未登录"，依赖服务端的能力不可用。

开发者：

git clone https://github.com/makecindy/cindy.git
cd cindy
git lfs pull
pnpm install

环境要求：Node.js 22.x、pnpm 10.x（暂不支持 v11）、Git LFS。

启动桌面端开发（连接官方服务）：

# 中国大陆账号
pnpm restart:desktop:remote --region=cn
 
# 全球账号
pnpm restart:desktop:remote --region=global

README 强调：用 cn 还是 global 要明确指定，不要依赖内部默认值。

模型与费用

README 对这点写得很清楚：

  • 客户端免费
  • 可以授权你已经付费的订阅（包括 Claude Code 或 Codex 的套餐）、接入自己的 API Key、使用本地模型，也可以用 Cindy 的托管模型服务
  • 供应商限额和计费照常适用，免费的客户端不等于无限的模型用量

核心特性

  1. 多设备接力

    • 同账号的设备互相发现，任务可在设备间继续；项目文件留在原电脑上，不是整盘同步

  2. 跨设备共享模型

    • 把一台电脑上的供应商共享给自己的其他设备，甚至通过分享链接共享给其他账号

  3. 手机远程桌面

    • 内置，有独立的权限控制

  4. 三引擎并存

    • Claude Code、Codex、Pi，会话保留在 Cindy 里；切换引擎时是交接或重建引擎上下文，而不是让它们的内部状态完全一致

  5. 伙伴与群聊

    • 可以给伙伴设定角色、指令、Skill 和周期性工作，也可以把多个伙伴放进群聊协作

  6. Orca 协同

    • 一个 Lead 会话拆任务、派活、验收，多个 Worker 会话并行或串行执行

  7. 插件、Skill 与 SkillHub

    • 在 SkillHub 里发现 Skill 和插件，也有官方插件仓库 cindy-official-plugins

  8. 富回答

    • 图表、交互控件和富 HTML，而不是一堵文字墙

项目优势

对比项Cindy单独使用 Claude Code / Codex自建远程方案（SSH 加 tmux 等）
多引擎三个引擎同一界面，可切换各用各的自己拼
多设备账号互联，手机可操作以单机终端为主要自己搭链路
服务器你的电脑就是服务器，不用租也不用自建不涉及需要自己维护
手机体验原生手机客户端，含远程桌面弱终端体验差
开放性客户端 Apache-2.0，可审计可 Fork视引擎而定完全自控

为什么值得看？

  • 它选了一条不同的路：不卷"自己造一个更强的 Agent"，而是做 Agent 之上的设备、角色与协作层
  • 仓库本身就是一份大型 AI 辅助开发项目的工程治理样本，AGENTS.md 写得非常细
  • 隐私说明几乎是"把一切摊开讲"，包括已知例外

项目详细剖析

仓库结构

README 里的表格：

路径说明
apps/desktopElectron 桌面客户端
apps/mobileExpo / React Native 手机客户端
packages/*共享的客户端能力（认证、设备互联、Agent 编排、模型供应商等）
apps/*-bin随桌面端分发的工具二进制（Claude Code、Codex、ripgrep、Pi）

这些二进制都没有提交进仓库：Claude Code、Codex 和 ripgrep 由 pnpm install 按平台下载，Android platform-tools 则在 Windows 打包前以固定版本和 sha256 校验方式获取。

packages/ 下有三十多个包，值得留意的有：

  • maker-core：核心，Agent 抽象（BaseAgent）、会话编排与事件流，零 Electron 依赖
  • device-link 与 device-link-protocol：设备互联与协议
  • orca-workflow：多 Agent 协同工作流
  • model-providers、model-compat、anthropic-compat-proxy、responses-anthropic-bridge、responses-chat-bridge：模型供应商与各种协议之间的桥接
  • maker-cc-manager、maker-pi-manager、maker-remote-ssh：在远程 SSH 机器上运行的 Claude Code 与 Pi 守护进程
  • maker-scheduler：cron 引擎与定时任务
  • plugin-protocol、lizi-mcps：插件协议与内置 MCP
  • design-tokens：设计 Token
  • voice-input-core：语音输入

架构不变量

docs/dev-rules/architecture-invariants.md 收拢了影响面很大的几条规则：

  1. package 要与 render / main 解耦：package 是未来可以单独提供能力的模块，不得 import Desktop Renderer 组件，也不得反向 import Desktop Main；相关部分通过初始化或运行时配置、回调注入
  2. main 进程禁止运行时动态 import()：依赖一律用顶层静态 import，原因是动态 import 带来打包、加载时机与错误路径的不确定性
  3. 主界面布局树：布局真身是全局递归的 split / pane 树；面板身份只认 panelKind，禁止用"左栏 / 右栏"这样的位置充当业务身份；chat-main 在整棵树中必须恰好一个、始终可见、不可关闭、不可折叠，最小宽度 400px
  4. 布局是用户级配置而非 session 数据，启动时必须随首帧同步就位，禁止先画默认布局再跳成用户布局

其中还有一条体贴的设计：未注册、沉睡或已抽离的面板允许保留在存档里但不渲染，重新注入后必须原位恢复，不要用清理未知 panelKind 的方式破坏位置记忆。

多设备互联：device-link

跨设备的一切都建立在 device-link 上：一个带 relay 的协议，手机与桌面、桌面与桌面都走它。

以"供应商分享"的契约文档为例（docs/provider-sharing-contract.md），可以看到它的协议设计很严格：

  • relay 的信封里有一个可选的 providerShare 范围字段，同一帧不得同时带 sharedTask 与 providerShare
  • 能力协商：客户端在 hello 里声明 provider-share-v1，relay 回同名能力，双方都声明才能通信，否则回 VERSION_MISMATCH
  • source 字段只由 relay 写入，永不信任发送方提供的值
  • 邀请链接是一次性口令：43 位 base64url（randomBytes(32)），5 分钟过期，服务端只存 sha256；受邀者的申请 24 小时过期，带 4 位配对码
  • 被拒绝的帧回 relay-error，错误码统一用 DEVICE_OFFLINE，不暴露原因
  • 分享不随分享者离线关闭

供应商分享和"共享任务"是两套独立的授权，并且产品规则里允许中国大陆版与 Global 互享。

另外，remote-desktop.md 对远程桌面的描述也体现了很强的产品细节：悬停时不会启动桌面抓取，也不会抢走别的查看者的控制；窗口关闭确认只在连接建立后才出现；关闭窗口会立刻"退役"本地输入与心跳权限，租约清理在后台进行，远端不回复也不会让窗口一直关不掉。

引擎整合：Claude Code、Codex、Pi

Cindy 对引擎的态度是整合，不是替代。这一点在 AGENTS.md 的红线里最明显，其中关于 Pi 有一条：

Pi 原生能力非退化是红线：Pi 原生允许的安装、更新、扩展加载与 Agent 自助修复，Cindy 不得以静态分析、兼容提示、内容指纹、宿主审批或新增的"安全增强"为由拒绝、停用或变成不可逆流程；显式用户命令即授权。Cindy 只能增加可跳过的提示和更顺畅的 GUI，不能让 Cindy Pi 比同版本原生 Pi 更难用。

这是一个很克制的产品原则：套壳不能让底层引擎变差。

桌面端内置的四个二进制（claude、codex、ripgrep、pi）版本由 tools/<kind>/latest.json 固定，并由 tools/update.mjs 更新。

Orca：多 Agent 协同

docs/dev-rules/orca-team-architecture.md 是 Orca 的唯一权威文档，体量超过 12 万字符。核心模型：

  • 一个 Lead 会话负责拆任务、派活、验收与汇总
  • 多个 Worker 会话并行或串行执行
  • Worker 是完整会话，不是一次性 subagent：它有自己的模型、effort、工具调用流、上下文和可见历史

目前已实现的有：多 Worker（可设角色、标签、聚焦切换、软硬限制、归档）、Lead 与聚焦的 Worker 并排的分屏视图、本地 Claude Code / Codex / Pi 都能做 Lead 或 Worker，SSH 远端会话也可以。远端的 Codex 通过 SSH remote-forward 连接本机的 MCP bridge。

文档也直接写出了当前边界：

  • Orca Team 仍严格绑定单个 Lead 会话，不支持跨 Lead 共享 Worker
  • Worker 的聚焦切换是"单 Worker 面板替换"，不是多个并排
  • Worker 归档后 UI 里没有取消归档的入口
  • workflow_run / CC Workflow 编排尚未纳入
  • 通过 device-link 的协同，Lead / Worker / team 全部在被控端进程内编排，控制端只经隧道路由

文档的第二部分是"未来规划"：执行单元愿景、三态拆分、Worker 生命周期分型、Side Chat、控制面的九大机制。

伙伴（Bot）与能力继承

伙伴是有身份的 Agent：角色、指令、Skill、周期性工作。docs/dev-rules/agent-capabilities.md 里有一个体现设计演进的细节：

  • 新伙伴默认继承 Cindy 已启用的工具和连接（toolsetMode: inherit、mcpMode: inherit），创建时的显式选择优先
  • 旧格式无法可靠判断名单是用户设的还是系统生成的，所以 2026-10-02 产品确认：旧名单统一放开，不再靠"空 / 非空"去猜
  • 现有的 ask / auto / 完全访问档位保持原值
  • 文档如实写了已知边界：群专线、其他伙伴及自动化转来的消息沿用该 Agent 的能力与权限档，目前没有"按触发来源整轮降低权限"的实现

这类写法很罕见，不只记录"是什么"，还记录"为什么这样裁决"和"哪里还没做"。

插件系统与"存量兼容红线"

插件（.cindy）的规则在 docs/dev-rules/plugin-security-and-authoring.md（近 10 万字符）。AGENTS.md 里摘出的红线是：

存量插件兼容是红线：任何插件系统改动（含批准状态 schema、指纹格式、manifest 校验、安装布局、包格式）都必须向下兼容，用户升级后什么都不做，已装、已批准、已启用的插件必须照旧可用，绝不允许要求用户重新安装、重新确认权限或重新配置。做不到就必须自带从旧版数据的自动迁移；漏迁移等于 P0。

并且改到插件基座的 PR，一律走白名单确认门，需要放行人明确 Approve 才能合并，不看 diff 大小。

插件发现采用渐进式：ghost_list → ghost_info → ghost_call，用 ghost-progressive-discovery.md 规范。最新的 v0.1.118 里，"获准的插件现在能查看任务的运行状态与消息、接收关键事件，并在允许范围内触发整理或中断；插件通过宿主发起的操作也会统一计入用量"。

日志上传与脱敏：三条不变量

log-upload-and-redaction.md 里的三条不变量也值得一看，它们体现了对隐私的态度：

  1. 记录边界：写侧的续行转义和读侧的切分是同一条不变量的两半，破坏任何一侧都会让隐私逃逸
  2. 白名单方向：deny-by-default，不得改成黑名单，因为调试级别的功能日志是用户内容的主要泄漏源
  3. 标记代次加原子清除：并发实例下仅靠时间戳会误删另一个实例刚写的新崩溃标记

脱敏规则只增不减，放宽任何一条都视为隐私变更，需要重新评审。

工程治理：给 AI 协作者的入口

整个仓库对"AI 如何参与开发"设了一套明确的入口：

  • AGENTS.md 是 Codex 和 Claude Code 共用的项目指令正本，CLAUDE.md 只保留 @AGENTS.md，避免两处维护
  • 规则分三类：开发规则放 docs/dev-rules/，产品规则放 docs/product-rules/，设计规则放 docs/design-rules/
  • 根 AGENTS.md 只保留所有任务都适用的规则、风险入口和文档索引，模块专属规则放嵌套的 AGENTS.md
  • 每类改动都有"必须先读"的文档，比如改 Orca 前必须读 orca-team-architecture.md，改日志上传前必须读脱敏规则
  • 测试有"价值门槛"：新增测试必须通过真实生产入口验证可观察结果，说明依据、覆盖缺口和最小失败输入；pnpm check:test-hygiene 在 CI 里阻断违规，基线只减不增
  • 提交需要 DCO 签名（git commit -s），不需要 CLA

还有一个小细节：产品术语有统一的术语表（i18n/GLOSSARY.md），"任务 / 对话 / 消息"这三个词的边界被明确规定：session 面向用户叫"任务"，"对话"只用于任务内的交流，单条往来叫"消息"，"任务"与 task 同句出现时必须消解歧义。

隐私与遥测

README 对此写得相当坦率，这里摘要几点：

  • 官方发行版内置 TapDB 使用统计，包括设备标识、系统与应用版本、启动与活动事件；登录后事件会关联账号 ID，所以不是完全匿名。TapDB 不采集聊天内容、文件内容和工作目录数据
  • 可以不改代码关闭：桌面端在 设置 → 关于 → 使用统计；手机端在设置里的使用统计。默认开启
  • 已知的手机端例外：企业 SSO 登录会跳过隐私政策接受步骤。如果没有同意记录，并且该登录在重启后恢复，当前的迁移逻辑可能把一个全新安装也标为已同意；TapDB 配置存在且统计开启时，上报可能在没有明确接受政策的情况下开始。关闭"使用统计"可阻止这次迁移启用上报。README 直接链接了相关源码
  • 在线心跳和诊断日志是独立的机制，不受"使用统计"开关影响。桌面端只在已验证的云端登录期间向 Cindy 服务发送心跳（账号 ID、平台、版本）；本地模式不发送
  • 桌面原生崩溃转储只留在本地，不会自动上传。诊断日志可手动上传，另有默认关闭的自动崩溃日志上传选项
  • 从源码构建不要求保留统计：桌面开发构建默认不初始化 TapDB

默认连接官方云服务，这是有意为之：外部开发者不需要自己搭服务器，用自己的 Cindy 账号登录开发版，就可以直接对着官方服务器开发和测试。

适用范围与局限

  • 后端不开源：开源的是客户端，服务端在另一个仓库。很多能力（云端伙伴同步、设备互联的 relay、托管模型服务）依赖官方服务；"Skip Sign-In"模式下这些能力不可用
  • 默认连官方服务：端点清单在 config/endpoint.json 与 endpoint.global.json，桌面自动更新也来自官方 CDN
  • 有遥测：官方发行版默认开启使用统计，可关闭，但也有上面提到的手机端已知例外
  • 项目非常年轻且迭代极快：2026 年 7 月创建，两周内发了十多个版本，约 2000 个未关闭的 issue，beta 版和稳定版并行。适合愿意跟着走的人，不适合期待"稳定不变"的场景
  • 费用不等于免费：客户端免费，模型用量仍按供应商计费
  • 权限面很大：Agent 能操作文件、浏览器、应用，甚至整个远程桌面。设备互联需要保持在线、同账号登录并启用对应权限；远程访问不是整盘同步
  • Orca 的当前边界：单 Lead 绑定、Worker 聚焦切换不能并排、归档不可撤销等（见上文）
  • 文档以中文为主：AGENTS.md、docs/dev-rules/ 里的规则文档多为中文，README 和贡献指南有英文版

项目地址与资源

官方资源

相关资源

  • 官方插件: makecindy/cindy-official-plugins
  • 贡献指南: 仓库内 CONTRIBUTING.en.md
  • 仓库地图: 仓库内 docs/dev-rules/repo-map.md
  • Orca 架构: 仓库内 docs/dev-rules/orca-team-architecture.md
  • Linux 安装: 仓库内 docs/linux.md

总结与展望

核心要点回顾

  1. 整合而不是替换：Claude Code、Codex 和 Pi 并存，Cindy 做的是设备、角色与协作层
  2. 你的电脑就是服务器：多设备接力、模型共享、手机远程桌面，不需要租服务器或自建
  3. 多 Agent 协同有明确模型：Orca 的 Lead 加完整会话的 Worker，而不是一次性的子 Agent
  4. 工程治理很重：架构不变量、"必须先读"的规则索引、存量兼容红线、测试价值门槛，是一个 AI 参与开发的大仓库如何保持秩序的样本
  5. 隐私说明坦率：包括遥测、关闭方式和已知的手机端例外，但后端不开源、默认连官方服务这两点需要自己权衡

适用人群

  • 同时在多台电脑和手机上使用 Claude Code、Codex，希望任务能跨设备接力的开发者
  • 想把多个 Agent 组织成"队长加队员"，并做独立评审的人
  • 想研究"大型 AI 辅助项目如何写规则文档"的工程师，AGENTS.md 加 docs/dev-rules/ 的组织方式很有参考价值
  • 想做 Agent 插件或 Skill，并接入一个现成客户端的人

使用建议

先下载客户端，用"Skip Sign-In"跑一遍本地 Agent，感受一下界面和引擎切换；再决定是否登录体验多设备能力。如果在意隐私，第一件事是去 设置 → 关于 里关掉使用统计，并仔细读 README 的 Privacy & telemetry 一节。想读源码的话，从 docs/dev-rules/repo-map.md 的"按用户行为定位"表开始，比直接翻目录高效得多。

探索 PrimeSkills —— 精选 AI agent 和技能工具，每一个都经过真实工作流验证。没有炒作，只有真正好用的工具。

访问我的个人主页，获取更多见解和有趣的产品。

← 返回博客列表