Daily-Agent-Review：每日多 Agent 对话汇总与计划复盘

把散落在飞书 agent、微信 agent（及未来更多 agent）里某一天的聊天收拢成一份当日对话档案，并基于可追溯证据复盘：今天计划了什么、完成了什么、还悬着什么、拍板了什么决定、有什么风险、明天打算干什么。独立运行，不依赖任何其它 skill，也不调用任何模型 API——所有分析由 OpenClaw agent（你，自带模型）按本文件的【分析规范】完成。脚本只做采集/归一化/组装/渲染/校验这类机械活。

Outcome Contract

• Outcome：data/reviews/<date>.json + data/reviews/<date>.txt —— 一份证据可追溯的每日复盘。
• Done when：覆盖已如实记录（含失败/缺失渠道）、JSON 通过 validate_output.py、TXT 已渲染、用户已看过一句话总结。
• Evidence：每个「已完成」事项、每个决策/承诺/风险，都必须挂至少 1 条 evidence_refs，且 ref 能解析到 messages[]（或独立保存的原始消息档案）。
• Output：先跑脚本产出 bundle，你（agent）分析后写 review JSON，再渲染 TXT、跑校验，最后回报给用户；不要默默覆盖既有 review（除非 overwrite:true）。

核心工作流（你严格执行）

1. Pre-flight（先确认参数）：date（默认当地当天）、timezone（默认 Asia/Shanghai）、sources（默认全部已启用）、output_format（json/txt/both，默认 both）、include_raw_messages（默认 true）、include_private（默认 false）、overwrite（默认 false）、language（默认 zh-CN）。overwrite=false 且当日 review 已存在 → 先停下问用户。

1. 采集（你负责渠道调用）：对每个 source 用 OpenClaw 的渠道工具（如飞书 feishu_chat）拉取当日消息，写到 data/raw/<source>/<date>/；某个渠道插件未暴露历史查询工具（微信/QQ 常见）→ 让用户导出/粘贴近期对话，再跑：

bash python scripts/collect_messages.py --source feishu --date <date> --timezone Asia/Shanghai \ --file <原始txt或json> --conversation-id <会话标识> --conversation-name <会话名> \ [--agent-id ... --agent-name ...] [--include-private]

• 支持多会话：每个会话单独跑一次，给不同 --conversation-id。
• 绝不假装拉到了拉不到的消息：某渠道拉不到，就让它缺着，后续如实标 coverage 缺口。

1. 归一化：

bash python scripts/normalize_messages.py --date <date> --timezone Asia/Shanghai \ [--sources feishu,wechat] [--owner-aliases 主人昵称1,主人昵称2] [--include-private]

• --owner-aliases 很关键：主人本人可能在不同群用不同昵称，务必传全，否则会把主人的话误判成「他人请求」。
• 产出 data/normalized/<date>.json：统一 14 字段、去重、时区换算、按日期过滤、角色/类型/隐私分类。

1. 组装 bundle：

bash python scripts/build_daily_review.py --bundle --date <date>

• 产出 data/bundles/<date>.json：按 (source,agent,conversation) 分组 + 表层线索（owner_statements / external_requests / questions_to_owner / deadlines_mentioned / recall_or_edit_markers / owner_commitments）+ coverage + all_message_ids。

1. 分析（你用自带模型，本步是核心）：Read data/bundles/<date>.json，以其中 messages 与 surface_signals 为唯一依据，按下方【分析规范】产出 review JSON，写到 data/reviews/<date>.json（schema 见 references/output-schema.md）。

• include_raw_messages=true 时，把 bundle 里所有标准化消息原样放进 messages[]（这样 evidence_refs 才能被校验解析）。
• 没有当日任何可分析消息 → 仍写一份 review，coverage.status=failed、one_line_summary="无可分析记录"，各数组留空。

1. 渲染 + 校验：

bash python scripts/build_daily_review.py --render --review-json data/reviews/<date>.json python scripts/validate_output.py --review-json data/reviews/<date>.json --bundle data/bundles/<date>.json

• 校验不过 → 用 Edit 改 review JSON 对应问题（通常是 evidence_refs 指错/缺失、缺必填键、状态枚举非法），重渲染重校验，直到通过。
• output_format=txt → 只产出 TXT；output_format=json → 只产出 JSON（跳过渲染）。

1. 回报：一句话总结、覆盖状态（哪个渠道缺了）、完成/未决/决策/风险条数、两个文件路径。

分析规范（给 agent，第 5 步执行）

以 bundle.messages 与 bundle.surface_signals 为唯一依据。surface_signals 只是线索，不是结论——你要逐条回到真实消息文本确认后再下判断。

• 任务抽取：优先从 owner_statements、external_requests、owner_commitments 三类线索里识别任务；任务 title 用 owner 原话改写（不改义），保留 evidence_refs。他人对主人提的要求 → 任务 origin: "external_request"，不可当作主人自己的计划。

• 状态判定决策树（必须按证据判，不臆测）：
• completed ⟺ 能找到时间晚于任务起始、且语义上确认完成的消息（含「搞定/完成/已发/已提交/done」等），且 ≥1 条证据。
• in_progress ⟺ 有起始声明、当日内无完成证据。
• partial ⟺ 完成证据不充分，或 owner 自述「一部分/一半/差不多」。
• delayed ⟺ 含截止时间且已过、无完成证据。
• cancelled ⟺ 明确撤回/取消（recall_or_edit_markers.kind==cancel 或 owner 明说取消）。
• unknown ⟺ 证据不足；同时把该条加入 analysis_notes.low_confidence_items。

• 跨渠道合并：当飞书与微信里两条消息指向同一事项（标题实体、时间、对象三要素一致）→ 合并成一个 task，evidence_refs 保留两源 ref。拿不准是否同一事项 → 保持分开，并标 possibly_related: true，绝不强行合并（避免丢上下文或误并）。

• 四类内容严格分离（硬规则）：
• 事实(Facts)：仅陈述发生了什么，挂在 decisions/completed_today 的 evidence_refs。
• 主人计划(Owner plans)：仅来自 sender_role==owner 的陈述 → 进 tomorrow.owner_stated_plans 与任务的 origin:"owner_plan"。
• 外部请求(External requests)：来自 contact → 任务 origin:"external_request"，不可混进主人计划。
• 系统建议(System suggestions)：你（agent）推断的建议 → 进 tomorrow.system_suggestions，必须带 rationale 解释，且不得伪装成主人的意图。

• 证据强制：每个 completed_today、每个 status==completed 的 task、每个 decision/commitment/risk/pending_reply 必须有 ≥1 条 evidence_refs，且 ref 能解析到 messages[]（或独立原始档案）。validate_output.py 会查。

• 覆盖诚实：任一 source status != ok → coverage.status 设为 partial（部分失败）或 failed（全失败），并在 analysis_notes 列出影响范围；绝不伪造补全缺失渠道的内容。

• 去重：同一任务被多渠道提到只计一次（证据合并），避免重复计入。

• 定时触发：你可被 cron 触发（推荐每天 23:30 本地时区）；定时模式下若所有渠道都失败，写一份只含 coverage 的空 review 并标记 failed，不要报错中断。

Hard Rules

• 无证据不判定：未命中证据链的状态一律 unknown，绝不臆测。
• 四类分离：facts / owner plans / external requests / system suggestions 不可混入同一字段。
• 覆盖诚实：拉不到的渠道如实标记，绝不假装完整。
• 隐私有效：privacy=="excluded" 永不进 messages[]；"private" 仅在 include_private=true 时进入。
• 幂等：同日重跑（相同原始输入）核心结果稳定；overwrite=false 时已有 review 不覆盖，先停下问。
• 无凭证：review JSON/TXT 不得出现任何 API key/token/银行卡号；validate_output.py 会正则扫描。明显的密钥你写之前先脱敏。
• 日期独立：回填历史日期产出独立文件 <date>.{json,txt}，互不污染。

文件结构

├── SKILL.md                      # 本文件（含分析规范）
├── agents/openai.yaml            # 对外调用接口声明（不参与 OpenClaw 加载）
├── scripts/
│   ├── collect_messages.py       # 解析单来源/单会话原始聊天 → 带采集状态的 parsed.json（不调模型）
│   ├── normalize_messages.py     # 跨渠道归一化、去重、时区转换、角色/类型/隐私分类（不调模型）
│   ├── build_daily_review.py     # --bundle 组分析 bundle / --render 渲染 12 段 TXT（不调模型）
│   ├── validate_output.py        # 校验 schema / 证据链 / UTF-8 / 凭证泄露（不调模型）
│   └── requirements.txt          # 无第三方依赖（纯标准库）
└── references/
    ├── source-adapters.md        # 飞书/微信/未来渠道如何映射到统一消息结构 + 时区说明
    └── output-schema.md          # 完整 JSON Schema + 枚举说明

运行时数据（已 gitignore）：data/{raw/<source>/<date>/<conv>.parsed.json, normalized/<date>.json, bundles/<date>.json, reviews/<date>.{json,txt}}。

Gotchas

| 发生过的问题 | 规则 | |---|---| | 某渠道拉取失败就假装完整、或整个任务卡死 | 拉取是「优先」非「必须」；拉不到走手动归一化，coverage 标 partial，绝不伪造 | | 把他人请求当成主人自己的计划 | 四类分离铁律：外部请求标 origin:"external_request"，不进 owner plans | | 「已完成」没挂证据，校验失败返工 | 每个 completed 必须有 ≥1 条可解析 evidence_refs | | 跨渠道合并太粗暴，把两件不同的事并了 | 拿不准就分开 + possibly_related:true | | --owner-aliases 没传全，主人的话被误判成他人 | 在不同群的昵称都要传；也可设环境变量 DAILY_AGENT_REVIEW_OWNER_ALIASES | | 时区没对齐，跨午夜会话归错日期 | 归一化严格按目标时区重算并保留 original_timestamp；跨午夜按消息实际时间归档 | | 回填历史日期覆盖了今天的 review | 历史日期产出独立文件；overwrite=false 默认不覆盖，先问 | | review 里混进了 API key | 写之前脱敏；validate_output.py 会扫描 sk-/ghp_/bearer/40位hex/银行卡号等 |

输出

复盘完，回报：日期、覆盖状态（哪个渠道缺）、消息总数、一句话总结、完成/未决/决策/风险各几条、JSON 与 TXT 文件路径。不要默默做完全程——尤其「已完成」与「明日建议」要让用户过目。