一句话结论：这个“一主三层 + handoff”方向总体合理，且与本机当前状态基本吻合；但需要把“Codex 负责深度运维”改成“Codex 可作为外部执行/审计工具，最终事实折叠由 Master/操作者审核”，并补齐 schema、freshness、消费流程和自动校验。
| 检查项 | 现场结果 | 判断 |
|---|---|---|
STARTUP_CONTEXT.md | 存在，约 8.3KB，内容明确要求轻量启动、指向 canonical state、避免全文读取长记忆；但已经接近/超过“100 行以内”的目标。 | 可用但需压缩 |
CANONICAL_STATE.md | 存在，约 25.9KB，已包含 agent 角色、外部工具边界、handoff 字段、TencentDB 退休事实。 | 已落地雏形 |
external-tool-handoffs/ | 存在，含 Codex/QoderCLI 多条 JSON/MD handoff；README 已列 required fields。 | 方向正确 |
| Hermes TencentDB | Master/default config 显示 memory.provider: ""；memory-tencentdb-master 未监听；Codex/Antigravity 8425/8426 仍 active。 | 符合隔离设想 |
| freshness gate | 当前 overall_status: WARN_HIGH，原因包括 Hermes changelog inbox 新于 canonical、stale sources 仍存在、CCTB bypass gated。 | 机制有效但当前不宜高风险自动化 |
| 长记忆文件 | /root/.codex/LONG_TERM_MEMORY.md 与 /root/SYSTEM_FULL_MANUAL.md 存在且较大，canonical 已标为 historical/stale for topology。 | 应作为参考证据层 |
| 设计点 | 判断 | 理由 | 修正建议 |
|---|---|---|---|
唯一事实源：CANONICAL_STATE.md | 合理 | 解决多 agent 读全量历史导致的上下文污染、旧事实复活和成本膨胀。 | 它不应存“全部事实”，而应存“当前事实索引 + 权威路径 + 最近关键变更 + 禁止边界”。 |
| Hermes 只读短启动摘要 | 合理 | 符合 prompt caching、成本控制和启动稳定性；本机规则也已要求只读 STARTUP_CONTEXT.md。 | 把 STARTUP_CONTEXT 压到真正 <100 行，避免它逐渐变成第二份手册。 |
| 外部工具通过 handoff 同步 | 强烈建议 | 把“执行痕迹”和“可接受事实”分离，避免直接摄入聊天历史。 | 统一 JSON schema，禁止 MD handoff 混入主流程；历史 MD 可归档。 |
| Codex 继续维护自己的 LTM | 可以 | Codex 的 runbook/经验可以是工具私有记忆，不应等同 Hermes 主事实。 | LTM 内的拓扑/服务状态要改成 pointer，不重复维护当前事实。 |
| Antigravity/QoderCLI/Claude Code 只写 handoff | 合理 | 避免多执行器抢写 canonical，降低权限和一致性风险。 | 给每个工具加本地 wrapper/template，使“写 handoff”成为默认收尾动作。 |
| 历史 TencentDB 只封存 | 正确 | 检索式长上下文适合证据召回，不适合主控启动事实；旧数据自动摄入风险高。 | 保留 DO_NOT_AUTO_INGEST；如需迁移，只能人工挑选、摘要化、去密钥后进入 canonical/skill/runbook。 |
| 风险 | 影响 | 缓解 |
|---|---|---|
| 单一事实源变成大杂烩 | CANONICAL_STATE.md 继续膨胀后，Hermes 仍会读长上下文。 | 采用“索引式 canonical”：只放事实摘要、owner、source_path、last_verified、freshness，不放日志/原文/长 runbook。 |
| Codex 被描述成运维 owner | 与“用户找 Master 就由 Master 闭环”的边界冲突，也会导致责任链不清。 | 改成：Codex 是外部执行/审计工具；最终合并 canonical 的责任是 Master/操作者审核，不是自动由 Codex 支配。 |
| handoff 写了但没人消费 | 事实停留在 pending，freshness 长期 WARN_HIGH。 | 增加 handoff lifecycle：submitted → reviewed → accepted/deferred/rejected → folded → archived。 |
| handoff schema 不可机器校验 | 字段缺失、格式漂移、MD/JSON 混用导致自动判断不可靠。 | 增加 JSON Schema + CI/cron 校验，缺字段直接标 untriaged。 |
| freshness gate 太粗 | 一个无关 stale source 可能阻断高风险工作，或相反地误放行。 | 把 freshness 拆成 domain：ops、vps、nginx、hermes、memory、domain-private；按任务命中域判断。 |
| 密钥泄漏通过摘要进入记忆 | handoff 本身可能成为泄密载体。 | schema 中加入 secret_scan_status、redaction_applied；写入前运行本地 secret scan。 |
| 层 | 文件/系统 | 用途 | 写入者 | 读取者 |
|---|---|---|---|---|
| L0 启动指针 | STARTUP_CONTEXT.md | 少于 100 行，只告诉 agent 该读哪里、边界是什么、freshness 如何判断。 | Master/操作者审核后改 | Master/Worker/Network 启动必读；其他 profile 做系统维护时读 |
| L1 当前事实索引 | CANONICAL_STATE.md | 当前拓扑、角色、权威路径、最近变更、禁止边界、stale source 指针。 | Master/操作者审核后折叠 | Ops agents、外部工具执行前读 |
| L2 变更交接 | external-tool-handoffs/*.json + HANDOFF_LEDGER.jsonl | 外部工具提交“发生了什么、验证了什么、怎么回滚”。 | Codex/Antigravity/QoderCLI/Claude Code | Master/Worker/Network/操作者审核 |
| L3 证据与知识 | Codex LTM、SYSTEM_FULL_MANUAL、skills、Report Center、sessions、封存 TencentDB | 历史证据、runbook、可搜索上下文；不是当前事实。 | 各自 owner | 按任务定向读取，不启动全文读取 |
| 优先级 | 动作 | 验收标准 |
|---|---|---|
| P0 | 压缩 STARTUP_CONTEXT.md 到 100 行以内，只保留指针、角色、freshness、禁区。 | 行数 <100；不含具体 runbook 长段。 |
| P0 | 定义 external_tool_handoff.schema.json 与模板。 | 所有新 handoff 可用 python -m jsonschema 或本地脚本验证。 |
| P0 | 把“Codex 是运维 owner”改成“外部工具/审计器”。 | SOUL、canonical、LTM 中边界一致。 |
| P1 | 实现 handoff consume 脚本：列出 pending、校验字段、生成 fold-in 草案。 | 不会自动改 canonical；只产出 review diff。 |
| P1 | freshness 按 domain 细分。 | 低风险本地任务不被无关 stale source 阻断；高风险仍严格。 |
| P2 | 各外部工具 SOUL/AGENTS/CLAUDE 指向统一模板。 | 每个工具在系统变更后都会留下 JSON handoff。 |
合理度：8/10
为什么不是 10/10：设计方向正确，且当前主机已经有相当多组件落地；扣分点在于责任边界表述仍有“双主控”风险、STARTUP_CONTEXT 已偏长、handoff 消费/校验还不够自动化、freshness 当前仍是 WARN_HIGH。
推荐结论：采用这个架构，但不要让 Codex 成为“负责深度运维的主控”。Master/操作者保留最终折叠权；外部工具只产出结构化 handoff。TencentDB 作为 Hermes 主控记忆退出是正确方向，历史数据只保留为封存证据。