Cindy（makecindy/cindy）：把 Claude Code、Codex、Pi 收进一个客户端，用 18 个 MCP 工具做多 Agent 协同

一、导读

Claude Code、Codex、Pi、Gemini CLI——过去一年开发者桌面上的「AI 编程入口」越来越多，但每一个都是孤岛：各开各的壳、各配各的 key、各记各的记忆，换引擎就等于换一套工作区。Cindy（makecindy/cindy）要做的是把引擎变成可替换零件，把「工作现场」固定在客户端层。它由心动网络（XD Inc.）CEO 黄一孟在 2026-07-26 的 TapTap 开发者沙龙（TDW 2026）上发布并宣布完整开源。

核心结论：它真正的技术含量不在「聚合三个 CLI」，而在把多 Agent 协作、跨 Harness 记忆与工具亲和层做成了客户端级基础设施——一组 18 个工具的进程内 MCP 服务 cindy_orca、一套 fail-closed 的会话路由、一个可关的「协同模式」插件开关。代价同样清晰：服务端未开源、1,893 个开放 issue、Electron 常驻内存偏高、多端能力不对等。

二、项目速览

项目	内容
仓库 / 主体	`makecindy/cindy`，主体为心动网络（XD Inc.）
主语言 / 许可	TypeScript / Apache-2.0（权重、商标等单独标识材料不在仓库级授权内）
Star / Fork	4,039 / 579（GitHub REST API，2026-10-24 抓取）
当日涨星	471（GitHub Trending daily，2026-10-24 抓取）
首次提交	2026-07-22；最近推送 2026-10-24
开放 issue	1,893（单版 release 可含约 40 个 PR）
Release 节奏	已发布 72 个 release（v1.0.0 至 v0.1.115），近 8 天连续每天一版
贡献者	API 首页即返回 100 位（Top 10 单人 208–2,188 次提交）
形态	Electron 桌面端（macOS/Windows/Linux）+ Expo/React Native 移动端（iOS/Android）
仓库印证的 Harness	Claude Code / Codex / Pi 三套（Pi 文档定位为「未来的基座 harness」）
未开源部分	服务端在独立仓库，不在本 monorepo 内

口径校准：README 正文仍写「首批 harness 是 Claude Code 与 Codex」，但仓库开发文档与 Orca 权威文档已把 Pi 并列，v0.1.115 release notes 亦含 Pi 修复。本文以代码与开发文档为准，采用「三套」。

三、为什么是它：把「交接税」变成产品

第一，它对准的是一笔没人开发票的隐性成本。 双持两个 CLI 的人都经历过：换工具等于换工作区状态、记忆清零、Skill 重配。Cindy 把任务放在更高一层——用户面对工作区，下层再选这次由哪套 harness、哪个模型跑，中途可切换，而工作区、消息记录、记忆、Skill、工具保持连续。

第二，它把「模型来源」与「客户端」解耦。 README 列了四条供给路径：官方 Cindy 服务（按量透明扣减）、一键授权你已有的 Claude Code / Codex Coding Plan（不重复付费）、自带 API Key、本地模型。对已付费用户，「不重复扣费」比任何 benchmark 都有说服力。

第三，Orca 多 Agent 编排是护城河而非噱头。 Lead 会话拆任务、派活、验收，Worker 会话并行执行——关键在于 Worker 是完整会话，不是一次性 subagent：各有模型、推理强度、工具调用流、上下文与可见历史，可休眠、归档、唤醒。这是「把模型多样化变成系统能力」。

第四，471 星的直接动因是迭代密度。 v0.1.115 单版约 40 个 PR：群聊轮流发言、私聊话题与引用、跨设备直连与锁屏服务、供应商组按额度换机、阿里云语音（通义千问与 CosyVoice）接入、新建任务边输入边预热等；v0.1.108–v0.1.115 为连续 8 天每天发版。同时仓库里 46 篇开发规则与 37 篇产品规则把工程与产品判断写成权威文档——高频发版加规则正本化，是这类快速生长的 Agent 客户端能维持质量的关键做法。

四、【重点】架构原理

4.1 整体分层：一层外壳、三类引擎、一套内建工具面

graph TD
    U["桌面端 / 移动端 / IM / 定时任务"] --> UI["apps/desktop (Electron)<br/>apps/mobile (Expo/RN)"]
    UI --> ORCH["packages/maker-core<br/>统一 Agent 抽象 · session 生命周期 · translator"]
    ORCH --> H1["Claude Code"]
    ORCH --> H2["Codex (app-server)"]
    ORCH --> H3["Pi (pi --mode rpc)"]
    H1 --> MCPS
    H2 --> MCPS
    H3 --> MCPS
    subgraph MCPS["packages/lizi-mcps：内建 in-process MCP 工具面"]
        T1["cindy_helper（essential，不可关）"]
        T2["cindy_orca（18 个协同工具，可关插件）"]
        T3["scheduler / memory / ssh / wechat / feishuBot / docs"]
        T4["browser / computer / android / lsp"]
    end
    ORCH --> DL["packages/device-link（跨机控制面）"]
    ORCH --> WF["packages/orca-workflow（Lead prompt · worker bridge）"]
    ORCH --> ACP["anthropic-compat-proxy / responses-*-bridge（方言互译）"]

三条架构不变量（docs/dev-rules/architecture-invariants.md）决定了这套外壳不会退化成脚本堆积：

package 必须与 render/main 解耦：packages/* 不得 import 渲染层组件，也不得反向 import main 进程，关联部分只能靠初始化或运行时回调注入。这是「同一套能力同时供桌面端、移动端、远端被控端」的前提。
main 进程禁止运行时动态 import()：依赖一律顶层静态 import，避免打包、加载时机与错误路径的不确定性。
主界面布局树是唯一的全局 split/pane 树：面板身份只认 panelKind，chat-main 在整棵树中必须恰好一个、始终可见、不可关闭、最小宽 400px；布局是用户级配置而非 session 数据，必须首帧同步就位，禁止「先画默认布局再跳成用户布局」。

4.2 harness 亲和层：三种引擎如何被抹平

Harness	接入方式	身份/上下文恢复	权限落地
Claude Code	会话级 MCP 挂载	持久 bearer token + URL `?session=<id>`	原生审批映射为 `InteractionRequest`
Codex	app-server 单例，多 thread 共用 MCP	`params._meta.threadId` 查 thread context	同上；跨会话串线一律 fail-closed
Pi	`pi --mode rpc`（JSONL/stdio）spawn	`--append-system-prompt` 追加宿主段、保留 Pi 默认 prompt	注入 `cindy-bridge.ts`，在 `pi.on('tool_call')` 拦截

Pi 这一路最能看出取舍。 Pi 原生没有工具审批（官方 security.md 明确「非沙箱、不限制工具」），Cindy 在 Pi 进程内注入扩展拦截每次 tool_call，经 extension_ui_request 冒泡到宿主映射成统一审批 UI；权限档写入 perm-<sessionId>.json，bridge 每次调用现读，因此支持热切换。文档同时写下不夸大边界的约束：Full access 档与原生 Pi 对齐，不得用凭证路径或 /proc/*/environ 文本硬拦原生允许的读、搜、bash；Ask/Auto 仍把这类调用升级为审批。诚实结论是「bash 写入 Extra Dirs 仍非 OS 强制……真正的强隔离需要 OS 级手段（macOS sandbox-exec、Linux 只读 bind mount/seccomp），本阶段未接入」。另一处细节：伙伴提示词轻易两三万字符，内联会顶穿 Windows 的 spawn 命令行预算，因此命令行只传文件路径——这是三平台同跑逼出来的设计。

4.3 核心机制一：Orca 协同控制面（18 个工具 + 不可伪装的派单契约）

packages/lizi-mcps/src/orca/server.ts 是一个进程内 MCP server（cindy_orca），把 18 个 team 工具直接注册到顶层（不走 list_tools/call_tool 入口）：start_team / create_worker / create_workers / send_to_worker / interrupt_worker / get_worker_queue_status / update_queued_message / cancel_queued_message / merge_queued_messages / steer_queued_message / move_queued_message / list_workers / switch_focus / idle_worker / end_team / archive_worker / update_worker / list_available_models。

源码注释给了「为什么直接注册」的直白理由：协同工具藏在 list_tools 后面时，模型在用户说「开协同/派 worker」时往往发现不了 start_team，反而误抓直接可见的 send_to_session（产出普通独立 session，不进 team 控制面）；提到顶层后路由才确定，代价是这些 schema 进入系统提示前缀（固定成本、缓存稳定）。独立成 server 的理由是可关：「协同模式」开关 gate 整个 cindy_orca，而 cindy_helper 作为自省与 handoff 基础设施不可关。

真正的约束力在三条运行时契约上，它们直接决定多 Agent 协作是否可信：①派单不得由原生 subagent 冒充——目标 role/label 不存在时 Lead 必须先如实说明并征求创建授权，「任务指派本身不等于创建授权」，多角色请求必须在一个并行 tool-call batch 内一次发出；②实际执行通道必须披露并按同一通道验收，Codex spawn_agent 或 Claude Code Agent/Task 的结果不能当成 Orca Worker 的完成，也不得写入 Worker 状态；③只有真实异步派发才静默结束 turn，send_to_worker 须返回 ok=true 且 wake_kind 属于 resumed/already-active/queued，否则必须立刻报告真实结果，不能等待一个不会到来的回报，不得 sleep、不得 poll。

4.4 核心机制二：fail-closed 会话路由与纵深防御

Codex app-server 是单例，多 thread 共用同一批 MCP server，工具是全局注册的，身份只能在调用时恢复。两条不变量：①**mcp-session-id 只标识 MCP transport、不证明 maker session 归属，故不作路由依据；bridge 只认已初始化 POST message 里的 params._meta.threadId，缺失、未知、batch 内不一致或不完整时宁可不注入 context（降级为 NO_SESSION_CONTEXT），也绝不猜一个错误 context 造成跨会话串线；②context 生命周期必须与 thread 绑定**（start/resume 注册、close 注销），注入发生在 tool-call 处理期间，不依赖 turn/item 时序与 TTL。

第三层是按 caller 自身 Lead 身份做归属校验：resolveWorkerRef 同时接受 worker_id 与 worker_session_id（opaque、精确匹配，命中 0 个报 NOT_FOUND、多匹配报错且无副作用），但只在 caller 自己的 worker 列表内解析；ctx 缺失直接 LEAD_NOT_SUPPORTED。文档称之为「与 fail-closed 路由正交的纵深防御」——路由保证 ctx 不串成别人，归属校验再挡住「ctx 正确、模型传错 id」的越权。 另有一个明确的「不做」：不为 per-role 工具隔离改写 Responses 的 tools 字段（ADR 记录），因为 Codex app-server 不支持单进程内 per-thread MCP 配置，拆多实例会引入启动耗时、常驻内存与 resume 匹配成本。

4.5 核心机制三：跨 Harness 记忆与工具亲和

「记忆跨 harness 共享」要求工具面也共享：内置 MCP 在注册处声明能力元数据；插件沿 manifest 渐进发现；自定义 MCP 由引擎自己持有连接——宿主查询目录时不会另起进程、不会读出 URL/headers/token，而是向发起查询的 session 所在引擎读取「本任务实际持有的工具」（Codex 用带本任务 threadId 的 mcpServerStatus/list，Claude Code 用 mcpServerStatus()）。未就绪时返回明确原因而非模糊失败：not-mounted、no-tools、failed、needs-auth、pending、disabled，引擎无此入口报 HARNESS_DISCOVERY_UNAVAILABLE；文档特意注明「不转发引擎失败原文，避免带出连接地址」。再加一条「Agent 与用户同权」：用户本人能做的操作 Agent 也要有工具并可在工具索引第一步发现，能否执行交给权限档与自动审核。

4.6 设计取舍：为什么这样拆，代价是什么

引擎用外部进程而非重写——产品原则写明「不以重新实现 Claude Code、Codex 或其他 Agent Loop 为目标，也不把底层模型与 Agent 已具备的能力包装成自己的智能」，Cindy 只负责连接；代价是跟随上游节奏，上游发版或改启动方式，Cindy 会继承这份滞后。Pi 被选作未来基座并划红线：同版本原生 Pi 能完成的安装、更新、扩展加载与自助修复，Cindy Pi 也必须能完成；用户发出完整确定性的命令或精确点击就是授权，不得再叠确认；宿主分析器不确定/超时/崩溃时必须退回 Pi 原生行为，不能 fail closed 到能力消失。三条不变量采用「增量适用」：约束新增与在改代码，不为统一形式专项重构存量。

五、【重点】应用场景

场景一：双持两个 CLI 的独立开发者——消灭交接税

痛点：复杂重构用 Claude Code（长上下文强），PR 流程走 Codex；每次换工具，工作区状态、记忆、Skill 全部重来。做法：把项目工作目录固定成一个任务，harness 与模型作为可切换执行单元；切换后工作区、消息记录、记忆、Skill、工具连续，消息记录能分辨某一步来自哪个引擎。收益：客户端免费；已订阅 Claude Code / Codex Coding Plan 的可一键授权复用，不在客户端侧重复扣费（README 明示）。真实收益是流程时间节省，本文不为此编造百分比。边界：需完全离线、完全不连官方云者不适合（默认连官方云、后端未开源）；只用单一 CLI 且从不切换者收益接近于零。

场景二：多角色协作开发——Lead 拆活、Worker 并行、交叉审查

痛点：一次重构含「方案设计 + 两个模块改造 + 质检」四条线，单模型串行易前后不一致，人工拆会话又丢上下文。做法：用 cindy_orca 的 Lead/Worker 状态机；Worker 是完整会话，各有模型、推理强度、上下文与可见历史；手机或另一台电脑都能当控制端操作同一支队伍。收益：可做到「最强模型出方案、最快模型干体力活、最谨慎模型做质检」；消息队列支持整条改写、撤回、原子合并，派活了能收回；并行时「部分 Worker 先报到，Lead 只处理当前报告，后续报告作为新消息自动唤醒 Lead」。注意：这不是加速倍数保证，并发与资源治理（soft/hard limit、预算闸）的完整控制面仍属规划阶段。 边界与不建议：①不要为了「像指挥中心」开到八个 Worker，任务边界不清时并行只会互相干扰；②Worktree 可选——开启时 Lead 与 Worker 共用同一 worktree，写入冲突靠 Lead 的任务切分避免，而非文件系统隔离；③Orca Team 严格绑定单个 Lead session，不支持跨 Lead 共享 worker；④Worker 归档后 UI 内无反归档入口。

场景三：个人长期助手——跨 Harness 记忆 + 定时任务 + IM 派活

痛点：偏好、项目规则、习惯做法散落在各 CLI 配置里，换工具就丢；周报、巡检等周期事务还要人工触发。做法：把「你调教出来的 Agent」放在客户端层：Memory（纠正一次跨 harness 生效）、Skills（教一次到处复用）、Automation（自排班、自执行、自汇报）、MCP（接内部工具），并可从 IM 与日程派活。伙伴默认走继承：toolsetMode 与 mcpMode 均为 inherit。收益：2026-10-02 产品裁决明确旧格式工具名单统一升级为「继承」（旧版无法可靠区分名单来自用户还是系统），升级后仍可重新选择——这解释了为何老用户升级后伙伴「会用的工具变多了」；权限档 ask/auto/完全访问保持原值。边界：跨项目记忆有「串味」风险——项目规则、个人偏好与临时任务混在一起可能带入无关背景（社区提出，官方未见明确隔离结论，待确认）；按触发来源整轮降权的能力当前未实现，文档明确「现有公共审批不能被描述为已经实现来源隔离」。

场景四：多端与远端——把同一支队伍带到手机和另一台电脑

痛点：长任务跑到一半要出门；公司电脑上的任务无法用手机跟进；多人共享开发机时状态互相干扰。做法：桌面与移动端经 device-link 打通，被控端的 Lead/Worker/team 真身都在被控端进程内编排，控制端只是镜像；手机上可发消息、处理确认、编辑队列、Fork/Rewind、看 Worker 列表，协同编排走与桌面相同的 channel（协同设置只读）。跨设备优先直连，不可用则回退中继；另提供本机 Agent API 连接码，供任意本机应用按 v1 协议接入。 收益（仓库自带基准，非第三方复现）：语音链路连接预热基准中，冷连接 WebSocket 升级请求中位数 1,606ms、预热后 359ms，候选收益约 1,247ms；仓库脚本复跑为 1,364ms 至 279ms、差值 1,085ms，两轮一致支持约 1.1–1.25 秒 网络层候选收益（Apple Silicon / macOS 27.0，2026-09-25；六次均返回 401，未做认证建连验证，按原口径转述）。边界：「焦点」在手机上不展示也不提供切换；maker:worker:update 已在被控端白名单与能力位中，但手机端 UI 暂未提供 Worker 改名入口；老版被控端缺 Orca channel 时控制端fail-closed 置灰入口并提示设备版本过旧。

场景五：TapTap Maker 游戏创作闭环（不适用其他团队）

痛点：云端 Maker 门槛低，但本地使用要装 CLI 并配 MCP，对无 AI 编程经验的创作者偏高。做法：Cindy 内置 TapTap 制造（TapTapMaker）原生插件，把接入收进客户端；官方路径为「Cindy（本地 Agent 终端）→ TapMaker（AI 游戏引擎插件）→ Tap 开发者中心（CLI 化、面向 Agent）→ 发布至 Tap 及其他渠道」。 收益（发布方 TDW 2026 公开数据）：2026 上半年 TapTap 新发行可玩游戏 5,002 款、其中 4,699 款由 Maker AI 制作、累计玩家超 1,100 万、日均玩家 16 万+、创作者超 3,000 人。边界：属发布方自述业务数据，非第三方审计；非游戏团队不适用这部分。TapTap 制造「未来希望完全开源」目前尚未开源（待确认）。

六、快速上手

# 环境：Node.js 22.x、pnpm 10.x（暂不支持 v11）、Git LFS
git clone https://github.com/makecindy/cindy.git
cd cindy
git lfs pull
pnpm install
pnpm restart:desktop:remote --region=global   # 中国大陆账号改 --region=cn

不想登录？登录页有 Skip Sign-In（应用内显示「未登录」）：本机 agent 照常可用，依赖服务端的能力不可用。Windows 亦可用 winget 安装；Linux 见 docs/linux.md。

最小验收清单：① 打开真实项目目录建任务，让 Claude Code 跑通一次修改；② 任务中途切到 Codex，确认工作区与记忆未丢；③ 开启协同模式，建 1 个 Worker 并让它回报 Lead 一次。三条都过，再谈接进日常。

七、横向对比

维度	Cindy	OpenCode	单独用 Claude Code / Codex	Cherry Studio 类客户端
定位	多 harness 统一工作区 + 多 Agent 协同	客户端/服务端分离的开放编码智能体	单一厂商 CLI	多模型桌面聊天客户端
引擎中途切换	✅ 上下文连续	单引擎	❌	不适用
多 Agent 协同	✅ Lead/Worker 完整会话级编排（18 个 MCP 工具）	有限	❌（仅原生 subagent）	❌
跨 harness 记忆/Skill	✅ 客户端层共享	自身记忆	各自独立	❌
移动端	✅ Expo/RN，可远程操作电脑	有限	❌	部分
复用已有订阅	✅ Claude Code / Codex Coding Plan	需自配	原生	需自配
许可	Apache-2.0（仅客户端）	开源	闭源	多为开源
主要代价	服务端未开源；1,893 开放 issue；Electron 常驻内存偏高	单引擎	换工具即换现场	只消费模型，不编排执行

读法：若核心痛点是「多引擎 + 多 Agent 协作 + 多端连续」，Cindy 是少数把这三点同时做进客户端层的开源方案；若只需要一个稳定好用的单一编码智能体，直接用上游 CLI 的收益风险比更好——它的增量价值几乎全部来自「切换」与「协同」这两个动作。

八、局限、风险与社区观察

第一，开源只开一半，这是被反复指出的最大保留意见。 README 明写「服务端位于独立仓库」。可以审计与修改客户端、可用 Skip Sign-In 完全本地运行 agent，但无法仅凭公开代码自建完整服务，自托管被描述为面向 Enterprise 层级。第三方评测（explainx.ai、technobrother、FollowAgents）称其为「开放的客户端」而非「完全开放的 Agent 平台」——这个表述准确，本文采用。

第二，默认连官方云与遥测需读者知情。 官方发行版内置 TapDB 使用分析（设备/OS/应用版本元数据，登录后关联账号 ID），README 明确声明不收集聊天内容、文件内容与工作目录数据；登录后有心跳（仅账号 ID、平台、版本）；崩溃转储留在本机。从源码构建可完全剥离：移掉渲染层入口的 initTapdb() 即可，移动端无凭据注入时为空操作。

第三，安全模型的边界必须说清。 Pi 文档主动写明：Full access 档「不得用凭证路径硬拦原生允许的读、搜、bash」，选择即接受父进程环境里的代理 token、网关 key、自带密钥、外部 MCP header 可能被读取；真正的强隔离（sandbox-exec、只读 bind mount/seccomp）本阶段未接入，需要硬边界应用 ask/auto 档。这类「把做不到的说出来」的写法是加分项。

第四，体量与成熟度的代价。 1,893 个开放 issue 与 72 个 release 同时存在，关注度与欠债都在快速累积；社区实测指出 Electron 桌面端常驻内存偏高、启动偏慢、部分版本需在 Cindy 内另行配置模型供应商（与本地 CLI 配置不共享）。多端能力不对等：移动端目前偏重远程会话查看与基础指令。

第五，合规与条款风险。 用第三方客户端驱动已订阅的 Claude Code / Codex（README 明确支持该路径），是否完全符合对应套餐条款，需读者自行核对当前条款（本文不作判断）；遥控另一台电脑、驱动浏览器与手机等能力，生产环境应有与风险匹配的授权与审计。

第六，维护活跃度。 近 8 天连续每日发版、Top 10 贡献者单人最高 2,188 次提交、主体为上市公司——Bus Factor 风险低于个人项目；但订阅关注者仅 18、issue 响应压力大，且发布方自述「早期在公司内部是一个无立项、无预算、无项目组的三无状态」，长期投入承诺待观察。

九、小结与行动建议

Cindy 的价值不在于把两个 CLI 装进同一个壳，而在于把「工作现场」从引擎里搬到客户端层，并为此写出了可执行的不变量：18 个协同工具的显式路由、fail-closed 的 thread 路由与归属校验、不得伪装的派单契约、以及「上游能力非退化」的红线。它把这一层的竞争，从「谁的界面好看」拉到了「谁的编排语义更可靠」。

先用 Skip Sign-In 试本地 agent，再决定是否登录官方服务——先把「引擎可切换 + 记忆连续」验证清楚，再评估是否接受默认云与遥测。
权限档从 ask/auto 起步，不要一上来就给 Full access——官方文档自己承认 Full access 等于接受凭证可能被读取，且 OS 级强隔离尚未接入。
协同模式按 2 到 3 个 Worker 起步并明确任务切分——worktree 共用时写入冲突靠 Lead 切活避免，而非文件系统隔离。
需要审计与合规的团队准备两条路：客户端自建（源码可用、遥测可剥离）＋自配模型网关与 API Key；完整自托管服务端目前不在开源范围内。
贡献前先读规则再读代码——DCO 签名强制、无 CLA；46 篇开发规则与 37 篇产品规则是这套多端 Agent 维持一致性的真实资产。

资料来源（抓取于 2026-10-24，除注明外）：GitHub Trending daily 与 REST API（makecindy/cindy，★4,039 / 579 fork / 1,893 open issues / Apache-2.0 / 72 releases / 创建 2026-07-22）；仓库 README 与 README.zh-CN；AGENTS.md、CONTRIBUTING.en.md；docs/dev-rules/（orca-team-architecture.md 75KB 权威文档、architecture-invariants.md、agent-capabilities.md、pi-harness.md、electron-security-and-process-boundaries.md 等）；docs/product-rules/（core-product-principles.md、region-and-editions.md、agent-user-parity.md 等）；packages/lizi-mcps/src/orca/server.ts、packages/lizi-mcps/src/index.ts、packages/maker-core/；docs/voice-connection-benchmark-2026-09-25.md、docs/local-agent-api.md；Releases v0.1.108–v0.1.115；TDW 2026 演讲与媒体转述（游民星空、GameLook、游戏日报、游戏葡萄、格隆汇研报摘要）；第三方评测与社区讨论（explainx.ai、opensourcedrop、toolsdepth、followagents、technobrother.ru、tangly1024 博客、linux.do / 大佬说）。发布方自述的业务数字均已标注来源；README 与代码不一致处（Harness 数量）以代码为准并已注明；未能核实项已标注「待确认」。