通知投递矩阵
本页在文档构建时由固定版本的宿主能力表 amp-0.0.0-20260907001852-gf348fed.json、claude-2.1.260.json、codex-0.147.0.json、cursor-2026-08-28.json、portable-1.0.0.json 渲染而成。这些 JSON 文件是每个目标适配器编译时依赖的唯一事实来源；请修改它们而不是本页。表格内容保留英文原文。
通知是与项目状态共同挂载、以日志为底的通知账本中的一条记录（保留的存储 id 为 @agent-bundle/runtime/agent-notice-ledger/v1）。它面向一个接收者，并且只会经历有证据的状态——pending、attempted、acknowledged、expired、unavailable、withdrawn；已结束的终态通知会按项目的 notices.retention 策略被清理、日志被压实，因此历史是有界的，而非永久保留。投递通过下列通道尝试，生成的 MCP 服务器只在宿主宣告了某条跨请求路由时才接线：按接收者限定的收件箱资源 agent-bundle://notices/inbox 会为宣告 mcp-inbox 的宿主（所有内置宿主）上的有状态项目注册；只有当宿主还宣告了 mcp-resource-updated 且 state 生命周期为工作区持久时，才提供 resources/subscribe 以及每条新近可用的待处理通知一次 notifications/resources/updated——它以可用性回执记录在账本上，绝不是投递声明。没有受支持的通道时，绝不声称已投递到宿主。
接收者轴
接收者是它所命名的各个已观测身份轴的合取：出现的每个轴都必须与准入请求匹配，请求无法观测到的轴永不匹配。conversation 与 root 读取自请求的 lineage，因此能定向到单个代理线程——或某个根之下的全部线程——这是 session 做不到的：在 Claude 和 Codex 上，每个子代理的钩子都携带根 session_id，而以 conversation 定向的通知绝不会在兄弟代理的事件上被准入。任何固定宿主都没有推送通道，因此定向到某个会话仍然意味着发布，然后在该会话的下一个事件上准入。
发布者视图
接收者永远看不到其他接收者的通知，发布者也不会获得接收者视图。发布者得到的是 notices.published()：其自身主体发布的通知，涵盖所有状态并附带回执。publish() 会把发布请求观测到的身份轴记录在通知上（publisher：actor、host、session、workspace，以及来自 request.lineage 的 conversation）；当读取方解析出相同的谱系会话时即为发布者——因此发布通知的钩子与发起查询的 MCP 工具调用即便宿主名、会话 id 与 cwd 各不相同也能对上——若发布者记录时没有谱系，则要求记录的每个轴都匹配。该视图不会在账本上记录任何内容，按通知逐条经授权阶段 published 判定，并且只在默认的 internal 上限下披露内容（internal 经过密钥脱敏，public 按原文，secret 为占位符）。由未观测到任何身份的请求发布的通知不属于任何视图。
投递通道
敏感度上限
每条通知都带有作者声明的 sensitivity——public、internal（默认）或 secret。受支持的通道会声明它能完整承载的最高敏感类别，并附上该上限的带日期证据；未声明上限的通道接受 internal。高于通道上限的通知会被该通道拒绝，且拒绝会记录在通知上；internal 内容在离开存储前会经过运行时的密钥脱敏（flare-redact，@agent-bundle/runtime 精确锁定版本的依赖；每处命中整体替换为 [REDACTED]），public 内容按作者原文传递，secret 内容仅在通道允许时按原文传递。