Omi 桌面端 Mac→Windows 对等移植Track 3「主动智能与记忆」的状态文档解读与 P0–P9 阶段规划【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend本文以 Omi 仓库desktop/windows/docs/mac-parity-audit/track3-ground-truth/下的编排器状态文档_TRACK3-STATUS.md为主体完整拆解 Windows 版 Omi 桌面端「主动智能与记忆」移植轨道Track 3的 P0–P9 阶段计划、九份 ground-truth 证据的关键结论staged-tasks 契约、Goals 后端真相、Focus/Glow 机制、记忆抽取与嵌入、连接器以及门控决策与挂起问题的处理方式。读完本文你可以掌握一条可复用的跨平台功能对等parity移植方法论如何用冻结参考分支、源码级证据核验与增量式additive数据库 schema驱动一个长周期、可无人值守推进的多阶段工程。一、这份状态文档是什么长周期无人值守会话的单一事实源_TRACK3-STATUS.md的开头定义了自己的定位Orchestrator status doc. Single source of truth for phase progress, decisions, and parked questions across this (long, unattended) session. Update as items complete.编排器状态文档是本次长周期、无人值守会话中阶段进度、决策与挂起问题的单一事实源随事项完成持续更新。它同时钉住了整条轨道的工程环境坐标原文逐条给出项值工作分支feat/win-proactiveworktree 位于.worktrees/track3-proactive已推送到 origin沙箱端口renderer5223CDP9329沙箱 profileomi-windows-sandbox-track3-proactiveMac 参考冻结 ground truth.worktrees/mac-ref tagv0.12.7212072-macoscommit50d264c9「冻结参考」是这个工作流的核心手法之一把 Mac 端代码钉死在特定 tag/commit 上作为基准所有 ground-truth 提取器extractor都对着这份冻结源码逐行核验而不是对着文档摘要转述。文档还说明了 P0 阶段的一个实战细节初始 spawn 的提取器中 coordinator 与 insight 两个因挂起被换窄narrower后重生extractors done (coordinatorinsight respawned narrower after hanging)体现了编排器对子任务超时的处置方式。二、P0–P9按依赖顺序排布的阶段路线图状态文档的 Phase plan (dependency order) 一节列出了整条轨道的完整路线图与当时状态。这是理解 Track 3 全局的主骨架阶段内容状态该快照时点P0 Ground truth源码级事实提取✅ 完成P0 增量式 schema PR3 张新表 CRUD 漂移守卫✅ 已合并PR #32mergec3b01ecP1 AI User Profile用户画像合成✅ 已合并PR #42渲染层自动触发接线推迟到 P2P2 AssistantCoordinator框架层节流、上下文切换检测、背压⬜ 未开始P3 Focus assistant glow overlay专注助手与发光边框⬜ 未开始P4 Insight assistant 深度两阶段 SQLvision、backend-sync 作为记忆、历史 UI⬜ 未开始P5 连续记忆抽取 embeddingssource-namespace 键、count-guard、RAW-row 分页器⬜ 未开始P5b 屏幕任务抽取受门控 G-A 约束⬜ 未开始P6 自动每日目标生成 advice目标完成走后端契约C10Mac wrongGoals 导航受 G-C 约束⬜ 未开始P7 统一连接器三个入口Memories 页 / onboarding / Apps hub发布同一能力⬜ 未开始P8 Home widgetsWhatMattersNowSectionFocusedGoalsSection删除 legacyQuickTask/QuickGoals⬜ 未开始P9 页面表层对齐 Mac 规格Memories / Tasks / Goals 三页⬜ 未开始两个值得注意的「纠偏」措辞直接写在路线图里P6 标注 goal-completion uses BACKEND contract (C10, Mac wrong)——即 Mac 端的目标完成实现相对后端契约是错的移植时以服务端契约为准而不是照抄 Mac这一点在下方 Goals ground truth 中有完整证据。P9 标注 Tasks (grouped-by-due; NOT rich multi-filter G-D)——Mac 的富多组过滤器 UI 被明确排除仅对齐分组方式。需要说明时间线该状态文档是 Track 3 会话进行中2026-07-14 前后的活快照后续整体重写的对等审计索引 00-INDEX.md 在 2026-08-22 重新核验后记录coordinator 与 Focus/Insight/Memory/Task/Goal 各助手实际已于 2026-07-14 至 07-19 间陆续合入 Windows 端。也就是说本文描述的是这条轨道从证据到计划、再到前两个 PR 落地的完整决策过程而 P2 之后的阶段在快照之后数日内被逐步兑现。三、P0Ground truth 与增量式 schema PR3.1 增量式建表模式无需迁移条目gt-windows-inventory 的返回结论定义了 Windows 端db.ts的新表模式状态文档原样继承新表通过CREATE TABLE IF NOT EXISTS写在 bootstrap 中镜像现有insights表 INSIGHT_COLUMNSrecentInsights的写法dbMigrations的MIGRATIONS数组只有一条v1净新增表不需要迁移条目避免版本号争用渲染层两种既有数据模式A 本地 SQLite 经 IPC 访问window.omi.X→ ipc →db.tsB renderer 直接 axios 打后端memories/goals/tasks 现状无本地表。3.2 P0 PR 的落地结果状态文档记录 P0 增量式 schema PR 由 Opus agentafe2c9b实现、独立 Opusaaa3be8审计后合并3 张净新增表均为CREATE TABLE IF NOT EXISTS无迁移条目ai_user_profiles、focus_sessions、task_embeddings后者采用复合主键(source, item_id)对应 Mac 端的一处 bug fix详见第六节配套db.ts中 14 个 CRUD 函数 taskEmbeddingVector.tsshared/types.ts记录类型 dbTrack3.test.ts9 个测试助手设置不落 SQLite复用 Windows 现有 settings store验证typecheck 干净、全量套件 1484 pass15 skip、eslint 干净真机启动real-app-boot验证 3 张表确实被创建。3.3 漂移守卫drift-guard抓到的真实泄漏P0 中最有价值的一条记录是漂移守卫的实战收益Drift-guard caughtfixed a real Track-2 leak (voice_turn_outbox missing from sign-out wipe) and exempted Track-4 app_meta. 即守卫发现voice_turn_outbox表漏在 sign-out 清理逻辑之外属于另一条轨道 Track 2 的表顺手修复同时对 Track 4 拥有的app_meta表做了豁免。这说明该守卫不是只服务于本轨道而是覆盖全库表级不变量的跨轨道防线。四、P1AI User Profile 的架构决策状态文档对 P1 的标注信息密度很高是「渲染层/主进程职责划分」的一次典型裁决实现形态main/assistants/aiUserProfile/{synthesis,service} IPC 设置开关 增量式类型/preload 绑定。synthesis 逻辑为纯函数且有测试采用两阶段2-stage合成输出字符上限 10000prompt 要求 2000data_sources_used取总条目数与 Mac 口径一致。后端契约GET/PATCH /v1/users/ai-profile无平台分支platform-agnostic。在线冒烟真实 backend LLM 跑通产出连贯画像data_sources_used66。架构裁决原文 ARCHservice 是主进程侧能力而渲染层持有 Firebase token因此「调度/会话推送由 renderer 驱动」——自动触发接线auto-trigger wiring随 P2 的 renderer 主动式框架一起落地当前先用手动generateNow(session)演练。审计修复清单Opus 审计后给出修复项 M1编辑路径 count 损坏、m3service 错误路径测试、m4401 与无数据的区分、m6/m7/m8。五、Ground-truth 证据深读一Tasks 与 staged_tasks 契约gt-tasks.md 是门控 G-A 的「证据消解」现场状态文档以 G-A DISSOLVED 一句话收编了其结论服务端只有一个任务暂存模型staged_tasks。路由层在 backend/routers/staged_tasks.pyPOST/GET/DELETE /v1/staged-tasks、PATCH /v1/staged-tasks/batch-scores、POST /v1/staged-tasks/promote、POST /v1/staged-tasks/{id}/promote、POST /v1/staged-tasks/migrate模型定义见 backend/models/staged_task.py字段为id / description / completed / due_at / source / priority / metadata / category / relevance_score(0-1000)。Promote 不是机械搬运promote_staged_task在创建action_item前用get_active_action_item_by_description大小写不敏感、剥离[screen]标记后归一化做去重守卫命中则把due_at/priority/category等富化字段合并进已有条目并标记completedTrue, promotion_skippedduplicate, promoted_toexisting_id。平台无关对routers/staged_tasks.py与database/staged_tasks.pygrepX-App-Platform/platform零命中——Windows 客户端可直接消费无服务端门控风险。G-A 消解的推理任务前提Mac 正在服务端向 Candidate/workstream 模型迁移与源码不符——全backend/树中Candidate|Workstream的约 50 处命中全部属于记忆域等无关子系统客户端里的 Candidate归因遥测事件名 / Suggested UI 的待审条目名与 WorkstreamTask Agent 的会话续接都是 UI/遥测词汇不是数据模型。服务端唯一模型就是staged_tasks无需决策。Mac 侧提取管线参数移植时要逐字继承白名单应用 10 分钟定时器 上下文切换触发模型gemini-2.5-flashdefaultMinConfidence 0.75工具循环恰好 8 次迭代5 个工具search_similar / search_keywords / no_task_found / extract_task / reject_task首迭代强制工具调用。Windows 存量 bug 已修审计文档描述的 Tasks 页 300 条上限/永不刷新问题已被 commitd750654修复分页TASKS_PAGE_SIZE 100跟随has_more且窗口focus事件触发重取状态文档因此标注 no work needed。六、Ground-truth 证据深读二Goals —— 以后端契约为唯一权威gt-goals.md 是不要照抄 Mac的教科书式案例。状态文档压缩为GoalUpdate accepts only {title,target_value,current_value,min_value,max_value,unit}; NO completion route; complete PATCH /{id}/progress?current_valuetarget (Windows already correct; Mac completeGoal/getCompletedGoals are 400/404-broken — do NOT port).完整证据链路由全集见 backend/routers/goals.pyGoalUpdatePydantic 模型只有 6 个字段title / target_value / current_value / min_value / max_value / unit没有is_active / completed_at / status。Pydantic v2 默认extraignore未知键在解析阶段被静默丢弃路由侧再对空update_data抛 400 No updates provided。由此推出 Mac 的两个活体故障completeGoal()发送{is_active, completed_at}→ 解析后 update 为空 →400getCompletedGoals()请求GET /v1/goals/completed→ 该路由不存在 →404。Mac 的GoalsAIService.fetchRichContext()与GoalGenerationService.removeStaleGoals()都依赖这两个调用错误被 catch 后仅记日志——这不是假设是 Mac 对活后端的实际行为。正确的完成姿势PATCH /v1/goals/{id}/progress?current_valuetarget把进度推到目标值客户端以current_value target_value推导完成——这正是 WindowsGoals.tsx今天的行为且toggleComplete()的注释已独立验证了同样结论与接线审计 C10 发现一致。零成本富能力闲置GET /v1/goals/{goal_id}/advice实际是混合检索实现向量检索 k10 近 7 天会话 近期聊天消息 记忆四段上下文拼 prompt 走专用goals_advice模型档比 Mac 本地getGoalInsight更丰富但 Windows 生成的类型化客户端绑定零调用点Goals.tsx也没有 advice UI——纯 UI 接线缺口。GET /v1/goals/suggest零请求体uid 之外无参数后端取 100 条记忆、截断到前 20 条进 prompt无会话/任务/persona/历史目标上下文因此可能建议出重复目标。UI 规格部分值得移植的视觉细节emoji 图标是对goal.title做约 30 个关键词桶的顺序子串匹配默认进度条是离散阈值色而非渐变≥0.8 绿#22C55E/ ≥0.6 青柠#84CC16/ ≥0.4 黄#FBBF24/ ≥0.4 橙#F97316/ 其余灰完成庆祝为 4 阶段约 3.3–3.5s 动画暗幕 → 40 粒子 9 色纸屑 → 渐变标题文本 → 淡出。状态文档对 P9 的 Goals (G-C; emoji/gradient/confetti) 即指向这套规格其中 gradient 指庆祝标题的文本渐变进度条本身是离散色。七、Ground-truth 证据深读三Focus 助手与 Glow 边框gt-focus-glow.md 给出了 P3 的完整移植规格状态文档将其浓缩为一条高密度记录Focus rides shared 3s capture timer (×3 battery). gemini-2.5-flash via proxy /v1/proxy/gemini/models/{model}:generateContent thinkingBudget 0. Notify only on state transitions; freq 0-5 (0 off/1 60m/2 30m/3 10m/4 3m/5 none), bar-only.7.1 分析门控与节流Focus不自建截图循环挂在共享 Rewind 采集定时上默认 3 秒/帧电池下乘batteryCaptureIntervalMultiplier 3.0变 9 秒×3 battery 的来源。每帧先过shouldSkipAnalysis门控再决定是否调 Gemini顺序为错误指数退避min(5.0×2^(n-1), 300s)→ 冷启动必分析 →上下文切换应用或归一化窗口标题变化绕过冷却必分析→ 分心后 10 分钟冷却 → 已 focused 且同上下文则跳过。登录/锁屏loginwindow/ScreenSaverEngine与隐私排除应用硬跳过。并发受maxPendingTasks 3背压限制陈旧帧结果旧帧响应晚于新帧返回按 frame number 丢弃。模型gemini-2.5-flashpremium 档thinkingBudget: 0走桌面后端代理/v1/proxy/gemini/models/{model}:generateContent设备上不出现裸 Gemini key瞬时错误重试 2 次共 3 次backoff 2s/8s。JSON 响应 schema 严格status: focused|distracted、app_or_site、description必填message可选——没有 neutral/idle 态。系统 prompt 是版本化产品文案v2bump 版本即清空用户自定义关键规则只判主窗口反幻觉终端里出现 YouTube 字样不等于在刷 YouTube、When in doubt, lean toward distracted、coaching message 限 100 字符。7.2 通知频控表P2 框架要逐字移植频率档含义最小发送间隔0Off默认主动通知 opt-in∞全部丢弃1Minimal60 分钟2Low30 分钟3Balanced10 分钟4High3 分钟5Maximum无节流叠加规则只在状态跳变时发通知lastNotifiedState去重防 3 个并发在途分析重复发仅浮层条floating-bar投递Focus 从不用系统横幅声音显式.none。主开关是isEnabled AND notificationsEnabled——关通知等于完全停止屏幕分析不只是关横幅。7.3 会话模型、评分与 Glow 机制focus_sessions一行 一次分析结果不是带 start/end 的连续区间时长由相邻两行时间戳差值事后推导。表结构id, screenshotId(FK→screenshots, 级联删除), status, appOrSite, description, message, durationSeconds, backendId, backendSynced, createdAt, windowTitle索引在createdAt/status/screenshotId/backendSynced。双写每条会话同时写入统一memories表category:systemtags[focus, focused|distracted, app:{appOrSite}]并通过通用createMemory同步后端——不存在专用/v1/focus/*后端 APIFocusStorage里的FocusStatsResponse等结构体是死代码grep 无调用点。日分公式focusRate focusedMinutes/(focusedMinutesdistractedMinutes)*100总为 0 时记 0这是唯一的每日分数不是积分制。Glow 4 个独立贴边窗口上下左右而非整屏单窗borderless、透明、ignoresMouseEvents全穿透、窗口层级等同.popUpMenu、跨 Space 常驻外扩 20pt、内缩 4pt自动 3.5s 消失新触发立即顶替旧窗口。颜色不是固定 hex.focused基色相 0.38绿动画区间 0.33–0.45.distracted基色相 0.0红0.95–1.05 回绕macOS 15 用 3×3MeshGradient网格中心点 sin/cos 抖动 双层 blur 合成低版本退回 7 段AngularGradient动画 0.3s 淡入 1.5s easeInOut 脉冲 ×3 往返 0.5s 淡出。触发矩阵分心跳变 → 红光从分心回到专注才触发绿光冷启动的 focused 结果不发光只落库。状态文档同时记录了 Windows 侧核查对Focus/focus_session/distracted/GlowBorder/GlowEdge/glowOverlay全仓 grep零命中0% 已移植而src/main/insight/interval 型 Insight toast与src/main/overlay/浮层条是相邻但不得混用的系统——前者可作为Windows 怎么做主动式 toast的参考样板后者的窗口被明确豁免不得复用。gt-focus-glow.md 末尾还给出 8 项 Electron 等价实现清单含transparent/frame:false/alwaysOnTop/setIgnoreMouseEvents(true)/skipTaskbar等窗口参数与厚度/动画时序的逐条对齐是 P3 的直接施工单。八、Ground-truth 证据深读四连续记忆抽取与 Embeddingsgt-memextract-embeddings.md 支撑 P5 的三项设计状态文档原句source-namespace key, count-guard, RAW-row pagerMemoryAssistant 流水线newest-1 帧缓冲新帧覆盖pendingFrame只发信号不内联分析extractionInterval默认 600sisEnabled AND notificationsEnabled双门关通知 不发起 Gemini vision 调用prompt 内嵌最近 20 条已抽记忆做自去重响应 schema 严格has_new_memory / memories[content≤15词, category∈system|interesting, source_app, confidence] / context_summary / current_activity全 required最多取 1 条memories.firstschema 名义允许 3 条但下游硬截 1confidence ≥ 0.7门槛低于即丢弃空结果是正常预期prompt 明言 DEFAULT TO EMPTY LIST。落库顺序本地 SQLite 先行 →createMemory同步后端 →markSynced回写 backend id → 通知/埋点。EmbeddingService3072 维、L2 归一化后存储搜索时点积即余弦走代理:embedContent/:batchEmbedContents批 ≤100内存索引上限5000条约 60MB只索引action_items staged_tasks两张表记忆表无向量索引线性全扫 topK默认 10无 ANN。两个必须复刻的 bug fix状态文档点名 composite key {source,id} 与 guard embeddings.counttexts.countsource-namespace 复合键action_items与staged_tasks是自增 rowid 各自从 1 起的两张表用裸Int64做索引键会在低 id 区间静默撞键改为TaskEmbeddingKey{source, id}搜索返回(source, id, similarity)三元组以便确定性地回查正确表。这正是 P0 新建task_embeddings表采用(source, item_id)复合主键的原因。批量计数守卫Gemini 按请求顺序 1:1 返回嵌入调用方按位置 zip 回原文任何一条缺失/多余都会让后续所有嵌入静默错位。因此guard embeddings.count texts.count else throw而不是 compactMap 后继续。RAW-row 分页规则pagerMacMemoriesPage用两个独立游标——currentOffset本地缓存/展示游标按过滤后可见数推进与rawBackendOffset后端原始页游标按服务器实际返回的原始行数推进。两者混用的后果是对称的按过滤数推原始游标 → 重复请求同一原始页导致重复反向推则跳页。软删除还要分别回退两个游标本地行先消失后端行在 undo 窗口后才真正删除。Windows 真实缺口定位memoriesBulk.ts的fetchAllMemories()已正确实现原始偏移推进100k 上限 Map 去重真正的 bug在 useMemories.tsfetchMemories文档定位在 43–58 行——单次GET /v3/memories?limit500offset0后从不请求第二页后端在 offset0 时强制返回至多 5000 条Memories 页对 5000 记忆的账户永远看不到尾部且页面另以RENDER_CAP 400二次截断。状态文档据此把 P5 的修复范围收窄为my file内的一处分页改造。九、Ground-truth 证据深读五统一连接器——Windows 反超 Mac 的领域gt-connectors.md 得出状态文档里一句罕见的正向判断Mac Gmail/Cal cookie-scrape hack;Windows AHEAD: real Google OAuth2 PKCE REST already built → EXTEND, dont port Mac.Mac 的 Gmail 读取是解密用户浏览器 cookieChrome/Arc/Brave/Edge 全 profile后抓 Gmail 内部未公开表面首页嵌入 JS 数据 blob20 天前的走 13 路 legacy Atom feed 合并Calendar 则用SAPISIDHASH派生鉴权打clients6.google.com的未公开认证端点。Windows 已有特性开关VITE_ENABLE_GOOGLE_INTEGRATION后默认关闭真正的 OAuth 2.0 PKCE loopback 流src/main/integrations/oauth.ts Gmail REST 只读google.tsformatmetadatanewer_than:7d25 条 增量同步态syncState.ts。结论是扩展现有路径而非移植 cookie 抓取。导入写路径双路必实现POST v3/memory-imports/batch每批 ≤100 条、自动分块、429/5xx/网络错误按 2s/5s/10s 重试每批打importRunId desktop-source-uuid与clientDeviceId溯源当该端点 404 或返回403 memory_import_requires_canonical时回退到POST v3/memories/batch旧端点同样 ≤100/批。合成阶段一次 claude-haiku 调用从原始证据提炼约 10–15 条记忆 2–5 条任务。X 连接器后端中介 OAuth2 PKCEGET /v1/x/oauth-url?success_redirect_url起跳 → 后端/v2/integrations/x/callback换 token 并后台首同步 → 客户端轮询GET /v1/x/connection-status阶段一 2s×60 次等connected阶段二 2s×90 次等syncingfalse→ 辅助路由POST /v1/x/sync、POST /v1/x/disconnect、GET /v1/x/posts。记忆提炼全在后端桌面只读计数。MCP服务端 URL{base}v1/mcp/sse铸造POST /v1/mcp/keysbody{name}→{key}按用户缓存、切账号失效、并发铸造按 owner 去重连通性实测 对mcpServerURL发一条 JSON-RPCtools/callget_memories, limit:5。本地编码代理 CLI 写入器幂等、先检测工具是否安装路径逐字移植、~换 Windows homeClaude Code 写~/.claude.json的mcpServers.omi-memoryhttp Bearer写前备份至~/.claude/backups/Codex 直接跑codex mcp add omi-memory -- npx -y mcp-remote url --header Authorization: Bearer keyOpenClaw 写~/.openclaw/openclaw.jsonSOUL.md标记块Hermes 手工拼~/.hermes/config.yaml的mcp_servers段不用 YAML 库。ChatGPT/Claude 走公开 PKCEclient idomi-chatgpt-prod/omi-claude-prod无 secretUI 只展示 URL clientId 由对方产品页驱动握手Notion 仅 memory-pack剪贴板 Markdown 本地备份 浏览器打开无后端推送。共享运行态ConnectorImportRunner形态Phase{running,succeeded,failed}RunState 按 connector id 全局键控 runToken使陈旧进度更新失效 acknowledgeSuccess要 1:1 移植为三个入口Memories 页 / onboarding / Apps hub共享的 run-state store保证从任一口启动的导入在其它口显示同一状态而非并发第二个 run。平台识别佐证windows是服务端认可的取值database/users.py平台族映射windows:desktop、utils/subscription.py的DESKTOP_PLATFORMS{macos,windows}而导入/导出/MCP 路由本身不分支平台——服务端门控风险为零。十、屏幕数据缝screen feed与 P2 框架的架构裁决gt-screenfeed 的返回状态文档标注 KEY UNBLOCK定义了 P2/P3 的地基其核心是只读缝read-only seam 主进程驻留两条架构约束只读采集缝已导出、零 Track-4 编辑即可复用latestRewindFrame()、listRewindFrames()、getCurrentScreen()主进程侧OCR 文本约 1s 新鲜度活跃窗口走main/usage/nativeForeground.tskoffi/user32的事件驱动subscribeForegroundChange()SetWinEventHook——已建好但未使用正好可供上下文切换检测复用。无 新帧 推送事件因此 Track 3 按自己的节奏轮询latestRewindFrame()并对 id 做差分而不是要求采集侧改造这是跨轨道边界的纪律P2 框架对 Track-4 拥有代码的改动为零。架构裁决tentative原文 ARCH DECISIONcoordinator 与 Focus/Memory/Task 各助手统一放在main/assistants/**——因为 JPEG 缓冲、原生前台钩子、SQLite 全在主进程助手轮询只读缝即可后续由 profilecoordinator 与 insight 提取器的细节定稿。P1 的 renderer 驱动调度、main 提供能力 与这一裁决互为表里主进程持有重型状态renderer 只拿 token 与触发时机。既有的 insight 引擎renderer/src/lib/insightEngine.ts15 分钟轮询、纯文本无 vision在 P4 升级为两阶段 SQLvisionmain/insight/**仅做展示——这条区分也防止了与既有 Insight toast 系统的混淆。页面表层gt-pages-ui支撑 P8/P9的要点同样收进状态文档Memories 页头部搜索 Default/ST/LT/Archive 层切换[服务端档位门控] This device 开关 类别 批量菜单、详情 sheet 450×600、undo 倒计时胶囊 toast、BrainGraph 以 props 方式挂载组装动画 800 次主线程外物理 tick 3s 沉降图签名未变则跳过动画Tasks 对齐 Mac 的 4 桶分组Today 折叠逾期 / Tomorrow / Later / No-DeadlineWindows 现 5 桶需收敛 顶部建议任务条Goals 因 Mac 无路由化 Goals 页dashboard 小组件 max 4 历史页 庆祝P9 只做轻量历史/详情面对应门控 G-CHome 新增WhatMattersNowSectionFocusedGoalsSection并删除QuickTaskWidget/QuickGoalsWidget紫色仅用于主 CTA 与 New/AI 徽标。另有一条跨轨道旗标pages-UI 代理报告--accent: #5b02e0紫色疑似泄漏与设计 token 计划INV-UI-1冲突Track 5 所有Track 3 不碰 globals.css。十一、决策日志、门控与挂起问题状态文档的 Decisions log / Gate notes / Parked questions 三节展示了门控驱动的推进纪律Q1 / cherry-picka4c50bcb4→ REVISED to HOLD该提交主体是对话/收听链路的设备溯源backendsync.py/transcribe.py/merge_conversations.py 已定稿的 Windows 文件其中只有lib/clientDevice.ts自包含的每安装设备 id 原语与 Track 3 相关且无冲突。即便如此也先 HOLD——直到记忆 ground-truth 确认后端/v3/memories契约确实携带每设备溯源字段否则 This device 过滤器是死 UI、clientDevice.ts是死代码。这是先验证契约再落地原语的范例。G-A — 以证据消解而非决议见第五节唯一模型staged_tasksnothing to decide保留在挂起清单中仅作记录。G-CGoals 导航位置Mac 无顶层 Goals 导航dashboard 小组件 历史页 庆祝建议 Windows 对齐为 Home 的FocusedGoalsSection 轻量历史/详情面不加顶层导航项最终裁决挂起。G-DTasks 富多组过滤器按 plan 跳过但 5→4 桶分组属于 IA信息架构对齐而非过滤器仍要做。M2跨轨道平台决策AGENTS.md的 fallback 遥测只定义了 Python/Swift/Rust 的 emitterdesktop/windows/src中不存在recordFallback因此带 fail-open 分支的 Windows 特性Track 3 profile 降级、Track 2 语音、sync、auth、listen目前无法机械满足禁止静默运维规则。二选一留给决策人(i) 建最小 TS/Electron fallback emitter 作为 Windows 共享基础设施或 (ii) 对 Electron 面做范围化豁免。P1 期间的临时措施非静默的结构化 warn TODO。状态文档明确 Not a Track-3-owned decision——挂起但不阻塞。十二、方法论小结这份状态文档给出的可复用工程模式把_TRACK3-STATUS.md与它引用的 00-INDEX.md 合起来读可以提炼出 Omi 仓库在跨平台对等移植上沉淀的一套可复用手法冻结参考 源码核验Mac 基准钉在 tagv0.12.7212072-macoscommit50d264c9的独立 worktree每份 gt-*.md 都声明 Verified directly against source (not doc summaries)并逐一列出读过的 Swift/TS/Python 文件——任何 Absent/Partial 结论都要落到具体文件检查。门控由证据消解G-A 这类需要拍板的问题最终用 grep 全后端树 模型路由清点证明没有可决策的分歧直接消解G-C/G-D/M2/Q1 则明确挂起且标注归属绝不阻塞主线推进。增量式 schema 漂移守卫净新表走CREATE TABLE IF NOT EXISTS、不占迁移版本号跨轨道表级守卫sign-out 清理完整性在 P0 就上线并真实抓到了 Track 2 的voice_turn_outbox泄漏。以后端契约为唯一权威Goals 案例证明对齐不等于照抄 Mac——Mac 的completeGoal/getCompletedGoals对活后端就是 400/404Windows 的正确行为progress 推到 target反成移植基准反之在连接器上 Windows 的 OAuth 路径反超 Mac策略变为 EXTEND, dont port Mac。跨轨道边界用只读缝表达助手框架轮询 Track-4 导出的只读采集接口零侵入拥有方代码平台级问题M2显式上交而非擅自决定。状态文档本身是工件进度勾选、PR 号、merge commit、失败与重生记录、审计修复项M1/m3/m4…全部落在同一文件使任何后来者人或 Agent都能从单一入口还原整条轨道的决策上下文。最后需要提示读者该状态文档是 2026-07 中旬的会话快照。仓库已演进——00-INDEX.md 的 2026-08-22 重核确认本轨道的大部分助手能力已合入且 2026-09-03 的仓库级死代码清理删除了这些 dated audit 所引用的若干文件如focus/stats.ts、main/ipc/ocr.ts、insight 辅助文件等。按索引的说明凡是 audit 声称已写好并单测的文件若出现在删除名单里应视为已删除而非待办——阅读本系列文档时以该注意为准。延伸阅读均在本仓库内轨道状态主体desktop/windows/docs/mac-parity-audit/track3-ground-truth/_TRACK3-STATUS.mdGround-truth 各篇gt-tasks.md、gt-goals.md、gt-focus-glow.md、gt-memextract-embeddings.md、gt-connectors.md后端契约源staged_tasks 路由、goals 路由、StagedTask 模型整体审计索引00-INDEX.md【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Omi 桌面端 Mac→Windows 对等移植：Track 3「主动智能与记忆」的状态文档解读与 P0–P9 阶段规划
Omi 桌面端 Mac→Windows 对等移植Track 3「主动智能与记忆」的状态文档解读与 P0–P9 阶段规划【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend本文以 Omi 仓库desktop/windows/docs/mac-parity-audit/track3-ground-truth/下的编排器状态文档_TRACK3-STATUS.md为主体完整拆解 Windows 版 Omi 桌面端「主动智能与记忆」移植轨道Track 3的 P0–P9 阶段计划、九份 ground-truth 证据的关键结论staged-tasks 契约、Goals 后端真相、Focus/Glow 机制、记忆抽取与嵌入、连接器以及门控决策与挂起问题的处理方式。读完本文你可以掌握一条可复用的跨平台功能对等parity移植方法论如何用冻结参考分支、源码级证据核验与增量式additive数据库 schema驱动一个长周期、可无人值守推进的多阶段工程。一、这份状态文档是什么长周期无人值守会话的单一事实源_TRACK3-STATUS.md的开头定义了自己的定位Orchestrator status doc. Single source of truth for phase progress, decisions, and parked questions across this (long, unattended) session. Update as items complete.编排器状态文档是本次长周期、无人值守会话中阶段进度、决策与挂起问题的单一事实源随事项完成持续更新。它同时钉住了整条轨道的工程环境坐标原文逐条给出项值工作分支feat/win-proactiveworktree 位于.worktrees/track3-proactive已推送到 origin沙箱端口renderer5223CDP9329沙箱 profileomi-windows-sandbox-track3-proactiveMac 参考冻结 ground truth.worktrees/mac-ref tagv0.12.7212072-macoscommit50d264c9「冻结参考」是这个工作流的核心手法之一把 Mac 端代码钉死在特定 tag/commit 上作为基准所有 ground-truth 提取器extractor都对着这份冻结源码逐行核验而不是对着文档摘要转述。文档还说明了 P0 阶段的一个实战细节初始 spawn 的提取器中 coordinator 与 insight 两个因挂起被换窄narrower后重生extractors done (coordinatorinsight respawned narrower after hanging)体现了编排器对子任务超时的处置方式。二、P0–P9按依赖顺序排布的阶段路线图状态文档的 Phase plan (dependency order) 一节列出了整条轨道的完整路线图与当时状态。这是理解 Track 3 全局的主骨架阶段内容状态该快照时点P0 Ground truth源码级事实提取✅ 完成P0 增量式 schema PR3 张新表 CRUD 漂移守卫✅ 已合并PR #32mergec3b01ecP1 AI User Profile用户画像合成✅ 已合并PR #42渲染层自动触发接线推迟到 P2P2 AssistantCoordinator框架层节流、上下文切换检测、背压⬜ 未开始P3 Focus assistant glow overlay专注助手与发光边框⬜ 未开始P4 Insight assistant 深度两阶段 SQLvision、backend-sync 作为记忆、历史 UI⬜ 未开始P5 连续记忆抽取 embeddingssource-namespace 键、count-guard、RAW-row 分页器⬜ 未开始P5b 屏幕任务抽取受门控 G-A 约束⬜ 未开始P6 自动每日目标生成 advice目标完成走后端契约C10Mac wrongGoals 导航受 G-C 约束⬜ 未开始P7 统一连接器三个入口Memories 页 / onboarding / Apps hub发布同一能力⬜ 未开始P8 Home widgetsWhatMattersNowSectionFocusedGoalsSection删除 legacyQuickTask/QuickGoals⬜ 未开始P9 页面表层对齐 Mac 规格Memories / Tasks / Goals 三页⬜ 未开始两个值得注意的「纠偏」措辞直接写在路线图里P6 标注 goal-completion uses BACKEND contract (C10, Mac wrong)——即 Mac 端的目标完成实现相对后端契约是错的移植时以服务端契约为准而不是照抄 Mac这一点在下方 Goals ground truth 中有完整证据。P9 标注 Tasks (grouped-by-due; NOT rich multi-filter G-D)——Mac 的富多组过滤器 UI 被明确排除仅对齐分组方式。需要说明时间线该状态文档是 Track 3 会话进行中2026-07-14 前后的活快照后续整体重写的对等审计索引 00-INDEX.md 在 2026-08-22 重新核验后记录coordinator 与 Focus/Insight/Memory/Task/Goal 各助手实际已于 2026-07-14 至 07-19 间陆续合入 Windows 端。也就是说本文描述的是这条轨道从证据到计划、再到前两个 PR 落地的完整决策过程而 P2 之后的阶段在快照之后数日内被逐步兑现。三、P0Ground truth 与增量式 schema PR3.1 增量式建表模式无需迁移条目gt-windows-inventory 的返回结论定义了 Windows 端db.ts的新表模式状态文档原样继承新表通过CREATE TABLE IF NOT EXISTS写在 bootstrap 中镜像现有insights表 INSIGHT_COLUMNSrecentInsights的写法dbMigrations的MIGRATIONS数组只有一条v1净新增表不需要迁移条目避免版本号争用渲染层两种既有数据模式A 本地 SQLite 经 IPC 访问window.omi.X→ ipc →db.tsB renderer 直接 axios 打后端memories/goals/tasks 现状无本地表。3.2 P0 PR 的落地结果状态文档记录 P0 增量式 schema PR 由 Opus agentafe2c9b实现、独立 Opusaaa3be8审计后合并3 张净新增表均为CREATE TABLE IF NOT EXISTS无迁移条目ai_user_profiles、focus_sessions、task_embeddings后者采用复合主键(source, item_id)对应 Mac 端的一处 bug fix详见第六节配套db.ts中 14 个 CRUD 函数 taskEmbeddingVector.tsshared/types.ts记录类型 dbTrack3.test.ts9 个测试助手设置不落 SQLite复用 Windows 现有 settings store验证typecheck 干净、全量套件 1484 pass15 skip、eslint 干净真机启动real-app-boot验证 3 张表确实被创建。3.3 漂移守卫drift-guard抓到的真实泄漏P0 中最有价值的一条记录是漂移守卫的实战收益Drift-guard caughtfixed a real Track-2 leak (voice_turn_outbox missing from sign-out wipe) and exempted Track-4 app_meta. 即守卫发现voice_turn_outbox表漏在 sign-out 清理逻辑之外属于另一条轨道 Track 2 的表顺手修复同时对 Track 4 拥有的app_meta表做了豁免。这说明该守卫不是只服务于本轨道而是覆盖全库表级不变量的跨轨道防线。四、P1AI User Profile 的架构决策状态文档对 P1 的标注信息密度很高是「渲染层/主进程职责划分」的一次典型裁决实现形态main/assistants/aiUserProfile/{synthesis,service} IPC 设置开关 增量式类型/preload 绑定。synthesis 逻辑为纯函数且有测试采用两阶段2-stage合成输出字符上限 10000prompt 要求 2000data_sources_used取总条目数与 Mac 口径一致。后端契约GET/PATCH /v1/users/ai-profile无平台分支platform-agnostic。在线冒烟真实 backend LLM 跑通产出连贯画像data_sources_used66。架构裁决原文 ARCHservice 是主进程侧能力而渲染层持有 Firebase token因此「调度/会话推送由 renderer 驱动」——自动触发接线auto-trigger wiring随 P2 的 renderer 主动式框架一起落地当前先用手动generateNow(session)演练。审计修复清单Opus 审计后给出修复项 M1编辑路径 count 损坏、m3service 错误路径测试、m4401 与无数据的区分、m6/m7/m8。五、Ground-truth 证据深读一Tasks 与 staged_tasks 契约gt-tasks.md 是门控 G-A 的「证据消解」现场状态文档以 G-A DISSOLVED 一句话收编了其结论服务端只有一个任务暂存模型staged_tasks。路由层在 backend/routers/staged_tasks.pyPOST/GET/DELETE /v1/staged-tasks、PATCH /v1/staged-tasks/batch-scores、POST /v1/staged-tasks/promote、POST /v1/staged-tasks/{id}/promote、POST /v1/staged-tasks/migrate模型定义见 backend/models/staged_task.py字段为id / description / completed / due_at / source / priority / metadata / category / relevance_score(0-1000)。Promote 不是机械搬运promote_staged_task在创建action_item前用get_active_action_item_by_description大小写不敏感、剥离[screen]标记后归一化做去重守卫命中则把due_at/priority/category等富化字段合并进已有条目并标记completedTrue, promotion_skippedduplicate, promoted_toexisting_id。平台无关对routers/staged_tasks.py与database/staged_tasks.pygrepX-App-Platform/platform零命中——Windows 客户端可直接消费无服务端门控风险。G-A 消解的推理任务前提Mac 正在服务端向 Candidate/workstream 模型迁移与源码不符——全backend/树中Candidate|Workstream的约 50 处命中全部属于记忆域等无关子系统客户端里的 Candidate归因遥测事件名 / Suggested UI 的待审条目名与 WorkstreamTask Agent 的会话续接都是 UI/遥测词汇不是数据模型。服务端唯一模型就是staged_tasks无需决策。Mac 侧提取管线参数移植时要逐字继承白名单应用 10 分钟定时器 上下文切换触发模型gemini-2.5-flashdefaultMinConfidence 0.75工具循环恰好 8 次迭代5 个工具search_similar / search_keywords / no_task_found / extract_task / reject_task首迭代强制工具调用。Windows 存量 bug 已修审计文档描述的 Tasks 页 300 条上限/永不刷新问题已被 commitd750654修复分页TASKS_PAGE_SIZE 100跟随has_more且窗口focus事件触发重取状态文档因此标注 no work needed。六、Ground-truth 证据深读二Goals —— 以后端契约为唯一权威gt-goals.md 是不要照抄 Mac的教科书式案例。状态文档压缩为GoalUpdate accepts only {title,target_value,current_value,min_value,max_value,unit}; NO completion route; complete PATCH /{id}/progress?current_valuetarget (Windows already correct; Mac completeGoal/getCompletedGoals are 400/404-broken — do NOT port).完整证据链路由全集见 backend/routers/goals.pyGoalUpdatePydantic 模型只有 6 个字段title / target_value / current_value / min_value / max_value / unit没有is_active / completed_at / status。Pydantic v2 默认extraignore未知键在解析阶段被静默丢弃路由侧再对空update_data抛 400 No updates provided。由此推出 Mac 的两个活体故障completeGoal()发送{is_active, completed_at}→ 解析后 update 为空 →400getCompletedGoals()请求GET /v1/goals/completed→ 该路由不存在 →404。Mac 的GoalsAIService.fetchRichContext()与GoalGenerationService.removeStaleGoals()都依赖这两个调用错误被 catch 后仅记日志——这不是假设是 Mac 对活后端的实际行为。正确的完成姿势PATCH /v1/goals/{id}/progress?current_valuetarget把进度推到目标值客户端以current_value target_value推导完成——这正是 WindowsGoals.tsx今天的行为且toggleComplete()的注释已独立验证了同样结论与接线审计 C10 发现一致。零成本富能力闲置GET /v1/goals/{goal_id}/advice实际是混合检索实现向量检索 k10 近 7 天会话 近期聊天消息 记忆四段上下文拼 prompt 走专用goals_advice模型档比 Mac 本地getGoalInsight更丰富但 Windows 生成的类型化客户端绑定零调用点Goals.tsx也没有 advice UI——纯 UI 接线缺口。GET /v1/goals/suggest零请求体uid 之外无参数后端取 100 条记忆、截断到前 20 条进 prompt无会话/任务/persona/历史目标上下文因此可能建议出重复目标。UI 规格部分值得移植的视觉细节emoji 图标是对goal.title做约 30 个关键词桶的顺序子串匹配默认进度条是离散阈值色而非渐变≥0.8 绿#22C55E/ ≥0.6 青柠#84CC16/ ≥0.4 黄#FBBF24/ ≥0.4 橙#F97316/ 其余灰完成庆祝为 4 阶段约 3.3–3.5s 动画暗幕 → 40 粒子 9 色纸屑 → 渐变标题文本 → 淡出。状态文档对 P9 的 Goals (G-C; emoji/gradient/confetti) 即指向这套规格其中 gradient 指庆祝标题的文本渐变进度条本身是离散色。七、Ground-truth 证据深读三Focus 助手与 Glow 边框gt-focus-glow.md 给出了 P3 的完整移植规格状态文档将其浓缩为一条高密度记录Focus rides shared 3s capture timer (×3 battery). gemini-2.5-flash via proxy /v1/proxy/gemini/models/{model}:generateContent thinkingBudget 0. Notify only on state transitions; freq 0-5 (0 off/1 60m/2 30m/3 10m/4 3m/5 none), bar-only.7.1 分析门控与节流Focus不自建截图循环挂在共享 Rewind 采集定时上默认 3 秒/帧电池下乘batteryCaptureIntervalMultiplier 3.0变 9 秒×3 battery 的来源。每帧先过shouldSkipAnalysis门控再决定是否调 Gemini顺序为错误指数退避min(5.0×2^(n-1), 300s)→ 冷启动必分析 →上下文切换应用或归一化窗口标题变化绕过冷却必分析→ 分心后 10 分钟冷却 → 已 focused 且同上下文则跳过。登录/锁屏loginwindow/ScreenSaverEngine与隐私排除应用硬跳过。并发受maxPendingTasks 3背压限制陈旧帧结果旧帧响应晚于新帧返回按 frame number 丢弃。模型gemini-2.5-flashpremium 档thinkingBudget: 0走桌面后端代理/v1/proxy/gemini/models/{model}:generateContent设备上不出现裸 Gemini key瞬时错误重试 2 次共 3 次backoff 2s/8s。JSON 响应 schema 严格status: focused|distracted、app_or_site、description必填message可选——没有 neutral/idle 态。系统 prompt 是版本化产品文案v2bump 版本即清空用户自定义关键规则只判主窗口反幻觉终端里出现 YouTube 字样不等于在刷 YouTube、When in doubt, lean toward distracted、coaching message 限 100 字符。7.2 通知频控表P2 框架要逐字移植频率档含义最小发送间隔0Off默认主动通知 opt-in∞全部丢弃1Minimal60 分钟2Low30 分钟3Balanced10 分钟4High3 分钟5Maximum无节流叠加规则只在状态跳变时发通知lastNotifiedState去重防 3 个并发在途分析重复发仅浮层条floating-bar投递Focus 从不用系统横幅声音显式.none。主开关是isEnabled AND notificationsEnabled——关通知等于完全停止屏幕分析不只是关横幅。7.3 会话模型、评分与 Glow 机制focus_sessions一行 一次分析结果不是带 start/end 的连续区间时长由相邻两行时间戳差值事后推导。表结构id, screenshotId(FK→screenshots, 级联删除), status, appOrSite, description, message, durationSeconds, backendId, backendSynced, createdAt, windowTitle索引在createdAt/status/screenshotId/backendSynced。双写每条会话同时写入统一memories表category:systemtags[focus, focused|distracted, app:{appOrSite}]并通过通用createMemory同步后端——不存在专用/v1/focus/*后端 APIFocusStorage里的FocusStatsResponse等结构体是死代码grep 无调用点。日分公式focusRate focusedMinutes/(focusedMinutesdistractedMinutes)*100总为 0 时记 0这是唯一的每日分数不是积分制。Glow 4 个独立贴边窗口上下左右而非整屏单窗borderless、透明、ignoresMouseEvents全穿透、窗口层级等同.popUpMenu、跨 Space 常驻外扩 20pt、内缩 4pt自动 3.5s 消失新触发立即顶替旧窗口。颜色不是固定 hex.focused基色相 0.38绿动画区间 0.33–0.45.distracted基色相 0.0红0.95–1.05 回绕macOS 15 用 3×3MeshGradient网格中心点 sin/cos 抖动 双层 blur 合成低版本退回 7 段AngularGradient动画 0.3s 淡入 1.5s easeInOut 脉冲 ×3 往返 0.5s 淡出。触发矩阵分心跳变 → 红光从分心回到专注才触发绿光冷启动的 focused 结果不发光只落库。状态文档同时记录了 Windows 侧核查对Focus/focus_session/distracted/GlowBorder/GlowEdge/glowOverlay全仓 grep零命中0% 已移植而src/main/insight/interval 型 Insight toast与src/main/overlay/浮层条是相邻但不得混用的系统——前者可作为Windows 怎么做主动式 toast的参考样板后者的窗口被明确豁免不得复用。gt-focus-glow.md 末尾还给出 8 项 Electron 等价实现清单含transparent/frame:false/alwaysOnTop/setIgnoreMouseEvents(true)/skipTaskbar等窗口参数与厚度/动画时序的逐条对齐是 P3 的直接施工单。八、Ground-truth 证据深读四连续记忆抽取与 Embeddingsgt-memextract-embeddings.md 支撑 P5 的三项设计状态文档原句source-namespace key, count-guard, RAW-row pagerMemoryAssistant 流水线newest-1 帧缓冲新帧覆盖pendingFrame只发信号不内联分析extractionInterval默认 600sisEnabled AND notificationsEnabled双门关通知 不发起 Gemini vision 调用prompt 内嵌最近 20 条已抽记忆做自去重响应 schema 严格has_new_memory / memories[content≤15词, category∈system|interesting, source_app, confidence] / context_summary / current_activity全 required最多取 1 条memories.firstschema 名义允许 3 条但下游硬截 1confidence ≥ 0.7门槛低于即丢弃空结果是正常预期prompt 明言 DEFAULT TO EMPTY LIST。落库顺序本地 SQLite 先行 →createMemory同步后端 →markSynced回写 backend id → 通知/埋点。EmbeddingService3072 维、L2 归一化后存储搜索时点积即余弦走代理:embedContent/:batchEmbedContents批 ≤100内存索引上限5000条约 60MB只索引action_items staged_tasks两张表记忆表无向量索引线性全扫 topK默认 10无 ANN。两个必须复刻的 bug fix状态文档点名 composite key {source,id} 与 guard embeddings.counttexts.countsource-namespace 复合键action_items与staged_tasks是自增 rowid 各自从 1 起的两张表用裸Int64做索引键会在低 id 区间静默撞键改为TaskEmbeddingKey{source, id}搜索返回(source, id, similarity)三元组以便确定性地回查正确表。这正是 P0 新建task_embeddings表采用(source, item_id)复合主键的原因。批量计数守卫Gemini 按请求顺序 1:1 返回嵌入调用方按位置 zip 回原文任何一条缺失/多余都会让后续所有嵌入静默错位。因此guard embeddings.count texts.count else throw而不是 compactMap 后继续。RAW-row 分页规则pagerMacMemoriesPage用两个独立游标——currentOffset本地缓存/展示游标按过滤后可见数推进与rawBackendOffset后端原始页游标按服务器实际返回的原始行数推进。两者混用的后果是对称的按过滤数推原始游标 → 重复请求同一原始页导致重复反向推则跳页。软删除还要分别回退两个游标本地行先消失后端行在 undo 窗口后才真正删除。Windows 真实缺口定位memoriesBulk.ts的fetchAllMemories()已正确实现原始偏移推进100k 上限 Map 去重真正的 bug在 useMemories.tsfetchMemories文档定位在 43–58 行——单次GET /v3/memories?limit500offset0后从不请求第二页后端在 offset0 时强制返回至多 5000 条Memories 页对 5000 记忆的账户永远看不到尾部且页面另以RENDER_CAP 400二次截断。状态文档据此把 P5 的修复范围收窄为my file内的一处分页改造。九、Ground-truth 证据深读五统一连接器——Windows 反超 Mac 的领域gt-connectors.md 得出状态文档里一句罕见的正向判断Mac Gmail/Cal cookie-scrape hack;Windows AHEAD: real Google OAuth2 PKCE REST already built → EXTEND, dont port Mac.Mac 的 Gmail 读取是解密用户浏览器 cookieChrome/Arc/Brave/Edge 全 profile后抓 Gmail 内部未公开表面首页嵌入 JS 数据 blob20 天前的走 13 路 legacy Atom feed 合并Calendar 则用SAPISIDHASH派生鉴权打clients6.google.com的未公开认证端点。Windows 已有特性开关VITE_ENABLE_GOOGLE_INTEGRATION后默认关闭真正的 OAuth 2.0 PKCE loopback 流src/main/integrations/oauth.ts Gmail REST 只读google.tsformatmetadatanewer_than:7d25 条 增量同步态syncState.ts。结论是扩展现有路径而非移植 cookie 抓取。导入写路径双路必实现POST v3/memory-imports/batch每批 ≤100 条、自动分块、429/5xx/网络错误按 2s/5s/10s 重试每批打importRunId desktop-source-uuid与clientDeviceId溯源当该端点 404 或返回403 memory_import_requires_canonical时回退到POST v3/memories/batch旧端点同样 ≤100/批。合成阶段一次 claude-haiku 调用从原始证据提炼约 10–15 条记忆 2–5 条任务。X 连接器后端中介 OAuth2 PKCEGET /v1/x/oauth-url?success_redirect_url起跳 → 后端/v2/integrations/x/callback换 token 并后台首同步 → 客户端轮询GET /v1/x/connection-status阶段一 2s×60 次等connected阶段二 2s×90 次等syncingfalse→ 辅助路由POST /v1/x/sync、POST /v1/x/disconnect、GET /v1/x/posts。记忆提炼全在后端桌面只读计数。MCP服务端 URL{base}v1/mcp/sse铸造POST /v1/mcp/keysbody{name}→{key}按用户缓存、切账号失效、并发铸造按 owner 去重连通性实测 对mcpServerURL发一条 JSON-RPCtools/callget_memories, limit:5。本地编码代理 CLI 写入器幂等、先检测工具是否安装路径逐字移植、~换 Windows homeClaude Code 写~/.claude.json的mcpServers.omi-memoryhttp Bearer写前备份至~/.claude/backups/Codex 直接跑codex mcp add omi-memory -- npx -y mcp-remote url --header Authorization: Bearer keyOpenClaw 写~/.openclaw/openclaw.jsonSOUL.md标记块Hermes 手工拼~/.hermes/config.yaml的mcp_servers段不用 YAML 库。ChatGPT/Claude 走公开 PKCEclient idomi-chatgpt-prod/omi-claude-prod无 secretUI 只展示 URL clientId 由对方产品页驱动握手Notion 仅 memory-pack剪贴板 Markdown 本地备份 浏览器打开无后端推送。共享运行态ConnectorImportRunner形态Phase{running,succeeded,failed}RunState 按 connector id 全局键控 runToken使陈旧进度更新失效 acknowledgeSuccess要 1:1 移植为三个入口Memories 页 / onboarding / Apps hub共享的 run-state store保证从任一口启动的导入在其它口显示同一状态而非并发第二个 run。平台识别佐证windows是服务端认可的取值database/users.py平台族映射windows:desktop、utils/subscription.py的DESKTOP_PLATFORMS{macos,windows}而导入/导出/MCP 路由本身不分支平台——服务端门控风险为零。十、屏幕数据缝screen feed与 P2 框架的架构裁决gt-screenfeed 的返回状态文档标注 KEY UNBLOCK定义了 P2/P3 的地基其核心是只读缝read-only seam 主进程驻留两条架构约束只读采集缝已导出、零 Track-4 编辑即可复用latestRewindFrame()、listRewindFrames()、getCurrentScreen()主进程侧OCR 文本约 1s 新鲜度活跃窗口走main/usage/nativeForeground.tskoffi/user32的事件驱动subscribeForegroundChange()SetWinEventHook——已建好但未使用正好可供上下文切换检测复用。无 新帧 推送事件因此 Track 3 按自己的节奏轮询latestRewindFrame()并对 id 做差分而不是要求采集侧改造这是跨轨道边界的纪律P2 框架对 Track-4 拥有代码的改动为零。架构裁决tentative原文 ARCH DECISIONcoordinator 与 Focus/Memory/Task 各助手统一放在main/assistants/**——因为 JPEG 缓冲、原生前台钩子、SQLite 全在主进程助手轮询只读缝即可后续由 profilecoordinator 与 insight 提取器的细节定稿。P1 的 renderer 驱动调度、main 提供能力 与这一裁决互为表里主进程持有重型状态renderer 只拿 token 与触发时机。既有的 insight 引擎renderer/src/lib/insightEngine.ts15 分钟轮询、纯文本无 vision在 P4 升级为两阶段 SQLvisionmain/insight/**仅做展示——这条区分也防止了与既有 Insight toast 系统的混淆。页面表层gt-pages-ui支撑 P8/P9的要点同样收进状态文档Memories 页头部搜索 Default/ST/LT/Archive 层切换[服务端档位门控] This device 开关 类别 批量菜单、详情 sheet 450×600、undo 倒计时胶囊 toast、BrainGraph 以 props 方式挂载组装动画 800 次主线程外物理 tick 3s 沉降图签名未变则跳过动画Tasks 对齐 Mac 的 4 桶分组Today 折叠逾期 / Tomorrow / Later / No-DeadlineWindows 现 5 桶需收敛 顶部建议任务条Goals 因 Mac 无路由化 Goals 页dashboard 小组件 max 4 历史页 庆祝P9 只做轻量历史/详情面对应门控 G-CHome 新增WhatMattersNowSectionFocusedGoalsSection并删除QuickTaskWidget/QuickGoalsWidget紫色仅用于主 CTA 与 New/AI 徽标。另有一条跨轨道旗标pages-UI 代理报告--accent: #5b02e0紫色疑似泄漏与设计 token 计划INV-UI-1冲突Track 5 所有Track 3 不碰 globals.css。十一、决策日志、门控与挂起问题状态文档的 Decisions log / Gate notes / Parked questions 三节展示了门控驱动的推进纪律Q1 / cherry-picka4c50bcb4→ REVISED to HOLD该提交主体是对话/收听链路的设备溯源backendsync.py/transcribe.py/merge_conversations.py 已定稿的 Windows 文件其中只有lib/clientDevice.ts自包含的每安装设备 id 原语与 Track 3 相关且无冲突。即便如此也先 HOLD——直到记忆 ground-truth 确认后端/v3/memories契约确实携带每设备溯源字段否则 This device 过滤器是死 UI、clientDevice.ts是死代码。这是先验证契约再落地原语的范例。G-A — 以证据消解而非决议见第五节唯一模型staged_tasksnothing to decide保留在挂起清单中仅作记录。G-CGoals 导航位置Mac 无顶层 Goals 导航dashboard 小组件 历史页 庆祝建议 Windows 对齐为 Home 的FocusedGoalsSection 轻量历史/详情面不加顶层导航项最终裁决挂起。G-DTasks 富多组过滤器按 plan 跳过但 5→4 桶分组属于 IA信息架构对齐而非过滤器仍要做。M2跨轨道平台决策AGENTS.md的 fallback 遥测只定义了 Python/Swift/Rust 的 emitterdesktop/windows/src中不存在recordFallback因此带 fail-open 分支的 Windows 特性Track 3 profile 降级、Track 2 语音、sync、auth、listen目前无法机械满足禁止静默运维规则。二选一留给决策人(i) 建最小 TS/Electron fallback emitter 作为 Windows 共享基础设施或 (ii) 对 Electron 面做范围化豁免。P1 期间的临时措施非静默的结构化 warn TODO。状态文档明确 Not a Track-3-owned decision——挂起但不阻塞。十二、方法论小结这份状态文档给出的可复用工程模式把_TRACK3-STATUS.md与它引用的 00-INDEX.md 合起来读可以提炼出 Omi 仓库在跨平台对等移植上沉淀的一套可复用手法冻结参考 源码核验Mac 基准钉在 tagv0.12.7212072-macoscommit50d264c9的独立 worktree每份 gt-*.md 都声明 Verified directly against source (not doc summaries)并逐一列出读过的 Swift/TS/Python 文件——任何 Absent/Partial 结论都要落到具体文件检查。门控由证据消解G-A 这类需要拍板的问题最终用 grep 全后端树 模型路由清点证明没有可决策的分歧直接消解G-C/G-D/M2/Q1 则明确挂起且标注归属绝不阻塞主线推进。增量式 schema 漂移守卫净新表走CREATE TABLE IF NOT EXISTS、不占迁移版本号跨轨道表级守卫sign-out 清理完整性在 P0 就上线并真实抓到了 Track 2 的voice_turn_outbox泄漏。以后端契约为唯一权威Goals 案例证明对齐不等于照抄 Mac——Mac 的completeGoal/getCompletedGoals对活后端就是 400/404Windows 的正确行为progress 推到 target反成移植基准反之在连接器上 Windows 的 OAuth 路径反超 Mac策略变为 EXTEND, dont port Mac。跨轨道边界用只读缝表达助手框架轮询 Track-4 导出的只读采集接口零侵入拥有方代码平台级问题M2显式上交而非擅自决定。状态文档本身是工件进度勾选、PR 号、merge commit、失败与重生记录、审计修复项M1/m3/m4…全部落在同一文件使任何后来者人或 Agent都能从单一入口还原整条轨道的决策上下文。最后需要提示读者该状态文档是 2026-07 中旬的会话快照。仓库已演进——00-INDEX.md 的 2026-08-22 重核确认本轨道的大部分助手能力已合入且 2026-09-03 的仓库级死代码清理删除了这些 dated audit 所引用的若干文件如focus/stats.ts、main/ipc/ocr.ts、insight 辅助文件等。按索引的说明凡是 audit 声称已写好并单测的文件若出现在删除名单里应视为已删除而非待办——阅读本系列文档时以该注意为准。延伸阅读均在本仓库内轨道状态主体desktop/windows/docs/mac-parity-audit/track3-ground-truth/_TRACK3-STATUS.mdGround-truth 各篇gt-tasks.md、gt-goals.md、gt-focus-glow.md、gt-memextract-embeddings.md、gt-connectors.md后端契约源staged_tasks 路由、goals 路由、StagedTask 模型整体审计索引00-INDEX.md【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考