Eyrie 与 Cradle 同时诞生于 2025-2026 年 AI 编码工具爆发期，均采用 Electron + React 19 + Drizzle + xterm 技术栈，但解决的核心问题截然不同：Eyrie 是交付中枢，Cradle 是指挥中心。
Cradle 在哪些维度领先 Eyrie？Eyrie 的工程纪律优势能否转化为产品壁垒？哪些 Cradle 功能值得 Eyrie 短期引入？
两个项目从不同角度切入 "AI 编码工具管理" 问题域，各自的核心循环和产品边界大相径庭。
| 维度 | Eyrie | Cradle |
|---|---|---|
| 一句话定位 | AI 编码时代的软件交付中枢 | AI 工具的统一管理平台 |
| 核心循环 | plan → dispatch agents → review → merge | organize → manage agents → human-AI collab |
| 侧重 | 让 agent 产出安全落地到代码库 | 给多个 AI 工具一个统一 UI |
| 创建时间 | 2025-05 | 2026-04-25 |
| 开源状态 | 私有 MVP | 公开仓库 |
| 目标用户 | 使用 AI agent 的开发团队 | 同时使用多个 AI 工具的个人开发者 |
两者在 monorepo 结构和核心组件选型上高度重合，关键分歧集中在 API 协议、状态管理和扩展机制。
| 维度 | Eyrie | Cradle |
|---|---|---|
| 包管理器 | bun workspaces | pnpm workspaces |
| Monorepo | apps/ + packages/ | apps/ + packages/ + plugins/ |
| 桌面框架 | Electron + electron-vite | Electron + electron-vite |
| 前端 | React 19 + TanStack Router | React 19 + TanStack Router |
| 后端 | 独立 daemon, Hono + WebSocket | 独立 server, Hono + Elysia |
| API 协议 | tRPC 端到端类型推导 | OpenAPI Elysia 生成 + openapi-ts |
| 数据库 | Drizzle + better-sqlite3 | Drizzle + better-sqlite3 |
| 状态管理 | 服务端 state + React Query | Zustand + React Query |
| 富文本 | incremark (轻量) | Tiptap (完备 WYSIWYG) |
| 终端 | xterm.js + node-pty | xterm.js + node-pty |
| i18n | i18next | i18next |
| 可观测性 | pino 日志 | OpenTelemetry + Langfuse + Prometheus |
| 插件系统 | 无 | Plugin SDK + 6 内置插件 |
| AI 集成 | 调 provider CLI | Vercel AI SDK 多 provider |
Eyrie 选择 tRPC 意味着 daemon、client 包、desktop 三层共享同一份类型定义，任何接口变更在编译期即可捕获不一致。Cradle 选择 OpenAPI + codegen 路线，API 文档自动生成对外部消费者友好，但 codegen 产物与源码之间存在同步时差。
Cradle 拥有完整的 Plugin SDK：manifest 声明、权限模型、生命周期钩子，已有 browser-use、github-issues 等 6 个内置插件。Eyrie 目前通过 ACP (Agent Client Protocol) 对接外部 agent，但无通用插件机制，新 agent backend 需要硬编码。
从产品功能维度看，Cradle 追求覆盖面广度，Eyrie 追求每个功能的闭环深度。
| 功能 | Eyrie | Cradle |
|---|---|---|
| Task/Issue Kanban | 核心功能，含标签、里程碑 | 核心功能，含代理委派 |
| Agent 会话管理 | session + runner-manager | session + await 支持 + CI 集成 |
| Chat 运行时 | 通过外部 agent CLI 代理 | 内建多 provider Chat UI |
| Git 集成 | 仓库模型 + 分支 + 差异 | simple-git 基础集成 |
| 内置终端 | xterm + node-pty | xterm + node-pty |
| Agent 协议 | ACP | ACP + Claude Agent SDK + Codex |
| 长期记忆 | 无 | jieba 分词 + 知识持久化 |
| 代码编辑器 | 无 | Monaco Editor |
| 流程可视化 | 无 | xyflow 节点图 |
| 自动更新 | 无 | electron-updater |
| 跨平台分发 | 开发中 | macOS/Win/Linux 就绪 |
| E2E 测试 | 无 | Playwright + Cucumber |
| Web 版本 | 仅 desktop | 独立 web app |
| Observability | 日志 | OpenTelemetry 全链路 |
Eyrie 的 Git 模块 (apps/daemon/src/git/) 拥有独立的 model 层和 testing 层，对分支操作建模为领域对象。Cradle 仅通过 simple-git 做基础调用。在 "agent 产出合入主干" 这个场景中，Eyrie 的 Git 集成深度是其核心竞争力。
Cradle 同时集成了 ACP、Claude Agent SDK 和 Codex SDK 三种协议，覆盖面更广。Eyrie 目前仅支持 ACP，但 provider discovery 和 provider detection 机制为未来扩展提供了接口。
工程实践是 Eyrie 相对 Cradle 的最显著优势。Eyrie 在 CI 守护、依赖管理和架构边界上的投入远超同期产品。
| 维度 | Eyrie | Cradle |
|---|---|---|
| 类型安全 | tRPC 端到端推导 | OpenAPI codegen |
| 包边界检查 | eslint-plugin-boundaries | 无 |
| CI 守护脚本 | 8+ 自定义检查 | 标准 lint + test |
| 依赖版本 | 精确锁定 + overrides | 范围版本 (^) |
| 注释规范 | check-comments 自动化 | 无 |
| 密钥扫描 | check-secrets | 无 |
| CJK 规范 | check-cjk | 无 |
| CSP 检查 | check-csp | 无 |
| 主题 Token | check-theme-tokens | 无 |
| React Compiler | 未使用 | babel-plugin-react-compiler |
^ 范围版本，CI 重现性依赖 lockfile 而非声明Eyrie 应从 Cradle 的功能广度中挑选高 ROI 项加速产品化，同时将工程纪律转化为协作 AI 场景下的产品壁垒。
本周评估 electron-updater 集成工作量，本月内完成自动更新上线。Q3 规划 OpenTelemetry 接入和 Playwright E2E 框架搭建。