摘要

背景与问题定义

现实困境（用户痛点）

• 碎片化控制：账号散落在数百个服务里；授权、密码、2FA、设备权限互不相通。
• 不可见授权：OAuth scopes、第三方应用访问、数据共享链条不透明；撤销点分散。
• 数据外流不可追：数据经由广告生态、数据经纪商扩散；删除成本高、流程复杂。
• 自动化成本高：IFTTT/脚本/规则引擎门槛高；而“代理式 AI”又容易越权。
• 数字遗产无系统：各平台规则不一致；亲属在关键时刻要面对证明、流程、时限。

产品机会（为什么现在做）

• 授权协议成熟：OAuth2/OIDC/SCIM/UMA/GNAP 等标准提供可组合的授权与身份基础。
• 隐私信号与法规推进：GPC 进入 W3C 文档体系，并被部分法律/监管实践纳入“可执行信号”。
• 数字遗产机制普及：Google Inactive Account Manager、Apple Legacy Contact、Microsoft/OneDrive 的数字遗产功能等，给了“合规继承”的锚点。
• AI 代理的可控化路径清晰：工具调用 + 策略引擎 + 审计日志，能把“会胡来”的模型关进笼子。

产品定义与边界

产品定位

AI 总控系统是一套个人控制平面（Personal Control Plane），核心职责是： 1）发现并编目你的数字资产与痕迹； 2）聚合并治理你授予第三方的访问权； 3）把“想做的事”转成受控自动化； 4）在你不在时执行你提前定义的遗产与分身策略。

四条产品边界（写死在 PRD）

产品形态

• 移动端 App：控制中心（授权、策略、自动化、审计、遗产）。
• 浏览器扩展：隐私信号（GPC/OOPS）、Cookie/同意记录采集、账号发现、网页数据采集。
• 桌面/本地代理（可选）：访问本机文件、照片库、密码库接口（不读取明文密码）、本地模型推理。
• 云端控制平面：连接器编排、策略决策、审计、通知；默认不持有明文数据（端到端加密）。

目标、原则、成功标准

目标（G）

• G1：可见：让用户知道“我在互联网上有哪些资产、谁能访问、访问到什么”。
• G2：可控：让用户一键撤销/收敛授权，把权限从“散落”变成“可策略化管理”。
• G3：可自动化：让用户把反复劳动交给系统，但不牺牲可控性与可追责性。
• G4：可继承：让用户在生前明确数字遗产的归属、时机、范围、限制。

原则（P）

• P1：最小授权：默认只读；写/删必须显式升级权限。
• P2：策略先于智能：AI 只负责“建议与生成”，执行由策略引擎裁决。
• P3：审计即产品：所有数据访问与自动化动作都可回放、可导出、可证明。
• P4：端到端加密默认开启：服务端只看见密文与必要元数据。
• P5：遗产双重证明：生前授权 + 事后证明（死亡证明/代理权文件）缺一不可。

成功标准（S）

用户画像与场景

画像

典型场景（JTBD）

• 我想知道：哪些应用/第三方还在访问我的邮箱、网盘、社交数据？
• 我想减少：重复的退订、归档、备份、清理任务。
• 我想控制：广告追踪与数据经纪商的售卖/分享。
• 我想留下：哪些内容给谁、何时给、给到什么粒度。
• 我想延续：在授权范围内，用“分身”回答家人关于我的信息，但不冒充我做交易。

核心概念模型

核心对象

“接管程度”刻度（用户可配置）

关键用户流程

流程 A：首次入驻（资产盘点）

1. App 创建“保险库”（生成本地密钥/恢复方案）
2. 连接邮箱（首选）→ 从邮件中发现账号线索（注册/账单/登录通知）
3. 连接主流身份提供方（Google/Microsoft/Apple 登录）
4. 生成“数字资产清单”：服务、账号、授权、订阅、设备、风险
5. 输出“优先清理队列”：高风险授权、过期服务、可撤销第三方
        

流程 B：授权治理（看清 + 收敛 + 撤销）

1. 展示所有 OAuth 授权（按服务/第三方应用/Scope 聚合）
2. AI 解释每个 Scope 的“可能读取/写入的真实含义”
3. AI 提出最小化方案：减少 Scope / 改只读 / 拆分账号 / 替代连接器
4. 用户确认 → 系统调用官方撤销端点/管理界面跳转
5. 写入同意记录 + 审计事件（不可抵赖）
        

流程 C：自动化（从意图到受控执行）

1. 用户自然语言描述：例如“每周清理订阅邮件，重要的留着”
2. AI 生成工作流草案（触发器/条件/动作/回滚）
3. 策略引擎静态审查：是否越权？是否涉及敏感类别？
4. 沙箱演练：在样本数据上跑一遍，输出拟执行清单
5. 用户一次确认 → 运行时执行（带速率限制、失败重试、可回放）
6. 结果汇总 → 审计记录 → 用户可一键撤销该自动化
        

流程 D：遗产模式（生前规划 → 身后执行）

1. 设定遗产联系人（可多人）与分配范围（照片/文件/账号权限/备忘录）
2. 设定触发条件：长期不活跃、死亡证明上传、法院/遗嘱执行人证明
3. 设定时间窗：例如“触发后 30 天冷静期，可被撤回”
4. 系统进入“封存”状态：冻结高风险自动化、锁定策略
5. 核验完成 → 释放：只读访问/导出包/平台官方遗产机制引导
6. 数字分身（可选）：仅回答允许主题；永不输出登录凭证/交易指令
        

功能清单（分期）

MVP（必须做，且能做）

V1（增强控制面）

• 权限生命周期：授权到期提醒、自动轮换、最小 Scope 建议。
• 风险信号：新设备登录、异常 OAuth 授权、数据外传模式异常（基于事件）。
• 浏览器隐私层：发送 GPC/OOPS 信号、Cookie 同意记录采集、跟踪器可视化。
• 数据经纪商治理：对接可用的官方/监管平台（如加州 DROP）或模板化删除请求管理。
• 多保险库：工作/个人分区；不同密钥与策略。

V2（数字分身与跨域互操作）

• 数字分身（受控）：基于 Vault 的检索增强问答；主题白名单；强制“非本人声明”。
• 数据可移植：对接 Data Transfer Project/DTI 能力（若目标平台支持）。
• 自托管/Pod：引入个人数据仓（PDS/Pod）形态，兼容 Solid 生态（可选）。
• 代理式授权协议演进：支持 GNAP/OAuth2.1 等新型授权形态（按需）。

AI 驱动设计

AI 在系统中的职责（严格限定）

Agent 组件（可实现的“多代理”）

对抗模型幻觉与提示注入（Prompt Injection）

• 工具白名单：模型只能调用明确的工具；每个工具只做一件事。
• 策略前置：任何工具调用先走策略引擎（OPA）判定 allow/deny。
• 输出类型化：模型输出必须是结构化 JSON/DSL，经 schema 校验。
• 双通道解释：给用户同时展示“将要做什么”和“为什么需要这个权限”。
• 回放与撤销：工作流每一步都可回滚，至少对“外部副作用”提供补偿动作。

系统架构

高层架构图（逻辑）

┌──────────────────────────────────────────────────────────────────────┐
│                               用户端                                  │
│  Mobile App (控制中心)  Browser Extension (隐私信号/发现)  Desktop Agent │
└───────────────┬───────────────────────────────┬───────────────────────┘
                │                               │
                │ E2EE 密钥在端侧                │
                ▼                               ▼
┌──────────────────────────────────────────────────────────────────────┐
│                         个人控制平面（云）                             │
│  ┌──────────────┐   ┌──────────────┐   ┌──────────────────────────┐  │
│  │ 连接器编排层   │→  │ 事件/队列总线  │→  │ 归一化/索引/元数据服务      │  │
│  └──────────────┘   └──────────────┘   └──────────────────────────┘  │
│          │                   │                         │              │
│          ▼                   ▼                         ▼              │
│   ┌──────────────┐   ┌──────────────┐        ┌───────────────────┐   │
│   │ 授权与同意中心  │   │ 策略引擎 OPA  │        │ 审计账本（追加写） │   │
│   └──────────────┘   └──────────────┘        └───────────────────┘   │
│          │                   │                         │              │
│          ▼                   ▼                         ▼              │
│   ┌───────────────────────────────────────────────────────────────┐  │
│   │ AI Orchestrator（多代理） + 工具沙箱（受限执行）                 │  │
│   └───────────────────────────────────────────────────────────────┘  │
│                                  │                                     │
└──────────────────────────────────┼─────────────────────────────────────┘
                                   ▼
                       ┌────────────────────────┐
                       │ 外部服务（OAuth/API/导出）│
                       └────────────────────────┘
        

部署形态：默认“云控制 + 端侧密钥 + 可选本地代理”

• 端侧：密钥管理、敏感计算（可选本地模型）、用户交互确认。
• 云端：连接器、队列、策略裁决、审计、通知、模型推理（可选）。
• 可选自托管：高隐私用户可部署私有控制平面或使用 Pod/PDS。

关键子系统说明

数据、权限、同意模型

权限模型：三层叠加

1. 外部平台权限：OAuth scopes/平台 API 能力。
2. 系统内策略权限：Policy 决定“即使有外部权限也不允许做什么”。
3. 动作级审批：按风险分级决定是否需要二次确认/生物识别/硬件密钥。

同意记录：可交换、可审计

同意记录建议对齐 ISO/IEC TS 27560 这类“机器可读同意记录结构”，并生成用户可读的“同意回执”（类似收据）。 这样做的价值是：对内统一审计，对外可互操作（未来可对接更多生态）。

数据分类（建议最小集合）

审计账本：事件溯源（Event Sourcing）

AuditEvent {
  event_id, timestamp, actor (user/agent/service), action,
  resource_ref (asset/grant/policy), decision (allow/deny/step_up),
  inputs_hash, outputs_hash, reason, signature, prev_event_hash
}
        

安全、隐私、合规

安全基线

• 端到端加密：Vault 数据在端侧加密，云端只存密文；密钥不落服务端。
• 强身份验证：优先 Passkeys/WebAuthn；对高风险动作触发 step-up。
• Token 安全：支持 DPoP/绑定型令牌（若服务支持），减少令牌被盗重放风险。
• 最小权限连接器：每个连接器声明能力矩阵（read/write/delete/export）。
• 隔离与最小爆炸半径：每个租户独立密钥域；连接器运行在隔离沙箱。

隐私控制：信号 + 法定请求 + 平台机制

合规要求（产品侧“必备动作”）

• 数据最小化：默认不采集不必要数据；可关闭任意连接器。
• 透明度：让用户知道系统读了什么、为什么读、存多久、发给谁。
• 可携带与可删除：Vault 内一键导出/一键销毁；对外发起删除请求的证据链。
• 遗产合规：不同平台/地区对继承访问要求不同，必须使用“证明材料工作流”。
• 安全管理体系：建议对齐 ISO/IEC 27001 的 ISMS（至少在流程上）。

数字分身的合规与伦理红线

工程落地指南

技术选型（建议，不绑死）

连接器开发规范（决定成败）

• 声明式能力矩阵：每个连接器提供 machine-readable 的 capabilities：read/write/delete/export。
• 最小 Scope：只申请必须的 scopes；尽量用增量权限升级。
• 增量同步：必须支持 cursor/watermark；避免全量拉取。
• 幂等与补偿：写/删动作必须幂等；提供补偿动作或清晰不可回滚说明。
• 速率限制：按平台政策做自适应限流；避免触发封禁。
• 输出规范：统一为内部 Canonical Schema，避免下游重复适配。

AI 工作流执行框架（模板）

(1) Intent → (2) Plan(JSON) → (3) Policy Check → (4) Dry-run
    → (5) User Approval (if needed) → (6) Execute Steps
    → (7) Post-check + Audit → (8) Summarize + Learn
        

“可落地”分解：先把最硬的骨头啃掉

1. 先做授权中心：因为它是后续自动化与分身的合法基础。
2. 再做保险库：因为没有统一数据层，AI 只能靠猜。
3. 再做低风险自动化：用“能回滚/能解释”的动作建立信任。
4. 最后做数字分身：否则你会得到一个极像你但到处胡说、还容易被滥用的系统。

路线图与里程碑

指标与验收

验收清单（MVP）

上线后要盯的指标

• 授权撤销率、最小化率（Scope 减少比例）
• 自动化节省时间（可测量：任务数量、处理邮件/文件量）
• 告警误报/漏报率
• 连接器稳定性（失败重试次数、被平台限流/封禁率）
• 用户导出/销毁成功率（“退出成本”要低）

风险清单与对策

参考标准与资料

授权/身份/同意/策略

• OAuth 2.0（RFC 6749）：https://datatracker.ietf.org/doc/html/rfc6749
• OpenID Connect Core 1.0：https://openid.net/specs/openid-connect-core-1_0.html
• UMA 2.0（用户可管理访问）：https://docs.kantarainitiative.org/uma/wg/uma-core-2.0-20.html
• SCIM（RFC 7644）：https://datatracker.ietf.org/doc/html/rfc7644
• ISO/IEC TS 27560:2023（同意记录信息结构）：https://www.iso.org/standard/80392.html
• Open Policy Agent（OPA）：https://www.cncf.io/projects/open-policy-agent-opa/
• GNAP（RFC 9635）：https://datatracker.ietf.org/doc/rfc9635/
• OAuth 2.1（草案）：https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
• OpenID Shared Signals Framework 1.0：https://openid.net/specs/openid-sharedsignals-framework-1_0.html

强认证与令牌安全

• WebAuthn（W3C）：https://www.w3.org/TR/webauthn-3/
• Passkeys（FIDO Alliance）：https://fidoalliance.org/passkeys/
• NIST SP 800-63B（认证强度）：https://pages.nist.gov/800-63-3/sp800-63b.html
• DPoP（RFC 9449）：https://www.rfc-editor.org/rfc/rfc9449.html

隐私信号与监管

• GPC（W3C TR）：https://www.w3.org/TR/gpc/
• 加州司法部：GPC 说明：https://oag.ca.gov/privacy/ccpa/gpc
• 加州 CPPA：OOPS（Opt-out Preference Signal）介绍：https://cppa.ca.gov/pdf/oops.pdf
• 加州 CPPA：DROP 平台：https://privacy.ca.gov/drop/
• GDPR（欧盟）：https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX%3A02016R0679-20160504
• CCPA（加州）：https://oag.ca.gov/privacy/ccpa
• ISO/IEC 27001（ISMS）：https://www.iso.org/standard/27001

数字遗产（平台官方机制）

• Google Inactive Account Manager：https://support.google.com/accounts/answer/3036546
• Apple Digital Legacy / Legacy Contact：https://support.apple.com/en-us/102631
• Microsoft：死亡后账户访问说明：https://support.microsoft.com/en-us/account-billing/accessing-outlook-com-onedrive-and-other-microsoft-services-when-someone-has-died-ebbd2860-917e-4b39-9913-212362da6b2f
• OneDrive 数字遗产：https://support.microsoft.com/en-us/office/preserve-your-digital-legacy-with-onedrive-245869c6-3505-4d75-a75f-82bdec48ad7b

AI 安全（提示注入等）

• OWASP Top 10 for LLM Apps：https://owasp.org/www-project-top-10-for-large-language-model-applications/
• NIST AI RMF：https://www.nist.gov/itl/ai-risk-management-framework
• OpenAI：Prompt Injections：https://openai.com/index/prompt-injections/