一个 Agent 多个身体：Cindy 的 Harness x Model 矩阵

来源: makecindy/cindy — https://github.com/makecindy/cindy
语言: TypeScript | 今日 Stars: 471 | 协议: Apache 2.0
一句话: 不绑定单一模型或框架的 AI agent——一个任务可以跨 Claude Code × GPT-4 规划、Codex × Sonnet 执行、Gemini × Pro 复审

一个反直觉的设计

大多数 AI agent 都有一个"身体"——一个模型，一个 harness（框架），一个工具集。Claude Code 用 Claude 模型，Codex CLI 用 GPT 系列，Gemini CLI 用 Gemini。你选了 agent 就选了模型，选了模型就选了生态。

Cindy 的第一个反直觉设计是：这些维度是正交的。

一个任务在 Cindy 里可以这样做：Claude Code harness 配 Sonnet 模型做规划，Codex harness 配 GPT-4o 做执行，Gemini harness 配 Pro 模型做复审。workspace、memory、skills、tools 在切换中保持连续。你不是在用三个 agent，你是在用一个 agent 的三次变身。

这听起来像"多 agent 协作"，但有一个关键区别：多 agent 协作是 N 个独立实例互相通信，Cindy 是 1 个连续身份在不同身体间迁移。前者是"开会"，后者是"换班"。

为什么这很重要

当前 agent 工程的一个隐性瓶颈是"模型锁定"。你用 Claude Code 是因为 Claude 模型在某个任务上强，但 Claude 模型在另一个任务上可能不如 GPT-4o。你被迫在"整体能力"和"单项能力"之间做取舍。

Cindy 的解法是把这个取舍变成时间维度上的切换：

• 规划阶段用擅长结构化推理的模型（Claude Sonnet）
• 执行阶段用擅长代码生成的模型（GPT-4o 或 Codex）
• 复审阶段用擅长发现盲点的模型（Gemini Pro）

这不是新概念——人类团队一直这样做。但 agent 世界之前做不到，因为 harness 和 model 是绑定的。Claude Code 只能跑 Claude 模型，Codex CLI 只能跑 OpenAI 模型。Cindy 做的是把 harness 和 model 解耦，让它们自由组合。

Memory 跨 harness 持续

Cindy 的第二个设计是"纠正一次，所有 harness 都记住"。

传统 agent 的 memory 是 harness-bound 的——你在 Claude Code 里纠正过的偏好，换到 Codex 里要重新说一遍。因为 memory 存在 harness 的 context 里，不是 agent 的 context 里。

Cindy 把 memory 提到了 harness 之上的一层。你告诉 Cindy "我喜欢用 pnpm 不喜欢用 npm"，这个偏好会跨所有 harness 生效。下次不管 Cindy 换到哪个身体，她都知道用 pnpm。

这看起来是个小功能，但它改变了一个根本性的东西：agent 的身份不再依附于某个模型。之前"我的 agent"实际上是"我的 Claude Code 配置"或"我的 Codex 配置"。Cindy 让"我的 agent"变成一个跨模型的连续实体。

Skills 一次定义，到处复用

第三个设计是 skills 的跨 harness 可移植。

你教 Cindy 一个工作流——比如"每次提交前跑 lint + type check + test"——这个 skill 会在所有 harness 里生效。不需要在 Claude Code 里配一遍 hooks，在 Codex 里再配一遍。

这和之前讨论过的 skills CLI 概念一脉相承：技能是资产，agent 是消费端。但 Cindy 把这个概念推得更远——不只是技能可移植，连 memory、workspace context、甚至任务状态都可移植。

开箱即用的代价

Cindy 的卖点是"开箱即用"——下载客户端，登录，就能用。不需要配置 API key，不需要选模型，不需要装插件。

但开箱即用是有代价的。Cindy 的客户端连接的是官方云服务（cindy.app），你的任务数据经过他们的后端。虽然代码开源（Apache 2.0），但后端服务不开源。

这和 Open WebUI 的哲学不同——Open WebUI 是完全自托管，你的数据不出你的机器。Cindy 选择了一个中间路线：客户端开源，后端托管。

"Skip Sign-In" 模式可以不登录就用本地 agent，但 server-backed 能力不可用。这是一个明确的权衡：易用性 vs 自主性。

桌面 + 移动 + IM

Cindy 的另一个野心是多端。不只是桌面客户端，还有移动端（Expo/React Native），还能从 IM 和日程驱动任务。

"从 IM 驱动"意味着你可以在微信/Slack 里给 Cindy 发一个任务，她在桌面端执行，完成后把结果发回 IM。这把 agent 从"你需要打开它"变成"它随时在线"。

但这也是最需要警惕的地方。一个能操作你电脑、能访问你 IM、能读你日程的 agent，如果出错，影响面比一个纯代码 agent 大得多。Cindy 的安全模型目前看是"用户授权 + 本地执行"，没有看到额外的沙箱层。相比之下 NVIDIA OpenShell 把 agent 关在沙箱里，Cindy 让 agent 直接用你的登录态。

真正的竞争维度

Cindy 不是在和其他 agent 竞争——Claude Code、Codex CLI、Gemini CLI 各有各的模型优势。Cindy 在竞争的是一个更上层的东西：agent 的操作系统层。

操作系统干的事是抽象硬件差异——你不需要知道具体是哪块显卡，操作系统给你一个统一接口。Cindy 干的事是抽象 harness 和 model 差异——你不需要知道当前用哪个 harness，Cindy 给你一个连续的 agent 身份。

这个定位和 Open WebUI 的"AI OS"概念有交集，但路径不同。Open WebUI 是从聊天界面往上长，Cindy 是从 harness 往下长。谁先到达"agent OS"的位置，取决于市场更买"一个界面管所有模型"还是"一个身份跨所有模型"。

一个值得关注的细节

Cindy 的仓库是 pnpm monorepo，包含 apps/desktop（Electron）、apps/mobile（Expo）、packages/*（共享能力）。值得注意的是 apps/*-bin 目录——claude-code、codex、ripgrep 的二进制文件不提交到仓库，而是在 pnpm install 时按平台下载。

这意味着 Cindy 把 Claude Code 和 Codex 当作"依赖"而不是"集成"。它们是 Cindy 这个 agent 的可选身体，按需下载。这和"agent 是 Claude Code 的插件"完全不同——这里 Claude Code 是 Cindy 的一个组件。

收尾

Cindy 的核心赌注是：agent 的身份不在模型里，而在模型之上。如果这个赌注对了，未来的 agent 市场不是"谁的模型最强谁赢"，而是"谁的抽象层最好谁赢"。模型变成可替换的组件，agent 的连续性才是用户粘性来源。

这个赌注有风险。模型厂商可能通过 API 限制阻止跨 harness 使用（Claude Code 的订阅能不能在 Cindy 里用？答案是可以——Cindy 支持"Claude Code / Codex Coding Plan"授权，不重复计费）。如果模型厂商收紧限制，Cindy 的核心卖点就消失了。

但至少在今天，Cindy 提供了一个其他 agent 都没有的东西：一个连续的"你"，在不同身体间流动。