同时装了几个编码 Agent 的人多半有过这个体验：这个月用某个工具顺手，下个月想让另一个工具试同一件事，于是工作区、记忆、纠正过的习惯全部留在上一个工具里，等于换个现场重来。Cindy 押的是另一条路——它不造新的编码 Agent，而是骑在它们头上，把 Claude Code、Codex、Pi 当成可互换的引擎：一个任务可以用 A 组合做计划、B 组合并行执行、再让 C 组合来审，中途换引擎时工作区、记忆、技能与工具保持连续。客户端是 Apache-2.0 开源的，桌面端基于 Electron，移动端基于 Expo 与 React Native，整体是 pnpm monorepo；后端服务是单独且闭源的。本教程六步落地：装起来、接上引擎、建任务与工作区、中途换引擎、开协同模式跑多 Agent，最后走审批收口并把边界说清。
「开源」的边界要先讲清楚：开源的是客户端（Apache-2.0），后端服务是闭源的。跨设备同步、记忆与技能的云端同步等能力依赖它自己的服务；项目文件留在本机，远程访问不等于整盘同步。对数据出境或供应链有要求的团队，先把这一条走一遍合规再决定要不要引入。
Step 1：装：源码构建或系统包
源码路线是四步：克隆、拉 LFS 资源、装依赖、启动。启动命令带区域参数，中国大陆账号改用 cn。Windows 也可以用 winget 安装，Linux 的安装说明在仓库的 docs/linux.md 里。跑起来之后会进入引导，让你连一个模型提供方。
# 源码路线
git clone https://github.com/makecindy/cindy.git
cd cindy
git lfs pull
pnpm install
pnpm restart:desktop:remote --region=global
# 中国大陆账号改：--region=cn
# Windows 也可以 winget 安装；Linux 见仓库里的 docs/linux.md如果你已经在用 Claude Code 或 Codex，授权已有订阅即可；也可以填自己的 API key 或指向本地模型。想先看看再决定，登录页的 Skip Sign-In 可以直接跳过——本机 Agent 照常干活，只是依赖服务端的能力（跨设备同步等）用不了。它服务的平台覆盖 macOS、Windows、Linux 与 iOS、Android。
Step 2：接引擎：让三个 harness 在一个界面里可见
它同时支持 Claude Code、Codex 与 Pi 三个 harness。每个任务选一组「harness + 模型」的组合，工作推进过程中也能换。这里有个容易被误读的点：官方的说法是切换 harness 时会交接或重建引擎上下文，而不是让两边内部状态完全一致——换句话说，Cindy 这一层的工作区、记忆、技能与工具是连续的，但引擎内部那一份上下文不保证完全相同。你在某一个 harness 里纠正过一次的事，任务换到另一个上照样记得，靠的是记忆与技能在客户端层共享。
一台机器上的三种 harness
Claude Code / Codex / Pi
每个任务选一组：harness + 模型
中途可换：工作区、记忆、技能、工具保持连续
注意：切换是「交接或重建引擎上下文」
不是两边内部状态完全一致复用的不只是引擎，还有你已经付过的订阅：把已有的 Claude Code 或 Codex 订阅授权给它，就能直接用，不必为「换个界面」再买一份。
别把「引擎可换」理解成「结果等价」：同一个任务换到不同 harness 上，产出与风格可能差很远。真要对比，就在两个工作区里各跑一遍，用同一份验收标准打分，而不是在同一个会话里来回切——后者只会得到两份互相污染的半成品。
Step 3：建任务与工作区：改动先进隔离区
建任务时指向一个真实项目目录，改动会先落进隔离的工作区，而不是直接写你的检出。这层隔离是后面一切的基础：没审过的改动不会自己生效。一个务实的用法是——一个工单一个任务，任务里按阶段拆会话；完成或闲置的任务收起来，保持侧栏干净。
最小验收清单（三条都过，再谈接进日常）
1) 打开真实项目目录建任务，让 Claude Code 跑通一次修改
2) 任务中途切到 Codex，确认工作区与记忆未丢
3) 开启协同模式，建 1 个 Worker 并让它向 Lead 回报一次这三条分别验的是「能干活」「能换引擎」「能协同」。任何一条不过，就说明你的环境或理解还有缺口，先补齐再往下走。
Step 4：中途换引擎：换的是发动机，不是现场
真正的用法不是挑一个最好的用到底，而是按阶段配：规划用你信得过的那个，实现阶段换性价比高的那个跑量，最后再换一个来审。跨 harness 互审顺手实现了一个便宜版的「评估者独立」——换个模型、换个 harness 来查同一份改动，比让作者自查更能查出问题。因为记忆与技能在所有 harness 之间共享，你在某一个里纠正过的偏好，换过去依然生效。
按阶段配引擎的一种分法
计划 → 你信得过的强模型组合
实现 → 性价比高、跑量快的组合
评审 → 换一个不同厂商的组合做独立复核
共享层：工作区 / 记忆 / 技能 / 工具它还能直接操作本地文件、终端与已登录的浏览器态——也就是用你已经登录的内部系统账号去整理文档、同步数据，而不必交出账号密码。这一条在团队内部系统自动化上很实用，同时也要按权限边界谨慎使用。
换引擎的代价是上下文要重建：长会话切一次就有一次冷启动成本，频繁来回切不如一次切到位。把阶段划分清楚，每个阶段内只用一个组合。
Step 5：开协同模式：Lead 拆活、Worker 并行、Reviewer 审
一个 Agent 不够用时，可以开协同模式：一个 Lead 负责把目标拆开并定验收标准，若干 Worker 并行执行，再让另一个组合来做独立评审。这不是让你去配一套集群编排，而是给一个团队分工——共享的是同一个目标和明确的验收标准。协同相关的能力通过一组 MCP 工具暴露出来（社区整理的清单里是 18 个，覆盖建 Worker、派活、收回报、查状态等），具体工具名与数量随版本变化，以仓库里的文档为准。
协同模式的角色
Lead 拆目标、定验收标准、收回报
Worker 并行执行各自的子任务
Reviewer 换一个组合独立审改动
共享：同一个目标 + 明确的验收标准配合 SkillHub 装技能、接 MCP 服务，可以把例行流程固化成可复用的自动化；再绑上飞书或 Slack 之类的渠道，就能用 IM 派活。
并行 Worker 改同一批文件会互相覆盖：拆活时按目录或按文件划清楚归属，让每个 Worker 只在自己的范围内写，重叠部分交给 Lead 统一收口。另外 MCP 工具清单随版本变动，别把自动化脚本写死在某个具体工具名上。
Step 6：审批与收口：逐条过、可回退、可远程
改完不是直接生效：每一处改动会进审查面板，你逐条看过、确认之后才真正写下去，不满意可以回退重来。审批不一定要坐在电脑前——装了移动端之后可以远程看进度、批改动，甚至当电脑遥控器用。结果形态也不只是文本和代码，还能出图表、交互控件与富页面，这对给非技术同事看结果很有帮助。
收口与扩展
- 审查面板：逐条检查改动，确认后落地，可回退
- 移动端：远程看进度、审批、远程操作电脑
- SkillHub：装技能
- MCP：接外部工具
- 渠道：飞书 / Slack 等，用 IM 派活
- 自动化：把例行流程固化成定时任务官方给出的典型场景有四类：跨设备续接开发、用已登录的浏览器态做自动化、团队日报自动化、多 Agent 协作开发。挑其中一件先跑顺，比一次全上更稳。
三个现实边界：一是服务端闭源，跨设备能力依赖它自己的服务；二是仓库的开放问题数在两千上下（不同来源的口径在一千九到两千一之间），说明边角还很多，别把它放在交付关键路径上；三是桌面端是 Electron 应用，常驻内存偏高，低配机器上要留意。
常见问题速查
| 现象 | 原因与处理 |
|---|---|
| 必须登录吗 | 不用，登录页有 Skip Sign-In；本机 Agent 可用，服务端能力失效 |
| Node 与 pnpm 版本 | Node 22.x，pnpm 10.x，明确不支持 v11 |
| 忘了 git lfs pull | LFS 资源缺失，界面资源可能显示异常，补拉一次 |
| 国内账号同步异常 | 启动加 --region=cn |
| 换引擎会丢上下文吗 | 工作区、记忆、技能、工具连续；引擎内部上下文是交接或重建 |
| 协同模式有多少 MCP 工具 | 社区整理为 18 个，随版本变动，以仓库文档为准 |
| Worker 互相覆盖 | 按目录或文件划分归属，重叠部分交给 Lead 收口 |
| 改动会直接生效吗 | 不会，先进隔离区，审查面板确认后才落地 |
| 手机上能做什么 | 看进度、审批、远程操作电脑 |
| 能接哪些 IM | 飞书、Slack 等渠道，用 IM 派活 |
| 收费吗 | 客户端免费开源；可用已有订阅、自备 key、本地模型，或它的付费服务 |
| 完全开源吗 | 客户端 Apache-2.0，后端服务闭源 |
| 支持哪些平台 | macOS、Windows、Linux 与 iOS、Android |
| 适合当主力工具吗 | 开放问题数偏多，建议先在非关键任务上跑顺 |