主动式 Agent 运行时与具身设备架构设计稿

版本 v0.3 ｜ 2026-11-04 ｜ 状态：架构扩展稿，待分阶段原型验证
基于：v0.1《主动式 Agent 运行时架构设计稿》、v0.2《主动式 Agent 运行时与具身设备架构设计稿》
本版重点：将 Agent 身份、控制平面、设备躯体、多设备连续性、人机控制权、自我状态、时间语义、能力生命周期、环境模型与行动后验证纳入统一架构。

---

0. 一句话

把工作的单位从「消息」换成「带生命周期的工作项」，把 Agent 所在设备视为它连接现实世界的躯体：硬件与软件能力通过统一的感知通道输入事件，通过受控的行动通道执行操作；运行时再以 持久账本 + 常开廉价感知 + 门槛式唤醒 + 隔离执行 + 离线巩固 为基础，让 Agent 能持续理解自己正在做什么、外部发生了什么、下一步该做什么，以及什么时候需要人介入。

核心结构：

设备是躯体，通道是感知器官和行动器官，模型是可替换的认知能力，运行时负责持续存在；Agent 的身份、记忆和任务不应绑定到某一台设备或某一个模型。

Sense（感知） → Event → Ledger / WorkItem → Gate / Salience → Worker
                                                        ↓
Action（行动） ← Policy / Scheduler ← Plan / Tool Call ←─┘
                                                        ↓
                                              Consolidation（巩固）

Agent 不等于某一台设备，也不等于某一个模型。 Agent 有稳定身份和持续状态；设备是它当前可使用的一个或多个运行载体。模型可以本地运行，也可以通过网络调用外部推理服务。无论模型部署在哪里，设备上的感知、权限、任务和行动都必须经过统一运行时管理。

---

1. 目标与非目标

1.1 目标

1. 用户不必「推一下才动一下」：系统知道在等谁、在等什么、什么时候该出声。
2. 新任务进入时，系统能判断它与现有任务的关系：续跑、分叉、建依赖、共享事实或另起，不把所有输入塞进同一个上下文。
3. 回复与主动通知由可审计的状态跃迁触发，而不是仅由用户发言触发。
4. 系统能通过设备和软件通道持续接收外部事件；用户不在当前对话中时，仍可完成被授权的工作并投递紧急通知。
5. 设备上的硬件、操作系统、应用和网络服务都能以统一接口注册为感知器或行动器。
6. 系统区分「看见了什么」「推断了什么」「被允许做什么」；感知到信息不代表获得执行授权。
7. 系统崩溃、断网、Worker 退出或重复收到事件后，能够从账本恢复，且不因重试重复产生不可逆副作用。
8. 自主学习从失败、验收、纠正和打扰反馈中产生，按可撤销程度逐层结晶。
9. Agent 身份与 Body 解耦；设备离线、更换或新增时，持久任务和记忆仍能正确延续。
10. 人与 Agent 对共享设备拥有明确的控制权仲裁、资源租约和紧急停止机制。
11. Agent 能感知自身计算、存储、网络、通道、认知服务和预算状态，并按策略降级。
12. 系统正确处理跨设备时钟偏差、事件迟到、乱序和环境状态变化。
13. 关键行动必须验证外部结果，而不能把「工具调用成功」等同于「目标达成」。

1.2 非目标

• 不做模型永动：不追求模型 24 小时连续生成思考。常开的只应是低成本采集、过滤、匹配和健康检查；复杂推理按需唤醒。
• 不默认开启全量监控：拥有摄像头、麦克风、键盘、屏幕或网络访问能力，不代表默认持续采集或保存原始内容。
• 不把每一个传感器信号变成任务：输入必须先分类为用户意图、外部事件、环境状态、遥测或反馈。
• 不让系统自己出题当课程：自主产生的候选问题默认不进入执行队列。
• 不自动发起机会性任务：无人要求的工作必须有明确规则，且默认先运行在 shadow 模式。
• 不实时合并多个执行体的注意力层：跨任务只共享有来源的断言、文件或明确授权的资源。
• 不在第一版动模型权重：权重迁移排在最后，并且必须独立回归验证。
• 不把设备权限等同于用户授权：操作系统允许访问某项资源，不代表 Agent 在当前任务中可以使用它。
• 不把 Agent 身份绑定在躯体上：设备只是运行载体，不能成为长期身份与记忆的唯一持有者。
• 不把模型等同于 Agent：模型是可替换的推理能力，模型不可用时 Agent 应能降级、等待或切换。
• 不默认争夺人类输入设备：共享桌面上的鼠标、键盘和窗口需要明确控制权仲裁。
• 不声称模拟等于真实世界：模拟、dry-run 和测试环境只能覆盖已建模的行为，不能代替真实环境验证。

---

2. 设计公理

#	公理	直接推论
A1	系统的时钟不能只有用户。	触发源包括外部事件、定时器、状态断点、设备状态变化和外部回执。
A2	监听的相关性来自「有主的东西」。	感知层优先匹配已有工作项的等待条件；不做无边界的全世界语义监听。
A3	打断消耗人的注意力。	默认沉默；只有延迟成本、风险或用户裁决价值足以证明打断正当时才开口。
A4	错并的代价远大于错开。	激进隔离、保守合并；无法用明确目标证明同一任务时，默认新建工作项。
A5	沉默的退化方向可能是越来越沉默。	漏报与打扰信噪比成对度量；每个抑制决定都留下原因。
A6	经验先落在便宜、可撤销的层。	账本 → 规则/订阅 → 技能/检索策略 → 模型权重。
A7	感知权与行动权必须分离。	每个通道分别声明 read / observe / execute 权限；采集权限不能自动推导出操作权限。
A8	设备是载体，不是 Agent 身份。	Agent ID、Body ID、Channel ID 分离；设备可掉线、替换或增加，任务与记忆不能因此丢失。
A9	任何外部输入都不天然可信。	传感器、网页、文件、邮件、IM 和工具返回值均作为数据处理，不能直接覆盖系统指令或授权策略。
A10	人与 Agent 可能共享同一躯体和资源。	输入设备、窗口、文件和外部账号必须有控制权仲裁、租约与紧急停止。
A11	持续存在不等于持续在线。	设备离线、网络分区、模型不可用时，系统按任务依赖和离线授权降级运行。
A12	时间戳不等于因果顺序。	事件需保存来源时钟、单调序号、观察时间、入库时间和时钟不确定度。
A13	行动的完成必须由外部证据验证。	Action 回执、后置条件验证、补偿和人工确认构成闭环。
A14	自我管理不能越过安全边界。	资源自适应可以降级或暂停，但不能自行扩大权限、关闭安全机制或解除硬件保护。

---

3. 基本概念：Agent、Body、Sense、Brain、Action、Memory

3.1 核心概念

概念	定义	典型内容
Agent Identity	跨设备、跨模型保持稳定的 Agent 身份	Agent ID、策略、长期记忆引用、所有权
Body	Agent 当前使用的设备或运行环境	PC、服务器、手机、边缘设备、虚拟机
Sense	从外部世界取得信息的输入能力	摄像头、麦克风、键盘/鼠标事件、屏幕、文件、网络、应用 API
Brain	对信息进行理解、判断、规划的认知能力	规则引擎、模型、检索、规划器
Action	对外部世界产生影响的受控能力	鼠标键盘控制、文件修改、应用操作、网络 API、通知、音频输出
Memory	跨时间保存状态、证据、经验的机制	Ledger、WorkItem、Assertion、时间性记忆、技能、检索索引
Control Plane	管理 Agent 权威状态和全局协调的逻辑平面	身份、Ledger、策略、调度、租约、恢复；可以与 Body 同机部署
Body Runtime	在具体设备上管理本地硬件、软件通道和资源的运行时	Adapter、Capability、SelfState、本地事件缓冲、Action Runner
Inference Runtime	提供推理能力的执行位置与路由层	本地模型、远端 API、视觉/语音模型、模型路由
Environment Model	对有限范围内外部实体及状态变化的结构化表示	Entity、Observation、State、Evidence、Confidence
Principal / Grant	表示谁拥有什么身份、所有权和授权	Owner、Operator、Observer、Approver、资源范围与有效期

这是工程上的功能类比，不是对设备或模型具有生命、意识或自主权的宣称。

3.2 Agent 与设备的关系

Agent（稳定身份）
├── Runtime Core（运行时核心）
│   ├── Ledger / Scheduler / Policy / Event Bus
│   ├── Worker / Model Router / Consolidator
│   └── Memory / Evaluation
│
├── Body A：桌面 PC
│   ├── Sense：键鼠交互、屏幕、文件系统、进程、摄像头、麦克风、网口
│   └── Action：键鼠控制、应用操作、文件操作、音频/通知输出
│
├── Body B：手机或边缘设备（可选）
│   ├── Sense：摄像头、麦克风、定位（经授权）、通知、设备状态
│   └── Action：屏幕呈现、通知、音频、应用 API
│
└── 外部能力
    ├── 云端推理模型
    ├── Git / CI / IM / 邮件 / Webhook
    └── 其他 SaaS 或内部服务

约束：

• Agent ID 不随设备变化；Body ID 标识具体设备或运行环境。
• 每个 Body 可以连接多个 Channel；一个 Agent 可以使用多个 Body。
• Body 离线时，其他可用 Body 或云端运行时可以继续处理不依赖该设备的任务。
• 依赖某个设备本地传感器或文件的任务，必须明确标记其 Body 依赖；设备离线时进入 blocked / waiting_device，而不是假装仍可感知。
• 模型可以部署在本机或远端；模型的位置不改变数据来源、权限和审计规则。

3.3 通道不是插件清单，而是统一的能力契约

硬件与软件都通过 Channel Adapter 接入。每个通道至少声明：

• 身份：channel_id、body_id、provider、version。
• 方向：sense、action 或 bidirectional。
• 能力：可读取的数据、可执行的动作、支持的事件类型。
• 权限：允许的资源范围、用户授权来源、授权有效期。
• 运行状态：启用、暂停、掉线、降级、故障。
• 数据策略：是否允许原始数据留存、保留期限、是否需要本地预处理。
• 资源成本：CPU、内存、带宽、电量、调用费用和频率限制。

同一个设备能力如果同时支持读取和写入，必须拆成独立权限。例如文件系统的 read_file 与 write_file 不应共用一个笼统的「文件权限」。

---

4. 总体架构

职责边界：

1. Body 提供能力，但不负责决定 Agent 应该做什么。
2. Adapter 负责接入、标准化和报告能力健康度，不负责任务决策。
3. L0 负责低成本、确定性的过滤与匹配。
4. L1 负责是否记账、唤醒或请求澄清。
5. Worker 负责理解任务和形成计划，但不能绕过 Policy Engine 直接操作设备。
6. Action Runner 是所有有副作用操作的唯一执行入口。
7. Ledger 是任务与状态事实源；对话只是它的一个视图。

4.1 部署平面与行动闭环

上面的图强调事件流水线；下图强调不同运行平面的职责，以及行动必须经过仲裁、策略和验证的闭环。

Control Plane、Body Runtime 和 Inference Runtime 是逻辑边界，可以先部署在同一台机器。即使模型位于远端，设备操作也必须回到本地 Body Runtime，经 Policy、仲裁和 Action Runner 执行。

---

5. 运行平面：Control Plane、Body Runtime、Inference Runtime

5.1 为什么需要分平面

v0.2 已经区分 Agent Identity 与 Body，但还需要明确哪些状态由谁权威持有、哪些能力必须在设备本地执行，以及模型服务失联时系统如何继续运行。建议将运行时按职责分成三个平面。它们是逻辑边界，不是要求第一版部署成三个独立服务。

平面	核心职责	可以部署在哪里	不应承担的职责
Control Plane（控制平面）	Agent 身份、Ledger 权威状态、任务图、策略、调度、租约、恢复与审计	本机、家庭服务器或云端；单一 Agent 应有明确权威写入端	不直接采集高频硬件流，不绕过 Body 执行设备动作
Body Runtime（躯体运行时）	本地设备发现、Channel Adapter、权限代理、资源监测、事件缓冲、设备行动	每台 PC、手机、服务器或边缘设备	不自行改变 Agent 全局身份、授权策略或任务事实
Inference Runtime（推理运行时）	模型路由、推理、视觉/语音理解、规划辅助	本地 GPU、局域网推理服务器或外部 API	不成为 Ledger 的唯一存储，也不直接持有无限制设备权限

5.2 单机与多设备部署

第一版可把三个平面放在同一台电脑上：

单机部署（v0）
┌─────────────────────────────────────────┐
│ PC / Server                             │
│  Control Plane ─ Body Runtime           │
│       │              │                  │
│       └──── Inference Router ─ Local/Remote Model
│                      │                  │
│                Channels / Action Runner │
└─────────────────────────────────────────┘

多设备形态再演进为：

多 Body 部署（后续）
                  Agent Identity
                        │
                Control Plane（权威状态）
                  /       |       \
             Body A    Body B    Body C
             Desktop    Phone    Server
               |         |        |
            Channels  Channels  Channels
                  \       |       /
                 Inference Router
                 /      |       \
             Local GPU  LAN GPU  Remote API

分离是逻辑上的，部署可以合并。 不要为了体现分层而过早拆微服务；只有在设备边界、资源隔离、独立升级或故障域确实要求时才拆进程或服务。

5.3 权威状态与单写者原则

• 每个 Agent 必须明确一个 Ledger 权威写入端（Authority）。其他 Body 可以缓存、缓冲事件和保存本地检查点，但不能在网络分区时各自修改同一份全局任务状态并假设最终自然一致。
• 多 Body 对共享资源的写操作通过租约和 fencing token 防止旧持有者在租约过期后继续写入。
• 设备本地事件可以先进入持久化 Outbox；恢复连接后按事件 ID、来源序号和因果关系补传。
• 断网期间只允许执行事先授权、范围明确、可安全离线完成的动作；其余进入等待状态。
• Inference Runtime 可切换模型或位置，但模型切换不得改变事件来源、任务授权和数据访问范围。

5.4 模型不可用时的降级

推理服务不可用不等于 Agent 状态丢失。系统应按能力降级：确定性规则、定时检查、任务等待、设备健康监测和安全停止仍可运行；需要复杂理解的任务暂停或转人工处理。不得为了维持「看起来在线」而编造推理结果。

---

6. 运行连续性与多 Body 迁移

6.1 连续性定义

运行连续性不是让某个 Worker 永远不停止，而是保证 Agent 的身份、权威记忆、工作项状态、权限边界和可恢复检查点能跨进程重启、设备离线和设备替换继续存在。

连续性分为四级：

1. 进程连续性：同一设备上的 Runtime 或 Worker 崩溃后恢复。
2. 设备连续性：原 Body 离线或重启，任务能等待或迁移。
3. 服务连续性：模型 API、推理服务器或消息服务暂时不可用时系统降级。
4. 身份连续性：设备被替换时，Agent ID、任务谱系和记忆仍然有效。

6.2 Body 依赖与可迁移性

WorkItem 必须声明依赖的是「能力」还是「具体设备」。例如：

• 需要 filesystem.read 且数据已同步：可迁移到具备同等授权的 Body。
• 需要本机摄像头实时观察：只能在拥有该摄像头且获得授权的 Body 执行。
• 需要某台电脑当前已登录的本地 GUI 会话：通常不能直接迁移，必须重新验证会话和用户控制权。
• 需要本地未同步文件、USB 设备或物理环境状态：必须等待原 Body 恢复，或由人提供新证据。

不要把「另一个 Body 也有摄像头」视为环境相同；设备位置、视角、用户授权和采样时间都可能不同。

6.3 迁移流程

Body A 发生离线 / 维护 / 资源不足
    ↓
检查 WorkItem 的 BodyRequirement
    ↓
识别依赖：能力依赖 / 特定设备依赖 / 当前会话依赖
    ↓
核实 ActionInvocation 是否有未决副作用
    ↓
生成 Transfer Manifest（迁移清单）
    ↓
选择具有等价能力与独立授权的 Body B
    ↓
恢复任务检查点、证据引用和未完成步骤
    ↓
重新验证权限、前置条件和环境状态
    ↓
继续 / 等待原设备 / 请求人工处理

迁移清单只包含完成任务所需的最小状态：WorkItem 版本、执行检查点、证据引用、资源依赖、未决动作、租约和授权引用。不得复制明文密钥；目标 Body 必须重新取得自己的凭据授权。

6.4 网络分区与 Split-brain

• 同一个共享资源在同一时刻只能有一个有效写租约；租约需要 epoch/fencing token。
• Body 无法联系 Control Plane 时，不得自行延长共享写租约。
• 离线缓存的事件可以补传；高风险写操作默认停止，除非有预先签发、范围和期限都明确的离线授权。
• 两个 Body 对同一实体产生冲突观察时，先保留各自证据，不直接覆盖；由时间语义和独立验证流程解决。

---

7. 人机控制权仲裁（Human-Agent Arbitration）

7.1 原则

设备可能由人和 Agent 共享。操作系统允许 Agent 控制鼠标，不代表 Agent 可以在用户正在操作时抢占鼠标。控制权必须按资源粒度管理，而不是只设置一个全局「Agent 正在运行」开关。

7.2 控制权状态

状态	含义	典型行为
HUMAN	人类当前控制某个资源	Agent 对冲突资源暂停自动输入
AGENT	Agent 持有受限控制租约	仅能操作获准的窗口、会话或资源
SHARED	双方可并行使用不冲突资源	使用资源锁、窗口隔离或只读观察
LOCKED	安全策略或系统状态禁止操作	拒绝新的 ActionInvocation
EMERGENCY_STOP	全局或 Body 级紧急停止已触发	取消排队动作、终止可终止执行、撤销租约并阻止新动作

状态应作用于资源，例如 body_id + desktop_session + window_id + input_device，不要让用户在一个窗口上的活动无谓冻结所有后台任务。

7.3 控制权取得和释放

• Agent 申请操作窗口或输入设备前，先请求一个短期控制租约；租约应有到期时间和续租条件。
• 发现用户开始操作同一资源时，Agent 应停止注入新的键鼠输入，并安全结束当前原子步骤；不得在用户输入过程中继续键入。
• 用户接管后，Agent 记录检查点并重新读取界面状态；不能假设焦点、坐标或页面内容仍与上次一致。
• 用户活动检测应尽量只使用粗粒度信号（例如目标窗口焦点变化或系统提供的空闲状态），不采集逐键内容，不将输入活动记录成行为画像。
• Agent 不应通过伪装用户输入绕过系统权限、确认框或安全控件。

7.4 紧急停止

必须提供一个不依赖大模型、网络或对话界面的本地停止入口，例如系统托盘、快捷键、物理开关或管理界面。紧急停止应：

1. 阻止新的 ActionInvocation 进入执行。
2. 取消尚未执行的动作。
3. 尽可能终止正在运行的可中断动作。
4. 撤销控制租约并释放资源锁。
5. 标记无法确认结果的动作，交给 Recovery 对账。
6. 保留日志，但停止敏感感知采集（除非该采集是安全停机所必需且已明确授权）。

软件紧急停止不能替代物理设备的硬件急停；涉及机械、车辆、医疗或其他物理危险的执行器，必须有独立硬件安全机制。

---

8. SelfState：Agent 的自我状态与资源自适应

8.1 自我状态范围

SelfState 是 Agent 对自身运行条件的结构化认知，不是对用户状态的推断。它至少覆盖：

维度	监测项	可能的降级动作
计算	CPU、GPU、RAM、显存、温度、并发	降低批量任务并发、切换轻量模型、延后非紧急任务
存储	磁盘空间、数据库可用性、队列积压、写入延迟	限制媒体缓存、清理过期数据、暂停高写入任务
通信	网络在线、延迟、丢包、DNS、远端服务可用性	本地缓冲、切换允许的推理端点、等待远端回执
感知	摄像头、麦克风、屏幕、键鼠、文件和 API 通道状态	关闭故障通道、降低采样、转为等待设备
行动	Action Runner、租约、沙箱、工具可用性	禁止新动作、收回租约、仅允许只读检查
认知	模型可用性、上下文余量、推理延迟、错误率	模型路由、压缩上下文、排队或交人工
运行	Worker 心跳、Lease、队列、恢复任务、事件延迟	回收过期 Worker、对账、限制并发
经济	API 成本、算力预算、调用额度、电量	延后低优先级推理、使用预算内模型或暂停

8.2 资源预算与优先级

任务调度不能只看 concurrency_max。每个任务可以声明软预算：最大推理成本、预计执行时长、CPU/GPU/内存需求、带宽和是否依赖电池供电。实际调度由策略层综合确定。

建议优先级：

1. 安全、紧急停止、权限撤销和恢复对账。
2. 已授权且有明确截止时间的高优先级任务。
3. 用户正在等待的任务及关键依赖。
4. 普通工作项。
5. 巩固、泛化扫描、机会性候选等后台工作。

8.3 自适应原则与禁止行为

SelfState 可以降低采样频率、限流、暂停后台 Worker、切换模型或请求增加资源；不能自行扩大设备权限、把数据转发到未批准服务、关闭安全策略、绕过用户预算或无限重试。温度、电池和物理设备保护必须尊重操作系统及硬件安全策略。

8.4 身体健康不等于用户在场

Body Health 只表示设备和 Agent Runtime 的运行状态。用户是否在场、是否忙碌或是否愿意被通知是另一类推断，必须单独授权、低精度处理并允许用户关闭，不得从摄像头或麦克风默认推断。

---

9. 时间语义与跨设备事件排序

9.1 多种时间不能混用

每个事件至少区分：

• occurred_at：来源认为事件发生的墙上时间；入库时统一规范化为 UTC，并保留来源原始时区/偏移。
• observed_at：Adapter 实际观察到事件的时间。
• ingested_at：事件写入本地 Inbox / Ledger 的时间。
• source_sequence：来源内单调递增序号（若支持）。
• monotonic_time 与 clock_domain：设备单调时钟读数及其时钟域。
• clock_uncertainty：来源时钟与参考时钟之间的估计偏差范围。

墙上时钟可用于跨系统展示和大致对齐；单调时钟用于同一设备内测量持续时间。不能仅凭两个设备的墙上时间戳推断精确先后顺序。

9.2 排序与因果

• 能取得来源序号时，优先保留来源内顺序。
• causation_id 和 correlation_id 表达因果链与工作流关联；时间戳本身不替代因果关系。
• 跨设备事件应允许迟到和乱序；对账和状态投影需支持 watermark 或可配置的迟到窗口。
• 若事件时间不确定区间重叠，系统应标记顺序不确定，而不是强行排序。
• 设备离线后补传事件时，应保留原始发生时间与补传时间。

9.3 多模态时间关联

摄像头、麦克风和系统事件需要统一到时间窗口，才可以判断它们是否描述同一场变化。Adapter 应保留采样时刻、帧/片段范围、采样率和时钟域。多模态关联产生的是带证据和置信度的推断，不能直接覆盖某个实体的已验证状态。

---

10. Capability Discovery：能力发现与生命周期

10.1 从设备发现到可用能力

新设备接入不应假定拥有固定硬件。Capability Discovery 负责发现可用能力，Capability Registry 负责登记，Policy Engine 负责授权，Capability Manager 负责启用、升级、暂停和撤销。

发现设备 / 软件接口
    ↓
识别 OS、硬件和 Adapter 版本
    ↓
验证 Adapter 来源、签名或可信发布渠道
    ↓
生成 Capability Descriptor
    ↓
向用户/管理员展示所需权限与数据策略
    ↓
授权后进入 shadow / 测试模式
    ↓
健康检查与能力验证
    ↓
按资源范围启用
    ↓
持续监测 / 更新 / 撤权 / 卸载

10.2 Capability Descriptor

每项能力需声明：能力 ID、输入/输出方向、支持的操作、资源范围参数、操作风险等级、是否产生副作用、幂等支持、可验证方式、资源成本、所需权限、数据分类、Adapter 版本和兼容平台。

发现能力不等于授予权限；安装 Adapter 不等于允许它执行；操作系统权限也不自动成为 WorkItem 授权。

10.3 生命周期状态

discovered → validated → disabled → shadow → enabled → degraded → revoked / retired。

• 新 Adapter 默认 disabled 或 shadow。
• Adapter 升级后重新校验版本、权限差异和行为兼容性；权限范围扩大必须重新授权。
• Adapter 不允许修改自己的权限声明或向自己授予权限。
• 未知来源的插件、脚本或驱动不得以 Agent 扩展的名义直接加载到高权限进程。
• 撤权需要立即阻止新的操作，并清理可撤销的会话、凭据和本地订阅。

---

11. Environment Model 与 Temporal Memory

11.1 从事件列表到有限范围的环境状态

Event 是一次发生或观察；Environment Model 是系统在特定时间对某些实体状态的当前估计。两者不能混为一谈。

Sense Event / Evidence
        ↓
Observation（观察记录）
        ↓ 关联实体、时间和来源
Entity State（带有效期的状态估计）
        ↓ 新证据、矛盾或过期
状态修订 / 状态不确定 / 需要重新观察

例如摄像头报告某个物体从桌面左侧移动到右侧，系统可以保存两个带时间和证据的 Observation，并生成一个 location_changed 状态变化。若遮挡导致位置不确定，应保留不确定性，而不是强行写成事实。

11.2 环境模型边界

• 只建模明确授权、对任务有用的实体和属性，不追求全量世界模型。
• 每个状态必须关联证据、来源、时间范围和置信度。
• 同一实体的不同 Body 观察可以冲突；冲突时保留多条观察，按时间、视角、来源可靠性和独立验证处理。
• inferred 状态不能单独触发高风险行动。
• 对人员、位置、家庭环境等敏感实体采用更严格的数据最小化和访问控制。

11.3 Temporal Memory（时间性记忆）

记忆应支持「当时是什么」与「系统何时知道」两个问题。建议采用双时间概念：

• valid_time：事实在外部世界成立的时间范围。
• transaction_time：系统记录或修订这条事实的时间。

这样可以保留历史变化，不会用新状态抹掉旧状态。例如设备在 6 月从 A 换成 B，系统既能回答当前使用 B，也能回答 5 月使用 A。

记忆分层：当前状态、历史状态、稳定事实、临时推断、经验规则、操作记忆。每类有独立 TTL、修订规则、隐私等级和来源追溯。过期意味着需要复核或降低置信度，不代表可以无痕删除历史审计。

---

12. Action Verification 与 Simulation

12.1 Action 的闭环

工具调用返回成功，只说明执行接口报告成功；并不证明目标状态已经达成。关键动作必须定义前置条件、预期后置条件和验证方式。

Plan
  ↓
Precondition Check（当前状态是否允许执行）
  ↓
Policy / Approval
  ↓
Action Runner 执行
  ↓
Receipt（工具或外部系统回执）
  ↓
Independent Verification（重新读取外部状态）
  ├─ verified：证据支持后置条件
  ├─ failed：证据表明没有达成
  └─ unknown：状态无法确认，先对账，不盲目重试
  ↓
更新 WorkItem / Assertion / 下一步

12.2 验证方法

动作	不充分的证据	更合适的验证
文件写入	写入 API 返回成功	重新读取文件、校验内容或哈希
GUI 保存	鼠标点击成功	重新读取页面状态、保存标记或后端数据
Git 提交	命令进程退出码为 0	查询目标分支和提交 ID
发送邮件/消息	客户端接受请求	查询服务端消息 ID / 送达状态；无法确认时标注 unknown
部署	CI 命令完成	查询部署版本、健康检查和关键服务状态
数据修改	SQL 执行成功	重新查询受影响记录并检查约束

验证方式应尽量独立于执行路径；如果执行与验证依赖同一个可能失真的回执，需标记证据局限。

12.3 失败补偿

动作失败不总是可回滚。系统需要区分：

• retry：确认没有副作用或动作具有幂等键时重试。
• reconcile：先查询外部状态，再决定是否继续。
• compensate：通过另一个明确动作抵消已发生的副作用。
• manual_recovery：不可安全自动恢复时交给人。

不得把补偿操作当作真正的时间回滚；例如邮件已发出，无法保证撤回收件人已看到的内容。

12.4 三种执行模式

模式	行为	用途
shadow	只记录本来会执行的计划，不产生副作用	规则与新能力冷启动
simulation	在模拟、dry-run 或隔离测试环境执行	检查计划、参数和部分副作用
live	在真实授权环境执行	生产运行

模拟结果必须标注模型覆盖范围与环境差异。Simulation 不能证明真实环境必然成功；物理设备、生产系统和不可逆操作仍需独立安全措施及适当审批。

---

13. Principal、Ownership 与 Delegation

13.1 身份关系

共享设备上至少区分以下主体：

主体	含义	典型权限
Agent Owner	Agent 的管理者和策略所有者	管理 Agent 身份、长期策略和授权边界
Body Owner / Administrator	设备或运行环境的管理者	安装组件、管理设备级权限和安全设置
Operator	可以向 Agent 分配任务的人	在其授权范围内创建和管理 WorkItem
Observer	只读查看者	查看被授权的任务和状态
Approver	对特定动作进行审批的人	审批限定风险、资源和时间范围的动作
Data Subject / Bystander	被感知数据涉及的人	其数据需要遵守适用的隐私和授权要求，不因设备归属而自动放弃边界

一个人可以同时承担多个角色，但角色不能被隐式推断。Agent Owner 不一定等于 Body Owner；拥有设备不代表拥有设备中所有账号或其他人的数据。

13.2 Grant（授权）

授权记录必须包含：主体、资源、动作范围、目标 Body / Channel / WorkItem、用途、授予方式、有效期、撤销方式、审批人和策略版本。授权采用最小权限，默认拒绝；新设备、新账号、新数据类型或扩大资源范围都需要重新评估。

13.3 委托与审批

Agent 可以把任务委托给 Worker 或另一个受信任 Agent，但委托不能扩大原始授权。子任务权限是父任务授权范围的子集；委托链必须可追溯，并设定期限、预算和可访问数据范围。审批应绑定具体 ActionInvocation 或明确动作模板，不能把一次审批解释为永久、无限范围的授权。

13.4 共享设备的默认规则

当无法确认当前用户身份或当前数据归属时，系统按较严格权限处理：可以继续执行已授权的非敏感后台任务，但不得读取其他用户私有数据、接管前台输入或向共享输出设备播放敏感信息。

---

14. Body 与 Channel：设备感知和行动体系

14.1 感知通道（Sense Channels）

类别	设备 / 软件来源	可产生的信息	设计约束
人机交互	键盘、鼠标、触控板、触摸屏	用户主动输入、点击、焦点变化、交互状态	默认只采集必要的交互事件；不得默认保存全局逐键记录或密码输入
视觉	摄像头、屏幕捕获、窗口/辅助功能树	图像、视频帧、窗口标题、控件结构、视觉变化	摄像头需显式授权和可见状态；优先按需采样与本地预处理
音频	麦克风、系统音频输入	音频片段、语音活动、转写文本、声音事件	默认不持续保存原始音频；录音、转写和留存分别授权
文件与存储	文件系统、云盘、数据库、文档应用	创建、修改、删除、同步状态、文件内容	限定目录与资源范围；敏感文件需单独策略
操作系统	进程、服务、窗口、系统日志、设备健康	运行状态、错误、崩溃、资源占用	优先使用系统事件和结构化接口，避免高频轮询
网络	网卡状态、DNS、连接、流量元数据、Webhook	连通性、服务状态、远端事件、请求结果	网络监听和内容解密属于独立高敏权限；默认不采集无关流量正文
软件应用	浏览器、IDE、办公软件、Git、CI、IM、邮件、业务系统	应用事件、状态变更、消息、提交、测试结果	优先官方 API、Webhook、插件或辅助功能接口；网页内容视为不可信输入
外部环境	可选的温湿度、位置、运动、门磁等传感器	环境状态和变化	仅在明确场景和授权下接入；位置等敏感数据单独管理

**键盘与鼠标的特别约束：**它们既可能是用户与 Agent 交互的输入设备，也可能是 Agent 控制电脑的执行设备。两种方向必须区分：

• sense.input_activity：感知用户正在进行某种交互；默认只记录必要的事件类型、窗口上下文或粗粒度状态。
• action.pointer_move / action.click / action.key_input：Agent 主动控制设备；必须经过动作授权、目标窗口校验和执行审计。
• 禁止把全局键盘记录、剪贴板内容、密码框内容作为默认感知机制。
• 用户正在亲自操作同一窗口时，Agent 的自动点击和键入应默认暂停或进入冲突仲裁，避免抢夺控制权。

14.2 行动通道（Action Channels）

类别	执行能力	风险示例	默认策略
人机设备	移动鼠标、点击、键入、滚动、触控	误点、覆盖用户输入、误提交	ask 或受限 auto；绑定目标窗口和操作范围
显示与音频	屏幕显示、语音播报、声音提示	打扰、泄露屏幕或语音信息	通知预算控制；敏感内容不在公共输出设备播放
文件系统	读取、创建、修改、移动、删除文件	数据损坏、误删、越权读取	读写分权；写入隔离目录；删除默认需要审批或回收站
进程与命令	启动命令、运行脚本、管理进程	任意代码执行、系统破坏	沙箱、命令白名单、资源限额、超时与审计
应用操作	调用应用 API、自动化界面、提交表单	错误提交、数据变更	每种动作单独声明权限和可回滚能力
网络与服务	HTTP 请求、数据库操作、Git、CI、IM、邮件	数据外传、生产变更、消息误发	域名/资源 allowlist、凭据代理、敏感操作审批
设备控制	摄像头、麦克风、蓝牙、USB、智能设备	隐私泄露、物理影响	默认关闭；按需启用；高风险动作二次确认

任何会改变外部状态的调用都必须经过 Action Runner。 Worker 可以提出动作意图，但不直接持有无限制的设备控制权。

14.3 Channel 生命周期

发现能力
  ↓
注册 Channel Descriptor
  ↓
用户 / 管理员授权
  ↓
shadow（只观察，不执行副作用）
  ↓
启用 sense 或受限 action
  ↓
运行中持续报告健康度
  ↓
暂停 / 撤权 / 设备离线 / 版本变化
  ↓
清理订阅、令牌与本地缓存，并将相关任务置为 waiting_device 或 blocked

通道状态建议：discovered / disabled / shadow / enabled / degraded / offline / revoked / error。

每个 Channel 需要心跳或健康检查，但不能用高频轮询代替系统原生事件。设备掉线时，应产生 body.offline 事件；恢复时产生 body.online，并执行缺失事件补偿或状态对账。能力的发现、验证、授权、启用、升级和撤销由 Capability Manager 管理，不能由 Adapter 自行完成授权。

14.4 事件类型与用户意图分离

不是每个传感器事件都代表用户希望 Agent 开始工作。输入至少分为：

类型	例子	默认处理
intent	用户明确说「帮我修复这个项目」	创建或路由 WorkItem
external_event	CI 失败、邮件到达、PR 被审核	与 WaitCondition 匹配
environment_state	摄像头检测到某物体、窗口切换、设备在线	先成为观察事件，不直接创建任务
telemetry	CPU、内存、网络延迟、服务心跳	规则阈值与健康检查
feedback	用户纠正、接受、拒绝、评价通知	写入 Ledger 和学习信号
receipt	API 请求成功、邮件送达、操作完成	验证 ActionInvocation 结果

只有 intent 或已定义规则允许的事件，才能创建新任务。环境感知和遥测默认只更新状态或进入候选池。

14.5 感知数据生命周期

感知不是「全部收集、全部上传、永久保存」。推荐分层：

1. 设备侧即时处理：原始音视频、屏幕帧优先在本机完成采样、检测、转写或结构化。
2. 事件化：向 Event Bus 发送必要的结构化事件、时间戳、来源和证据引用。
3. 证据留存：只有任务需要、授权允许且策略要求时，才保存原始片段或截图；优先保存短片段和引用。
4. 过期清理：按数据类别分别设置 TTL；撤销权限后停止新的采集，并按策略删除或冻结既有数据。
5. 跨设备传输：加密传输；默认不把原始摄像头、麦克风和全屏数据发送到外部模型。

---

15. 核心数据结构

字段里的推荐值是起步建议，不是不可调整的标准。所有结构都应有 schema_version。

15.1 WorkItem 工作项

系统的承重对象。一项工作必须有目标、验收条件、归属与状态。

字段	类型	原理	推荐值
id	str	稳定引用	wi-<日期>-<n> 或 UUID
goal	str	一句话说明最终状态	≤ 30 字优先
done_when	AcceptanceCriterion[]	可判定验收条件	至少 1 条；优先硬判据
status	enum	明确生命周期	draft / open / ready / running / blocked / waiting_device / awaiting_user / verifiable / closed / cancelled
stale	derived flag	停滞是派生状态，不与生命周期混为一谈	由 last_progress_at 和策略计算
owner_agent_id	id	确定由哪个 Agent 负责	必填
body_requirements	BodyRequirement[]	声明能力依赖、特定 Body 依赖或当前会话依赖	可迁移性由依赖类型决定
blocked_on	WaitCondition[]	说明在等待谁或什么	—
parent / depends_on	id[]	任务依赖图	深度建议 ≤ 3，超出时重新拆分评估
authorization_profile_ref	id	关联授权范围，不使用单一档位覆盖所有动作	默认最小权限
interrupt_budget	int	单项通知预算	起步 3 次/周/项
last_progress_at	time	判断是否真正推进	每次有证据的进展更新
next_check_at	time	下次内部检查点	默认 24h，可按任务调整
cost_slope	number + unit	延迟的预期边际成本	冷启动按规则估算
context_ref	path / uri	Worker 上下文及工作目录边界	每个工作项独立目录或分支
version	int	乐观并发控制	每次有效状态更新递增
created_at / updated_at	time	生命周期审计	必填

stale 不应作为任务的终态。一个任务可以是 blocked 且同时 stale=true。

15.2 EventEnvelope 统一事件封套

所有硬件、操作系统、应用和外部服务的事件先转换为统一封套，再交给 L0。

字段	类型	说明
event_id	UUID	本运行时生成的全局唯一事件 ID
source_event_id	str	来源系统自己的事件 ID，若存在则保留
event_type	str	如 ci.failed、camera.motion_detected、file.changed、body.offline
schema_version	str	事件结构版本
agent_id	id	归属 Agent
body_id	id	产生事件的设备/运行环境
channel_id	id	具体感知通道
occurred_at	time	事件在来源处发生的时间
observed_at	time	设备或适配器观察到事件的时间
ingested_at	time	进入本地事件总线的时间
source_sequence	int	来源内单调序号（可用时）
monotonic_time	number	来源设备的单调时钟读数（可用时）
clock_domain	str	单调时钟所属设备/进程域
clock_uncertainty_ms	number	时钟偏差估计或不确定范围
correlation_id	id	关联一个工作流程
causation_id	id	引起当前事件的上游事件/动作
provenance	enum	observed / told / inferred / verified
trust_level	enum	来源可信等级，不等于事实正确性
privacy_class	enum	public / internal / sensitive / restricted
payload_ref	uri	结构化内容或受控证据引用；避免在封套中塞入大型原始数据
dedupe_key	str	去重键

时间字段必须区分「发生时间」与「收到时间」，因为设备可能离线后补传旧事件。

15.3 ChannelDescriptor 通道描述

channel_id: ch-desktop-camera-01
body_id: body-pc-01
provider: local-camera-adapter
version: 1.0.0
artifact_digest: sha256:...
trust_state: validated
direction: sense              # sense | action | bidirectional
capabilities:
  - camera.frame_sample
  - camera.motion_detected
permissions:
  mode: disabled              # disabled | shadow | read | execute | approval_required
  resource_scope: []
  granted_by: null
  expires_at: null
data_policy:
  raw_retention: none
  local_processing: true
  external_transfer: deny
health:
  state: disabled
  last_heartbeat_at: null
resource_budget:
  max_fps: 0
  max_bandwidth_kbps: 0

以上仅为结构示例。实际权限由 Policy Engine 管理，Agent 不能通过修改自己的描述文件自行给自己授权。

15.4 WaitCondition 等待条件

L0 的主要匹配对象。每个条件必须有归属、来源范围、过期时间和去重策略。

字段	类型	说明
id	id	稳定引用
workitem_id	id	必须关联工作项；特殊系统健康订阅需关联系统级 WorkItem
event_type	str[]	允许匹配的事件类型
channel_selector	object	来源通道、Body、应用或服务范围
matcher	structured rule	字段、阈值、前缀、状态等确定性条件
priority_hint	float	初始权重
cooldown	duration	同一事件反复出现的冷却期
dedupe_strategy	str	来源 ID、资源 ID、时间窗等去重方式
expires_at	time	自动过期，避免僵尸订阅
last_matched_at	time	命中审计

禁止建立无归属、无过期时间的通用监听。对于无法用结构化规则匹配的高价值信息，可进入受限的批量扫描候选池，而不是默认每条事件调用模型。

15.5 Assertion 断言（事实与结论层）

跨 Worker 的共享载体：共享结论与证据，不直接共享完整注意力上下文。

字段	类型	说明
id	id	唯一 ID
text	str	断言内容
provenance	enum	observed / told / inferred / verified
source_ref	uri	必须可追溯到事件、文件、动作回执或人工输入
source_independence_group	str	防止同一来源被复制多次伪装成独立证据
verified_by	criterion / human id	只有独立判据或人可以完成验证
expires_at	time	推断必须过期；观察事实也需按领域设定复核周期
supersedes	id[]	被新断言推翻的旧结论
privacy_class	enum	控制跨任务和跨设备访问

inferred 不允许单独成为高风险动作的依据，也不允许在没有新证据时自动升级为 verified。

15.6 ActionInvocation 行动调用

所有可能改变外部状态的操作必须生成行动记录。

字段	类型	说明
action_id	UUID	本次动作唯一 ID
workitem_id	id	动作归属工作项
body_id / channel_id	id	使用哪台设备和哪个行动通道
capability	str	如 filesystem.write、ui.click、git.push
target_scope	object	目标资源、窗口、文件、仓库或 API 范围
arguments_ref	uri	参数引用，敏感值不得直接写入普通日志
authorization_decision	object	允许/拒绝/需审批及原因
idempotency_key	str	重试防止重复副作用
precondition	object	执行前状态校验
status	enum	proposed / waiting_approval / approved / running / succeeded / failed / cancelled / compensated
result_ref	uri	执行回执或结果
expected_postcondition	object	期望的外部状态
verification_ref	id	对应 ActionVerification
compensation_ref	uri	可用时记录回滚/补偿操作
started_at / finished_at	time	执行时间

15.7 InterventionLog 开口日志

字段	类型	说明
trigger	enum	result / decision / blocked / correction
payload_kind	enum	acceptance_request / decision_request / status_digest / urgent_alert
context_inline	bool	消息必须自带上下文
user_response	enum	helpful / annoying / already_knew / unanswered / unknown
response_observed_at	time	用户反馈时间
suppression_reason	str	未上报的原因；只对抑制决策填写
would_have_been_late	number	延迟后果估算，注明单位和置信度

unanswered 不能直接判定为 annoying；无反馈与负面反馈必须分开统计。

15.8 Correction 纠正采集

字段	类型	说明
orig_output / corrected	text/ref	成对保存
domain	enum	fact / workflow_preference / format / judgment / safety
avoidable_by	enum	retrieval / rule / skill / model / unknown
source_workitem_id	id	追溯发生场景
independence_group	str	同一事件链不算多个独立样本
repeat_count	int	独立复现次数

流程偏好、隐私偏好和授权边界默认只进入外部规则层，不直接进入权重训练候选。

15.9 BodyDescriptor 躯体描述

字段	类型	说明
body_id	id	设备或运行环境的稳定标识
agent_id	id	归属 Agent
owner_principal_id	id	设备管理者/所有者引用
platform / os_version	str	平台与系统版本
runtime_version	str	Body Runtime 版本
capability_refs	id[]	已发现能力引用
state	enum	online / degraded / offline / revoked / maintenance
last_seen_at	time	最近在线时间
clock_domain	str	本机单调时钟域
trust_state	enum	设备注册、校验和可信状态

15.10 Principal 与 Grant

Principal 表示用户、Agent、服务账号或组织主体；Grant 表示某主体对某资源执行特定动作的授权。

principal_id: user-001
principal_type: human        # human | agent | service | organization
role: operator

grant_id: grant-001
subject_id: user-001
resource:
  body_id: body-pc-01
  channel_id: ch-files-01
  scope: ["workspace/project-a/**"]
actions: ["read", "write"]
purpose: "workitem execution"
granted_at: 2026-11-04T09:00:00Z
expires_at: 2026-12-04T09:00:00Z
revoked_at: null

实际授权还必须包含授予来源、审批证据、策略版本和撤销事件。示例只表示结构，不代表建议的默认权限。

15.11 SelfState 自我状态快照

字段	类型	说明
body_id	id	状态所属 Body；Agent 级状态可另设 runtime_id
observed_at	time	采样时间
resource_metrics	object	CPU、GPU、RAM、显存、磁盘、温度、电量、网络等
channel_health	object[]	每个 Channel 的状态与最近心跳
worker_health	object[]	Worker 心跳、Lease、队列和检查点
inference_health	object[]	模型端点可用性、延迟、错误率和预算
budget_remaining	object	计算、调用费用、带宽或电量预算
degradation_level	enum	normal / constrained / degraded / critical
evidence_ref	uri[]	指标来源和采样证据

15.12 Observation 与 EnvironmentState

Observation 保存一次观察，不直接等于事实；EnvironmentState 是对实体在某时间范围内状态的估计。

字段	类型	说明
observation_id	id	观察 ID
entity_id	id	被观察对象；无法识别时可为空或临时 ID
body_id / channel_id	id	观察来源
observed_at	time	观察时间和时钟域
content_ref	uri	结构化观察或证据引用
provenance	enum	observed / told / inferred / verified
confidence	float / enum	置信度，必须说明标定口径
privacy_class	enum	数据分类
valid_time	interval	观察认为成立的外部时间范围

EnvironmentState 额外保存 state_version、valid_from / valid_to、transaction_from / transaction_to、supersedes 和支持证据引用。

15.13 ActionVerification 行动验证

字段	类型	说明
verification_id	id	验证记录 ID
action_id	id	对应 ActionInvocation
precondition_result	enum	passed / failed / unknown
expected_postcondition	object	预期外部状态
verification_method	str	通过什么独立方式验证
verification_result	enum	verified / failed / unknown
evidence_refs	uri[]	验证证据
verified_at	time	验证时间
compensation_action_id	id	如需补偿，关联补偿动作

15.14 TransferManifest 迁移清单

字段	类型	说明
manifest_id	id	迁移记录 ID
workitem_id / version	id/int	迁移的工作项及版本
source_body_id / target_body_id	id	迁移来源与目标
checkpoint_ref	uri	可恢复执行检查点
required_capabilities	object[]	目标 Body 必须具备的能力
evidence_refs	uri[]	最小必要证据引用
pending_actions	id[]	需要先对账的动作
authorization_refs	id[]	需要在目标 Body 重新验证的授权引用
fencing_epoch	int	防止旧 Body 继续写入的租约代次
status	enum	prepared / validated / transferred / rejected / expired

---

16. Ledger 与运行时可靠性

16.1 Ledger 是事实源，不只是普通任务表

建议采用追加式事件记录 + 可重建投影的结构：

Command（命令请求）
   ↓ 校验权限与前置条件
Event Store（追加式事件存储）
   ↓
Projection（WorkItem / WaitCondition / Assertion / Dashboard）
   ↓
Scheduler / Gate / Voice

约束：

• 所有状态修改通过 Ledger Command API；模块不能直接修改投影表。
• 事件追加成功后才确认命令成功；投影可以异步重建。
• 每个聚合（如一个 WorkItem）维护递增版本号，防止并发覆盖。
• 事件需有唯一 ID、时间、版本、来源、因果关系和 Schema 版本。
• 定期快照用于加速恢复，但快照不能替代原始事件记录。
• Ledger、原始证据与大型媒体文件分开存储；Ledger 保存受控引用和校验摘要。

16.2 至少一次投递 + 幂等处理

不要承诺跨数据库、消息队列和外部 API 的端到端「恰好一次」。工程上采用：

• 事件投递允许至少一次。
• Inbox 根据 event_id / source_event_id / dedupe_key 去重。
• Worker 任务领取使用 lease、心跳与超时恢复。
• Action Runner 对支持幂等的外部动作传递 idempotency_key。
• 不支持幂等的动作，在重试前先查询外部状态，或要求人工确认。
• 本地状态提交与待投递事件通过 Outbox 模式关联，避免「账本写成功但消息没发出」或相反。

16.3 崩溃恢复

Worker 领取任务（lease）
    ↓
记录 running + lease_owner + lease_expires_at
    ↓
执行步骤并持续写入检查点
    ↓
完成后提交结果事件

若 Worker 心跳丢失：
    ↓
Lease 到期
    ↓
Recovery 检查最后检查点与 ActionInvocation
    ↓
判断：安全续跑 / 查询外部结果 / 补偿 / 转人工处理

不能只凭 status=running 就重新启动任务。恢复前必须检查上一个动作是否已经在外部成功，避免重复提交、重复发送或重复修改。

16.4 一致性与存储建议

v0 可用单机关系型数据库作为 Ledger，媒体和大文件独立存储；事件量增长后再拆消息队列或分布式存储。第一版不需要为了「事件驱动」先引入复杂微服务。

最低要求：事务写入、唯一约束、版本控制、备份恢复、Schema Migration、审计查询。是否采用专门 Event Store，取决于原型的事件量和恢复需求，不是前置条件。

---

17. 状态机、任务调度与依赖

17.1 WorkItem 状态流转

stale 是基于进展时间计算的标记，不是主状态。暂停、取消和关闭都要留下事件与原因。自动重试必须有限次，并使用退避策略。

17.2 新任务 B 进入：五类路由判定

路由不能只看文本相似度。使用目标、产物可复用性、依赖关系和事实共享关系：

默认走独立工作项。无法明确解释为什么是同一个目标时，不允许自动合并。

17.3 调度原则

• WorkItem 并发上限是人的验收带宽和系统资源的共同约束，不是模型吞吐量指标。
• 区分 ready 队列、blocked 等待集、awaiting_user 审批集和 running 执行集。
• 依赖满足后只放行对应下游任务，不因一个事件唤醒所有 Worker。
• Worker 必须有租约、心跳、超时、取消和检查点。
• 用户明确要求立即处理、硬截止时间或高风险安全事件可覆盖普通排队策略，但不能覆盖安全权限策略。

---

18. 关键流程

18.1 事件进入：Sense → Adapter → Event Bus → L0 → L1

硬件 / 操作系统 / 应用 / 网络服务产生信息
  ↓
Channel Adapter 采集（遵守通道授权）
  ↓
本地预处理、标准化、去敏、标记来源
  ↓
EventEnvelope 写入 Inbox / Event Bus
  ↓
去重与顺序检查
  ↓
L0：匹配 WaitCondition + 设备/通道健康检查
  ├─ 未命中 → Noise Pool（采样、限额、TTL）
  └─ 命中   → 组装关联工作项与证据摘要
  ↓
L1：相关性、新颖性、延迟成本、置信度与风险判断
  ├─ 忽略：记录抑制原因
  ├─ 记账：写 Ledger，不唤醒 Worker
  ├─ 唤醒：交 Scheduler / Policy Engine
  └─ 不确定：进入候选或请求澄清，不伪装成低风险

18.2 L0：廉价、确定性、可解释的感知门控

L0 不负责理解世界，只负责把事件缩小到可能相关的工作项：

• 事件类型、来源通道、资源 ID、状态码、阈值和明确字段匹配。
• 根据 WaitCondition 索引进行倒排、前缀或哈希匹配。
• 设备离线、恢复、权限撤销、心跳丢失等系统事件走专用规则。
• 每个抑制结果记录命中的规则或未命中原因。
• 未命中事件按来源和类别分层采样；3% 仅是起始参考，不应对所有来源统一固定。

L0 不应对每一帧摄像头、每个音频采样点或每个网络包创建一个通用 Event。高频媒体输入必须先由设备侧 Adapter 做窗口聚合、事件检测或抽样。

18.3 未知事件与感知盲区

「只监听已有 WaitCondition」会产生感知盲区。解决方式不是让每条未知事件都调用模型，而是：

1. 对未命中事件按类别、来源、重要性和成本进行分层采样。
2. 设备侧先做低成本聚合，避免保存高频原始流。
3. L3 或独立 Batch Scanner 定时分析抽样数据，寻找可能的新事件模式。
4. 新模式先生成候选 WaitCondition，进入 shadow 验证。
5. 候选订阅只有通过准确率、误报率和权限检查后才启用。

噪声池不能被视为漏报保障；漏报仍需通过抽查、独立监测源和用户反馈评估。

18.4 L1：显著性、延迟成本与置信度

L1 至少评估四个维度：

• relevance：是否直接关联某工作项的目标、前提、等待条件或验收判据。
• novelty：是否带来新信息、状态变化或与已有断言矛盾；重复事件应习惯化衰减。
• cost_slope：继续延迟处理的预期边际损失。
• confidence：事件解析、来源判断和后果估计的可信程度。

可将延迟成本定义为估算框架，而不是假装能精确计算：

expected_loss(t) = P(loss | delay until t) × impact(loss)
                  + dependency_spillover(t)

cost_slope ≈ [expected_loss(t + Δt) - expected_loss(t)] / Δt

其中 P、impact 和 dependency_spillover 可以由硬规则、历史数据或受限模型估计；必须记录来源、单位和置信区间/等级。冷启动时采用 low / medium / high / critical 分档，不伪造精确小数。

判定建议：

情况	动作
相关性低、新颖性低、延迟成本低	忽略并记抑制原因
有关联但暂时不需要行动	记账，等待后续条件
验收条件改变、硬依赖解除、成本快速上升	唤醒对应 Worker
置信度低且潜在影响高	进入人工裁决或保守通知
置信度低且影响低	观察，不主动打扰

L1 模型化之前，规则旁路必须常驻，用于高危事件、权限边界和明确截止时间；模型不能覆盖硬规则拒绝。

18.5 Worker 执行与 Action Runner

Worker 被唤醒
  ↓
读取 WorkItem 投影与必要证据（最小上下文）
  ↓
制定下一步计划（goal / expected_result / done_when）
  ↓
提出 ActionInvocation
  ↓
Policy Engine 检查：身份、授权、资源、风险、环境、设备状态
  ├─ deny：拒绝并记录原因
  ├─ approval_required：等待用户批准
  └─ allow：Action Runner 在受限环境执行
  ↓
记录回执、证据和检查点
  ↓
更新 WorkItem / Assertion / WaitCondition

Worker 只能访问授权给自己的上下文与资源。工具返回的数据是不可信输入；不能把网页、邮件、文档中的指令提升为系统指令。所有高副作用动作都需要独立审计。

18.6 自动排下一步

来源	能否自动创建	附加要求
硬依赖未满足	能	挂在既有工作项上，说明为什么现在做
验收判据失败	能	记录失败原因、已尝试步骤和下一步差异，限制重试次数
设备或通道离线	能创建恢复子任务	必须受设备权限与用户策略限制，不得擅自扩大访问范围
环境中的机会性发现	默认不能	进入候选池，等待用户或预先写下的规则

每个自动生成任务必须有 goal、done_when、来源事件和父工作项；否则不能进入执行队列。

18.7 开口策略

允许主动通知的四类状态跃迁：

1. result：产出达到验收条件，等待用户接受或否决。
2. decision：继续自行猜测的成本高于请求用户裁决。
3. blocked：自身无法推进，明确说明阻塞条件。
4. correction：推翻此前已经通知用户的结论。

通知类型：acceptance_request、decision_request、status_digest、urgent_alert。普通状态摘要不应伪装成需要用户操作的请求。

节流原则：

• 同一工作项的微进展合并发送。
• 跨工作项摘要按时间窗合并。
• 24 小时是内部检查上限，不是每个工作项必须打扰用户的期限。
• 增加 Agent 全局通知预算，避免多个工作项各自合规、整体刷屏。
• 紧急通知可突破普通预算，但不能突破用户明确设置的勿扰和安全规则；涉及生命安全的特定场景另行定义。
• 非紧急信息在下一个用户在场窗口或摘要窗口投递。
• 每条消息自带上下文，且明确用户需要执行的动作；没有动作时应使用状态摘要。

18.8 自我巡检

内部 tick 检查：

检查	含义
stall	长时间没有证据化进展
contradiction	断言互斥或最新观察推翻旧事实
self_overturn	自己曾上报的结论被后续证据推翻
capacity	Worker 余量、成本、心跳、队列积压
body_health	Body 在线情况、资源、电量、温度、网络和通道健康度
permission_drift	通道授权撤销、过期、范围变化或凭据失效
action_reconciliation	外部动作状态与 Ledger 记录不一致

18.9 巩固 Pass（离线）

默认按日运行，在线链路可独立工作；巩固失败或跳过不能阻塞执行。产出：

1. 清理、更新 WaitCondition 与候选订阅。
2. 生成规则、授权档位和通知阈值的变更申请。
3. 从重复失败、纠正和停滞中生成技能/检索候选。
4. 生成训练样本包与回归计划。
5. 为规则、技能和模型变更产生版本、差异和回滚点。

巩固程序不能直接修改安全硬规则，也不能自行授予高风险设备权限。

---

19. 安全、权限与隐私边界

19.1 权限模型：动作风险 × 资源范围 × 工作项授权 × 设备授权

单一 auto / notify / ask 不足以表达设备安全。最终是否允许，应取所有约束中最严格的结果：

Effective Permission = 最严格约束(
  全局安全策略,
  动作风险等级,
  资源范围策略,
  WorkItem 授权,
  Body / Channel 本地授权,
  用户当前会话状态
)

任何一个层级拒绝，都不能被其他层级的 auto 覆盖。

19.2 动作风险分类

风险	典型动作	建议策略
R0 只读	查询状态、读取授权范围内文件、读取 CI 结果	可按范围自动
R1 可逆低影响	修改隔离工作区文件、创建草稿、生成报告	受限 auto / notify
R2 对外副作用	发送消息、提交代码、修改共享数据、执行部署前操作	默认 ask 或 notify，按具体规则
R3 高风险/不可逆	生产发布、删除数据、修改权限、转账、泄露敏感数据	独立审批或硬禁止；不得仅凭成功次数升为 auto

历史成功次数只能作为参考，不能单独成为权限升级依据。升级需绑定动作类别、目标环境、资源范围、可逆性和回滚能力。

19.3 不可信输入与提示注入

所有外部输入都按数据处理，包括：网页、邮件、IM、文件、代码注释、截图 OCR、语音转写和工具输出。

• 外部内容不能修改系统策略、授权表或 Agent 身份。
• 内容中要求读取密钥、扩大权限或外传数据时，视为待分析文本而非命令。
• 模型生成的计划不能直接执行；必须转成 ActionInvocation 并经过 Policy Engine。
• 工具输出中的 URL、命令和脚本不能自动执行。
• 对外数据传输需要目标 allowlist、数据分类和凭据代理。

19.4 凭据边界

• Worker 不直接读取长期密钥；由凭据代理在授权动作执行时注入短期凭据。
• 按 Body、Channel、WorkItem 和资源范围分配凭据。
• 日志只记录凭据引用和结果，不记录明文令牌。
• 通道撤权、设备丢失或账号变更时，支持吊销令牌与轮换。

19.5 隐私与人机共用设备

• 摄像头、麦克风、屏幕、剪贴板、位置与全局键盘输入属于敏感感知能力，应默认关闭或按需启用。
• 摄像头和麦克风应有可见运行状态、明确授权、快速暂停方式；设备有物理遮挡或硬件静音能力时优先尊重。
• 不因用户正在使用电脑，就推定同意记录所有屏幕和键盘内容。
• 对密码框、支付页面、私人聊天和敏感窗口采用默认屏蔽策略。
• 可用粗粒度在场状态进行通知排期，但不应为了判断「用户是否在场」而无边界地分析用户行为。
• 设备本地处理优先；原始媒体的保存和外传分别授权。

19.6 多租户与隔离

多租户可以后置，但在支持多个用户或团队前必须完成：租户级 Ledger 隔离、凭据隔离、Body 归属、工作目录隔离、日志访问控制和跨租户 Assertion 共享策略。

---

20. 组件划分

模块	职责	约束
agent_identity	Agent 身份、归属与策略引用	不与单一设备绑定
principal_registry	Owner、Operator、Observer、Approver 等主体和授权记录	角色不能隐式推断；委托不得扩大权限
control_plane	权威 Ledger、任务协调、策略和租约管理	明确单写者/权威端；逻辑边界不等于微服务
body_runtime	本地设备运行、资源和通道管理	每个 Body 独立运行；断网可安全降级
capability_manager	能力发现、验证、授权启停和升级	Adapter 不得自我授权
arbitration	人类与 Agent 对共享设备的控制权仲裁	资源级租约；有本地紧急停止
self_state	计算、存储、通信、通道、推理和预算状态	可以降级，不得扩大权限或关闭安全机制
time_service	时钟域、偏差、事件时间和迟到处理	时间戳不等同因果关系
environment_model	Observation、实体状态和时间性记忆	状态保留证据、置信度和有效期
verification	行动前置条件、后置验证、补偿和对账	工具回执不等于目标达成
body_registry	注册设备、运行环境、在线状态与资源指标	Body 离线可感知；支持多 Body
channel_registry	注册 Sense / Action Channel、能力、版本、权限与健康度	感知权限和行动权限分开
adapters	接入摄像头、麦克风、键鼠、文件、系统、网络、应用和服务	只采集/标准化，不做任务决策
event_bus	事件接收、去重、缓冲、路由	至少一次投递，消费者幂等
ledger	WorkItem、Event、Assertion、Action、日志的事实源	追加式事件 + 投影；唯一写入口
gate (L0)	结构化事件匹配、系统巡检	纯程序优先，零模型调用
salience (L1)	相关性、新颖性、延迟成本、置信度	规则起步，保留硬规则旁路
scheduler	tick、依赖放行、并发、预算、Worker Lease	资源与验收带宽双重限制
worker (L2)	独立上下文、计划、推理和任务执行	不得绕过 Policy / Action Runner
policy_engine	权限求值、风险分类、审批与审计决策	默认拒绝；权限取交集/最严格值
action_runner	受控执行设备和软件动作	幂等、超时、回执、补偿
voice	主动汇报、节流、多通道投递	全局与单项通知预算
consolidator (L3)	回放、规则/技能候选、变更申请	可重放、幂等、可跳过
recovery	任务恢复、动作对账、设备重连	恢复前检查外部副作用
eval	漏报抽查、质量指标、回归测试	独立于优化回路

20.1 运行部署形态

第一版建议采用单机模块化单体 + 独立 Worker 进程，不要一开始就拆成大量微服务：

桌面 PC / 服务器（Body）
├── Agent Runtime Core
│   ├── Ledger（本地数据库）
│   ├── Event Bus（进程内或轻量持久队列）
│   ├── Gate / Salience / Scheduler / Policy
│   ├── Voice / Recovery / Consolidator
│   └── Model Router（本地模型或远端 API）
├── Channel Adapters
│   ├── OS / File / Process
│   ├── Browser / IDE / Git / CI
│   ├── Keyboard / Mouse / Screen（按需授权）
│   └── Camera / Microphone（后续阶段）
└── Isolated Worker Processes / Sandboxes

后续再把设备端 Adapter 拆成边缘节点，让多个 Body 连接同一 Agent Runtime。跨设备只传必要事件与受控证据引用，不默认传输原始音视频。

---

21. 参数总表（初始值，需由影子运行校准）

参数	初始建议	说明
tick_interval	60s	事件实时性由推送保障；tick 用于兜底和巡检
lease_ttl	120s	Worker 租约起始值；需配合心跳与任务时长调整
heartbeat_interval	30s	Worker / Body 心跳起始值，设备类按资源约束调整
stale_after	7d	停滞判断；需区分正常外部等待
internal_checkpoint	24h	最长内部检查间隔，不等于强制通知
merge_n	3	同项微进展合并数量
merge_window	2h	跨项非紧急摘要窗口
interrupt_budget_per_item	3 次/周/项	单项预算
interrupt_budget_global	可配置	全局预算，按用户在场窗口调整
novelty_decay	半衰期 7d	重复事件衰减的起始值
wake_threshold	规则分档	不直接固定一个浮点数；按领域校准
confidence_floor	按风险分级	高影响低置信度进入人工裁决
crystal_repeat_k	≥ 3 个独立来源/场景	同一事件链重复不算独立样本
assertion_ttl	inferred 7d；observed 按领域设置	过期需复核，不自动永久保留
noise_sample_keep	分层采样	3% 仅为起始参考，不能保证召回
concurrency_max	5 个活跃工作项起步	同时受设备和模型资源限制
authorization_baseline	新通道 disabled，新动作类 shadow	感知与行动分别启用
raw_media_retention	默认 none	仅在明确任务和授权下设置 TTL
action_retry_max	3 次起步	不可幂等动作不自动重试

---

22. 指标与验收口径

必须成对优化，不能只降低通知次数或只追求任务完成数量。

指标	定义	目标/说明
打扰信噪比	有帮助的主动通知 / 有明确反馈的通知	初期 ≥ 0.6，成熟后争取 ≥ 0.7；无反馈单独统计
漏报率	抽样审计中应报但未报的事件比例	与信噪比同时报告；说明样本来源和置信度
事件发现召回率	独立监测源确认的应发现事件中，系统实际发现的比例	避免系统通过少监听获得虚假高信噪比
任务自主推进率	无需用户追加推动而完成的任务占比	按任务难度分层，不能鼓励无授权行动
任务恢复成功率	崩溃/断网/Worker 退出后恢复到正确状态的比例	必须包含外部副作用对账
Action 重复副作用率	重试造成重复外部操作的比例	不可逆动作目标为 0
权限违规率	未授权读取或执行次数	目标必须为 0；通过审计与负向测试验证
通道健康率	可用通道运行时间 / 预期运行时间	按 Body / Channel 分类
验收直通率	一次通过的验收比例	反映目标和验收条件质量
纠正复用率	已结晶经验的同类问题复发率	复发需检查经验落点
净能力变化	变更前后旧能力集与新能力集差值	不允许未经批准的负收益上线
未上报留痕覆盖	记录了抑制原因的抑制决策 / 全部抑制决策	必须 100%

不应把「用户主动发起次数下降」作为单独成功指标；用户可能只是放弃使用。它只能与任务质量、主动推进率和漏报率一起解释。

---

23. 里程碑与实施顺序

本路线将「先让运行时可靠，再让它感知更多、行动更深」作为硬约束。时间估计只用于安排原型，不代表每阶段必须按固定日历完成；验收门槛未通过，不进入下一阶段。

v0：运行时内核与影子账本

范围：

• Agent Identity、Principal、单 Body 注册和最小 Grant 模型。
• Ledger Event Store、投影、WorkItem 状态机、事件 Schema Version。
• Inbox 去重、Outbox、版本控制、快照和备份恢复。
• L0 基础规则、L1 规则判定、抑制原因留痕。
• Worker 仅 shadow；暂不开放有外部副作用的自动操作。

验收：进程重启后任务可恢复；重复事件不会重复生成状态；权限拒绝可审计；每个抑制决定有原因。

v0.5：第一个 Body 与低风险 Channel

范围：

• 一台桌面电脑注册为 Body，采集 SelfState。
• Channel Registry、Capability Descriptor、发现/验证/授权/撤权流程。
• 接入一个低风险 Sense Channel（指定目录文件变更或 CI Webhook）。
• 接入一个低风险 Action Channel（桌面通知、生成草稿或隔离目录写入）。
• 完成 Body offline/online、通道健康、撤权和本地紧急停止入口。

验收：事件能追溯到 Body/Channel；撤权后通道停止工作；资源不足会安全降级；系统不因设备离线丢失任务。

v1：单源任务闭环与行动后验证

范围：

• 接入一个真实事件源，优先 Git / CI。
• 打通 WaitCondition、L1、Worker、Policy Engine、Action Runner、Verification 和通知。
• 引入 ActionInvocation 前置条件、幂等、回执、独立后置验证和 Recovery 对账。
• GUI 自动化仍处于 shadow 或受限模式；实现资源级 Human-Agent Arbitration。

验收：一个工作项能自主推进到待验收；Worker 重启或回执丢失不造成重复副作用；工具报告成功但目标未达成时不会误关闭任务。

v2：多通道、多 Worker 与共享设备控制

范围：

• 接入多个软件通道和至少一个本机系统通道。
• 完成五类任务路由、依赖图、全局通知预算、Worker Lease 和取消机制。
• 完成人机控制权仲裁、全局紧急停止、凭据代理和目录/进程隔离。
• 增加多用户角色、设备所有权与审批范围。

验收：多个工作项独立运行；用户接管窗口时 Agent 不抢输入；高风险动作不会因历史成功次数自动放权。

v3：多模态感知、时间语义与环境模型

范围：

• 摄像头、麦克风、屏幕等敏感通道按需启用，先本地处理和 shadow 验证。
• 建立跨通道时间对齐、迟到/乱序处理和 Observation 模型。
• 建立有限范围 Environment Model 与 Temporal Memory。
• Batch Scanner 发现的新模式先生成候选 WaitCondition，再经过 shadow 评测。

验收：多模态关联能提供证据和不确定度；不同 Body 的冲突观察不会互相覆盖；原始媒体默认不外传、不永久留存。

v4：多 Body 连续性与能力迁移

范围：

• 第二个 Body 接入（如手机或服务器）。
• Control Plane 权威状态、Body 本地缓冲、租约和 fencing token。
• Transfer Manifest、Body 依赖识别和任务迁移。
• 网络分区下的离线策略和外部副作用对账。

验收：Body 离线不会丢失任务；可迁移任务能在重新验证权限后继续；不可迁移任务会准确等待原设备；不会出现双 Body 同时写入同一共享资源。

v5：受控技能与模型改进

范围：

• L3 巩固、规则版本化、技能/检索策略改进、回放测试。
• 收集经过治理的 L1 显著性判断样本。
• 仅在评测收益明确时尝试 L1 模型化或 Adapter 微调。
• 保留安全硬规则旁路、灰度、审批和回滚。

验收：能力改进在旧任务集和新任务集上均经过回归；任何负收益可回滚；巩固失败不影响在线系统。

阶段门槛：在 Ledger 恢复、设备权限、人机仲裁和 Action Verification 未通过前，不开放高风险自动行动；在多 Body 权威状态与租约机制未验证前，不允许跨设备并行写共享资源；在反馈样本独立性和评测体系成熟前，不进行权重迁移。

---

24. 反模式清单

1. 把对话当主体、账本当导出物。
2. 把一台设备或一个模型等同于 Agent 身份。
3. 把所有硬件输入都当成默认常开、默认可保存的数据源。
4. 把键盘感知做成全局逐键记录，或把屏幕/摄像头原始流默认上传。
5. 感知权限自动推导成行动权限。
6. Worker 绕过 Action Runner 直接调用设备或外部 API。
7. 用 embedding 相似度直接决定两个工作项合并。
8. 建立无归属、无 TTL 的常驻订阅。
9. 用「恰好一次」作为跨系统投递承诺，而没有幂等与对账设计。
10. Worker 崩溃后不核实上一次外部动作就直接重跑。
11. 用每项 24 小时通知替代内部健康检查。
12. 只统计打扰下降，不统计漏报和独立发现召回率。
13. 把 unanswered 直接当成 annoying。
14. 让 inferred 断言单独触发高风险动作。
15. 用训练解决检索、规则或授权配置问题。
16. 让 L3 未经版本化、回归测试和审批直接改变在线安全规则。
17. 让巩固 Pass 与在线链路互相阻塞。

---

25. 未决问题

1. cost_slope 在缺少历史代价数据时仍需领域规则；不同任务的成本单位如何统一，需要通过原型验证。
2. 未命中事件的分层采样能否发现足够多的新模式，召回率和采样成本尚未量化。
3. 多 Body 的 Agent 身份、Ledger 所在位置、离线缓存和冲突合并策略需要根据部署形态确定。
4. 摄像头、麦克风、屏幕和键鼠的连续感知策略需要按操作系统能力、用户授权与隐私法规分别定义。
5. 多 Worker 共享 Assertion 时，如何评估证据独立性与共同来源偏差。
6. 团队场景下的 Ledger 归属、共享 WorkItem、组织权限与人工审批人模型尚未设计。
7. L1 模型化后解释性下降，规则旁路与可解释日志需要长期保留。
8. 多租户需要在产品化前补齐；单用户原型也必须先完成凭据、目录和动作权限隔离。
9. 哪些本机感知信号可以长期保留为低成本状态指标，哪些必须事件发生后才临时采集，需要按使用场景逐项评估。
10. Control Plane 的权威位置（本机、家庭服务器或云端）如何选择，需要结合隐私、在线率、成本和数据主权验证。
11. 人机仲裁在不同操作系统、远程桌面和多显示器环境下可获得哪些可靠信号，需逐平台测试。
12. 多 Body 的时钟偏差、离线缓存保留期和迟到事件 watermark 如何按实际通道设定。
13. Environment Model 的实体标识、合并和冲突解决规则应按场景定义，不宜过早做通用世界模型。
14. 哪些动作具备真正独立的验证接口，哪些只能得到弱回执或人工确认，需形成能力目录。
15. 多用户授权、Data Subject 权利和共享家庭/办公设备的数据边界需按部署地区及适用规则进一步细化。

---

26. 与早期版本的关系

本版保留 v0.1 的核心理念：

• WorkItem 是运行时承重对象，对话是视图。
• Ledger 是事实源，Assertion 是跨 Worker 共享结论的载体。
• L0 纯程序门控，L1 显著性判断，L2 隔离 Worker，L3 离线巩固。
• 新任务默认隔离，机会性任务默认不自动执行。
• 自主学习按账本、规则、技能、权重逐层结晶。

v0.2 新增的内容在本版继续保留；v0.3 新增或强化：

• Control Plane、Body Runtime、Inference Runtime 的逻辑平面分离；明确权威状态、部署边界和模型可替换性。
• Runtime Continuity、多 Body 迁移、Transfer Manifest、租约和 fencing token。
• Human-Agent Arbitration、资源级控制权、用户接管与本地紧急停止。
• SelfState、自适应资源预算和安全降级边界。
• 跨设备时间语义、时钟不确定度、迟到/乱序和多模态时间关联。
• Capability Discovery、Descriptor、Adapter 可信验证和完整生命周期。
• Environment Model、Observation、Temporal Memory 与双时间记忆。
• Action Verification、失败补偿以及 shadow / simulation / live 执行模式。
• Principal、Owner、Operator、Observer、Approver、Data Subject 和 Grant。
• Agent Identity 与 Body / Channel 分离，支持一个 Agent 使用多个设备。
• 硬件和软件统一建模为 Sense / Action Channel。
• 引入事件封套、通道注册、设备健康、事件总线和数据生命周期。
• 引入 ActionInvocation、Policy Engine、Action Runner，分离感知和行动权限。
• 补齐 Ledger 事件一致性、幂等、Outbox / Inbox、Worker Lease 和恢复流程。
• 将 cost_slope 增加置信度和估算口径。
• 将 24 小时检查改为内部检查点，通知由全局预算与汇总策略控制。
• 把凭据、外部输入、设备隐私与执行隔离提升为第一阶段必须考虑的工程边界。

---

27. 术语表

术语	含义
Agent Identity	跨设备保持稳定的 Agent 身份
Control Plane	管理权威状态、任务和全局策略的逻辑平面
Body Runtime	在具体设备上管理通道、资源和本地行动的运行时
Inference Runtime	提供本地或远端模型推理的运行位置与路由层
Principal / Grant	主体身份及其对具体资源和动作的授权
SelfState	Agent 对自身资源、通道、Worker 和推理能力的状态记录
Environment Model	由 Observation 和证据构成的有限范围环境状态估计
Temporal Memory	同时保存事实有效时间与系统记录时间的记忆机制
Body	Agent 使用的物理设备或运行环境
Sense Channel	从硬件、系统、应用或服务接收信息的通道
Action Channel	通过硬件、系统、应用或服务执行操作的通道
Channel Adapter	将具体设备/软件接口转换为统一能力契约的适配器
Capability Registry	通道能力、权限、状态和资源成本的注册表
EventEnvelope	所有输入事件的统一封套
Ledger	任务、状态、证据、动作和反馈的事实源
WorkItem	有明确目标和验收条件的持续工作项
WaitCondition	工作项等待的结构化事件条件
Assertion	带来源、可信等级和有效期的事实或结论
ActionInvocation	一次受权限约束、可审计的行动请求
Policy Engine	计算当前动作是否被允许的策略引擎
Action Runner	实际执行外部副作用的受控组件
Action Verification	使用外部证据检查动作后置条件是否达成
Human-Agent Arbitration	人与 Agent 对共享设备和资源的控制权仲裁
Capability Discovery	发现、验证和注册设备/软件能力的过程
Transfer Manifest	任务从一个 Body 迁移到另一个 Body 的状态清单
Fencing Token	防止已过期资源租约持有者继续写入的代次标识
L0 / L1 / L2 / L3	感知门控 / 显著性判断 / 执行 / 离线巩固
Body Health	设备、系统资源和通道的健康状态

---

28. v0.3 的范围纪律

本版扩展了目标架构，但不意味着第一版必须实现所有能力。建议按以下原则控制复杂度：

1. 先有接口与安全边界，再逐步接入硬件。 第一版可以只接文件变更、CI Webhook 和桌面通知；摄像头、麦克风、全局屏幕捕获和物理执行器不是内核启动条件。
2. 先单机模块化单体，再多 Body。 Control Plane、Body Runtime 和 Inference Runtime 先作为模块边界；跨设备部署需要实际需求和故障域证明。
3. 先有 Action Verification，再扩大自动化权限。 无法验证的动作可以作为候选或人工操作，不应假装具有闭环能力。
4. 先明确谁拥有资源，再讨论共享。 多用户、多租户和跨组织共享在策略模型未明确前不应开放。
5. 先保留证据和不确定性，再构建环境模型。 不要为了看起来像「理解世界」而过早建立没有来源和时效性的长期事实。
6. 自主进化不得管理自己的安全边界。 L3 可以提出改进申请，但不能自我授予权限、关闭审计或修改紧急停止策略。

v0.3 的核心验收不是「支持了多少种传感器」，而是：Agent 在至少一个 Body 上能够持续运行、可靠记忆、正确感知、受控行动、验证结果，并在用户接管、设备离线、网络中断和进程崩溃时安全降级与恢复。