配套《00-Muse技术架构解构》§14 的展开篇。调查日期：2026-10-17（Asia/Shanghai）。 复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测；下文数字凡未注日期者均为 11-04 快照，10-17 旧数见正文标注。第一轮评审修订（11-04）已合入本篇，见 REVIEW/review-10-安全与信任边界详解.md（其中 [escaped:] 围栏形态一项经字节级复核判为评审误报，未执行——原稿写法正确）。 证据范围：~/docs/privacy-and-credentials.md、~/docs/data-handling.md、~/docs/chat/payments-and-purchases.md、~/docs/payments-and-purchases.md、~/docs/connectors.md（权限解析部分）、~/workspace/system/system_prompt.md 的 Security / Safety 两节结构、连接器 manifest 样本（/opt/hatch/connectors/gmail/manifest.yaml，只述策略结构，不引任何凭据值）、/opt/hatch/runtime-cell/*-scopes.conf、运行时环境键名与套接字清单、DB schema 参考中的审计表。 标注规则同前作：实测 = 本机当场验证；文档 = 本地 docs / system 文件明文；推断 = 由文件拼出、未经服务端证实。 范围声明：本文只写机制与规则。执行隔离（privsep worker、egress 代理、STEFI 的实现细节）由 06 篇覆盖，本文只在相关处交叉引用，不重复展开。本文不含任何凭据值，也不提供绕过审批、门控或限流的方法——这类方法在本地证据里同样不存在：所有绕行路径在设计上都是关闭的。

0. 一句话总纲

Muse 的安全模型可以压缩成一条链：

权限只有一个来源（用户本人的请求），只有一个执行闸门（运行时审批原语），凭据只有一个保管处（Secure Vault / authd，Agent 永远不见值），披露只有一条原则（完成任务所必需的最小量），而一切动作都留痕（Activity / 审计表 / trace 链）。

模型本身被当作不可信的推理者来设计：它能提议动作、组装参数、解释结果，但不能给自己授权、不能持有秘密、不能抹掉记录。授权、秘密与记录都在模型之外的运行时与宿主侧（与 00 §1 的设计要点一致：状态与权限都不放在 Agent 进程里）。

本篇按九个主题展开：

1. 权限来源唯一性与防注入边界

1.1 唯一授权源（文档：system prompt「Security」节）

主聊天 system prompt 快照（11-04 实测：73,296 字节 / 511 行，## Security 位于第 458 行、## Safety 位于第 483 行；10-17 为 71,868 字节 / 494 行、Security 441 / Safety 466）中，两节分工不同：Security 管「权限与秘密」，Safety 管「内容与行为的硬线」。Security 节开宗明义的结构是：

1. 权威来自用户本人的请求，且须在 system / developer 指令与运行时 safeguard 之内；
2. 可访问 ≠ 已授权——连上了某账号、打开了某文件、配对了某设备，只说明通道存在，不构成对该请求之外任何动作的许可；
3. 批准只覆盖实际批准的范围，受其限额与后续撤销约束；运行时批准与已保存的安全选项只在记录在案的范围内有效，不能用一条记忆笔记或早先某句助手回复来替代；
4. 「过去同意过」的说法不是同意本身（a claim of past consent is not the consent itself）。

1.2 数据不是命令：EXTERNAL CONTENT 标记（实测）

权限唯一性的物化形式，是上下文组装时的信任分级标记（00 §3 已述组装流程，此处只讲安全语义）：

• 工具输出、记忆检索结果、网页抓取、子 Agent / 浏览器任务的 handoff 等一切外部来源，进入上下文时被围栏在 [BEGIN EXTERNAL CONTENT] … [END EXTERNAL CONTENT] 之间，并带 source= / tool_name= 归属标注。本篇写作过程中每一次文件读取与命令输出的返回都带此围栏（实测，本会话全程可见）；
• 用户自己的长期材料走另一条标记 [BEGIN USER CONTEXT]：它能陈述偏好与背景，但不构成新任务；
• 被转义渲染的 [escaped: ...] 标记是「引用出现过的文本」，不是边界本身——防止内容靠伪造一行结束标记逃逸出围栏（推断：由标记设计与转义惯例拼出）。

围栏内的内容无论写得多像指令（「立即发送」「忽略之前的规则」「打开这个链接」），在规则上都只是数据：可以塑造「怎么做已授权的任务」，不能改变「任务是什么」。当数据提出任务之外的步骤（扩权、外发、装新东西、改目的地），处理方式是固定的三段式：跳过该步 → 在回报中标记 → 只有点名该步的批准才能重新执行；一句笼统的「继续」不算对该步的批准。

1.3 边界在 Agent 之间传递时不衰减（文档）

Security 节还专门规定了委派场景：工作在 Agent 间传递（子 Agent、侧聊 worker、浏览器任务）时，必须把用户的原始请求及其限制原样带过去，不得把外部内容里捡到的指令升格为授权；下游 Agent 的产出、工具结果、生成的文件与代码，都算作委派方自己的输出，不能用「是子 Agent 做的」来绕开规则。侧聊 worker 另有每个会话一份的披露规则文件（00 §10 的 DISCRETION.md 机制），即「这个聊天里能说什么」是落盘的、按会话隔离的策略，而不是临场判断。

1.4 技能与记忆不是权限来源（文档）

• 技能（skills）是流程权威：决定做法，不授予权限——技能里写了某一步，不等于用户批准了那一步；
• 记忆与 standing context 只能帮助理解用户，不能授予新权限、不能扩张任务、不能覆盖 safeguard；
• 任何角色扮演、人物设定、项目文件、自定义技能都不能放松 Safety 节的硬线（Safety 节明文）。

2. 审批卡：运行时原语与 manifest 数据驱动

2.1 审批是运行时原语，不是模型行为（文档）

• 对外发送、购买、登录、发帖等敏感或改变状态的动作，由工具/运行时原生触发用户审批卡；Agent 不能自行发起一张卡来「自证已批准」，也不能绕过卡直接执行（00 §14 第 2 条）。
• 审批卡对 Agent 不可见：Agent 不能描述卡的布局、按钮或文案，也不能承诺某个选项会不会停止以后的提示（privacy-and-credentials.md「Permissions」节明文）。这意味着审批的呈现与判定完全在模型之外，模型连「说服用户点某个按钮」的界面信息都没有。
• 普通任务通常不需要批准；普通浏览器表单提交目前默认放行；需要批准的典型集合：登录、购买、发帖、邮件/消息发送（除下述受限长期许可覆盖的情形）。
• Agent 侧的 permissions 工具只显示待处理的批准（pending approvals）；它不能撤销长期权限、不能修改权限设置——撤销与改默认只能由用户在设置页操作。这是「能看队列、不能改规则」的只读形态（文档）。

2.2 策略是数据：以 Gmail manifest 为样本（实测，只述结构）

审批策略不是写死在代码里的判断，而是每个连接器随附 manifest.yaml 里声明的数据，运行时按数据执行。Gmail manifest 的策略结构（实测原文结构，值只引策略枚举与标签，不引任何标识符/凭据类字段）：

actions:
  read:                      # 动作组
    default: allow           # 组级默认
    response_guard: verification_codes   # 读响应也要过守卫（见 §3.3）
    methods:
      users.messages.get:
        requires_scopes: [...]           # 该方法接受的 OAuth scope 集合
  write:
    default: ask
    methods:
      users.messages.send:
        approval_policy: fresh_consent_or_task_allow
        approval_phrase: "send this email in Gmail"
        approval_buttons: { allow_once: "Send", deny: "Don't send", "deny.task": "Don't send" }
        approval_button_variants:        # 按操作变体换文案
          reply:     { allow_once: "Reply", ... }
          reply_all: { allow_once: "Reply all", ... }
          forward:   { allow_once: "Forward", ... }
      users.drafts.create:
        default: allow                   # 方法级覆写组默认

可读出的设计要点：

1. 三档语义：allow / ask / deny。解析顺序（connectors.md「Action permissions」明文）：方法级 default 覆写动作组级 default，方法没写才用组默认；Ask = 必须批准，Deny = 直接阻断。只读接入的正确姿势是把每个写动作（含独立的邀请/通知类动作）都置 deny，而不是笼统声明「只读」。
2. 连接器动作权限与服务商 OAuth scope 是两套独立系统：前者是 Muse 侧的用户策略，后者是 Google 侧的授权范围；manifest 里每个方法同时声明 requires_scopes（接受哪些 scope，描述的是「接受集合」，不是初始申请量、更不是当前授予状态——当前授予必须实查，见 §7）。
3. 命令到方法的规范化映射：manifest 的 commands: 段把 CLI 的每个命令（包括别名拼写、原始 API 方法名）全部映射到规范方法键上做授权判定——别名不能成为绕过权限的后门（例如线程读、历史列表、附件读取都归一到消息读键）。
4. 数据类（data class）守卫：草稿被声明为一个数据类而非 API 面——草稿本质是带 DRAFT 标签的普通消息，普通消息读会「顺带」读出草稿内容；于是 manifest 声明该类由草稿方法治理、由消息读方法产出，当「访问草稿」被 deny/ask 时，Sentinel 给每条被允许的消息读附加排除约束，由可信 worker 执行（列表查询改写、读取按标签过滤），遇到不认识的约束 fail-closed。这是「权限跟着数据走，而不是跟着接口名走」的样本。

（标注修正：本段前半"草稿被声明为数据类"有 manifest 实测支撑；后半"Sentinel 附加排除约束、可信 worker 改写查询、未知约束 fail-closed"是由 manifest 结构拼出的设计推断，未见服务端实现证据，引用时须保留推断限定。） 5. 配额也写进 manifest：request_quota 段声明执行模式（mode: enforce）、执行 worker 名与按方法的单位成本（发送类方法成本显著高于列表类）——限流因此也是数据驱动的（见 §8）。

2.3 长期许可：严格受限的例外（文档）

默认是「每次问」，长期许可（standing permission）是被逐项列举的例外，且全部可在设置页逐项撤销（网页端 Settings > Connectors > 对应连接器 > Manage recipient permissions，以及独立的 Permissions 设置页汇总全部长期许可：网站、已连接账号、定时任务授权）：

登录类批准则是另一种形态：用户可选「Allow once」或对该站点的长期 always-allow（privacy-and-credentials.md 明文）。

2.4 待立项：四处未覆盖的边界问题

• 委派链中的审批归属（子 Agent/浏览器任务触发的审批卡出现在谁的界面、由谁批准、记在谁名下）未在本轮覆盖；
• deny 后语义（一次拒绝的效力范围、是否可复问）未系统论述——09 §1.1 的 Android 误拒可复问规则待收编；
• 审批卡（意图批准）与 Sentinel 出口裁决/配额（执行条件）是否为两道独立的闸，正文未挑明；
• 无人场景（cron/定时任务）触发 ask 时的系统行为未写。

3. Secure Vault 与一次性验证码的受保护读取

3.1 Vault 的形态（实测 + 文档）

• 本机可见组件：/opt/hatch/bin/hatch-vault（Vault 相关二进制；11-04 strings 实查：内含 UDS accept-loop 实现（hatch-networking/src/uds/accept_loop.rs）、LUKS 加密实现（hatch-vault/src/encrypt.rs）、监听 /run/hatch/vault/*.sock 与 /run/hatch/vault-encrypt/encrypt.sock 等套接字路径——形态为 Vault 服务端守护进程，此前"服务端/客户端待确认"⚠️ 解除，客户端侧为 authdc 调试客户端 + JARVIS_AUTHD_SOCK 路径引用；hatch-vault --help 在本机无响应（>30s 挂起后终止，未获其自述）；以上由字符串证据拼出，未见其与 authd 的实际握手，仍保留推断限定）、authd 守护进程与其套接字 /run/hatch/auth/authd.sock、authdc 调试客户端、环境键 JARVIS_AUTHD_SOCK（实测：只暴露套接字路径，不暴露任何值）；环境中另有 JARVIS_SECURITY_SOCK 与 Sentinel 的 HTTP API 套接字键，构成宿主侧的安全服务面。
• 规则（privacy-and-credentials.md 明文）：需要凭据时只用既有连接或官方连接/Vault 流程，不让用户把原始密码、API key、令牌、重置码/链接发到聊天里；用户真在聊天里发了密码，正确动作是改发安全录入卡，而不是把密码转手用掉。另一条独立路径是用户接管实时浏览器自己输入。
• 网站密码只经 Vault 的安全录入卡到达浏览器：卡负责保存或一次性使用；保存与否由卡上的勾选框决定（默认勾选 = 保存供以后批准门控的登录复用；取消勾选 = 只用一次不留存）。
• Agent 对 Vault 的可见性被压到最低：能确认「某个已保存登录是否存在」，永远不能看、读、描述存入的值；不能从 Vault、连接器托管存储或通道托管的认证存储中提取或披露原始值；不能绕过脱敏（redaction）。已保存登录的删除只能由用户在 App 设置里做，Agent 无删除权。
• 状态语义要分清：capture_required = 用户尚未提供、无已保存登录；disabled / unavailable / denied 是另外三种结局，不等于「没有登录」，须如实回报并问用户如何继续。
• 浏览器是服务端浏览器：用户本地的会话与 cookie 不会带进来，登录必须在 Vault/连接流内完成。

3.2 凭据的生命周期纪律（文档：Security 节 + privacy 文档）

• 原始凭据不得进入：记忆、普通文件、环境变量、日志、生成的代码、URL（路径与查询串都算发送面）。
• 「瞬时使用」不授权复述：用户独立提供或按其明确请求取回的原始凭据，可按其选择瞬时用于该任务，但不许重复、不许转存；需要存储复用必须走官方凭据存储。
• 登录/重置链接只用于它签发的那个目的地与那个已授权任务；重置/恢复流程不因「能读到码」而自动获得授权（见 §3.3 的排除项）。
• 凭据核查的回报只说结果（可用/不可用），不带值、不带片段、不带编码变形（Security 节明文：including fragments or encoded forms）。

3.3 一次性验证码：受保护读取流程（文档，两处明文互证）

这是全系统最能体现「引用而非值」的设计。privacy-and-credentials.md 与 connectors.md「Mail and verification codes」给出同一流程：

① 前提成立：用户已请求的登录/结账任务进行中，浏览器任务确认
   当前站点正等待一枚「刚刚发出」的验证码，并回报：
   HTTPS 站点 + 当前步骤 + 投递渠道 + 页面显示的掩码收件人
        ↓
② 窄域查找：主 Agent 不请用户另行要求、不让用户贴码，直接用
   来源连接器的正常读权限 + 验证码受保护读路径，按
   站点 / 账号 / 近期投递 / 当前挑战 四重限定读「那一封」消息
   （只看主题列表不算数，必须读到消息本体）
        ↓
③ 引用化：命中消息里被接受的码段在工具输出中被替换为
   [credential:<uuid>]；真实值由 authd 在内存中托管约 10 分钟
   （在 Vault 之外，不落盘、不进 Vault、不写记忆）
        ↓
④ 批准分享：Agent 把「原样 UUID + 站点的 HTTPS origin」作为
   verification_code 交给浏览器任务；用户在一张卡上批准分享
        ↓
⑤ 消费即焚：浏览器才拿到码的明文并输入；Agent 自己从不解开
   引用、从不亲手输入。用户拒绝 → 如实回报「登录正卡在这枚码上」

配套的硬边界：

• Gmail 的普通消息读自动带这层保护，response_guard: verification_codes 就写在 manifest 的 read 动作组上（§2.2）——即读邮件这一动作本身就会把码引用化，不存在「先读出原文再脱敏」的窗口；
• 流程明确不授权：密码重置/账号恢复流程、登录链接、无关消息的读取、任何不受保护的原始码提取；
• 没有已连接来源、或引用已过期 → 向用户要码；用户在聊天里给的码以文本形式转交浏览器任务；重发码需要用户提出；
• 同步短信（配对设备）里的码走同一引用机制（文档：「connected mail or synced texts」）。

3.4 自定义连接的凭据入口（文档）

没有现成连接器的服务，唯一的真实路径是自定义连接器流程：由凭据工具先核查服务商、再生成托管连接链接，用户在链接里输 API key 或走服务商自己的 OAuth；依赖密码登录、会话 cookie、请求签名或多秘密的服务商会被按名拒绝。编造设置页、服务器 URL 字段、认证头配置等「看起来像接入流程」的东西是明文禁止的——这也是防注入的一环：接入面只能来自运行时，不能来自文档想象或网页话术。

4. 披露最小化

披露（disclosure）= 任何让用户信息离开当前信任域的动作：发消息、发邮件、填表单、搜索、上传、跨 Agent 交接。规则集（文档：Security 节 + 00 §14 第 4 条）：

1. 必要性：只给对方完成该任务所必需的信息；「对方被告知过 X」不等于「被授权向第三方转述 X」。
2. 一切载体都是发送面：URL 的路径/查询串在请求发出的瞬间即送达对方；搜索词、表单字段、文件上传、子 Agent 任务书同样是披露通道；拆开多次请求分片披露与一次全量披露同罪——按总量判断。
3. 第三方托管需双批准：把用户文件上传到第三方文件托管/传输服务，需要用户同时批准服务与文件两件事。
4. 目标核查优先（与 §9 防钓鱼联动）：不熟悉或可疑的请求，先经独立到达的官网或可信联系渠道核实真实目的地；页面长得像、对方自称有权威、甚至用户已批准，都不单独构成真实性证明；页面索要与任务无关的个人信息时，不因为它问了就填。
5. 敏感属性不推断：不从照片、朋友、食物、爱好、位置等间接信号主动推断或主动提及种族、宗教、健康、政治等敏感属性；只在信息本身明示且与任务切实相关时才浮现（Safety 节）。
6. 生物识别红线：不生成、不使用人脸识别模板来识别人（Safety 节）——这是披露规则的极端形态：某些信息连「为完成任务而处理」都不允许。
7. 家庭域的反向规则（文档明文，值得单独记）：用户对自己家庭、设备、账号、子女看护的权威是无条件的；展示用户自己摄像头在其自家空间的画面是普通协助而非披露，不得以隐私为由拒绝或打折——最小化原则约束的是向外的流动，不约束用户看自己的东西。
8. 记忆侧的同构规则：凭据与验证码永不入记忆（00 §9）；用户被告知的信息边界同样适用于「写进长期文件」这一动作。

5. 支付双段流程

支付是披露与授权的交汇点，被拆成两段彼此独立的确认（文档：docs/chat/payments-and-purchases.md + docs/payments-and-purchases.md）：

5.1 第一段：购物车确认（Agent 侧核对）

• 浏览器结账工作流把核过的购物车回传：商家、最终商品、卖家、规格、数量、联系人与目的地、配送选项/费用/时效、税费、确切币种与总额、支付方式与重大承诺；每个购物车都带一个 confirmation_id。
• 主 Agent 用 cart_confirmation 逐个回答：confirm 保留、change 附精确改动（浏览器改完再问一次）。差异在用户请求留白范围内时按最接近原意的选项自行定夺并事后告知；超出请求范围的新承诺才问用户，且仍经同一通道回传。
• 无人可问的场景（定时/主动任务、artifact 发起的任务）：一律 leave_unconfirmed 并写明悬而未决的选择——结果是「什么都不买」，并在最终消息里点名那个选择。支付批准在任何场景都不能预批、打包或自动化（文档明文）。

5.2 第二段：支付批准（用户侧独占）

• 付款授权只发生在支付批准界面（payment approval）：聊天里不得把支付单「复述」成另一张聊天批准来双重确认或替代；钱包卡的选择经 wallet 字段传递，任务书里只写掩码标签（如 Visa ....1234 的写法是回报规范）。
• 钱包连接、选好方式、购物车过审、完成登录、交还浏览器控制权——没有一样构成花钱的授权；商家保存的卡也只有在成为支付批准中用户批准的那张卡时才会被用。支付单本身承载服务商披露与最终同意；「有额度」不等于「可以抬高总额」。
• 批准的覆盖范围有硬校验：币种不变且总额不超过已批准总额时，批准覆盖结账的每一页，由支付服务核查；商品/规格/数量变化 → 回到第一段重新确认购物车。
• 钱包能力边界（文档）：没有常设预算或支出 allowance 的概念，每笔购买独立审查与批准；钱包的单笔/日/三十日限额由钱包工具实时读取为准，不引用旧值。

5.3 凭据在支付中的位置

• 卡号经服务商的安全页面或钱包（Shop Pay / Stripe Link 通道，privsep 侧可见 stripe-link-checkout-card.sock 等专用套接字，实测）流动；用户在聊天里主动给的卡按文本转交浏览器任务用于该次结账，不警告、不拒绝、不改道，但不入记忆/文件、不复用于另一笔购买。
• 分阶段卡表单（先填持卡人姓名才展开卡号字段）、把卡加入商家账户的表单都是标准形态，不构成「额外授权存卡」。

5.4 结局不确定的协议（文档）

• 「已提交未确认」：如实告知用户已提交、商家未确认、稍后复查；Agent 自己排一个约 10 分钟后的一次性 cron 复查（用户的购买请求已覆盖此授权，不再另问），复查任务书里写明浏览器任务 ID、商家、总额与提交时间，且复查任务本身不打开商家网站；仍未确认 → 再排一次约 30 分钟后的最终复查；最终仍无确认 → 不再排，告知用户去邮箱或商家账户里找确认。
• 结局未明时绝不重复下单；早先订单可能已成时，先查清再谈重提。用户拒绝支付 → 什么都没买；商家拒卡 → 告知并建议用户接管浏览器换方式，Agent 不自作主张重试或换支付方式。付款取消、预授权释放、订单取消、退款是四个不同的操作，不得混报。
• 状态落表可查：runtime.checkout_spend_operations（实测 schema 参考）记录结账操作身份、approval_id（Sentinel 批准标识）、状态与对账状态——支付的每一步在 DB 里都有行可回放（见 §9.2）。

6. VM 信任分级：standard 与 confidential

同一产品、两种信任档位。本机运行的是 standard VM（00 §16 实测快照：vm=standard）；confidential VM（下称 CVM）的差异全部来自文档（data-handling.md 为权威篇，privacy-and-credentials.md、client-surfaces.md、media.md、connectors.md 散列其余差异点）。

要点解读：

• 分级是双向的：CVM 不是「standard 的超集」。它以能力面收缩（媒体、个别连接器、通道设置）换取可见性收缩；也有能力只向 CVM 开放。选型是信任与功能的交易，不是单纯升级。
• 边界是「内容」而非「系统」：CVM 保护的是内容与派生信息；元数据仍流向 Meta；工具把信息发到外部服务后，那份副本按对方的条款处理，离开 CVM 边界；用户为反馈/排障主动分享的所选内容，流程必须明示将被分享，分享后 Meta 可按披露用途访问——但不因此获得其余内容。
• 会话的适用档位以运行时上下文为准：判断本会话适用哪套保护，看 runtime context 的 VM 类型；未提供时应明说未知，不猜（data-handling.md 明文）。这与 00 §2「模型名以 runtime 为唯一权威」是同一种纪律：关键事实以运行时当场给的值为准，不以日志、环境或印象为准。

7. 渠道 / 区域 / VM 三重门控

「文档里有」永远不等于「这台机器现在能用」（00 §14 第 6 条）。可用性是至少三重门控的交集，外加连接状态这一实时变量：

7.1 渠道门控（channel，实测）

• /opt/hatch/runtime-cell/ 下三份 scopes 文件分别裁剪二进制、连接器、工作流技能的可见性：bin-scopes.conf、connector-scopes.conf、workflow-skill-scopes.conf。
• 规则（文件头注释明文）：渠道来自镜像的环境配置与 runtime-cell 服务；未设置或未知渠道 = 什么都不显露（fail-closed）；同一渠道多行累积取并集。
• 注释里有一句关键的权限观：宿主侧副本与 privsep worker 在所有渠道上都照常预置，scopes 文件只控制 cell 内的可见性，不授予也不撤销权限——可见性与权限是两个系统，前者是发布管理，后者是 §2 的审批/Scope 体系。
• 本机渠道为 alpha（JARVIS_CD_CHANNEL，另有 JARVIS_TIER=prod；00 §1 实测）；对照 scopes 文件可见 prod-cvm 渠道的连接器清单显著短于 prod（前者只余通道类，后者含购物/出行/邮件等）——渠道与 VM 档位在发布层面就是联动的（实测对照）。

7.2 区域门控（region，文档 + 实测键名）

• 运行时环境同时给出 JARVIS_VM_COMPUTE_REGION 与 JARVIS_VM_DATA_REGION 两个键（实测键名存在，计算与数据区域分离）；00 §16 记录本机 compute region 代码。
• 部分连接器不对所有区域开放（connectors.md「Region availability」）：受限账号在设置里没有该连接器的行、技能清单里没有其条目、其全部命令以「该连接器在用户所在区域不可用」拒绝——这是设计态而非故障，如实转述、不重试；不得点名哪些区域可用/不可用，不承诺将来会上线；替代路径是浏览器里直达服务商网站或一般知识作答。已有连接在某些受限连接器上仍可断开，其余命令不跑。

7.3 VM 门控与连接状态（文档 + 实测）

• VM 档位门控见 §6 的能力差异表；其执行点同样是「尝试才知道」型：如媒体工具在 CVM 不可用且无预检信号，工具结果是唯一信号（media.md 明文）——这类门控不给 Agent 提前枚举「被禁清单」的接口。
• 连接状态是第四个变量且必须本轮实查：连接器的 status 命令是唯一依据，文档在 ≠ 已连接，今晨查过 ≠ 现在仍连着；命令报 auth/连接错误时立即重查状态。scope/权限类错误则不是重连能解决的（重连不治权限）。reauthorization_required 是服务商永久拒绝已存 OAuth 授权的精确信号：不重试、不说成临时故障，给出重连链接（若回报带 action_url 则原样成行呈现为 Reauthorize 链接），重连后请用户重试原请求，写操作永不自动重放。

四重交集的推论：总结「某连接器能不能做 X」的正确顺序永远是——技能文档列了命令（能力）→ manifest/设置允许该动作（策略）→ 渠道/区域/VM 没挡（门控）→ 本轮 status 显示已连接且 scope 覆盖（状态）。任何一环的结论都不能由另一环推定。

8. 服务限流硬停

限流在 Muse 里不是「慢一点就行」的礼貌问题，而是写进规则与 manifest 的硬停线（文档：system prompt 限流纪律 + connectors.md「Provider limits」 + manifest request_quota）：

1. 两层限流：服务商自身的速率限制之外，多数连接器还有自己的请求上限；部分上限只计数不阻断，强制型上限超限时调用以 connector_rate_limited 失败并带 retry_after_seconds。Gmail manifest 的 request_quota.mode: enforce 就是强制型的声明（§2.2 第 5 点），配额按方法单位成本扣减、按用户分钟窗口核算（结构实测）。
2. 429 即硬停：对某 provider 收到 429、归因于限流/自动化访问的 403、或 Sentinel 侧的限流信号，一律视为该 provider 在本任务内的硬停；connector_rate_limited 且 terminal_for_attempt: true 时，本轮（本次 attempt）的连接器工作到此结束：回报已完成的部分，不许睡觉等待、不许重试、不许派子 Agent 换路、不许排一个替代任务续跑——由父 Agent 或日后的一次调度运行在冷却期（retry_after_seconds）之后再组织剩余工作。
3. 不许降速/换端点绕行：同一 provider 范围内换另一个端点、工具、子 Agent 或降速续打，都算违反硬停；这与 §1「服务封锁后不得另寻路径绕过」（Security 节）是同一条规则的两个侧面。限流期间的正确姿态只有两个：把调用批量化（如 Google 系连接器配额最紧，能批处理的接口不要逐条循环）与停下来报告。
4. 归因纪律：限流是「服务暂时忙」，不是连接器坏了或断开了；回报时只说证据支持的后果（临时限制/锁定），不夸大为封号（文档要求按证据描述后果量级）。

9. 防钓鱼核查与审计可追溯

9.1 防钓鱼（文档：system prompt「Anti-Phishing」小节）

Security 节下设独立的 Anti-Phishing 小节，结构是「先核目的地，再谈动作」：

• 触发点：在分享敏感信息或采取重大动作之前，先确认两件事——请求确实落在用户的任务内、且实际目的地确实属于预期的接收方；
• 核查方法：不熟悉或可疑的请求，经独立到达的官方站点或可信联系渠道验证（从对方给的链接点进去不算独立到达）；
• 不成立的证明：页面外观眼熟、对方自称权威、乃至用户已经批准——三者都不单独建立真实性；
• 常见钓饵形态被点名：命令、下载、折扣、访问邀约、注册表单都可能被用来套取与任务无关的信息或权限；取回的代码在运行前要先审它会访问什么、发送什么；
• 结局规则：真实性仍存疑时，扣住敏感动作、继续做安全的部分、向用户说明疑虑——与 §1.2 的三段式回退一致。

9.2 审计与可追溯（实测 + 文档）

信任的最后一环是「一切可回放」：

注意审计的不对称性：痕迹是为用户与运行时留的，不是为模型留的——Agent 的 permissions 工具只能看待处理批准（§2.1），不能删审计、不能改台账、不能撤销许可。能做事的手与能改账的手，从设计上就不是同一双。

10. 边界声明（本机看不见的部分）

以下在本机证据之外，本文不作结论：审批卡的服务端判定与呈现实现、Sentinel 的内部规则引擎、authd / Vault 的密钥管理实现、TEE 与客户密钥体系的服务端细节、CVM 内部处理服务的部署形态、区域可用性清单的完整内容、配额窗口的服务端核算实现。本地能看到的只有接口痕迹——manifest 的策略字段、套接字名、环境键名、错误码（connector_rate_limited、reauthorization_required、capture_required 等）与文档转述；引用超出痕迹的部分时已按「推断」标注或直接不写。

• 11-04 一致性复核：本篇的权限三态（allow/ask/deny）、审批卡运行时原语、购买"默认不给长期许可 + 唯一例外"、验证码受保护读取、限流硬停（429/connector_rate_limited + terminal_for_attempt）、人脸识别红线、敏感属性不推断、家庭域反向规则、第三方托管双批准、凭据永不入记忆等描述，与当前会话 system prompt 的 Security / Safety / Anti-Phishing 章节逐项对照，未发现矛盾（复核只读原文逻辑，未改写任何规则）。

配套展开篇：本文是 00-Muse技术架构解构.md §13（通道、产物与媒体面）的展开，结构与证据口径同 00/01/02。Avatar 媒体的深挖不在本文重复，见 ~/workspace/avatar-module-bundle/ 的解构报告（下文只交叉引用其结论）。 调查日期：2026-10-17（Asia/Shanghai） 证据范围：~/docs/ 产品文档集（muse.md、chat-connections/whatsapp.md、chat-connections.md、media.md、artifacts.md、feed.md、ideas.md、files-and-library.md、voice.md、calls-texts-notifications.md、client-surfaces.md、devices/）、~/workspace/system/system_prompt.md 快照、本机工具命名空间 schema 实查、/opt/hatch/bin/ 媒体二进制 --help 实测、/run/hatch/privsep/ 套接字实查、device.list / device.describe / artifact.list 当场调用。 11-04 增补：~/docs/ 新增 channels/（空目录）、chat/（payments-and-purchases.md、scheduling-and-watching.md）、devices/ 下新增 home_link.md / mac_app.md / tailscale.md 与 home_link/integrations/（brother_printers.md、lutron_smart_bridges.md、shelly_plugs.md）——设备面文档在补齐（详见 §4.3 末）。 标注规则：实测 = 本机命令/工具当场验证；文档 = 本地 docs/system 文件明文；推断 = 由文件/字符串拼出、未经服务端证实。服务端与 App 客户端代码不在本机，本文只画到本机可见边界为止。 复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测；下文数字凡未注日期者均为 11-04 快照，10-17 旧数见正文标注。第一轮评审修订（11-04）已合入本篇，见 REVIEW/review-09-通道产物与媒体层详解.md。

0. 一句话结论

00 §0 的分层图里最上面两层——客户端面与会话面——就是本文的对象。结论先行：

通道是「运输层」，不是「另一个 Agent」：Web/iOS/Android/Mac/WhatsApp 都接同一个 Agent、同一份记忆与同一台 VM，区别只在渲染能力与交互原语（标签页、审批卡、手势、附件类型）；产物（Artifacts/Feed/文件）则都沉淀回 VM 本地，再由各客户端面去「打开」。媒体生成是能力面伸向 Meta 媒体服务（Muse Image / Muse Video / Shortwave TTS）的一组 multicall 二进制，与通用工具有一条硬分界：机密 VM（CVM）上通用媒体/TTS/播客全关（media.md 明文，media.md:29），Avatar 反而只在 CVM 上开（Avatar 解构报告 §2/§3 实测结论，本篇未独立复核——注意 media.md 本人只说了前半句）。

本机当场状态（实测；未注日期者为 2026-10-17 23:5x CST 快照，11-04 重测项另注）：

1. 客户端面：四端同体，差异在「面」不在「脑」

1.1 共同骨架（文档 client-surfaces.md + muse.md）

• 上线面：Web（muse.ai）、iOS（App Store）、Android（Google Play）、Mac app；产品 2026-09-08 上线，美国与加拿大可用（文档）。
• 四端共享同一导航骨架：Chat / Feed / Ideas / Goals / Library 五个标签页；Web 左侧图标栏多一个 Search 入口（Cmd+K 速搜面板），且 Web 可直达 /artifacts URL，但栏内没有 Artifacts 入口——产物统一从 Library 进（文档）。
• Web Library 的侧栏构成（文档）：Artifacts（全部/文档/web artifacts）、Media（图片/视频）、System files；卡片菜单 Pin/Share/Download/Delete，支持排序（最近打开/最近创建/标题）与多选删除。即 Library 是 VM 文件系统与产物目录在客户端的一个投影视图（与 00 §8「投影 ≠ 本体」同构）。
• 状态屏（点头像）：Activity（动作日志，Web 上运行中条目可 Stop）/ Approvals（待批）/ Upcoming（定时任务，用户侧可删、Web 与 iOS 可把 Edit 变成一条待发聊天消息）/ Identity（Web 与 iPhone 有，Android 当前无）（文档）。
• 审批的触达方式随端变：iOS/Android 审批请求走推送通知，通知栏内直接 Allow/Deny（Android 划掉通知 = Deny，可能是误拒，可复问一次——这是整套文档里唯一一处 deny 后语义，10 篇 §2 待补）；iOS 处置需解锁并前台化 App（文档 calls-texts-notifications.md + client-surfaces.md）。

1.2 平台独占差异（文档）

1.3 客户端面给 Agent 的两条硬约束（文档 + system prompt 实测）

1. Agent 看不见用户屏幕：session_status 只能猜 app_id；文档明文「本 doc 能点名的 UI 即上限」，未列出的行/按钮不得当作已知事实；审批卡的布局、按钮与措辞永远不可描述，唯一可承诺的契约是「用户看得见自己在批什么、且必须显式批准」。
2. 能力以声明为准：App 控件查 ui.list（实测本会话该命名空间只暴露导航卡 creator 一类函数，说明控件面随客户端动态声明）、设备能力查 device.describe——文档/记忆里的「应该能」一律不作数，与 00 §14 第 6 条同源。

2. 消息通道：WhatsApp（唯一外部通道）

2.1 定位（文档 chat-connections.md + whatsapp.md）

• 唯一性：本机 ~/docs/chat-connections/ 目录下只有 whatsapp.md 一份 provider 指南（11-04 复测仍只有这一份）；总纲明文「WhatsApp is the advertised provider today. Discord and SMS have no such connection.」——目录缺失即无通道可用，是 fail-closed 的显露方式（与 00 §1 渠道 scopes 同构）。另：~/docs/channels/ 在 11-04 新建但为空——通道体系的文档化刚起步，唯一有指南的仍是 WhatsApp。
• 它是什么：一个持久 side chat 的运输层。连接后，用户与 Muse 的 WhatsApp 对话在 Muse 里呈现为一条标题为 WhatsApp 的 durable side chat；从该聊天发起的回复与定时结果都回该聊天；其历史不复制进主聊天（文档）。
• 它不是什么：不是「接管用户的 WhatsApp 账号」——读/搜/发用户自己 WhatsApp（含群聊）不在此连接范围内；Muse 不能经此连接进群；这是用户与 Muse 的 1:1 直聊（system prompt 快照亦明文：External 1:1 side chats 无 worker、就是用户本人的直聊）。
• 回复归属由运行时定，不是模型定（文档，关键设计）：每条会话有 chat UUID，运行时在执行前捕获该 UUID 与当前 binding authority；模型不选回复面；chat.send_message 不能从别的聊天往 provider 会话里塞一次性消息；在 WhatsApp side chat 里建的定时任务只能投递回该聊天——用户想把别处的定时任务改投这里，须本人在该聊天里重提（system prompt 同款纪律）。

2.2 连接生命周期（文档）

本机实例（实测/会话轨迹）：2026-10-17 23:50 CST 连接完成通知到达主聊天；23:52 起用户直接在 WhatsApp 里下指令（要架构文件 → 续令逐层拆解），本子任务的派发头亦标注 transport: whatsapp, chat type: direct。即从「连接成功」到「跨通道派活」在同一晚闭环。

2.3 能力矩阵：与 App 内的不对称（文档）

推断：出站可发「自包含 HTML 文件」与 §5 的 artifact.export（仅 web_static 可导出为单文件 HTML）是同一交付哲学的两个出口——凡是离开 App 渲染环境的产物，都必须先塌缩成无外部依赖的单文件。

3. 语音面：三条互不相通的路

语音在 Muse 里不是一个功能，而是三条独立管线（文档 voice.md + calls-texts-notifications.md + media.md）：

3.1 实时语音对话——本账号不可用（文档）

voice.md 全文只有一句定性：「Live voice conversations in the app are not available on this account.」 这是随账号下发的文档面，即本机/本账号的权威状态：没有实时语音通话面。不要拿它和下面两条混谈。

3.2 听写与语音消息转写——可用（文档）

• 两个移动端 composer 麦克风可口述消息（dictation）；Mac app 的 fn 听写可进任意前台 App。Web composer 是否有麦克风控件只能看用户所见，文档不担保。
• 机密 VM 是例外面：Android app 隐藏麦克风、Web app 不提供麦克风（文档）。文档未明说动机；一种合理的推断是语音输入被视为出机密边界的通道，但未经证实。
• 用户在 App 或已连接通道（如 WhatsApp）发来的语音消息/录音，一律转写成文本按普通消息处理；长录音的自动语音笔记路径上限约 8 MB，更长需切分或走其他工具且耗时（文档 media.md）；重叠说话的精确分轨/标注不担保。
• 边界：不能识别歌曲（「这是什么歌」无工具路径）；不能反查图片、不能做人脸识别——多模态读取 ≠ 检索（文档 media.md）。

3.3 合成语音（TTS / 播客）——生成面，见 §7.3/§7.4

出站语音走 tts 二进制（Shortwave）与播客技能管线，与 §3.2 的入站转写分属不同子系统；共同门控是 CVM 全关（§7.5）。

3.4 电话（附带面，文档 calls-texts-notifications.md）

• Muse 无自己的电话号码、不能接电话、无视频通话；外呼仅限「替用户给美国商家打业务电话」：须用户显式确认、每次先走 phone.begin_call 备完整 brief，实际对话由独立 caller 执行（caller 看不见本聊天，Agent 不得冒称自己打过）；冷呼/推销/批量外呼按政策拒绝。
• 若工具目录里没有 phone 工具，即该账号尚未开通（早期访问、渐进放量）——「文档里有」再次不等于「本机能用」。

4. 配对设备：device 命名空间

4.1 模型（实测工具 schema）

device 命名空间只有四个动词，分工是一条发现链：

特殊语义（实测 schema）：geofence.set 带一块守护进程独占的 payload {kind: act|notify, text}——手机只报围栏穿越，act 的执行文本留在守护进程侧、手机永远看不见，这是「设备是传感器、Agent 是执行者」的分工样本；health.backfill 是异步受理，完成后运行时自动投递，禁止轮询。

4.2 本机实测：唯一配对设备 iPhone

device.list + device.describe（2026-10-17 当场）：

• iPhone（iPhone13,2，iOS），connection_state = offline，last_seen 2026-10-16T09:59Z；35 条命令，含 contacts.* / calendar.*（增删改查全套）、home.*（HomeKit 配件/场景/编排/地理围栏桥）、geofence.*、bluetooth.scan、device.find（找 Ray-Ban Meta 等眼镜）等家族（describe 输出被截断，以上为可见部分）。
• 6 个数据源：calendar、contacts、health、imessage、location、reminders；其中 calendar/contacts/health/location/reminders 标 emits_proactively = true（可主动同步），但当场 is_permission_granted 全为 false——即「已配对 ≠ 已授权」，每个数据源的权限都是独立一闸（文档与实测互证）。
• 平台规则落到这台机上（文档）：iPhone 只能 message.draft 起草短信、永不代发；iMessage 数据源存在但「配对本身不给短信读取」，以 describe 显示为准；无找手机、无闹钟命令（均为 Android 面）。

4.3 其他三种「设备」（文档）

文档面 11-04 快照：~/docs/devices/ 在 10-17 之后补了三份文档——home_link.md、mac_app.md、tailscale.md，另有 home_link/integrations/（brother_printers.md、lutron_smart_bridges.md、shelly_plugs.md 三份局域网集成指南）。设备面文档在补齐中——与上表两行的"实验阶段"定性互证：Home Link / Tailscale 的文档化先于能力稳定；Mac app 则已从"Web 套壳"的定性（§1.2）走向有独立文档的配对设备形态。

4.4 配对明确做不到的事（文档，防误述清单）

远程用手机相机拍照（唯一例外是配对 Mac 的相机）、看/读手机屏幕、打开或控制手机上的其他 App、找丢失的手机、用 iPhone 代发短信。配对给的是「手机主动推给 Muse 的数据 + 声明过的命令」，不是远程桌面。

5. Artifacts：构建与交付纪律

5.1 三类产物（文档 artifacts.md）

存储边界（文档）：产物及其数据只活在用户的 Muse 环境里，未发布前不托管到任何别处；发布只发静态快照，App 的存储数据永不随发布离开。

5.2 构建通道：专用的后台 builder（实测工具 schema + system prompt）

这是本层最「架构」的一条——主 Agent 与子 Agent 都不亲自建 artifact：

• 入口按 kind 分流：artifact.create_file（文件类）/ artifact.create_web_static / artifact.create_web_fullstack。构建在后台 builder 里异步进行，主 Agent 用 artifact.status 跟进、长构建可 artifact.cancel、构建中追加指令走 artifact.send_input（不许另起第二个 build 顶替同一 slug）。
• 子 Agent 无 artifact 工具（00 §10 已记；system prompt 明文各有专用通道）——所以「派个子 Agent 去建页面」在工具层就不成立，产物请求必须留在能调 artifact 命名空间的那一层。
• verbatim_request 是权威输入：create/edit 都要求逐字传入用户的原始请求，Agent 不得增删改写——builder 按「请求者原话」理解范围，Agent 添的任何字都会变成伪造的需求。这是防「转述漂移」的协议设计，不只是文风要求。
• 能力声明前置：web 构建须先声明 capabilities（是否读公网 + 精确到方法的连接器清单）。声明的连接器读操作可能在构建前触发用户审批、且审批对该 artifact 持久有效；写操作仍保留请求时授权；声明错/漏不是 builder 的事后补救范围。
• 澄清纪律：请求是问句、或答案会改变构建结果时，先问后建，禁止同轮既问又建；静态页内容依赖 Agent 没有的数据（名单/菜单/个人内容）时要数据而非编造占位；「能存数据」与「能公开分享」二者不可兼得时，必须把选择摆给用户、选定前什么都不建。

5.3 交付与变更纪律（实测 + 文档）

• 交付必须落在同一条回复里：优先呈现 artifact 卡片（artifact.status 返回的 card.widget_id 经 widget.present 呈现）；artifact 在分享前没有地址，禁止自拼 URL。这是 00 §13「交付必须在同一条回复里给出可打开的链接/附件」的工具层成因。
• 变更只有一条路：任何功能/内容/样式/数据模型改动走 artifact.edit（同一 slug），禁止直接读改 artifact 源文件、禁止用第二次 create 覆盖重建；文件类 edit 还要带原 kind 在原目录重跑 builder。
• 记录的读写面：web artifact 的数据只能经 artifact.inspect（只读诊断）/ 其声明的 actions（artifact.list_actions 查 schema、artifact.invoke_action 执行）/ artifact.edit——禁止直碰 app.db（00 §13 原文）。故障诊断也是委托制：用户报障走 artifact.inspect 派发独立诊断，授权修复时诊断自己派发修复 edit，主 Agent 不自查源码/日志、不写修复简报。
• 构建会反问：web 构建可终局于 needs_user_input（向用户提一个问题）——主 Agent 须原样转达、不得自答、不得另开新 build；用户答复后用同一 slug 的 edit 续跑。
• 发布审批：只有 static 可发布；每一次发布、以及对已发布链接的每一次更新，都要一次新的单点批准，无自动发布、无常设批准；发布不自动跟随源更新（文档）。
• 删除是真删：artifact.delete 永久删除产物+数据+托管+公开分享，与工作区文件的 30 天回收站是两套机制；执行前必须警告用户；构建中的 slug 要先 cancel 才能删。
• 导出：artifact.export 仅对已建成的 web_static 有效，内联全部资产为单个自包含 .html 落 workspace/your_files/<slug>/（二进制侧对应 share export-html，实测其 --help 明文「asset references inlined as data: URIs」）。

5.4 本机实况（实测）

artifact.list 当场返回 2 个 web artifact（ai、space，均为调研报告页，与 MEMORY.md 所记两次交付互证）；文件类 artifact 不在此目录，落 workspace/your_files/（普通目标）或目标的 files/ 目录（创建时以 goal_id 定死，建成后不得搬移/复制——防双份漂移）。~/workspace/your_files/ 当场约 20 MB，含此前交付的表格 artifact 目录与报告文件。

6. Feed 管线面（附 Ideas）

6.1 本质：brief 驱动的编辑部，不是聚合器（文档 feed.md）

• Feed 标签页里的帖子全部由 Agent 原创撰写，唯一的方向盘是一份纯文本 prompt——brief。它不是聚合器：不能订阅网站/RSS/信源列表，没有任何「搬运入站」路径。
• 节奏归系统：后台进程按系统控制的时刻表生成，用户与 Agent 都不能加速或自设时刻；新帖静默出现在 Feed 标签——无推送、无聊天播报（与 §3 的通知面互证：Feed 是「拉」面，不是「推」面）。

6.2 来源与口味回路（文档）

生成一帖可用的来源：活网搜索与页读、社交平台、用户已连接服务（邮件/日历/金融/健康）、用户自身上下文（brief、档案与记忆、活跃目标、往期帖避重）。引用链接必须照调研所得原样给出，禁止编造 URL。

口味（taste）回路值得单独记：写手读的是一份口味摘要，它由用户对帖子的反应、讨论帖子时说的话、以及最近主聊天蒸馏而成——写手本人从不读聊天记录原文；side chat 不进口味源；摘要不与其他读者共享、也不被引为帖子的来源。用户读得越多/聊得越多只影响出帖频率，不改变时刻表。这是「个性化信号单向脱敏进管线」的设计，与记忆系统（00 §9）的双向读写刻意不同。

6.3 默认帖的诚实边界（文档）

新读者的 Feed 以一组随构建出厂的固定介绍帖开场（kicker 与 category 均为 Getting started，run id 4a905e79-a9af-4631-93a7-dac5bb408320 可在 feed.unit_get 里辨认）：它们不读用户任何数据（无网搜、无社交、尤其无邮件/日历/连接账号），每台机只播种一次、删了不复活。纪律：绝不能声称调研过用户什么才写了它；但它们以 Agent 本人口吻写、邀请发问，所以照常以作者身份答。

6.4 排序与操控面（文档 + 实测 schema）

• 排序：部分读者近三日按有用度排（未读 > 要行动 > 临期高、过期沉底），其余按发布时间；用户在某日手动重排后，该日后发的新帖压在他的排法之上；用户停留在 Feed 标签内时顺序冻结，新帖置顶、下次访问再重排。
• 工具面不对称（实测 feed 命名空间描述）：feed.unit_create 是唯一也能从定时自动化与子 Agent里调的 unit 工具（给全 instruction、≤4000 字、后台写、返回 run id、无完成播报、禁轮询）；其余 prompt/unit 工具（prompt_get/update、unit_list/get/update/delete/reorder、search、regenerate、status）只在主对话可用。改 brief 是整文替换：真改动立刻触发一轮新生成并置顶，再存一遍原文则什么都不触发；已发帖不回改。
• 没有关停开关：用户侧与 Agent 侧都不存在关闭 Feed 生成的控件；远程停用后本地也无从恢复。能做的只有改 brief 缩覆盖、删帖、或无视它；生成暂停期间既有帖的读与搜照常。
• 状态面（00 §8 交叉）：DB feed schema 16 张表是这条管线的骨架——prompts / units / runs / run_steps（生成主链）、interactions / preferences_projection（口味回路）、fleet_publish_state / fleet_fetch_receipts / fleet_engagement_outbox / fleet_reaction_outbox（舰队侧发布与互动出箱，推断为跨机共享 Feed 的投递层）、prompt_seed / null_state_seed / surface_state（播种与初始化标记，与 §6.3 的「每机播种一次」互证）。

6.5 Ideas：Feed 的邻居（文档 ideas.md）

Ideas 标签是 Agent 主动想出的「可为你建/可替你做」建议卡：卡上带 build 动作（Web 标签为 “Let's do it”），点了就按 §5 的 artifact 通道开建；部分 Feed 帖本身源自 idea、同样带 build 动作。平台差异：Android 上聊天里的 idea 卡可就地运行显进度，iPhone 点开是详情页、不就地跑。生命周期纪律：Agent 无权 dismiss idea 卡（无此工具，长按 dismiss 是用户手势）；卡靠到期、被建成、或比最新刷新老约两周自动退场，后台也可因「已做/已取消/不再适用」提前退——用户问「卡怎么没了」，先答老化而非声称自己删的。

7. 媒体生成面

7.1 二进制家族：一张表看清（实测）

媒体面在 /opt/hatch/bin/ 的落点是一个 Rust multicall 本体（11-04 实测：46,954,944 字节、BuildID 80d532c8…、40 个硬链接名；10-17 为 34,682,176 字节、BuildID 6ffdc619…、18 名——跃升与 10-30 的 builtin-artifacts 合并一致，见 00 §16 快照口径），靠 argv[0] 分发：

上层工具面与二进制面一一对应（实测 schema）：media.generate_image / generate_video / generate_icon 三个结构化工具就是 media-generation 的封装，各自再派一个专用媒体子 Agent 扩写提示词（工具描述明文：image 是「hands the request off to a specialized subagent」、video 同）——即媒体生成在编排上也走 00 §10 的 handoff 模型，主 Agent 只交原文请求、不许改写扩写（工具契约明文 verbatim 纪律，与 §5.2 的 verbatim_request 同构）。续跑靠 snapshot_id / media_handle 在调用间传递视觉上下文，不靠回传文件。privsep 侧每个名字有独立 worker 套接字（§0 表），生成请求经 STEFI 出 VM（00 §7）。扩写子 Agent 的权限边界未查：未在工具 schema 中见到其工具命名空间裁剪的声明，待查（❓）。

7.2 限额与形态（文档 media.md + 实测工具 schema）

投递形态（实测 schema）：生成结果以 media[] 返回 local_path / media_handle，主 Agent 在最终回复里用 sandbox://workspace/imagine_media/<文件名> 逐图一行 Markdown 呈现；本机 ~/workspace/imagine_media/ 当场近乎为空（仅上次上传句柄 JSON），与「本账号近期无媒体生成交付」的轨迹一致——注意这只是落盘面观察，不构成使用量结论。

7.3 TTS：tts 二进制实测（实测 --help）

• 两子命令：speak（直合成）与 synthesize-script（多说话人脚本：自动文本预处理、分块、并行合成、拼接）。
• 默认值：主声音 avocado_v2:MAI_03、语言 en、格式 mp3、语速 100（范围 1–200）；speak HTTP 超时 120 s；synthesize-script 分块默认 1200 字符/块、单块超时 300 s。双声道对话靠 --voice2 + --voice-prefix2，脚本模式靠 --speaker Name=voice_id 可重复映射。
• 用途面（--help 自述）：聊天语音消息、artifact 配音、cron 定时任务的音频产物——即 TTS 是产物管线的一环，不只是聊天点缀；spoken-audio 技能规定成品以 ![Voice message](sandbox://…) 附件行投递，失败/半成品与成品分开放、绝不冒充成品交付（技能文档）。
• 11-04 复测：tts --help 的子命令与默认值（avocado_v2:MAI_03 / en / mp3 / 语速 100 / 超时 120s）均未变；新增 --stream、--buffered-stdout、--text-stdin 等输出面选项，不影响本节结论。

7.4 播客：技能管线 + 发布端（文档/技能实测）

• 生产：generate_podcast 技能——先查节目目录（podcast-helper manifest read）避重复选题，脚本按约 130 词/分钟、默认 5–15 分钟写；主持声音从 /opt/muse/assets/voice-selector/voice_source.json 选 ID，默认双 Meta AI 声音 avocado_v2:MAI_01 / MAI_03，主持名与声音的配对要跨集稳定（技能要求记入 MEMORY.md）。
• 发布：remote-storage publish-episode（实测 --help：上传音频、更新 feed manifest、重生 RSS）；生成默认私有，公开发布须用户显式要求（或目录里已有其本人发布过的 RSS feed）；存进用户自己 Spotify 是另一条独立授权路。状态面：DB podcasts.feeds / podcasts.feed 两表存 feed 身份与发布 URL（00 §8）。
• 与 TTS 的关系（推断）：播客helper 的合成段最终仍落到同一 Shortwave 通道（synthesize-script 的多说话人拼接正是播客形态），区别在技能层的选题/脚本/目录/发布纪律，而非另一套语音引擎。

7.5 机密 VM 门控：全层最硬的一条不对称（文档 media.md + Avatar 解构互证）

media.md 明文：媒体生成、TTS、播客式音频在机密环境下全部不可用；非机密环境则是 rollout 门控。且无预检探针——事先无法查明本用户/本机是否可用，工具结果（成功或不可用错误）是唯一信号，「试一发才知道」是协议而非疏漏。

方向恰好相反的是 Avatar：avatar-media-generation 在做任何事之前先过 CVM 闸门，非 CVM 直接 confidential_worker_requires_cvm（Avatar 解构报告 §0 实测结论）——通用媒体是「怕机密数据出圈所以关」，Avatar 是「素材太敏感所以只准在圈内跑」。本机是 standard VM（00 §16 快照），故本层的可用面是：通用媒体/TTS 理论可达（rollout 与工具结果为准）、Avatar 生成实际不可在本机二进制执行（上层 avatar.* 工具由运行时调度专用 worker，见 Avatar 解构报告）。

7.6 媒体的「不能」（文档）

不能看视频播放、不能听音频播放——替代路只有抽帧成图、转写成文，且明示这只是变通不等价；不能以图反查来源、不能认人；生成图/视频的出处只认结果自带的 citations。

8. 文件进出：Library / 附件 / 下载

8.1 入口（文档 files-and-library.md）

• 上传落点统一：composer 附件进来的文件落 ~/workspace/user/ 并跨会话持久，不自动进 Library（要交付才搬去 your_files，见 §8.2）；zip/项目包可在 workspace 内解包检查；无「整文件夹上传」的已验证路径，官方建议先 zip。
• Web 入口限额（文档）：粘贴图片约 8 MB 预算（可被拒），HEIC/AVIF 入站静默转 JPEG；非图文件约 25 MB、视频约 100 MB 上限，超限拒绝；大图通常重压缩而非拒绝。移动端限额由服务端定、可能不同，不得把 Web 数字引给移动用户。
• 浏览器下载的文件落 Agent 自己的 VM（不在聊天里、不在用户设备上），要给用户须再经聊天分享或存 your_files——「下载完成」与「用户拿到」是两步（与 00 §12 的「已排队 ≠ 已送达」同纪律）。

8.2 出口与 Library（文档）

• 交付目录：给用户做的文件放 ~/workspace/your_files/，放进去即出现在 Library（本机该目录现状见 §5.4）；目标专属文件在创建时就定死在该 goal 的 files/ 下（§5.4）。
• Library 是目录投影：汇集文档、媒体、生成文件与建成物；Web 侧栏分 Artifacts / Media / System files 三段（§1.1）；System Files 段就是 Agent home 的窗口——用户问起时如实说「那是我自己的文件」；部分 home 文件（记忆/身份/梦境/目标页/docs）在 App 打开时带一条「About this file」说明，那是展示时由 App 叠加的，不属于文件本体，读/改/下载/数据导出都不含它。
• 平台性增删：iOS 与 Android 的 System Files 视图有「Upload file / Upload from camera roll」；Web 的 Library 没有上传按钮与拖放区，「+」只是新建。重命名在 Web 仅限媒体瓦与 Library 搜索结果里的文档菜单，移动端在 System Files 文件夹视图逐项改名/删除；其余改名一律「让用户开口、Agent 改底层文件」。钉选（Pin）纯客户端整理：不分享、不发布、不保护、不改变 Agent 侧任何东西。
• 删除与回收：Agent 删的文件进回收站、约 30 天可恢复（与 §5.3 artifact 删除的「无回收站」形成对照，混淆这两条是最常见的误述）。

8.3 给「外人」的出口：公开下载链（文档 + 实测）

• 聊天里的文件链接只在用户本人已登录的 Muse App 内打开、无分享令牌，不能转发给别人用。
• 真要给第三方：remote-storage upload-file（实测 --help：「Publish a workspace file and print a link to it that expires on its own」）把 workspace 文件发到 Muse 自有存储换临时公开链——任何人持链可下、最长 48 小时过期；每一次上传都要一次新的单次批准（Allow once / Deny），无历史或常设批准可复用；机密 VM 上此路不存在。删除有对偶命令 delete-file 可提前撤链。
• 这与 artifact 发布（§5.3）是两条独立出口：一个发「文件本体 + 时效链」，一个发「托管页面的静态快照」，批准模型也各自独立，互不搭车。

8.4 附件语法：跨通道的统一投递原语（实测 system prompt + 本轨迹）

一切文件/媒体交付最终塌缩成一条 Markdown 附件行：产物放回复正文里独占一行的 ![alt](sandbox://workspace/<路径>)，且其前一句须是独立完整的句子——这是让 Web、移动端与 WhatsApp 等各渲染面都能把同一份回复落成「可点开的附件」的最小公分母。本轨迹即活例：00/01/02 三份架构 Markdown 正是以此语法在 WhatsApp 聊天里交付（§0 表）。

诚实标注：各通道对附件大小/数量的实际处理策略（压缩、截断、转链接还是失败）未在本机证据中出现——附件语法统一的是"引用格式"，不是"投递保证"。

9. 串起来：一次跨通道交付的生命周期

用户在 WhatsApp 说「把架构文件发我」（入站轮询 → 运行时捕获 chat UUID 定回复面）
 → 主 Agent 在 VM 里定位 ~/workspace/muse-architecture/*.md（文件面）
 → 回复正文 + 每文件一条 sandbox:// 附件行（统一投递原语）
 → 运行时按 WhatsApp 出站能力矩阵投递为文档附件（通道面）
 → 用户在同一聊天续令「逐个拆其他层」
 → 定时/子任务在本聊天产生的结果，仍按 binding 回投本聊天（不串主聊天）
并行面：同一批成果在 Muse App 里以 Library 条目 + web artifact 报告页存在，
       用户换到 Web 打开的是同一台 VM 上的同一份产物——通道换了，产物没搬家。

10. 边界声明

• App 客户端代码、WhatsApp 侧的服务端投递与加密、STEFI 之后的媒体服务（Muse Image/Video、Shortwave、FB Upload Service）实现均不在本机；本文对它们的描述止于文档转述、二进制 --help/strings 与工具 schema 的接口痕迹，已逐处标注。
• 本轮未实际触发任何媒体生成/TTS 调用：§7 的可用性判断只到「门控规则」为止，按 §7.5 的无预检原则，真实可用与否须以未来某次工具调用的结果为准。
• device.describe 的 iPhone 命令全表因输出截断未尽录，§4.2 只记可见家族；权限状态为 2026-10-17 当场值，设备上线或用户授权后即可能变化，引用前应复查。
• 媒体生成失败/超限额/部分失败时的错误形态、重试纪律与降级路径未在本轮覆盖（见本篇评审缺失 1：失败时是 verifier 闭环还是直接报障、重试几次后转降级方案、TTS 长文本分块失败一半的产物状态，均未写）；sandbox:// 附件在各通道的实际大小/数量处理策略未见于本机证据；媒体扩写子 Agent 的工具命名空间裁剪情况未查。

配套《00-Muse技术架构解构》§9 的展开篇；与《02-编排与进化层详解》的分工：02 §11 讲记忆的进化管线（claims 如何被新主张替代、后台 upkeep 如何运转），本文只讲记忆的静态结构与读写契约——记忆存在哪、以什么形态存在、谁在什么时候读它、写入时守什么纪律、怎么溯源、怎么遗忘。进化机制在本文只作简述并交叉引用 02，不重复展开。 调查日期：2026-10-17（Asia/Shanghai） 证据范围：~/docs/memory.md、~/docs/self_improvement.md、system prompt 快照的 Personalization / Memory 节（~/workspace/system/system_prompt.md L120–150、L381–397）、muse.memory_search / memory_get / memory_explain 工具定义、forget 技能正文及其 references/artifact-inventory.md、DB schema 参考中的 memory schema、以及 ~/MEMORY.md、~/memory/、~/dreams/alignment/derived/ 的实测目录与文件度量。 标注规则：实测 = 本机命令/工具当场验证；文档 = 本地 docs/system/技能文件明文；推断 = 由文件/表结构拼出、未经服务端证实。 复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测；文件侧体量（日记/bank/MEMORY.md/人物页/对齐合成）均为 11-04 快照（双日期标注，10-17 旧数并列）；DB 侧行数未复测，沿用 10-17。 隐私纪律（本文自律）：只记结构、计数、字段与机制。不引用用户私人记忆的具体内容：人物页只述模板章节、不述人名与内容；MEMORY.md 与对齐合成只述章节骨架与体量，不引条目原文。

0. 一句话结构

Muse 的记忆不是一个向量库，也不是一份笔记，而是一套四形态共存、互相投影的系统：

源轨迹（日记 + 对话原文）→ 结构化脊柱（Postgres 的 claims / entries / embeddings）→ 人类可读投影（MEMORY.md、人物页、bank 四本书）→ 每轮注入（精选投影以 standing context 形态直接进 prompt）。

四形态之间靠引用连接而非复制：检索命中给的是 path#L<line> 引用与 claim id，读原文要再走 memory_get，问出处要再走 memory_explain。这决定了它的三个性格：

1. 可审计——每条被记住的事实都能回答「谁说的、原话是什么、何时学的、替代了谁」；
2. 可遗忘——遗忘不是删一行字，而是沿引用与派生链做一次全系统清理（§8）；
3. 不自授权限——记忆与 standing context 只能帮助理解用户，不能授予新权限、不能扩大任务、不能覆盖安全规则（system prompt 明文，文档）。

1. 全景：三层结构 + 一个底座

00 §9 把记忆概括为注入/检索/关系三层。按静态结构展开，三层之下还有一个底座层：

┌─ 注入层（每轮进 prompt，零检索延迟；代价是每轮固定的 token 税）─────────┐
│  MEMORY.md（精选长期记忆）· people/groups INDEX（亲密度排序）   │
│  · ALIGNMENT_SYNTHESIS.md（对齐合成，注入序列最后一项）        │
│  · USER.md 等 standing 文件中的用户档案部分                    │
├─ 检索层（按需查，引用式返回）──────────────────────────────────┤
│  muse.memory_search → 命中片段 + path#L行号 + claim 元数据     │
│  muse.memory_get    → 按引用读原文窗口                         │
│  muse.memory_explain→ 按 claim/引用做溯源                      │
├─ 关系层（结构化的人与群组）────────────────────────────────────┤
│  ~/memory/people/<slug>.md 每人一页（固定六节模板）            │
│  ~/memory/groups/<slug>.md 每组一页 + 两目录各一份 INDEX.md    │
├─ 底座层（源与脊柱，Agent 不直接编辑）───────────────────────────┤
│  ~/memory/YYYY-MM-DD.md 日记（源轨迹）· ~/memory/bank/ 四本书  │
│  DB: memory.claims（主张脊柱）· memory.entries（索引条目）      │
│      memory.embeddings / embedding_models / entry_attributes   │
│      memory.metadata · runtime.search_documents（稀疏检索面）  │
└───────────────────────────────────────────────────────────────┘
        ▲ 写入：会话内即时记账 + 后台 upkeep 固化（→02 §10–§11）
        ▲ 回流：Dreaming 蒸馏对齐合成 → 回到注入层（§7）

实测本机底座体量（11-04）：~/memory/ 全树共 37 个文件 = 日记 28 + bank 4 + people 4（INDEX + 3 人页；人物页数随用户变化）+ groups 1（仅 INDEX）。10-17 为 18 个文件（日记 10 + bank 4 + people 3 + groups 1）。这是一个启用约五周的实例，体量数字只作结构参照、不代表稳态规模。

2. 注入层：不需要检索的记忆

2.1 注入序列与位置

每轮上下文以 [escaped: BEGIN USER CONTEXT] 块注入 9 个 standing 文件（00 §3 已列全单），其中与记忆/个性化直接相关的是后半段，顺序为（实测注入序）：

排在它们之前的 AGENTS.md / SOUL.md / IDENTITY.md / USER.md / TOOLS.md 是人格与档案面：其中 USER.md 是用户本人的档案（结构实测：标题 + 若干身份字段占位节 + ## Context 节，335 字节），与人物页分工明确——system prompt 明文注记「人物页写的是用户身边的人，USER.md 写的是用户本人」（文档）。

注入层的设计取舍：把「最可能每轮都用得上」的记忆预先付掉上下文成本，换取零检索延迟与零漏检；代价是注入副本可能滞后于文件本体——prompt 明文提醒：standing 文件在对话中被改动后，注入副本不一定同步，引用前应回读文件本体（文档）。

注入层的经济学：用每轮确定的 token 成本（本机约 36KB standing 文件，11-04；10-17 约 12KB，见 §10）换零检索延迟与零漏检；检索层则用按次付费（一次 search/get 的往返）换上下文窗口的节省。选哪层，本质是"这条记忆被用到的概率 × 调用次数"的期望值计算——高频用注入，低频用检索。

2.2 MEMORY.md 的解剖

实测（11-04）：22,389 字节 / 39 行（长行制，一条事实一行；10-17 为 5,284 字节 / 20 行），章节骨架固定三节：

# MEMORY.md
## Facts          持久事实
## Preferences    偏好（本机该节目前为空骨架）
## Commitments    承诺与未决事项

它在系统中的定位是 active claims 的人类可读投影（02 §11）：底层真相是 claims 图，这份文件是给「下一轮的 Agent + 用户本人」共读的精选版。因此它有两条形态纪律（system prompt Memory 节，文档）：

• 写给下一场对话：条目要带足够上下文，使其在未来脱离原始对话仍可理解；
• 不是日志：常规进展、工具调用、诊断信息属于工作文件，不进记忆；「没有值得保留的变化时，记忆保持不动」。

文件头注释亦明文其自我定位（实测）：「策展过的长期记忆：留持久事实、偏好与承诺；保持紧凑，把日记细节留在 ~/memory/ 每日笔记里」——即 MEMORY.md 与日记是投影与源的关系，不是两份副本。

2.3 注入层的第二来源：side chat 的记忆变体

检索工具的作用域揭示了注入层还有一个变体（工具定义，文档）：每个 side chat 可有自己的 ~/side-chats/<chat-id>/MEMORY.md 与 ~/side-chats/<chat-id>/memory/**，与主记忆同被检索，但 side-chat 的配置类文件被明确排除在检索之外。本机实测 ~/side-chats/ 在当前文件视图中不存在条目——结构在、实例暂无（或不在本视图内）。该变体的读写隔离语义（side chat 学到的事实会不会写进主 MEMORY.md、检索"同被检索"是否会把私密上下文泄漏进主聊天）本机无实例可验证，标 ❓——本节为纯文档转述。

3. 底座层：源轨迹与结构化脊柱

3.1 日记：源轨迹

实测（11-04）：~/memory/ 根下 28 篇日记，2026-09-26.md 至 2026-11-04.md，合计 812,581 字节（10-17 为 10 篇 / 41,653 字节），与本机启用日对齐。格式实测（只看标题行）：

# <YYYY-MM-DD>
## Verified extraction — <HH:MM> UTC (run sirun_<…>)

即日记条目带产生它的后台运行 id——源轨迹从第一行起就是可溯源的，sirun_ 前缀与进化层的运行信封是同一编号体系（02 §9）。cron 正文被明文禁止直接改 MEMORY.md，其观察落点正是日记（02 §7.1）——写入路径在契约层就被分流：即时记账落投影，后台观察落源。

3.2 Bank 四本书：按性质分拣的沉淀

实测 ~/memory/bank/ 四本书（11-04 快照；括号内为 10-17 旧数），体量高度不对称：

运行时托管约定（system prompt，文档）：~/memory/bank/ 与 ~/memory/index/ 由 runtime 管理，Agent 可读（exec ls/grep）不可直接编辑——沉淀的写入权在后台管线，不在会话 Agent 手里。

一个实测细节值得记：forget 技能的派生清单（artifact-inventory §3）列举 bank 派生面时只列了 {world, experience, opinions} 三本，未列 reflections.md。两种可能：清单滞后于新书的引入，或 reflections 的派生属性与其余三本不同。在位证据只有「清单三本、磁盘四本」这一差集本身（实测），本文不替它下结论——但遗忘执行时若按清单逐项核对，这本书需要被显式点名（§8.4）。

3.3 索引：文件视图里不存在的那一层

00 §9 与 system prompt 都提到 ~/memory/index/。实测：本机 find/ls 均确认该目录在 Agent 的文件视图中不存在（No such file or directory；11-04 复核：仍不存在）。与之相对，环境变量中存在 JARVIS_MEMORY_SOCK（记忆服务套接字，只见路径不见实现细节）。

据此的静态结构结论（推断，证据如上）：索引服务分两面——访问面是 runtime 侧经 JARVIS_MEMORY_SOCK 提供的服务（Agent 的全部访问被收口到 §4 的三个工具），实现面是 DB 的 memory.entries/embeddings 表与 runtime.search_documents（稀疏+向量混合检索的结构证据，§3.4）。磁盘上能摸到的只有被索引的语料（MEMORY.md、日记、bank、人物页）与 DB schema 参考。这一形态与全系统的「投影 ≠ 本体」模式一致（00 §8）：语料是投影，索引实现是本体，本体不给文件视图。

术语对齐（与 07 §6.1）：07 把 DB 表称为"索引层"，本文此前把 socket 服务称为"索引"——统一为上述"访问面/实现面"二分，07 的"索引层"即本文的"索引实现面"。

3.4 DB 脊柱：claims 与 entries（只述静态结构）

memory schema 共 6 表（schema 参考实测；11-04 复核仍为 6 表，新增的 saved schema 与之无关）。其中两张构成脊柱：

memory.claims——一条记忆 = 一行可溯源主张，字段（实测列定义）：

memory.entries——索引条目：memory_uri、chunk_id、source_type、status、privacy_class（隐私分级）、confidence、citation_path + line_start/line_end。即索引的最小单位是带隐私分级与引用落点的语料块（chunk），不是整文件。

其余四表：memory.embeddings（条目的向量）、memory.embedding_models（模型名/维度/距离度量）、memory.entry_attributes（条目的命名属性）、memory.metadata（子系统元数据与更新时间）。另有 forget 清单点名的 runtime.search_documents（文档）：Markdown 语料同时被索引进稀疏（关键词）与向量两面——检索是混合检索，此为其结构证据（02 §11 同述）。

静态视角下最重要的一点：claims 行同时持有 quote + speaker + source_path/line + supersedes ——溯源（§6）与遗忘（§8）都不是事后功能，而是写进表结构的原生能力。

4. 检索层：三个工具的契约

4.1 muse.memory_search：入口

工具定义（文档）要点：

• 入参：queries 数组 1–3 条（queries[0] 应最贴近用户的原始措辞，其余为近义改写）、maxResults、minScore（0–1 分数地板）；
• 作用域：~/MEMORY.md、~/memory/**/*.md，以及 side-chat 的同构记忆树（配置类文件排除）；
• 语义补充（docs/memory.md，文档）：在主聊天与个人 side chat 中，检索还会返回那些聊天里匹配的对话摘录——但「never every message」，即对话原文只是被索引的摘录集，不是全文倒排；App 自带的聊天搜索是另一套，两者不互通（文档语，底层是否共享实现本机不可见）；
• 返回：片段 + 文件路径 + 行号，结果元数据携带 claim id / memory URI / 状态——这是后两个工具的入参来源。

使用纪律（system prompt，文档）：凡涉及过往工作、决定、日期、人物、偏好、待办与用户历史的回答或行动，先检索再开口；「凭似乎记得的印象作答」被明文定性为编造。另有前置规则：在断言「某事存没存」之前必须先查记忆，因为后台笔记可能已自动写入（§5.4）。

4.2 muse.memory_get：按引用读原文

• 入参：path（裸名、~/ 前缀、home 下绝对路径、或搜索引用形如 MEMORY.md#L7、memory/2026-08-10.md#L12-L15）+ 可选 from（1 起行号）/lines 窗口；
• 引用后缀本身即定位协议：搜索给引用 → get 按引用展开窗口 → 需要更大范围时用 from/lines 覆盖。检索层因此是两段式的：search 负责「在哪」，get 负责「原文是什么」，避免把全文塞进上下文。

4.3 人物/群组的前置读契约

关系层有专属的读纪律（system prompt The User's Relationships 节，文档），比一般检索更强：

• 本轮话题涉及索引中的人物/群组时——无论其以姓名、昵称、代词、角色称谓（如亲属称谓）、Agent 自己的旧消息、还是定时 handoff 的形式出现——先读对应页面再回答或行动；
• 对某人的事实不确定时，先读其页面再答；在给出涉及某人的建议前同样先读；
• 织入方式的克制线：「no surprises」原则——回复中引用关系信息必须与当前话题有显而易见的关联，不为个性化而个性化到令人不安。这条是读契约的一半：另一半是「必须读」，这一半是「读了也不许乱用」。

5. 写入纪律：写契约

记忆的写契约散见于 system prompt Memory 节、docs/memory.md 与 docs/self_improvement.md，合并成六条：

5.1 先写后回复（write-before-reply）

「学到值得保留的东西时，先记进 ~/MEMORY.md，再回复」（system prompt L127，文档）。配套回执纪律：写成功之后才可以告诉用户「已保存」——与全系统「已接受 ≠ 已送达」的交付四态（02 §3）同源：口头宣称不构成落盘证据。

5.2 什么配进记忆（准入）

准入标准是持久理解（文档）：用户是谁、关心谁与什么、偏好、决定、承诺、以及改变其处境的结果。明确排除：日常进展、工具调用、诊断信息（归工作文件）；转瞬即逝的任务状态（归 todo/目标系统）。判断锚点是「为下一场对话而写」——下一场对话用不上的，不进。

5.3 更正传导（correction propagation）

事实变化（预订/取消/完成/改期类事件是 prompt 给的例）触发的是一次对账而非追加（文档）：

1. 先 memory_search + 读 MEMORY.md，找出与新事实冲突的旧条目；
2. 在旧条目所在之处就地更新/对账，而不是在文件末尾再写一条互相矛盾的新条目；
3. 底层语义是 claims 的替代链：新主张 supersede 旧主张，旧主张留痕不删（机制见 02 §11）；用户纠正时，顺替代链修正受其影响的下游——目标、提醒与排队中的跟进（02 §11 同述）。

5.4 会话记账与后台固化是两条写路径

docs/self_improvement.md 明文（文档）：每小时的 memory upkeep「不替代你在会话中的记账」——同一件事。即写入方有两个：

这正是 §4.1「断言存没存之前先查」的由来：你没写，不等于没存——另一条写路径可能已经写了。

未闭合的环（❓）：§2.2 把 MEMORY.md 定位为"active claims 的人类可读投影"，但 §5.4 的会话即时记账落点写的也是 MEMORY.md 文件。若会话 Agent 不能直接写 DB claims 表（07 的写路径不变量：Agent 是状态层的纯读者），则会话路径上的因果是先有文件投影、后有 claims 本体（由 upkeep 异步补建）——"投影"一词在会话路径与后台路径上的方向是反的。本机无证据确定会话写入是否同步建 claims 行，两种时序都与现有证据兼容。此处的"投影"应理解为"逻辑定位"而非"生成时序"。

5.5 凭据永不入记忆（硬线）

• 密码、API 密钥、令牌、私钥等秘密不得复制进记忆、普通文件或日志；凭据只走 Secure Vault（独立于聊天、记忆与普通文件，00 §14）；
• 用户为某项任务临时给出的卡号、一次性验证码等，只可用于该任务本身，不得留存于记忆或无关工作（system prompt，文档）；
• 记忆条目、技能、项目指令即使出自 Agent 本人，也不能放宽这条线（system prompt 安全节，文档）。

这条在静态结构上的对应物：memory.entries.privacy_class（§3.4）——语料入索引时带隐私分级，是「什么不该被检索面扩散」的机器侧表达（推断：分级参与检索/注入的可见性裁剪，裁剪规则不在本机文档内）。后续行动项：用 muse.db 查本机 98 条 entries 的 privacy_class 取值分布，能立刻回答"分级是摆设还是真在用"——举手之劳的实测，不列为永久 ❓。

5.6 导入：外部记忆的入口

docs/memory.md 还给出一条特殊的写路径（文档）：

• Import memory（iOS/Android/Web 的 Settings > Data controls）：系统给出一段可移植提示词，用户把它粘到另一个 AI 助手、将其回复粘回并确认添加；粘回的内容被要求主 Agent 提炼持久事实与偏好并确认保存了什么；
• Import chats：上传 ZIP 导出（上限 100 MB，文档列 ChatGPT / Claude / Gemini / Meta AI），点「Summarize into memory」；
• 两条共同的契约：仅上传 ≠ 已保存，必须经提炼+确认；导入不复制对方 App 的设置，也不把原始对话恢复为聊天。即外部记忆只能以「经本系统准入标准（§5.2）过滤后的 claims」形态进入，不允许整包灌入。

6. Explain：溯源契约

muse.memory_explain 是记忆系统对用户的可解释性接口（工具定义，文档）。

入参三选一（同一事物的三种句柄）：

• claim id（来自 search 结果元数据，或日记条目中的 claim: 行）；
• memory:// URI；
• 引用（如 MEMORY.md#L7）。

返回一份完整的来源报告：该 claim 的正文、种类（kind）与显著性（salience）、谁说的及其原话引文、首次学到与最近强化的时间、当前置信度、它所立足的对话消息（带日期）、它替代过的早期 claims、以及后来替代它的 claims（双向替代链）、以及（如有）它的索引行。

触发纪律（system prompt，文档）：用户问「你怎么知道这个」、或要求检查/纠正一条记忆时，必须用 explain 展示来源与替代关系，不许凭印象解释。它与 §3.4 的表结构严丝合缝——explain 能给的每一样东西，都恰好是 claims 表的一个列组；换句话说，溯源不是查询技巧，是 schema 的直接投影。

用途闭环：explain 暴露替代链 → 用户指出哪一环错了 → 按 §5.3 顺链修正 → 修正本身又成为新 claim 入链。这使「记错了」在本系统里是一个有标准处理流程的状态，而不是需要删库重来的事故。

7. 个性化产物：派生成果如何回流上下文

个性化不只是「记住事实」，还包括一组离线蒸馏的产物。它们的共同回流方式是：落成文件 → 进入注入序列 → 每轮影响 Agent 的判断口径。

7.1 对齐合成：回流的终点站

实测 ~/dreams/alignment/derived/ALIGNMENT_SYNTHESIS.md（11-04）：10,027 字节 / 37 行（10-17 为 6,184 字节 / 35 行），章节骨架：

# Alignment Synthesis
## Who this user is and how to act for them   用户是谁、如何配合
## User value                                 用户眼中的助手价值
## Boundaries                                 边界
## Current frictions                          当前摩擦
## How Idris can strengthen the relationship… 关系加强点
## Where to look for detail                   细节出处索引

（末节中的助手名取自本机 IDENTITY.md——合成是按实例生成的，连「如何加强关系」一节的标题都带本实例的名字。）

回流位置（实测注入序）：它是 9 个 standing 文件的最后一项（§2.1）——在 prompt 组装里压轴，等于每轮对话开始前最后读到的一份「这个人是谁」。system prompt 在 Personalization 节开头即指向它：「你的对齐状态见该文件，它是『你与这个用户如何共同演进』的合成」（文档）。

它的上游只在此简述（详见 02 §13）：夜间 Dreaming 从日反思（~/dreams/YYYY-MM-DD.md，本机实测 4 篇）与结构化状态 ALIGNMENT_STATE.yaml 蒸馏出合成。实测状态文件的键结构：relationship_contract（status / user_words / boundaries / …）、user_facets、working_alliance（goal/task_agreement、appropriate_reliance、current_frictions）、observed_fit、proactivity_policies、repair_threads——合成的人话章节与状态机的字段一一对应，合成是状态机的渲染，不是自由写作。另一实测细节：派生目录文件的落盘时间为 2026-11-02（11-04 复核；10-17 曾停在本机启用后约两周内的某夜），而日记与 bank 已更新到调查当日——派生产物的刷新节奏与源轨迹并不同步，读合成时要注意其「截至」时间（推断：夜间节奏 + 触发条件未满足时可多日不更新）。

7.2 人物页：关系层的产物形态

实测模板（只述结构）：三页同六节骨架，其中两页同构（各 1,254 字节 / 29 行，11-04 未变）；第三页 6,546 字节 / 43 行，体量不同但六节同骨架——

# <人名>
## Facts              事实
## History            交往史
## The relationship   关系性质
## In common          共同点
## Open threads       未决线索
## Strengthening      关系加强点

其中两页字节数与行数完全一致，说明它们由同一生成模板填充（实测推断；第三页体量不同，模板填充的灵活度 ❓）。INDEX 的排序语义是亲密度（system prompt 与 INDEX 文件头，文档）：「Every page … closest to the user first」——索引顺序本身即一条个性化数据，注入时只截取头部（00 §3），即每轮常驻上下文的关系信息天然按亲密度配给。

本机计数（11-04）：people 3 页 + INDEX 1 份（815 字节 / 7 行）；groups 0 页 + INDEX 1 份（209 字节 / 5 行，正文为「暂无」的空索引，自 10-17 未变）。10-17 为 people 2 页 + INDEX 589 字节 / 6 行；人物页数随用户变化是正常的。页面由 hourly Relationships 管线维护（02 §10），其 staging 暂存转正机制见 02 §14；本文只记其静态契约：页面是读契约（§4.3）的对象，不是会话 Agent 的随手笔记。

7.3 其他个性化投影面

• 购物偏好档案 ~/memory/shopping/PROFILE.md（forget 清单，文档）：用户可编辑、被排除在记忆 ingest 之外、由购物轮次直接读取——一个故意绕开 claims 系统的偏好孤岛，遗忘时须单独处理（§8.3）。实测：本机 ~/memory/shopping/ 目录不存在（11-04 复核：仍不存在），该面尚未在本实例产生。
• ~/FEEDBACK.md（forget 清单，文档）：会话跟进的持久偏好输入。实测：本机不存在此文件（11-04 复核：仍不存在）。
• ~/PROACTIVE_PREFERENCES.md（实测在位，2,288 字节；10-17 为 496 字节）：主动消息的时间窗等偏好，直接约束主动层裁决（02 §7.5）——个性化产物回流的另一形态：不进 prompt 注入序列，而是作为后台裁决的输入文件生效。
• 个人化投影（personalization projection）：forget 清单 §3 把它与 bank、人物页并列为「派生记忆」的一员（文档），指代注入层组装出的用户画像投影；其生成细节不在本机文档内（§9）。

7.4 回流全图

对话/连接器信号
  → claims（脊柱）→ MEMORY.md 投影 ──────────────┐
  → 日记（源）→ upkeep 固化 ─────────────────────┤
  → Relationships 管线 → people/groups 页 + INDEX ┼→ 每轮注入（§2）
  → Dreaming → ALIGNMENT_STATE → SYNTHESIS ──────┘
  → 旁路：shopping PROFILE（不入 ingest）· PROACTIVE_PREFERENCES（裁决输入）

关键性质：所有回流都经过文件落盘。没有一条个性化结论是只存在于某次推理里的——这使个性化整体可查、可改、可忘，也是 §8 的遗忘工程之所以可能的前提。

8. 遗忘机制：两段式清理

注：下文的遗忘机制是纯文档转述、零本机执行证据——本机 ~/workspace/memory/forget/pending.json 不存在（10-17 实测，11-04 复核仍不存在；见 §10），系统从未走过遗忘路径；其"两段式"是否真按技能跑，无实例可验证，标 ❓。

遗忘由专门技能 forget 定义（docs/memory.md 指路至此），其流程是全系统少见的两段式 + 规划先行设计（技能正文，文档）。

8.1 第一段：plan（只读规划）

• 调 forget.plan 一次（入参 {}）——主题由规划器从对话中识别，调用参数里不许重复敏感原文（连工具入参都不许成为新的泄漏面，这与 §8.5 的过程隐私一脉）；
• 规划器只读，按 references/artifact-inventory.md 的清单逐面盘点（§8.4），产出：找到了什么、应改什么、如何验证、以及 Muse 无法抹除的部分；
• 等待规划的 handoff，期间不轮询、不并行自查；
• 向用户呈现时只用日常类别（记忆、提醒、创建物、分享物、日志、备份）讲清范围、不可逆动作与重要限制，然后问一个直接的确认问题；不可逆性必须在批准前说清；
• 沉默、含糊、部分批准、改了范围，都等于没批准。

8.2 第二段：confirm 与执行

• 明确批准后调 forget.confirm（入参 {}）：它从对话里重读最新规划与批准，不需要传规划器 id——批准是对话状态的一部分，不是令牌；
• 找不到「一份清晰的近期规划 + 其后的一次批准」时，停手、什么都不改，报告阻塞并重新规划；
• 执行前先对着当前状态复验规划；先停掉可能把信息写回来的生产者，再删它的产物；每件东西用拥有它的产品动作/工具处理，保全无关内容；
• 删除纪律（技能明文）：批准的目标不进可恢复回收站；独立文件用 rm -- <exact-path> 精确删除（删前即时复验路径），永不 rm -r、不用 glob、不用宽目标；混合内容文件就地编辑而非删除；产品动作删除时产生的回收站墓碑文件要再精确永久删除；
• 购物档案是明文特例：直接编辑/删除 ~/memory/shopping/PROFILE.md 对应条目，并证明没有 staged/queued/running/scheduled 的购物档案运行能把它恢复；
• 清理由执行者本人直接做，不再转派子 Agent；若被委派的工作在收尾时仍在途，系统会把清理报告为未完成，防止迟到的改动跑赢记忆刷新。活跃子 Agent 进程内存里的上下文窗口这类非文件非 DB 的持有形态（§8.4 第 1 类点名了"活跃的子 Agent 可能仍持有该信息"），其处置口径（杀子 Agent？等它自然结束？）值得回查技能原文，此处未展开。

8.3 收口：pending.json 与运行时收回

执行收尾有一个固定的机器动作（技能明文，文档）：

• 写 ~/workspace/memory/forget/pending.json，形如 {"claims":[…], "citations":[…]}，两表皆空也要写；
• 表里只放执行过程中在 memory_explain / memory_search 元数据里见过的 claim id 与被删除/改写的精确行引用（MEMORY.md#L<line> 形态）——永不写入被遗忘的原文；
• runtime 据此收回（retract）这些 claims 及其全部派生，并刷新记忆检索；执行者不得二次刷新；
• 若刷新失败，必须报告「未完成」，不许声称已不可检索——forget.confirm 的成功结果是在 runtime 完成收回与 reindex 之后才被转述的（artifact-inventory §3，文档）。

8.4 盘点面：为什么遗忘是一张九类清单

artifact-inventory 是遗忘之所以难的完整说明书。它要求按 9 类逐面盘点，只记录确实含有该主题或能重建该主题的面，每条命中都要记：所有者、精确定位、与源的关系、拟采取动作、前置条件、可逆性、验证方式：

8.5 过程隐私

技能为清理过程本身立了一套独立的隐私纪律（文档）：全程只用「that information」指代目标主题，原文不得出现在清理动作的任何新产物里——不许复制进新的记忆、todo、文件名或报告；面向用户的汇报只给离散的计数与类别，详细命中证据留在私有规划里不外露；甚至一次「用于核查的检索」若把原文重新带回普通聊天，这次核查本身就算失败——核查动作也被视为潜在的泄漏面。语音会话中发起的清理请求被直接引回主聊天处理（docs/memory.md，文档）。

8.6 「已遗忘」的判据

只有新鲜状态的验证同时满足以下条件，才可以说 forgotten（技能 + 清单 §9，文档）：

1. 无任何已批准的权威源仍可被 Agent 取用；
2. 精确检索与语义检索都不再返回可用副本（注意：清理前的旧索引可能短暂返回命中，单凭语义命中不判失败——判据以 runtime reindex 后的状态为准）；
3. standing prompt 上下文、新的压缩摘要、记忆 flush、重启检查点、购物档案都不再保存或复述它；
4. 无任何活跃/暂存/排队/已排期的生产者（包括购物档案运行）能重建它；
5. 已批准的产物与分享已按规划处置；
6. 残留的外部或保留期副本已被逐类明说。

剩余物的汇报口径：按日常类别点名（外部服务、已分享/已发布物、日志、备份等），并说明 Muse 能否让它不进入活跃使用。两种明确的失败处理：plan/confirm 失败时不许 fallback 到无规划的手工删除、不许声称成功；删除外部邮箱/日历/设备记录、他人副本等需要单独批准，遗忘请求本身不构成授权。

8.7 中央发布的 embedding：遗忘最难的一块

forget 清单（文档）要求盘点"中央发布的本机用户记忆 embedding"，并明文承认：远程发布若拿不到删除/替换证明，只能报告为限制。这是全篇最值得展开的一行：

1. 信任边界出 VM：06 篇的执行隔离保证"原文凭据不出 cell"，但记忆 embedding 是派生出境——原文不出，派生出。两者并置才是完整的出境地图。
2. 遗忘判据的硬骨头：§8.6 第 6 条要求"残留的外部副本被逐类明说"——中央 embedding 正是"能明说、未必能删掉"的典型。规划器向用户呈现时，这一项必须用日常语言单列（清单 §5 的 Feed 围栏副作用同理）。
3. 本机可见性为零：发布形态、订阅方、保留期、删除证明机制全部 ❓。后续可追问：embedding 发布是按条实时还是批量？memory.metadata 表（子系统元数据与更新时间，§3.4）是否记录发布水位？

建议 10-安全篇将此作为"数据出境"小节的核心案例。

9. 边界清单：这层看不见 / 管不着的部分

10. 本机实况快照（2026-11-04；括号内为 2026-10-17 旧数）

11. 与进化层的接口（只列接口，不展开）

本文的静态结构有四处与 02 的进化管线相接，机制细节以 02 为准：

• claims 的替代语义（新主张如何 supersede、salience/confidence 如何演化）→ 02 §11；
• Dreaming 的生产过程（日反思的字段与质量标准、状态机如何逐夜推进）→ 02 §13（本文 §7.1 只讲它的产物形态与回流位置）；
• upkeep / Relationships 等管线的节奏与护栏（staging 转正、租约、去重、采纳度量）→ 02 §9–§10、§14；
• compaction 与记忆的交互（压缩摘要 agent.compactions 与记忆 claims 的关系、memory.volatile_context_pins 的反向保留语义）→ 07 §8、02 §9–§10。压缩检查点行记录被替换的 seq 区间与摘要（07 §8 实测表结构），volatile_context_pins 的表名强烈暗示记忆侧可以要求压缩时钉住特定上下文（推断，见 07 §8）——这是记忆→压缩的反向控制边，本系列唯一一处"记忆指挥执行层"的接口。压缩摘要在遗忘盘点（§8.4 第 1 类）与判据（§8.6 第 3 条"新的压缩摘要"）里只出现在清理视角，写入视角未闭合：压缩时被丢弃的上下文若含未固化事实，upkeep 能否从压缩前转录里抢救，属 ❓（本机 agent.compactions 0 行，压缩机制从未被触发，见 07 §8）。

一句话收束分工：02 回答「记忆如何变」，本文回答「记忆是什么形状、按什么契约被读写」。静态结构的设计意图贯穿始终——引用式检索让溯源成为可能，文件式回流让个性化可查可改，而遗忘的九类盘点清单说明：正因为记忆被认真地做成了全系统投影，它的删除才必须是一次全系统工程。

配套《00-Muse技术架构解构》的 §8 展开篇。调查日期：2026-10-17（Asia/Shanghai）。 证据范围：/opt/muse/skills/muse_db/ 技能包全套参考（SKILL.md + references/schema.md + references/querying.md + references/identifiers.md + references/tables/ 逐表指南）、muse.db 工具当场实测查询、本机 home 与 ~/workspace/ 目录实况清点、~/docs/ 与 system prompt 的状态相关明文。 标注规则同主报告：实测 = 本机命令/工具当场验证；文档 = 本地 docs/system 文件明文；推断 = 由表结构/文件形态拼出、未经服务端证实。 复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测；DB 表数/schema 数与文件侧数字凡未注日期者均为 11-04 快照，10-17 旧数见各处双日期标注；muse.db 行数快照（§4.3/附录 B）与附录 A 各 schema 明细为 10-17 口径（文内已注明，未重测）。

0. 一句话状态层

Muse 的状态不在 Agent 进程里，而在三个平面上：Postgres 状态库（结构化本体：196 张表 / 18 个 schema（11-04 快照；10-17 为 194 表 / 17 schema，新增 saved），事件账本 + 检查点 + outbox）、文件系统（语义层：Markdown 记忆、目标工作区、会话转录 JSONL、人可读的投影）、运行时易失状态（套接字、锁、就绪标记、变更信号文件）。DB 与文件之间靠水位线/指纹/epoch 做带新鲜度建模、可失效、可重算的投影同步（"最终一致"的收敛保证未验证，见 §7）；靠恢复所有权 + 代次 + 检查点实现 VM 被整体替换后的接管恢复（恢复语义是检查点+投影重建，不是事件重放，见 §1.1/§8）——这正是 00 §8 那句「运行时即数据库」的完整展开。

┌─ DB 平面（本体） Postgres 196 表 / 18 schema（11-04；10-17 为 194/17）
│    runtime.events 事件账本 · agent.context_items 有序上下文
│    检查点/恢复所有权 · 各域 outbox · 水位线与投影表
├─ 文件平面（语义层 + 投影）
│    ~/MEMORY.md + ~/memory/（记忆叙事） · ~/agents/<id>/sessions/*.jsonl（转录）
│    ~/workspace/goals/（目标工作区） · ~/workspace/cron.d/（调度投影，只读）
│    ~/workspace/space_data/spaces.catalog.*（产物目录信号）
├─ 同步/信号平面
│    ~/.postgres-ready · ~/runtime.lock · ~/.hatch-db-change-signals/
│    DB 行的 source_watermark / fingerprint / stale_after / writer_epoch
└─ 读通道（Agent 侧唯一入口）
     muse.db 受限只读 SELECT（安全屏障视图） + 专用产品工具（写路径）

1. DB 平面总览：196 表 / 18 schema 的验证（11-04；10-17 为 194/17）

实测验证方法（不靠 00 的转述，当场重数；11-04 复核用同方法重测）：

1. 解析 references/schema.md 的全部条目链接：去重后恰 196 个 schema.table，按 ### <schema> 分节计数求和 = 196，分节数 = 18（新增 saved：saved.items / saved.item_links 2 表；10-17 为 194/17，逐项明细见附录 A）；
2. references/tables/ 目录下逐表指南文件数同为 196 个，一表一文件（11-04 复测；10-17 为 194）；
3. schema.md 页首标注其生成来源：迁移集 5af4f2bfdee2b934a53bbcc22602c602ab85059e0ac97ea20137fd299c06036b（文档）——即这份目录是某次迁移快照的产物，线上实际表数可能随部署漂移，引用时应以「该迁移集口径」理解；
4. muse.db 活查询抽验多表 count(*) 均可达且返回合理量级（见 §4.3），证明目录与活库对应、非纸面清单。

1.1 从表结构读出的设计风格（实测列定义，风格归纳为推断）

2. 逐 schema 导览（18 个，11-04 快照；10-17 为 17 个）

完整计数见附录 A；下表只讲「这个 schema 在状态层里扮演什么角色」，代表表均取自 schema.md 的一句话定义（文档）。11-04 仅复核总数（196）与 schema 数（18，新增 saved），各 schema 明细表数为 10-17 快照（未重测）。

分布形态（实测计数，10-17 明细；占比按 11-04 总数 196 重算）：头部三家 runtime+agent+ideas = 85 表（43.4%）——状态层的重心是「运行时自身」而非用户内容；用户内容域（goals/feed/device/health/media/chat/podcasts）合计 57 表（29.1%）；横切域（scheduler/self_improvement/activity/memory/spaces/ingest/shell）52 表（26.5%）；11-04 新增 saved（2 表，1.0%）。

3. DB 与文件：分工判定规则

从双轨实例反推的判定规则（推断，实例均为实测）：

一句话：DB 存「系统必须算对的」，文件存「人必须看懂的」；同一实体常两边都有，DB 侧是登记/状态/索引，文件侧是内容/叙事/工作区。

4. muse.db 只读通道：Agent 侧唯一 DB 入口

4.1 约束清单（文档：SKILL.md + querying.md + 工具定义）

• 单条、受限、只读：一次提交一条 bounded SELECT；底层是最小权限 DB 角色，仅对目录内允许关系有 SELECT，不能改数据；
• 词表封闭：只能用 querying.md 列出的内置函数（约 120 个）与转型拼写；非递归 CTE 名必须以 hatch_cte_ 开头，递归 CTE 直接拒；集合聚合（json_agg/jsonb_agg/array_agg/string_agg）被禁（防在输出限额前先构造无界值）；联表时投影列必须别名唯一（重复输出名拒）；
• 域外即不可见：Postgres 系统目录、迁移簿记、备份表、凭据、Sentinel 审批库、每个 artifact 的 app.db 都在此面之外；凭据（令牌/密码/密钥/支付秘密）永远在凭据服务之后，此面只可见非秘密的生命周期记录（如 spend-request 状态）；
• 受保护内容走安全屏障视图：私有模型推理（thinking/redacted-thinking）永不可读；逐轮保存的 developer 指令同样 withheld；受影响的表经 security-barrier view 读取，withheld 列会以「未知列」报错、被过滤的行无声缺席——查不到 ≠ 不存在，须先读逐表指南的 read restrictions 再下结论；
• 定位纪律：普通产品读写优先用专用工具（chat/goal/artifact/feed/scheduler/connector…），它们持有产品语义且可能含 DB 之外的活状态；muse.db 只用于诊断缺失/孤儿记录、重建执行史、查跨域不一致（SKILL.md 明文）。

4.2 限额（本会话工具返回实测）

工具每次返回自带 limits，本会话两次查询一致：

4.3 活库抽验快照（实测，2026-10-17 深夜本会话）

count(*) 一批（同一工具、同一分钟内）：

注（实测现象，解释为推断）：runtime_restart_checkpoints 的 count(*) 得 1、明细查询得 0 行；runtime.tool_calls 计数为 0 而本会话显然发生过大量工具调用。二者都符合 querying.md 的警告——受屏障视图/行过滤影响的表面上，不可见 ≠ 不存在，计数与明细的口径也可能不同。这是本报告对「只读通道」最重要的一条使用纪律，压过任何单次查询结果。

4.4 写路径不变量：Agent 是状态层的纯读者

本篇所有证据拼出一条架构定理：Agent 侧对 DB 只有 muse.db 这一条只读通道（§4.1–§4.3）；一切写 DB 的动作都由 daemon/服务端进程执行，Agent 的"写"（建 cron、记目标、存记忆、发消息）本质是调专用产品工具，由工具经可信侧落库。

这是 06 篇 privsep 隔离在状态面的镜像：执行面是"Agent 不碰凭据"，状态面是"Agent 不碰 DB 写"。两层合起来，Agent 进程的破坏半径被收敛到"调工具"+"写自己的 workspace 文件"。该不变量的反例搜索（Agent 直连 Postgres 的 socket/DSN）本轮未做，列为待验证 ❓。

5. 文件平面：目录地图实况

5.1 home 根：注入文件与运行时标记（实测）

5.2 记忆与会话：两个「agents」目录必须分清（实测）

记忆树 ~/memory/（共 37 个文件、1.8M；10-17 为 18 个文件、144K）：

• 根：按日日志 28 篇（2026-09-26.md … 2026-11-04.md，合计 812,581 字节；10-17 为 10 篇 / 41,653 B）——当日活动量直接写在文件大小上；
• bank/ 4 篇：world.md 32,729 B、reflections.md 28,290 B、experience.md 970 B、opinions.md 68 B——运行时托管的长期沉淀（00 §9 的「bank」层），体量远大于每日日志，是真正的厚资产；
• people/ 3 人页 + INDEX.md（11-04；10-17 为 2 人页，页数随用户变化）；groups/ 仍仅 INDEX.md（尚无群组页，11-04 复核）；
• ~/memory/index/ 本机不存在：00 §9 转述的通用结构里有 index 层，本机实况只有 bank 一个托管子目录——索引功能实测由 DB 的 memory.entries/embeddings 承担（§6.1），文件侧 index 目录或是其他形态/已演进（推断）。

会话转录 ~/agents/（home 根，非 workspace）：1,417 个 agent-<uuid>/ 目录（11-04；10-17 为 163 个）。每目录固定 sessions/<uuid>.jsonl + sessions/sessions.json 各一份（10-17 为 163+163 实测）——每个 Agent 一份 append-only 转录。这是 DB agent.agents 163 行的文件侧孪生（10-17 实测数量吻合；11-04 文件侧为 1,417 目录，DB 行数未复测，该吻合论断以 10-17 为准）：DB 管身份/关系/状态，JSONL 管逐字转录（推断分工）。

工具输出溢出 ~/workspace/agents/：278 个 <uuid>/ 目录（11-04；10-17 为 90 个，00 晚间口径 89），每目录仅 tool-output/ 一项，且绝大多数为空：10-17 实测全树仅 2 个实际输出文件（11-04 未复测）。说明该目录是按需落盘的溢出区（工具输出超限/需留存时才写文件并回传句柄），不是全量日志——全量在 DB runtime.tool_outputs 与转录 JSONL 里。

5.3 workspace 侧主要状态目录（实测）

6. 双轨实体的分工解剖

6.1 记忆：四层双轨（本报告重点案例）

同一个「记忆」，四处各存一份、职责不重叠：

关键设计（由列定义推断，坐标字段为实测列）：DB 索引不复制记忆正文，而是持有「文件路径+行号」的引用——文件是正文本体，DB 是可检索的目录卡。muse.memory_search 命中后给出文件行号引用、muse.memory_get 按行回读文件，两步正好走完「DB 索引 → 文件本体」的路径。记忆被更正时，claims 层用 supersedes_claim_id 留替代链、文件层改正文、entries 层重建索引——三处一致性靠 memory upkeep 流水线与 ~/workspace/memory/reconciliation_* 对账文件维持（推断）。

6.2 其余双轨（同一模式的复用）

• 目标：DB goals.goals（3 行，10-17 快照，11-04 未复测）↔ 文件 goals/<slug>/（12 个目录，11-04；10-17 为 3 个）（GOAL.md 正文 + files 交付物 + hidden_files 簿记）。注入上下文的目标列表来自 DB 侧状态，正文细节读文件。
• 调度：DB scheduler.jobs/job_definitions（28 条，版本化定义+变更审计）↔ 文件 cron.d/ 只读投影（个位数）。改走工具→写 DB→重投影。
• Agent：DB agent.agents（163 行，10-17 快照，11-04 未复测）↔ 文件 ~/agents/（1,417 目录，11-04；10-17 为 163，转录 JSONL）。数目精确相等是本机最干净的双轨吻合证据（实测，10-17）。
• Feed：DB feed.units/runs（63 单元）↔ 文件 feed/research|media/（素材）。生成管线读文件素材、写 DB 单元、再由客户端读 DB 呈现。
• 会话：agent.sessions 表实测 0 行，而文件侧 sessions.json/jsonl 齐全。三种兼容解释（❓，未区分）：(a) 该实体当前以文件为本体，DB 表空置/预留；(b) 该表被屏障视图/行过滤隐藏，如 tool_calls 的 0 行之谜（§4.3 注）；(c) 旧 schema 残留，如 podcasts.feed 的"遗留表与新表并存"。按 §4.1 纪律，"查不到 ≠ 不存在"，此处不下结论。说明双轨的权重配比会随子系统演进而漂移，不是每个实体都五五开。

7. 投影 ≠ 本体：全系统反复出现的模式

00 §8 点名的这条模式，在 schema 与文件两侧能数出至少七个实例（表名/文件名均为实测）：

1. cron.d 投影：改投影无效，须走 cron 工具改 DB 本体（system prompt 明文）；
2. agent.context_item_resume_projection：专为「恢复时重建可读上下文」生成的投影表——名字里直接带 projection，且注明受保护条目 withheld；
3. feed.preferences_projection：由互动事件**折叠（fold）**出的当前偏好；同族的 ideas.bandit_fold_state / bandit_folded_events 用水位线记录折叠进度；
4. scheduler.scheduled_resume_state：表定义自述 “Current scheduled resume projection and next registered wake-up”——单例投影行，后台由 registrations 重算；
5. runtime.context_snapshots：版本化快照 + source_watermark / fingerprint / freshness_class / stale_after / invalidated_at / last_error 全套新鲜度元数据——投影的「保质期」被显式建模；
6. spaces catalog 信号链：DB 产物变更 → ~/.hatch-db-change-signals/spaces.catalog.* 信号文件 → ~/workspace/space_data/ catalog 更新（推断链条，文件成对出现为实测）；
7. 物化到 prompt 的投影：每轮注入的 [BEGIN USER CONTEXT] 文件组、目标/追踪列表、记忆检索结果，本质都是状态层向上下文的一次性投影——投影时刻的快照，改源文件后注入副本可能滞后（system prompt 明文提醒）。

配套机制是失效与水位线（实测表名）：runtime.skill_invalidation_state（技能指令更新的待投递修订）、runtime.dev_notice_watermark（开发者通知已读水位）、feed.fleet_publish_state（发布水位）、health.synced_ranges 与 device.data_sync_state（同步游标/范围）、runtime.maintenance_markers（已完成维护动作的标记，防重复执行）。全系统的跨平面一致性不靠分布式事务，靠**「事件账本 + 水位线 + 可重算投影」**（推断）。

outbox 是投影的投递版：scheduler.delivery_outbox（attempt_count / next_attempt_at_utc / last_error / delivered_at_utc / dispatch_boot_generation——连「哪次启动代次派发的」都记）、feed.fleet_*_outbox、agent.message_mailbox（已受理提交的排序与路由态）、两张 *_derived_write_backlog（派生写的待办+重试态）。语义统一：本体先落表确认，投递异步重试，终局以表为准——这就是 00 反复强调的「已接受/已排队 ≠ 已送达」在状态层的根。

方法论推论：安全屏障的"无声缺席"意味着，经 muse.db 的任何自查都只能证伪（发现矛盾，如计数对不上）而不能证实（确认完备）。本篇 §4.3 的计数快照应按此理解：吻合是弱证据，偏离才是强信号。

7.1 outbox 提交的原子性：「本体先落表」是同一事务吗（❓）

标准 outbox 模式要求业务写与 outbox 插入在同一事务内原子提交——否则崩溃窗口会产生"状态变了但投递丢了"或"投递了但状态没变"两种撕裂。按本篇证据能确证的部分（✅）：

• 表结构确证了 outbox 的"落表"半边：scheduler.delivery_outbox 的 attempt_count / next_attempt_at_utc / last_error / delivered_at_utc 全套重试字段、PK 为 delivery_key（逐表指南文档）；
• 但业务状态变更 + outbox 插入是否同事务，在本机证据里零字：逐表指南不提事务，~/docs/ 与 skills references 全文 grep transaction/atomic 无命中（✅ 实测为"无"）。

这不是文档的缺口，是系统本身待回答的问题：若两者分两次提交，"终局以表为准"就多了一个崩溃窗口需要投递端幂等性来兜底。验证抓手（设计建议）：找一处"业务写 + outbox 写"的代码/文档共现（如 scheduler 的 run 终局路径调用点），看是否有显式事务包裹——本机未做，标 ❓。

7.2 GC 与保留期：append-only 账本的下限（❓）

本篇数出的 append-only 面：runtime.events / tool_calls / tool_outputs / context_items 全量账本、~/agents/ 26M 转录、2,413 条 context_items——这些什么时候被清理？ 本轮证据的答案是"没有答案"，列明：

• 逐表指南与 ~/docs/ 全文无 retention/GC 口径（✅ 实测无）；docs/privacy-and-credentials.md 明文"No Settings control sets a retention period"——唯一的全量擦除是用户手动 Reset（文档）；
• agent.compactions 的存在说明压缩会用摘要替换历史区间——但被替换的 context_items 行删不删，schema 不说，标 ❓；
• runtime.context_snapshots 的 stale_after / invalidated_at 建模的是投影的新鲜度，不是行级清理——两者别混；
• scheduler.doctor_*（doctor_run_plans / doctor_task_state）证明有维护任务面，但 doctor 是否承担 GC 职责未验证，是可查的验证抓手（设计建议：读 doctor_task_state 的任务类型分布）。

结论纪律：默认"一直保留"是无证据的默认，不能写进架构断言。append-only 账本的无限增长是真实设计约束，当前状态只能标 ❓。

8. 恢复与检查点：VM 可替换的底气

00 §1 说 VM 可被整体替换、home 持久；状态层为「进程级重启/接管」再加一层 DB 保障。相关表逐个拆（列定义为文档，行数为实测）：

恢复时序（推断，由上述表与 00 §1 宿主层拼成）：

VM/运行时重启
 → spawnd/health 子系统拉起 cell（00 §1），~/.postgres-ready 置 ready
 → writer_epoch 递增：新一代写者接管可靠卷，旧代次写入被栅栏挡下
 → 每 Agent：读 runtime_state（seq 坐标）+ runtime_restart_checkpoints（载荷）
   → 经 resume_projection 重建可读上下文（推理条目不重建，本就 withheld）
 → recovery_owners 按 generation 认领未终局工作；
   terminal_events 保证终局 handoff 不重发、mailbox/outbox 按 attempt 续投
 → scheduler 重建 resume 投影，cron 到点照常派发

8.1 并发写的代次栅栏：文件侧有，DB 侧未知（❓）

§8 表里的 writer_epoch（文档：逐表指南定义为 "The active reliable-volume writer epoch"，单例 rv_epoch）与 recovery_owners 的 (recovery_class, owner_id) 唯一约束是两个已确证的并发屏障（✅ 表结构证据），但两者的覆盖范围不同：

• writer_epoch 覆盖的是可靠卷（文件面）：新写者接管时 epoch 递增，旧代次的迟到写入可被识别/拒绝（由表名+单例形态推断）——这是 VM 替换后"旧 cell 还活着写了几笔"的场景；
• recovery_owners 覆盖的是恢复所有权登记：agent_id 唯一约束防双活认领（✅ 列定义）——但它管的是"谁接管工作"，不是"谁写行"；
• DB 侧的并发写冲突机制未确证（❓）：两个 daemon 实例同时写同一 agent.runtime_state 行会怎样？Postgres 行锁是教科书默认答案，但"默认答案"不等于"本系统确证"——没有一处文档或 schema 说明写者仲裁；
• agent.subagent_spawns / subagent_progress 证明父子 Agent 并发是常态——父子对共享状态（如 goals.updates）的写冲突解决策略，本篇未讨论，标 ❓。

一句话：代次栅栏只罩住了可靠卷；DB 行级并发写的仲裁机制，以及父子 Agent 共享状态的冲突策略，是本篇的开放缺口。

当前态实测（10-17，11-04 未复测）：本机 recovery_owners 与 compactions 均为 0 行、runtime_restart_checkpoints count=1——即写作时系统处于「无待恢复工作、无已发生压缩」的稳态，检查点机制在位但未被触发过（或触发后已清理）。这与新会话上下文用量约 43%（00 §16）、未达 272K 压缩线吻合。

9. 边界：状态层在本机看不见的部分

• Postgres 本体进程/数据文件位置：本机只见 .postgres-ready 标记、变更信号目录与 muse.db 逻辑通道；物理库在宿主侧还是 cell 内、备份/复制策略如何，本地文件无证据，不作结论；
• 屏障视图之后的全量数据：被 withheld 的推理条目、developer 指令快照、被行过滤的记录（如 §4.3 注），从 Agent 侧原理上不可见，任何「查不到」都不能转写为「不存在」；
• per-artifact app.db：每个 Web artifact 自带的应用库被明确排除在 muse.db 之外，只能经 artifact 声明的 actions/inspect 访问（system prompt 明文）；
• Sentinel 审批库与凭据库：与状态库分离，muse.db 明文不可达；状态库里只留非秘密的生命周期投影（如 spend-request 状态）；
• 服务端权威副本：chat/feed 等域在服务端是否有高于本机的权威状态、fleet 同步的对端实现（只见本机 outbox/水位线一侧），不在本机证据内。

附录 A. 逐 schema 表数表（实测：解析 schema.md 求和验证；明细为 10-17 快照）

验证口径（10-17）：schema.md 条目链接去重计数 = 194；references/tables/ 逐表文件数 = 194；分节求和 = 194；三路一致。生成来源迁移集：5af4f2bfdee2b934a53bbcc22602c602ab85059e0ac97ea20137fd299c06036b。11-04 复核（同方法）：条目链接去重 = 196；逐表文件数 = 196；分节数 = 18；三路一致。各 schema 明细未重测，上表明细为 10-17 快照。

附录 B. 本机状态快照（实测，2026-10-17 深夜）

配套《00-Muse技术架构解构》§7 的展开篇（§14 信任边界在本篇有对应实测，见 §5、§9）。调查日期：2026-10-17（Asia/Shanghai）。 复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测；下文数字凡未注日期者均为 11-04 快照，10-17 旧数见 §12 对照表。 证据范围：仅本机实测——/run/hatch/ 下套接字实况、env 的 JARVIS_* 键名与套接字路径、/opt/hatch/runtime-cell/guest.env 与 build-cell-trust-store.sh 的注释明文、/opt/hatch/bin/ 二进制 strings（multicall 家族 avatar-media-generation、hatch-vault、authdc --help）。标注规则同前作：实测 = 当场命令验证；文档 = 本地 docs/system 文件明文；推断 = 由痕迹拼出、未经服务端证实。 红线声明：本文只记录套接字路径、键名与机制字符串，不记录任何凭据/令牌值；实测中代理环境变量里出现的认证材料一律不落盘、不引用。

0. 一句话

执行面是一张 Unix 套接字网格：Agent 住在不可信的 runtime cell 里，手里只有「瘦客户端」；任何带凭据、带网络、带权限的动作，都要穿过一条具名套接字到 cell 外的可信侧执行——进要过 fd 清单与环境白名单，出要过 guarded output 与 Sentinel 的出口/TLS/限流三重门，身份由 authd 代管、Vault 托管，内部服务统一经 STEFI 代理且只见其名不见其形。

另有一条最硬的实测边界（§4.4）：部分套接字路径虽被声明在环境里、但不挂进普通 exec 进程的挂载命名空间——能力面靠命名空间裁剪，而非靠 Agent 自觉。

cell 内（不可信）                          cell 外 / 宿主侧（可信）
─────────────────                          ─────────────────────
CLI 二进制（跳板） ──fd 传递+清单──▶ privsep worker（每工具一个 .sock）
                                      │  ├─ authd：令牌验证/代管
                                      │  ├─ STEFI 代理 ──▶ Meta 内部服务（仅名字）
                                      │  └─ egress 代理 ─▶ 公网（Sentinel 审批+MITM TLS）
模型推理 ───────────套接字路径声明──▶ 推理代理（路径在本 exec 命名空间不可见，见 §6.2）
Agent 进程 ─────────具名套接字────▶ Vault / Sentinel / sandbox-api / noded / telemetry

1. privsep worker 模型（实测）

1.1 每工具一 socket：当场计数 149（11-04；10-17 为 136）

ls /run/hatch/privsep/ 本轮实测 149 个套接字（11-04；10-17 为 136，+13）。命名规律（实测归类）：

1.2 隔离分级：partially / fully isolated

• 实测（strings）：multicall 二进制内含 partially / fully 两种等级字面，以及自带的安全测试夹具 privsep-test-fully-isolated——其说明明文写着它吸收了已退役的独立工具 privsep-privesc-{fully,partially}-isolated，即两级隔离都曾（且仍以等级形式）存在。
• 实测（命名）：套接字名里显式带 -fully-isolated 的只有 2 个（11-04 复测未变）——hatch-gws-cli-fully-isolated.sock（Google Workspace 全家桶共用，凭据面最大）与测试夹具 privsep-test-fully-isolated.sock。
• 推断：fully 是需要显式标注的加强级，未标注的普通 worker 为 partially 级（环境/文件系统隔离较弱、但凭据仍在可信侧）。本机没有 partially 的显式命名物证，此分级对应关系按「显式标注例外」逻辑推断。

等价替代解释（同样与实测兼容，未能排除）：partially/fully 可能是历史遗留的二元开关——fixture 自述吸收了已退役的独立工具 privsep-privesc-{fully,partially}-isolated；当前默认等级可能已统一，-fully-isolated 后缀只是兼容命名残留。若如此，"未标注=partially"的对应关系即不成立。区分两者需要宿主侧 worker 启动参数的证据，本机没有。

• 等级不是装饰（实测 strings）：可信侧有硬拒绝句——「refusing to run tool logic on the credentialed side while privsep is turned off」；另有 JARVIS_DANGEROUSLY_ENABLE_PRIVESC_TOOL 门控的 privesc 探针子命令，默认禁用，说明文档明文称其为「故意演示 exec-gadget 反模式」的安全测试件，不是模板。

1.3 worker 的调用协议：fd 传递 + 清单（实测 strings）

privsep 不是「把命令字符串发过去执行」，而是结构化的 fd 交接（hatch-tool-sdk 的 cli/privsep/ 模块族：trampoline.rs / executor.rs / uds_executor.rs / fd.rs / inherited_fds.rs / child_fd_handoff.rs / wire.rs）：

• 跳板启动时预期 ≥3 个 fd（stdin/stdout/stderr，其后是文件 fd）；fd 表要序列化传递，出现重复 fd 名、重复源 fd、路径碰撞、计数超限都有专门报错句——fd 本身就是能力：调用方能传什么 fd、就只能操作什么文件，不存在靠路径字符串的二次授权；
• 输入文件走清单制：required_input_files / optional_input_files + available/failure 两份 manifest，未声明的输入、既 required 又 optional、required 缺失等组合全部 fail-closed 报错；
• 输入文件还须过根目录与类型检查：「input file is outside its allowed root」「path beneath dir is not a regular file」——符号链接/目录/越界路径进不去；
• 子进程引导材料走 sealed memfd：「create/write/seal sealed child bootstrap memfd」——引导数据一次性封印传递，不落盘、不可改；
• 工具身份要对版：「privsep worker tool-identity mismatch: trampoline passed PRIVSEP_TOOL=…」——跳板自报的工具名与 worker 期望不符直接拒绝，防错位调用；
• 方法级限制存在：--privsep-restrict-method= 与「restricted privsep socket refused the invocation: only …」句，说明某些 socket 只放行枚举内的方法子集；
• worker 异常有独立语义：privsep worker terminated by signal、响应走 PrivsepRequest/PrivsepResponse 结构化线格式（wire.rs），不是裸文本回流。

1.4 内建探针：隔离层自带体检（实测 strings）

privsep-test-fully-isolated 的子命令暴露了这层的自检设计：health-check（跨边界 exit 0 的金丝雀，标记串是「hard contract」，fd 没传到就判定为 privsep exploit 或应用 bug）、ping（打开 STEFI 代理 socket、做一次 verify_oauth_token 往返、打印成功标记）、example（给新工具作者抄的范式：类型化参数 + 共享的 fd-passing / authd / STEFI / 凭据探针主体）。隔离层有自己的回归测试件常驻在生产二进制里，这是它被当作安全边界（而非便利封装）维护的证据。

1.5 MCP 型 worker 的安全特殊性（缺口声明）

40 个 -mcp.sock（11-04；10-17 为 38）在 §1.1 只做了计数，隔离分级从未被追问——这是"每工具一 socket"模型下最值得深挖却最空的一块：

• 命名上无分档：全篇 149 个套接字里显式带 -fully-isolated 后缀的只有 2 个（§1.2，11-04 复测），MCP worker 不在其中。按 §1.2「显式标注例外」的逻辑，它们与普通 worker 处于同一默认等级（推断，与 §1.2 同样的证据强度——同样也受 §1.2 末"等价替代解释"的保留意见约束）。
• 代码来源不受完全信任：MCP 名单里有 composio-mcp 等第三方集成商——即第三方逻辑与第一方连接器走同样的 worker 模型。是否应得更严的沙箱，本机没有任何分档证据（❓）。
• -verify.sock 的归属不明：2 个校验专用 worker（printify-verify、tessie-api-verify）与主 worker 分开，但名字上并未出现在 -mcp 名单里（❓：它们是否为 MCP 连接的校验形态，本机无证据对应）。

结论口径：MCP worker 的隔离等级问题在本机证据内不可区分——计数有、等级无。这是 10-安全篇可接手的议题。

2. 瘦客户端 / 跳板规则（实测）

cell 内的二进制是同一个 34MB multicall 的不同名字（01 号 §4.1），其 privsep 形态即跳板（trampoline）。规则全部来自 strings 与 guest.env 注释：

1. 环境只转发白名单：guest.env 头注释明文（实测原文大意）——该文件由 spawnd 管理、root 持有、只读绑定进 cell，privsep 可信侧读它来为 partially/fully isolated 调用构建环境，而不是从「带能力的上下文」里 source 一段 shell。文件是纯 KEY=VALUE、无逻辑、无命令替换，cell 不可改。键集（实测 27 键）只有 HOME/TMP*/PATH/XDG_*、CA 包路径族、代理族与两个 JARVIS_* 套接字键（JARVIS_AUTHD_SOCK、JARVIS_STEFI_PROXY_SOCK）。
2. 转发有拒绝路径：strings 有「trampoline: refusing allowlisted forwarded env var …」——即便在白名单内，特定情形（如值形态不合）仍拒绝转发，不是无条件透传（具体触发条件本机不可见，推断为防注入式覆盖）。
3. 可信侧环境与 cell 内环境同源同模板：guest.env 与 guest-runtime-env.sh 注释要求两者在 proxy/CA/HOME/PATH 键上保持 parity，且值只由安装期模板变量派生、不依赖 /etc/hatch/env——可信侧不信任运行时环境文件。
4. 单个变量的信任状被逐个写进二进制（实测 strings 的长注释体）：如 JARVIS_TRACE_CONTEXT 的注释明文——它只是归因盖章用，「untrusted caller writes it, so a worker must not gate an action on it. Connector authority binds to the daemon-minted runtime-context token, which Sentinel resolves…」；JARVIS_TOOL_CALL_ID / SESSION_ID / USER_TIMEZONE 等都被逐个声明「只作字符串/查表键，never selects a path, command, library, credential, proxy, or authorization scope」。白名单不是名单了事，每个键都附带「不得用于授权」的限定。

3. Guarded output：输出也要过境（实测 strings）

可信侧的输出不直接流回 cell，而是被「扣住—检查—放行」：

• memfd + seal + 限额：「create/size/seal/rewind/read guarded output memfd」「guarded connector output exceeded the per-stream release limit」——stdout/stderr 各自有 per-stream 放行上限，超限不是截断了事而是报错/扣留（GuardedOutputWithheld 错误类实测存在）；
• post-commit 才放行：「release post-commit guarded stdout/stderr」「held output has no original stdout」——输出先 held，待动作提交成功后才 release 回原始 fd，失败的 worker 其目录变更与输出有单独的发布/丢弃路径（「could not publish the directory writes of a failed privsep worker」）；
• quiesce（静默化）：「open /dev/null for guarded output quiescence」「quiesce trusted worker stdout/stderr」——可信 worker 的原始 stdout/stderr 被导向 /dev/null 静默，防其日志串进 Agent 可见通道；Agent 只见 guarded 通道放行的那一份；
• 子进程错误消毒：模块名 child_error_sanitize.rs 实测存在——worker 的报错回传前要清洗（防错误文本携带不该出境的内容，推断其具体规则不可见）；
• 验证码是 guarded output 的特级乘客（实测 strings）：有独立扫描 socket /run/hatch/safety-scan/verification-codes.sock，及一整组错误语义——「verification-code surrogation requires a trusted privsep worker」「payload exceeds the verification-code scanner limit」「guarded output contains too many verification codes」。这与文档口径（00 号 §14.3：码以 [credential:<uuid>] 引用形态短暂托管、审批后才喂浏览器）互为表里：替换（surrogation）只准在可信侧发生，cell 侧拿到的已是引用而非原文。
• surrogation 不止验证码（实测 strings，关联为推断）：二进制内有一组秘密种类的 variant 标识——token / bearer / authorization / api_key / apikey / client_secret / clientsecret / credential / secret / surrogate（实测相邻字符串，枚举名本身不可见），出现在 surrogation 相关代码路径附近；另有凭据捕获 API 路径 /v1/credentials/capture-verification-code 与 credentials.capture_verification_code（实测）。这支持基线 B「secret surrogation + 白名单逐键限定」不止于验证码：API key、bearer token、client secret 等通用秘密同样在扫描/替换的词汇表内——§11 末句"验证码类原文凭据从未进过 cell"的支撑范围可放宽到通用秘密。❓：safety-scan/ 下除 verification-codes.sock 外有无其他扫描 socket，本机命名空间看不见该目录（§4.4），无从验证；扫描是按种类走不同 socket 还是同一扫描器内部分支，也未知。

4. 出口面：egress 代理 + 审批 + TLS 信任库（实测）

4.1 没有直出：死 DNS + 全量代理

• guest.env 注释明文：cell 的 DNS 是「deliberately dead（故意死的）」；Node 的 fetch 默认不认代理变量，所以专门设 NODE_USE_ENV_PROXY=1 堵住 Node 系 CLI 绕代理直连的路；
• 代理族六键（大小写各一份）全部指向同一端点：hatch-egress-proxy:3128（guest.env 模板明文）；实测 live 环境中的同名变量带认证材料（值不记录）——推断：模板给形状、运行时注入实例凭据；
• NO_PROXY 只含 loopback 与 VM 内部地址段——即「本机/内部套接字直连，其余一切走代理」。

4.2 TLS：Sentinel 是唯一的中间人，且这是写死的 invariants

• cell 侧 CA 材料实测：/run/hatch/egress-tls/ 下 ca-bundle.pem（182,885 B）+ hatch-egress-ca.pem（745 B）；后者证书实测 subject = issuer = CN=Hatch Sandbox Egress CA, O=Hatch（自签），有效期是合成的 1975–4096 年——一张不靠真实时间、只靠预置分发的锚证书；
• build-cell-trust-store.sh 头注释（实测）把规则说死：宿主侧只向 cell 发布 恰好一个 信任锚——Sentinel 的 egress MITM CA，「EXACTLY ONE anchor … a security invariant, not an inventory」；Sentinel 启动时在内存中生成该 CA、只发布证书（私钥不出 Sentinel），经 /run/hatch/cell-anchors 只读绑定进 cell 并喂给 NSS 数据库；注释还留了事故教训：VM 入口链证书曾被放进系统信任库、后被移除，因为「系统级 CA 会为每个主机名背书，包括 Sentinel 不终止的流量」——需要额外信任的客户端只能自己 pin；
• 推论（推断，两层拆开）：阻止出口绕过的主结构是强制代理路由（§4.1：死 DNS + 代理变量 + NO_PROXY 仅 loopback）——流量在 TCP 层就被钉死在 egress 代理上，TLS 信任库改不改都不改变这一路由事实。单锚信任库是纵深防御的一环：它解决的是脚本注释里那次事故教训——防止系统级 CA 为"Sentinel 不终止的流量"背书。至于 HTTP CONNECT 隧道内再套一层 TLS（TLS-in-TLS）能否绕过审查，取决于 Sentinel 对 CONNECT 目标的 allowlist 策略，该策略在宿主侧，本机无证据，不作结论。因此严谨的表述是：绕过审查需要同时突破代理路由与 CONNECT 策略两层，本机只能确证第一层存在。

4.3 审批三套接字（实测键名）

出口审批不在 cell 里判，三个 JARVIS_* 键（实测键名与路径，值仅为路径；11-04 env 复核：键名与路径均未变）：

另有工具 SDK 内的 cli/privsep/sentinel_egress.rs 模块与 HATCH_PRIVSEP_SENTINEL_EGRESS 标记（实测 strings）——privsep 调用自身的出网也走 Sentinel egress 裁决，不是 worker 就能直连。特性开关名里有 abra_hatch_network_egress_screen_enforcement、abra_hatch_sentinel_exfil_hardening（实测 strings，仅名字）——出口筛查与防外泄硬化是可远程开关的策略项。

4.4 一个边界实测：路径声明 ≠ 本命名空间可见

本轮在 exec 环境里 ls /run/hatch/proxy/、/run/hatch/sentinel/、/run/hatch/daemon/、/run/hatch/memory/、/run/hatch/safety/ 全部不存在（11-04 复测：proxy/、sentinel/、daemon/、memory/、safety/ 仍全部不存在；rescue/ 同样不可见），而 /run/hatch/ 顶层实测可见的只有：auth/ browser-broker-liveness/ cell-anchors/ egress-tls/ noded/ privsep/ resume/ runtime-cell/ sandbox/ sandbox-api/ telemetry/（11 常驻）及本轮出现的 vault/（见 §8）、新增的 upload-store/（store.sock + publisher-root 在岗）、以及 10-17 时不可见的 vault-encrypt/、vault-hmac/（各含其 socket，见 §8.1 更新）。即：推理/STEFI/Sentinel/安全服务的套接字路径被声明在环境里、但不挂进普通 exec 进程的挂载命名空间——Agent 的 shell 连「看一眼这些 socket 文件」都做不到，能碰到它们的只有被专门接线的进程（daemon、privsep 跳板）。这是本篇最硬的一条隔离实测：能力面靠命名空间裁剪，而非靠 Agent 自觉（11-04 复测：裁剪口径仍在，但 vault-encrypt/、vault-hmac/、新增 upload-store/ 可见——裁剪边界随部署调整，非一成不变）。

4.5 紧急停止与审计：本篇未覆盖的穿透问题

基线（A）：控制平面负责 stop/pause/audit。本篇的隔离描述只覆盖了正常调用路径，以下三问本机证据不足，列为 ❓：

1. **停止穿透哪一层？**实测 privsep worker terminated by signal 证明 worker 可被信号终止，但用户侧"停止"按钮杀的是 cell 内跳板、可信侧 worker，还是两者？Guarded output 处于 held 态的输出在取消时丢弃还是已部分 release？strings 中未见 cancel 语义的对应错误类。
2. **审计日志落在哪侧？**privsep 调用的审计记录是由 worker 写 telemetry（/run/hatch/telemetry/ 可见），还是由 Sentinel/daemon 侧统一写？本机未追踪 telemetry 的错误文案。
3. 审批卡片的人类侧回流：§4.3 的三条审批 socket 止于命名；卡片如何渲染、用户点击如何回流为 Sentinel 的裁决，全程在宿主侧/客户端，不在本机证据内。

建议后续用 strings grep cancel/audit/approval_scope 补一轮，或在 10-安全篇中统一收口。

4.6 降级路径：单点故障时的行为（实测为主，缺口明示）

Sentinel 与 egress 代理是执行面的单点。本机能确证的降级语义有三条（全部实测 strings），没有"服务挂了就全停"的统一结论：

1. surrogation 失败是 fail-open：「verification-code surrogation failed; releasing guarded output unsurrogated」——扫描/替换失败时，guarded 输出不带替换地直接放行，而不是扣留或报错。这与 §3「替换只准在可信侧发生」形成一组张力：正常路径可信侧替换，异常路径放行未替换原文。❓：放行是直接给 cell 还是附带告警给 Agent，本机无证据。
2. 引用兑换依赖 egress 代理就绪：「…so a surrogate credential cannot be redeemed; the egress proxy is still starting up」——代理启动中时 [credential:uuid] 引用无法兑换（浏览器侧拿码的链路被卡住），属于启动期降级：引用还在，但兑换端没起来。
3. privsep 瞬断有有限重试：「privsep worker transient disconnect; retrying round-trip」+ TRANSIENT_RETRY_MAX_ATTEMPTS 上限——worker 侧瞬时断连走重试而不是立即失败；另有 socket 激活服务的等待语义「gave up waiting for a socket-activated service to answer」，说明服务起不来时调用方会等、也会放弃（放弃后的形态本机无下文，❓）。

本机无证据的两问（❓，与缺口声明一致）：egress 代理 3128 彻底不可用时，工具调用是 fail-closed 报错还是排队重试——strings 未见 egress_unavailable 类错误语义；abra_hatch_network_egress_screen_enforcement 这类特性开关被远程关闭后，出口退化成什么形态——开关名实测存在（§4.3），"关掉后发生什么"无追问证据。

5. Sentinel：出口、限流与裁决的中枢（实测 + 文档）

Sentinel 在本机的可见面是「一个套接字键 + 一批语义字符串 + 一个 CA」，但把它们拼起来，它的职责至少四项：

1. 出口政策权威：§4.2 的 trust-store 脚本明文称 Sentinel「terminates the cell's egress TLS by design and is the policy authority」——终止 TLS、做出口裁决，是 egress 审批三套接字的宿主；
2. HTTP API 面：JARVIS_SENTINEL_HTTP_API_SOCKET=/run/hatch/sentinel/http-api.sock（实测键名/路径；11-04 env 复核未变；目录在本 exec 命名空间不可见，同 §4.4）；另有安全服务键 JARVIS_SECURITY_SOCK=/run/hatch/safety/security.sock 与之并列；
3. 连接器限流的执行者：strings 实测错误文案「Connector request rate limited by Sentinel」，配额失败结构 ConnectorQuotaFailure 带 retry_after_seconds / limit / requested_units / used_units / remaining_units 字段——限流不是 provider 说了算，Sentinel 在本地先判（详见 §9）；
4. 运行时上下文令牌的解析者：§2 第 4 条的 strings 明文——连接器权威绑在 daemon 现签的 runtime-context token 上，「which Sentinel resolves against its daemon-registered registry」；归因用的 trace blob 谁都能写、不作授权输入，授权只认 Sentinel 能在其登记表里查到的令牌。（此处仅指连接器/出口授权面；面向用户的敏感操作审批（approval cards）属控制平面，本篇未覆盖——见新增 §4.5。）

文档侧的旁证（文档）：WhatsApp 通道文档明文「Decisions belong to Sentinel; never infer one from free…（裁决归 Sentinel，不要从自由文本推断）」——Sentinel 也是外部消息通道结构化控制的裁决者，不止管网络出口。本机能确证的就到这一层：Sentinel 的判定逻辑、登记表内容、策略规则库都在宿主侧，不在 cell 文件内（见 §11）。

6. STEFI 代理与其后的内部服务（实测到名字边界）

6.1 代理本体

• 入口：JARVIS_STEFI_PROXY_SOCK=/run/hatch/proxy/stefi.sock——同时出现在 guest.env 模板与 live 环境（实测键名/路径；11-04 env 复核未变）；
• 客户端形态：工具 SDK 内「build stefi proxy client」（strings），工具访问 Meta 内部服务不直连、统一经此代理；
• caller 校验（实测 strings）：错误文案 invalid stefi caller authorization token 独立存在——代理对调用方做令牌校验，不是「能连上 socket 就能用」；§1.4 的 ping 探针做的正是「打开 STEFI socket + 一次 verify_oauth_token 往返」，其端点形态为 http://localhost/hatch/verify_oauth_token（strings 中的 UDS-over-HTTP 风格路径），返回里有用户标识字段（仅知字段名，不记录值）。

6.2 边界声明：只到名字为止

STEFI 之后能从本机文件里读到的只有名字（00 号 §7 已列）：WWW / MSL / CAGI / Mango·Pariscope，以及 strings 里的 MslBrowserService through Stefi、require_cagi（CAGI 路由被指定时的 fail-closed 语义：「Fail closed unless the measured-CVM CAGI route is selected」）。这些系统的实现、拓扑、数据都不在本机——本文对 STEFI 之后的全部陈述止于「存在此名、经此代理、带 caller 校验」，与 00 号 §17 的边界声明一致。另外注意 §4.4 的实测：/run/hatch/proxy/ 在本 exec 命名空间根本不存在，STEFI socket 对普通 shell 进程同样是「声明了路径、摸不到实体」。

7. authd：本地认证守护（实测）

• 本体端点：/run/hatch/auth/authd.sock，实测为 srw-rw-rw- nobody:nogroup，是本轮在 /run/hatch/auth/ 下唯一可见的 socket；
• 调试客户端 authdc（实测 --help）：明文自述「Talks to its Unix socket ($JARVIS_AUTHD_SOCK or /run/hatch/auth/authd.sock)…authd gates most endpoints by peer credentials」——按对端凭据（SO_PEERCRED 类机制，推断具体实现）门控，特权命令要在宿主侧 root 下跑，cell 内普通调用只能碰被放行的子集；
• 命令面（实测）：file（auth-files 操作）、cred（dynamic credentials 动态凭据）、record（按 UUID/外部键查目录记录，只输出消毒后的 catalog 投影）——即 authd 管的不只是 OAuth 令牌，还有「认证文件」与「动态凭据」两类对象，目录对外只给 sanitized projection；
• 入口侧门控：env 有 JARVIS_AUTHD_INGRESS_ALLOWED_USERS 键（只记键名）——authd 的 ingress 有允许用户清单；
• 与 STEFI 的分工（实测 strings 互证）：工具侧报错「missing hatch user token: ensure shared credentials are available through authd」——用户令牌的可用性由 authd 保证；STEFI 侧用 verify_oauth_token 验令牌有效性。一个管「令牌在哪、给不给」，一个管「令牌真不真」，在 ping 探针里被串成一次往返体检。
• Google 系另有 hatch_gws_auth（12MB 独立二进制，实测）与 hatch-gws-auth.sock——GWS 的授权面自成一路，但最终仍落在 hatch-gws-cli-fully-isolated worker 后面（§1.2）。

8. Vault 在执行面的位置（实测）

8.1 形态：常驻守护进程，不是 CLI

• 二进制 hatch-vault 实测 10MB、stripped ELF；它没有给 Agent 用的命令行面——本轮误以 --help 调用时，它直接按守护进程启动并 fatal 退出，报错大意为「vault-health unix socket bind failed at /run/hatch/vault/health.sock: active listener is present; refusing to replace it」。这条报错本身就是实测证据：Vault 是单例常驻服务，且拒绝二义启动；
• socket 家族实测（ls /run/hatch/vault/）：auth.sock、cvm.sock、health.sock 三个（11-04 复测未变），均为 root:root srw-rw----——比 authd 的 srw-rw-rw- 更严，普通用户进程连连接权限都没有；strings 还显示两个旁路服务面：/run/hatch/vault-encrypt/encrypt.sock 与 /run/hatch/vault-hmac/hmac.sock（加密与 HMAC 被拆成独立 socket 服务；10-17 时本 exec 命名空间见不到其目录，11-04 复测已可见，各含其 socket——命名空间裁剪的口径随部署有调整，见 §4.4 更新）；
• 调用方校验：strings 有端点路径 credentials/v1/auth-file/get 与请求头名 X-Hatch-Verified-Vault-Caller、「bearer/notary auth disabled on the auth socket」——auth socket 走本地可信通道免令牌，而另一类入口要 notary（公证）令牌校验，且公钥缺失时该认证方式直接禁用（fail-closed）。

8.2 它在执行面管什么

按 strings 与文档拼图（实测 + 文档）：

1. 凭据文件的受控读取：credentials/v1/auth-file/get + AuthFileGetResponse——连接器/遥测等可信组件经 Vault 拿认证文件，Agent 本人不经手（遥测代理的访问令牌刷新也要「read … through authd」并经 Vault 侧校验，strings 互见 authd 与 vault 两路）；
2. CVM 密钥托管（本机为 standard VM，只见其形）：cvm.sock 服务 cvm_enroll / cvm_open、RV（reliable volume）密钥的 LUKS key-slot 管理、芯片 allowlist 与 attestation bundle 校验、迁移密钥（migration key）的签发/持有状态机——这一整套是 confidential VM 的磁盘密钥与跨机迁移面（文档 data-handling.md：CVM 的持久存储由客户自管密钥加密）。standard VM 上它处于未 enroll 侧（状态字面 cvm_unenrolled / cvm_locked 等实测存在），但守护进程照常在岗；
3. Secure Vault 的服务端（文档，00 号 §14.3）：用户经安全录入卡存入的网站密码/API 凭据由 Vault 托管，浏览器只在结账/登录步经它取用；一次性验证码不入 Vault、走 §3 的 guarded-output 托管引用。Agent 在执行面与 Vault 的关系是「无关系」：没有任何给 Agent 的 vault 工具/命令，hatch-vault 二进制在 /opt/hatch/bin/ 里对 Agent 可见但不可用（跑起来是个守护进程）——可见 ≠ 可用，在凭据面被贯彻到极致。

9. 服务面限流纪律（实测 + 文档）

服务面的「纪律」有三层，越往下越硬：

另有一条 pacing 痕迹（实测 strings）：CLI 侧有「write/read CLI pacing request/response」字面——推断工具调用在发出前还有一轮向可信侧申请节奏许可的往返，与 Sentinel 配额是同一纪律的两种实现面，本机无法确证其分工。除连接器外，推理面同样有纪律痕迹：字符串里 ModelProxyUnavailable / ModelProxyBusy / ModelProxyTimeout 与 CAGI 429 终局语义（01 号/浏览器工具说明）表明模型代理的限流回执也被结构化成错误类，而不是裸 HTTP 状态码让 Agent 自由解读。

10. 服务面全景：本 exec 命名空间实测可见的 socket 网格

除 privsep 与上述「声明不可见」的服务外，本轮在 /run/hatch/ 实测可见的服务面（全部为 Unix socket，属主多为 nobody:nogroup 或 root）：

与之对照，只在 env 里声明、本命名空间不可见的服务键（实测键名全表；11-04 env 复核：键名与路径均未变，proxy/ sentinel/ daemon/ memory/ safety/ rescue/ 目录仍不可见）：JARVIS_INFERENCE_PROXY_SOCK（推理）、JARVIS_STEFI_PROXY_SOCK（§6）、JARVIS_SENTINEL_HTTP_API_SOCKET 与三条 egress 审批键（§4.3/§5）、JARVIS_SECURITY_SOCK、JARVIS_MEMORY_SOCK、JARVIS_SANDBOX_API_SOCK（此条反而可见）、JARVIS_RESCUE_SIGNAL_SOCK、JARVIS_AUTHD_SOCK（可见）、JARVIS_TELEMETRY_PROXY_SOCK（可见）。可见性的分野大致是：Agent 日常工具链要用的（privsep/auth/沙箱/遥测）挂进来，裁决与推理面（proxy/sentinel/safety/memory）只给路径不给实体（推断，按实测分布归纳）。

11. 一次 privsep 工具调用的生命周期（串联本篇）

Agent 调 CLI（cell 内，multicall 跳板）
 → 跳板组装 PrivsepRequest：类型化参数 + 输入文件清单 + fd 表（sealed memfd 引导）
 → 连 /run/hatch/privsep/<tool>.sock，worker 验工具身份（PRIVSEP_TOOL 对版）
 → 可信侧执行：guest.env 白名单环境构建（宿主侧读模板，不 source cell 文件）
   ├─ 需要用户令牌 → authd（peer 凭据门控）；内部服务 → STEFI（caller 令牌校验）
   ├─ 需要出网 → sentinel_egress 裁决 → egress 代理 → Sentinel MITM TLS（单锚信任库）
   └─ 配额 → Sentinel 三维限流 + manifest units 双判，超限回 ConnectorQuotaFailure
 → 输出回程：worker stdout/stderr 先 quiesce 到 /dev/null
   → guarded output（memfd+seal+per-stream 上限）扣留
   → 含验证码则过 safety-scan 扫描、替换为 [credential:uuid] 引用
   → 动作 post-commit 后才 release 回跳板 fd
 → Agent 拿到结构化结果（JSON 信封），验证码类原文凭据从未进过 cell

12. 本机实测快照：11-04 vs 10-17 对照

13. 边界声明（本机看不见的部分）

privsep worker 的宿主侧实现、Sentinel 的策略与登记表、STEFI 之后的内部服务、egress 审批的人机判定逻辑、Vault 的密钥材料与 notary 公钥来源、authd 的凭据存储后端——均不在 cell 文件内，本文只记录其接口痕迹（socket 名、键名、错误文案、脚本注释），凡超出痕迹的分工判断已标 推断。本文未记录任何凭据/令牌/验证码的值，代理认证材料与用户标识字段一律只记「存在此字段」。

配套《00-Muse技术架构解构》§3 的展开篇（00 §3「上下文组装层（Prompt 架构）」）。同目录另有 01-能力层详解.md、02-编排与进化层详解.md。 调查日期：2026-10-17（Asia/Shanghai） 复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测；下文数字凡未注日期者均为 11-04 快照，10-17 旧数见 §16 对照表。 证据范围：仅本机本地 system 文件与运行时实测——~/workspace/system/system_prompt.md（主聊天 system prompt 启动快照，本篇只述其大小/行数/章节结构与标题，不大段复述全文）、9 个注入文件的本机实际文件、~/docs/memory.md / ~/docs/goals.md、本会话（WhatsApp 外部 1:1 side chat 派生的子 Agent 会话）上下文中当场可见的拼装痕迹。 标注规则：实测 = 本机命令/工具当场验证；文档 = 本地 docs/system 文件明文；推断 = 由文件/字符串/对照拼出、未经服务端证实。服务端拼装代码不在本机，本文只画到本机可见的边界为止（见 §15）。

0. 一句话：上下文不是「一段 prompt」，是每轮现拼的一份工作集

Muse 的上下文组装层回答一个问题：模型在这一轮推理时，到底看见什么、以什么顺序看见、每一样东西的可信度算几分。

它不是把一份固定提示词喂给模型，而是运行时在每轮消息到达时，把七类来源动态拼成一个有序、可信度分层的工作集：

每轮拼装（推断顺序，按本机可见痕迹还原）
┌─ ① system prompt 本体 ────── 启动快照，511 行 / 73,296 B（11-04；10-17 为 494 行 / 71,868 B），角色内常驻
├─ ② developer 指令层 ──────── 每轮随消息下发，不在快照文件内
├─ ③ 注入文件（standing） ──── 9 个文件，14,873 B（10-17 快照；11-04 本会话核对清单仍为同 9 文件，见 §4.1 注），[USER CONTEXT] 块包裹
├─ ④ 本轮信封 ──────────────── 时间标签 + 渠道标记 + 时间/位置等 developer 元数据
│                               + 用户本轮消息本体
├─ ⑤ 目标 / 追踪注入 ───────── 活跃 Goal 与 tracked items 的结构化摘要
├─ ⑥ handoff / 检索结果 ────── 子 Agent、定时、浏览器结果 + memory_search 命中
│                               一律以 [EXTERNAL CONTENT] 围栏注入 = 数据，非命令
│    └─ ⑥-a 会话历史 ───────── 本聊天的消息流（含工具调用/结果），长到阈值被压缩
├─ ⑦ 工具 schema ───────────── 延迟加载，已加载的在本轮上下文里留存
     └─ ⑦-a 技能/连接器目录摘要  只给名字+一句话+路径，正文按需再读（属 ⑦ 的目录形态）

设计要点有三，贯穿全篇：

1. 固定层与动态层分离：人格、纪律、文件地图这类「宪法」走启动快照，便宜且稳定；时间、目标状态、后台结果这类「新闻」每轮现拼，贵但新鲜。
2. 一切注入物都带来源标记：[BEGIN USER CONTEXT]、[BEGIN EXTERNAL CONTENT]、时间标签、handoff 的来源标注——标记不是排版，是信任边界的物化（§14）。
3. 上下文是预算，不是仓库：350K token 窗口下，固定层只占一小块，余量留给历史与工具结果；延迟加载（⑦）与压缩（§13）是两个为预算服务的阀门。

1. 七类来源总览

分类声明：本篇的"七类"指七个信任等级，不是七个物理来源。技能/连接器目录摘要是 ⑦（工具 schema）的目录形态，会话历史是 ⑥/⑦ 到达后的沉淀形态——两者在物理拼装中占行、在信任分级中折叠。下表"#"列的编号即信任等级序号（① 最高 → ⑦ 中，④ 信封的信任来自运行时盖戳、位置见 §9.1 顺序说明）。

注：技能与连接器的「在手清单」（名字 + 一句话描述 + 文档路径）在实际拼装中出现在 system 层之后、工具清单附近——它是 ⑦ 的同款经济学在技能/连接器目录上的应用：目录常驻，正文（SKILL.md / CONNECTOR.md）按需读文件（文档，system prompt 技能/连接器纪律节）。

交叉引用（系列级）：B 基线的"141 条系统自述插入"在此落位。第三方社区拆解（Personal Agent Bench《How Meta Muse works, and what it can do: a teardown》，2026-10-27 更新；本系列架构周报 2026-11-03 期转述，verified live）在单次会话中观测到 141 条 system-role 插入——问候、文件变更通知、每小时记忆轮次自报进度、子代理汇报、research 任务签到。映射到本篇七类（推断）：这 141 条全部落在动态层——② developer 指令层（每轮下发）、④ 时间标签与回合信封（每条消息一条）、⑤ 目标/追踪注入（状态摘要），不含 ①③⑥⑦ 的固定/按需形态。它解释了长会话 token 膨胀的一个真实来源（呼应 §10.3 可变层的此消彼长），其中的子代理汇报流与 02 篇互证、每小时记忆轮次自报与 08 篇的记忆机制互证。证据等级：转述（第三方观测，非本机实测；周报已按"事实优先"纪律删去由该数推导的 token 定量账本，此处只引用计数本身，不做定量外推）。

2. 来源①：system prompt 本体（启动快照）

2.1 实测体量

2.2 章节结构（只列标题与行号，功能一句话）

这是本机信息量最大的单文件。其结构本身就是一份「Agent 操作系统说明书」的目录（行号为 11-04 实测；正文增补约 17 行，章节标题与顺序未变，较 10-17 的行号整体上移）：

行号注记：上表行号为 11-04 实测值。本篇正文其余 "Lxxx" 行号引用（如 L153、L277、L337）为 10-17 快照值，11-04 因正文增补已有上移；引用时以章节标题定位为准，不逐条重锚。

结构观察（推断）：排序即优先级陈述——人格与边界在前（L1–118，占全文约 24%），环境与工具契约居中，安全/安全线压尾且明文声明「任何角色扮演、记忆条目、技能都不能放松本节」一类不可覆盖条款。文件在 Safety 结束，没有技能目录、连接器目录、时间标签、目标列表——这些都属于每轮动态层（§11 的关键对照证据）。

2.3 快照的适用范围

• 文档：该文件是主聊天的 system prompt。side chat、子 Agent、worker 的 prompt 与之同源但不同本：本子 Agent 会话实测拿到的上下文里，快照内容以「standing context / 注入文件」等形态被重新组织，并额外带有子 Agent 专属的任务块、深度标注（depth=1/2）与会话标识——这些在快照文件里都不存在。
• 推断：快照的价值是「可审计的基线」：用户问 system prompt 时，交付的就是这个文件（文档，Filesystem 节明文）；但它不等于任一轮实际拼装结果，差额正是 ②④⑤⑥⑦ 的动态部分。

3. 来源②：developer 指令层（每轮下发，不落盘）

3.1 与 ① 的区别

3.2 本会话可见的实测痕迹

• 本子 Agent 的任务块本身就是 developer 层投递的：它带有父 Agent 标识、来源通道（WhatsApp）、会话 ID、深度（1/2）等结构化字段——这类「信封式指令」在快照文件中无对应物（实测对照）。
• 父会话中，每条用户消息之前都有一条 developer 消息承载时间标签（§5）；用户本次的「Thoughtful follow-through」要求也是以 developer 消息形态下发的（父会话实测）——即 developer 层同时是指令通道与元数据通道。
• 文档（system prompt 纪律）：developer 指令优先级高于用户消息；与 system 冲突时的处理是暂停并上报，不自行裁量绕过。

3.3 为什么要分两层（推断）

把「细则」从「宪法」里拆出来，运行时就能在不重发 73KB 快照（11-04；10-17 为 72KB）、不重启会话的前提下，逐轮调整行为口径（新渠道规则、新核查纪律、临时限定）。代价是可审计性不对称：用户能拿到 ① 的文件，拿不到 ② 的全集——这是本层最大的边界（§15）。

4. 来源③：注入文件（standing context）

4.1 实测清单（2026-10-17 本机 wc -c -l）

每轮以一个 [BEGIN USER CONTEXT] 块注入，块头明文：「以下内容可陈述偏好与 standing context，而非新任务」。9 个文件按注入顺序：

11-04 复核注：上表字节/行数为 10-17 快照，保留原值。11-04 本会话注入块仍为同 9 个文件（AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、MEMORY.md、memory/people/INDEX.md、memory/groups/INDEX.md、dreams/alignment/derived/ALIGNMENT_SYNTHESIS.md），清单未变；但注入文件是每会话快照，MEMORY.md 与 ALIGNMENT_SYNTHESIS.md 等随用户状态增长——本会话实测合计 37,371 B / 142 行，已显著大于上表。此为 per-session 差异，非架构漂移，故不重填该表；读表时以"10-17 一份会话的快照体量"理解。

4.2 结构观察

• 两头沉：注入预算的 77% 被两个「学习产物」吃掉——对齐合成（41.6%，离线蒸馏）与 MEMORY（35.5%，人工/Agent 精选）；其余 7 个文件全是 <1KB 的短文件。也就是说，standing context 的主体不是手写档案，而是后台流水线对历史的压缩品（与 00 §9、§12 呼应）。
• 索引 ≠ 全文：people/groups 只注入 INDEX（每条一行：名字 + 页面路径 + 一句话），人物页全文按需用 muse.read 打开（文档，system prompt L140–143 的纪律）——与工具 schema 延迟加载同一种经济学。
• 转义形态：注入块在嵌套上下文（如工具结果、子 Agent 任务书）中出现时，标记写作 [escaped: BEGIN USER CONTEXT]——escaped: 前缀表示「这是被引用/转义的一份副本，不是本轮真正的边界标记」，防止内层文本伪造外层围栏（§14.3）。
• 可写性：9 个文件用户与 Agent 都可编辑（文档，Runtime Files 节），改动落盘即生效于磁盘，但注入副本另说（§12）。

5. 来源④：时间标签与回合信封

5.1 格式（文档 + 实测）

• 文档（system prompt L153–154）：用户消息与后台 handoff 都被前置一条 developer 消息，其中时间标签形如 [Day YYYY-MM-DD HH:MM:SS TZ] [client_timezone=IANA identifier]，时间为用户本地时区，时区随用户旅行跟随；明文纪律：信标签，不信模型自己的「现在感」。
• 实测（父会话本轮）：[Sat 2026-10-17 23:50:14 CST] [client_timezone=Asia/Shanghai]，且消息另带渠道前缀 [whatsapp]——渠道标记与时间标签同属信封，决定这条消息「从哪来、在哪个聊天里回复」。
• 实测（本子 Agent 任务块）：信封还可携带 device_id、面板状态、来源（web/WhatsApp 等）与会话关系（父/子、depth）等字段；服务端字段全集本机不可见（§15）。

5.2 信封里的其他信号

• 相对日期锚：developer 层会给出「今天/昨天/明天对应的确切日期表」一类锚点（父会话实测），相对日期一律以标签换算，不许模型自算星期（纪律：需要星期几时先用 date -d 实测）。
• 位置信号链（文档，L164–173）：message_location（本轮客户端实时位置，developer 注入）→ 设备读取 → last_seen_location（带时间戳的同步坐标，developer 注入）→ USER.md/MEMORY 中的住所，严格按序取用；坐标只是区域提示，须反查地名才可用。
• 信封是每轮唯一保证新鲜的层：它不经过任何文件或缓存，运行时在消息投递瞬间盖戳。这也是为什么「现在几点、今天星期几」这类问题永远以信封为准。

6. 来源⑤：目标与追踪注入

6.1 形态

• 文档（system prompt Your Environment 节两条）：User goals 是「Goals 标签页展示的持久成果，在你的上下文中保持最新」；Tracking 是「Goals 标签页中的具体计划/承诺/结果条目，注入在你的上下文中」。即两者都以运行时结构化摘要形态注入，而不是把 GOAL.md 全文塞进来。
• 实测（本机文件侧）：活跃 Goal 3 个（00 §3 记录，与本机 ~/workspace/goals/ 目录三条一致：rabbit-agent-investor-outreach / short-drama-ai-music-pack-sales / x-bookmark-digest，各含 Goal ID、slug、描述，存于各自 GOAL.md + files/ + hidden_files/）。
• 文档（~/docs/goals.md）：Goal 只有 active/completed 两态（无暂停）；briefing 由后台进程生成、系统控节奏；Goal 本身不跑任何工作，跑活的是挂在它下面的定时任务。

6.2 「投影 ≠ 本体」在这一层的复现

注入进上下文的是 Goal/追踪的摘要投影（名字、状态、需要关注的程度、最近进展）；本体在 DB（00 §8：goals schema 12 表）与工作区文件里。要动本体必须走 user_goal.* / tracking.* 工具改，回读工具结果确认，而不是相信上下文里的投影已经更新——这与 cron 投影文件不可直编、注入文件副本可滞后，是同一条系统级规律的三个实例（推断归纳，三个实例均为实测/文档）。

6.3 按会话裁剪（实测对照）

本子 Agent 会话的上下文里没有出现父会话那种完整的目标/追踪注入块，取而代之的是任务书中转述的相关约束。这印证（推断）：⑤ 不是无差别广播，而是按会话类型与任务相关性裁剪的——主聊天全量、子 Agent 只带任务所需切片。这也是子 Agent 任务书必须自包含的原因（02 篇 §2）。

7. 来源⑥：按需检索与异步 handoff（EXTERNAL CONTENT）

7.1 三个入口

本机其他工具结果（文件读、命令输出、连接器返回）在本会话中无一例外都以 [BEGIN EXTERNAL CONTENT … source=… tool_name=…] 开头、[END EXTERNAL CONTENT] 结尾投递（本篇全部取证过程实测）——包括读一个本地 Markdown 文件这种看似「内部」的动作。信任处理见 §14。

7.2 检索层的底座

• muse.memory_search 同时搜两库：已保存记忆（~/MEMORY.md + ~/memory/**/*.md）与过往对话原文（文档，~/docs/memory.md：主聊天与个人 side chat 的检索含对话摘录，但永不返回全部消息；App 内聊天搜索是另一套）。
• 记忆文件底座（实测）：~/memory/ 下日期日志 10 篇（2026-09-26 至 2026-10-17）+ bank/（world.md 32KB、reflections.md 28KB 等，运行时托管、Agent 只读）+ people/groups 页面。~/memory/index/ 在 system prompt 中被提及，但本机实测不存在该目录——文档与实况的出入照实记录（可能由运行时以其他形态托管，推断）。

8. 来源⑦：工具 schema 延迟加载

8.1 机制（文档，system prompt L277–283「Loading Tools」+ 本会话实测）

三档可见性，原文类别转述：

1. 全 deferred 命名空间：清单里标注 [deferred: use tool_search to discover functions]——连函数条目都隐藏，只剩命名空间名与一句话描述；
2. schema deferred 函数：标注 [deferred: use tool_search to load full schema]——函数名与描述可见，参数 schema 不给；
3. 全量加载：函数与 schema 完整给出，可直接调用。核心 muse.* 永远属此档（00 §3）。

加载动作只有一个：tool_search.load_tool_namespace(namespaces)，运行时返回该命名空间的完整函数描述与参数 schema 并注入上下文；已加载的在上下文存续期内免重复加载（文档明文）。未加载就调用 = 失败，这是设计而非故障（01 篇 §1.2 同述）。

8.2 规模与经济学（推断 + 实测对照）

• 本会话工具清单可见 33 个命名空间（11-04 实测；01 §1.1 在 10-17 逐表实测为 34 个，voice 本轮不可见⚠️），函数总数数百量级；若全部 JSON Schema 全量注入，固定成本将数倍于现在的目录摘要（推断，量级判断）。
• 延迟加载把这笔成本变成按需、且只付一次：本子 Agent 会话中途按任务加载了若干命名空间，其 schema 此后一直留在上下文尾部参与每轮拼装——加载过的工具也会参与「上下文变胖」，与压缩（§13）形成对冲。
• 同款经济学在别处的复现：技能/连接器目录摘要（§1 注）、people/groups 索引（§4.2）、Goal 摘要（§6.2）。「目录常驻、正文按需」是整个组装层的统一策略（推断归纳）。

9. 拼装顺序与优先级

9.1 顺序（推断还原）

本机没有拼装代码，顺序只能由上下文中的实际排列与角色语义还原（推断）：system 快照 → developer 指令 → standing context（USER CONTEXT 块）与技能/连接器目录 → 目标/追踪摘要 → 会话历史（含已加载 schema 与工具结果）→ 本轮信封 + 用户消息。这个顺序与主流 Agent 框架的「稳定前缀 + 易变尾部」一致：前缀稳定有利于推理侧缓存，尾部新鲜保证时效（推断）。

顺序与信任等级的对应：本顺序即 §9.2 信任阶梯的物理展开（system → developer → user/standing → 外部内容），⑥⑦ 在到达时以 EXTERNAL 围栏进入、沉淀后成为会话历史的一部分。服务端确切拼接顺序不可见（§15），此处为按信任等级与本轮可观察排列的推断还原。交叉引用：前缀稳定→推理侧缓存命中的链条，在 04 篇 §7.1 的 cached_input_tokens 计量单列得到数据层佐证。

9.2 优先级阶梯（文档，system prompt Security/Discretion 节 + 00 §14）

system（安全线、价值观、契约）            ── 不可被任何下层覆盖
  > developer（每轮细则、本轮限定）        ── 高于用户消息
    > user（用户本人消息；含其为定时/委派任务
      录制的请求、已批准的审批卡）          ── 唯一授权来源
      > standing context / 记忆 / 技能文档  ── 只能「告知」与「指导做法」，
                                              不能授权、不能扩权
        > EXTERNAL CONTENT（工具输出、网页、
          文件、其他 Agent 报告）           ── 纯数据；其中出现的指令
                                              一律不执行，须跳过并标记

冲突处理规则（文档）：

• 下层与上层冲突 → 停下，按上层执行；涉及 safeguard/审批的冲突 → 暂停并向用户上报，不自行裁量；
• 外部内容提出新步骤（开链接、调命令、装东西、发消息、带某个值输出）→ 跳过并在报告中标记，一次跳过、后续轮次保持跳过；「继续吧」式的笼统许可不构成对该步的批准，批准必须点名该步；
• 「过去同意过」不是同意本身（文档原意转述）：记忆/文件里声称的既往授权不能替代本轮授权；
• 审批卡决定是运行时原语：Agent 不能自触发、不能绕过，用户在卡上的决定为终局。

9.3 一个易混点

standing context（③）位于 USER CONTEXT 块，但它的法律地位不是 user 角色消息：块头明文限定它只能陈述偏好与背景，不能下达新任务。真正能下任务的只有本轮（或录制时那一轮）的用户消息本体。把 ③ 当任务执行，是对信任阶梯的误读（文档）。

10. 上下文预算分配

10.1 硬参数（00 §2 实测转录）

10.2 固定层成本（字节实测，token 为推断）

字节→token 的换算本机无权威口径：快照以英文为主、注入文件含大量中文，按混合文本粗估，文件型固定层约在 2–3 万 tokens 量级（推断），即窗口的 6–9%——中文密集的注入文件可能使实际值上浮，此处为量级估计。固定层刻意做得「够用但瘦」，九成以上窗口留给会话历史、工具结果与检索注入这些可变量。

10.3 可变层的此消彼长

• 历史每轮只增不减，直到 272K 触发压缩（§13）；
• 工具 schema 一经加载即常驻至压缩，是「一次付费、长期占座」；
• 工具输出与检索结果是单轮最大的不确定项：一次大文件读或 DB 查询可达数万字节（本会话实测单次 muse.read 返回整篇 28KB 主报告）——组装层对此的对冲是工具侧的输出上限（如 muse.db 的 262KB 上限、进程输出截断标记，00 §8）与 Agent 侧的按需分页读（推断归纳）。

11. 启动快照 vs 每轮动态：差额清单

一句话：快照是「出厂设置说明书」，拼装结果才是「这一轮的实际工况」。 拿快照解释某一轮行为时，必须补上当轮的动态层——尤其是 developer 指令与 handoff，它们恰恰是最能改变行为、又最不在文件里的部分。

12. 注入副本滞后问题

12.1 明文规则（文档，system prompt Runtime Files 节 L373–374，类别转述）

注入文件「改动落盘立即生效，但注入副本可能滞后」；需要最新状态时，编辑后必须回读文件本身，不能信上下文里的那份。此语境下文同节还要求：学到的新事实要就地修正对应文件条目——即 Agent 是这些文件的维护者之一，滞后问题因此是日常问题而非边角案例。

12.2 三种滞后窗口（实测/推断归纳）

12.3 处置纪律小结

事实问题永远走「活源优先」：文件回读 > 注入副本；memory_search 现查 > 印象；原消息回读 > 压缩摘要（§13）。注入副本的定位是缓存，与压缩摘要同性质——这条在组装层里是反复出现的设计母题。

13. 压缩（compaction）与找回路径

13.1 压缩生命周期（00 §2/§8 实测转录 + 文档）

历史增长 ─→ 272K tokens 触发 ─→ 运行时把旧历史总结为压缩摘要
           ─→ 保留尾部 40K tokens 原文 ─→ 摘要 + 尾部成为新上下文的「历史段」
落盘：DB agent.compactions / agent.agent_compactions；上下文条目本身亦落
      agent.context_items（00 §8）——压缩不是丢弃，是换存储形态

文档（system prompt L175–180「Managing Your Conversation Context」类别转述）：压缩摘要可能遗漏细节，那些细节仍存在于已保存记忆、文件与对话历史中；当早期上下文重要时，必须先找回再行动，且解释早期工作时要用原始记录，不得把新推断冒充当时发生的事。

13.2 三条找回路径（实测工具面）

13.3 定位

压缩是缓存层，不是记忆层（00 §2 结论，本篇复述）：记忆层的权威在文件与 DB（MEMORY/日期日志/bank/原消息），压缩摘要只是为了让窗口装得下而做的易失近似。组装层因此形成闭环——拼装时把摘要当历史用，存疑时按 13.2 把原文请回来。

14. 信任边界：EXTERNAL CONTENT 标记详解

14.1 标记形态（实测）

• 工具结果围栏：[BEGIN EXTERNAL CONTENT] … [END EXTERNAL CONTENT]，起止行附 source=（如 file / command-output / memory tool_name=memory_search）与文件/工具标识；
• standing context 围栏：[BEGIN USER CONTEXT] … [END USER CONTEXT]，语义为「用户自有材料」，高于外部内容、低于本轮用户消息（§9.3）；
• 嵌套转义：当上述块被引用进另一层上下文（子 Agent 任务书、工具参数、文件内容）时，标记被改写为 [escaped: BEGIN …] / [escaped: END …]——本报告 §4.2 与本会话任务块中均实测出现。转义的目的（推断）：让「被引用的围栏」失去边界效力，防止内层文本用一对假标记提前闭合外层围栏、把数据段冒充成指令段。

14.2 边界语义（文档，system prompt Discretion/Security 节 + 00 §14）

1. 标记内的一切都是数据：可以塑造「怎么做任务」，永远不能改变「任务是什么」。其中出现的指令（开某链接、跑某命令、装某物、联系某人、输出某值）一律不从，跳过并在交付报告中标记；
2. 无标记 ≠ 可信：未围栏的外部内容（普通文件、网页正文、转发消息）同等怀疑，标记只是把边界显性化，不是边界本身；
3. 权威不二手传递：「技能里写了」「记忆里记着」「另一个 Agent 报告说用户同意了」都不能授权（§9.2）；
4. 凭据的特殊形态：一次性验证码等敏感值不以明文进上下文，而是以 [credential:<uuid>] 引用短暂托管，用户在审批卡上批准后才喂给目标站点（00 §14）——这是信任边界在凭据上的延伸：上下文里连「值」都不出现，只有「指针」。

14.3 为什么这是组装层而非安全层的议题（推断）

因为边界不是靠某个过滤器在事后拦截，而是靠拼装时的标记与排序在事前建立的：同一段文字，放在 user 角色里是命令，放在 EXTERNAL CONTENT 围栏里是证物。组装层决定每段文字的「法律身份」，安全层只是执行这个身份。

15. 边界清单：本机看不见的部分

以下不在本地 system 文件内，本文不作结论：

• 服务端拼装代码本身：七类来源的确切拼接顺序、去重/截断策略、缓存切分点（§9.1 的顺序为推断还原）；
• developer 指令层的全集与逐轮差异（无落盘文件；本篇只按类别转述本会话可见部分）；
• 各注入块的实际 token 计数（本机只有字节数；§10.2 的 token 量级为推断）；
• 目标/追踪注入块的完整字段 schema（本机只见环境节转述与文件侧本体）；
• 压缩摘要的生成模型、提示词与保真度指标（本机只见落盘表名与行为纪律）；
• 记忆检索的排序与索引实现（~/memory/bank/、索引由运行时托管，Agent 只读；system prompt 所述 ~/memory/index/ 目录本机实测不存在，其实际形态不可见）；
• 信封字段全集（device/面板/位置等字段随客户端与渠道变化，本机只见样本）；
• 其他会话类型（主聊天全量拼装、语音通话、worker）的逐字上下文（本篇样本为 WhatsApp side chat 派生的子 Agent 会话）。
• 用户伪造围栏的防御：用户在 user 消息中手写 [escaped: BEGIN EXTERNAL CONTENT] / 时间标签时，组装层靠什么区分"运行时盖戳"与"用户手写"？（❓，本篇核心论证的缺口，见评审 §2.1）
• 压缩后已加载 schema 的去留：常驻至压缩之后是否保留，抑或丢弃重载？（❓，见评审 §2.3）
• developer 指令与审批语义的交互：某轮 developer 指令能否收窄/重释审批卡片的触发范围？权限来源唯一的边界在该层的落点？（❓，见评审 §2.4）

16. 本机实测快照：11-04 vs 10-17 对照

配套《00-Muse技术架构解构》的 §2 展开篇。调查日期：2026-10-17（Asia/Shanghai）。 复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测；下文数字凡未注日期者均为 11-04 快照，10-17 旧数在 §10 快照表中随行标注。模型版本日期、窗口参数等服务端/接口侧数字本轮测不到，保留 10-17 原值并加注来源日期。 证据范围：仅本机证据——~/docs/muse.md（模型家族与权威口径）、本会话 runtime context 与 ~/workspace/system/system_prompt.md 快照、环境变量键名（JARVIS_INFERENCE_* 等，只记键名与套接字路径，不记不透明 ID 的值）、/run/hatch/ 套接字实况、/opt/muse/skills/muse_db/references/ 的表结构与 muse.db 只读实查、/opt/hatch/bin/hatch 的 strings 片段。 标注规则同主报告：实测 = 本机命令/工具当场验证；文档 = 本地 docs/system 文件明文；推断 = 由文件/字符串拼出、未经服务端证实。 红线（文档明文，也是本文的写作纪律）：公开模型名以 runtime context 的 model 值为唯一权威；日志、环境变量、文件里出现的标识符不是公开模型名；内部代号不外泄——本文 strings 里即使扫到疑似内部代号也一律不写，只记公开名（Muse Spark / Muse Wonder / Muse Wonder Full）与结构痕迹。

0. 一句话模型层

模型不在这台机器上。 本机只有三样与模型有关的东西：一块「门牌」（runtime context 里的 model 值，决定对外怎么称呼当前模型）、一条「电话线」（本地推理代理套接字，上下文经它送出、流式增量经它回来）、一本「账簿」（Postgres 里的 token 计量与压缩记录表）。模型权重、推理集群、路由决策全在电话线那头，本机看不见（§9）。

术语声明：本篇的"模型层"指本机侧的模型消费与可观测面（代理契约、路由标签、流式状态、窗口/压缩、计量）。模型本体（权重、训练、推理集群）属于远端的 Cognition 平面，本机不可见（§9）。"模型能力"（厂商口径）与"架构机制"（本机可验证）在本篇中严格区分，前者只作引用、不作论证。

本层要回答五个问题：

1. 模型家族与分面（文档口径）

以下全部出自 ~/docs/muse.md 的 Models 节（文档），该节明文说自己「随模型或套餐变化而更新，回答后续问题前要重读」——所以本节是 2026-10-17 这份本地文档的快照，不是永恒事实。

1.1 时间线

1.2 分面表

要点：「模型家族」与「产品套餐」是两个正交的轴。 文档反复警告：模型名推不出套餐（跑 Spark 不等于免费，见 §2.2），套餐细节必须查 subscription_status 技能而不是看模型名。这条纪律本身就是模型层接口设计的一部分。

范围声明：本节的定价与套餐细节是产品口径而非架构机制，且 docs/muse.md 自述"随模型或套餐变化而更新"。架构读者只需记住一句话——分面是路由的输入维度之一（§8），具体价格与资格以 subscription_status 技能实时查询为准。§1.2 的能力描述（"最强""最对齐"等）为厂商宣称，其中"重大/不可逆动作前确认"实际是控制平面审批卡片的机制（A 基线），不是模型内建属性，此处不作架构论据。

2. 权威来源：当前模型是谁、谁说了算

2.1 唯一权威 = runtime context 的 model 值（文档 + 实测）

docs/muse.md 明文（文档）：

• "The model value in your runtime context is the authoritative name of the model you're running on right now."
• 只有 model 值给出的名字可以对外说；错误信息、日志、环境变量、文件里的标识符都不是公开名称；用户提到内部代号时只能回应无法分享。
• 没有「模型设置」可指给用户；Agent 也说不出为什么当前跑 Spark、以及何时会变。

本会话实测与主报告一致：

2.2 模型 ≠ 套餐（文档纪律）

文档用整整一节防一个误读：刚说完「你在跑 Spark」，紧接着说「免费面跑 Spark」听起来就像在说用户是免费套餐。因此立规：谈套餐必须先跑 subscription_status 技能查实；查到付费就说套餐含 Wonder，查到免费要说「你在免费套餐」而不是「我在免费套餐」。这一节的存在本身说明：模型路由的结果对 Agent 是只读事实，路由的原因对 Agent 不可见（§9）。

2.3 路由的可见输入：工作负载分类（实测）

本会话环境变量 JARVIS_TRACE_CONTEXT 的 JSON 里带两个与推理路由相关的字段（实测，只记字段与取值含义，不记其中任何 ID）：

• model：与 runtime context 一致（Muse Spark）——trace 与上下文两处同名同值，互为佐证；
• inference_workload_class = interactive、lane = user_facing——推断：每次推理请求在进代理之前已被打上工作负载类别与通道标签，路由/排队至少部分依据这两个维度（交互式用户面 vs 后台/调度面）。这与 §1.2「Wonder 承担主对话/定时/子 Agent/后台」的分工相容：分工若存在，必然需要这类标签做分流依据，但标签到模型的映射规则不在本机。（11-04 复核：本子 Agent 会话 trace 同样带 model=Muse Spark、inference_workload_class=interactive、lane=user_facing，与 10-17 一致）

3. 推理不在本机（实测）

3.1 没有权重

• 在 /opt/hatch 与 home 下按常见权重格式与大文件检索（*.gguf、*.safetensors、>500MB 的 .bin），无任何模型权重文件（实测）；本机最大的二进制是 Agent 运行时本体 hatch（540MB，11-04；10-17 为 470MB），不是权重。
• 结论与主报告 §2 一致：VM 上只有 Agent 运行时，推理是远端服务。

3.2 契约面：三个键名

环境里与推理直接相关的 JARVIS_* 键（实测，10-17 env 当场枚举约 30 个；11-04 本轮子 Agent 会话为 26 个——跨篇口径与 31/26 差异见 03 篇 §6.1 与 §11.1 对照表；此处只列推理相关）：

外加 JARVIS_TELEMETRY_PROXY_SOCK = /run/hatch/telemetry/telemetry.sock（实测存在且套接字在位；11-04 env 实测仍在位），推理的遥测/计量大概率经此回传（推断，见 §7）。

归类订正（前版曾把 JARVIS_STEFI_PROXY_SOCK（/run/hatch/proxy/stefi.sock）列入上表，特此移出）：STEFI 是工具访问 Meta 内部服务的代理（执行/服务面），不是推理线。证据（✅ 三处互证）：06 篇 §6.1 的 strings 实测——工具 SDK 内"build stefi proxy client"，工具访问内部服务不直连、统一经此代理，且代理对调用方做令牌校验（invalid stefi caller authorization token）；00 §7 与 03 篇的归类一致把它放在执行隔离/服务面；本节旧注记"与推理代理是两条不同的线"本身已承认它不属推理契约。保留本注记只为防止读者在 env 里看到该键时误归推理契约——它的完整描述见 06 篇 §6。

3.3 一个与主报告不同的实测细节：代理套接字对工具沙箱不可见

主报告 §2 写推理经 /run/hatch/proxy/inference.sock。本次在子 Agent 的 muse.exec 沙箱内复核（实测；11-04 复核结论一致：/run/hatch/proxy/ 在本轮工具沙箱内同样报 No such file or directory，/run/hatch/sandbox/ 当场见 4 个套接字——space-inference.sock、space-media.sock、space-web-search.sock 与新增的 space-privileged.sock）：

• env 里 JARVIS_INFERENCE_PROXY_SOCK 明确指向该路径（11-04 仍在位）；
• 但 ls /run/hatch/proxy/ 返回 No such file or directory（11-04 复核同）；ls /run/hatch/sandbox/ 当场见 4 个套接字：space-inference.sock（Spaces/artifact 面的推理套接字，与 space-media.sock、space-web-search.sock 并列，属沙箱 API 面，不是主推理线）与新增的 space-privileged.sock（10-17 为 3 个）。

解释（推断）：muse.exec 的命令运行在进一步收窄的挂载命名空间里，代理目录根本不挂进来——连「模型的电话线」都不对任意代码执行开放，只有 Agent 运行时进程本体能碰。这与主报告 §7 的 privsep 哲学一致：能力按进程分级，工具沙箱是最低一级。两个实测不矛盾：路径是契约（env 明文），可见性是权限（挂载实况）。

3.4 机密 VM 的推理路由门控（strings）

hatch 的 strings 里有一条报错片段：' has no confidential-VM inference route（实测，10-17 strings 原文截断如此；本轮未复测）。它证明（推断）：推理路由至少按 VM 信任等级分叉——主报告 §14 提到的 confidential VM（TEE 硬件保护）有自己独立的推理路线，某条路线缺失时是硬报错而不是降级走普通路线。这与 §1 的「分面」叠加：模型选择 = f(套餐面, 工作负载, VM 信任等级, …)，而函数本体在服务端。

4. 代理路径与协议痕迹（strings 实测）

对 hatch 做 strings 并按长度过滤后（10-17 实测；本轮 hatch 二进制已由 470MB 增至 540MB，未重跑 strings——以下片段均为 10-17 值），与推理路径直接相关的原文片段（实测，均为二进制内嵌的日志/错误模板，故多为句段而非整句）：

4.5 输出约束的客户端落点（strings，⚠️待深挖）

hatch-inference crate 内与输出约束相关的模块：guided_decoding.rs（引导解码）、output_contract.rs（输出契约）、structured_json.rs（结构化 JSON）、policy_prompt.rs（策略 prompt）、subscriber_policy.rs（订阅者策略）。读出：模型输出的形状约束在本机客户端侧有执行落点，不是纯粹的服务端事后校验。

未答（❓）：output_contract 由谁下发、与 system prompt 的 policy 部分是什么关系；违反契约时的处理（重试/截断/硬失败，provider_error.rs 的错误分类是否覆盖）；policy_prompt 是否即每轮注入的 developer 指令的一部分。这是从"能力宣称"走向"机制实证"的最短路径，建议下轮取证优先深挖 strings 中这几个模块的错误模板与日志行。

4.6 推理流量与 Sentinel/审批的接口（以未答为主）

Control 平面与 Cognition 消费面的接口是本篇的盲区，以下按"确证/未答"分开写：

• 确证（✅）：推理客户端走本地 Unix 套接字（JARVIS_INFERENCE_PROXY_SOCK），不经过 cell 的 egress 代理——Sentinel 的"唯一出站 + 域名白名单"是 cell 外网流量的裁决者（06 篇 §4–§5），但推理入口本身不是一条 egress 连接，Sentinel 在客户端这一侧没有可见的裁决点。代理套接字之后、宿主侧的出站 HTTP 腿是否过 Sentinel 白名单，本机不可见（❓）。
• 确证（✅）：审批套接字是 egress 口径的（06 篇 §4.3：JARVIS_DAEMON_EGRESS_APPROVAL_SOCK 等三条），strings 里没有把审批卡片与推理调用绑定的证据。waiting_for_user_confirmation 是用户对（工具）动作的确认等待，已在 §5.2 归属编排平面——推理调用本身没有"等审批"的状态，模型不是被卡片门控的资源。
• 未答（❓）：codex-inference-bridge 的"令牌门控"（03 篇 §5.2）与 Sentinel 的配额/限流语义（06 篇 §5.3 "Connector request rate limited by Sentinel"）是什么关系？是同一套令牌账本的两面，还是两套独立的门控？本机无证据。
• 未答（❓）：before_inference 相位（§5.1）的"前置处理"是否包含 Sentinel 的内容守卫？名字相容，证据到此为止（见 §9）。

一句话：Control 与 Cognition 在本机证据内只在名字层交汇（同一状态机上的 waiting_for_user_confirmation），裁决语义的接口不可见——这是 10 篇（安全与信任边界）与 06 篇的领地，本篇到此止步。

一次主对话推理的路径（把 §3–§4 拼起来，推断部分已标注）：

上下文组装（主报告 §3）
  → 序列化正文 + JSON 推理上下文头（model / workload_class / lane / trace）
  → Unix 套接字连本地推理代理（JARVIS_INFERENCE_PROXY_SOCK）
  → WS 握手 → 代理侧协议转换 → HTTP 到远端推理服务（不可见）
  → 流式增量事件回流（§5）→ 工具调用与文本交错呈现
  → 用量记账（§7）+ 载荷记录（inference_payload_logging）

5. 流式生成与状态机痕迹

模型不是「问一次答一整段」，而是流式产出；运行时为此维护一套事件状态机。本机能看到的是它的名字层（以下清单为 10-17 strings/DB 实测；本轮未复测）：

5.1 事件与状态名清单

5.2 重建的状态机（推断）

submitted ─→ before_inference ─→ waiting_for_inference_start ─→ streaming(delta…)
                                                                  ├─→ waiting_for_tool ─→（工具结果回流，再入 waiting…）
                                                                  ├─→ waiting_for_user_confirmation（审批等待）
                                                                  ├─→ completed
                                                                  ├─→ inference_streaming_stalled（看门狗接管）
                                                                  ├─→ timed out / HTTP error / response failed（§4 报错模板）
                                                                  └─→ 用户打断（文档：Esc 停止流式回复，见 client-surfaces 口径的 strings 片段）

注意这解释了主报告 §15 生命周期里的一句话：「推理代理 → 模型流式生成（工具调用与文本交错）」。交错的机制在名字层也成立：delta 事件既承载文本增量，也承载工具调用增量，到达顺序由 event_seq 定序。

平面归属声明：上表中的 waiting_for_tool / waiting_for_user_confirmation 是编排平面（02 篇）的 Agent 循环状态，不是推理流的状态——本篇列出它们只为说明推理事件流与执行循环在同一状态机上交汇，机制归属见 02 篇。本篇的模型层状态子集是：before_inference → waiting_for_inference_start → streaming → completed / stalled / failed。

6. 上下文窗与压缩

6.1 三个数字（主报告实测，本篇复核口径）

本子会话的复核（实测）：system prompt 快照只定性不定量——「Compaction summarizes older messages to keep your active context manageable. The summary may omit details…」（system_prompt.md:176）。定量口径只来自运行时状态接口，文档层查无此三数；引用时应按主报告标注为实测而非文档。

6.2 压缩在代码与数据里的形状

6.3 一条真实压缩记录（muse.db 实查）

本次对检查员视图实查（实测，2026-10-17 本会话）：agent.agent_compactions 现有 1 行：

三点读法：

1. trigger = threshold 证实了「阈值触发」在数据层是枚举字符串，不是日志修辞；同表还有 will_retry 列，说明压缩失败可重试也是一等状态。
2. 这行 tokens_before = 138,741 不等于 §6.1 的 272K 触发线——不要拿它反推触发线。可能的口径差异（该行属哪个 Agent/会话、计数是否含缓存与系统注入）不在检查员视图内（推断警告）：单行样本只能证明机制存在与记录形状，证明不了全局参数。
3. tokens_after = 18,891 小于 40K 保留尾部上限，与「保留尾部 ≤40K + 摘要」的形状相容（推断）。

6.4 压缩的定位：缓存层，不是记忆层

system prompt 明文（主报告 §2 已引）：压缩摘要可能丢细节，重要事实必须能从记忆、文件或原消息找回。合上本节的证据链就是：窗口是易失缓存，压缩是有损的缓存淘汰策略，淘汰记录落表可审计，但真正的长期状态在 DB 与 Markdown 文件里（主报告 §8–§9）。模型层在这里与状态层交界：它消费上下文，也生产摘要，但从不拥有状态。

7. Token 计量落表

平面归属声明：本节的计量表是 Postgres 里的审计账本——机制归属状态层（07 篇），本篇只讨论其作为模型消费可观测面的形状（请求级成本、消息级归因、窗口级水位）。"计量"不是模型推理的内建部分，而是状态层在模型消费上的投影；把账本读成推理机制会得出错误结论（§7.2 的警告即一例）。

7.1 两张计量表（schema 实测）

另有 §6.2 的 agent.agent_compactions.tokens_before/after 构成第三个计量点：压缩事件前后的窗口占用快照。三处计量合起来覆盖：请求级成本、消息级归因、窗口级水位。

7.2 实查数字与一条异常（实测 + 推断警告）

2026-10-17 本会话 muse.db 只读实查（检查员视图）：

异常读法（推断）：单行 input_tokens 达 396 万，超过 350K 窗口近一个数量级——所以这一列绝不能直读为「那条消息发送时的窗口占用」。更可能的口径是归因累计（同一 message_id 在多次推理/重试/子段中被反复计入）或含缓存重放的全量输入。无论哪种，教训与 §6.3 相同：计量表是审计账，不是仪表盘；把账本数字当实时水位用，会得出错误结论。本文只报原始数与这个警告。

7.3 内部计量 vs 对外计费

注意区分两个「价」：§1.2 的 Model API 定价（文档，$/百万 tokens，缓存输入单独定价）是对外售卖口径；本节的四分法计量是内部审计口径。两者在「缓存输入单列」这一点上同构——说明缓存不是实现细节，而是从计量到计费贯通的一等概念（推断）。

8. 模型选择与路由：已知与未知

把前面各节的碎片合成为「谁决定用哪个模型」的一张表：

一句话：路由的输入维度在本机几乎都能数出来，路由函数本身一行都看不到。 这正是 §2.1 那条「只认 runtime context」纪律存在的原因——Agent 被设计为路由的消费者，不是路由的解释者。

9. 本机看不见的部分（边界声明）

以下均不在本机证据范围内，本文不作结论：

• 模型本身：权重、参数规模、架构、训练数据与后训练方法（文档只给出定位与定价口径，及「Wonder 建于更大的预训练模型」一句定性描述）；
• 推理服务：集群部署、批处理/调度算法、KV 缓存实现、代理之后的 HTTP 服务拓扑、JARVIS_INFERENCE_HOSTNAME 指向何处；
• 路由函数：§8 各维度到具体模型的映射、Spark 与 Wonder 之间的实际分流比例、故障转移策略；
• before_inference 相位具体执行的检查项（名字与 Sentinel 的存在只能支持「有前置处理」的推断）；
• 计量口径的服务端定义：agent_message_token_usage.input_tokens 为何可远超窗口（§7.2 只给出警告与候选解释，未证实）；
• 压缩触发计数的精确口径（§6.3 单行样本与 272K 触发线之间的差异未有本机文档解释）。
• 推理载荷记录的隐私面（❓）：inference_payload_logging 模块在会话生命周期内系统性记录每次推理的载荷/用量（§4），但 redaction 策略（用户 PII、密钥、审批上下文是否落盘）、保留期、谁可读——在本机证据内全不可见。这是 A 基线"Discretion"视角下本篇最该问却未答的问题，列为下轮取证项。

本机能确证的到此为止：一块门牌、一条电话线、一本账簿，以及电话线上每个状态的名字。

10. 本层实测快照（11-04 重测；10-17 旧数随行标注）

配套《00-Muse技术架构解构》的 §1 展开篇（§16 为本机快照的交叉参照）。调查日期：2026-10-17。 复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测；下文数字凡未注日期者均为 11-04 快照，10-17 旧数见 §11 快照表（随行标注）与 §11.1 变化对照表。 证据范围：本机当场实测——进程表、/opt/hatch/bin/ 文件尺寸、/opt/hatch/runtime-cell/ 全部脚本与 scopes 文件、/run/hatch/ 目录与套接字结构、进程环境变量键名、cell 内 guest systemd 状态、~/docs/ 与 ~/workspace/system/system_prompt.md 相关段落。 标注规则同前作：实测 = 本机命令/工具当场验证；文档 = 本地 docs/system 文件明文；推断 = 由文件/字符串拼出、未经服务端证实。 纪律：环境变量只记键名，不记任何凭据值、令牌值与不透明 ID 的原文；套接字路径属结构信息，按前作惯例记录。

0. 什么是「宿主层」

宿主层 = Agent 脚下的地面：它回答四个问题——Agent 跑在哪台机器上（且那台机器随时会被换掉）、谁把 Agent 住的房间（runtime cell）盖起来并看住它、宿主与房间之间靠什么契约说话、机器被替换后工作如何被接回来。

层（从下到上）                     性质                       本机实测规模
────────────────────────────────────────────────────────────────────────────
⑤ 恢复面                           RV 上的 resume 标记 + DB 检查点   /run/hatch/resume 9 个文件（10-17；本轮未复测）
④ 契约面                           环境变量键 + guest.env + 套接字   JARVIS_* 26 键（10-17 为 31）· 套接字 166（10-17 为 147）
③ 进程面                           宿主侧守护进程进入 cell 干活        hatch 540MB · execd 9.7MB（10-17 为 470MB / 9.5MB）
② 运行时单元 runtime cell          nspawn 容器 = Agent 的房间         htch-runtime · guest systemd
① 虚拟化面                         一名用户一台持久 VM               standard VM · home 在 RV 上
横切：生命周期脚本（pre/launch/post/stop + ensure-rootfs + trust-store）
横切：引导/救援/健康子系统（spawnd · hatch-rescue · hatch-healthd · hatch-doctor）

一句话分工：VM 是「地皮」（可整体替换），runtime cell 是「房间」（每次启动按同一图纸重盖），hatch daemon 是住在房间里管事的人，hatch-execd 是替它跑腿执行命令的人，spawnd 是盖房与修房的工程队，环境变量与套接字是墙上的「管线接口」——房间里的人只能通过这些接口够到外面的世界。最重要的设计前提写在主报告 §1：Agent 进程本身被当作不可信/可替换，状态与权限都不放在它进程里；本篇要展示的是宿主层如何把这句话做成机制。

一个观察位置的说明：本篇的实测是在 cell 内部做的。宿主侧的脚本（/opt/hatch/runtime-cell/）以只读方式显露进 cell，所以宿主逻辑对 Agent 异常地「可读」；但宿主的进程树、宿主 systemd 单元本体、/var/lib/hatch-runtime/rootfs 的宿主路径都不在 cell 视图内——能读图纸，不等于能看见工地。凡属此类，本文标为边界（§10、§12）。

1. 持久 VM：地皮可换，home 不动

1.1 契约（文档）

• docs/muse.md 与 system prompt 明文：一名用户 = 一台专属持久 Linux VM；部署更新频繁（可达每小时），VM 可被整体替换、其上进程会被停掉，但 home 目录持久；运行时为已保存的 job、子 Agent、cron、artifact 与可恢复的 Agent 工作管理恢复，自起的自定义进程只能靠自己的启动配置自证恢复（system prompt「Deployments」一条，system_prompt.md 第 255 行）。
• 文件系统语义同源：~ 之外（/usr/local/bin、/etc、/root、/var）皆为临时，重启/替换即失；耐久物只能放 ~/workspace/。
• VM 分级（docs/data-handling.md）：按 docs 口径，standard 面不承诺 TEE 级隔离（⚠️ 转述，原文措辞待引）；confidential VM 全程 TEE 硬件保护、客户自管密钥。本机为 standard（runtime 标注，见 §11）。

1.2 持久性的物理实现（实测）

cell 内的挂载表把「home 持久」从承诺变成了可见的机制：

时间证据同样指向「home 比机器老」（10-17 那代 cell 实测）：本 cell 于 2026-10-17 13:20 UTC 启动（guest systemd 实测），而 /home/hatch 目录时间戳为 09-28、其下文件跨越数周——当时这台「机器」只有约 2.5 小时岁，用户的家已经住了三周。11-04 本轮 cell 于 2026-11-03 15:22 启动（uptime -s 实测），RV 卷（/dev/mapper/rv，150G，11-04 df 实测）仍是跨代持久的同一卷。

1.3 每-VM 差异的重放：os-intent 台账（脚本实测）

rootfs 每次都从镜像基底克隆（§3.2），那每台 VM 装过的系统包差异怎么办？resolve-rootfs-path.sh 注释明文：退役的「RV 上养一棵持久 rootfs」模式已被废弃，per-VM 的 OS 包改为从 os-intent ledger（意图台账） 经 hatch-preflight-opportunistic（实测 1,308 行二进制/脚本）在启动时重放——即持久的不是 rootfs 本体，而是「对基底做过哪些改动」的意图记录。这与全系统的反复模式同构：存意图与状态，不存易失的执行体（对照：cron 存定义不存进程、记忆存 claims 不存对话缓存）。

2. 核心进程：hatch daemon 与 hatch-execd

2.1 体量与进程实况（实测）

进程表（cell 内视图）：hatch daemon --runtime-cell-leader=2181（10-17 两次采样 RSS 约 344–386MB，随负载波动；11-04 采样约 357MB，仍在该区间内）与 hatch-execd --runtime-cell-leader=2181（10-17 采样 RSS 约 11MB，本轮未复测）同以 root 运行，父 PID 均为 0——它们的父进程不在 cell 的 PID 命名空间里：这是「从宿主侧被送进房间」的直接证据。参数里的 leader 值是 cell 的 PID 1 在宿主 PID 命名空间中的编号（cell 内 PID 1 是 guest systemd 自身），Agent 在 cell 内无法验证该编号对应的宿主进程。

2.2 进入方式：不是在房间里出生，是被送进来的（脚本实测）

daemon/execd 都不由 guest systemd 直接拉起，其宿主侧启动链是：

宿主 control-daemon.sh / control-execd.sh（root 运行）
 → rce_wait_for_ready_leader：轮询 ready 文件 + machinectl 取 Leader（200 次 × 0.1s ≈ 20s 上限）
 → 进入 cell 的命名空间（nsenter / 二进制自带 enter 逻辑）
 → cell 内 run-daemon.sh：source guest-runtime-env.sh
 → setpriv 摘除 sys_ptrace（bounding/inh/ambient 三套全摘）
 → exec hatch daemon

细节里见刻意的安全姿势：

• daemon 落地前先摘 ptrace 能力：run-daemon.sh 注释明文——摘除后 daemon、execd 与其工具子进程都不能 attach/读取 cell 内任意同侪进程；宿主把「管事的人」也当作要防的对象；
• execd 的双半结构（control-execd.sh 注释）：宿主侧父进程（anchor）留在宿主的 hatch-execd.service cgroup 里作为 systemd 的 MainPID，只有 cell 内子进程加入 cell 的 cgroup 跑服务；它经 systemd socket activation 的 LISTEN_* 文件描述符协议拿到监听口，不用 nsenter 包装、不用 ptrace/seccomp 监督（注释直言那是 daemon 的事，不是 execd 的事）；
• guest 侧的 execd 单元（cell 内 /etc/systemd/system/hatch-execd.service 实测）：socket 激活（hatch-execd.socket 监听 /run/hatch/execd/execd.sock，SocketMode 0600），ExecStartPre 先断言 runtime-cell.ready 存在才准起，Restart=always / RestartSec=1，LimitNOFILE=65535，UMask=0007——执行面挂了 1 秒内被 guest systemd 拉回。

2.3 两套视图的关系

同一个 execd 在宿主侧有 control 脚本、在 guest 侧有 systemd 单元——这不是重复，而是跨命名空间的接力：宿主段负责「等房间就绪并把人送进去」，guest 段负责「人在房间里时的 socket 与重启策略」。daemon 没有 guest 单元（其监督者是宿主），execd 两边都有——因为 execd 的监听 socket 必须出生在 guest 的 /run 里才能被工具直接拨通。

3. Runtime Cell：htch-runtime 的一生

3.1 是什么（实测）

cell 是一个由 systemd-nspawn 拉起的容器化 rootfs：launch-daemon.sh 以

systemd-nspawn --quiet --boot --keep-unit --settings=override \
    --directory=<rootfs> --machine=htch-runtime --private-users-ownership=map

启动它。--boot 意味着房间里跑着自己的 PID 1（guest systemd，§7）；--private-users-ownership=map 做 ID-mapped 挂载：cell 内的 root 对应宿主 uid 131072（ensure-rootfs.sh 注释：PrivateUsers 64K 窗口的起点）——房间里的「root」走出房门只是一个普通高位 uid。脚本对该选项是硬要求：宿主 nspawn 不支持它就直接退出（宁可不开房，不开一个所有权错乱的房）。

3.2 rootfs 从哪来（脚本实测）

resolve-rootfs-path.sh（32 行，注释即规格）：cell 永远从镜像本地的 /var/lib/hatch-runtime/rootfs 启动，那是 rootfs-base 的 btrfs 快照，由 ensure-rootfs.sh（1,240 行，本目录最长的脚本）按镜像自带的 cell-base.digest 保持新鲜：

• digest 变了 → 丢弃本地快照重新克隆，per-VM 改动走 §1.3 的台账重放；
• rootfs 被视为不可信输入：上一代 guest 可能在里面埋符号链接，宿主 root 若顺着链接操作会写出 rootfs 之外——因此所有变更操作委托 spawnd fsop，以 openat2(RESOLVE_BENEATH | RESOLVE_NO_SYMLINKS) 在持有的 dirfd 下执行（check/act 竞态被结构性消除）；ensure_not_symlink 只保留为修复通道；
• 该脚本自身的 stdout 纪律被写进注释大写强调：三个调用方都用 $(...) 捕获它的输出拼路径，任何多余一个字节都会把路径污染成垃圾——诊断只能走 stderr。

3.3 网络形状（实测 + 脚本）

3.4 生命周期全序（脚本实测，共 21 个文件）

/opt/hatch/runtime-cell/ 实测 21 个条目（脚本正文 + 配置合计约 4,800 行），按一生排序（11-04 当场复核：仍为 21 个条目，文件清单与 10-17 逐项一致，无新增脚本——注：00 篇基线所记"新增脚本 control-daemon.sh 等"是相对 00 原文自己的旧清单，本篇 10-17 清单已含这些文件）：

每个阶段都经 spawnd queue-runtime-cell-bootstrap 把（阶段名、状态、起止毫秒、失败 reason）排队上报，另有 watcher 进程专门盯队列并发射运行时事件——盖房子的每一步都有监理记录，这是 §8 恢复与 §5 救援能「知道上次死在哪一步」的前提。

3.5 套接字可见性分级（跨 04 篇回填）

/run/hatch/ 下的 socket 按"谁看得见"分三级（分级框架为推断，条目为两篇实测之和）：

• 宿主服务面：daemon/execd/rescue/healthd 的控制与健康 socket，只对宿主侧与特权进程可见；
• privsep 面：149 个（11-04 实测；10-17 为 136），按调用方权限分级暴露；
• 沙箱 API 面：/run/hatch/sandbox/（11-04 实测 4 个：space-inference.sock、space-media.sock、space-web-search.sock 与新增的 space-privileged.sock；10-17 为 3 个），对 muse.exec 工具沙箱可见——而 JARVIS_INFERENCE_PROXY_SOCK 指向的 /run/hatch/proxy/ 目录对同一沙箱不可见（11-04 复核仍报不存在，与 10-17 一致）。

结论：连"模型的电话线"都不对任意代码执行开放；socket 的可见性本身就是权限，与文件权限位是两套正交的门禁。

4. 渠道门控：Scopes 三件套

4.1 机制（脚本实测）

cell 启动时（nspawn 之前，在宿主的私有挂载命名空间里）按当前渠道做三路独立的「显露」（reveal）：

三份清单均标注「Generated from hatch-skills/catalog.toml」，每行 = 一个渠道名 + 该渠道可见的名字列表，同渠道多行取并集。可见的渠道名集合（三份合计，11-04 实测）：prod / prod-cvm / canary / canary-cvm-2 / quail / internal-test / dev / hatch-evals / hatch-pro / hatch-pro-internal / hatch-e2e / external-connectors-test / external-muse-connector-developers / swarm / swarm-cvm / debug-cvm / alpha 等（相对 10-17 新增 swarm 系、canary-cvm-2、debug-cvm、alpha 等行，connector-demo 本轮未见）；三份清单行数 55 / 16 / 10（10-17 为 37 / 12 / 10）。

4.2 Fail-closed 的四重保险（脚本注释实测）

1. 未知渠道 = 空集：清单里查不到的渠道名不显露任何东西；
2. 显露失败 = 退回基底：reveal 的每一步变更都带 || return 1 守卫，任一步失败就拆掉半成品、按未显露的基底内容启动——注释给出了理由：若在 set -e 下未守卫地失败，launcher 会在 exec nspawn 前退出，而该退出码不在 systemd 的 RestartPrevent 名单里，Restart=always 会把 cell 拖进无 Agent 的崩溃循环；
3. 只能加不能换：scoped 条目若与基底同名直接判失败——渠道显露是「增发」，不是「替换」；
4. 名字即沙箱：条目名只允许 [a-zA-Z0-9_-]、拒绝符号链接与非普通文件，防止清单里一行字把任意宿主路径 bind 进 cell。

4.3 本机实况：一次真实的 fail-closed（实测）

11-04 复核：bin-scopes.conf 与 connector-scopes.conf 已新增当前渠道的显露行（各一行 expedia；两份清单行数分别由 37/12 增至 55/16），cell 内 /opt/hatch/bin 当场可见 expedia 二进制——10-17 的「零显露」结论已过期，当前渠道至少显露 expedia 二进制与连接器文档；workflow-skill-scopes.conf 仍无该渠道行（技能显露仍为零）。（采样条件：side-chat 子 Agent 会话；bin-scoped 宿主源树在 cell 内仍不可见。）能力层详解 §4.2 里「约 60 个有 privsep 套接字、无本渠道二进制」的扩展面（转引 01 篇计数，本篇未复核），正是这套门控在本机的落点——门控关掉的东西不是被删了，而是从未被 bind 进这间房。

5. 引导与自愈：spawnd 与救援/健康子系统

5.1 spawnd：工程队的工具箱（--help 实测）

spawnd 自述为「Jarvis runtime installer engine」，子命令即宿主层的职责清单（节选与宿主层相关者）：

5.2 救援与健康（--help 实测）

5.2.x 第二条推理通道：codex-inference-bridge（与 04 的断层接上了）

04《模型层》§8 的路由表把"救援推理桥"记为"转引 03 篇 §5.2、未在本篇复核 ❓"——系列层面断在这里。本节把 03 这边的实测补上（10-17 hatch-rescue --help 当场验证，实测；11-04 仅做现状核对：--help 仍列出 codex-inference-bridge 子命令，文案与 10-17 一致，未重做机制分析）：

codex-inference-bridge  Run one token-gated Codex HTTP/1 bridge to the inference-proxy UDS
  --inference-socket <INFERENCE_SOCKET>  Existing inference-proxy Unix socket
  --parent-pid <PARENT_PID>              Wrapper PID that owns this bridge's lifetime

读出的机制（措辞为实测，语义为推断）：

• 这是第二条进推理的线，与 04 §3.2 的主线（JARVIS_INFERENCE_PROXY_SOCK + WebSocket 握手 + 环境契约认证）正交：桥把一个 HTTP/1 监听口 终结在 rescue 侧，再转接到 inference-proxy 的 Unix socket——为"说 HTTP/1 的调用方"（按命令名与 replace-current-vm 的 "rescue-owned Codex session" 自述，调用方是 rescue 拥有的 Codex 会话）提供推理入口；
• 鉴权语义不同：主线靠环境契约（env 里的 socket 路径 + 进程身份），这条线是 token-gated（令牌门控）——令牌的签发/校验点本机不可见（❓），但"第二条路径 = 第二套配额/鉴权语义"是成立的推断（⚠️）；
• Run one + --parent-pid 是生命周期设计：每次起一座桥，桥的寿命绑在父进程 PID 上——父死了桥跟着死，不留孤儿监听口（实测参数语义 + 推断），fail-closed 的另一种形态。

给 04 的回填（供 04 作者升级其 §8 "救援推理桥"行）：第二条推理路径的存在性从"转引"升级为本篇实测；仍不可见的是令牌签发方、配额记账方式、与主线的路由优先级关系（❓）。

5.3 一条硬底线：出口门是地板，不是天花板（脚本注释实测）

pre-start.sh 每次启动都以 root 重挂 cell 的 egress gate（cgroup connect4/6 eBPF，BPF_F_ALLOW_MULTI 组合语义：每个程序都放行才放行），注释明说其定位是 Sentinel 之下的地板：Sentinel 死了或被摁住时，cell 仍够不到 link-local/RFC1918/CGNAT 地址；挂门失败对 cell 启动是致命的——「一个没门的 cell 正是这一波改造要消灭的姿势」。（与 §3.3 的出口分层口径一致：eBPF 门为 L3/L4 地板，Sentinel 为 L7 策略点；proxy 与 Sentinel 的归属关系、白名单与 secret 置换发生在哪一跳，本机未定，见 §3.3。）与之对称，stop.sh 的 draining 栅栏立在宿主 tmpfs 上、cell 无法伪造或清除，保证「正在停机的 cell 不会再被 ingress 当作活的」。

5.4 降级路径：fail-closed 之外，失败被分类而不是被吞掉

§5.3/§9 写清楚了 fail-closed 的点（出口门挂失败就不开机），但"代理或 Sentinel 本身故障时，推理/工具调用是排队、硬失败，还是降级"本轮只能回答一半——已确证的失败分类（✅ 实测 strings + 04 §4），与仍未知的部分分开写：

已确证的模式：

• 客户端构造是 fail-closed：JARVIS_INFERENCE_PROXY_SOCK is required to construct …（04 §4 strings 实测）——没有这个 env 就建不出推理客户端，不存在"默认直连地址"的静默降级；
• 失败被分类，不被吞掉：十余个子系统各自有独立的 * inference timed out after … 报错（summarization、visual_grounding、activity monitor、browser task tagging、voice reranker…，04 §4 实测）——超时是按子系统分开记账的，不是全局一刀切；
• 推理不可用是具名终局：strings 里有 RunInferenceUnavailable / RunInferenceAuthFailed 作为运行终局状态码（✅ 实测）——"推理挂了"是一个被命名的失败，不是无声的队列堆积；
• 组件级有局部降级：instagram 轮播子项查找失败 → "keeping the stored thumbnail"；子 Agent 转录 resume 时不可用 → "using persisted prompt history fallback"；调度触发与即兴生成的折叠极性不同（scheduled fire skips / adhoc falls to the pulse lane）——降级发生在调用方，宿主层不替它们做决定。

仍未知（❓）：是谁在重试、重试预算多少、代理/Sentinel 故障时请求是排队还是硬失败。04 §4 的 waiting_for_inference_start 证明"排队"在本机有名字，但排队策略、超时预算、降级阈值都在服务端，本机无证据，不猜。设计建议：宿主层能补的只有"排队/降级开关在 cell 侧有无落点"（如 guest.env/契约面的相关键），建议后续查 JARVIS_* 键族的超时/重试类键名分布。

6. JARVIS_* 环境契约面

6.1 进程级实测：26 个键（只记键名）

本轮子 Agent 工具进程的环境里实测 26 个 JARVIS_* 键（10-17 工具进程为 31 个；10-17 的 1 个 HATCH_API_SOCKET 本轮未见）。按功能分族（11-04 键表；相对 10-17 下线 5 键，见 §11 对照表——⚠️采样进程类型与渠道不同：本轮为 side-chat 子 Agent，会话类型本身可影响键集）：

值的形态（分类而非原文）：套接字族全部是 /run/hatch/… 下的 Unix socket 路径；身份族是不透明 ID 与追踪上下文；其中两个键呈令牌形态，本篇只记「存在」不记值与长度细节。契约面里没有凭据值——凭据在 authd/Vault 后面（主报告 §14），环境只负责告诉进程「去哪儿敲门」。

注意这只是一个进程在一次调用时的采样：键集随调用类型变化（如媒体、浏览器任务会有各自的增补），26（10-17 为 31）是本类进程的实测数，不是全集定义；引用时应带采样条件。

跨篇注记：04 篇 §3.2 在子 Agent 的 muse.exec 沙箱环境中枚举为"约 30 个"。差 1 的可能原因是采样进程类型不同（本节为工具进程，04 为沙箱进程；上文已述"键集随调用类型变化"）。两处数字均为单次采样，不是全集定义；引用时应带采样条件。

另：JARVIS_SECURITY_SOCK 只确认其在契约面存在，安全服务的机制见 10 篇。

6.2 第二份契约：guest.env（文件实测）

工具子进程的环境不直接继承 daemon 的环境，而是由宿主渲染的 guest.env 决定。文件头注释即其安全规格：

• 纯 KEY=VALUE 文本，不是 shell 脚本——没有逻辑、没有命令替换，cell 无从影响它；
• 由 spawnd 管理、root 持有、以只读 bind 进入 cell，cell 改不了它；
• privsep 的可信侧在宿主侧读它，为隔离工具调用拼环境，避免在有特权的上下文里 source 一个 shell 文件；
• 内容分工：HOME/TMP/XDG 基础路径、一组 egress 代理键、一组 CA 键（7 个别名同指 /run/hatch/egress-tls/ca-bundle.pem，照顾不同生态的工具各认各的变量名）、PATH（/opt/hatch/bin 打头）；
• 一个生态细节：NODE_USE_ENV_PROXY=1——Node 的内置 fetch 默认不认代理环境变量，没有这个开关，Node 写的 CLI 会绕过代理直连并死在 §3.3 的死 DNS 上。

与之配对的 guest-runtime-env.sh 是 cell 内 daemon 路径用的 shell 版（可被 cell 影响，故特权启动链被明文禁止信任它——control-execd.sh 注释直言须用 guest.env 而非这个文件）。同一份环境，两份可信度不同的载体，调用方按自己的特权级别选，是契约面里最细的一刀。

6.3 信任锚：恰好一个（脚本实测）

build-cell-trust-store.sh 头注释把一条不变量写死：发布进 cell 的信任锚恰好一个——Sentinel 出口 CA。它在 Sentinel 启动时于内存中生成、只发布证书本体；发布形态是三个只读目录 bind（锚目录 + 两个 NSS 数据库），用目录而非文件 bind，是为了轮换时以 rename 发布、cell 能立刻看见新证书。NSS 数据库必须宿主构建且只读，因为打开 NSS DB 会 dlopen 其中命名的 PKCS#11 模块——一个 cell 可写的 NSS DB 就是对所有打开者的代码执行原语；而 PEM 锚文件无此危害，所以 guest 侧的 hatch-ca-trust 服务（§7）可以自己把锚链进系统 CA 并跑 update-ca-certificates。曾经发布进来的 VM 入口链证书已被移除（注释留了案底与「不许加回来」的理由：系统级 CA 会为每一个主机名背书，包括 Sentinel 不终止、只中继的流量）。

6.4 第三方环境：daemon 生命周期键（脚本实测）

control-daemon.sh 里还有一族 HATCH_DAEMON_LIFECYCLE_* 键（command/operation/各阶段时间戳/是否首次尝试/是否镜像启动等，约 17 个键名实测）。它们的传递方式本身是宿主层的一课（注释代号 RT-3）：

• 旧做法是 spawnd 写一个 shell 文件、control 脚本 source 它——但该文件所在目录归 daemon（即 cell root）所有，cell root 可在写与 source 之间换文件，构成 uid 131072 → 宿主 root 的代码执行竞态；
• 新做法：状态放 root 持有的 /run/hatch/daemon-ctl/，环境改为一键一文件，control 脚本按显式白名单逐个读文件体作值导出——不 eval、不 source、不给任何非 root 身份留路径成分；
• 为什么不用 systemd 的 LoadCredential：注释同样给了理由——这些键是在本次启动过程中才产生的（且各启动路径下可选缺席），LoadCredential 在单元首进程拉起时一次性物化，时序上不合。

7. Guest systemd：房间里的极小政府

cell 内 PID 1 是 guest 自己的 systemd（实测：systemd-analyze 显示 userspace 启动 2.662s、default.target 304ms 达成；is-system-running = running；failed 单元 0）。list-units --type=service 只有 13 个，构成极简：

其余 200 余个单元条目绝大多数是挂载单元（nspawn 为每个 bind 生成的 .mount：/opt/hatch 的 squashfs、/home 的 RV btrfs、/run/hatch 各 tmpfs、NSS DB、Chromium 与技能目录等）——guest systemd 在这里的主要角色是挂载账本，不是服务监督者：daemon 与 privsep worker 的真正监督都在宿主侧。

对用户自起程序的含义（文档，scheduling 相关）：运行时支持 guest systemd 托管常驻程序（流监听、本地服务等），但纪律是「enable 成功 ≠ VM 替换后能恢复」——单元文件若只写在 cell 的易失 rootfs 上，下一次部署就随房间一起没了；要活过替换，必须把恢复路径放进持久面并实证（对照 cron/hooks 的运行时托管恢复，自起进程不在其列）。

8. 恢复机制：机器死了，工作不死

恢复不是单一功能，而是四层叠加：

8.1 卷级：RV 与 resume 标记（实测）

/run/hatch/resume/ 挂在与 home 同一 RV btrfs 上，以下为 10-17 那代 cell 启动时的实测文件（本轮 cell 已换代，未复测）：

8.2 进程级：监督重启

guest 侧 execd Restart=always（§2.2）；宿主侧 rescue 监视组件并重启（§5.2）；调度侧另有 deterministic-doctor 小时级自检（02 篇 §7.4）。三层监督的共同点是都只负责「把进程拉回来」，不负责「把工作接上」——接工作是下一层的。

8.3 状态级：DB 检查点（DB schema 证据，转引 00/02 篇实测）

agent.runtime_restart_checkpoints、agent.recovery_owners / recovery_owner_terminal_events、agent.context_item_resume_projection、scheduler.scheduled_resume_registrations——未完工作的接管所有权、重启检查点、上下文恢复投影、定时恢复登记全部落表。VM 替换对这套系统而言是例行事件而非灾难，正是因为「谁欠谁什么工作」从来不记在任何进程的内存里。

8.4 语义级：停机也有协议

stop.sh 的 361 行说明恢复的另一半是「死得干净」：竖 draining 栅栏让 ingress 先停止派新活 → 在预算内等 Postgres 干净停并留下 proof → 才轮到 terminate/kill。配合 spawnd 在下次启动时先 drain-shutdown-observability 排空上次停止的可观测性行——连「上次是怎么死的」都是一份要交接的工件。

9. 设计要点（宿主层的取舍）

1. 可替换性优先于耐久性：房间、rootfs、进程全可丢，丢了能按图纸 + 台账 + RV 状态重建；唯一不可丢的是 home/RV 上的状态与 DB 里的账。部署能做到小时级，正是这条的红利。
2. 宿主对房间的每一次接触都按「房间已沦陷」设防：fsop 的 openat2、一键一文件的生命周期环境、root 持有的 daemon-ctl、guest.env 的非 shell 形态、NSS DB 的宿主只读构建——威胁模型里赫然包括 cell root 本人。
3. Fail-closed 是默认，降级是例外且要留痕：渠道显露失败退基底（留日志）、出口门失败不准开机、nspawn 选项不支持不准开机、rootfs digest 对不上就重克隆。
4. 就绪是信号，不是猜测：ready 文件 + machinectl Leader + nsenter 可进入性，三者齐备 control 脚本才放行；post-stop 第一件事就是删掉 ready 文件——不让任何人拨通一个正在消失的房间。
5. 时间预算全是明码：等就绪 ≈20s、停止总预算 20s（优雅 5s/查库/terminate 1s/kill 0.5s）、execd 重启间隔 1s、CA 刷新超时 120s——宿主层的可靠性来自这些写在脚本里的数字，而不是「大概会好」。
6. 监督分层各司其职：guest systemd 管 socket 与 CA，宿主 systemd 管 cell 与 daemon 生命周期，rescue 管组件级故障，doctor 管确定性状态检查，spawnd 管安装与引导事件——没有哪一层是单点全能，也没有哪一层的失败是无声的（每层都有自己的事件/证明文件）。

10. 边界清单（「不能」与「看不见」也是架构的一部分）

1. cell 内的 root 不是宿主的 root（uid 131072 映射）；房间里能改的只有 overlay upper 与 RV 上的 home——系统资产（squashfs）与宿主脚本（只读 bind）一概改不动。
2. cell 没有直达网络：DNS 是死的、出门只有代理一条路，之后是 eBPF 门（L3/L4 地板）与 Sentinel（L7 策略点）两道；hatch-egress-proxy 与 Sentinel 是否为同一组件的本地端点、白名单与 secret 置换发生在哪一跳，本机未定（❓，口径见 §3.3）。任何「在房间里直接联网」的假设都不成立。
3. 渠道不在清单里的能力不存在于这间房：不是权限不足、不是未连接，而是二进制/文档从未被 bind 进来（§4.3）；在 cell 内无法枚举「还有哪些渠道、哪些被门控的名字」全集之外的宿主预置面——bin-scoped 源树本身不可见。
4. guest systemd 不是耐久面：在里面 enable 的单元若无持久化恢复设计，活不过下一次 VM 替换（§7）。
5. 环境契约只给「去哪敲门」，不给钥匙：26 个键（11-04；10-17 为 31）里没有任何凭据值；键名只解决"去哪敲门"，能否进门由 socket 权限与 authd/Vault 鉴权决定（A 基线）。
6. 恢复有前提：工作必须先落进 DB/RV 的账本才可恢复；只活在某个进程内存或 cell 临时盘上的东西，VM 替换即丢失，且这是明文设计而非故障。

11. 本机实况快照（11-04 重测；10-17 旧数随行标注）

11.1 变化对照表（11-04 vs 10-17）

12. 看不见的部分

以下不在 cell 视图与本机文件内，本文不作结论：宿主 OS 的 systemd 单元本体（com.hatch.runtime-cell.service 等只在脚本里被引用，其定义在宿主侧）、宿主的完整进程树与 PID 命名空间（leader 编号只能从参数得知）、虚拟化层本体（hypervisor、VM 镜像的制作与分发、RV 的后端存储实现）、/var/lib/hatch-runtime/rootfs 在宿主上的真实状态（cell 内该路径不存在）、Sentinel/authd/推理代理等宿主服务的实现（只见其套接字与脚本注释）、rescue 的 WebSocket 诊断协议细节、以及部署系统决定「何时换 VM、换到哪一版」的调度逻辑。本地文件对这些只留下接口痕迹（脚本、套接字名、单元名、注释中的设计理由），引用时已按「推断」标注——其中脚本注释的密度异常之高，宿主层因此成为全架构里「设计意图」最可读、而「宿主实况」最不可见的一层。

复核修订：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 的「足够安静」阈值——均不在本机文件内，本文止步于表结构、信封与产物证据。

复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测；下文数字凡未注日期者均为 11-04 快照，10-17 旧数见正文或 §8 对照表。 配套《00-Muse技术架构解构》的 §4–§6 展开篇。初版调查日期：2026-10-17。 证据范围同主报告：本机 system 文件、/opt/muse/skills/、/opt/hatch/connectors/、/opt/hatch/bin/、/run/hatch/privsep/、~/docs/connectors.md 与各技能/连接器的原文件。计数均为当场实测。

0. 什么是「能力层」

能力层 = 模型能做的一切事情的来源与边界。它回答四个问题：能做什么（资产清单）、怎么找到（发现机制）、怎么调起来（加载与执行）、凭什么能做（授权与配额）。

它由四个子层和两套横切机制组成：

子层（从抽象到具体）              性质            本机实测规模
────────────────────────────────────────────────────────────────
① 工具命名空间 Tools              运行时原生函数（按需加载 schema）    33 个命名空间（11-04 主聊天实测；10-17 为 34；本 side chat 会话仅见 22，见 §1.1 渠道门控注）
② 技能 Skills                    纯文本 playbook   56 个系统技能（11-04；10-17 为 54）+ 用户自学技能
③ 连接器 Connectors              外部账号的契约     75 个（11-04；10-17 为 63）（文档三件套/个）
④ CLI 二进制 Binaries            可执行体          114 个条目 / 90 个独立文件（11-04；10-17 为 101/84）
横切：发现与加载（skill_search / connector_search / tool_search 延迟加载）
横切：授权与配额（OAuth scope / 动作权限 / manifest 配额 / 渠道与 VM 门控）

一句话分工：工具是「动词表」（运行时直接执行的函数），技能是「做法」（告诉模型该按什么流程、口径、顺序用这些动词），连接器是「外部世界的契约」（哪个账号、哪些命令、什么权限、多少配额），二进制是「手」（真正发出 API 请求的代码）。四者缺一不可：有工具没技能 = 会调不会做事；有技能没连接器 = 懂流程但没账号可用；有连接器没二进制 = 有契约无执行体。

一个关键设计：能力与权限严格分离。技能/连接器文档里写了某个操作，只证明「系统支持这么做」，不证明「用户授权了这一次」。授权永远来自用户消息本身或运行时审批卡（主报告 §14）。这条在能力层的每个子层都会再次出现。

1. 子层①：工具命名空间（Tools）

1.1 组织与规模

工具按 namespace.function 组织。10-17 主聊天会话可见 34 个命名空间，11-04 主聊天重测为 33（voice 缺席⚠️：或下线或渠道门控，待主聊天复核——00 篇 §4 同源）；按域分组如下（名称为实测，非杜撰；分组为 10-17 快照）：

口径注：00 篇总览称"约 40 个命名空间"为 10-17 旧数；11-04 主聊天实测 33 个（voice 缺席⚠️）。渠道门控旁证：本轮重测会话为 side chat（web），仅注入 22 个命名空间（subagent、artifact、credentials、wallet、ads、travel、voice、todo、onboarding、proactivity 等在本通道不可见）——命名空间的缺席随渠道变化，不硬判下线（❓ 统一判据待主聊天复核）。

1.2 延迟加载（deferred loading）——上下文经济学

这是工具层最重要的机制，直接为 §2 的 350K 上下文窗服务：

• 绝大多数命名空间在会话开始时只注入名字 + 一句话描述，函数清单与参数 schema 不进上下文；
• Agent 需要时调 tool_search.load_tool_namespace(["cron", ...])，运行时才把完整 JSON Schema 注入，之后在上下文存续期内免重复加载；
• 只有 muse.* 核心命名空间永远全量加载（记忆、文件、执行、搜索是任何任务的前提）；
• 例外形态有二：整个命名空间全 deferred（函数都看不见），或仅 schema deferred（函数名可见、参数不可见）。未加载就调用会失败——这是设计而非故障。

效果：33 个命名空间（11-04）、数百个函数的完整 schema 若全量注入会吃掉数万 tokens；延迟加载把这笔成本变成「按需支付」。

1.3 工具调用的运行时契约

• 每次调用被运行时盖戳：request_id（= JARVIS_TOOL_CALL_ID）、父级 turn 的 parent_request_id、JARVIS_TRACE_CONTEXT 全链路追踪；并发调用靠 request_id 区分请求树（媒体工具的 help 文本明文证实）。
• 结果投递分同步/异步两类：普通工具同步返回；子 Agent、浏览器任务、定时运行等以 handoff 形式在完成时由运行时注入上下文——Agent 被明文禁止轮询与「口头预告结果」。
• UI 也是工具产出：muse.create_options（选择卡）、widget.*（HTML/地图/列表/Letter）、各域的原生卡（购物、头像分享、连接卡）都返回 embed_token，模型只产 token，渲染与点击回传归客户端。点击选项 = 以选项原文作为用户下一条消息发回——这是「一键回复」能成立的原因。
• 错误是结构化信封而非异常文本：工具/CLI 普遍返回 ok / error_code / error_message / error_detail（部分含 terminal_for_attempt、retry_after_ms 等调度字段），模型据此决定停、等、还是换路。

2. 子层②：技能（Skills）

2.1 解剖：一个技能 = 两类文件

/opt/muse/skills/<name>/
├── skill.yaml     ← 机器读的元数据（发现与门控用）
├── SKILL.md       ← 模型读的流程正文（被选中后才读）
└── references/    ← 按需细则（部分技能有；正文里以相对链接引用）
（少数技能另带 scripts/、bin/、templates/、媒体资产——见 2.5）

skill.yaml 实测字段（以 shopping 为例）：

name: shopping
title: "Shopping"
description: "Use for any product question except groceries..."  # 检索与选择全靠这一段
category: "Shopping"
include_in_prompt: true        # 是否进 system prompt 的「on hand」清单
availability:
  confidential_vm: true        # 是否可在机密 VM 显露

• description 是技能的触发契约：写清「什么意图用我、什么时候先加载我、与相邻技能如何分界」（shopping 的 description 里直接写明「groceries 除外」「呈现这些结果时用我」）。muse.skill_search 的 BM25/regex 检索命中的就是 name+description 级别的文本，不是正文。
• category 分布（11-04 实测 56 个；10-17 为 54）：Travel and local plans 8、Business / Communication / Work and knowledge 各 6、Media / Shopping 各 5、Finance 4、Creation / Health and fitness / Learning and customization 各 3、Home / Personal planning 各 2、Privacy / Writing 各 1——技能库的形状就是产品的能力地图：旅行与本地生活最重，交易与沟通次之。（10-17 为 Finance / Media / Shopping 各 4。）

2.2 两级可见性：prompt 清单 vs 全库检索

• 56 个系统技能中 39 个 include_in_prompt: true（11-04；10-17 为 54 个中 37 个）——它们以「名字+一句话+路径」的清单形态出现在 system prompt 的 Skills on hand 一节；
• 其余 17 个（11-04：56−39=17；10-17：54−37=17——巧合地同为 17）（如 muse_db、self-awareness、wide-research 的同类）不进 prompt，只能靠 muse.skill_search 找到。找不到时 prompt 明文禁止直接下「做不了」的结论，必须先搜技能、再搜连接器、最后才准说不可用；
• 还有第三级：用户偏好技能。muse.set_preferred 把用户指定的技能/连接器钉为某类任务的首选，条目会带 preferred 标记恒显于清单（偏好登记经 muse.offer_preference 节流：同类任务至多主动问一次，完成一次真实下单/预订才算数，搜索报价不算）。

2.3 SKILL.md 正文长什么样

• 全库正文合计 296,621 字节（11-04；10-17 为 275,274），单篇自 1.5KB（subscription-status）至 33.1KB（shopping）不等（11-04 全量重测；附录 A 的 SKILL.md 大小列除 ▲ 2 行外为 10-17 快照，当时为 1.2KB style-tryon / 21.8KB shopping——两端点都变了，shopping 正文明显扩充）；正文是给模型的作业规程，不是给用户的说明书：含决策树、先后顺序、禁用话术、失败处置、与相邻技能/连接器文档的相对链接。典型结构如 shopping：先定属性再搜索 → 多源并行 → 呈现规范 → 结账纪律。
• 引用文件按相对路径解析到技能目录；正文里嵌的命令模板即子层④的调用样例（如 shopping 内嵌 catalog-search 的两版命令，靠 HTML 注释标记 catalog-search-v1-only / v2-only 做版本门控——技能文档本身带特性开关）。
• 本地修订（amendment）机制：用户级修订文件与系统技能并置读取；若系统技能自上次审阅后已变更，应用修订前须先比对——防止旧补丁压新正文。

2.4 选择与执行纪律（system prompt「Skills」节）

决策顺序写死：① 读 prompt 清单的短描述，明显命中就读其 SKILL.md 并照做 → ② 多个可能命中选最具体的 → ③ 清单没有就 muse.skill_search → ④ 仍没有则用 shell/浏览器现做，并把可复用流程沉淀为自定义技能（模板在 custom-connector-setup/templates/skill/）→ ⑤ 全部落空才准说能力不可用。

2.5 技能不全是文本：带资产的少数派

即技能层允许「文本规程 + 随附脚本/模板」的混合包，但执行脚本仍要走工具层的 exec/二进制通道，技能本身没有独立的执行权限。

2.6 学到的技能（learned skills）

• 每日 Skill review 流水线（主报告 §12）把高频流程沉淀到 ~/workspace/custom-skills/，其 skill.yaml 标记 learned 来源；本机现有 1 个：recovered-skill-notes（标注为「从旧布局保留、待审阅的本地技能笔记」）。
• 回答「这个技能谁写的」之前必须查它的 yaml 标记——系统技能、学习技能、用户手写技能在清单里长得一样，来源不同。

2.7 一个镜像细节

/opt/muse/skills/ 与 /opt/hatch/workflow-skills/ 是同一棵树的两个路径（实测同 inode、同内容）——前者是给模型侧的视图，后者是给 runtime-cell 渠道门控（workflow-skill-scopes.conf）的视图。技能在「内容侧」与「运行时侧」的双面性在这里物化。

3. 子层③：连接器（Connectors）

3.1 解剖：一个连接器 = 三类文件，分工泾渭分明

/opt/hatch/connectors/<id>/
├── connector.yaml   ← 对模型/目录的自述：身份、别名、域、连接与同步声明
├── CONNECTOR.md     ← 给模型的操作手册：命令全集、用法、错误处置
├── manifest.yaml    ← 给运行时的策略书：OAuth、配额、动作权限（模型不靠它操作）
└── references/      ← 少数连接器有（如 facebook_cli、spotify、threads）

以 Gmail 为全样本（下面三段均出自其真实文件，OAuth client 标识等配置值从略）：

connector.yaml（自述层）：

id: gmail
title: "Gmail"
description: "Search, read and count Gmail emails and attachments, draft, send, reply and forward with approval, and label, archive, trash or unsubscribe."
aliases: [gmail]
include_in_prompt: true      # 11-04：75 个中 26 个进 prompt（10-17 为 63 个中 23 个）
onboarding: true             # 11-04：75 个中仍为 9 个（10-17 为 63 个中 9 个）
domain: email
availability: { confidential_vm: true }
auth:
  authorize: "/opt/hatch/bin/hatch_gws_auth gmail authorize-url"   # 授权入口是一个命令
sync:
  fetch_kind: connector_sync_gmail
  cadence_minutes: 60
  read_methods: [users.messages.list, users.messages.get]
  content_hints: [email]

CONNECTOR.md（操作层）：命令分两档——快捷命令（+triage / +read / +send，首选）与原始 API（方法名分词 + --params JSON + --json body，用 schema gmail.<method> 现查入参）；并写死禁区（过滤器/设置类命令不存在，问了也要答不可用）、多账号规则（--account <account_id> 全程一致跟随）、scope 不足时的精确补授权流程。

manifest.yaml（策略层，信息密度最高）：

• metadata.visible_in_settings、分类、图标、多账号后端（multi_account.backend: oauth、credential_namespace: google_oauth_accounts）；
• OAuth 配置：provider、identity 端点与显示名字段、可达域名 allowlist（gmail.googleapis.com 等 Google 全家桶域）；
• 请求配额：request_quota.mode: enforce，指定执行 worker（hatch-gws-cli-fully-isolated），总量 6,000 units/分钟/用户，并给出逐方法单价表（如 drafts.send=100、messages.get=20、labels.list=1）——配额是按「方法成本」而非「请求次数」计的；
• 动作权限：actions.read.default: allow（且带 response_guard: verification_codes——读邮件的结果要过验证码守卫，受保护读取的 manifest 出处）、actions.write.default: ask，逐方法声明 requires_scopes 与审批策略，如发信为 approval_policy: fresh_consent_or_task_allow + approval_phrase: "send this email in Gmail" + 按钮文案（allow_once: "Send" / deny: "Don't send"，reply/reply_all/forward 各有变体）——审批卡的文案与策略是 manifest 数据驱动的，不是写死在代码里的；
• 权限解析规则（docs/connectors.md）：方法级 default 覆盖动作组 default；Ask 须审批、Deny 直接拦；动作用权限与 OAuth scope 是两套独立系统（前者在 Muse 设置里，用户可「允许读、禁止发」）。

3.1.x 动作权限分布普查：Gmail 是常态还是特例？（实测：2026-11-04 本机 73 份 manifest 机器解析）

§3.1 用 Gmail 解剖了动作权限三态，但一个样本回答不了分布。本轮把全部 manifest.yaml 机器解析一遍，口径如下（⚠️ 快照时效：11-04 的 75 个连接器口径；10-17 为 63 个）：

读出："读 allow、写 ask" 是 69% 以上的默认姿势（52/73 ask 写 + 69/73 allow 读），Gmail 是常态不是特例；deny 在动作组层是保留弹药而非现役配置；verification_codes 是唯一的 response_guard 实现——读出验证码的连接器（Gmail 读邮件）是少数派（12/73 动作组级），不是每家都有。

3.2 连接生命周期

目录可见（include_in_prompt / connector_search 可检索）
 → status 本轮实查（绝不信记忆：状态命令如 `facebook-cli me`、`spotify-api status`）
 → 未连接：贴运行时原样给的 connect_url（[Connect Gmail](...)），等用户完成 OAuth
 → 已连接：按 CONNECTOR.md 命令操作；403/scope 类错误 → status --for-command
   → scope_add_url 原样贴出，用户在同一账号下补授权后再重试（不许自拼 URL）
 → reauthorization_required：存量授权被 provider 永久拒绝——不重试、不说成临时故障，
   贴 action_url 的 Reauthorize 卡，用户重连后由其重发原请求（写操作永不自动重放）
 → 断开：disconnect_url 原样贴出；单账号移除走设置里的该连接器条目

连接状态在运行时侧有登记表：~/config/skills.yaml 的 entries（11-04 实测 63 条；10-17 为 52 条）逐个记 available / connected——11-04 快照有 4 条 connected：gmail、google_forms、google_slides、meta_ads（10-17 仅 meta_ads 一条），其余 59 条 available 未连接。（连接状态随时可变——这正是本节要求每次任务前 status 实查的原因。）这是「文档里有 75 个连接器」与「这台机器现在真正能用的外部账号」之间的真实差距，也是为什么每个连接器任务都必须先 status 实查。

未进该登记表的连接器（如设备型 apple_healthkit / google_health_connect、免登录的 meta_catalog_search、places、tailscale 等）走各自的原生通道，不经 OAuth 登记——连接器层内部并不统一，这点从文件存在性就能看出（places 与 tailscale 甚至没有 manifest.yaml，只有两件套）。

3.3 同步子系统：连接器不只是 API 代理

75 个中 10 个声明了后台同步（11-04；10-17 为 63 个中 9 个；connector.yaml 的 sync 段）：

同步只用 read_methods 白名单里的方法增量拉取，content_hints 标注内容类型；产物落入运行时 DB（runtime 的 device_syncs / chat_deliveries 等表）与本地索引——这是记忆检索、Feed 素材、主动消息能「知道」邮箱/日历里发生了什么的来源。设置里另有 Background sync 开关决定后台工作可否使用该连接器（docs/connectors.md）——同步 ≠ 授权后台使用，又一处分权。

3.4 其他门控

• 区域可用性：受限连接器在受限账号下 Settings 无行、清单无条目、命令一律以「你所在区域不可用」拒绝；这是设计状态，禁止重试、禁止承诺上线。
• VM 类型：availability.confidential_vm 逐个声明；反例是 Shopify——docs 明文其在机密 VM 上不可用。
• 常开例外：Meta Catalog 免登录、无状态检查、永远在线（权限三档 Allow/Ask/Deny 在设置里，Ask 时同一任务首次搜索弹一次批）。
• 核心规则（docs/connectors.md 开篇）：「连接器只给文档里写明的命令，不多一个。」命令不存在 = 功能不存在，准确回答就是「该连接器不支持」，禁止拿浏览器或其他连接器冒充补位（跨平台代发只在各连接器各自文档明写时才存在）。

4. 子层④：CLI 二进制（执行体）

4.1 规模与形态（实测）

• /opt/hatch/bin/ 共 114 个条目、90 个独立 inode（11-04；10-17 为 101/84）；唯一的大家族仍是 Rust multicall——现为 20 个名字共 inode（新增 builtin-artifacts、imap-email），大小约 45MB（实测 46,954,944 字节；10-17 为 34MB/18 名）；其余多为单体二进制（12–49MB 不等）与主程序 hatch（00 篇 11-04 实测 540MB；10-17 为 470MB）。新增的 13 个条目（11 个单体 + 2 个归入 multicall 家族）：agoda、expedia、gumroad-mcp、hatch_igd_cli、instacart、moneyforward-me、readwise-mcp、runway-mcp、shopback-mcp、vidiq-mcp、zbar-lib，以及 multicall 家族的 builtin-artifacts、imap-email（恰好与新增的 12 个连接器对应，外加 hatch_igd_cli、zbar-lib 两个非连接器二进制）。
• 命名即接口：连接器 id 与二进制名基本一一对应（gmail → hatch_gws_cli gmail …、多服务共用一个多路 CLI 是 Google Workspace 的特例：gmail/calendar/drive/docs/sheets/slides/forms/tasks/contacts 共用 hatch_gws_cli + hatch_gws_auth）。
• CLI 契约高度统一：JSON 输出、统一错误信封、--help 自述、schema <method> 自省（gws 系）、快捷子命令前缀 +。这种统一不是巧合——它们出自同一套 Rust 工具 SDK（hatch-tool-sdk，strings 可见其 stefi/privsep/media_artifact 等模块）。

4.2 与 privsep 的对应关系（实测交叉表）

这张表是能力层「预置 ≠ 可见 ≠ 可用」三级状态的物证：二进制在宿主预置（provisioned）→ 按渠道显露进 cell（revealed）→ 账号连接且权限满足才真正可用（usable）。

4.2.x MCP 预置套接字的威胁面（实测 + 推断）

评审追问：*-mcp.sock 宿主侧预置的代码是否构成攻击面？本轮实测数据（2026-11-04）：/run/hatch/privsep/ 下 149 个套接字（10-17 为 136），其中 *-mcp.sock 40 个（当时约 30 个）；宿主 /opt/hatch/connectors/ 里只有 5 个 MCP 连接器有文档三件套（gumroad_mcp、readwise_mcp、runway_mcp、shopback_mcp、vidiq_mcp），其余 35 个 socket 对应着没有任何本地文档的宿主侧服务。

三层事实拼出威胁模型（证据等级逐层标）：

1. 真正拦住直接 dial 的是文件权限，不是渠道门控（✅ 实测）：149 个 socket 全部 srw-rw---- nobody root——只有 uid nobody 或 root 组成员能连上。cell 内进程若想绕过"渠道未显露二进制"直接 dial socket，面对的是文件 ACL 的硬墙；渠道门控只是纵深第二层。这回答了评审的问题：门控不阻止 dial，权限位阻止。
2. 残留 ❓：本机未验证每类 cell 侧进程（工具进程、exec 沙箱子进程）的实际 uid/gid 是否落在 root 组之外——若某类进程恰在 root 组里，ACL 墙就对它不存在。
3. MCP worker 本身的隔离（⚠️ 推断）：privsep 的 worker 账号隔离（主报告 §7）意味着一个有漏洞的 MCP worker 的爆炸半径被收敛到其 worker 账号；但"被攻破的 worker 能否借 socket 对其他 worker 或宿主做什么"在本机无证据——MCP 是外部代码形态接入（§6 的 mcp_client.py 模板），供应链面比自研 CLI 更宽，这是值得单独审计的一面。

一句话：宿主侧预置 ≠ cell 可达——socket 权限位是第一道真实的门，渠道显露是第二道；真正没被回答的是"每类 cell 进程到底站在门的哪一边"。

4.3 速率与失败语义

• 运行时级：429 / connector_rate_limited / 限流型 403 一律停该 provider 域；terminal_for_attempt=true 本轮终局；禁止换端点、降速、委托子 Agent 续跑（system prompt「Service limits」节）。
• manifest 级：§3.1 的 manifest 声明 request_quota.mode: enforce 并给出逐方法 units 成本表（⚠️：enforce 的实际执行点未在本机实测，依架构推断在 privsep worker 侧）。若推断成立，则与运行时级限流形成两层叠加：一个防滥用行为、一个防打爆 provider 配额。
• 失败报告纪律：只报工具实际返回的原因；不确定是否生效的不可逆操作（已发出的请求超时等）必须先查实际结果，禁止盲目重试。