Muse 智能体 · 推理与模型消费层详解（原"模型层"）

本篇目录

1. 0. 一句话模型层
2. 1. 模型家族与分面（文档口径）
3. 2. 权威来源：当前模型是谁、谁说了算
4. 3. 推理不在本机（实测）
5. 4. 代理路径与协议痕迹（strings 实测）
6. 5. 流式生成与状态机痕迹
7. 6. 上下文窗与压缩
8. 7. Token 计量落表
9. 8. 模型选择与路由：已知与未知
10. 9. 本机看不见的部分（边界声明）
11. 10. 本层实测快照（11-04 重测；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 旧数随行标注）