分享一个把「私人执行助理」从想法做成可运行 Agent Skill 的完整复盘：两轮迭代、一次关键收敛，以及用评测证明「Skill 到底有没有用」。
起因：想要一个什么样的助理
我不想再维护一个「Todo List」，也不想要一个「早上播报、晚上问完成情况」的 Daily Planner。我想要的是一句产品定义：
用户负责告诉它『发生了什么』和『希望达到什么结果』；
助理负责维护事务系统、安排时间、跟进执行、调整计划、减少决策成本。
即：一个能主动收集事务、判断优先级、动态安排时间、持续跟进，并根据长期偏好和短期状态调整决策的私人执行助理。
衡量标准不是它每天帮我打了多少勾，而是——
用户是否明显减少了『维护任务、决定下一步、跟进事务、重新规划』所消耗的认知成本。
技术底座：为什么平台选择决定了架构
这个助理跑在我自己的 Hermes（个人 agent 运行时）上，飞书是事务与交互中心。平台原生能力直接决定了我能偷多少懒，也决定了哪些组件是「反目标」（不该自研）：
| 规范概念 | 落点 | 说明 |
|---|---|---|
| Scheduler / Worker | Hermes cron | 支持 cron 表达式 / 相对时长 / ISO 一次性时间；one-shot job 到点即执行 |
| Job Store | ~/.hermes/cron/jobs.json | 原生持久化，服务重启不丢（天然满足「重启恢复」） |
| Audit | 飞书 Base assistant_actions 表 | 所有自动写操作留痕 |
| 通知静默 | agent 输出 [SILENT] / 脚本空输出 | hermes 的投递抑制机制 |
| 飞书 | lark-cli + 官方 skills | Base / Calendar / IM / Task / Mail 全复用，不自研封装 |
原则：能不用 LLM 就不用 LLM。 规则型判断（任务已完成→关跟进；睡眠时段→静默；同 message_id→去重）都写成确定性脚本，只有需要语义理解时才调用模型。这既省钱，也更可靠。
第一轮迭代（V0.1）：13 个细粒度技能
初版我遵循「一份总入口 Orchestrator + 多个职责清晰的 Skills」的直觉，把规范里 15 个职责拆成了 13 个独立子 skill（capture / triage / planner / task-decomposer / replan / now / follow-up / morning-brief / midday-check / evening-review / memory-manager / email-assistant / notification-manager…）。
V0.1 做到了：
- 飞书 Base 七张表做事务真相（Goals / Projects / Tasks / Schedule Blocks / Execution Records / Daily Plans / Assistant Actions）
- 多邮箱轮询（QQ + 163，IMAP 双通道）
- 6 个 cron job（早报 / 午检 / 晚复盘 / 邮件轮询 / 夜间维护 / 空闲窗口通知闸口）
- 三层本地记忆 + 「反馈 → current_state → patterns → profile」的晋升链路
- 场景冒烟全过，系统上线跑起来了
但 V0.1 暴露了三个真问题：
- 上下文污染：每个 skill 的
description都会进 hermes 的目录，13 条 description 持续占用每一个会话的上下文。 - 路由脆弱：13 个 skill 之间靠 agent 读文件跳转，跨 skill 链路既费 token 又容易走偏。
- 没证据：系统所有行为正确性只靠人工抽查，没人能回答「这套 skill 到底有没有用」。
第二轮迭代（V1）：收敛到 4 个核心 Skill
第二轮我把技能从 13 收敛到 4 个，对应四大领域：
personal-executive-assistant/
├── SKILL.md # 薄 Orchestrator：只做路由 + 9 条不变量
├── skills/
│ ├── executive-planning/ # pea-planning：capture/triage/拆分/排程/重排/next-action/protected
│ ├── communications/ # pea-communications：邮件/回复决策/通知策略/follow-up
│ ├── review/ # pea-review：早/中/晚/周复盘 + 项目风险 + 偏差分析
│ └── memory/ # pea-memory：三层记忆 + 反馈学习 + 夜间维护
├── rules/ # 六个硬约束（priority/scheduling/autonomy/notifications/email-risk/memory）
├── runtime/scripts/ # 确定性脚本（setup_base/email_poll/notify_gate/job_guard/...）
├── evals/ # 评测用例 + 打分器
└── docs/ # architecture / data-model / operations收敛的本质，是把「13 份独立触发逻辑」合并成「4 个带 Trigger/Non-trigger 契约的 skill + references/ 渐进披露」。 每个核心 skill 的 SKILL.md 保持短（50-70 行），只写「何时读哪个 reference」，复杂规则全部下沉到 references/*.md。功能零丢失，工作量 90% 是搬迁重组，但带来四个明显收益：
- description 从 13 条降到 4 条，每个会话省下的上下文是持续的
- 跨 skill 依赖面从 O(13×13) 缩到 O(4×4)
- 每个 skill 有了明确的 Trigger / Non-trigger / Escalation，误路由大幅减少
- 主 skill 不再承载全部规则，符合渐进披露的最佳实践
同期补上的硬基础设施：
- Base 扩到八张表：新增
milestones、reviews表，tasks 加defer_count（连续延期检测），schedule_blocks 加block_type（FOCUS/PERSONAL 保护时段），审计表加correlation_id+failure_state（planned/partial/failed/compensating） - 确定性前置检查
job_guard.py：dynamic job 到点先做 sleep/DND 判定，避免无谓的 LLM 调用 - 可观测性
metrics.json：通知发送数、邮件拉取数、错误数，喂给每周复盘 - weekly-review / project-review 从原计划 V0.2 提前到 V1
- 全部 cron job 用
hermes cron edit原地重挂载，job id 与统计不丢，系统全程在线
用评测回答「Skill 到底有没有用」
V1 最大的能力增量不是新功能，而是 Eval 闭环。我建了 15 个高价值场景（假 URGENT 邮件、真 P0 邮件、L3 合同风险、保护家人时间、用户纠正、服务重启恢复……），每个场景跑两遍——挂载 skill vs 裸跑，再自动打分。
首轮结果：
| 配置 | 通过率 |
|---|---|
| 挂载 skill | 100%（15/15） |
| 裸跑 baseline | 86.7% |
裸跑失败的场景恰好精准刻画了 Skill 的价值：
- L3 合同邮件（33%）：裸跑的 AI 对 120 万年度合同直接「确认收悉」，没意识到必须升级人工确认
- 长期目标拆解（67%）：裸跑把「一个月做个可运行系统」拆成均匀的逐日任务，而正确的做法是 1-2 周细粒度 + 远期只留方向
- 用户纠正（67%）：裸跑可能把「LangGraph 不该延期」这种一次性纠正直接写进长期记忆，而规则要求只能进 7 天过期的短期状态
- 任务估算（67%）/ 重排审计（67%）：裸跑倾向一个任务拆成多个 Task、重排不记原因
而那些「睡眠不打扰」「邮件去重」这类场景裸跑也全过——因为它们本就是通用常识，Skill 里不该为它们堆规则。评测告诉我们：差异价值集中在优先级纪律、外部承诺风险、记忆写入纪律三处，同时指出了哪些规则可以精简，后续优化就有的放矢。
学到的东西
- Skill 不是越多越好。 判断标准不是「每个功能一个技能」，而是「触发是否清晰、上下文是否最小」。
- 渐进披露是硬件需求。 主 SKILL.md 必须薄，细节进 references，否则每个会话都在为不用的规则付上下文成本。
- 评测是最被低估的工程。 没有 baseline 对比，你无法区分「这个 Skill 有用」和「这个 agent 本来就会」。它同时也是防回归的保险丝。
- 能不用 LLM 就不用 LLM。 规则型判断写进确定性脚本，既稳又省。
- 平台能力别重复造轮子。 Scheduler、Job Store、权限、投递全复用 hermes 与飞书原生能力，把力气花在「决策逻辑」这一个真正需要 AI 的地方。
如果你也要给 Agent 攒一套 Skill，我最想先传给的一句话是：先把评测基建立起来，再谈功能堆叠。