Muse 智能体 · 能力层详解

本篇目录

1. 0. 什么是「能力层」
2. 1. 子层①：工具命名空间（Tools）
3. 2. 子层②：技能（Skills）
4. 3. 子层③：连接器（Connectors）
5. 4. 子层④：CLI 二进制（执行体）
6. 5. 横切机制 A：发现与选择（一次任务的完整路径）
7. 6. 横切机制 B：扩展（能力层是可生长的）
8. 7. 能力层的边界清单（「不能」也是架构的一部分）
9. 8. 关键计数对照（11-04 vs 10-17）
10. 附录 A：系统技能全表（56，按 category；11-04）
11. 附录 B：连接器全表（75；11-04）
12. 附录 C：二进制分组（114 条目 / 90 独立文件；11-04）

复核修订：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 配额。
• 失败报告纪律：只报工具实际返回的原因；不确定是否生效的不可逆操作（已发出的请求超时等）必须先查实际结果，禁止盲目重试。

---

5. 横切机制 A：发现与选择（一次任务的完整路径）

以「帮我看看 Gmail 里有没有某供应商的发票」为例，能力层的标准流水线：

1. 意图命中 prompt 清单中的 email-management 技能（include_in_prompt）
   → 读 SKILL.md：定邮箱、定检索口径、发送须审批等规程
2. 技能指向 gmail 连接器 → 读 CONNECTOR.md（命令手册）
   → muse.connector_search 只在「不知道用哪个服务」时才需要
3. 状态实查：hatch_gws_cli gmail status → 未连接则贴 connect_url 等用户
4. 加载工具面：exec 直调 CLI（或先 load 对应工具命名空间）
   → 经 privsep 的 hatch-gws-cli-fully-isolated worker 执行
   → manifest 配额扣 units；read 动作 default allow 直接过
5. 若要转发发票：write 动作 default ask → manifest 的审批策略生成审批卡
   → 用户点 Send 才执行；内容改动须重新给用户看再送
6. 任务完成且属首次成功：offer_preference 至多问一次「是否设为邮箱首选」

任何一步落空都有既定退路：技能没有 → skill_search → 现做并沉淀新技能；连接器没有 → custom_connector_setup 建自定义连接器（§6）；命令不存在 → 如实说不支持。

6. 横切机制 B：扩展（能力层是可生长的）

6.x 自定义连接器的信任边界：文档写得了什么、写不了什么

§6 的表格说自定义连接器"凭据走安全流"，但没回答评审的尖锐问题：用户可写的 CONNECTOR.md/connector.yaml 能否声明超出其应有权限的动作（比如把某个高危方法标为 read）？答案是结构上不能——不是政策禁止，是没有地方写（✅ 脚手架模板实测）：

1. 模板里根本没有权限声明面：templates/connector/connector.yaml 只有 id / title / description / include_in_prompt / require_auth 五个字段（全为注释模板，实测原文）——没有 actions、没有 manifest。自定义连接器不产生 manifest.yaml，因此"把文档声明标成 allow 就能绕过审批"这条路不存在：审批策略的数据源（系统连接器的 manifest）自定义连接器根本没有。
2. 凭据不在文档里：连接经 credentials.request_api_access 注册并持有凭据；helper 拿到的是 hsurr: 替代符，运行时只在"已批准的请求 + 已注册的 host"上换回真凭据（模板 CONNECTOR.md 明文，✅）。用户在 workspace 里能改的是"怎么调"，不是"凭什么调"。
3. 客户端侧有硬约束（模板 mcp_client.py 实测）：PROVIDER 必须以 custom. 开头、端点固定 HTTPS（禁重定向、禁非 443 端口、URL 里禁用户名/密码/query/fragment）、ALLOWED_TOOLS 白名单——脚手架把"只能调注册过的固定端点"写成了代码，不是写成了约定。
4. "文档声明 ≤ 运行时策略"的单向约束因此是构造性的：系统连接器的策略投影面（manifest）与自定义连接器的文档面是两套不相交的东西；自定义连接器的权限天花板由凭据注册时的授权 + 运行时审批决定，本地文档只能往下收（require_auth 隐藏、文档里少写命令），不能往上加。

诚实标注：~/workspace/custom-connectors/ 本机暂无（✅ 实测：目录不存在）——以上是模板与技能文档的证据，没有活的自定义连接器可验证其审批行为，记为 ⚠️（未实测执行面）。

这与 §7 第 6 条合起来：本地修订/自定义扩展覆盖不了系统安全策略——对自定义连接器而言，覆盖的靶子（manifest）本来就不存在。

7. 能力层的边界清单（「不能」也是架构的一部分）

1. 文档未写的命令不存在——包括连接 Facebook 不能发图/视频帖、Spotify 连接器不提供听歌历史这类「接了也不等于全能」。
2. 技能不授予权限、连接器文档不授予权限、偏好不授予权限——权限只有用户消息与审批卡两个来源。
3. 渠道/区域/VM 类型三重门控可在任何一层把能力关掉，且关闭形态各异（清单无条目、命令拒绝、CVM 专用 worker 拒绝），Agent 必须按实际返回解释，不许归因于「故障」。
4. 配额与限流是硬停：到达即止，报告部分进展，不许绕行。
5. 同步是只读白名单：连接器的写能力永远不经同步通道，写必须走命令 + 动作权限 + （必要时）审批。
6. 本地修订/自定义扩展不能覆盖系统安全与审批策略：manifest 的动作权限与配额在 worker 侧执行，不在模型可改的文件里（自定义连接器目录在 workspace，但其凭据与执行仍经安全流与 privsep）——这正是 manifest 作为 Control 平面在能力层的策略投影：策略以 manifest 数据形态下发，执行在 worker 侧，两者分离。

---

8. 关键计数对照（11-04 vs 10-17）

本轮重测（2026-11-04，side chat / web 会话）与初版（2026-10-17）实测值对照。未重测项不列入。

附录 A：系统技能全表（56，按 category；11-04）

见下表（由 skill.yaml 实测生成；「prompt」列 = include_in_prompt，11-04 全量复测无变化；▲ = 11-04 新增 2 个；SKILL.md 大小列除 ▲ 2 行外为 10-17 快照）。

附录 B：连接器全表（75；11-04）

见下表（由 connector.yaml 实测生成；「同步」列为 cadence 分钟数，无则 —；▲ = 11-04 新增 12 个；旧行的 prompt/引导/同步三列已 11-04 全量复测，与 10-17 快照无变化）。

附录 C：二进制分组（114 条目 / 90 独立文件；11-04）

见下表（由 inode 分组实测生成；同组 = 同一文件多个名字；▲ = 11-04 新增）。

A. 技能清单

B. 连接器清单

C. 二进制分组（同 inode 一组）

多名组（1 组）：

• authdc, avatar-media-generation, browser-service, builtin-artifacts▲, device-data, edits, feature-request, geocode, hatch-multicall, image-search, imap-email▲, media-generation, media-library, muse-mail, privsep-test-fully-isolated, share, shopping, subscription-status, tts, web-search — 约 45 MB（实测 46,954,944 字节；11-04；10-17 为 33.1 MB / 18 名）

单名二进制（94 个；11-04。10-17 为 83 个；原表误将 subscription-status 同时列入多名组与单名，11-04 订正为只归多名组）：

▲agoda, aftership, asana, box-cli, browser-broker, calendly, canva, dropbox, duffel, etsy-cli, evernote, ▲expedia, facebook-cli, figma, flightaware, function-health, genui-display-render, ghl, github, granola-cli, ▲gumroad-mcp, hatch, hatch-browser-lease-helper, ▲hatch_igd_cli, hatch-connector-output, hatch-doctor, hatch-execd, hatch-healthd, hatch-rescue, hatch-rescue-systemctl, hatch-rescuectl, hatch-slide-style, hatch-vault, hatch-ws-client, hatch-zeitgeist, hatch_gws_auth, hatch_gws_cli, hatch_messenger_cli, health-cli, healthex, healthkit-cli, ingress-rev-proxy, ▲instacart, instagram-cli, instagram-messages-cli, klaviyo, linear, local-search, lovable, meta-ads-cli, meta-catalog-search, ▲moneyforward-me, native-comms-cli, notion-cli, nutrition-cli, onepassword, opentable, outlook-calendar, outlook-contacts, outlook-mail, peloton, philips-hue, pickup-briefing-animation, places, plaid, printify, quickbooks, ▲readwise-mcp, remote-storage, replit, ▲runway-mcp, save-to-spotify, shop-wallet-cli, ▲shopback-mcp, shopify, shopify-ucp-cli, slack, spawnd, spotify-api, stripe, stripe-link, tailscale, tessie-api, threads-cli, threads-messages-cli, ticketmaster, todoist, vercel, ▲vidiq-mcp, wearables-display, withings, zapier, zoom, ▲zbar-lib