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: 问题空间

在构建解决方案之前，必须精确定义问题。本部分回答三个问题：

1. Agent 到底面对什么样的不确定性？
2. 它比传统系统难在哪里？
3. 前人在哪些领域已经解决过类似问题？

1.1 不确定性的六个来源

Agent 系统的不确定性来自六个维度。其中，LLM 输出概率性是 Agent 独有的——传统程序在相同输入下永远产生相同输出。其余五个在传统系统中也有对应，但在 Agent 场景中均被放大或扭曲。

1.2 三个独有问题

以上六种来源中，有三个在 Agent OS 中特别显著——不是因为传统系统完全没见过，而是它们在 Agent 场景下被根本性地放大了。具体来说：

• ① LLM 输出概率性 →"概率性执行主体"— 传统程序的执行者是确定性的，同样输入永远产生同样输出。LLM 不是。这是 Agent OS 与所有传统系统的根本分界线。
• ④ Context Window 有限 →"观测窗口硬约束"— 传统系统内存理论上可无限扩展，Context Window 是物理上限，意味着 Agent 永远只能看到"世界的局部投影"。
• ⑥ 模型升级行为漂移 →"假设腐化"— 传统系统升级 API 版本是低频、有文档、可测试的事件。模型升级是高频、隐式、行为不可预测的事件——你为 v1 写的 prompt、设的阈值、调的参数，v2 可能全部失效。

1.3 跨领域全景：计算机中"驯服不确定性"的经典实践

对于我们来说，一个好消息是：面对不确定性，计算机领域几十年来积累了丰富的对抗经验。下面这张全景图覆盖 10 个领域——注意最右边一列，它标记了每个领域的解法最终对应到哪种范式。

核心观察：最右列只出现了 5 个不同的答案。10 个领域、几十种具体技术，最终可以归纳为 5 种核心范式——这是 Part 2 的主题。但在这 10 个领域中，分布式系统是最接近 Agent OS 的参照域——两者共享 8 个核心问题中的 6 个，Agent 只多了一个额外维度（概率性执行者）。下面做一次深度对标。

1.4 分布式系统深度对标

理解Agent OS 与分布式系统的映射关系，可以让我们直接复用分布式领域几十年的工程积累，而不必从零发明。而那些"不能直接复用"的部分，恰恰是 Agent OS 需要重新发明的地方。

1.4.1 8 个经典问题全景对照

经典分布式系统的 8 个核心问题：

Agent Harness 的 8 个对应问题：

1.4.2 解法对号入座

注：下表中的"对应范式"和"ETCLOVG 层"引用了后续章节才正式介绍的概念。初次阅读可跳过这两列，读完 Part 2 和 Part 4 后回看。

状态恢复的根本区别（最值得强调）：

1.4.3 Event Sourcing — 两个世界的共同解

Event Sourcing（事件溯源）是一种软件架构模式，通过将系统状态变化记录为不可变的事件序列来替代直接存储当前状态‌，支持状态重建、完整审计和历史回溯。

1.4.4 复用 vs 重造

可直接复用：

需要重新发明：

1.5 认知演进 — 四个工程阶段

以上是从横向（领域对标）看清全局。从纵向（时间演进）来看，Agent 系统的认知本身经历了四个阶段。每一个阶段都在回答一个更深层次的问题。

四次跃迁的本质：

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 应用：

设计原则：

• R1：对高价值决策，用确定性 Verifier (测试通过率) 而非第二个 LLM 做投票裁判。
• R2：冗余的上限是 Verifier 质量。没有好 Verifier 时，冗余退化为浪费。

适用条件：高价值、低频、允许延迟。N 次采样 = N 倍 Token 成本。

冗余解决的是"个体可能失败"的问题。但如果失败不是随机的而是系统性的呢？——比如，模型对某类任务总是犯错，重试 10 次也没用。这就需要第二种范式。

2.1.2 范式二：闭环反馈

原理：执行 → 观测 → 比对期望 → 修正。通过持续修正收敛到目标。

Agent OS 应用：

设计原则：

• F1：Agent 执行循环 = Sense-Think-Act-Verify。Verify 不可省略。
• F2：反馈信号必须来自 Agent外部(测试结果、环境状态)，不能是自我评估。
• F3：失败后应"换策略"而非"简单重试"——语义错误不因重试消失。

闭环反馈能修正已发生的错误。但更好的策略是：让错误根本无法发生。

2.1.3 范式三：约束空间

原理：不修正错误，而是让错误不可能发生。通过缩小行为空间消除不确定性。

Agent OS 应用：

约束层级 (Defense in Depth)：

可靠性：低 -------------------------------------------------------------------- 高 Prompt 约束 → 结构约束 (JSON) → 环境约束 (Sandbox) → 验证约束 (E2E) → 人确认 (可被忽略) (中等可靠) (高可靠) (高可靠) (最终)

设计原则：

• C1：Defense ComesOutsidethe Model。安全约束永远在模型外部施加。
• C2：能用 Schema 约束的，不用 Prompt。能用环境约束的，不用 Schema。
• C3：约束空间可动态调整——随信任建立逐步放宽 (渐进信任)。

约束缩小了行为空间，但有些场景既不能约束也不能修正——因为存在确定性的解法。为什么还要让 LLM 猜？

2.1.4 范式四：确定性优先路由

原理：当确定性方案和概率性方案都能达成目标时，优先选择确定性方案。

Agent OS 应用：

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 应用：

不可逆度分级：

可逆 ←------------------------------------------→ 不可逆 读取 写文件 发消息 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 关键路径的叠加

2.2.3 设计决策流程

1. 识别不确定性来源 ├─ LLM 输出？→ 【冗余 + 投票】或【约束空间】 ├─ Tool 失败？→ 【闭环反馈】或【确定性优先路由】 ├─ 并发竞争？→ 【不可逆隔离】 └─ 观测不全？→ 【闭环反馈】 2. 判断操作可逆性 ├─ 完全可逆 → 允许自动 + 反馈修正 ├─ 部分可逆 → Checkpoint + 约束 └─ 不可逆 → 强制【隔离】+ Grant 3. 判断是否存在确定性替代 ├─ 有 → 【确定性优先】, LLM 做 Fallback └─ 无 → 【冗余】+【反馈】组合 4. 确认：至少一种范式已应用 ✓ 关键路径至少两种 ✓

2.2.4 ROI 排序

1. 确定性优先路由— 投入一条 CLI 路径 = 永久消除不确定性
2. 约束空间— 一次性设计成本，零运行时成本
3. 闭环反馈— 通用性最强，所有子系统都需要
4. 不可逆隔离— 安全底线，不做就是负债
5. 冗余 + 投票— 效果好但成本高，用于关键决策

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)

以下定义在全文中多次引用，此处为唯一标准版本。后文用编号引用，不再重述。

不变量之间的关系：

• INV-S 和 INV-C 定义了状态的存储和投影关系——一切状态管理围绕这对关系展开
• INV-D 和 INV-R 分别对应约束空间范式和确定性优先范式的操作化
• INV-P 是 INV-S 的推论：既然 Session 是唯一事实源，派生物必须可从中重建

3.2 系统结构：4 域 10 对象

有了不变量，下一步是定义"系统里有什么"——即状态本体论。

Task 9 状态机：submitted → planning → waiting_grant → running → waiting_external → completed | failed | canceled | rolled_back

3.3 世界模型：6 维认知表示

定义了"系统有什么"之后，下一个问题是：Agent 如何认知这个世界？

3.3.1 认知状态的工程价值

认知不确定度的显式表示是当前 Agent 系统最大的缺失：

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 世界模型与五种范式的对应

3.3.5 信念-现实漂移感知

世界模型最大的风险：Agent 的信念与现实不同步而不自知。

因此需要做相应处理。

漂移检测流程: 1. 对关键信念定期 probing (读文件/查状态/API 调用) 2. probing 结果与当前信念比对 3. 漂移超过阈值 → 触发世界模型更新 + 可能重新规划 类比: INS (惯性导航) = Agent 基于历史的推断 GPS 校正 = 主动 probing 真实环境 INS + GPS 融合 = 世界模型的 Kalman 更新

3.4 可验证性保证 (Verifiability Guarantees)

可控、可恢复、可持续优化是系统的运行时属性。可验证则是元属性——它保证其他三个属性确实在工作，而非仅仅被声称。

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

各层 × 范式矩阵如下：

4.2 E – Execution Environment

共享接口：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 四类 (生命周期 × 权限 × 删除机制)：

Compaction 4 策略：Auto / Micro / Reactive / History Snip

Context Anxiety (窗口焦虑)

模型接近 Context Window 上限时表现出的行为漂移——这是 INV-C (Context = 有损投影) 在实践中的直接后果：

症状：提前收工 (模型"感觉"快满了→草率完成)、遗忘早期指令 (前面的 system prompt 被挤出注意力)、决策质量下降 (长 Context 稀释关键信息的权重)。

对抗策略：

1. 上下文管理策略插件化 (Harness 控制何时压缩，非硬编码阈值)
2. Feature Gate 远程热切换压缩策略 (无需重启)
3. 关键指令在 Context 末尾重复锚定 (recency bias 利用)
4. 监控"Context 利用率"指标，超过 70% 触发主动压缩

核心认识：Context Window 管理不是"满了才压缩"，而是一个持续运行的状态估计系统(INV-C)。

4.5 L – Lifecycle & Orchestration