rc-69f3895b-20c9 2026.04.30 32 KB

Yi App / AI IM 竞品横纵研究

原始 research campaign 输出，来自 may1 facade yi app product design research。这页保留报告结构和运行痕迹，正式文章会在写作区重写。

Yi App / AI IM 竞品横纵研究

调研日期：2026-05-01 Campaign: rc-69f3895b-20c9 调研范围：Cherry Studio、LobeChat、Open WebUI、LibreChat、Chatbox、Claude Desktop、ChatGPT Desktop、Poe、TypingMind、MindMac、Cursor 3、Claude Code CLI、Windsurf、Cline、Aider、新兴 Agent UI 协议

一、执行摘要

本报告对 11 款 AI Chat/Agent 产品 + 5 款 IDE Agent 工具 + 若干新兴协议进行了横纵分析，为 Yi App（Maple 的个人 AI IM 客户端，替代 Discord）的 MVP 设计提供竞品参考。

核心结论：

Yi 的最大差异化是"原生 AI IM"而非"又一个 Chat UI"。所有竞品（包括 LobeChat、Poe）本质上仍是"一问一答"的 Chat 范式，没有产品真正以 IM 通讯录 + 异步消息 + 群聊协作为基础架构。Poe Group Chat 最接近但仍是寄生在 Chat UI 上的功能。
后台任务 + 通知是 2025-2026 年的核心战场，但整个行业做得都不好。ChatGPT Tasks 是唯一成熟的定时任务系统，Claude Dispatch 最接近 Yi 的远控场景但缺通知，LobeHub Schedule 是开源唯一方案。Yi 作为 IM 客户端，通知是天然基础设施。
Human-in-the-loop 是公认刚需但几乎无人做好。Open WebUI 的 PR 未合并且有安全问题，LibreChat 排在 Q2 路线图，商业产品只有 Claude Cowork 做了方向纠正级别的 HITL。
A2UI 协议（Google）和 AG-UI 协议（CopilotKit）是值得关注的标准，可避免自造轮子。
移动端 MVP 本质是"agent 仪表盘 + 审批终端"，不是全功能 Chat 客户端。

二、已确定的 Yi App 设计约束

以下约束来自 Meridian 项目现有文档（SOUL.md / IDENTITY.md / ADR-003 / ADR-010 / architecture.md / vyane-personal-runtime-plan.md），是 MVP 设计的硬边界：

编号	约束	来源
C1	IM 是入口，Vyane 是 gateway。自研 app 只做前端入口层，所有任务路由/模型调度/session 管理走 Vyane daemon	ADR-003, vyane-plan
C2	Session 不绑定 Model/Runtime。前端一个会话窗口可能背后切换 GPT-5.5 和 Claude Opus，UI 不能假设固定模型	ADR-003 I-3 不变量
C3	Yi 是唯一面向用户的持久 Agent。短期 AgentRun 在后台执行，由 Yi 协调汇报	ADR-010, team.md
C4	Role / Runtime / Model 三层解耦。前端可展示这三维信息但不能混为一谈	ADR-010
C5	排在 daemon/session 可靠性之后。Vyane 的 webhook auth、scheduler、hot reload 先稳定	vyane-plan
C6	温暖但不谄媚，冲突时可靠性优先。UI 交互反映这个基调	SOUL.md
C7	给选择题不给问答题。UI 应支持 Yi 给出选项让 Maple 选择的交互模式	SOUL.md
C8	影响分级：绿色自动通行、黄色知会、红色需拍板	coordination.md
C9	个人优先，不做通用产品	meridian-personal-first-plan
C10	Discord 只是当前入口，自研 app 应复用 Yi 的 runtime 路由层	vyane-plan

已有基础设施（可直接复用）：

MER-214 MessageInbox：parent-child worker、pending message 注入、本地 API 和 CLI
MER-212 SessionMirror：logical session 与 mirror thread 映射、反向投递
MER-229 IdeaInbox：手动 idea 捕获和 task-board promote
Yi 按 channel 切换 runtime（/runtime codex / /runtime claude）

三、横向分析：逐产品概览

3.1 开源桌面端

能力	Cherry Studio	LobeHub	Open WebUI	LibreChat	Chatbox
GitHub Stars	44.8K	75.9K	135K	36.3K	39.7K
多 Agent 协作	无	有（Agent Groups）	无	无（Q2 规划）	无
多 Model 接入	50+ 提供商	全面	Ollama 为主	最广	基础
MCP 支持	有	有（10K+ 插件）	有	有	有
Tool 调用 UI	基础	中等	可折叠+富 embed	中等	基础
后台任务	无	有（Schedule）	初步	Q2 规划	无
通知机制	无	有限	Events 系统	无	无
HITL 审批	无	有限	PR 未合并	Q2 规划	无
移动端	RN (Expo) 早期	PWA + 适配	PWA	PWA/社区	原生 (Capacitor)
技术栈	Electron+React+Redux	Next.js+React+Zustand	Svelte+Python	React+Node+MongoDB	Electron+React+Jotai
License	AGPL-3.0	社区版	BSD-3 变体	MIT	GPL-3.0

逐产品关键发现：

Cherry Studio：走"AI 生产力工作台"路线，模型接入最广（50+ 提供商、Vercel AI SDK 统一抽象）。v2 大重构中。Mobile app (React Native/Expo) 已有但功能有限。Agent 模式不成熟，缺 HITL 和通知。WebDAV 同步方案有参考价值。
LobeHub：最接近 Yi App 设想的产品。Agent Groups（系统自动组装合适 agent 并行协作）+ Schedule（定时后台任务）+ Pages（多 agent 共享上下文协作）三位一体。技术栈 Next.js + Zustand + CRDT 本地同步。但通知和 HITL 审批不够完善。
Open WebUI：社区规模最大（135K stars、2.82 亿次下载）。Events 系统的 __event_emitter__（单向推送）和 __event_call__（需要用户响应）双模式设计是 Yi 通知/HITL 的直接参考。HITL PR 虽未合并但方案设计值得研究（暴露了 Socket 所有权验证、审批超时、分布式部署等问题）。Svelte + Python 技术栈。
LibreChat：2026 路线图最有野心——Q2 计划同时推出 HITL Approval Gates + Background Agents + Message Queuing。Resumable Streams 的多设备同步对 IM 场景有参考价值。MIT 许可证最友好。Code Interpreter 支持 8 种语言沙箱。
Chatbox：功能最简但跨平台最全（Electron 桌面 + Capacitor 移动端原生 + Web）。Electron + Capacitor 的代码共享方案对 Yi 移动端策略有直接参考价值。近期活跃度下降。

3.2 商业产品

能力	Claude Desktop	ChatGPT Desktop	Poe	TypingMind	MindMac
多 Agent/Bot	Projects + Sub-agent	Custom GPTs	100 万+ Bot 生态	50+ 预设 + 自建	150 模板
多模型切换	仅 Anthropic	仅 OpenAI	200+ 模型	BYOK 多厂商	BYOK 多厂商
Tool trace 可视	推理过程+计划侧栏	Tools 六模式+侧栏进度	基础	Thinking 展示	基础
后台任务	Cowork+Dispatch+Routines	Tasks 定时任务	无	无	无
通知推送	暂缺	Push+Email 完善	社交通知	无	无
人工接管	透明推理+方向纠正+删除授权	Monitor model+计划可编辑	停止生成	停止生成	停止生成
移动端	iOS/Android + Dispatch 远控	iOS/Android 完整	全平台原生	PWA	仅 macOS
独特 UI	三 Tab 分流	Tools 下拉	Multi-Bot Chat/Group Chat	对话内换模型+Fork	Inline Mode
定价	订阅 $20-200/月	订阅 $20-200/月	订阅 $5-250/月	一次性 $23+	一次性 $29-69

逐产品关键发现：

Claude Desktop：三个后台任务层级最有参考价值——Cowork（本地 VM agentic 任务）→ Dispatch（手机远控桌面执行）→ Routines（云端，关机也能跑）。Cowork 的 HITL 设计是标杆：透明推理过程 + 方向纠正 + 删除操作显式授权。但通知缺失是明确短板，Dispatch 没有 push notification，用户需主动检查。未发布的 Chyros 源码泄露显示有 push notification 设计但未上线。
ChatGPT Desktop：唯一在生产环境大规模运行的 AI 定时任务系统（Tasks，Free 10 个/Plus 40 个/Pro 400 个）。通知最完善（Push + Email，可分别开关）。Deep Research 的"可编辑计划 + 实时进度 + 中途干预"是异步长任务交互的最佳参考。Monitor model 独立看护 agent 行为的安全思路值得借鉴。
Poe：唯一做到人+AI 群聊的商业产品（Group Chat 支持 200 人 + 200 个 AI 模型同框）。Multi-Bot Chat（同一提示多模型并排回答）是独有交互。Canvas Apps 突破纯对话界面。对 Yi 的 IM 场景最有直接参考价值，但 Poe 本身没有后台任务和 HITL 能力。
TypingMind：对话内换模型 + Fork 是杀手功能——在 IM 语境中等于"让不同 agent 接手同一对话"。BYOK + 一次性买断的商业模式适合注重隐私和成本控制的个人用户。本地数据存储 + SOC 2 合规。PWA 移动端有天花板。
MindMac：Inline Mode 最有启发——在任何 app 内通过 /gpt 命令直接调用 AI，无需切换窗口。说明 AI 不一定要在独立窗口里用。macOS-only 是战略选择。成本追踪功能在 BYOK 模式下很实用。

3.3 IDE Agent 工具

产品	核心 UI 模式	后台 Agent	通知	HITL	对 Yi 的启发
Cursor 3	Agent-first：Agents Window 统一面板，Canvas 持久化 artifact	云端 VM，自建分支+PR	OS 通知+Slack+声音	Design Mode 点击选择	"对话流+任务面板"双视图；Canvas/Artifact 模型
Claude Code	终端折叠式 tool trace，Ctrl+B 后台，`/tasks` 查看	子 agent 后台运行	完成时浮出（不主动推送）	6 种权限模式分级	折叠式 trace 是处理透明性的好方案；后台通知是公认痛点
Windsurf	Flow Awareness 共享时间线	并行多 agent session	IDE 内通知	实时逐步 approve/reject	跨 app/设备上下文追踪概念
Cline	Plan-Preview-Apply 三阶段	VS Code 内运行	侧边栏更新	最细粒度：每步 diff 审批	高风险操作的三阶段模型
Aider	终端原生，Architect 模式先讨论再执行	无	无	无	先方案后执行的对话节奏

3.4 新兴协议与"AI IM"先驱

协议/产品	描述	对 Yi 的价值
A2UI (Google)	Agent-to-User Interface 协议。Agent 输出声明式 JSON payload 描述 UI 组件组合，客户端渲染器映射到本地实现。安全（不执行任意代码）、LLM 友好（扁平组件列表+ID 引用）。v0.9 接近稳定	Yi agent 回复不应只是文本，应支持声明式 UI 组件渲染。A2UI 的安全模型和 LLM 友好设计正好适合 IM 场景
AG-UI (CopilotKit)	Agent-User Interaction Protocol。HTTP/WebSocket 事件流协议，定义 agent 后端与前端应用间的双向实时通信。Google/LangChain/AWS/Microsoft 已采用	可作为 Yi 的 agent-frontend 通信层标准，不用自己发明轮子
Poke	通过 iMessage/SMS/Telegram/WhatsApp 发消息使用 AI agent。近月用户量 10 倍增长	验证了"把 AI agent 当联系人"的需求真实存在
Manus (Telegram Agent)	2026.02 在 Telegram 推出个人 AI agent，能执行复杂任务（找公寓、建网站、订外卖）	验证了 IM 内 agent 的可行性，但寄生在别人平台上有天花板

四、纵向分析：按维度深度对比

4.1 多 Agent 支持

行业现状：绝大多数产品只支持"多个独立 agent/bot"，不支持 agent 之间的协作。

层级	描述	代表产品
L0 预设模板	只有 system prompt 预设，无独立 agent 概念	MindMac、Chatbox
L1 独立 Agent	用户可创建自定义 agent，各自独立工作	Cherry Studio、Open WebUI、TypingMind
L2 Agent 生态	有 Marketplace/Store，社区共享 agent	ChatGPT (GPTs)、Poe (100 万+ bot)、LibreChat
L3 Agent 协作	系统自动组装多 agent 并行协作	LobeHub (Agent Groups)、Claude (Cowork sub-agent)
L4 Agent 通讯	Agent 之间异步消息通信、handoff	无商业产品做到（Yi 的 ADR-003 Message 概念在此）

Yi 的定位：直接面向 L4。Yi 作为唯一持久 Agent 协调多个 AgentRun，AgentRun 之间通过 Message（handoff/escalation）通信。这超越了所有现有竞品的 agent 协作深度。

4.2 多 Model 支持

行业共识：2026 年 MCP 已成为标配，多模型接入不再是差异化。

模式	描述	代表
封闭单厂商	仅自家模型	Claude Desktop、ChatGPT Desktop
BYOK 多厂商	用户自带 API Key	TypingMind、MindMac、Cherry Studio
平台聚合	统一计费，200+ 模型	Poe
本地+远程混合	Ollama 本地 + 云端 API	Open WebUI、LobeHub

Yi 的约束（C2）：Session 不绑定 Model/Runtime。前端需展示当前使用的 model 信息但不限制切换。这与 TypingMind 的"对话内换模型 + Fork"最接近，但 Yi 的切换是由 Vyane gateway 路由的，不是用户手动选择。

4.3 Tool Trace / 思考过程展示

最佳实践综合：

层级	内容	展示方式	参考
L1 状态指示	“正在思考…” / “正在调用工具…”	一行文字 + 微光动画	ChatGPT 流式反馈
L2 步骤摘要	具体在做什么：“正在检查航班…”	Progressive disclosure	ChatGPT Deep Research 侧栏
L3 可折叠详情	完整 thinking chain / tool call 日志	默认折叠，点击展开	Claude Code、Open WebUI
L4 交互式 artifact	代码 diff、表格、图表、确认按钮	独立卡片/Canvas	Cursor Canvas、Poe Canvas Apps

Yi 的建议：采用 L1-L3 的渐进披露，L4 通过 A2UI 声明式 UI 实现。在 IM 消息流中，tool call 作为特殊消息类型（带 icon + 折叠框），融入消息流而非打断它。

4.4 后台任务

行业全景：

产品	后台模式	持久性	触发方式
ChatGPT Tasks	定时/周期任务	云端，离线可跑	用户设定时间
Claude Cowork	本地 VM agentic 任务	需开机	用户发起
Claude Dispatch	手机远控桌面执行	需桌面端在线	手机端发指令
Claude Routines	云端执行	关机也能跑	计划任务
LobeHub Schedule	定时运行 agent	需服务端在线	用户设定
Cursor Background Agent	云端 VM 独立运行	云端，独立于客户端	用户发起/CI 触发

Yi 的优势：作为 IM 客户端，后台任务完成后的通知天然就是一条消息推送到对话中。这比任何竞品的通知机制都更自然。Vyane daemon 已有 scheduler-mode shadow，可以直接承载后台任务执行。

4.5 通知机制

行业现状极其薄弱：

产品	通知能力	评价
ChatGPT	Push + Email，可分别开关	唯一完善的
Claude Desktop	缺失（Dispatch 无 push）	被用户明确吐槽
Poe	社交型通知（关注/回复）	非任务通知
Open WebUI	Events 系统（emitter + call）	架构好，但限于 Web
LobeHub	有限	Schedule 暗示有回调
其余	无	—

Yi 的机会：这是整个行业最大的空白。Yi 作为 IM 客户端，推送通知是基础设施。建议实现三级推送：

静默同步：常规状态更新只更新角标
标准推送：任务完成通知，显示摘要
紧急推送：需要 HITL 审批，附带 action button

4.6 Human-in-the-Loop

行业最薄弱环节。按成熟度排序：

层级	描述	代表	状态
L0 停止生成	用户只能终止，不能干预	Poe、TypingMind、MindMac、Chatbox	大多数产品的现状
L1 权限门控	敏感操作需授权	Claude Code（6 种权限模式）	已实现但仅限 CLI
L2 方向纠正	执行中修改指令/计划	Claude Cowork、ChatGPT Deep Research	商业产品领先
L3 逐步审批	每个操作预览 diff，approve/reject	Cline（Plan-Preview-Apply）	仅 IDE 工具
L4 Approval Gates	工具使用审批门控 + 消息排队	LibreChat（Q2 路线图）	未实现

Yi 的建议：结合约束 C8（影响分级），实现三级确认：

绿色（自动通行）：低风险操作 agent 自主执行，结果通知
黄色（知会+确认）：展示 Plan/Preview，用户一键确认或修改
红色（逐步审批）：敏感操作逐步 diff 审批，类似 Cline 的 Plan-Preview-Apply

4.7 移动端

四层状态模型（来自 AI UX Design Guide）：

层级	名称	形态	适用场景
L1	Ambient Status	角标/小圆点	Agent 后台运行中，无需关注
L2	Progress Status	可展开进度面板	用户主动查看时展开
L3	Attention Status	中断式通知	需要用户输入/审批
L4	Summary Status	完成报告	任务结束后的结果摘要

跨平台技术方案对比：

维度	Tauri (桌面) + React Native (移动)	Flutter 全平台	Electron + Capacitor
桌面端体验	最好（原生窗口、低内存）	一般	中等（Electron 内存大）
移动端体验	好（RN 成熟生态）	最好（Impeller 引擎 60/120fps）	中等（WebView 有限）
代码复用	共享 TS 逻辑层	一套代码	共享 React 代码
推送通知	原生完整支持	原生完整支持	原生支持
AI Chat 适配	好	最好（有官方 AI Toolkit）	中等
开发成本	中（两套 UI 层）	低（一套代码）	低（共享代码）
已有案例	—	—	Chatbox

Claude Dispatch 模式是最接近 Yi 移动端场景的参考：手机发指令 → 桌面端执行 → 异步返回结果。但 Dispatch 缺 push notification 是公认短板。

五、IM 风格 vs Chat 风格融合分析

两种范式的核心差异

特征	传统 IM（微信/Telegram/Discord）	AI Chat（ChatGPT/Claude）
组织方式	联系人/群组列表	按话题的对话列表
时间线	按时间排列，新消息在底部	一问一答交替
状态感知	已读/在线/正在输入	AI 永远在线
交互手势	左滑回复、长按反应、@提及	输入框+发送
富内容	消息气泡 + 文件/图片/视频	Markdown+代码+LaTeX
通知	按对话粒度，支持免打扰	基本无通知

融合模型：IM 壳 + Agent 内核

Telegram Bot 是目前最成熟的融合案例：Bot 作为联系人出现在聊天列表，内联键盘（Inline Keyboard）允许 bot 在消息下方挂按钮触发回调。但 Telegram Bot 不支持复杂富文本渲染、折叠展开、流式输出。

Yi App 的融合设计建议：

IM 概念	Yi 中的映射
联系人列表	Agent 列表（Yi 是主联系人，其他 AgentRun 按角色/任务列出）
在线状态	Agent 运行状态（绿点=空闲，旋转=运行中，橙色=等待审批）
消息气泡	Agent 回复用卡片式展示（支持折叠 tool trace、内嵌 artifact）
群聊	多 Agent 协作空间（参考 Poe Group Chat，但更深——展示任务委派链）
内联键盘	Agent 消息下方挂审批按钮/选项按钮（约束 C7：给选择题）
@提及	指定 Agent/Role 接手任务
消息免打扰	按 Agent/任务粒度设定通知级别
消息引用	关联上下文/引用历史决策

六、值得直接借鉴的设计模式

来源	借鉴点	适用于 Yi 的方式
LobeHub Agent Groups	系统自动组装多 agent 并行协作	Yi 通过 Vyane 的 task routing 实现，前端展示协作关系
LobeHub Schedule	定时后台任务	对接 Vyane scheduler，结果推送到 IM 对话
Open WebUI Events	`__event_emitter__`（单向）+ `__event_call__`（需响应）双模式	Yi 的通知和 HITL 架构参考
LibreChat Resumable Streams	断线重连 + 多设备同步	IM 场景下的消息可靠投递
ChatGPT Tasks	定时/周期任务 + Push/Email 通知	后台任务 + 通知的产品设计参考
ChatGPT Deep Research	可编辑计划 + 实时进度 + 中途干预	长任务的 HITL 交互模式
Claude Cowork	透明推理 + 方向纠正 + 删除授权	HITL 的信任模型参考
Claude Dispatch	手机远控桌面执行	移动端 MVP 的核心交互模式
Poe Group Chat	200 人 + 200 AI 模型同框	IM 范式下人+AI 群聊的产品验证
TypingMind Fork	对话内换模型 + 分叉讨论	"让不同 agent 接手同一对话"的交互映射
MindMac Inline Mode	在任何 app 内调用 AI	系统级 AI 快捷入口（macOS Spotlight 式）
Cursor 3 Agents Window	所有 agent 任务统一面板	"对话流 + 任务面板"双视图架构
Cursor Canvas	Agent 产出持久化交互式 artifact	Agent 输出不只是文本消息
Cline Plan-Preview-Apply	三阶段审批	高风险操作的 HITL 交互
Windsurf Flow Awareness	跨 app 上下文追踪	长期方向：Yi 感知 Maple 跨设备工作状态
A2UI (Google)	声明式 agent UI 组件协议	Agent 回复渲染为结构化 UI 而非纯文本
Chatbox Capacitor	Electron + Capacitor 跨端方案	移动端技术选型参考

七、MVP 范围建议

7.1 核心架构

┌─────────────────────────────────────────────┐
│                   Yi App                     │
│  ┌──────────────┐  ┌──────────────────────┐  │
│  │  对话流视图   │  │   任务面板视图        │  │
│  │  (IM 主界面)  │  │  (Agent Dashboard)   │  │
│  └──────┬───────┘  └──────────┬───────────┘  │
│         │                     │               │
│  ┌──────┴─────────────────────┴───────────┐  │
│  │          本地 Event Bus                 │  │
│  │  (通知分级 / HITL 路由 / 状态同步)      │  │
│  └──────────────────┬─────────────────────┘  │
└─────────────────────┼─────────────────────────┘
                      │ HTTP / WebSocket
              ┌───────┴────────┐
              │  Vyane Daemon   │
              │  (Gateway)      │
              │  ┌────────────┐ │
              │  │ MessageInbox│ │
              │  │SessionMirror│ │
              │  │ Scheduler   │ │
              │  └────────────┘ │
              └───────┬────────┘
                      │
          ┌───────────┼───────────┐
          │           │           │
     Claude Code   Codex CLI   Gemini CLI
     (Opus/Sonnet) (GPT-5.5)   (Gemini)

7.2 功能优先级

P0：MVP 必须有

功能	描述	理由	参考竞品
IM 对话流	与 Yi 的基本对话，支持 Markdown 渲染、代码高亮	核心交互	所有产品
Agent 联系人列表	Yi 作为主联系人，AgentRun 按角色/任务列出，带运行状态	IM 范式的核心差异化	Poe Bot 列表
Vyane API 对接	调用现有 MessageInbox / SessionMirror API	约束 C1：IM 只是入口	—
Tool trace 折叠	tool call 和 thinking 过程默认折叠，点击展开	信息密度管理	Claude Code、Open WebUI
选项式交互	Yi 给出选项按钮让 Maple 选择	约束 C7	Telegram Inline Keyboard
影响分级门控	绿色自动、黄色确认、红色审批	约束 C8	Claude Cowork、Cline
桌面系统通知	任务完成 / 审批请求推送到 OS 通知	通知是 IM 基础设施	Cursor、ChatGPT
Model/Runtime 标识	每条消息标注使用的 model 和 runtime	约束 C2、C4	TypingMind

P1：MVP 后第一轮迭代

功能	描述	理由	参考竞品
任务面板	所有运行中/历史 agent 任务聚合视图	Cursor Agents Window 验证的模式	Cursor 3
后台任务生命周期	pending → running → waiting → completed/failed	后台任务的可视化	ChatGPT Tasks
对话 Fork/分支	从某条消息分叉，用不同 agent/model 继续	探索性对话的核心需求	TypingMind
消息搜索	全文搜索历史对话	IM 基本功能	所有 IM
A2UI 渲染	Agent 回复渲染为结构化 UI 组件（表格/图表/确认卡片）	超越纯文本的表达力	A2UI 协议、Cursor Canvas
移动端只读浏览	手机查看对话历史和 agent 状态	移动端最核心价值	Claude Dispatch
移动端推送+审批	推送通知 + 直接在通知上审批	移动端生命线	ChatGPT Push

P2：中期迭代

功能	描述	参考
多 Agent 群聊	多个 AgentRun 在同一空间协作，展示任务委派链	Poe Group Chat、LobeHub Agent Groups
定时/周期任务	设定 agent 定时执行任务，结果推到 IM	ChatGPT Tasks、LobeHub Schedule
跨设备同步	桌面-移动实时同步对话和状态（SQLite + CRDT）	LibreChat Resumable Streams
成本追踪	每个 agent/session 的 token 消耗和费用	MindMac
对话/任务文件夹	按项目/主题组织对话	LibreChat、LobeHub

P3：长期方向

功能	描述	参考
Flow Awareness	追踪 Maple 跨 app/设备的操作上下文	Windsurf
系统级快捷入口	在任何 app 内通过快捷键调用 Yi	MindMac Inline Mode
Agent Marketplace	共享/导入社区 agent 配置	Poe、LibreChat
云端 Routines	关机也能跑的后台任务	Claude Routines
语音交互	移动端语音输入/对话	ChatGPT Voice Mode

7.3 技术栈建议

层	推荐	理由
桌面端框架	Tauri 2	比 Electron 内存低 10 倍，Rust 后端可复用。Yi 定位桌面优先
前端框架	React + TypeScript	4/5 开源竞品采用，生态最成熟。Tauri 2 完整支持 React
状态管理	Zustand	LobeHub 验证，比 Redux 轻量
本地存储	SQLite (libsql/Turso)	Cherry Studio + Chatbox 验证，离线优先
跨设备同步	SQLite + CRDT (sqlite-sync)	本地优先 + 无冲突合并
移动端	React Native（P1 阶段）	与 React Web 共享逻辑层，推送通知原生支持
Agent-UI 通信	AG-UI 协议或 WebSocket 事件流	标准化，不自己发明轮子
Agent UI 渲染	A2UI 协议	声明式、安全、跨平台一致

不推荐：

Electron：内存占用是所有桌面端的共同痛点，新项目应避免
纯 PWA 移动端：iOS 推送能力受限（无静默推送/富媒体），对 HITL 审批场景不可接受
Flutter：代码复用好但与现有 Web 技术栈不兼容，且桌面端体感不如 Tauri

八、不确定性与风险

项目	不确定性	影响	建议
A2UI 协议成熟度	v0.9 接近稳定但未 v1.0，可能有 breaking changes	UI 渲染层设计	关注 v1.0 发布，MVP 阶段先用自定义 JSON schema 可后期迁移
Vyane daemon 稳定性	约束 C5 明确排在 daemon 稳定之后	MVP 开发时间线	Yi App 前端可先用 mock API 开发，后接 Vyane
Tauri Mobile 成熟度	Tauri 2 桌面端成熟，但移动端仍是早期	移动端方案	移动端用 React Native 而非 Tauri Mobile
跨设备 CRDT 同步	sqlite-sync 尚无大规模生产验证	数据同步可靠性	MVP 阶段先做单设备，CRDT 同步放 P2
开源许可证风险	Cherry Studio (AGPL) 和 Chatbox (GPL) 要求衍生作品开源	如果参考代码	仅参考设计思路，不直接引用代码。LibreChat (MIT) 最安全
LobeHub 竞争	LobeHub 正在快速迭代，方向与 Yi 有重叠	差异化压力	Yi 的核心差异是 IM 原生 + 个人化（约束 C9），不是通用平台

九、建议的后续调研

方向	原因	优先级
A2UI v1.0 tracking	协议稳定后评估是否直接采用	P1
Open WebUI HITL PR 源码分析	学习安全问题和实现细节（Socket 所有权验证、审批超时等）	P1
LibreChat Q2 发布跟踪	Approval Gates + Background Agents 落地后评估效果	P1
Claude Chyros 进展	后台 agent + push notification 的官方实现	P2
LobeHub Agent Groups 深度试用	实际体验多 agent 协作的 UX	P2
Tauri 2 + React 实际 PoC	验证桌面端开发体验和性能	P0（MVP 前）
Poe Group Chat 深度试用	体验人+AI 群聊的 UX 边界	P2

十、附录：信息来源

开源产品

Cherry Studio: GitHub (44.8K stars)
LobeHub: GitHub (75.9K stars)
Open WebUI: GitHub (135K stars)
LibreChat: GitHub (36.3K stars)
Chatbox: GitHub (39.7K stars)

设计参考

AI UX Design Guide: aiuxdesign.guide
Agentic UI Design Patterns: Procreator Design
OpenAI Apps SDK UI Guidelines: developers.openai.com
Cross-Platform Tech Comparison: CodeNote
SQLite-Sync CRDT: GitHub

项目内部文档

SOUL.md、IDENTITY.md、ADR-003 v2、ADR-010、architecture.md、meridian-personal-first-plan.md、vyane-personal-runtime-plan.md、team.md、coordination.md、yi-personality-design.md

Yi App / AI IM 竞品横纵研究

一、执行摘要

二、已确定的 Yi App 设计约束

三、横向分析：逐产品概览

3.1 开源桌面端

3.2 商业产品

3.3 IDE Agent 工具

3.4 新兴协议与"AI IM"先驱

四、纵向分析：按维度深度对比

4.1 多 Agent 支持

4.2 多 Model 支持

4.3 Tool Trace / 思考过程展示

4.4 后台任务

4.5 通知机制

4.6 Human-in-the-Loop

4.7 移动端

五、IM 风格 vs Chat 风格融合分析

两种范式的核心差异

融合模型：IM 壳 + Agent 内核

六、值得直接借鉴的设计模式

七、MVP 范围建议

7.1 核心架构

7.2 功能优先级

P0：MVP 必须有

P1：MVP 后第一轮迭代

P2：中期迭代

P3：长期方向

7.3 技术栈建议

八、不确定性与风险

九、建议的后续调研

十、附录：信息来源

开源产品

商业产品

IDE Agent 工具

新兴协议

AI IM 先驱

设计参考

项目内部文档