一个「Agent」底层装两个引擎，还能中途换——开源项目 Cindy 到底在重构什么？

昨天大家还在聊 AI 视频怎么从「碰运气」变成「有纪律」，今天 GitHub Trending 上就多了一个方向完全不同的项目：makecindy/cindy，⭐1920，一句话自我定位是「Consider it done. 想到，就能做到。开源、开箱即用的 AI Agent」。

名字很温柔，工程很硬核。它有个被很多人忽略、但相当反直觉的技术决策：一个 Agent 的「底层引擎」是可插拔、可混排、甚至任务中途能换的。

这篇文章只拆一件事：Cindy 是怎么把「Harness × Model」这种组合，做成一套能切换、能并行、还能独立审核的工程架构。

---

先搞清楚一个误会：Agent 不是模型，是「车」

很多刚接触的人有个惯性：Agent = 一个很强的大模型。这其实是把两个东西混为一谈了。

Cindy 的文档里反复出现两个词：Harness 和 Model。

• Model 是「发动机」：Claude、GPT、本地模型……
• Harness 是「整车」：它负责怎么把任务喂给模型、怎么调用工具、怎么收集结果、怎么回滚。Claude Code 是一套整车，Codex 是一套整车。

以往你用的绝大多数产品，是「一辆车焊死一个发动机」：买了 Claude Code，就用 Claude 的模型；买了 Codex，底层就是 OpenAI 那套。换不了，也拆不开。

Cindy 的野心，就是把「车」和「发动机」之间的焊点全部松开，做成接口。首批兼容的就是 Claude Code 和 Codex 两套 Harness，更多在路上，自研 Harness 也在酝酿。

最狠的一点：任务做一半，可以换模型

把「车」和「发动机」拆开，普通人第一反应是——省了重复付费，能用一套车跑多个模型。这确实省，但只是浅层。

真正值钱的能力是文档里轻描淡写那一句：models and harnesses mix freely and can switch mid-task.

翻译成人话：同一个任务里，模型和 Harness 可以自由组合、中途切换，而工作现场、记忆、Skill、工具全程连续不断档。

为什么要中途切？真实场景很常见：

• 前面用擅长代码的模型写实现，后面换一个更擅长推理/审阅的模型来 review。
• 某个模型在这个子任务上被拒、超时、或者质量明显不行，当场换一个顶上，不用推倒重来。
• 便宜的模型干粗活，贵的模型干关键决策——按段计价，不浪费。

关键在最后那半句：切换时上下文不丢。同一份 workspace、同一份 memory、同一批 skill、同一撮 tool handles，跟着任务走，而不是跟着模型走。这在工程上极难——意味着所有状态必须与「引擎」解耦，单独持久化，而不是寄生在某个模型的会话里。

更进一步：一个任务，能让多个 Agent 分头干

拆了 Harness 和 Model，Cindy 又往前迈了一步：多 Agent 协同，官方代号叫 Orca。

说人话就是——一个任务可以由「不同 Harness × 模型组合的多个 agent」来规划、并行执行、独立 review。

它的协作模型是清晰的 Lead / Worker 结构（见 orca-team-architecture.md）：

• 一个 Lead session 负责拆任务、派活、验收、汇总。
• 多个 Worker session 负责并行或串行执行。Worker 是完整会话，不是一次性 subagent——它有自己的模型、effort、工具调用流、上下文和可见历史，可以随时查、随时续。

而且这几个人干活时可以「不是一辆车」。同一团队里，Lead 可能是 Claude Code 引擎、某个 Worker 是 Codex 引擎、另一个 Worker 用的又是别的模型。规划、执行、审核三层，分别交给不同的组合去跑。

这里面最打动我的一个工程细节：Worker 之间的工具调用不是黑箱。它通过 MCP 桥接实现跨 agent 的工具互通——本机的 codexHttpBridge 会维护身份路由，云端/SSH 远端的代码 agent 也能经 remote-forward 连回本机做审批。连 threadId 这种会话粒度都做了远程路由（CodexMcpThreadContextStore），不是简单把两个 CLI 扔在一个目录里各干各的。

「开箱即用」不是一句空话，是三层硬承诺

很多开源 AI 工具，光是把环境配起来就要半天。Cindy repo 在「开箱即用」这件事上写了不少工程约束，我挑三条最有代表性的：

1. 依赖不是用户自己去装的。
桌面端会自带一套 apps/*-bin 工具二进制——claude-code、codex、ripgrep 由 pnpm install 按平台自动下载；Android platform-tools 在 Windows 打包前按固定版本下载并校验 sha256。版本钉死 + 校验和，依赖不可变，装出来的环境可复现。

2. 安全边界不是靠「提醒」是靠「架构」。
它是一个 Electron 壳子，但文档里专门有 electron-security-and-process-boundaries.md 定义 renderer / preload / BrowserWindow / WebView / IPC / CSP 的进程边界。插件（.cindy）不是能乱跑的，而是被运行时沙箱 + 权限 slot（网络、凭证、资源交接）包起来的，见 plugin-security-and-authoring.md。凭证和本地数据也有专门的安全规则，日志上报还做了脱敏和原子清除。

3. 本地数据是正经做迁移的。
Desktop 端的 SQLite 不是「建个表就行」，它定义了 schema、migration、companion（伴生进程）和运行期访问规范。这意味着升级不丢数据、不改坏结构——对一个把「记忆」当核心卖点的产品来说，这条是命根子。

它的「记忆」和「技能」，不是挂在会话里的，是对象

细看 repo 结构，会发现 Cindy 把 agent 能力做成了独立对象（看 npm monorepo 布局）：

• Memory：纠正它一次，以后就做对。关键是多套 Harness 共用同一份记忆——你教育它的规矩，不会因为你换了个引擎就丢了。
• Skill：教一种做事方法一次，就能在所有地方反复用。
• Automation：周期性任务自己排班、执行、汇报。
• MCP：把内部工具和业务系统「接」进来，而不是写死进某个产品。

这些能力全部收在 packages/* 共享层里（鉴权、device-link、agent 编排、模型供应商……），由 packages/maker-core 统一做 agent 编排、prompt 组装、model 映射，甚至还有缓存率 / 性能 / 准确性指标的度量（maker-core-and-agent-behavior.md）。

表面上看，这只是一个能把活干完的助手。往深了看，它其实在回答一个更大的问题：当模型变成「耗材」，什么才是恒定的内核？ Cindy 的答案是：工作现场、记忆、技能、工具、安全边界——这些跟引擎无关的东西，才值得被认真做成一等公民。

说回 Agent 生态：这是「解耦」对「绑定」的一次反击

把视野拉到整个行业。过去两年，AGI 产品的竞争基本是「全家桶」逻辑：模型、工具、UI、账号，全绑在一个闭环里，你买了我就被套住。谁也不想当「耗材」的搬运工。

Cindy 走的是另一条路：协议 < 接口，通用 < 内核。它复用你已在付费的 Claude Code / Codex Coding Plan，不必重复买单；也能接自己的 API key，甚至本地模型；还能「跳过登录」跑纯本机 agent。

这么做的代价是：少了一些「全家桶」式的顺滑，多了无数需要自己缝合的接缝。它的收益是：你随时能换掉任何一个部件，而不必换掉整个系统。 对一个把「可靠性」看得比「酷炫」重的开发者来说，这比讨好更重要。

如果你正好在多个模型之间做对比测试，likeai520.cc 的 API 中转能省掉不少逐个接 key 的折腾。但要不要把「发动机」焊死在「车上」，是你的选择——而这，恰恰是 Cindy 想还给你的自由。

---

本文基于 makecindy/cindy 公开仓库的 README、README.zh-CN.md、docs/README.md、orca-team-architecture.md 整理，仅作技术分析。