Muse 智能体 · 通道、产物与媒体层详解

本篇目录

1. 0. 一句话结论
2. 1. 客户端面：四端同体，差异在「面」不在「脑」
3. 2. 消息通道：WhatsApp（唯一外部通道）
4. 3. 语音面：三条互不相通的路
5. 4. 配对设备：device 命名空间
6. 5. Artifacts：构建与交付纪律
7. 6. Feed 管线面（附 Ideas）
8. 7. 媒体生成面
9. 8. 文件进出：Library / 附件 / 下载
10. 9. 串起来：一次跨通道交付的生命周期
11. 10. 边界声明

配套展开篇：本文是 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 的工具命名空间裁剪情况未查。