GBrain 最新版调研与 55 结合方案

日期：2026-05-13
目的：调研 Garry Tan 开源 GBrain 的最新版原理、应用模式，并判断如何与 55 结合，把忠伟日常信息接入为“全知、全能”的个人高管助理。
资料边界：本次基于可验证资料整理：GitHub garrytan/gbrain README、docs、skills 文档，以及本地历史会话和既有《Agent记忆体系研究》。外网可访问 GitHub raw，但部分大文件下载出现 timeout，因此本文只引用已成功读取的资料，不把未读取内容当事实。
关键来源：README.md、docs/GBRAIN_RECOMMENDED_SCHEMA.md、docs/architecture/brains-and-sources.md、docs/architecture/system-of-record.md、docs/storage-tiering.md、skills/brain-ops、skills/query、skills/meeting-ingestion、skills/voice-note-ingest。

1. 结论先行

GBrain 不是普通知识库，而是“由 Agent 持续维护的个人/组织外部大脑”：用 Markdown 作为人可读的知识界面，用 PGLite/Postgres + 向量 + 图关系作为机器检索和推理层，用 Skills + 定时任务把会议、邮件、语音、网页、社交、联系人等信号自动摄取、抽取实体、建立关系、更新人物/项目/公司页面。

对 55 的最佳结合方式不是替换 55 工作区，而是采用三层架构：

GBrain：原始资料 + 长期知识资产 + 跨 Agent 记忆主库
55 工作区：高管助理执行台 + 当前事项 + 结构化摘要 + 决策上下文
Hermes Memory：极少量每次启动必须知道的核心事实

一句话：

GBrain 管“忠伟经历过什么、说过什么、见过谁、形成过什么判断”；55 管“现在应该做什么、如何推动闭环”；Hermes Memory 管“每次都必须立刻知道什么”。

如果忠伟的目标是让 55 变成“全知、全能”的助手，GBrain 应成为 55 的外部大脑主库；55 不应该把所有原始资料塞进工作区，否则工作区会变成噪音库。

2. GBrain 最新版核心事实

2.1 定位

GBrain README 对它的定位是：

• “Your AI agent is smart but forgetful. GBrain gives it a brain.”
• 由 Garry Tan 用于实际 AI agents 的生产脑库。
• 能摄取 meetings、emails、tweets、voice calls、original ideas。
• 每次写入页面时自动抽取实体引用并创建类型化链接。
• 提供 hybrid search、自连接知识图谱、结构化 timeline、backlink-boosted ranking。

README 中列出的生产规模指标：

• 17,888 pages
• 4,383 people
• 723 companies
• 21 cron jobs autonomously running
• 29/34+ skills 与 30+ MCP tools（不同版本描述略有差异）

这些指标说明：它的目标不是 demo，而是面向长期真实使用的个人/组织知识操作系统。

2.2 安装和运行形态

GBrain 支持：

1. 本地 CLI

   • 推荐方式：git clone https://github.com/garrytan/gbrain.git && cd gbrain && bun install && bun link
   • 初始化：gbrain init
   • 导入：gbrain import ~/notes/
   • 查询：gbrain query "..."

2. MCP Server

   • stdio 模式：gbrain serve
   • HTTP + OAuth 2.1 模式：gbrain serve --http --port 3131
   • 可被 Claude Code、Cursor、Windsurf、ChatGPT、Claude Desktop、Perplexity 等客户端连接。

3. Agent 平台集成

   • README 明确提到 Hermes Agent / OpenClaw 等平台。
   • 推荐由 Agent 安装、初始化、加载 skills、配置 recurring jobs。

2.3 当前重要版本能力

从 README 已读取内容看，近期重点包括：

• v0.25.0：BrainBench-Real
  可 opt-in 捕获真实 query/search 调用，PII scrub 后进入 eval_candidates，用于回放检索质量。

• v0.28.8：LongMemEval in the box
  可运行 LongMemEval benchmark，验证长期记忆检索能力。

• v0.32.3.0：压缩 AGENTS.md / resolver
  functional-area-resolver 用两层 dispatch 压缩 agent skill routing 文档，并提高命中效果。

• Minions
  Postgres-native durable job queue，用于替代脆弱的 sub-agent spawn，适合确定性后台任务。README 给出的对比是：Minions 753ms、$0 token、100% success；sessions_spawn >10s timeout、失败。

3. GBrain 的核心架构原理

3.1 Markdown + Database 双层架构

GBrain 推荐架构不是“只有数据库”，也不是“只有文件夹”，而是：

Markdown Repo：人类和 Agent 可读写的知识页面 / Git 同步 / 主记录
PGLite/Postgres：派生索引 / 搜索 / 向量 / 图关系 / runtime 状态
Skills：摄取、归档、查询、富化、维护的操作流程
MCP/CLI：对外提供工具接口
Cron/Minions：后台自动整理、同步、批处理

system-of-record.md 明确写道：

GitHub repo（markdown + frontmatter）是 system of record；Postgres/PGLite 是 derived cache。数据库不备份，必要时从 repo rebuild。

含义：

• 用户知识的可信主记录在 Markdown。
• 数据库主要用于加速搜索、去重、图关系、embedding、runtime job。
• 数据库损坏后，可通过 gbrain rebuild --confirm-destructive、gbrain sync、gbrain extract all 等重建。

这点对忠伟很重要：GBrain 不应成为黑盒记忆数据库，而应保留可读、可迁移、可审计的 Markdown 知识资产。

3.2 三层资料结构：Raw Sources / Brain / Schema

GBRAIN_RECOMMENDED_SCHEMA.md 中定义三层：

1. Raw sources

   • meeting transcripts
   • emails
   • tweets
   • web research
   • API responses
   • calendar events
   • contact data
   • immutable，Agent 读取但不修改。

2. The brain

   • interlinked Markdown files
   • people / companies / deals / meetings / projects / ideas / concepts / personal / household 等页面。
   • Agent 创建、更新、维护交叉引用。

3. The schema

   • RESOLVER.md
   • directory README
   • schema.md
   • skills
   • 规定页面结构、归档规则、工作流。

这与 55 的三层建议高度一致：原始资料不要直接污染执行工作区，而是先入 GBrain 的 raw/source 层。

3.3 MECE 目录与 Resolver

GBrain 强调：每条知识必须有唯一 primary home。

规则：

• 每个目录有 README 作为 local resolver。
• 顶层有 RESOLVER.md 作为主决策树。
• Agent 创建任何页面前必须先读 resolver。
• 现实可以多面，但页面只能有一个主目录；多面性通过 typed backlinks 表达。

对 55 的启发：如果未来接入海量生活、会议、健康、家庭、设备数据，必须提前定义归档规则，否则“全知”会变成“全乱”。

3.4 Compiled Truth + Timeline 双层页面

GBrain 的页面分两层：

页面上半部分：Compiled Truth
- 当前综合结论
- 一段 executive summary
- 当前状态字段
- open threads
- see also

---

页面下半部分：Timeline
- append-only
- 逆时间顺序
- 每条带 date/source/what happened

作用：

• 问“当前状态是什么” → 读上半部分。
• 问“发生过什么” → 读下半部分。
• 既保留当前结论，又不丢历史证据。

这比单纯 RAG 更适合 55，因为 55 经常要回答：

• 这个人现在怎么看？
• 这个项目最新进展是什么？
• 上次我和他聊了什么？
• 这个判断是怎么形成的？

3.5 Entity Registry / Event Ledger / Fact Store / Relationship Graph

推荐 schema 中提到四个数据库 primitive：

1. Entity registry
   管 canonical ID、aliases、外部 ID，解决同名/别名/邮箱/社交账号对应同一人的问题。

2. Event ledger
   每个触达大脑的 signal 都是不可变事件，带 source、timestamp、confidence、raw payload reference。

3. Fact store
   结构化 claim + provenance，例如“Jane 是 Acme CTO”。冲突事实并存，不直接覆盖。

4. Relationship graph
   typed edges：Person→Company、Person→Person、Company→Deal 等，支持图遍历。

对 55 的意义：

• 人物关系、项目关系、会议参与、家庭关系、健康指标变化都不应只靠全文搜索。
• 要能回答“谁跟谁有关”“这个判断从哪里来”“过去和现在是否矛盾”。

3.6 自动链接和关系抽取

GBrain README 与 brain-ops skill 都强调：每次 put_page 写入，会自动提取实体引用并写入 graph links。

已读取 skill 中列出的默认关系类型包括：

• attended
• works_at
• invested_in
• founded
• advises
• source
• mentions

这类“零 LLM 调用”的 deterministic auto-link 是关键：

• 便宜
• 稳定
• 可批量
• 不阻塞用户交互

3.7 Hybrid Search + Graph Traversal

GBrain 查询不是单一路径：

• keyword search / FTS
• semantic / vector query
• backlinks
• typed graph traversal
• timeline
• full page compiled truth

query skill 要求：

• 先拆问题，决定 keyword、semantic、structured/backlink 哪种策略。
• 关系问题用 graph，而不是全文搜索。
• 回答必须带 citation；不知道就明确说 brain 没有信息。

典型图查询：

• “Who works at Acme?” → graph-query companies/acme --type works_at --direction in
• “Who attended Demo Day?” → graph-query meetings/demo-day --type attended --direction out

3.8 Storage Tiering：db_tracked vs db_only

新版 GBrain 支持 storage tiering：

storage:
  db_tracked:
    - people/
    - companies/
    - deals/
    - concepts/
    - ideas/
    - projects/

  db_only:
    - media/x/
    - media/articles/
    - meetings/transcripts/

含义：

• db_tracked：人类编辑、重要、可进 Git。
• db_only：大量机器生成或隐私/体积敏感内容，保存在数据库，磁盘只是 cache，不提交 Git。

对忠伟很关键：会议录音、转写、家庭设备流水、健康设备时序数据，绝不能都进 Git 仓库；应使用 db_only 或外部对象存储。

3.9 Brain / Source 双轴隔离

brains-and-sources.md 说明：

• Brain = 一个数据库。
• Source = 一个 brain 内部的一个内容 repo。
• --brain <id> 选择哪个数据库。
• --source <id> 选择数据库内哪个 repo。
• 如果数据 owner 不同，用 brain 隔离；owner 相同但主题/仓库不同，用 source 隔离。

对忠伟建议：

Personal Brain（忠伟个人主脑）
  source: 55-workspace-summary
  source: personal-life
  source: ai-remember-me
  source: family
  source: health

Bixin Work Brain（比心工作脑，可与个人隔离）
  source: tech-org
  source: ai-native-rd
  source: meetings
  source: projects

个人与公司数据强烈建议至少用 source 分隔；如果权限、合规、泄漏风险较高，则用不同 brain 分隔。

4. GBrain 的主要应用模式

4.1 个人高管外部大脑

适合对象：CEO、技术负责人、投资人、创作者。

接入：

• 会议纪要/录音转写
• 日历
• 邮件
• 聊天摘要
• 人物/公司/项目资料
• 社交媒体
• 个人思考

产出：

• meeting prep
• 人物 dossier
• 项目上下文
• open threads
• daily briefing
• 决策追踪

4.2 会议摄取与会前准备

meeting-ingestion skill 定义的流程：

1. Parse transcript：提取 attendees、date、duration、topics、decisions、action items、companies/projects。
2. Create meeting page：summary、key decisions、action items、discussion notes。
3. Attendee enrichment：每个参会人必须创建/更新 people page。
4. Entity propagation：每个公司/项目/概念都要更新。
5. Timeline merge：同一事件出现在所有相关实体 timeline。
6. Sync。

对 55 的直接价值：

• 会前自动拉出“上次和这些人聊过什么”。
• 会后自动核销 action items。
• 形成“人—项目—决策—会议”关系网。

4.3 语音/想法摄取

voice-note-ingest 的铁律：用户原话是信号，不能改写。

流程：

1. 保存原始音频。
2. 转写。
3. 按 decision tree 归档到 originals / concepts / people / companies / ideas / personal / voice-notes。
4. 页面中保留 User's Words 原文块。
5. 对提到的人/公司建立 cross-link 和 timeline。

这对“AI记得我”尤其重要：忠伟自己的措辞、犹豫、口头表达，是人格和思维方式的重要语料，不能只存 AI 总结。

4.4 Ambient Brain Ops：每次互动都读写脑

brain-ops 的核心是：brain 不是 archive，而是 live context membrane。

读写循环：

Inbound signal
  → detect entities
  → load brain pages
  → identify new information
  → write back with source citation
  → create/enrich missing notable entities

Outbound response
  → check brain
  → pull compiled truth + recent timeline
  → respond with context

对 55：所有微信/钉钉/语音/会议/健康/家庭设备信号，理论上都应触发这个 read-enrich-write 循环，但要按隐私和重要性分级。

4.5 Durable 后台任务：Minions

GBrain 把确定性后台工作从 LLM subagent 中拿出来，交给 Postgres-native job queue：

• 抓取 posts
• 解析 JSON
• 写 brain page
• sync
• 批量导入
• 定时维护

原则：

确定性任务 → Minions / script / job queue
需要判断的任务 → Sub-agent / LLM

对 55：家庭设备信号、健康设备同步、会议录音转写后的批处理，都应尽量走确定性 pipeline，避免每条数据都消耗 LLM。

4.6 评测与质量治理

GBrain 新版加入 BrainBench-Real 与 LongMemEval：

• 捕获真实 query/search 调用，回放检索质量。
• 用 Jaccard@k、top-1 stability、latency delta 评估变更影响。
• 支持 LongMemEval 对长期记忆问答检索进行 benchmark。

对 55：如果未来真的把生活全部接入，不能只凭“感觉好用”，需要评测：

• 能否找回上次会议关键结论？
• 能否找到某个健康指标变化原因？
• 能否准确识别人和项目的关系？
• 能否避免隐私数据串域？

5. 与 55 结合的目标架构

5.1 总体架构

[输入层]
钉钉 / 微信 / 邮件 / 日历 / 会议录音 / 语音备忘 / 家庭设备 / 健康设备 / 文件 / 网页
        ↓
[接入与预处理]
转写、OCR、结构化解析、去重、时间戳、来源标记、隐私分级
        ↓
[GBrain Raw Sources]
原始音频、转写、聊天记录、设备流水、健康报告、PDF、网页快照
        ↓
[GBrain Brain Layer]
people / meetings / projects / health / family / household / ideas / originals / concepts
Compiled Truth + Timeline + backlinks + typed graph
        ↓
[55 工作区]
当前任务、会议准备、项目摘要、人物卡片、决策备忘、健康摘要、家庭安排
        ↓
[Hermes Memory]
少量稳定高频事实：身份、偏好、长期方向、重要关系、健康禁忌、路径约定
        ↓
[55 行动层]
提醒、会议准备、日程建议、任务核销、风险提示、文档输出、跨渠道应答

5.2 数据该放哪里

5.3 和当前 55 工作区的关系

当前约定：

• 55/：55 自己的工作内容。
• zw/：忠伟工作/个人/家庭/健康内容。
• people/：人物关系档案。

建议：

• 保持当前 55 工作区作为执行层，不要迁移成原始资料库。
• GBrain 如果落地，可作为 /home/ypp/gbrain 或单独 repo，不和 /home/ypp/workspace 混在一起。
• 工作区文档只保存高价值摘要，并保留 GBrain source citation。

6. 面向“全知、全能 55”的数据接入设计

6.1 会议录音

目标：会前知道背景，会后自动沉淀决策和行动项。

接入流程：

会议录音
  → 原始音频入 GBrain storage/db_only
  → Whisper/ASR 转写
  → meeting-ingestion
  → 生成 meeting page
  → 更新参会人 people page
  → 更新项目 page
  → action items 同步到 55 工作区/任务系统

页面结构：

• Meeting page：summary / decisions / action items / discussion notes / transcript link。
• People page：该人参加了什么会、表达了什么观点、承诺了什么动作。
• Project page：项目的新增事实、决策、风险。

6.2 微信/钉钉聊天

目标：跨渠道理解上下文，但不把所有聊天全文塞进 prompt。

接入策略：

• 当前会话由 Hermes session archive 记录。
• 重要对话摘要进入 GBrain。
• 涉及人物/项目/决策/承诺时更新对应页面。
• 跨渠道继续聊天时，55 先用 session_search/GBrain 查询衔接。

写入原则：

• 用户明确纠正 → 高优先级写入。
• 重要承诺/任务 → 写入工作区任务和 GBrain timeline。
• 普通闲聊 → 不进入长期结构化页面，最多保留原始 session archive。

6.3 家庭设备信号

目标：从“家庭数据流水”变成“家庭运营洞察”。

可接入：

• Home Assistant 事件
• 温湿度
• 空气质量
• 门锁/摄像头/人体传感器
• 睡眠环境
• 用电/网络/设备故障

不要做：

• 每条设备事件都让 LLM 分析。
• 每条传感器流水都写入 Git。

推荐：

设备原始事件 → timeseries/db_only
日聚合/异常检测 → household timeline
重要异常 → 55 通知/任务
长期规律 → family/household summary

示例：

• “安安房间过去 7 天 22:00 后 CO2 经常超过阈值” → 进入家庭环境洞察。
• “门锁每天开关事件” → 只保留原始流水，不写入工作区。

6.4 健康信息

目标：让 55 理解健康趋势和注意事项，但避免医疗幻觉。

接入：

• 体检 PDF/OCR
• 血脂/血糖/肝功能/铁蛋白等指标
• 体重/运动/睡眠
• 耳鸣/眩晕/用药记录

存储：

• 原始报告：GBrain health raw/db_only 或受控 repo。
• 结构化指标：health fact store / timeline。
• 55 工作区：zw/health/baseline.md、medical_record.md、goals.md。
• Memory：只保留关键注意事项，例如铁蛋白、耳鸣、疑似 Gilbert 综合征用药提示。

边界：

• 55 可以做趋势提醒、资料整理、就医问题清单。
• 不能替代医生诊断。
• 所有健康判断必须带来源、日期和置信度。

6.5 个人思考与“AI记得我”

这是最高价值输入。

策略：

• 语音备忘必须保留原话和原音频。
• 原创想法进入 originals/。
• 产品想法进入 ideas/ 或项目页。
• 长期判断进入 concepts/ 或 programs/。
• 与人物相关的观察进入 people timeline。

这会让未来“AI记得我”不只是资料库，而是逐渐沉淀忠伟的表达方式、价值观、思维路径和人生轨迹。

7. 隐私、权限与安全边界

7.1 Brain 边界

建议至少拆两类：

Personal Brain：家庭、健康、个人思考、AI记得我、私人关系
Work Brain：比心组织、项目、会议、人物、AI原生研发

如果暂时不拆 brain，也至少用 source 隔离：

• source=personal
• source=bixin
• source=family
• source=health

7.2 数据分级

建议分 4 级：

7.3 Citation 和溯源

每个事实必须能追溯：

[Source: channel/source, author, date, time, timezone, raw_ref]

没有来源的内容只能作为“推断/假设”，不能写成事实。

7.4 反注入与远程访问

GBrain README 提到 LongMemEval 检索内容会使用 INJECTION_PATTERNS 做 prompt-injection 防护；system-of-record.md 提到 remote MCP 下会 strip 私有 facts/takes fence。

建议 55 落地时默认：

• 远程 MCP 只开放 read scope，write/admin 分开。
• 健康/家庭/私人数据默认不暴露给外部 client。
• 原始网页、邮件、聊天内容进入模型前做 prompt injection 清洗。

8. 推荐落地路线

Phase 0：不安装前的架构准备（1-2 天）

产出：

• 明确 Personal Brain / Work Brain 是否拆分。
• 定义目录 resolver。
• 定义数据分级。
• 定义哪些数据先接入，哪些暂缓。

建议优先级：

1. 会议录音/纪要
2. 微信/钉钉重要对话摘要
3. 个人语音想法
4. 健康报告
5. 家庭设备信号

家庭设备信号数据量大、价值密度低，建议后置。

Phase 1：GBrain MVP（1 周）

目标：跑通最小闭环。

动作：

git clone https://github.com/garrytan/gbrain.git
cd gbrain
bun install
bun link
gbrain init

然后：

• 建立 Personal Brain repo。
• 导入当前 zw/personal/ai-remember-me、people/ 的一部分摘要，不导入全部原始工作区。
• 配置 Hermes MCP：gbrain serve。
• 用 3 类数据试跑：一段会议纪要、一段语音想法、一份健康摘要。

验收：

• 能 gbrain query 查到人物/项目/健康摘要。
• 能通过 graph/backlinks 找关系。
• 页面能保持 Compiled Truth + Timeline。
• 工作区摘要能引用 GBrain 页面。

Phase 2：55 接入 GBrain 查询（1-2 周）

目标：55 回答问题前能查 GBrain。

动作：

• 为 55 增加“涉及人物/项目/长期事实 → 先查 GBrain”的规则。
• 将 GBrain 查询作为工具化检索，不把所有内容塞进 prompt。
• 针对会前准备、人物背景、项目复盘建立固定模板。

验收问题：

• “我上次和刘华聊 AI 原生研发是什么结论？”
• “最近关于 AI记得我 我有哪些原话想法？”
• “安安教育相关最近有哪些安排和观察？”
• “我的铁蛋白问题最近有哪些资料？”

Phase 3：会议和语音自动摄取（2-4 周）

目标：让高价值输入自动进入脑库。

动作：

• 会议录音 → ASR → meeting-ingestion。
• 钉钉/微信重要语音 → voice-note-ingest。
• 每天/每周维护任务：同步、检查孤立页面、缺 citation、缺 backlink。

验收：

• 每次会议后自动形成 meeting page、action items、人物 timeline。
• 55 可在会前给出 5 条关键背景，而不是全文摘要。

Phase 4：健康与家庭设备（1-2 月）

目标：接入低频高价值健康数据和高频低价值设备数据。

动作：

• 健康报告 OCR + 指标结构化。
• 体重/睡眠/运动日聚合。
• Home Assistant 事件先做日聚合，不直接 LLM 化。
• 只把异常和长期趋势写入工作区。

验收：

• 能回答某个健康指标的历史趋势与来源。
• 能识别家庭设备异常模式。
• 不产生通知噪音。

Phase 5：评测与治理

目标：防止“看起来全知，实际胡说”。

建立测试集：

• 20 个忠伟常问的问题。
• 20 个人物关系问题。
• 20 个项目状态问题。
• 20 个健康/家庭事实问题。
• 10 个隐私越权问题。

指标：

• top-5 recall
• citation completeness
• wrong answer rate
• stale answer rate
• cross-domain leakage rate
• latency

9. 55 的具体改造建议

9.1 55 的判断流程

当忠伟提问时，55 应按类型判断：

即时会话问题 → 当前上下文
跨渠道最近对话 → session_search
人物/项目/长期事实 → GBrain query/search/get_page
当前任务/执行状态 → 55 工作区
稳定偏好/身份 → Hermes Memory
真实日程/系统状态 → 工具查询，不用记忆

9.2 55 写入规则

只有这些写入 GBrain：

• 忠伟明确表达的重要判断、想法、偏好、纠正。
• 会议决策、行动项、承诺。
• 人物关系和观点变化。
• 项目状态变化。
• 健康报告和明确健康事件。
• 家庭重要安排和成长记录。

不写：

• 短期寒暄。
• 临时执行过程。
• 一周内会过期的任务细节。
• 无来源的推测。

9.3 55 工作区输出规范

工作区文件应增加来源引用：

## 来源
- GBrain: meetings/2026-05-13-ai-native-review
- GBrain: people/liu-hua
- Session: 20260513_xxx

这样 55 的结论可回溯，不会变成“我好像记得”。

10. 风险与注意事项

10.1 最大风险：数据全进来了，但没有 schema

没有 resolver、没有 primary home、没有 compiled truth/timeline，GBrain 会变成第二个杂乱网盘。

应先设计目录和写入规则，再批量导入。

10.2 第二风险：隐私边界不清

家庭、健康、工作、个人创业资料混在一个 brain，未来接入外部 client 时会有泄漏风险。

建议从第一天就做 Personal / Work 分域。

10.3 第三风险：过度自动化

不是所有信息都值得写入长期记忆。

55 的角色是保护忠伟注意力，不是制造更多上下文噪音。

10.4 第四风险：把总结当原文

对于“AI记得我”和忠伟个人思想，原话比总结更重要。

语音、日记、聊天关键片段必须保留原文/原音频；总结只作为派生视图。

11. 我的明确建议

忠伟，我建议你把 GBrain 定位为 55 的外部大脑主库 + AI记得我的长期记忆底座，但不要让它替代 55 工作区。

最优策略：

1. 原始资料统一进 GBrain：会议录音、语音想法、健康报告、家庭设备流水、聊天重要记录。
2. 55 工作区只放执行摘要：当前任务、会议准备、人物卡片、项目状态、健康/家庭关键摘要。
3. Hermes Memory 只放极少量稳定事实：身份、偏好、长期方向、核心关系、健康禁忌。
4. 先接高价值低噪音数据：会议、语音想法、健康报告；家庭设备信号后置做聚合。
5. 第一天就做权限和分域：个人、家庭、健康、比心工作至少 source 隔离，最好 brain 隔离。

如果按这个路线，55 会从“会话型助理”升级为：

• 知道忠伟经历和上下文的记忆系统；
• 能跨人、项目、会议做关系推理的高管助理；
• 能持续沉淀忠伟思想原文的“AI记得我”原型；
• 能连接家庭、健康、设备信号的个人操作系统入口。

12. 下一步建议

建议下一步不是马上全量导入，而是做一个 7 天 MVP：

1. 建一个 Personal GBrain。
2. 只接入三类样本：
   • 3 次会议纪要/录音转写
   • 10 条忠伟语音/文字原始想法
   • 1 份健康报告摘要
3. 让 55 基于这些资料完成 5 个真实任务：
   • 会前准备
   • 人物背景
   • 项目状态回顾
   • 健康问题清单
   • AI记得我想法回溯
4. 用结果判断：检索是否准、引用是否清晰、是否真的减少忠伟负担。

通过后，再扩大到家庭设备和更多渠道。