Cindy 项目调研：多 Harness 工作台、Orca 与本地执行边界

项目仓库：makecindy/cindy

AI 参与说明（Agent：Codex）：本文由 Codex 阅读官方站点、仓库文档与固定提交源码后协助调研、撰写和校验，并使用 humanizer-zh 编辑中文正文。整理日期为 2026-10-10，源码基线为 5feeb591。采用静态源码核对、文件读取命令与隔离的日志授权闸纯函数验证，未安装完整 Cindy、登录其服务或实测 Agent 任务成功率。运行记录：模型 gpt-6.1-sol，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai；运行记录中的 CLI 版本 0.162.0-alpha.17.2，不代表桌面 App 版本。

Cindy 用一个工作台连接不同的 Agent Harness、模型、工具和设备，让任务在真实文件和应用中执行。它的价值主要在于降低配置和操作成本，以及维护任务、审批、结果和多端状态。已有 Claude Code、Codex 或 Pi 工作流的人，可以重点评估这些连接能力能否解决日常使用中的问题。

本次调研有三点值得留意：Orca 的 Worker 是有独立上下文和历史的完整会话；手机主要控制电脑上的任务；开源范围是客户端，云端后端不在此仓库。“本地执行”描述工作发生的位置，数据传输仍取决于模型、设备连接和其他服务的配置。

先认识几个术语

项目定位与版本基线

Cindy is a client and orchestration layer around existing agent harnesses. Its cloud backend is outside this repository. 官方产品原则把主要职责概括为连接人、Agent、工具、文件、应用和设备，并明确不以重新实现 Claude Code、Codex 等 Agent Loop 为目标。产品原则，README

截至 2026-10-10 的检索快照，仓库未归档，约有 3,000 stars、457 forks；正式发行最新为 v0.1.101，发布于 10 月 9 日；预发行最新为 v0.1.103-beta，发布于 10 月 10 日。固定源码提交的提交者时间为 2026-10-10 17:30:05（Asia/Shanghai）。这些是活跃维护的迹象，不能用来证明兼容性或任务完成质量。仓库 API，固定提交

版本号需要分开看：apps/desktop/package.json 中的 0.0.0 是构建占位，不是正式发行版本；移动端 package 的版本也不能代替桌面发行号。下面的实现分析对应固定提交，下载和价格以官方页面当前展示为准。Desktop package

Context7 两次以产品名和仓库名检索均未找到对应索引，因此本文直接核对一手文档和源码，没有采用名称相近的其他库作为依据。

能做什么：把官方范围与实际证据分开

依据：Agent 导出，官方功能介绍，远程与 Mobile 规则，插件规则。

例如，官网展示用不同 Harness 与模型完成规划、并行实现和独立 Review。这说明产品支持的协同方向；它没有提供足以比较不同组合成功率的公开实验。评估时应拿同一项可检查的任务做比较，记录完成结果、人工修正、耗时与模型费用。

架构：界面、宿主、Harness 与设备连接

仓库是 pnpm monorepo。桌面端采用 Electron 与 React，移动端采用 Expo / React Native；共享 package 承担 Agent、模型和设备连接等能力。根配置要求 Node.js >=22.12、pnpm >=10.7 <11，并固定 pnpm 10.33.2；安装说明还要求 Git LFS。根 package，Mobile package，环境准备

依据：maker-core package，model-providers package，device-link package。

下面按职责画出本地 Desktop 与手机控制路径；SSH 会把 Agent 进程和工作目录移到远端，图中不展开这条路径。

flowchart TB
    Desktop["Desktop Renderer<br/>输入 / 审批 / Review"] --> Host["Desktop Main<br/>任务服务与权限"]
    Mobile["Mobile<br/>任务控制"] --> Link["device-link<br/>请求与状态传输"]
    Link --> Host
    Host --> Core["maker-core<br/>会话与 Agent 适配"]
    Core --> Claude["ClaudeCodeAgent"]
    Core --> Codex["CodexAgent"]
    Core --> Pi["PiAgent"]
    Claude --> Harness["上游 Harness<br/>Agent Loop"]
    Codex --> Harness
    Pi --> Harness
    Harness --> Tools["文件 / 进程 / MCP<br/>已授权的工具"]
    Harness --> Models["选定模型服务<br/>云端或本地"]
    Host --> Store["本地 SQLite<br/>任务与协同状态"]

通过这一分层，界面可以统一展示任务，无需自行实现每种 Harness 的全部循环。maker-core 将不同上游事件转换为宿主可处理的事件语义；权限、存储和系统操作留在对应信任边界。maker-core 规则，Electron 进程边界

三个适配器连接上游的方式并不相同：Claude 通过 @anthropic-ai/claude-agent-sdk 调用 Claude Code 二进制；Codex 通过自有 AppServerHost 驱动外部 codex app-server；Pi 使用 --mode rpc 进程。Cindy 吸收了这些传输差异，实际执行仍依赖相应上游。Claude adapter，Codex adapter，Pi adapter

官网的“切换 Harness，保持任务连续”也需要按这层关系理解。统一的任务、Memory、Skills 和工具环境可以继续使用；不同上游的原生会话格式、压缩与恢复方式仍有差异。这里不能推导出任意组合都拥有相同的上下文窗口或原生能力。

Orca：完整 Worker、消息协同与验收

An Orca Worker is a full session with its own harness, model, context and history. 官方架构文档将它与上游一次性 Subagent 区分：Lead 负责派活和验收，Worker 保留可查看、可追问的任务过程。Orca 架构

这适合有独立产物的分工，例如一个 Worker 修改实现，一个 Worker 检查回归，一个 Worker 核对文档。Lead 需要说明输入、产物和通过条件，再检查收到的结果；仅增加 Worker 数量不会自动消除共同误解或文件冲突。

固定版本的协同设置默认 soft limit 为 5、hard limit 为 8，空闲自动释放默认关闭。宿主对创建数量设限，不代表它已经实施每个 Worker 的 token 或费用预算；这些预算仍出现在后续规划中。第一次试用可以先只创建两个 Worker，观察结果和费用。协同设置源码

Orca 的几个边界值得在试用前确认：

• Team 绑定一个 Lead；数据库分别保存 Team、Worker 元数据和会话关系。
• 创建、派活、队列调整、回报和完成标记通过宿主服务与 MCP 工具完成，工具可见性本身不构成权限。
• 同一 Team 可以有多个 Worker，但 focused Worker 界面是切换一个 Worker 面板，不代表所有 Worker 同时并排展示。
• 手机和另一台电脑通过 device-link 操作执行端的 Team；任务与协同状态以执行端为准。
• 文档中的 workflow_run、统一 Side Chat pane 和部分执行单元规划属于后续设计，不能把整份架构文档都读成已实现功能。

创建成功也不意味着任务已经开始。创建代码先将 Worker 状态设为 idle，消息被接受后才转为 running。Worker 通过 send_to_lead 成功交付回报时可以被标为 done，用来避免终态自动回报重复；这个状态不是测试通过或 Lead 已验收的证明。Lead 的检查要求还包括 Prompt 约束，不能将它描述为每条任务都必经的程序化质量门禁。Worker 创建，消息接受处理，回报完成语义

另一个直接影响试用的设置是 Worker 权限：未保存创建偏好时，源码默认 bypassPermissions（Full access）；Worker 不继承 Lead 当前权限。UI 可以选择 auto，保存后用于后续创建。通过 MCP 显式把偏好从 auto 升为 bypassPermissions，宿主应先取得用户确认。试用前应查看这个独立设置，不能因为 Lead 使用审批模式，就认为 Worker 也使用同一模式。默认权限源码，Worker 权限契约

Orca does not create a separate Git worktree for every Worker by default. 创建代码默认使用 Lead 的工作目录；架构文档说明开启 Worktree 时 Lead 与 Worker 共用该 worktree。因此，即使任务与原仓库检出隔离，多个 Worker 之间仍可能修改同一份文件。显式 working_dir 指定的是已有目录，不会自动创建独立 worktree。应先划分文件修改范围，必要时另行准备独立目录；Git worktree 本身也不隔离云账号或外部系统。目录选择源码，Worktree 说明

Team、Worker 和会话关系有 SQLite 记录，重启后可据此恢复身份并唤醒会话；自动回报的部分在途状态却保存在进程内 Map。因此，不能仅凭会话持久化，就认定所有操作都能在崩溃后精确重放。若任务会写外部系统，仍需核对实际回执与重复执行情况。恢复入口，OrcaTeamService

本地执行、云端能力和数据传输

理解 Cindy 的数据流，需要分别看执行位置、模型请求、设备连接和诊断数据。

依据：README 的登录与默认服务器说明，Global endpoint manifest，device-link allowlist。

遥测与诊断也有不同开关：

• TapDB 使用统计：README 称其统计设备、系统、App 版本等元数据，不采聊天、文件或工作目录内容；这是一项官方说明。关闭统计不能代替检查其他网络路径。
• 登录心跳：云账号登录状态下，客户端向 Cindy 服务报告账号、平台和版本等在线信息。
• Crash dump：源码设置 uploadToServer: false，原生 minidump 留在本地。
• 诊断日志：另有手动上传和崩溃自动上传机制。自动上传默认关闭，需用户开启，并通过目标配置和隐私同意检查；手动上传独立于使用统计开关。

依据：README，Crash reporter，日志默认设置，上传授权闸。

因此，README 的“Crash dump 不自动上传”不能改写为“没有自动诊断日志上传功能”。日志实现有来源白名单、字段重建和脱敏规则，但本次没有对全部数据出口做安全审计。诊断日志规则

本次还将原始 consentGate.ts 转译后隔离执行，没有调用上传函数：目标已配置且已同意隐私政策时，手动路径返回 allowed，并且不读取崩溃开关；自动路径在开关关闭时返回 denied / crash-auto-off，开启后返回 allowed；隐私同意读取失败时返回 unknown。这验证了授权闸的分支行为，不验证采集内容或实际传输。

插件与许可证：两个容易扩大理解的边界

插件的沙箱界面与高权限执行路径需要分开看。规则要求插件页面不能直接获得 Node、宿主文件系统和通用网络权限，由宿主检查身份与能力声明；但插件中的 Skill 会交给主 Agent 执行，可信 Node Worker 也有单独的权限与凭证注入边界。审查一个插件时，应同时看 manifest、Skill 正文、脚本和运行期调用，不能只根据界面处于沙箱就认可整个包。插件规则，凭证与 Node Worker 边界

客户端源码默认使用 Apache-2.0，版权通知列出 XD Inc.。这是研究、修改和复用客户端的基础；模型、商标、单独标识的材料以及第三方组件仍可能采用其他条款。仓库的受限组件表单列了 Claude Code CLI、Claude Agent SDK 等依赖，不能把根许可证扩展为所有分发材料的许可证。LICENSE，NOTICE，受限组件表

如何开始使用与核验

普通使用优先从官方下载页选择平台与区域。GitHub 正式发行提供 macOS DMG、Windows EXE 和 Linux DEB；移动端路线以下载页当时给出的渠道为准。Linux 还需按安装文档区分 Ubuntu、Arch / Omarchy 与其他 glibc 桌面，不能把打包支持等同于所有发行版都已验收。

客户端免费，官方 managed model service 是可选计费服务；自带 API 和已有订阅的费用继续按相应服务计算。官方价格与规则

源码开发入口

准备 Node.js 22.x、匹配的 pnpm 10.x 和 Git LFS。以下命令来自仓库安装与 Desktop 开发入口，额外固定了本文的源码提交；本次未执行完整依赖安装和 Desktop 启动。

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

# Choose the region that matches your Cindy account.
pnpm restart:desktop:remote --region=global
# Mainland China accounts use --region=cn instead.

pnpm install 的 postinstall 会尝试下载 Claude、Codex、ripgrep、Pi 等运行时二进制，启动前还会检查缺项。它不只是安装 JavaScript 包。开发启动默认使用命名隔离 profile，但部分上游登录态仍有复用规则；隔离 Cindy 数据目录不能理解为与本机上游配置完全分离。环境准备，Desktop 开发规则

无需模型调用的源码核验

在仓库根目录执行以下 Node.js 命令，不需要安装依赖或提供模型凭据。它读取环境约束和 Agent 导出，帮助区分 README 描述与这个提交的源码入口。

node - <<'NODE'
const fs = require('node:fs');
const pkg = JSON.parse(fs.readFileSync('package.json', 'utf8'));
const source = fs.readFileSync('packages/maker-core/src/agents/index.ts', 'utf8');
console.log(`Node: ${pkg.engines.node}`);
console.log(`pnpm: ${pkg.engines.pnpm}`);
for (const name of ['ClaudeCodeAgent', 'CodexAgent', 'PiAgent']) {
  console.log(`${name}: ${source.includes(name) ? 'exported' : 'not found'}`);
}
NODE

本次在固定提交的对应文件上实际运行，输出为：

Node: >=22.12
pnpm: >=10.7 <11
ClaudeCodeAgent: exported
CodexAgent: exported
PiAgent: exported

这验证了声明与源码入口，不证明任意模型组合或平台上的端到端任务已经通过测试。

第一次试用，检查具体产物

本文建议用一个没有敏感内容的 Git 示例仓库试用，先做单任务，再开 Orca；每一步都保留能够人工核对的产物。

1. 选择一个已经可用的 Harness 和模型来源，完成一个小修改；检查实际目录、diff、执行命令与费用。
2. 查看任务权限与 Worker 创建权限，确认实际选择符合本次任务；检查新任务是否确实进入预期的 Git worktree。
3. 开启 Orca，用两个 Worker 分别完成实现和独立检查；给它们不同、清楚的交付条件，最终由 Lead 汇总人工可核对的证据。
4. 从手机发送一次后续指令和一次审批；断开后重连，确认消息没有重复执行、任务状态与电脑一致。
5. 检查统计、诊断上传、账号及模型连接设置，明确各条数据路径；需要离线时，单独验证 Skip Sign-In 与所选本地模型组合。
6. 记录失败和人工修正，判断节省的是哪些操作；涉及外部系统写入、定时任务或新插件时，再分别验收对应权限与回执。

这些是采用前的验证建议，不是本次已经完成的 Cindy 实测结果。

采用判断与进一步阅读

如果需要复用已有模型订阅，并希望集中处理 GUI Review、多个 Harness、多 Agent 分工和手机跟进，Cindy 值得做一次小范围试用。阅读源码时，可重点看异构 Agent 适配、Orca 会话与消息生命周期，以及跨设备请求如何进入宿主权限边界。

如果主要需求是稳定的服务端 Agent SDK、完整云后端自托管、严格离线运行或统一的操作系统级隔离，这个仓库不能直接满足全部条件。应先确认缺口和部署边界，再决定是否投入改造。它当前表现出较快的维护与发行节奏，长期采用还需要自己的版本固定和回归记录。

• Agent 栏目导航：相关工具、工作流与研究的入口。
• ZCode 项目分析：GLM 官方 Agent Harness 的架构与执行机制：对照自有 Runtime 的 Context、Goal 与 Workflow 设计。
• Pi Agent 框架架构：包边界、Agent Loop 与接入选择：理解 Cindy 所适配的 Pi 及其运行时边界。
• Cindy 文档索引：区分产品规则、当前实现、参考设计和后续规划。