一句话：AI 负责决策，hermes cron 负责时间，飞书 Base 负责真相，本地记忆负责学习，注意力策略负责不打扰。

「私人执行助理」（Personal Executive Assistant）是一套运行在 hermes agent 运行时 之上的个人事务管理系统。它主动收集用户的事务（邮件 / 飞书 / 日历 / IM）、判定优先级 P0-P4、动态排程与持续跟进，并根据用户长期偏好和短期状态调整决策。本文将把它从 13 个平铺子 skill 收敛为 4 核心 skill 的完整设计拆解清楚——包括四层架构、飞书八张数据表、三层记忆、技能路由、执行约束与数据状态流转。

一、总体架构：四层模型

系统不搭建任何自研常驻服务，全部能力落在 hermes 之上：飞书 Base「Personal Assistant」是唯一真相源（Source of Truth），hermes cron 是唯一调度器，AI agent 负责判断，确定性脚本负责规则。

规范组件 → hermes 映射（反目标：自研服务）：

二、核心循环（Runtime Loop）

每一次运行都遵循同一条不变量，且禁止阻塞：

获取上下文 → 判断 → 执行 → 创建下一事件 / Scheduled Job → 退出

• AI 负责决策，hermes cron 负责时间：动态跟进绝不用 while-true 等待，而是用 one-shot job（hermes cron create "<ISO时间>" --repeat 1）；job 到点必须先重读最新状态再行动。
• 能不用 AI 就不用 AI：规则型判断（任务已完成→关闭跟进；睡眠时段→静默；无新邮件→结束）由确定性脚本直接按规则执行。
• 每次 agent 运行是短生命周期会话，退出即释放，不残留常驻进程。

三、技能协同与路由（Skill Collaboration & Routing）

入口是一个薄 Orchestrator SKILL.md：只做路由与最高层不变量，不含业务细节。业务细节全部下沉到 4 核心 skill 的 references/ 中，通过**渐进式披露（progressive disclosure）**按需读取，避免一次性占满上下文。

四个核心 skill 各自带 Trigger / Non-trigger / Required context / Expected output / Escalation / 何时读哪个 reference / 关键操作约束 契约：

触发源 → 核心 skill 路由表（Orchestrator 的心智）：

路由判断要点（来自真实踩坑的沉淀）：

• ⚠️ ” 记住/提醒我 + 具体待办 + 时间词 ” 不是记忆指令——” 记住今天下班去取花买菜 ” 是带时间窗的一次性行动，一律走 planning 建 Task + Block + 飞书投影，禁止只写记忆收场。
• 长期偏好（” 以后都/一般/总是 + 偏好 ”）→ 直写 profile.md。
• 状态/DND（” 今天很累/别烦我 ”）→ 写 current_state.md（带过期）。
• 拿不准按 ” 行动 ” 处理，防止误路由。
• 命名空间用 pea- 前缀，避免 review/memory 这类通用名与已装 skill 争夺触发；description 承担触发，name 承担挂载。

四、数据模型：Task ≠ Calendar（三层执行模型）

飞书 Base 是唯一真相源，飞书 Task / Calendar 只是投影。核心建模思想是把 ” 任务 ”、” 时间投入 ”、” 实际执行 ” 严格区分成三层：

Task（要达到的结果，可跨多天）  1 ──── N  Schedule Block（一次时间投入）
                                1 ──── N  Execution Record（实际投入、进度变化、阻塞）

• 一个 N 小时任务 = 1 个 Task + N 个 Block + 每块 1 条 Execution Record。严禁为长任务创建多个重复 Task。
• 块状态（planned/done/missed/cancelled）与任务状态（active/completed/deferred/dropped/cancelled）独立推进——块结束 ≠ 任务成败。
• Calendar 不是 Todo：保留 Buffer/Admin/Recovery/Personal；不以填满日历为目标；空闲 ≠ 可用，需区分 Usable Free Time 与 Recovery Time。
• 进度模型按任务类型选：binary（简单任务）/ percentage（progress+remaining_minutes）/ checkpoint（里程碑驱动）。
• Done Definition：模糊任务（如 ” 研究 LangGraph”）必须转成可结束状态清单，写入 tasks.done_definition。

飞书 Base「Personal Assistant」—— 八张核心表 + 一张审计表

飞书投影一致性规则（强制闭环）：

1. Base 是唯一真相，飞书 Task/Calendar 只是投影，冲突时以 Base 为准并修复投影。
2. 投影条件：P0-P2 且有 deadline 的任务同步飞书 Task；需外部可见的时间块写飞书 Calendar，并回填 feishu_task_id / calendar_event_id。
3. 投影必须带 assignee，否则 +get-my-tasks 看不到。
4. 闭环自检：写完必须确认两个回链表都已回填，缺任一即视为未完成。
5. 多步写（Base + Calendar + IM）用 correlation_id 串联审计；中途失败记 failure_state=partial/failed + 补偿提示。

五、三层记忆与反馈学习（Memory）

记忆位于本地 ~/.hermes/personal-assistant/memory/，私有、不入库，与 skill 分离。核心思想是把记忆按生命周期分成三层，并通过 ” 反馈 → pattern → profile” 链路持续学习用户。

反馈 → 记忆晋升链路（核心）：

单次纠正/观察 → current_state（短期，有过期）
      │ 同类证据反复出现（correction + execution_records 偏差）
      ▼
patterns（evidence_count+1，confidence 更新）
      │ evidence_count ≥5 且 confidence ≥0.7，或用户明确确认
      ▼
pea-review(evening/weekly) 向用户确认一次 → profile（长期）

• 单次纠正永不直接进 profile，唯一例外：用户显式长期偏好（” 以后都/一般/总是 + 偏好 ”）→ 当场直写 profile 并回复强调写入层（” 已写入 profile：…”），不许只口头说 ” 我会记住 ”。
• 衰减：last_seen 超 30 天无新证据 → confidence 降一档；<0.3 标 inactive 移出决策依据（保留记录不删除）。
• 用户纠正处理四步：① 立即修正计划；② 记 is_correction=true；③ 短期决策依据写 current_state（默认 7 天过期）；④ 归并评估是否形成 pattern。

六、端到端事务生命周期（数据状态流转）

一次事务从进入系统到最终落地，经历完整的状态流转。所有写操作强制 审计 + 幂等 + 可撤销。

链路 1：用户 DM 进入

DM → Orchestrator 路由 → capture 归一化为候选事务
  → 行动类 → triage（定档 P0-P4 + 五种处置 + 反向质疑）
      → SCHEDULE → scheduling 排 block
      → DEFER/等待 → 建 follow-up one-shot
      → 写 Base tasks + 飞书 Task/Calendar 投影（闭环自检）
      → 记 assistant_actions（correlation_id）
  → 状态/纠正/DND → memory 写 current_state（带 expires_at）
  → 长期偏好 → memory 直写 profile
  → 想发消息 → communications notification-decision
  → "现在做什么" → next-action

链路 2：邮件轮询（cron pea-email-poll）

hermes cron → email_poll.py（拉 IMAP + 飞书邮箱，seen-ID 去重）
  → stdout JSON 注入 → communications 分类定级分流
  → Action Required/Deadline → planning triage 建任务
  → Waiting For → 建 follow-up one-shot
  → FYI/Newsletter 归档；L3 只起草草稿
  → 紧急 → notification；其余 → pending_notifications.json 聚合
  → 无新邮件 → [SILENT]

链路 3：持续跟进闭环（dynamic one-shot）

创建方判定需跟进 → hermes cron list 查重
  → hermes cron create "<ISO|30m>" --repeat 1 --name pea-followup-<task_id>
  → 到点触发 → job_guard.py 前置检查（完成/睡眠/DND → 空输出退出）
  → follow-up 重读 Base 当前状态（禁直接用旧上下文）
      → completed/cancelled/dropped → 关闭自我清理 → [SILENT]
      → 未完成 → 通知策略判定 → 提醒一句 / 或按间隔策略创建下一次 one-shot → [SILENT]

跟进间隔动态（禁止固定 30 分钟）：deadline<2h→15-30min；今日到期/P1→1-2h；常态→数小时到隔天；随临近逐步缩短、连续无变化则拉长，避免骚扰。

五种处置（Triage）

DO（立即/今天做）· SCHEDULE（排具体时间）· DEFER（明确延后到新时间，非无限搁置）· DROP（取消记原因）· DELEGATE/AUTOMATE（委托或建议自动化）。

优先级 P0-P4

• P0 — Interrupt：短时间不处理有明显损失/错过窗口/阻塞关键人员。判定必须严格——邮件标题写 URGENT ≠ P0。
• P1 — Today · P2 — Soon(2-3 天) · P3 — Planned · P4 — Optional。

幂等与可撤销清单

七、注意力策略（Attention Policy）

系统把注意力也当作需要管理的资源：每条主动消息必须同时回答 ” 值不值得打扰 ” + ” 现在适不适合打扰 ” 两问。这是所有 skill 想给用户发消息前的强制门槛（pea-communications 的横切职责）。

第一问：值不值得打扰（任一满足即值得）——P0/P1 新事务或风险、阻塞他人、外部承诺风险（L2/L3）、用户明确关心的话题。
反例（不值得）：Newsletter 摘要、P3/P4 常规状态变化、” 帮你归档了 3 封 FYI”、每个 Calendar Block 结束后的例行确认。

第二问：现在适不适合打扰（时段判定）：

处置：

1. 可发 → 直接作为输出（投递由 hermes --deliver 完成）。
2. 非紧急但值得知会 → 写 state/pending_notifications.json，由 pea-free-window 在空闲窗口聚合推送，或并入下一次简报。队列消息格式固定：” 发生了什么 + 我已做了什么 + 建议动作 + 预计耗时 ”。
3. 不值得 → 输出 [SILENT]（hermes 抑制投递）。

静默机制三层：agent job 输出 [SILENT]；no-agent 脚本空 stdout；排队聚合 pending_notifications.json。
确认预算：早/中/晚各至多一次批量确认，周日一次总确认；此外不主动询问任务状态。

八、一天的时间轴（cron 调度）

hermes cron 是唯一调度器，7 个固定 job + 动态 one-shot 构成了 ” 一天 ” 的自动化节奏。

全部 job --deliver feishu:oc_…（可被 integrations.yaml notify_chat 覆盖），推送到飞书私聊。

九、安全与自治边界（Guardrails）

一个高自主的助理必须同时具备 ” 能做多少 ” 的授权边界与 ” 敢承担后果 ” 的审计护栏。

自主边界（L0-L3）

• L0 信息确认 → 可自动。
• L1 常规沟通 → 可自动，记审计。
• L2 时间/任务/普通业务承诺 → 规则允许时自动，超出问用户。
• L3 重大金额/合同/法律责任/重大业务承诺 → 必须升级用户，只起草不直接发。

默认自动执行（个人可控范围）：创建/调整/延后任务、移动 Calendar 块、取消普通任务（记原因可撤销）、创建跟进、自动回复低风险邮件、重排今日。

六条硬约束规则（rules/）

时间与日期安全（真实踩坑的教训）

• ” 今天是服务器的今天 “，不是会话里任何旧日期。任何涉及 ” 今天/现在/明天/下班前 ” 的决策、排程、cron 创建第一步执行 date '+%F %T %z' 确认当前日期。
• epoch 禁心算：毫秒时间戳用 date -d … +%s%3N 生成，并用 date -d @<s> 回读校验（跨年错误是真实故障）。
• Base datetime 传 ISO 字符串（如 "2026-08-19 18:30"），不要传毫秒数字——否则解析错年。

十、总结

这套系统最核心的设计哲学是一句话：不做自己不该做的事，把每件做过的事都留下可追溯的痕迹。

1. 不造常驻服务——Scheduler/Worker/Job Store 全部复用 hermes cron，AI 决策与 cron 时间解耦。
2. 飞书 Base 唯一直相——Task/Calendar 只是投影，通过双向回链强制闭环；冲突以 Base 为准。
3. 渐进式披露——薄 Orchestrator + 4 核心 skill + references 惰性加载，控制上下文成本。
4. 三层记忆 + 反馈学习——短暂状态不污染长期偏好，只有反复验证的证据才晋升 profile。
5. 注意力是资源——一切消息过两问门槛，[SILENT] 是默认态而非例外。
6. 全量审计 + 可撤销 + 幂等——L0-L3 授权边界 + assistant_actions 兜底，让它 ” 敢自动做、也担得起后果 ”。

本文基于 life-skills 仓库中 skills/personal-executive-assistant/（V1）的真实源码整理：Orchestrator SKILL.md、4 核心 skill、rules/ 六条硬约束、docs/{architecture,data-model,operations,v1-adjustment-plan}.md，以及 image/助理架构图/ 下的 9 张架构图。