Agent: OpenAI Codex
+ Tools: Google 全家桶、WhatsApp、电报、浏览器自动化等
+ Data: Google Drive、Notion、AGENTS.md 等
+ Skills: inbox-zero、contacts 等
== 个人生活自动化 Agent 工具栈

@nicbstme 提出的两个典型工作流
1. 介绍邮件（跨 5 个工具的「胶水活」）
朋友 WhatsApp 求助 → 搜 WhatsApp/Gmail 找邮箱 → 网页查公司融资 → 起草介绍信 → 等批准 → 发邮件 → WhatsApp 告知完成。

人工约 20 分钟、大量上下文切换；用户侧约 10 秒提需求。Agent 做的是跨 App 的编排，不是回答问题。

2. 车牌更新（行政连续性）
发照片给 Agent → 更新 Drive 里的 Markdown 车辆档案 → 保留 VIN、保险等字段 → 上传回 Drive → 必要时用浏览器自动化同步到 FasTrak、停车 App、保险门户等无 API 的系统。

体现的是行政连续性：同一份信息在多处保持一致，而非一次性问答。

最重要的架构决策：Drive 作为 Source of Truth
Nicolas 刻意把知识从 Notion 迁到 Google Drive，原因很务实：
· Notion 对人友好，对 Agent 不友好（嵌套页面、数据库属性、权限、UI 原生结构）
· Drive + Markdown/CSV：可搜索、可 diff、可编辑、可上传、可引用 file ID
· gogcli 提供统一的 CLI 面（Gmail、Drive、Calendar、Docs、Sheets 等）

组织知识不应只为人类 UI，而应面向 Agent 的工具路径。 稳定 file ID、纯文本、表格、返回 JSON 的命令——这些才是 Agent 友好的数据形态。

联系人 CSV（电话、邮箱、LinkedIn 等）被作者称为「最佳投资之一」，因为它是跨渠道 lookup 的枢纽。

工具优先级（可靠性层级）
API / CLI > 本地文件 > 浏览器自动化 > 屏幕/UI 自动化

Agent 的可靠性上限取决于工具面。gog gmail messages list --json 比让模型在网页上点来点去更稳定、可重试、可推理。浏览器和屏幕自动化是必要时的兜底，不是主路径。

Skills：Agent 的「习惯」与「品味」
Skill 不是 fancy 架构，就是可迭代的操作手册。以 inbox-zero 为例：
· 列出收件箱 → 区分自动归档 / 需人工审阅
· 展示重要邮件、引用原文、建议归档或回复
· 起草后等明确批准再发送
· 保留所有收件人、回复简短、不主动建议电话、签名用 "Nicolas"

没有 Skill，每次都要重新 prompt 所有偏好；有了 Skill，说「run inbox zero」即可。个人 Agent 的个性化，来自操作品味的累积，而非 cute voice。

反馈闭环：
· 工具失败 → 修工具或加 guardrail
· 判断失误 → 更新 Skill
· 忘记偏好 → 写入 memory / AGENTS.md
· 工作流重复 → 体系 compound 改进

批准门控：信任分级才是产品
Nicolas 明确反对「YOLO 全自动」：
· 低 stakes 可直接发（如「告诉 Hugo 我下周在西雅图」）
· 高 stakes 必须：读上下文 → 起草 → 展示 → 等批准 → 执行 → 确认。

有用 vs 可怕的分界，在于是否在正确时刻问人。

「杀手级」工作流：What did I miss?
比单点邮件更重要的，是生活收件箱 triage：
· 每隔几小时问一句「我漏了什么？」→ Agent 扫描 WhatsApp、Telegram、Gmail、SMS、Calendar、Drive 变更 → 汇总：谁需要回复、什么 urgent、什么 stale、什么可忽略、什么该建日历、什么要查文档。

特点：上下文重、重复、跨工具、充满小决策——人讨厌做第一遍扫描，Agent 擅长第一遍，判断权仍在人。

复现清单（Nicolas 给出的路径）
1. 装 Agent 运行时 + 各渠道 CLI/连接器
2. 集中数据：Drive 为真相源，联系人 CSV，重要文档可搜索化
3. 谨慎授权：Full Disk Access、Screen Recording、Accessibility——必须配合同级 approval gates
4. 写 operating rules（AGENTS.md）：draft before send、工具路由、隐私边界等
5. 为重复流程写 Skills，并在每次失误后更新