Agent OS ：五种驯服不确定性的范式
Agent OS ：五种驯服不确定性的范式
0x00 概要
可能是3年前，那时候很多人都在说AIOS，但是到了今天，恐怕Agent OS这个名词更符合目前的趋势。
本文核心论点：Agent 面临的不确定性有 6 个来源，其中 3 个——概率性主体、窗口约束、假设腐化——是在传统系统中较少遇见（或者未遇见）的。但好消息是：计算机 70 年历史已在 10 个领域积累了成熟的对抗经验。我们可以提炼这些经验为可复用的范式。即：
Agent OS Engineering = 在"执行者本身是概率性的"这一新约束下，重新组合计算机 70 年来五种驯服不确定性的成熟范式。
”
全文逻辑架构如下：
- Part 1 (WHY) ：问题空间 → Agent 面临的 6 种不确定性 + 10 领域全景 + 分布式深度对标 + 认知演进四阶段
- Part 2 (WHAT - 理论) ：五种范式 → 冗余/反馈/约束/确定性优先/隔离 → 10 领域到此 5 范式的映射 + 组合策略
- Part 3 (WHAT - 模型) ：参考架构 → 5 条全局不变量 + 4 域 10 对象 + 6 维世界模型 + 可验证性保证
- Part 4 (HOW - 架构) ：ETCLOVG 七层详解 → 每层职责 × 五种范式 + 执行环境 + 状态持久化 + 进化闭环
- Part 5 (HOW - 实践) ：工程指导 → 原则集 + 操作化阈值 + 设计自检 + 开放问题
- Part 6：总结与展望 → 终极公式 + 复杂度隐喻 + 结论
本文在草稿箱里躺了几个月，期间不停依据业界出现的信息进行刷新，现在 Opus 4.8 都出来了，因此决定还是释放出来。
0x01 Part 1: 问题空间
在构建解决方案之前，必须精确定义问题。本部分回答三个问题：
- Agent 到底面对什么样的不确定性？
- 它比传统系统难在哪里？
- 前人在哪些领域已经解决过类似问题？
1.1 不确定性的六个来源
Agent 系统的不确定性来自六个维度。其中，LLM 输出概率性是 Agent 独有的——传统程序在相同输入下永远产生相同输出。其余五个在传统系统中也有对应，但在 Agent 场景中均被放大或扭曲。
| 来源 | 性质 | 经典类比 | 可消除？ |
|---|---|---|---|
| ① LLM 输出概率性 | 认知不确定性 (epistemic) | 传感器噪声 | 部分 (约束/微调) |
| ② Tool 调用可能失败 | 偶然不确定性 (aleatoric) | 网络丢包 | 部分 (重试/冗余) |
| ③ 环境状态变化 | 外部扰动 | 硬件故障 | 不可消除 |
| ④ Context Window 有限 | 观测约束 | 传感器视野有限 | 不可消除 (物理极限) |
| ⑤ 多 Agent 并发 | 竞争条件 | 分布式并发 | 可管理 (协议) |
| ⑥ 模型升级行为漂移 | 平台演变 | ABI 变更 | 不可消除 (持续演进) |
1.2 三个独有问题
以上六种来源中，有三个在 Agent OS 中特别显著——不是因为传统系统完全没见过，而是它们在 Agent 场景下被根本性地放大了。具体来说：
- ① LLM 输出概率性 → "概率性执行主体" — 传统程序的执行者是确定性的，同样输入永远产生同样输出。LLM 不是。这是 Agent OS 与所有传统系统的根本分界线。
- ④ Context Window 有限 → "观测窗口硬约束" — 传统系统内存理论上可无限扩展，Context Window 是物理上限，意味着 Agent 永远只能看到"世界的局部投影"。
- ⑥ 模型升级行为漂移 → "假设腐化" — 传统系统升级 API 版本是低频、有文档、可测试的事件。模型升级是高频、隐式、行为不可预测的事件——你为 v1 写的 prompt、设的阈值、调的参数，v2 可能全部失效。
| # | 独有问题 | 为什么独有 | 隐喻 |
|---|---|---|---|
| A | 概率性执行主体 | 传统程序确定性执行，同样输入 = 同样输出 | "工人可能把图纸看对了但活干错了" |
| B | 观测窗口硬约束 | 传统系统内存理论上无限，可以 cache 全部状态 | "只有 128KB 内存的数据库" |
| C | 假设腐化 | 传统 ABI 稳定，程序行为不会因"升级模型"而突变，或者变化了也会通知客户 | "每三个月工具手册要重印" |
1.3 跨领域全景：计算机中"驯服不确定性"的经典实践
对于我们来说，一个好消息是：面对不确定性，计算机领域几十年来积累了丰富的对抗经验。下面这张全景图覆盖 10 个领域——注意最右边一列，它标记了每个领域的解法最终对应到哪种范式。
| 领域 | 不确定性来源 | 确定化手段 | 与 Agent 的类比 | → 范式 |
|---|---|---|---|---|
| 通信/编码 | 信道噪声 | 纠错码 (Hamming/RS)、重传 (ARQ) | Tool 调用失败 → 重试 + 校验 | 冗余 + 反馈 |
| 分布式系统 | 网络分区/延迟/宕机 | 共识协议 (Paxos/Raft)、幂等性 | 多 Agent 协调 → Leader 选举 | 冗余 + 隔离 |
| 数据库事务 | 并发竞争 | MVCC、2PC、串行化隔离 | 并发 Tool 操作 → Session 锁 | 约束 + 隔离 |
| 控制论 | 传感器噪声 + 环境扰动 | Kalman 滤波、PID 闭环 | Agent Context Window = 状态估计 | 闭环反馈 |
| 实时系统 | 调度不确定性 | WCET 分析、Rate Monotonic | Agent 超时 → 有界委托 | 约束空间 |
| 容错计算 | 硬件故障 | TMR 三模冗余、检查点恢复 | 多模型投票 → Ensemble 验证 | 冗余 + 隔离 |
| 网络协议 | 丢包/乱序/拥塞 | TCP (序号+确认+重传)、拥塞窗口 | 上下文管理 → 流量控制 | 反馈 + 约束 |
| 编译器优化 | 分支预测失败 | 投机执行 + 回滚 | Agent 规划 → 尝试 + 回滚 | 反馈 + 隔离 |
| 蒙特卡洛方法 | 采样随机性 | 大数定律 + 方差缩减 | 多次采样取最佳 → Best-of-N | 冗余 |
| 量子纠错 | 量子退相干 | 表面码/Shor 码 | 不可复制性 ≈ LLM 不可重放 | 冗余 + 约束 |
核心观察：最右列只出现了 5 个不同的答案。10 个领域、几十种具体技术，最终可以归纳为 5 种核心范式——这是 Part 2 的主题。但在这 10 个领域中，分布式系统是最接近 Agent OS 的参照域——两者共享 8 个核心问题中的 6 个，Agent 只多了一个额外维度（概率性执行者）。下面做一次深度对标。
1.4 分布式系统深度对标
理解 Agent OS 与分布式系统的映射关系，可以让我们直接复用分布式领域几十年的工程积累，而不必从零发明。而那些"不能直接复用"的部分，恰恰是 Agent OS 需要重新发明的地方。
1.4.1 8 个经典问题全景对照
经典分布式系统的 8 个核心问题：
| # | 问题 | 本质 | 经典解法 |
|---|---|---|---|
| 1 | 状态一致性 | 多节点看到不同版本 | Consensus (Paxos/Raft)、Eventual Consistency |
| 2 | 容错 | 节点崩溃 | Replication、Failover、Checkpoint |
| 3 | 分区容忍 | 网络断裂时继续工作 | CAP 选择、降级策略 |
| 4 | 幂等性 | 重试产生副作用 | Idempotency Key、Exactly-once |
| 5 | 因果排序 | 事件时序混乱 | Logical Clock、Vector Clock |
| 6 | 状态恢复 | 从故障点接续 | WAL Replay、Event Sourcing |
| 7 | 可观测性 | 跨节点因果追踪 | Distributed Tracing (Jaeger/Zipkin) |
| 8 | 协调 | 多参与者达成一致 | 2PC、Saga、Choreography |
Agent Harness 的 8 个对应问题：
| # | 问题 | Agent 语境 | 与分布式的映射 |
|---|---|---|---|
| 1 | Context 不一致 | Context Window 与真实世界状态不同步 | = 状态不一致，但原因是窗口有限而非网络延迟 |
| 2 | 推理容错 | 模型"犯错"≠系统崩溃，需要优雅降级 | = 容错，但失败模式是"语义错误"而非 crash |
| 3 | 信息分区 | Context Window 截断 = 永远只看到局部 | = 分区容忍，但分区是永久的而非暂时的 |
| 4 | Tool 幂等 | 重复调用 API 买两张机票 | = 幂等，完全同构 |
| 5 | 多 Agent 排序 | 多个 Agent 异步协作时的因果关系 | = 因果排序，完全同构 |
| 6 | 跨 Session 恢复 | 新 Context Window 从零开始 | = 状态恢复，但不能 replay 推理 |
| 7 | Trace 归因 | 哪步决策导致最终失败？ | = 可观测性，但执行路径是概率性的 |
| 8 | 三方协调 | Human + Model + Tool 达成一致 | = 协调，但一个参与者 (模型) 是概率性的 |
1.4.2 解法对号入座
注：下表中的"对应范式"和"ETCLOVG 层"引用了后续章节才正式介绍的概念。初次阅读可跳过这两列，读完 Part 2 和 Part 4 后回看。
”
| # | 问题 | Agent 解法 | 对应范式（→Part2） | ETCLOVG 层（→Part4） |
|---|---|---|---|---|
| 1 | Context 不一致 | Session + Durable Artifacts + Session Start Protocol | 闭环反馈 | C + L |
| 2 | 推理容错 | 约束层级 (INV-D) + Feature passes | 约束 + 反馈 | V + G |
| 3 | 信息分区 | Context Engineering = 永久分区下的降级 | 反馈 + 确定性优先 | C |
| 4 | Tool 幂等 | Idempotency Key + progress.txt 防重做 | 约束空间 | T |
| 5 | 多 Agent 排序 | Event 时间戳 + trace_id + Compaction | 约束空间 | O |
| 6 | 跨 Session 恢复 | Fact Log (非 Command Log) + Durable Artifacts | 隔离 + 反馈 | C + E |
| 7 | Trace 归因 | 多次 Trace 统计归因 | 冗余 + 反馈 | O |
| 8 | 三方协调 | 双层 Grant = Agent 版 2PC | 隔离 + 约束 | G |
状态恢复的根本区别（最值得强调） ：
| 维度 | 分布式 | Agent |
|---|---|---|
| 日志内容 | Commands (可重跑) | Facts (不可重跑) |
| Replay | 确定性 | 不能 replay 推理 |
| 恢复精度 | 精确 | 有损 |
1.4.3 Event Sourcing — 两个世界的共同解
Event Sourcing（事件溯源）是一种软件架构模式，通过将系统状态变化记录为不可变的事件序列来替代直接存储当前状态，支持状态重建、完整审计和历史回溯。
| AgentOS | Event Sourcing | 区别 |
|---|---|---|
| Session | Append-only Event Log | 存 Facts 非 Commands |
| Harness | 事件消费 + 状态重建 | 不能 replay 推理 |
| Sandbox | Side Effects | 可能不可逆 |
| wake(sessionId) | Resume | 从事实投影恢复 |
1.4.4 复用 vs 重造
可直接复用：
| 分布式经验 | AgentOS 应用 |
|---|---|
| Event Sourcing | Session = append-only fact log |
| Idempotency Key | Tool call dedup |
| Trace ID propagation | Agent trace_id 贯穿 |
| Circuit Breaker | Tool 连续失败→切策略 |
| Sidecar Pattern | Agent 的 Sidecar |
| Control/Data Plane | Brain (决策) / Hands (执行) |
| Graceful Degradation | Context 不足时降级 |
需要重新发明：
| 分布式解法 | 为什么不能直用 | Agent 替代 |
|---|---|---|
| 确定性 Replay | 模型概率性 | Fact Log + 投影 |
| 自动 Gossip | 单向 Context Window | 主动 Retrieval |
| 固定超时重试 | 语义错误不因重试消失 | 反馈 + 换策略 |
| 静态配置 | 假设会腐化 | Feature Gate + Adaptive |
1.5 认知演进 — 四个工程阶段
以上是从横向（领域对标）看清全局。从纵向（时间演进）来看，Agent 系统的认知本身经历了四个阶段。每一个阶段都在回答一个更深层次的问题。
| 阶段 | 时间 | 核心问题 | 焦点 |
|---|---|---|---|
| Prompt Engineering | 2022-2024 | 给模型什么输入？ | prompt 文本 |
| Context Engineering | 2025 | 模型每步看到什么？ | 上下文管理 |
| Harness Engineering | 2025-2026 | 整个执行环境如何工程化？ | 完整基础设施 |
| Agent OS | 2026- | 如何构建概率性执行者的操作系统？ | 平台化治理 |
四次跃迁的本质：
Prompt Eng = 单次优化 (手工调一条 prompt, 期望一次成功)
Context Eng = 多轮管理 (设计 Context Window 的填充/压缩/检索策略)
Harness Eng = 系统工程 (7 层基础设施 + 状态管理 + 安全治理 + 可观测 + 评估)
Agent OS = 平台工程 (持久工作区 + 身份 + 多租户 + 跨 Agent 协调 + 生态治理)
关键转折点: "模型能力不再是瓶颈 → Harness/OS 成为约束瓶颈"
即: Agent 的表现上限不仅取决于 LLM 有多强，还取决于基础设施能提供多好的执行环境。
这意味着 Agent OS 工程的核心竞争力从"谁的 prompt 写得好"转移到"谁的 Runtime + 验证 + 安全基础设施更完备"——这正是本文要解决的问题。
1.6 ETCLOVG：业界已有的架构框架
CMU、Yale、Amazon 等机构的研究者近期发布综述论文《Agent Harness Engineering: A Survey》，将 Agent Harness 放到独立系统层的位置上，提出了 ETCLOVG 七层架构：执行（Execution）、工具（Tooling）、上下文（Context）、生命周期（Lifecycle）、可观测性（Observability）、验证（Verification）与治理（Governance）。这七层将在 Part 4 中作为我们的架构骨架逐一展开。但在此之前——我们先从理论出发，把 10 个领域的分散经验提炼为可复用的核心范式。
0x02 Part 2: 理论基础
Part 1 遍历了 10 个领域的对抗经验，并在 1.3 的表格最右列标注了每个领域对应的范式类型。现在我们要做的是归纳：把这些分散的标注统一成 5 种可复用的范式。
每种范式不是"发明"，而是"识别"——它们早已在工程实践中被反复验证。Agent OS 的任务是在正确的位置组合应用它们。
2.1 范式总览
不确定性 (概率、噪声、故障)
|
├─ 冗余 + 投票 —— "多试几次" "取最好的"
├─ 闭环反馈 —— "试了检查" "错了修正"
├─ 约束空间 —— "不让你错" "框住行为"
├─ 确定性优先路由 —— "能确定就" "不要猜"
└─ 不可逆隔离 —— "错了也没" "大事"
五种范式各有分工，按从"最直接"到"最保守"的顺序展开。
2.1.1 范式一：冗余 + 投票
原理：用多个独立副本/采样对冲个体失败概率。
| 经典领域 | 实现 | Agent OS 映射 |
|---|---|---|
| 航天 | TMR | 多模型 Ensemble |
| 通信 | 纠错码 | 多次采样 + Verifier |
| 存储 | RAID | 多 Agent 交叉验证 |
| ML | Bagging | Best-of-N 采样 |
Agent OS 应用：
| 场景 | 设计 | ETCLOVG 层 |
|---|---|---|
| LLM 输出不稳定 | Best-of-N + 确定性 Verifier 打分 | V |
| 单模型有盲区 | 多模型 Ensemble | L |
| 代码正确性 | 多 Agent 交叉 Review | L + V |
| Tool 可能失败 | 多路径尝试 + 比对 | T |
设计原则：
- R1：对高价值决策，用确定性 Verifier (测试通过率) 而非第二个 LLM 做投票裁判。
- R2：冗余的上限是 Verifier 质量。没有好 Verifier 时，冗余退化为浪费。
适用条件：高价值、低频、允许延迟。N 次采样 = N 倍 Token 成本。
冗余解决的是"个体可能失败"的问题。但如果失败不是随机的而是系统性的呢？——比如，模型对某类任务总是犯错，重试 10 次也没用。这就需要第二种范式。
2.1.2 范式二：闭环反馈
原理：执行 → 观测 → 比对期望 → 修正。通过持续修正收敛到目标。
| 经典领域 | 实现 | Agent OS 映射 |
|---|---|---|
| 控制论 | PID / Kalman | Context 管理 = 状态估计 |
| 网络 | TCP ACK + cwnd | Token Budget 闭环 |
| 强化学习 | Policy Gradient | 策略切换 |
Agent OS 应用：
| 场景 | 闭环设计 | ETCLOVG 层 |
|---|---|---|
| 任务执行 | Verify-then-Act Loop | V + L |
| Context 管理 | Kalman 式 Retrieval (预测→加载→验证) | C |
| 工具学习 | 失败→分析→换策略 (非简单重试) | T + L |
| 成本控制 | Token Budget 实时监控 & 调整 | O |
设计原则：
- F1：Agent 执行循环 = Sense-Think-Act-Verify。Verify 不可省略。
- F2：反馈信号必须来自 Agent 外部 (测试结果、环境状态)，不能是自我评估。
- F3：失败后应"换策略"而非"简单重试"——语义错误不因重试消失。
闭环反馈能修正已发生的错误。但更好的策略是：让错误根本无法发生。
2.1.3 范式三：约束空间
原理：不修正错误，而是让错误不可能发生。通过缩小行为空间消除不确定性。
| 经典领域 | 实现 | Agent OS 映射 |
|---|---|---|
| 编程语言 | 类型系统 / Rust borrow checker | Structured Output |
| 形式化验证 | Model Checking | Feature List 枚举 |
| OS | Capability 模型 | Tool 白名单 |
| 硬件 | IOMMU/MMU | Sandbox 文件/网络限制 |
Agent OS 应用：
| 场景 | 约束设计 | ETCLOVG 层 |
|---|---|---|
| LLM 输出格式 | JSON Schema / Structured Output | T |
| 工具权限 | Capability 白名单 | G |
| 操作范围 | Sandbox 文件系统/网络限制 | E |
| 状态变更 | Feature List 枚举空间 | L |
| Prompt 注入 | 输入净化 + 分离架构 | G |
约束层级 (Defense in Depth) ：
可靠性：低 -------------------------------------------------------------------- 高
Prompt 约束 → 结构约束 (JSON) → 环境约束 (Sandbox) → 验证约束 (E2E) → 人确认
(可被忽略) (中等可靠) (高可靠) (高可靠) (最终)
设计原则：
- C1：Defense Comes Outside the Model。安全约束永远在模型外部施加。
- C2：能用 Schema 约束的，不用 Prompt。能用环境约束的，不用 Schema。
- C3：约束空间可动态调整——随信任建立逐步放宽 (渐进信任)。
约束缩小了行为空间，但有些场景既不能约束也不能修正——因为存在确定性的解法。为什么还要让 LLM 猜？
2.1.4 范式四：确定性优先路由
原理：当确定性方案和概率性方案都能达成目标时，优先选择确定性方案。
| 领域 | 确定性优先 | 概率性 Fallback |
|---|---|---|
| 编译 vs 解释 | AOT 编译 | JIT |
| 路由 | 静态路由表 | 动态路由 (OSPF) |
| 渲染 | 预渲染静态页 | 动态 SSR |
| 搜索 | 索引精确查找 | 向量检索 |
Agent OS 应用：
| 场景 | 确定性路径 | 概率性 Fallback |
|---|---|---|
| 执行意图 | CLI/API (确定性) | GUI 操作 (概率性) |
| 信息获取 | MCP 结构化查询 | LLM 摘要 + 搜索 |
| 代码修改 | AST/结构化编辑 | LLM 生成 diff |
| 状态查询 | 读数据库/文件 | LLM 从 Context "回忆" |
PhoneHarness 项目的实验数据佐证了这一排序：CLI (确定性) 成功率达 ~99%，MCP (确定性) ~95%，GUI (概率性) ~70%。路由策略本身的收益大于模型能力提升的收益。
设计原则：
- D1：同一意图的路径按确定性排序：Rule > API > CLI > MCP > GUI > Free-form LLM。
- D2：路由决策不应由 LLM 做——用规则引擎判断是否有确定性路径。
- D3：每新增一条确定性路径 = 永久消除该场景的不确定性——Tool 建设是最高 ROI 投入。
前四种范式都假设"错误可恢复"。但如果错误是不可逆的呢？删了的文件、发出的邮件、转出的资金——没有 Ctrl-Z。
2.1.5 范式五：不可逆隔离
原理：把不确定性造成的损害限制在可回滚/可承受的范围内。
| 经典领域 | 实现 | Agent OS 映射 |
|---|---|---|
| 数据库 | 事务 + Rollback | Checkpoint 恢复 |
| 文件系统 | Copy-on-Write | 操作前保存状态 |
| 容器 | Namespace 隔离 | Trust Domain 隔离 |
| 金融 | 预授权→确认 | Grant 门控 |
| 航天 | 安全模式 | 有界委托 |
Agent OS 应用：
| 场景 | 隔离设计 | ETCLOVG 层 |
|---|---|---|
| 不可逆操作 | Grant 门控 (支付/邮件/物理动作→人确认) | G |
| 文件修改 | Checkpoint/Snapshot | E |
| 多 Agent | Trust Domain 隔离 (不共享凭证) | G |
| 探索性任务 | Sandbox 副本 (试错后才 Commit) | E |
| 长任务 | 有界委托 (步骤/时间/资源上限) | L |
不可逆度分级：
可逆 ←------------------------------------------→ 不可逆
读取 写文件 发消息 API 调用 支付 物理动作
(自动) (快照) (可撤？) (幂等？) (人确) (禁止)
设计原则：
- I1：按不可逆度分级，越不可逆越需要强门控。
- I2：Agent 默认操作空间 = "完全可逆"。进入不可逆区域需 Grant 升级。
- I3：有界委托——任何 Agent 任务必须有 Step/Time/Resource Limit。无限委托 = 无限风险。
2.2 组合策略
2.2.1 单一范式不够
真实系统从不依赖单一范式。比如，TCP = 冗余 (重传) + 反馈 (ACK) + 约束 (窗口大小)。Agent OS 的关键路径同样需要叠加。
2.2.2 Agent OS 关键路径的叠加
| 关键路径 | 范式组合 | 具体实现 |
|---|---|---|
| 代码生成 | 确定性优先 + 冗余 + 反馈 | AST 编辑优先 → Best-of-N → 测试循环 |
| 不可逆操作 | 隔离 + 约束 + 反馈 | Grant + Capability 白名单 + 执行后验证 |
| 长任务执行 | 反馈 + 隔离 + 约束 | 检查点 + 有界委托 + Feature passes |
| 多 Agent 协作 | 约束 + 冗余 + 隔离 | Trust Domain + 交叉验证 + 凭证隔离 |
| Context 管理 | 反馈 + 确定性优先 | Kalman 更新 + 优先读文件 > 靠记忆 |
2.2.3 设计决策流程
1. 识别不确定性来源
├─ LLM 输出？→ 【冗余 + 投票】或【约束空间】
├─ Tool 失败？→ 【闭环反馈】或【确定性优先路由】
├─ 并发竞争？→ 【不可逆隔离】
└─ 观测不全？→ 【闭环反馈】
2. 判断操作可逆性
├─ 完全可逆 → 允许自动 + 反馈修正
├─ 部分可逆 → Checkpoint + 约束
└─ 不可逆 → 强制【隔离】+ Grant
3. 判断是否存在确定性替代
├─ 有 → 【确定性优先】, LLM 做 Fallback
└─ 无 → 【冗余】+【反馈】组合
4. 确认：至少一种范式已应用 ✓
关键路径至少两种 ✓
2.2.4 ROI 排序
- 确定性优先路由 — 投入一条 CLI 路径 = 永久消除不确定性
- 约束空间 — 一次性设计成本，零运行时成本
- 闭环反馈 — 通用性最强，所有子系统都需要
- 不可逆隔离 — 安全底线，不做就是负债
- 冗余 + 投票 — 效果好但成本高，用于关键决策
Part 2 小结：五种范式构成了 Agent OS 的理论"武器库"。每种范式对应特定的不确定性类型，关键路径上必须叠加两种以上。ROI 最高的是确定性优先路由。下一步——在将这些范式映射到具体架构之前——需要先建立系统的状态模型：Agent 到底"知道"什么？这些知识如何结构化表示？
0x03 Part 3: 状态基石
Part 2 给出了"用什么范式"。但在落地为七层架构之前，还需要回答一个更根本的问题：Agent 到底"知道"什么？这些知识如何结构化表示？谁能写、何时写、冲突如何解？
本部分建立 Agent OS 的状态基石：5 条全局不变量为后续架构提供跨层约束；4 域 10 对象定义了系统骨架；6 维世界模型让 Agent 的认知可结构化、可量化；可验证性保证确保系统属性不仅被实现，还能被证明正在工作。状态持久化（Checkpoint）和写入协议的具体实现放在 Part 4（架构层）和 Part 5（工程实践）中展开。
3.1 全局不变量 (Canonical Invariants)
以下定义在全文中多次引用，此处为唯一标准版本。后文用编号引用，不再重述。
| ID | 不变量 | 含义 |
|---|---|---|
| INV-S | Session = append-only fact log | 唯一事实源，记录发生了什么 (facts, 非 commands) |
| INV-C | Context Window = Session 的有损投影 | 状态估计，非完整状态 |
| INV-D | 约束层级: Prompt < Structure < Environment < Verification < Human | 可靠性递增，Defense in Depth |
| INV-R | 路径排序: Rule > API > CLI > MCP > GUI > Free-form LLM | 确定性递减，优先走确定性路径 |
| INV-P | progress.txt 等派生文件 = Session 的缓存，可重建 | 唯一事实源仍是 Session |
不变量之间的关系：
- INV-S 和 INV-C 定义了状态的存储和投影关系——一切状态管理围绕这对关系展开
- INV-D 和 INV-R 分别对应约束空间范式和确定性优先范式的操作化
- INV-P 是 INV-S 的推论：既然 Session 是唯一事实源，派生物必须可从中重建
3.2 系统结构：4 域 10 对象
有了不变量，下一步是定义"系统里有什么"——即状态本体论。
| 域 | 对象 | 作用 |
|---|---|---|
| 执行域 | Agent / Task / Step / Artifact | 谁在做、做什么、做到哪、产出什么 |
| 能力域 | Capability / Context | 能调什么、当前上下文 |
| 治理域 | Grant / Audit | 谁授权、做了什么 |
| 记忆域 | Episode / Observation | 经验回放与多模态观察 |
Task 9 状态机：submitted → planning → waiting_grant → running → waiting_external → completed | failed | canceled | rolled_back
3.3 世界模型：6 维认知表示
定义了"系统有什么"之后，下一个问题是：Agent 如何认知这个世界？
3.3.1 认知状态的工程价值
认知不确定度的显式表示是当前 Agent 系统最大的缺失：
| 现状 (隐式) | 目标 (显式) | 工程价值 |
|---|---|---|
| Agent 不知道自己不确定 | 每个信念标注置信度 | 知道何时该验证 |
| 盲区无法检测 | 主动 probing 发现盲区 | 减少 hallucination |
| 决策无风险量化 | 不确定度 → 风险评分 | 自动判断是否需要人确认 |
3.3.2 Agent & 世界模型
论文General agents contain world models指出，任何能够泛化到多步骤目标导向任务的智能体都必须学习其环境的预测模型。即，如果一个 AI 智能体能够处理复杂的、长期的任务，那么它一定学习过一个内部世界模型——我们甚至可以通过观察智能体的行为来提取它。
因此，我们以手机Agent为例，来看看这个领域中，Agent的世界模型应该是什么样子。
3.3.3 六维模型
World Model
├── 1. 环境状态 (Environment)
│ ├── 文件系统 (存在/内容摘要/最后修改时间)
│ ├── 应用状态 (运行中 App/当前界面/后台任务)
│ ├── 设备状态 (网络/电量/传感器/屏幕)
│ └── 外部服务 (API 可用性/配额/延迟)
│
├── 2. 任务状态 (Task)
│ ├── 目标树 (Goal → SubGoal → Action)
│ ├── 进度 (完成/进行中/阻塞)
│ ├── 依赖图
│ └── 约束 (deadline/资源/权限)
│
├── 3. 认知状态 (Epistemic) ← 最关键的创新点
│ ├── 确信区域 (Agent 有信心的事实)
│ ├── 不确定区域 (事实 + 不确定度量化)
│ ├── 已知未知 (Agent 知道自己不知道的)
│ └── 未知未知/盲区 (最危险)
│
├── 4. 用户状态 (User)
│ ├── 当前意图 (显式 + 推断)
│ ├── 偏好/历史模式
│ ├── 信任级别 (影响 Grant)
│ └── 注意力/可用性 (影响 HITL 时机)
│
├── 5. 时间状态 (Temporal)
│ ├── 因果链 (A 导致了 B)
│ ├── 时间约束 (deadline/超时)
│ └── 变化率 (快变/慢变状态区分)
│
└── 6. 社会状态 (Social)
├── 其他 Agent 的能力/当前状态
├── 权限关系
└── 通信拓扑
3.3.4 世界模型与五种范式的对应
| 世界模型维度 | 主力范式 | 设计意义 |
|---|---|---|
| 环境状态 | 确定性优先 (直接读取) + 反馈 (验证) | 优先读文件/DB, 不靠记忆 |
| 任务状态 | 约束空间 (Feature List 枚举) | Task 只在声明空间内变更 |
| 认知状态 | 闭环反馈 (Kalman 式更新) | 持续修正信念 |
| 用户状态 | 不可逆隔离 (Grant 分级) | 不确定用户意图时→问人 |
| 时间状态 | 不可逆隔离 (Checkpoint) | 关键时刻快照 |
| 社会状态 | 约束空间 (Trust Domain) | 结构性限制交互 |
3.3.5 信念-现实漂移感知
世界模型最大的风险：Agent 的信念与现实不同步而不自知。
因此需要做相应处理。
漂移检测流程:
1. 对关键信念定期 probing (读文件/查状态/API 调用)
2. probing 结果与当前信念比对
3. 漂移超过阈值 → 触发世界模型更新 + 可能重新规划
类比:
INS (惯性导航) = Agent 基于历史的推断
GPS 校正 = 主动 probing 真实环境
INS + GPS 融合 = 世界模型的 Kalman 更新
3.4 可验证性保证 (Verifiability Guarantees)
可控、可恢复、可持续优化是系统的运行时属性。可验证则是元属性——它保证其他三个属性确实在工作，而非仅仅被声称。
| ID | 保证 | 含义 | 服务于 |
|---|---|---|---|
| P1 | Output Provenance (输出溯源) | 每个 Agent 输出附带完整证据链：触发源→路由决策→执行证据→验证判定 | 可控 |
| P2 | State Traceability (状态可追溯) | 任何系统状态变更可追溯到：用户意图→Grant→Task→Action→状态变化 | 可恢复 |
| P3 | Invariant Monitoring (不变量守护) | 5 条 INV 的运行时持续校验，违反即告警 + 进入 safe mode | 可控 + 可恢复 |
| P4 | Decision Reproducibility (决策可复现) | 给定 fact log 切片，可重建当时的 Context Window 和决策依据 | 可持续优化 |
| P5 | External Auditability (外部可审计) | 第三方可独立验证系统行为，不依赖系统自身声称 | 合规 + 信任 |
Part 3 小结：不变量定义了"铁律"，本体论定义了"骨架"，世界模型定义了"认知"，可验证性保证了"可信"。有了这套状态模型，下一步就是将五种范式和状态基石映射为可工程化的七层架构。
0x04 Part 4: 七层架构 — ETCLOVG 详解
ETCLOVG 不是凭空设计的七层——它是对 Agent Harness 生态 138+ 项目的归纳分类。本部分将每层与五种范式交叉，标注端云差异，重点展开 L 层的执行流水线和进化闭环。状态持久化（Checkpoint）和写入协议的具体机制也在此展开。
4.1 架构总览
控制平面 (Control Plane)
O: Observability | V: Verification | G: Governance
结构核心 (Structural Core)
E: Execution | T: Tool | C: Context | L: Lifecycle
各层 × 范式矩阵如下：
| ETCLOVG 层 | 冗余 | 反馈 | 约束 | 确定性优先 | 隔离 | 主力范式 |
|---|---|---|---|---|---|---|
| E Execution | △ | △ | ★★★ | ★ | ★★ | 约束 + 隔离 |
| T Tool | ★ | ★★ | ★★★ | ★★★ | △ | 确定性优先 |
| C Context | △ | ★★★ | ★ | ★★ | △ | 闭环反馈 |
| L Lifecycle | ★★ | ★★★ | ★ | ★ | ★★ | 反馈 + 隔离 |
| O Observability | △ | ★★★ | △ | ★★ | △ | 闭环反馈 |
| V Verification | ★★★ | ★★ | ★ | △ | △ | 冗余 + 投票 |
| G Governance | △ | △ | ★★★ | ★ | ★★★ | 约束 + 隔离 |
4.2 E – Execution Environment
| 端上 | 云端 | |
|---|---|---|
| 沙箱 | OS 权限 + TEE | microVM / Docker |
| 生命周期 | 常驻 + 功耗唤醒 | 按需创建/销毁 (Cattle) |
| 约束 | 内存/功耗/散热 | 成本/并发/启动延迟 |
共享接口：provision(spec) → id / execute(id, cmd) → result / destroy(id)
4.3 T – Tool Interface & Protocol
统一接口：execute(name, input) → result
确定性优先路由 (INV-R 的具体实现)：
Agent 收到任务 →
有 Rule/规则直接决定？→ 执行规则 (确定性最高)
能用 API 完成？→ API 调用 (确定性、有 Schema)
能用 CLI 完成？→ CLI (确定性、快、可审计)
能用 MCP 协议？→ MCP (确定性、可审计)
必须 GUI? → GUI Controller (概率性，最后手段)
标准排序 (INV-R): Rule > API > CLI > MCP > GUI > Free-form LLM
Capability Broker：注册、发现、5 维风险标签、affordance 向量检索。
4.4 C – Context & Memory
核心设计 (参见 INV-S / INV-C)：
- Session = append-only fact log (完整真相，INV-S)
- Context Window = Session 的投影 (有损估计，INV-C)
- World Model = Agent 对环境的结构化认知 (含不确定度，详见 §3.3)
Memory 四类 (生命周期 × 权限 × 删除机制)：
| 类型 | 寿命 | 删除 |
|---|---|---|
| Ephemeral Context | task 结束 | 自动 |
| Episodic Memory | 长期 | 用户主动 |
| Preference Memory | 永久 | GDPR |
| KVCache Memory | 推理周期 | LRU |
Compaction 4 策略：Auto / Micro / Reactive / History Snip
Context Anxiety (窗口焦虑)
模型接近 Context Window 上限时表现出的行为漂移——这是 INV-C (Context = 有损投影) 在实践中的直接后果：
症状：提前收工 (模型"感觉"快满了→草率完成)、遗忘早期指令 (前面的 system prompt 被挤出注意力)、决策质量下降 (长 Context 稀释关键信息的权重)。
对抗策略：
- 上下文管理策略插件化 (Harness 控制何时压缩，非硬编码阈值)
- Feature Gate 远程热切换压缩策略 (无需重启)
- 关键指令在 Context 末尾重复锚定 (recency bias 利用)
- 监控"Context 利用率"指标，超过 70% 触发主动压缩
核心认识：Context Window 管理不是"满了才压缩"，而是一个持续运行的状态估计系统 (INV-C)。
4.5 L – Lifecycle & Orchestration
L 层是七层中最复杂的一层——它编排推理循环、管理执行流水线、驱动进化闭环。
4.5.1 四层结构
| 层 | 变化频率 | 职责 |
|---|---|---|
| Meta-Harness/AOC | 季度 | 编排多 Harness |
| Harness | 周/月 | 推理循环 + Context Eng + Feature Gate |
| Runtime | 年 | Session / Tool / Security / Ontology |
| Execution | 随时 | 按需创建销毁 |
4.5.2 执行模式
- 双 Agent (Long-Running)：Initializer → 200+ features; Coding Agent → 增量完成
- Outer/Inner Agent (实时交互)：Outer 规划路由，Inner GUI 执行 (有界委托)
- 异步事件驱动：事件→Harness→异步派发→结果回流→任意 Worker 继续
4.5.3 Harness 5 阶段执行流水线
来源：ContextSearch (火山引擎) 验证的工程模式——将单次 Agent 执行拆成固定阶段，使得每一步可恢复、可审计、可复盘。
Admission → Prepare → Execute → Finalize → Persist
・输入校验 ・装配数据源 ・调用 LLM ・结果校验 ・写 Session
・边界控制 ・加载工具 ・路由 Tool ・证据链检查 ・写 Audit
・Grant 预检 ・权限注入 ・多步推进 ・答案溯源 ・写 Trace
・预算分配 ・Context 组装 ・中间状态 ・质量评估 ・触发回调
↑ ← ← ← ← ← ← ← ← 失败时回退到最近成功阶段重试 ← ← ← ← ← ← ↓
每阶段的价值：
| 阶段 | 解决的问题 | 失败时行为 |
|---|---|---|
| Admission | 拒绝不该执行的请求 (越权/超预算/格式错误) | 直接拒绝 + 告知原因 |
| Prepare | 确保执行环境就绪 (工具/数据源/权限/Context) | 回退到 Admission 重新评估 |
| Execute | 实际推理和工具调用 | 超时/失败 → 可从断点恢复 |
| Finalize | 验证结果是否被执行证据支撑 (非让 LLM 自评) | 结果标记"未验证" + 人工确认 |
| Persist | 将执行全过程写入持久层 (Session + Audit + Trace) | 阻塞直到写成功 (数据不能丢) |
4.5.4 Checkpoint：持久化锚点
三种快照粒度：
| 粒度 | 触发条件 | 内容 | 恢复方式 |
|---|---|---|---|
| 全量快照 | 里程碑/人确认后 | 完整世界模型 + 系统状态 | 直接加载 |
| 增量快照 | 每步/每 N 步 | 状态变更 delta | 全量 + apply deltas |
| 事件驱动快照 | 进入不可逆区域前 | 当前状态 + 回滚路径 | 事务式恢复 |
恢复协议：加载最近全量快照 → 重放增量 delta → 验证恢复后世界模型与环境一致 → 不一致项重新 probing
与 Session 的关系：Session = 事件流 (what happened, append-only)；Checkpoint = 状态快照 (what is, point-in-time)。两者互补：Session 保证不丢事实；Checkpoint 加速恢复。
4.5.5 状态写入所有权
| 状态层 | 可写入者 | 写入触发 | 只读消费者 |
|---|---|---|---|
| Session (fact log) | Harness (代理 Agent 追加) | 每次 Tool 调用/Agent 输出/外部事件 | Agent (通过 Context Window 投影) |
| Structure (4 域 10 对象) | Orchestrator 层 (L) | Task 创建/完成/失败/状态机迁移 | 所有层可读 |
| World Model (认知) | 仅 Verifier/Probing 结果 | probing 返回、E2E 验证完成、用户反馈 | Agent 推理时读取 |
| Checkpoint | Persistence 层自动触发 | 定时/事件驱动/增量 | 恢复时由 Harness 加载 |
多 Agent 冲突解决：
| 冲突场景 | 解决策略 |
|---|---|
| 多 Agent 同时更新同一 Task | Last-Write-Wins + 冲突事件追加到 Session |
| World Model 信念矛盾 | 以最新 probing 结果为准；旧信念降级为 uncertain |
| Checkpoint 并发写入 | 每个 Agent 独立 Checkpoint 空间；跨 Agent 恢复需协调者 |
核心不变量：Agent 永远不能直接写 Session（只能通过 Harness 代理追加）；World Model 更新必须有 provenance 标注；任何状态变更在 Session 中有对应 fact 记录。
4.5.6 Trace→Skill 进化闭环 (O 层反哺 L 层)
在线执行产生 Trace
↓
离线分析 (批量 Trace 聚合)
├─ 高频路径 → 沉淀为 Skill (固化路由，减少推理)
├─ 失败模式 → 策略优化 (调整路由/工具选择/Context 组装)
├─ 小模型路由 → 训练轻量分类器 (预测 Skill/datasource)
└─ 评测样本 → 回灌自动评测 (V 层持续校准)
结果:
每一次成功执行 = 系统变得更确定 (新 Skill = 新的确定性路径)
每一次失败执行 = 系统学会避免 (路由策略更新)
关键洞察：这个闭环使得"确定性优先路由" (INV-R) 不只是静态的人工封装，而是动态增长的——系统通过 Trace 分析自动发现可以固化为规则的模式，持续扩大确定性路径覆盖率。这也解释了为什么 D3 原则 (每条新确定性路径 = 永久消除不确定性) 的 ROI 最高——系统能自动产出新路径。根据 ContextSearch 项目的工程报告，确定性路径覆盖率可从初始 ~30%（人工封装）提升到运行数月后的 ~60-70%。
4.6 O – Observability
Trace 是一等评估对象，非仅调试材料。
O.1 全链路 Tracing (Session Event → Trace → Span)
O.2 Token/成本追踪 + Context 利用率
O.3 Agent 健康指标 + 告警
O.4 Session 回放
O 层与 L 层通过 Trace→Skill 进化闭环形成正反馈回路。
4.7 V – Verification & Evaluation
测试层级：Unit → API → Browser E2E → 视觉 → Trace-native → 副作用验证
副作用验证 (范式：闭环反馈 + 确定性优先)：
- 传统验证：Agent 说"我完成了" + 截图看起来对 → pass (脆弱)
- 副作用验证：检查预期副作用是否真实发生 → pass (可靠)
Feature List 模式：JSON 枚举所有 features，只允许改 passes 字段。
4.8 G – Governance & Security
| 端上 | 云端 | |
|---|---|---|
| 信任根 | 硬件 TEE | Software Vault + HSM |
| 凭证隔离 | 物理不可访问 | Network Policy + Proxy |
双层 Grant：任务级 (资源边界) + 步骤级 (单次高风险)
Trust Domain 三圈：A=TEE (不与 LLM 交互) / B=Runtime / C=External
4 道 Prompt Injection 防线：输入隔离 → 输出校验 → Capability 白名单 → HITL
4.9 七层结构化总览
| 层 | 核心职责 | 主力范式 | 失败模式 | 关键指标 | 端云差异 |
|---|---|---|---|---|---|
| E Environment | 隔离执行、资源限制 | 约束空间 + 不可逆隔离 | 逃逸、资源耗尽 | 逃逸率、冷启动延迟 | 端: TEE; 云: 容器/VM |
| T Tool | 统一接口、路由、幂等 | 确定性优先路由 | Tool 调用失败、路由错误 | 确定性路径覆盖率、调用成功率 | 端: 本地 CLI 优先; 云: API/MCP 优先 |
| C Context | 事实存储、投影、记忆管理 | 闭环反馈 | Context 丢失、信念漂移 | Context 利用率、漂移检测率 | 端: 本地 SQLite; 云: 分布式存储 |
| L Lifecycle | 推理循环、编排、Feature Gate | 闭环反馈 + 不可逆隔离 | 死循环、策略失配 | 步数/任务、Feature pass 率 | 端: 单 Agent; 云: 多 Agent 编排 |
| O Observability | Trace、成本、健康 | 闭环反馈 | 盲区 (无 trace 覆盖) | Trace 覆盖率、告警响应时间 | 端: 本地日志; 云: 全链路分布式 Trace |
| V Verification | 副作用验证、评估 | 冗余 + 投票 + 闭环反馈 | 虚假完成、验证器失效 | Feature pass 准确率、FP/FN 率 | 端: 轻量验证; 云: E2E 全套 |
| G Governance | 权限、审计、安全 | 不可逆隔离 + 约束空间 | 越权、注入攻击 | 越权拦截率、Grant 响应时间 | 端: TEE 硬件信任根; 云: 软件 Vault |
Part 4 小结：ETCLOVG 七层将理论映射到工程组件。E/G 靠约束 + 隔离，T 靠确定性优先，C/O 靠闭环反馈，V 靠冗余 + 投票。L 层是核心编排层，通过 5 阶段流水线实现可恢复执行，通过 Trace→Skill 闭环实现自动进化。Checkpoint 和状态写入协议在 L 层落地，确保 INV-S/C 的不变量约束被工程化执行。下一部分将从工程实践视角给出操作化指导。
0x05 Part 5: 工程实践
理论和架构解决了"为什么"和"是什么"。本部分回答"具体怎么做"——从原则到阈值、从自检到开放问题。核心精神：每条原则都有触发条件、默认动作和例外条件——原则必须可操作化，否则只是口号。
5.1 工程原则集
5.1.1 五种范式驱动的原则
| # | 原则 | 对应范式 | 对应问题域 |
|---|---|---|---|
| R1 | 高价值决策用确定性 Verifier 做投票裁判 | 冗余 + 投票 | 概率性 |
| R2 | 冗余上限 = Verifier 质量 | 冗余 + 投票 | 概率性 |
| F1 | 执行循环 = Sense-Think-Act-Verify | 闭环反馈 | 容错 |
| F2 | 反馈信号来自 Agent 外部 | 闭环反馈 | 容错 |
| F3 | 失败后换策略，非简单重试 | 闭环反馈 | 容错 |
| C1 | Defense Comes Outside the Model | 约束空间 | 概率性 |
| C2 | Schema > Prompt; 环境 > Schema | 约束空间 | 概率性 |
| C3 | 约束可动态调整 (渐进信任) | 约束空间 | 协调 |
| D1 | 路径确定性排序: Rule > API > CLI > MCP > GUI > LLM | 确定性优先 | 概率性 |
| D2 | 路由决策用规则引擎，不用 LLM | 确定性优先 | 概率性 |
| D3 | 每条新确定性路径 = 永久消除不确定性 | 确定性优先 | 概率性 |
| I1 | 按不可逆度分级门控 | 不可逆隔离 | 协调 |
| I2 | 默认操作空间 = 完全可逆 | 不可逆隔离 | 安全 |
| I3 | 有界委托 (Step/Time/Resource Limit) | 不可逆隔离 | 安全 |
5.1.2 架构原则 (A1-A15)
| # | 原则 | 对应问题域 |
|---|---|---|
| A1 | Session = 唯一事实源，append-only | 状态一致性 |
| A2 | Harness 无 long-lived 状态 (可随时替换) | 容错 |
| A3 | Tool 接口统一 + Idempotency Key | 幂等 |
| A4 | Context 不足时先跑 Feature (降级而非猜测) | 分区 |
| A5 | Session Start Protocol 验证环境健康 | 状态恢复 |
| A6 | 进度文件 (progress.txt) = Session 的派生缓存，可丢弃可重建 | 状态恢复 |
| A7 | Harness 变更 = 系统变更，端到端测试 | Coupling |
| A8 | 每个 intervention 标注移除条件 | 假设腐化 |
| A9 | Trace 是一等评估对象 | 可观测 |
| A10 | G 层从第一天设计，不是"后面再加" | 安全 |
| A11 | 质量不是标量——显式 tradeoff | 分区 |
| A12 | Handoff 传递完整上下文 | 协调 |
| A13 | Context = 状态估计 + 量化丢失 | 窗口约束 |
| A14 | 世界模型信念显式标注不确定度 | 窗口约束 |
| A15 | 信念-现实漂移主动检测 | 窗口约束 |
5.2 操作化参考值 (Default Thresholds)
以下为起步默认值，团队应根据场景校准。
| 原则 | 触发条件 | 默认动作 | 例外/升级 |
|---|---|---|---|
| R1 冗余投票 | Token 成本 > $0.05/call 或 操作含外部副作用 | Best-of-3 + Verifier 投票 | 只读查询免投票 |
| I1 不可逆门控 | 不可逆度 ≥3 (5 级制: 1=纯读, 2=可撤销写, 3=难撤销, 4=不可撤销, 5=影响他人) | Level 3→Checkpoint, Level 4-5→Grant | 用户预授权可跳 Grant |
| I3 有界委托 | 默认: ≤20 steps, ≤5 min wall-clock, ≤$1 resource | 超限暂停等 Grant | 用户主动扩展有效一次 |
| F3 换策略 | 同一路连续失败 ≥2 次 | 切换至下一级优先策略 | 若 3 种策略均失败→升级人工 |
| A14 不确定度标注 | 信念置信度 <0.7 | 标注 uncertain, 优先 probing | 只读决策可容忍 0.5 |
| A15 漂移检测 | 信念年龄 >5min 或 关键操作前 | 主动 probing 验证 | 高频操作可用缓存 (TTL=30s) |
| A8 移除条件 | 模型升级后 ablation 测试通过 | 移除 intervention | 涉及安全的 intervention 保留 |
5.3 设计自检清单
范式应用检查：这个子系统至少应用了一种范式？关键路径至少叠加了两种范式？选择的范式与不确定性来源匹配？
概率性执行检查：这个设计在"执行者确定性"假设下才成立吗？如果模型犯错，有结构性 (非 prompt) 兜底？验证机制不依赖模型自我评价？
观测窗口检查：真相源在哪——Context Window 还是外部持久化？Context 受限时如何降级？信念与现实可能漂移时，有主动 probing 吗？
腐化检查：这个设计依赖"当前模型行为"吗？有 Feature Gate + 移除条件吗？三个月后模型变强，哪些代码变成死重量？
不可逆检查：操作的不可逆度是什么级别？不可逆操作前有 Checkpoint？有界委托 (Step/Time/Resource Limit)？
世界模型检查：Agent 的信念有没有显式不确定度？关键决策前，是否 probing 验证了关键信念？盲区如何被发现和处理？
5.4 开放问题
| # | 问题 | 核心挑战 | 对应范式 |
|---|---|---|---|
| 1 | 认知不确定度量化 | 如何让 Agent 知道自己不知道什么？ | 闭环反馈 |
| 2 | 世界模型一致性 | 信念-现实漂移检测的成本 vs 收益 | 反馈 + 确定性优先 |
| 3 | 自适应约束调整 | 何时放宽/收紧 Agent 权限？ | 约束空间 |
| 4 | 确定性路径自动发现 | 如何自动将 GUI 操作升级为 API 路径？ | 确定性优先 |
| 5 | 跨 Agent 世界模型同步 | 多 Agent 如何共享信念而不泄露隐私？ | 隔离 + 反馈 |
Part 5 小结：工程实践将理论映射为可操作的原则、阈值和检查清单。Part 1 的分布式系统对标告诉我们哪些可以直接复用（8 项）、哪些必须重新发明（4 项）。核心精神：原则必须可操作化——每条原则有触发条件、默认动作、例外条件。
0x06 Part 6：总结与展望
6.1 终极公式
Agent OS Engineering = 五种驯服不确定性范式的组合应用
在"执行者概率性 + 观测有限 + 假设腐化"约束下的特化实现
”
6.2 复杂度隐喻
传统软件 = 在可靠环境中运行确定性程序
分布式系统 = 在不可靠环境中运行确定性程序
Agent OS = 在不可靠环境中运行概率性程序 ← 复杂度最高
对抗手段的进化：
- 传统 → 不需要特别对抗
- 分布式 → 主要对抗环境不确定性 (网络/硬件)
- Agent → 同时对抗环境 + 执行者 + 观测 + 平台 四重不确定性
6.3 结论
Agent OS 不需要发明新范式。70 年计算机历史已提供 5 种成熟范式。
Agent OS 的创新在于：
- 在正确的位置（ETCLOVG 七层）
- 以正确的组合（关键路径叠加两种以上）
- 针对新约束特化（概率性 + 窗口 + 腐化）
谁先把这三件事做对，谁就掌握下一代终端的入场券。
0xFF 参考/知识来源
| 内容 | 来源 |
|---|---|
| Brain/Hands/Session 解耦、Cattle 化 | Anthropic "Scaling Managed Agents" (2025) |
| Event Sourcing、Harness 腐化理论 | 知乎社区 + Claude Code 源码 |
| 双 Agent、Feature List、Session Protocol | Anthropic "Long-Running Agents" (2025) |
| ETCLOVG 分类法、Open Problems | Li et al. "Agent Harness Engineering" (2026, preprint) |
| 混合动作空间、确定性优先路由、副作用验证 | PhoneHarness (腾讯/港中文/清华, 2025, preprint) |
| Harness 5 阶段流水线、Trace→Skill 闭环 | ContextSearch (火山引擎, 2026) |
| 五种驯服不确定性范式 | 跨领域综合 (通信/控制论/数据库/实时/量子) |
本文使用 markdown.com.cn 排版