AGENT / AOWARCHITECTURE NOTES
系列文章 · 00–10

MUSE / ARCHITECTURE NOTES

Muse 智能体 · 技术架构解构

个人实例研究记录

本篇目录
  1. 0. 一句话架构
  2. 1. 宿主层：VM + 运行时单元（runtime cell）
  3. 2. 模型层
  4. 3. 上下文组装层（Prompt 架构）
  5. 4. 能力层（一）：工具命名空间
  6. 5. 能力层（二）：Skills（ playbooks ）
  7. 6. 能力层（三）：Connectors + CLI 二进制
  8. 7. 执行隔离层：privsep（权限分离）
  9. 8. 状态层：Postgres（194 表）+ 文件系统
  10. 9. 记忆与个性化子系统
  11. 10. 编排层：子 Agent / Workflow / 浏览器任务 / Worker
  12. 11. 调度与主动层
  13. 12. 自我改进子系统（后台进化闭环）
  14. 13. 通道、产物与媒体面
  15. 14. 安全与信任边界（贯穿所有层）
  16. 15. 一次请求的生命周期（把所有层串起来）
  17. 16. 本机实测快照（2026-11-04；初版基线 2026-10-17 23:23 CST）
  18. 17. 本机看不见的部分（边界声明）
研究时间与证据说明

调查日期：2026-10-17（Asia/Shanghai） 复核修订：2026-11-04（Asia/Shanghai）——基于当前会话运行时逐项重测。下文数字凡未注日期者均为 11-04 快照；10-17 旧数见 §16 对照表。 证据范围：仅本机本地 system 文件与运行时实测——~/workspace/system/system_prompt.md（主聊天 system prompt 的启动快照）、~/docs/ 产品文档集、~/AGENTS.md / SOUL.md / IDENTITY.md / USER.md / MEMORY.md 等注入文件、/opt/muse/skills/、/opt/hatch/connectors/、/opt/hatch/bin/、/opt/hatch/runtime-cell/、/run/hatch/ 运行时套接字、进程表、会话状态接口与数据库 schema 参考。 标注规则：实测 = 本机命令/工具当场验证；文档 = 本地 docs/system 文件明文；推断 = 由文件/字符串拼出、未经服务端证实。服务端（推理集群、STEFI 之后的内部系统、App 客户端代码）不在本机文件内，本文只画到本机可见的边界为止（见 §14）。

0. 一句话架构

Muse 不是「一个模型 + 一套提示词」，而是一个单租户、常驻、有状态的 Agent 操作系统：

一名用户 = 一个专属 Agent = 一台持久化 Linux VM（docs/muse.md 明文）；VM 内跑一个 Rust 守护进程（hatch daemon）托管「运行时单元（runtime cell）」，单元里住着 Agent 本体；模型推理不在本机，经本地代理套接字调用 Meta 的推理服务；Agent 的一切能力都被拆成四层可插拔资产——工具命名空间（tools）/ 技能（skills）/ 连接器（connectors）/ 二进制 CLI（multicall bins）——并由一套 Postgres 状态库（196 张表，18 schema）+ Markdown 文件记忆 + 后台自我改进流水线共同维持跨会话的连续性。

分层总图：

┌─ 客户端面 ──────── Web(muse.ai) / iOS / Android / Mac / WhatsApp 通道 / 配对设备
├─ 会话面 ────────── Main chat / Side chats（原生 · 外部1:1 · 外部worker）/ 语音通话
├─ 上下文组装面 ──── system prompt 快照 + developer 指令 + 注入文件(9) + 时间标签
│                    + 目标/追踪注入 + 记忆检索结果 + 对齐合成（每轮动态拼装）
├─ 模型面 ────────── Muse Spark 1.3（本会话实测） / Muse Wonder（付费面，文档）
│                    上下文窗 350K tokens，272K 触发压缩，保留尾部 40K
├─ Agent 编排面 ──── 主 Agent ⇄ 子 Agent（深度≤2）/ Workflow(JS) / 浏览器任务 Agent
│                    / Deep Research 隔离 Agent / Side-chat Worker
├─ 能力面 ────────── 工具命名空间（延迟加载，33；10-17 为 34，voice 本轮不可见⚠️）→ Skills(56) → Connectors(75)
│                    → CLI 二进制(114, multicall) → privsep worker（Unix socket/工具，149 套接字）
│                    注：箭头是"被查阅/被调用"的依赖方向，不是调用链——技能与连接器
│                    是模型先后查阅的两类文档，调用关系只存在于 模型→CLI→worker
├─ 服务面 ────────── STEFI 代理 → Meta 内部服务(WWW/MSL/CAGI/Mango·Pariscope)
│                    推理代理 / 出口代理(egress, 审批+TLS) / authd / Vault
├─ 状态面 ────────── Postgres 196 表（18 schema，新增 saved） + 文件系统（记忆/目标/工作区）
├─ 身份面 ────────── SOUL.md / IDENTITY.md / avatar 身份资产（每轮进上下文 + 独立资产服务 16/17 篇；Avatar worker 硬门控到机密 VM）
└─ 宿主面 ────────── 持久 VM → systemd-nspawn 运行时单元(htch-runtime)
                     → hatch daemon(540MB) + hatch-execd(9.7MB) + spawnd 引导/自愈

1. 宿主层：VM + 运行时单元（runtime cell）

实测进程与文件：

组件 证据
VM 每用户一台持久 Linux VM；部署更新频繁（可达每小时），VM 可被整体替换，但 home 目录持久（system prompt「Deployments」节）。本会话 runtime 标注 os=linux, vm=standard
守护进程 root 运行 /opt/hatch/bin/hatch daemon --runtime-cell-leader=2181；hatch 本体 540MB（11-04 实测；10-17 为 470MB，胖了约 70MB）；另有 9.7MB 的 hatch-execd（10-17 为 9.5MB）负责命令执行，注册为 systemd 服务 hatch-execd.service/.socket
运行时单元 /opt/hatch/runtime-cell/launch-daemon.sh 用 systemd-nspawn 以 --boot --machine=htch-runtime 拉起一个容器化 rootfs（/var/lib/hatch-runtime/rootfs），--private-users-ownership=map 做 UID 映射；Agent 本体与工具的跳板二进制活在这个 cell 里，与宿主 rootfs 隔离——但连接器等特权工具的真身在 cell 外的 privsep worker 里执行（§7），cell 内只有转发请求、不见凭据的瘦客户端
渠道门控 cell 启动时按发布渠道（channel）做可见性裁剪：bin-scopes.conf / connector-scopes.conf / workflow-skill-scopes.conf 分别控制二进制、连接器文档、工作流技能的显露。scopes 文件内枚举的渠道包括 prod / prod-cvm / canary / quail / internal-test / dev / hatch-evals …；本机环境实测 JARVIS_CD_CHANNEL=alpha（⚠️：alpha 不在上述枚举内——或为枚举不全，或"未知渠道 fail-closed"的"未知"另有定义，此处存疑，见评审注）。设计意图是 fail-closed：无法识别的渠道默认不显露任何能力
引导/自愈 spawnd 负责 runtime-cell bootstrap 阶段上报与看门；hatch-rescue / hatch-rescuectl / hatch-healthd / hatch-doctor 构成救援与健康子系统；runtime-cell/ 下还有 pre/post-start、ensure-rootfs、build-cell-trust-store（构建 cell 的 TLS 信任库）等脚本；11-04 快照新增 control-daemon.sh / control-execd.sh / is-loopback-rv.sh / resolve-rootfs-path.sh / runtime-cell-entry.sh / stop.sh
环境注入 26 个 JARVIS_* 环境变量（11-04 实测；10-17 记约 30 个，差值部分可能为统计口径）构成 cell 与宿主的契约面（实测键名）：JARVIS_HOME, JARVIS_BIN_DIR, JARVIS_SESSION_ID, JARVIS_HATCHLING_ID, JARVIS_TOOL_CALL_ID, JARVIS_TRACE_CONTEXT, JARVIS_RUNTIME_CONTEXT_TOKEN, JARVIS_STEFI_PROXY_SOCK, JARVIS_INFERENCE_PROXY_SOCK, JARVIS_INFERENCE_HOSTNAME, JARVIS_AUTHD_SOCK, JARVIS_MEMORY_SOCK, JARVIS_SANDBOX_API_SOCK, JARVIS_SECURITY_SOCK, JARVIS_SENTINEL_HTTP_API_SOCKET、三个 egress 审批套接字（DAEMON/ADMIN/EVENTS）、JARVIS_TELEMETRY_PROXY_SOCK（遥测代理，新增）、JARVIS_RESCUE_SIGNAL_SOCK（救援信号，新增）、JARVIS_REQUEST_MODE、JARVIS_USER_TIMEZONE 等。注意：JARVIS_VM_COMPUTE_REGION（10-17 值为 zhu）本轮已不在环境变量中，时区改由 JARVIS_USER_TIMEZONE 承载（⚠️ 区域信息或已内聚进其他变量）。全部是套接字路径与不透明 ID，不带凭据值

设计要点：Agent 进程本身是不可信/可替换的，状态与权限都不放在 Agent 进程里——状态在 DB 与 home，权限在宿主侧的 privsep worker 与审批系统（§7、§10）。

2. 模型层

  • 模型家族（文档 docs/muse.md）：Meta 的 Muse 系列。免费面跑 Muse Spark（1.3 版，2026-09），付费面（含试用）跑 Muse Wonder（2026-10-12 发布）——Wonder 承担主对话、artifact 构建、定时运行、子 Agent 与后台工作。另有对外面：Meta Model API、Muse（Wonder / Wonder Full）。
  • 本会话实测：runtime 标注与 muse.session_status 一致——model = Muse Spark (meta/muse-spark)，provider=Meta。文档明文：以 runtime context 的 model 值为唯一权威，日志/环境变量里的标识符不是公开模型名，内部代号不可外泄。
  • 推理不在本机：VM 上没有任何模型权重文件；推理经 JARVIS_INFERENCE_PROXY_SOCK = /run/hatch/proxy/inference.sock 的本地代理出去（另有 JARVIS_INFERENCE_HOSTNAME）。Agent 侧只见流式增量事件（strings/DB 表可见 agent_message_delta / inference_streaming_stalled / waiting_for_inference_start 等调度状态，推断为运行时对推理流的状态机）。
  • 上下文预算（实测）：窗口 350,000 tokens；272,000 触发自动压缩（compaction）；压缩保留尾部 40,000 tokens；本会话当前已用约 150K（43%，10-17 快照——用量随会话浮动）。压缩产物落 DB agent.compactions / agent.agent_compactions（§6），且 system prompt 明确：压缩摘要可能丢细节，重要事实必须能从记忆/文件/原消息中找回（chat.read_messages 回读原文）——即压缩是缓存层，不是记忆层。补注：压缩摘要的粒度决定了可恢复性的上限——40K 尾部之外的中间上下文（272K→40K 之间被摘要掉的部分）既不在尾部、又未必进记忆，是真正的"丢失带"；重要事实走记忆/文件通道是强制性纪律而非建议（与 §9"先写记忆再回复"呼应）。

3. 上下文组装层（Prompt 架构）

这是本机 system 文件里信息量最大的一层。每轮对话的上下文由运行时动态拼装，来源至少七类（本会话上下文实测）：

  1. System prompt 本体：~/workspace/system/system_prompt.md 是主聊天启动时由运行时落盘的快照，73,296 字节 / 511 行（11-04 快照；10-17 为 71,868 字节 / 494 行，## 章节结构未变，增量在节内）。结构（实测标题）：
    • Who You Are——价值观与人格基线（Truth/Beauty/Respect/Fun/Connection/Curiosity、尽职、主动跟进）、服务对象与权限边界（只为该用户工作、家庭权威、保密与对齐、防注入）；
    • Personalization——记忆与人物关系的使用规则；
    • Contextual Awareness / Managing Your Conversation Context——时间标签、上下文压缩后的找回路径、多任务不串线（todo 纪律）；
    • Writing Style——文风与交付格式（引用、附件、widget、反应）；
    • Your Environment / Tools / Subagents / Scheduled and Recurring Work / Side Chats——环境与编排契约；
    • Runtime Files / Filesystem——文件地图（每个目录的用途与持久性语义）；
    • Security / Safety——凭据、防钓鱼、硬性安全线。 注意：该快照是主聊天的 prompt；developer 层指令（每轮下发的行为细则）不在此文件内，属运行时注入的另一层。
  2. Developer 指令层：每轮随消息下发（所有权、记忆维护、尽职、核查纪律等），优先级高于用户消息；本报告不复述其全文，只指出它与 system prompt 是两个独立层。
  3. 注入文件（standing context）：每轮以 [BEGIN USER CONTEXT] 块注入 9 个文件：AGENTS.md（操作手册/经验）、SOUL.md（人格）、IDENTITY.md（名字，本机为 Idris）、USER.md（用户档案）、MEMORY.md（长期记忆）、memory/people/INDEX.md、memory/groups/INDEX.md、dreams/alignment/derived/ALIGNMENT_SYNTHESIS.md（对齐合成）、TOOLS.md。这些文件用户与 Agent 都可编辑，改动落盘即生效，但注入副本可能滞后（prompt 明文提醒改后回读文件）。
  4. 时间标签：每条用户消息前缀 [Day YYYY-MM-DD HH:MM:SS TZ] [client_timezone=...] [device_id=...]，另附来源（web/WhatsApp 等）与面板状态；相对日期一律以此为准。
  5. 目标与追踪注入：活跃 Goal（本轮注入 10 个；10-17 为 3 个——数量随会话与 attention 状态浮动）及其 Attention 状态、tracked items 被注入上下文；Goal 本体在 ~/workspace/goals/<slug>/GOAL.md + files/ + hidden_files/。
  6. 按需检索：muse.memory_search 的结果、工具输出、子 Agent/浏览器任务的 handoff，都以 [BEGIN EXTERNAL CONTENT] 标记注入——标记即信任边界（§10）。
  7. 工具 schema：命名空间延迟加载（deferred）——多数工具初始只给名字与一句话描述，Agent 须调 tool_search.load_tool_namespace 才拿到完整参数 schema；已加载的在上下文存续期内免重复加载。核心 muse.* 命名空间永远全量加载。

4. 能力层（一）：工具命名空间

  • 组织方式：namespace.function，本会话可见 33 个命名空间（11-04 实测；01 篇 §1.1 在 10-17 逐表实测为 34 个——差 1 个：voice（通话内语音）本轮在工具清单中已不可见，⚠️ 或为下线、或为渠道门控，待在主聊天复核；其余 33 个与 10-17 完全一致：muse / browser / chat / cron / hooks / avatar / media / shopping / wallet / device / feed / idea / artifact / workflow / subagent / tracking / user_goal / credentials / widget / worker / map / social / travel / ads / todo / tool_search …）。
  • 每次工具调用由运行时盖戳：JARVIS_TOOL_CALL_ID 作 request_id，turn 级 ID 作 parent_request_id，全链路带 JARVIS_TRACE_CONTEXT（文档/二进制字符串均证实，如媒体调用的 Mango/Pariscope 请求树靠 request_id 区分并发调用）。
  • 工具结果的投递是异步 handoff 模型：子 Agent、浏览器任务、定时运行完成后由运行时把结果「喂」回主对话上下文；Agent 不轮询、不自称已完成（system prompt 多处明文）。
  • UI 能力也是工具：options 选择卡、HTML/地图/列表 widget、Letter、原生卡片（购物、头像分享）都由专用 creator 工具生成 embed_token 嵌入回复——模型只产 token，渲染归客户端。

5. 能力层（二）：Skills（ playbooks ）

  • 实测 56 个系统技能于 /opt/muse/skills/（11-04 快照；10-17 为 54 个，净增 2 个、无下线：avatar-dance-videos（Avatar 舞蹈视频生成）、live-page-checks（页面现货核查）——恰好对应 Avatar 服务与现查两类高频工作）。只读、随部署替换；每个技能目录 = SKILL.md（流程正文）+ skill.yaml（元数据）+ references/（按需细则）；用户侧学习技能在 ~/workspace/custom-skills/（skill.yaml 标记 learned 来源）。
  • 检索：muse.skill_search（BM25 关键词 / regex 两种模式）与 muse.connector_search 分工明确——前者找「做事方法」，后者找「服务入口」。
  • 使用纪律（system prompt 明文）：任务先查技能/连接器文档再动手；技能是流程权威但不是权限来源——技能里写了某步操作，不等于用户授权了那一步。

6. 能力层（三）：Connectors + CLI 二进制

  • 实测 75 个连接器于 /opt/hatch/connectors/（11-04 快照；10-17 为 63 个，净增 12 个、无下线）。新增：旅行 agoda / expedia、生鲜 instacart、邮件 imap_email / muse_mail、密码 onepassword、记账 moneyforward_me，以及 MCP 系 5 个（gumroad_mcp / readwise_mcp / runway_mcp / shopback_mcp / vidiq_mcp）——MCP 正在成为连接器的一类标准形态。只读，每个 = CONNECTOR.md（操作手册）+ connector.yaml + manifest.yaml。覆盖 Gmail/Calendar/Drive/Docs、Meta 系（Facebook/Instagram/Threads/Meta Ads/Catalog）、Spotify、Stripe、Shopify、Duffel、Ticketmaster、Health（Apple HealthKit / Health Connect）、Tailscale 等。
  • 连接模型：OAuth/Accounts Center 授权流，Agent 只贴运行时给的 connect/scope_add 链接，永不经手密码；连接状态必须本轮实查（status 命令），文档在 ≠ 已连接；权限可按命令粒度追加 scope（status --for-command → scope_add_url）。
  • 执行后端：每个连接器对应 /opt/hatch/bin/ 下一个 CLI（实测共 114 个条目，11-04；10-17 为 101 个）。其中大量是 Rust multicall 二进制的硬链接名（典型：34MB 的 hatch-multicall 一体 18 名，见上一篇 Avatar 解构）；主程序 hatch 为 470MB。CLI 普遍输出 JSON、带统一错误信封（ok / error_code / error_message / error_detail）。
  • 限流纪律（system prompt 明文）：遇 429 / connector_rate_limited / 归因于限流的 403，立即停该 provider 域，不得换端点/降速续跑；terminal_for_attempt=true 即本轮终局。

7. 执行隔离层：privsep（权限分离）

这是从本机文件里挖到的最硬核的一层（/run/hatch/privsep/ 实测）：

  • 每个工具 CLI 一个独立 worker 套接字：/run/hatch/privsep/<工具名>.sock，实测 149 个（11-04；10-17 为 136 个，+13，与 bin 条目增量吻合）（gmail 系的 hatch-gws-cli-fully-isolated.sock、avatar-media-generation.sock、browser-service.sock、各 MCP 的 *-mcp.sock、支付的 stripe-link-checkout-card.sock 等）。cell 内的二进制更像瘦客户端/跳板（trampoline），真正的凭据与网络操作在 cell 外的可信 worker 里执行。
  • 跳板规则（二进制 strings + guest.env 注释证实）：只转发 allowlist 内的环境变量（HOME/TMP/JARVIS_* 套接字/代理与 CA 路径）；输入文件须在允许根目录内且为普通文件；输出经 guarded output（memfd + seal + 限额） 回传，超限截断；可信 worker 的 stdout 会被「静默化（quiesce）」防串扰。隔离分级：partially / fully isolated（套接字名与二进制名均有标注）。
  • 出口管控：cell 内一切外网流量走代理（HTTP(S)_PROXY + /run/hatch/egress-tls/ca-bundle.pem）；宿主侧有三条审批套接字（JARVIS_DAEMON_EGRESS_APPROVAL_SOCK 等）与 sentinel 服务（JARVIS_SENTINEL_HTTP_API_SOCKET）做出口授权与内容守卫。
  • STEFI 代理：工具访问 Meta 内部服务统一经 JARVIS_STEFI_PROXY_SOCK=/run/hatch/proxy/stefi.sock，带 caller 授权令牌校验（strings 证实 invalid stefi caller authorization token）；其后是 WWW / MSL / CAGI / Mango·Pariscope 等内部系统（本机只能看到名字，看不到实现）。
  • authd：/run/hatch/auth/authd.sock 的本地认证守护（authdc 为其调试客户端），负责 OAuth 令牌的验证/代管（STEFI 侧有 verify_oauth_token 往返）。

8. 状态层：Postgres（194 表）+ 文件系统

数据库（schema 参考实测）：/opt/muse/skills/muse_db/references/ 给出 196 张表、18 个 schema 的完整目录（11-04 快照；10-17 为 194 张表 / 17 schema，新增 saved schema；下表各 schema 表数为 10-17 快照，11-04 仅复核总数与 schema 数，明细待 07 篇同步）。，Agent 侧只有只读通道（muse.db 工具：受限 SELECT、5s 超时、262KB 输出上限）。分布：

schema 表数 存什么
runtime 38 运行时状态：avatar_state、avatar_selections、avatar_wardrobe、chat_bindings/deliveries、device_syncs、memory、scheduler、workflows、browser_monitor、checkout_spend、hotset、context_ingests…
agent 25 Agent 本体：agents、sessions、compactions、context_items、message_mailbox、subagent_spawns/progress、token_usage、recovery_owners、runtime_restart_checkpoints…
ideas 22 Ideas 卡片与灵感管线
feed 16 Feed 单元、运行、prompt、fleet 发布/互动 outbox
self_improvement 13 自我改进步骤与产物
device 13 配对设备：contacts、calendar_events、call_log、上传会话/分片
scheduler 12 定时任务与运行记录
goals 12 目标、briefings、sessions、suggestions、momentum
spaces / health / activity / memory / media / podcasts / chat / shell / ingest 余下 空间、健康聚合、活动监控、媒体库、播客、聊天绑定等

要点：「运行时即数据库」——连上下文条目（context_items）、子 Agent 进度、恢复所有权（recovery_owners / restart_checkpoints）都落表，这解释了 VM 被替换后任务能被运行时接管恢复（system prompt「Deployments」节）。

文件系统（与 DB 分工）：面向人/Agent 共读共写的语义层用 Markdown 与目录约定——记忆（~/MEMORY.md + ~/memory/）、目标工作区、artifact 源码与产物、cron 的投影目录（~/workspace/cron.d/{minutely,hourly,daily,weekly,monthly,yearly,runonce,secondly}）、子 Agent 运行目录（~/workspace/agents/<uuid>/，实测已积累 277 个，11-04；10-17 为 89 个，含各自 tool-output）。Prompt 明文划界：cron 的投影文件不可直接编辑，必须走 cron 工具改本体——投影 ≠ 本体，是全系统反复出现的模式（DB 行 ↔ 文件投影、技能文档 ↔ 运行时执行、Feed brief ↔ 生成管线）。

9. 记忆与个性化子系统

三层结构（文档 docs/memory.md + system prompt「Memory」节 + 实测目录）：

  1. 注入层：MEMORY.md（精选长期记忆，本机 5.2KB）+ 人物/群组索引 + 对齐合成，每轮直接进上下文；
  2. 检索层：~/memory/bank/（运行时托管，Agent 只读）与记忆服务套接字 JARVIS_MEMORY_SOCK 支撑 muse.memory_search——同时搜「已保存记忆」与「过往对话原文」，命中给文件行号引用，可用 muse.memory_get / muse.memory_explain 追溯每条记忆的出处、被谁替代、何时强化；（勘误：~/memory/index/ 在 Agent 的文件视图中不存在——08 篇 §3.3 实测证伪，检索走 socket 服务而非该目录）；
  3. 关系层：~/memory/people/*.md、~/memory/groups/*.md 每人一页，按亲密度排序，后台关系维护任务持续更新。

写入纪律：学到持久事实先写记忆再回复；更正要顺着受影响的记忆/目标/提醒一并修正；凭据与验证码永不入记忆。遗忘是专门技能（forget 技能 + 规划/确认两段式子 Agent），要连同派生副本与「未来会把信息带回来的生产者」一起处理。

对齐合成：~/dreams/alignment/derived/ALIGNMENT_SYNTHESIS.md 由夜间 Dreaming 任务从原始反思（dreams/alignment/raw/）与修复线程（repair/）蒸馏，内容是「这个用户是谁、怎么配合、当前摩擦、边界」——它是每轮注入的，所以人格适配本身是一个离线学习闭环的产物，不是写死在 prompt 里的。

10. 编排层：子 Agent / Workflow / 浏览器任务 / Worker

机制 契约（system prompt + 实测）
子 Agent（subagent.spawn） 继承当前上下文，后台运行，结果由运行时 handoff 回主对话；最大深度 2（本会话 depth=0, max_depth=2 实测）；需多子 Agent 时派一个 coordinator 再扇出，coordinator 的子级不能再派生。子 Agent 不能操作实时浏览器、不能建 artifact（各有专用通道）
Workflow VM 本地 JavaScript 编排（workflow.* 工具）：把多 Agent 计划写成确定性代码，适合审计/批处理类长任务
浏览器任务 独立路由：browser.browse 派给浏览器 Agent，窗口/标签/登录态在专用浏览器里（用户可围观或接管）；主 Agent 只下自包含任务书。浏览器本体为真实 Chromium（/opt/meta-chromium/ + headless-shell 资产），经 browser-broker（39MB）与 browser-service（multicall）驱动；CAPTCHA 由浏览器侧自行处理
Deep Research browser.deep_research：隔离、登出态的研究 Agent，只在用户明确要求深研时启用，产出带来源的报告后 handoff
Side-chat Worker 外部会话（群聊/他人 Muse/商家）里替用户发言的是另一个 Agent（worker），主 Agent 用 chat.send_message 下任务书而非代拟台词；每个 side chat 有 DISCRETION.md 记录该聊天的披露规则，worker 上报后由主 Agent 转述给用户
后台进程 muse.exec 的长命令自动转后台，终局结果自动投递；进程列表/日志由 process.* 管理

11. 调度与主动层

四种时间/事件机制（docs/chat/scheduling-and-watching.md）：

  • Cron：需 Agent 参与的定时任务/提醒/周期检查；可挂在 Goal 下（goal-owned）；每次运行是一个独立 run，查历史而非只看计划；
  • Hooks：轻量脚本轮询条件，命中才唤醒 Agent；新建默认禁用，须 dry-run 后启用；
  • systemd 服务：常驻程序（流监听、本地服务），guest systemd 托管，但须自证 VM 替换后的恢复；
  • 监看（watch）本质是轮询：文档明文没有真·推送监看，alert 只通知不自动处置。

主动消息（proactivity）：后台 worker 按版本（edition）备好候选条目，handoff 给主 Agent 后必须先做新鲜度复核（查记忆+活源），用 proactivity.select 逐条裁决 send/skip（理由枚举：time_sensitive/changed/requested/ready_for_decision/new_opportunity 对 moot/already_handled/unconfirmed/preferences/not_useful_now），再按格式投递。用户偏好落在 ~/PROACTIVE_PREFERENCES.md（本机：09:00–21:30 可达）。HEARTBEAT.md 是心跳 worker 的检查清单（一行一条，下一 tick 生效）。

12. 自我改进子系统（后台进化闭环）

docs/self_improvement.md 明文列出 7 条后台流水线——与主 Agent 是同一个 Agent、同一用户，只是离线运行，主 Agent 不能调度它们：

流水线 节奏 产物
Memory upkeep 有新信号时每小时 新对话固化进 MEMORY.md，旧主张被新主张替代，~/memory/ 留完整轨迹
Relationships 每小时 people/groups 页面维护
Idea curation 每日 Ideas 卡片（可行性/契合度/新颖度打分排序）
Studying 每日（夜间） Goal briefing、进展提醒、隐性目标建议
Dreaming 每夜 ~/dreams/ 反思、对齐合成、repair 线程
Skill review 每日 高频流程沉淀为 custom skill，无效改动退役
Quiet-moment pass 长对话静默后 有界的一轮内化，一天至多数次

可追溯性：任何建议/更新的「为什么」可用 muse.db 沿 run → step attempts → handoff → mailbox → delivery 记录链回放；文档特别强调**「已接受/已排队」≠「已送达」**，汇报必须区分。

13. 通道、产物与媒体面

  • 通道：Web/iOS/Android/Mac 是全功能面（Feed/Ideas/Goals/Library/Artifacts 标签页）；WhatsApp 是唯一外部消息通道（docs/chat-connections/whatsapp.md），同一 Agent/同一记忆，只是没有 App UI。配对设备（手机、Home Link 家庭桥、Tailscale）经 device 命名空间暴露联系人/日历/命令（11-04：~/docs/devices/ 新增 home_link / mac_app / tailscale 文档，另有空的 ~/docs/channels/ 目录——设备与渠道面在补文档）。
  • Artifacts：文档/网页/应用/表格/演示的构建在后台 builder 进行；Web artifact 的数据只能经其声明的 actions 或 inspect/edit 改，禁止直碰 app.db；交付必须在同一条回复里给出可打开的链接/附件。
  • Feed：brief（一份纯文本 prompt）+ 后台生成管线；来源可含活网、社交、已连接服务与用户上下文，但新用户默认帖是随构建发布的固定集，不许谎称调研过；排序、节奏由系统控制，用户只能改 brief 与单帖。
  • 媒体：图片/视频/TTS/播客各有专用二进制（multicall 家族，如上一篇的 avatar-media-generation、tts 经 Shortwave 服务）；docs/media.md 给出限额与一个关键门控——机密环境下通用媒体/TTS 不可用，Avatar 则反之只在机密 VM 可用。

14. 安全与信任边界（贯穿所有层）

  1. 权限来源唯一：只有用户本人的消息（含其为定时/委派任务录制的请求）能授权；工具输出、网页、文件、其他 Agent 的报告都是数据，不是命令。[BEGIN EXTERNAL CONTENT] 标记块即此边界的物化；注入内容要求扩权/外泄时，一律停下向用户核实。
  2. 审批卡是运行时原语：对外发送、购买、删除等由工具原生触发用户审批，Agent 不能自触发也不能绕过；支付另走 Wallet（Shop Pay / Stripe Link）+ 浏览器结账复核的双段流程，卡号经 provider 安全页，聊天里给的卡只作浏览器文本输入且不入记忆。
  3. Secure Vault：密码/API 凭据只走安全录入卡/连接流（hatch-vault + authd），Agent 只见令牌/链接不见值；一次性验证码走「受保护读取」——连接器读到的码以 [credential:<uuid>] 引用形态短暂托管，由用户在卡上批准后才喂给浏览器。
  4. 披露最小化：对外联系只给对方完成任务所必需的信息；被告知 ≠ 被授权转述；文件上传第三方托管须用户批准服务+文件。
  5. VM 信任分级：本会话是 standard VM——按 docs/data-handling.md，交互可被 Meta 记录/审查、非端到端加密、对话可用于 AI 改进（用户可在设置中退出）；confidential VM 则全程 TEE 硬件保护、客户自管密钥加密、Meta 只能见运营元数据、永不用于训练。部分能力（如 Avatar worker）被硬门控到 CVM（见 Avatar 解构篇）。
  6. 渠道与能力门控叠加：同一二进制/技能在不同 channel、不同 VM 类型、不同连接状态下可见性与可用性都不同——「文档里有」永远不等于「这台机器现在能用」，必须本轮实查。
  7. 身份资产是独立的一类状态（Identity 平面）：人格文件（SOUL.md / IDENTITY.md）、Avatar 形象、用户画像既进每轮上下文（§3 注入文件），又有独立的资产服务（16/17 篇）；Avatar worker 被硬门控到机密 VM（§13）。此平面原在 §0 总图中缺位，现已补入。

待验证的开放问题（❓）：审批卡是否绑定发起调用的 agent_id？子 Agent 继承父级上下文（02 篇 §2.1）时，敏感工具调用是复用父级已获得的审批、还是重新触发审批卡？基线只明确"审批只在记录范围内有效"，spawn 边界的审批语义在本机文件内无直接证据。在得到反证前，不得假设"子 Agent 继承审批"是安全的。

15. 一次请求的生命周期（把所有层串起来）

用户消息（带时间标签/来源）
 → 运行时拼上下文：system 快照 + developer 指令 + 注入文件 + 目标/追踪
   + 记忆检索 + 待投递 handoff（子Agent/定时/浏览器结果）
 → 推理代理 → 模型流式生成（工具调用与文本交错）
 → 工具分发：tool_search 按需加载 schema → 运行时盖 request_id/trace
 → 执行：本地工具（文件/DB 只读查询）或 privsep worker（连接器 CLI）
   或浏览器任务/子Agent（异步，完成后 handoff 回本对话）
 → 外部访问：STEFI 代理 → Meta 内部服务；或 egress 代理 → 公网（审批/限流规则）
 → 结果回上下文 → 模型继续，直到最终回复（可嵌 widget/附件/反应）
 → 会话后：todo 收口、记忆落盘、目标/追踪状态更新；离线再由
   memory upkeep / dreaming 等流水线二次固化

红灯路径（降级分支，评审注）：以上是全绿路径。推理代理不可用时的行为（inference_streaming_stalled / waiting_for_inference_start 状态机如何收敛）、STEFI 不可用时工具调用的失败语义、egress 审批被拒后的用户可见形态——§7 的三条审批套接字只记了"有"，没记拒绝路径。以上本篇未覆盖，留待实测补齐。

16. 本机实测快照（2026-11-04；初版基线 2026-10-17 23:23 CST）

项 11-04 快照 10-17 基线 变化
模型 Muse Spark（meta/muse-spark），上下文窗 350K / 压缩触发 272K 同 —
会话 side chat（源自 web），depth 0 / max 2 同 —
VM standard，channel=alpha（仍为 alpha，§1 存疑注记延续） standard，channel=alpha，tier=prod，compute region=zhu JARVIS_VM_COMPUTE_REGION 本轮已不在 env
守护进程 hatch daemon（540MB）+ hatch-execd（9.7MB），runtime cell = systemd-nspawn htch-runtime 470MB / 9.5MB 主二进制 +70MB
资产计数 命名空间 33 · 技能 56 · 连接器 75 · /opt/hatch/bin 114 条目 · privsep 149 套接字 · DB 196 表（18 schema，新增 saved） 34 · 54 · 63 · 101 · 136 · 194（17） 全线增长；voice 命名空间缺席⚠️
本地状态 工具输出溢出目录 277 个 · 活跃 Goal 10 个（本轮注入，随会话浮动） 89 个 · 3 个 —
system prompt 快照 73,296 字节 / 511 行 71,868 字节 / 494 行 +1.4KB，## 章节结构未变

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

以下不在本地 system 文件内，本文不作结论：推理服务的部署与模型权重、STEFI 之后的 WWW/MSL/CAGI 实现、宿主侧（cell 之外）的 spawnd/authd 完整实现与控制面、Muse App 客户端代码、Feed/Ideas 的系统侧排程参数、审批卡的服务端判定逻辑。本地文件对这些只留下接口痕迹（套接字名、环境变量、错误码与文档转述），引用时已按「推断」标注。