Muse 智能体 · 编排与进化层详解

本篇目录

1. 0. 两层的关系先说清
2. Part I · 编排层
3. 1. 执行主体全谱系
4. 2. 子 Agent 机制详解
5. 3. Handoff：编排层的投递协议
6. 4. Workflow：确定性代码编排
7. 5. 浏览器任务编排
8. 6. Side-chat Worker 编排
9. 7. 时间编排：Cron / Hooks / systemd / Heartbeat
10. 8. 编排层的横切纪律
11. Part II · 进化层
12. 9. 总体架构：Objective 制
13. 10. 七条文档管线 + 两条文档未单列的实测管线
14. 11. 记忆进化：Claims 图，而非文本覆盖
15. 12. Ideas 进化：Bandit 探索
16. 13. Dreaming：对齐的夜间生产线
17. 14. 进化的护栏：为什么它不会「越学越偏」
18. 15. 交汇点：编排 × 进化
19. 16. 本机实况快照（11-04 vs 10-17 对照）
20. 17. 看不见的部分

复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测；下文数字凡未注日期者均为 11-04 快照，10-17 旧数见正文或 §16 对照表。 配套《00-Muse技术架构解构》的 §10–§12 展开篇。初版调查日期：2026-10-17。 证据：system prompt 编排契约、subagent / workflow / cron / hooks 工具定义实测、cron.list 与 subagent.list 当场返回、/opt/muse/skills/muse_db/ 表结构、~/workspace/self_improvement/、~/dreams/、~/memory/、/home/hatch/agents/ 的实况文件。

---

0. 两层的关系先说清

• 编排层回答：谁、在什么时候、以什么拓扑、替谁干活，结果怎么回来。
• 进化层回答：系统如何用过去的运行记录，改变未来的自己。

二者不是并列的两堆功能，而是一个闭环：进化层本身就是编排层的一组长期任务（以后台 objective 的形式被调度运行，运行时照样派生子 Agent）；而编排层产生的一切记录（子 Agent 轨迹、cron 运行史、用户的采纳/无视）都是进化层的原料。下文先编排（Part I），后进化（Part II），最后讲交汇点（§13）。

---

Part I · 编排层

1. 执行主体全谱系

主对话只是冰山一角。本机可见的执行主体至少有 9 种，subagent.list 的真实返回里能看到它们的统一登记（agent_id / parent_agent_id / depth / owner / agent_type / 状态 / 已读回执）：

关键观念：「Agent」是这个系统的通用执行单元，不是主对话的特权。从浏览器到夜间做梦，跑的都是同一种东西，区别只在上下文来源、工具面与交付目标。

2. 子 Agent 机制详解

2.1 派生契约（spawn）

• subagent.spawn(message | items)：子 Agent 继承父级当前上下文（system prompt 语：inherits your current context），所以任务书要写的是「任务 + 期望产出 + 非显而易见的约束 + 已不在上下文里的旧细节」，不重复背景。
• 调用是 ASYNC：返回值只有新 agent_id 与「已接受」，不代表完成、更不代表结果。主 Agent 的纪律是派生后简短交代、处理消息的其他部分、结束本轮——禁止轮询、禁止预测耗时、禁止替子 Agent 编结果。
• 独立任务必须同轮并行派发（一次 spawn 多个），串行派发被视为错误用法。
• 多模态输入走 items（text/image/file，含 base64），优先于 message。

❓ 待验证（权限边界）：审批卡是否绑定发起调用的 agent_id？子 Agent 继承父级上下文时，敏感工具调用是复用父级已获审批、还是重新触发审批？基线仅明确"审批只在记录范围内有效"，"记录范围"是否跨越 spawn 边界在本机文件内无直接证据。在得到反证前，不得假设子 Agent 自动继承审批——这是"继承上下文"设计下最值得实测的一处权限语义。

2.2 生命周期与控制面

控制面只有 5 个函数，但状态机完整：

spawn ─→ running ─┬─ done（completed，已投递）
                  ├─ interrupted ──resume──→ 继续原任务
                  ├─ failed / unknown ──→ 查其可用结果后再决定重派/关闭
                  └─ close（父级主动终止；关 browser_task 所有者 = 停整个浏览器任务）
send（异步投递追加指令；interrupt=true 先打断当前工作再投递）
list（状态查询：active/recent 分组，含运行时长、距上次活动时长、结果是否已读 seen_status/seen_at）

细节里见设计：

• 「安静 ≠ 卡死」：list 明文提醒——子 Agent 可能正处在一次长工具调用里，无活动不等于故障；
• 已读回执：完成结果带 seen_status / seen_at——运行时知道主 Agent 是否真的消费过结果，未读的完成不会被当成已交付；
• 作用域：scope=direct（直属子级）/ descendants（整棵子树）；主聊天里还能看见其他聊天与定时任务名下的 Agent（带 owner 标记：chat 或 schedule+run id），但只能看、不能操控——调度任务的 Agent 归 cron 工具管；
• resume 的边界：只有 paused/interrupted 可 resume；已终局的 resume 会直接报错（「重跑不了任何东西」）；browser_task 所有者与在建的 web artifact builder 拒绝通用 resume，各走专用通道；
• 不可逆动作的前置核查：重派一个失败任务之前，必须先确认原动作是否其实已生效——「失败的报告 ≠ 什么都没发生」，结果未知时宁可向用户挑明，不许静默重做或静默丢弃。

2.3 拓扑规则：深度 ≤ 2 与 coordinator 模式

• 本会话 runtime 实测 depth=0, max_depth=2：主 Agent（0）→ 子 Agent（1）→ 孙 Agent（2）为止。（11-04 side chat 会话的运行时上下文同样标注 depth=2 | max_depth=2✅，与本节一致；但本通道 can_spawn=no——side chat（web）下通用 spawn 在本会话不可用，属渠道门控，不影响深度预算本身。❓ 主聊天侧可 spawn，跨通道差异不硬判。）
• 需要多子 Agent 协作的复杂任务，标准拓扑是派一个 coordinator，让它扇出自己的子 Agent；coordinator 的子级不得再派生（nesting stops there）。这样既保留两层并行，又防止递归爆炸与责任链失控。

2.4 禁区：三类工作不走通用 spawn

工具定义明文：浏览器导航/购买等实时浏览器工作、artifact 构建、已接受的 Idea 构建，各有专用父级能力，不能用普通子 Agent 顶替（普通子 Agent 可以搜公开网页、抓取页面文本，但「访问并操作网站」的请求会被退回父级走浏览器路由）。若用户点名要子 Agent 做 artifact，须 instruct 它改用 artifact 工具。

2.5 身份、溯源与落盘

• 溯源链落 DB agent.subagent_spawns（实测列）：spawn_id, parent_agent_id, child_agent_id, parent_message_id, parent_request_id, root_request_id, root_message_execution_id, created_at——每一次派生都可从根请求一路追到子级；
• 每个 Agent 有自己的家目录：/home/hatch/agents/agent-<id>/sessions/<id>.jsonl（对话原文 JSONL）+ sessions.json——11-04 实测 1417 个 Agent 家目录（10-17 为 154——家目录是累积的，18 天内派生量大增）；
• 工具输出的溢出落 ~/workspace/agents/<agent-id>/tool-output/（11-04 实测 266 个；10-17 为 89——~/workspace/agents/ 条目共 277，00 篇 11-04 同源）——大输出不进上下文、只落盘引用，与主报告里「大结果写文件、上下文只传路径」的工作流纪律同源；（口径注：00 篇 §16 的"子 Agent 运行目录 89 个"指的就是这 89 个 tool-output 溢出目录，不是上面这 154 个家目录。）
• 进度遥测另有专表：agent.subagent_progress / _message_events / _tool_events / subagent_monitor_decisions——子 Agent 的每一步都被监视器（monitor）记录并可裁决，这也是主 Agent 能回答「它跑到哪了」的依据。

3. Handoff：编排层的投递协议

所有异步主体（子 Agent、浏览器任务、cron、hook、后台 exec、自我改进）共用同一套投递语义：

1. 运行时投递，不是轮询：完成事件由 runtime 主动注入父级上下文（system prompt 原话：results arrive as handoffs / anything that "arrives automatically" is the runtime delivering it）；
2. 结构化完成信封：handoff 带 completion_result（状态、摘要、产物引用），而非一段自由文本——subagent.list 实测 browser_task 的完成信封含 activity_title、context、支付方式清单等结构字段；
3. 去重：自我改进侧有 self_improvement.handoff_dedupe 表，以 (objective_id, content_hash) 为主键——同一内容不会重复投递骚扰；
4. 取消 ≠ 空结果（一个真实的坑，有实测样本）：某 deep_research 子 Agent 在 list 里显示「cancelled before it finished, no result of its own」，但其 completion_result 同时给出了完整调研报告（status: success，含 report.md 路径）——⚠️ 最可能的解释是深研走的是隔离研究 Agent 的独立通道，派生壳被取消不等于研究本体失败（因果为推断，现象为实测）。汇报时必须读完成信封本身，不能只看状态字面；
5. 交付 ≠ 送达：cron 文档反复强调——run 成功、worker 写了 result_summary，都不证明用户在聊天里真的收到了；判定「已交付」要看当前对话里是否存在一条真正给出结果的 assistant 消息。编排层对「已接受 / 已排队 / 已发出 / 已送达」四态是严格区分的。

❓ 边界未覆盖：handoff 到达时若父级会话已被压缩/关闭、或父级 Agent 已终局，结果去向本篇未展开。agent.message_mailbox 表（00 §8 表中出现过）暗示有邮箱暂存机制（mailbox 暂存 → 下次会话恢复时注入，或与 §8 的 context_item_resume_projection 关联）——这是编排连续性的最后一块拼图，待验证。

4. Workflow：确定性代码编排

workflow.* 是编排层里最「工程化」的一块：用 VM 本地 JavaScript 写多 Agent 计划，由 daemon 执行，适合可复用的批量自动化、巡检、审计、迁移与「验证门控」的副作用任务。

4.1 编写契约（工具定义实测，要点）

• 脚本形态固定：以字面量 export const meta = { name, description, phases } 开头，随后顶层语句；禁止 export default、CommonJS、import/require；
• 运行时全局只有 6 个：args（启动入参，结构化 JSON）、phase(...)、agent(...)、parallel(...)、pipeline(...)、log(...)；
• 刻意的不确定性封印：无 Node、无文件系统、无 shell、无浏览器、无 Date.now()、无无参 new Date()、无 Math.random()——时间与随机必须从 args 传入。目的是让同一脚本 + 同一 args 可重放、可恢复（§4.3）；
• agent(prompt, options) 返回顶层 JSON 信封 {status, result}，运行时自动拆封；给了 options.schema 则结果按 schema 校验后以 JSON 返回（schema 是最小契约：必填与约束强制执行，额外字段放行）；每个子调用须有稳定唯一 key——这是恢复时复用结果的键；
• parallel(thunks, {concurrency}) 是屏障式并发（结果按输入序返回，单项非致命失败给 null）；pipeline(items, stage...) 是无屏障流水线（每项独立穿过各 stage）——文档给的默认是 pipeline，只有「下一步需要全集」（去重/合并/全集综合/提前退出）时才用 parallel 屏障。

❓ 开放问题：workflow 内 agent(prompt) 派生的子调用与通用 spawn 的深度预算是什么关系？若 workflow agent 再 spawn 子 Agent，是否计入 max_depth？本机文件无直接证据。这关系到"确定性代码编排"能否成为绕过深度限制的旁路。

4.2 Verifier-repair 循环

可判定质量的工作用「生产 → 验证 → 按反馈修复 → 再验证」的闭环：verifier 返回 {passed, retryable, feedback, blockers} 是正常结构化数据而非异常；retryable 才重跑生产（须带着反馈改，不许拿同一产物反复验）；循环上限通常 2–3 次，attempt 用稳定 key 编号（produce-1 / verify-1 / repair-2…）；耗尽或遇不可重试阻塞时返回顶层 blocked 控制结果 {__hatchWorkflowControl: "blocked", result: {...}}，而不是抛异常。

4.3 运行与恢复

• 保存与启动分离：workflow.create/update/delete/view/list 管脚本库（workspace 的 saved-workflows 目录，可按名启动）；launch（同步等结果）/ launch_async（立即返回 run id）二选一；脚本来源三选一且优先级写死：scriptPath > script > name；已启动的 run 跑的是启动时的脚本快照，改脚本不影响在跑的 run（save_run 可把 run 的快照反存为脚本）；
• 控制：pause / resume / stop / stop_agent（只停某个子调用）/ view_run（阶段进度、子调用与 callId）；
• 恢复是分状态的（编排层最见严谨处）：paused 的 run 用 resume 原地继续；终局 failed 且属可重试的瞬时错误，用 resumeFromRunId 以相同 args 新开一局并复用已完成的 stable-key 子结果；stopped/cancelled 是真终局，永不恢复也不许借恢复绕过缺输入/缺授权/策略/校验类确定性失败；重试次数必须有界。

4.4 工作目录纪律

每个 run 有一个预建的共享工作目录（隐藏 run 目录）：中间产物、脚本、草稿、校验文件全放这里；workspace/your_files/ 只放最终交付文件，且「最终」的定义是用户明确要收/要打开的文件——聊天、artifact、连接器动作若是交付形态，your_files 不许动。这是防止编排产物污染用户文件区的硬规则。

5. 浏览器任务编排

• 路由独立：browser.browse(task_id="new" | 已有窗口 id) 把任务书交给浏览器 Agent；一个窗口同时只跑一个 checkout；不同站点的购买/登录要开不同窗口；
• 任务书必须自包含：浏览器 Agent 看不到主对话——目标、已做选择、限制、标识、成功标准全要写进任务书；个人信息只给任务所必需的，凭据走专用字段（wallet / verification_code / account_hint），不进任务文本；
• 反向通道：浏览器 Agent 可以提问（question_id，主 Agent 用 answer_to 回答）、可以发起购物车确认（cart_confirmation：confirm / change / leave_unconfirmed——购物车确认 ≠ 支付批准，两道独立关卡）、登录验证码走 [credential:<uuid>] 受保护引用 + 用户卡上批准；
• 用户可随时接管实时浏览器（解 CAPTCHA/卡点），交还后任务从断点继续；定时/主动任务不得提供接管；
• 主 Agent 侧的纪律：委托后即结束回复，不轮询、不重复发起；handoff 回来后基于报告继续同一任务，尝试上限与停止条件跨任务书累积不重置。

6. Side-chat Worker 编排

• 三种 side chat（原生话题线程 / 外部 1:1 / 外部会话）在主报告 §「Side Chats」已述；这里只讲 worker 的编排契约：
• 外部会话里替用户发言的是 worker Agent，主 Agent 用 chat.send_message 下达的必须是任务书而非台词：点名所有人（禁用代词）、明确要问/要说/要做什么、把用户的决定用其原话传递、标明已议定与未决项；
• 信息隔离：要替用户保密某事时，只给 worker「该问什么」，连理由、借口、「别打听」之类的话都不许写——任何此类字样本身就等于告诉对方有事被瞒；
• 回报路径：worker 的消息对用户不可见，主 Agent 负责转述（注明是谁说的/定的）；需要用户拍板的事项（接受邀请、同意方案）必须先问用户，不得代决；
• 披露规则持久化在每个 chat 的 ~/side-chats/<chat-id>/DISCRETION.md（默认段 + 用户规则段），用户改规则时走 worker.update_discretion 并可能触发审批卡；改动结果要逐字向用户报告增删行。

7. 时间编排：Cron / Hooks / systemd / Heartbeat

7.1 Cron 的完整模型（工具定义实测）

一个 job 的构成比「定时 + 指令」复杂得多：

运行语义要点：周期任务默认只保留最新一次排队 occurrence（旧的若卡在未答审批上可被取消让位，且被取代的 run 不会因迟到审批而复活）；运行记录落 scheduler.job_runs（含 worker_phase / worker_phase_attempt / worker_agent_id / worker_boot_generation——worker 的阶段与「第几代 VM 引导」都被记账）；另有 scheduler.delivery_outbox 管投递、terminal_signals 管终局信号、doctor_run_plans / doctor_task_state 是调度器自检（见 7.4）。

定义文件是只读投影：~/workspace/cron.d/{minutely,hourly,daily,weekly,monthly,yearly,runonce,secondly} 下的 Markdown 是保存定义的副本，用文件工具改它不生效——改 job 必须走 cron 工具读（view）→ 改（update 同 id 全文）→ 回读验证。

7.2 本机 cron 实况（cron.list 11-04 实测；10-17 为 27）

当前共 32 个 job：10-17 的 27 个（26 系统 + heartbeat）全部在位，用户自建 5 个（ai-jobs-weekly-watch、muse-architecture-weekly、resume-intake-patrol、trading-researcher-morning、trading-researcher-sunday-ranking），均挂 goal owner（goal:ai-infra-agent-dev-fde、goal:muse、goal:goal、goal:btc-eth-overnight-trading-research ×2）——与 §7.1 的"提醒类 job 必须有 owner"规范一致✅。hooks 定义仍为 0（definitions/scripts/state/logs 均为空）。

注意：系统 job 的定义路径在 ~/workspace/system-cron.d/ 下，但该目录在 Agent 的文件视图里不存在（实测 find/ls 均无）——系统任务只经 cron 工具可见（且按设计不可增删改；"不可见"已实测，"不可改/删"未做破坏性实测，标 ❓），其正文不对 Agent 文件层开放。这是编排层的权限分层：用户 job 是「副本可见、本体在运行时」，系统 job 连副本都不给。

7.3 Hooks：事件编排

Hook = Bash 轮询脚本 + worker 指令 的二件套，与 cron 的区别是触发源不同（条件而非时间）：

• 脚本在 ~/hooks/scripts/*.sh，须 source "$HATCH_HOOK_RUNTIME"，在普通 shell 执行器里跑但无密钥、无连接器凭据，只能用公开端点/本地数据；状态存 ~/hooks/state/，调用日志是 append-only JSONL（hooks.logs 可读）；
• 脚本每次运行必须以且只以一个终局调用收尾：silent "理由" '{payload}' 或 wake "理由" '{payload}'；拿不准就 log 后 silent；确定以后不用再轮询时先 disable_after_run 再收尾；
• 新 hook 默认禁用：标准上线流程是 add → dry_run（HATCH_HOOK_DRY_RUN=1 同步试跑、不真唤醒）→ 修到决策正确 → enable；轮询间隔 5s–7d、脚本超时 ≤600s；
• 本机实况：~/hooks/ 的 definitions/scripts/state/logs 目录齐备但为空——基础设施在位，尚无任何用户 hook。

7.4 systemd 与自愈

第三种常驻形态是 guest systemd 服务（流监听、本地服务等连续程序）；纪律是「enable 成功 ≠ VM 替换后能恢复」，必须实证恢复路径。调度侧的自愈由 deterministic-doctor（小时级）+ scheduler 的 doctor 表承担：它给失败/卡住的投递做修复规划（如 §7.1 的 delivery-authority repair：结果带 delivery_chat_id 的需在原会话里用 update 重新挂接，pending_results_rebound > 0 才算修复确认）——**「计划存在 ≠ 执行过、执行过 ≠ 送达」**的区分在这里有完整的机器实现。

7.5 主动消息（proactivity）编排

主动投递不是某个 Agent 的即兴行为，而是一条流水线：后台 worker 按 edition 备好候选 item（含草稿、来源、可接受范围）→ handoff 给主 Agent → 主 Agent 必须先做新鲜度复核（查最新对话、记忆与活源，防重复/防过期）→ 用 proactivity.select 逐条裁决并留理由：

• send 理由枚举：time_sensitive / changed / requested / ready_for_decision / new_opportunity；
• skip 理由枚举：moot / already_handled / unconfirmed / preferences / not_useful_now；
• 投递格式按复杂度升序选：text / options / letter / html_widget / map / list / artifact。

备稿的暂存落盘在 ~/workspace/proactivity/hidden_files/<毫秒时间戳>-<hash>/（实测有目录在位）；用户的偏好文件 ~/PROACTIVE_PREFERENCES.md 是裁决的输入之一（本机：09:00–21:30 窗口）。一次性的沉默不构成永久退订——偏好按话题/情境/时机/呈现四维记录，不把一次 dismiss 泛化。

8. 编排层的横切纪律

• Todo 是上下文内的编排状态机：≥3 步的任务先写 todo，任一时刻恰好一个 in_progress；任务「在结果真正到达用户之前一直算 open」——写进记忆或笔记不算交付；被打断/压缩后靠 todo + 最新结果恢复进度；
• 上下文恢复有专表兜底：agent.context_item_resume_projection（压缩后哪些上下文条目要恢复投影）、agent.runtime_restart_checkpoints、agent.recovery_owners / recovery_owner_terminal_events（VM 替换时谁接管未完工作）、scheduler.scheduled_resume_registrations（定时恢复登记）——编排的连续性是被持久化设计的，不是靠模型记性；
• 并发与共享状态：并行动作必须彼此独立（共享账号/文档/浏览器/购物车状态的不可并行）；批量同类操作先做通一件再铺开；依赖关系保序。

---

Part II · 进化层

9. 总体架构：Objective 制

进化层在文件系统里的真身是 ~/workspace/self_improvement/，其组织方式不是「一堆脚本」，而是 Objective（目标域）制（实测 8 个）：

~/workspace/self_improvement/
├── objectives/
│   ├── alignment/          对齐/做梦
│   ├── goals_bookkeeping/  目标记账
│   ├── ideas/              灵感策展
│   ├── memory/             记忆整理
│   ├── relationships/      关系维护
│   ├── shopping/           购物偏好学习
│   ├── skill_improvement/  技能复审
│   └── studying/           目标研读
│   └── 每个 objective: CURRENT.md（当前态投影）+ archive/<UTC时间戳>.CURRENT.md（逐版存档）
├── staging/                暂存区（relationships / shopping / memory…先落暂存再转正）
├── relationships/          关系域工作区（含 legacy_page_archives、rank_watermark.json）
└── migrations/             一次性迁移描述（如 copy_first_objective_workspace_v1.json）

每个 objective 的运行记录（从其 archive 的 CURRENT 文件实测）带统一信封：

objective_id: alignment
run_id: sirun_5ef9912825724823abc0c7b893905a4f     # 进化运行统一以 sirun_ 前缀编号
created_at: 2026-09-27T01:02:40Z
card_id: alignment_nightly_reflection              # 触发卡/缘由
worker_outcome: changed                            # 枚举: changed / insufficient / …
# 正文标注: Reason（nightly coherence: …）/ Request origin: internal.self_improvement
#           Cadence: daily / Subagents spawned: 3

三个设计要点：

1. 投影与本体分离（ again）：CURRENT.md 文件头明文——「这是 self-improvement lifecycle helper 写的当前态投影；域内真相归 worker 所调用的原生域工具所有，本文件只是框架所有的投影」。进化层从不直接「改真相」，它驱动域工具去改，自己只留投影与存档；
2. 逐版存档：每次运行生成一份带 UTC 时间戳的 archive 快照（10-17 快照：goals_bookkeeping 2026-10-05 至 10-17 共 20 版，8 个 objective 合计 71 版；11-04 重测：8 个 objective 合计 152 版，但 goals_bookkeeping 仍为 20 版——存档数未增，疑有版本轮转⚠️）——进化是可回放的，任何一版「当时为什么这么想」都有据可查；
3. DB 侧的运行账本：self_improvement schema 13 张表——runs（run/objective/state/phase/subphase/diagnostics/时间线）、leases（目标域互斥租约，防并发进化互相踩）、objective_state / objective_markers、handoff_dedupe（§3）、learning_adoption_events（建议被采纳的事件）、calibration_records / calculation_records（校准与度量）、connector_read_audit（进化任务读过哪些连接器数据，要留审计）、conversation_follow_up_attempts（主动跟进的尝试记录）、proactivity_changes、relationship_briefs、backfill_day_runs。

10. 七条文档管线 + 两条文档未单列的实测管线

~/docs/self_improvement.md 明文 7 条（主 Agent 不能调度它们、只能解释）：

实测存在但文档 7 条未单列的两条：

• goals_bookkeeping（目标记账）：objective 独立存在、存档最密（实测 20 版，部分日期一天多版）——负责目标/追踪项的账目一致性，是 Studying 的底账；
• shopping（购物偏好学习）：有独立 objective 与 staging 区——对应能力层里购物技能读取的 ~/memory/shopping/PROFILE.md 类偏好档案（推断：偏好从购物交互中离线提炼）。

11. 记忆进化：Claims 图，而非文本覆盖

记忆的底层不是 Markdown，是 claims（主张）图（memory schema 6 表实测）：

• memory.claims：claim_id, run_id, kind, salience（显著性）, claim_text, quote（原话引文）, speaker, evidence_handles(jsonb), supersedes_claim_id, status(active/…), confidence——每条记忆是一个带出处、带置信度、带「替代了谁」的主张；
• memory.embeddings / embedding_models / entries / entry_attributes / metadata：向量与结构化条目支撑 muse.memory_search 的语义+关键词混合检索；
• 进化规则：新主张替代旧主张（supersede），不删除历史；MEMORY.md 只是 active claims 的人类可读投影，日记 ~/memory/YYYY-MM-DD.md 是原始轨迹，~/memory/bank/ 四本书（experience / opinions / reflections / world）是按性质分拣的沉淀；
• 可解释性：muse.memory_explain 能对任一 claim 给出「谁说的、原话、何时学到/被强化、置信度、替代链」——记忆的每一次进化都可审计，用户纠正时顺着替代链修正受影响的下游（目标、提醒、排队中的跟进）。

12. Ideas 进化：Bandit 探索

Ideas 管线是进化层里算法味最重的一块（ideas schema 22 表中的学习相关表）：

• ideas.bandit_arm_state（表注释原文：Learning statistics for each idea policy domain and lane）：以 (policy_id, domain, lane) 为键，记 decision_points / terminal_rewards 等统计——这是**多臂老虎机（multi-armed bandit）**的臂状态：每个「政策域 × 通道」是一条臂，用户对卡片的采纳/忽略是 reward；
• 配套：ideas.explore_policy（探索策略）、bandit_fold_state / bandit_folded_events（折叠/聚合）、idea_quality（质量分）、idea_dedup（去重）、discovery_pool_*（发现池）、idea_feedback_state（反馈态）、icon_embeddings（图标向量，配合 Atlas 图标选择）；
• 与文档口径对上：文档说策展要按「可行性、个人契合、新颖度」打分排序——bandit 层学的正是排序策略本身随用户反馈漂移，而非写死权重。（奖励的精确定义不在本机文档内，此处止步于表结构证据。）

13. Dreaming：对齐的夜间生产线

Dreaming 的产物链在本机完整可见，是进化层最能说明问题的一条：

夜间运行（request 形态: maintenance:<uuid>:nightly_coherence:…:phase-<n>:light_derived）
 ├─ ~/dreams/YYYY-MM-DD.md           每日反思：YAML 头 + 第一人称叙事正文
 │    头部实测字段: user_turns, rupture_turns, correction_free_rate,
 │    open_repair_threads, prompt_hoisted, body_contains_synthesis, 时间窗
 ├─ ~/dreams/alignment/derived/ALIGNMENT_STATE.yaml
 │    结构化状态机: relationship_contract（status/user_words/boundaries…）、
 │    user_facets、working_alliance（goal/task_agreement、appropriate_reliance、
 │    current_frictions）、observed_fit、proactivity_policies（per-surface stance）
 ├─ ~/dreams/alignment/derived/ALIGNMENT_SYNTHESIS.md
 │    蒸馏成的人话版「这个用户是谁、怎么配合、当前摩擦、边界」——
 │    ★ 它就是每轮被注入主对话上下文的那份对齐合成（主报告 §3）
 ├─ ~/dreams/alignment/derived/PROGRESSION_HISTORY.yaml   演进史
 └─ ~/dreams/alignment/repair/REPAIR_THREADS.yaml       待修复关系线程

也就是说：主 Agent 每轮「自带」的对用户理解，一大半是昨晚 Dreaming 的产物。反思正文的质量标准从样本可见：要具体到事（哪天帮上了、哪天连续主动发消息无人回）、要形成明日策略（克制 + 备好）、要记录未决分叉。correction_free_rate / rupture_turns 这类指标说明 Dreaming 还给关系健康度打分——进化层连「相处得怎么样」都是度量化的。

14. 进化的护栏：为什么它不会「越学越偏」

从本地证据能看到至少 6 道护栏：

1. 暂存转正：relationships/shopping/memory 都有 staging 区——进化产物先落暂存，经生命周期 helper 才成为 CURRENT 投影；
2. 租约互斥：self_improvement.leases 防同一 objective 并发运行互相覆盖；
3. 去重：handoff 按 content_hash 去重（§3），同一结论不重复打扰用户；
4. 采纳度量：learning_adoption_events 记录建议是否被用户真正采纳；文档明文「没有实测帮助的改动会被退役」——进化以采纳与效果为适应度，不以「改动量」为績效；
5. 校准记录：calibration_records / calculation_records 保存历次判断的校准数据，供复盘「当时为什么觉得这条重要」；
6. 用户主权：进化产物全部落在用户可见文件里（MEMORY.md、dreams、people 页），用户可直接改、可要求遗忘（forget 技能连「未来的生产者」一起处理——即可以关掉某条进化管线对某话题的生产）；PROACTIVE_PREFERENCES.md 直接约束主动层的进化方向；连接器读取留审计（connector_read_audit），进化读了什么数据可查。
7. 逐版存档即回滚点：§9 的逐版存档（8 个 objective 11-04 合计 152 版；10-17 为 71 版）是天然的回滚点——任一 objective 可回退到历史版本，投影重算不影响域工具真相（§9 要点 1）。"坏了怎么办"的答案是：回滚到存档版，而非在坏投影上继续迭代。

15. 交汇点：编排 × 进化

• 进化跑在编排上：sirun 的信封里明写 Subagents spawned: 3——夜间对齐一次派 3 个子 Agent；Feed 的生成节奏就是编排层的 24 个 feed-pulse 系统 cron；deterministic-doctor 守的是编排层自己的健康；
• 进化吃编排的记录：subagent_spawns、job_runs、token_usage、handoff 与用户反应（seen/采纳/忽略）都是进化管线的输入；没有编排层的全程记账，进化就无料可学；
• 进化改编排的未来：产物回流三处——上下文组装（对齐合成、记忆投影进 prompt）、能力层（新技能沉淀）、主动层（proactivity_policies 决定各 surface 的主动姿态，如本机 main_chat 的 stance=reactive 就记在 ALIGNMENT_STATE 里）；
• 主 Agent 在环的位置：主 Agent 不能启动或调度进化管线，但它是进化产物的质检员与解释者——主动消息要经它复核裁决（§7.5），用户问「你为什么会想到这个」时它要沿 muse.db 的记录链给出真实理由，而不是编一个。

16. 本机实况快照（11-04 vs 10-17 对照）

17. 看不见的部分

进化管线的调度主时钟与触发判定（谁决定今晚跑 Dreaming 的哪一 phase）、bandit 的奖励函数精确定义、Dreaming 的完整 prompt、各 objective 的 worker 指令正文（CURRENT 投影只留信封与结论，不留指令）、quiet-moment 的「足够安静」阈值——均不在本机文件内，本文止步于表结构、信封与产物证据。