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 版本。

DeepWiki：makecindy/cindy

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 创建服务为它生成独立业务 Session ID，Maker 选择对应的适配器，调用上游的 startSession，再把原生 handle 包装为 Cindy 的 Session。业务会话和 sdk_session_id 关联保存，Lead 与 Worker 各有自己的上下文和历史；回报作为消息进入 Lead，而不是把 Worker 整份历史直接合并过去。Codex 的 AppServerHost 可以复用多个原生 thread，因此独立 Session 不意味着每个 Worker 都单独启动一个进程。Worker 身份与 bootstrap · Maker 适配与持久化 · Codex Host

一条回报怎样从 Worker 到达 Lead

Worker 正常结束、Lead 仍在处理自己的当前轮次时，终态自动桥接按下面的顺序回报。OrcaTeamService 先写入 Worker 的 done，再尝试回报；Dispatcher 发现 Lead 正忙，把消息放入待处理队列。自动桥接把 Dispatcher 的 result.ok 当作 accepted，成功入队也会删除当前 autoBridge pending。因此三个事实可以同时成立：Worker 为 done，宿主已接受回报，Lead 队列里仍有待处理消息。先写状态再桥接 · 忙时入队 · accepted 的实际映射

回报进入待处理队列，说明消息已被宿主接受，尚未被忙碌的 Lead 消费。Lead 空闲时，Dispatcher 会尝试直接送到会话入口；这仍不提供内容已读或任务验收的结果。路由条件与发送

显式 send_to_lead 的时点不同：它在宿主接受直发或入队后，调用 settleWorkerReport 请求将 Worker 标为 done；入队时 MCP 返回 queued:true。这项数据库写入采用异步调用并单独记录失败，不能把工具返回视为数据库和运行期 Map 已同步完成的原子提交；后续终态路径还会处理运行期收口。显式回报 settlement · 异步状态写入 · 后续终态处理

投递失败进一步区分这两条路径：显式回报没有走成功 settlement，本次不会因此写 done；终态路径已经先写了 done，失败后仍保留进程内 autoBridge pending，并设置 retryAfterRejectedDelivery=true。符合条件的后续终态事件可以再次尝试桥接，这里没有固定间隔的重试计时器。done、投递接受和 Lead 验收属于不同的事实，不能互相代替。拒绝与异常分支 · 终态重试条件

上述分析基于固定源码，未运行真实 Cindy、上游 Harness 或模型；回报路径说明采用默认 queue，不展开锁冲突、steer 与版本竞态。

协同范围与执行边界

这适合有独立产物的分工，例如一个 Worker 修改实现，一个 Worker 检查回归，一个 Worker 核对文档。Lead 需要说明输入、产物和通过条件，再检查收到的结果；仅增加 Worker 数量不会自动消除共同误解或文件冲突。Lead 的检查要求包含 Prompt 约束，不能将它描述为每条任务都必经的程序化质量门禁。Lead 检查约束

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

Orca 还有几个实现边界：

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

创建成功也不意味着任务已经开始。创建代码先将 Worker 状态设为 idle；有首条任务时，消息被接受后才转为 running。没有首条任务时，宿主仍发送 ready placeholder，让原生会话确认就绪并建立可恢复历史，不能理解成完全没有 Harness 动作。Worker 创建 · 消息接受处理 · 无首条任务分支 · placeholder 实际发送

另一个直接影响试用的设置是 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、完整云后端自托管、严格离线运行或统一的操作系统级隔离，这个仓库不能直接满足全部条件。应先确认缺口和部署边界，再决定是否投入改造。它当前表现出较快的维护与发行节奏，长期采用还需要自己的版本固定和回归记录。

• Cindy 源码分析：一次用户输入如何进入 Harness：按 2026-10-27 的提交，从输入队列追到 Claude Code、Codex 和 Pi 的传输。
• Agent 栏目导航：相关工具、工作流与研究的入口。
• ZCode 项目分析：GLM 官方 Agent Harness 的架构与执行机制：对照自有 Runtime 的 Context、Goal 与 Workflow 设计。
• Pi Agent 框架架构：包边界、Agent Loop 与接入选择：理解 Cindy 所适配的 Pi 及其运行时边界。
• Cindy 文档索引：区分产品规则、当前实现、参考设计和后续规划。