本文核心论点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 MonotonicAgent 超时 → 有界委托约束空间容错计算硬件故障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 Consistency2容错节点崩溃Replication、Failover、Checkpoint3分区容忍网络断裂时继续工作CAP 选择、降级策略4幂等性重试产生副作用Idempotency Key、Exactly-once5因果排序事件时序混乱Logical Clock、Vector Clock6状态恢复从故障点接续WAL Replay、Event Sourcing7可观测性跨节点因果追踪Distributed Tracing (Jaeger/Zipkin)8协调多参与者达成一致2PC、Saga、ChoreographyAgent Harness 的 8 个对应问题#问题Agent 语境与分布式的映射1Context 不一致Context Window 与真实世界状态不同步 状态不一致但原因是窗口有限而非网络延迟2推理容错模型犯错≠系统崩溃需要优雅降级 容错但失败模式是语义错误而非 crash3信息分区Context Window 截断 永远只看到局部 分区容忍但分区是永久的而非暂时的4Tool 幂等重复调用 API 买两张机票 幂等完全同构5多 Agent 排序多个 Agent 异步协作时的因果关系 因果排序完全同构6跨 Session 恢复新 Context Window 从零开始 状态恢复但不能 replay 推理7Trace 归因哪步决策导致最终失败 可观测性但执行路径是概率性的8三方协调Human Model Tool 达成一致 协调但一个参与者 (模型) 是概率性的1.4.2 解法对号入座注下表中的对应范式和ETCLOVG 层引用了后续章节才正式介绍的概念。初次阅读可跳过这两列读完 Part 2 和 Part 4 后回看。#问题Agent 解法对应范式→Part2ETCLOVG 层→Part41Context 不一致Session Durable Artifacts Session Start Protocol闭环反馈C L2推理容错约束层级 (INV-D) Feature passes约束 反馈V G3信息分区Context Engineering 永久分区下的降级反馈 确定性优先C4Tool 幂等Idempotency Key progress.txt 防重做约束空间T5多 Agent 排序Event 时间戳 trace_id Compaction约束空间O6跨 Session 恢复Fact Log (非 Command Log) Durable Artifacts隔离 反馈C E7Trace 归因多次 Trace 统计归因冗余 反馈O8三方协调双层 Grant Agent 版 2PC隔离 约束G状态恢复的根本区别最值得强调维度分布式Agent日志内容Commands (可重跑)Facts(不可重跑)Replay确定性不能 replay 推理恢复精度精确有损1.4.3 Event Sourcing — 两个世界的共同解Event Sourcing事件溯源是一种软件架构模式通过将系统状态变化记录为不可变的事件序列来替代直接存储当前状态‌支持状态重建、完整审计和历史回溯。AgentOSEvent Sourcing区别SessionAppend-only Event Log存Facts非 CommandsHarness事件消费 状态重建不能 replay 推理SandboxSide Effects可能不可逆wake(sessionId)Resume从事实投影恢复1.4.4 复用 vs 重造可直接复用分布式经验AgentOS 应用Event SourcingSession append-only fact logIdempotency KeyTool call dedupTrace ID propagationAgent trace_id 贯穿Circuit BreakerTool 连续失败→切策略Sidecar PatternAgent 的 SidecarControl/Data PlaneBrain (决策) / Hands (执行)Graceful DegradationContext 不足时降级需要重新发明分布式解法为什么不能直用Agent 替代确定性 Replay模型概率性Fact Log 投影自动 Gossip单向 Context Window主动 Retrieval固定超时重试语义错误不因重试消失反馈 换策略静态配置假设会腐化Feature Gate Adaptive1.5 认知演进 — 四个工程阶段以上是从横向领域对标看清全局。从纵向时间演进来看Agent 系统的认知本身经历了四个阶段。每一个阶段都在回答一个更深层次的问题。阶段时间核心问题焦点Prompt Engineering2022-2024给模型什么输入prompt 文本Context Engineering2025模型每步看到什么上下文管理Harness Engineering2025-2026整个执行环境如何工程化完整基础设施Agent OS2026-如何构建概率性执行者的操作系统平台化治理四次跃迁的本质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 交叉验证MLBaggingBest-of-N 采样Agent OS 应用场景设计ETCLOVG 层LLM 输出不稳定Best-of-N 确定性 Verifier 打分V单模型有盲区多模型 EnsembleL代码正确性多 Agent 交叉 ReviewL VTool 可能失败多路径尝试 比对T设计原则R1对高价值决策用确定性 Verifier (测试通过率) 而非第二个 LLM 做投票裁判。R2冗余的上限是 Verifier 质量。没有好 Verifier 时冗余退化为浪费。适用条件高价值、低频、允许延迟。N 次采样 N 倍 Token 成本。冗余解决的是个体可能失败的问题。但如果失败不是随机的而是系统性的呢——比如模型对某类任务总是犯错重试 10 次也没用。这就需要第二种范式。2.1.2 范式二闭环反馈原理执行 → 观测 → 比对期望 → 修正。通过持续修正收敛到目标。经典领域实现Agent OS 映射控制论PID / KalmanContext 管理 状态估计网络TCP ACK cwndToken Budget 闭环强化学习Policy Gradient策略切换Agent OS 应用场景闭环设计ETCLOVG 层任务执行Verify-then-Act LoopV LContext 管理Kalman 式 Retrieval (预测→加载→验证)C工具学习失败→分析→换策略(非简单重试)T L成本控制Token Budget 实时监控 调整O设计原则F1Agent 执行循环 Sense-Think-Act-Verify。Verify 不可省略。F2反馈信号必须来自 Agent外部(测试结果、环境状态)不能是自我评估。F3失败后应换策略而非简单重试——语义错误不因重试消失。闭环反馈能修正已发生的错误。但更好的策略是让错误根本无法发生。2.1.3 范式三约束空间原理不修正错误而是让错误不可能发生。通过缩小行为空间消除不确定性。经典领域实现Agent OS 映射编程语言类型系统 / Rust borrow checkerStructured Output形式化验证Model CheckingFeature List 枚举OSCapability 模型Tool 白名单硬件IOMMU/MMUSandbox 文件/网络限制Agent OS 应用场景约束设计ETCLOVG 层LLM 输出格式JSON Schema / Structured OutputT工具权限Capability 白名单G操作范围Sandbox 文件系统/网络限制E状态变更Feature List 枚举空间LPrompt 注入输入净化 分离架构G约束层级 (Defense in Depth)可靠性低 -------------------------------------------------------------------- 高 Prompt 约束 → 结构约束 (JSON) → 环境约束 (Sandbox) → 验证约束 (E2E) → 人确认 (可被忽略) (中等可靠) (高可靠) (高可靠) (最终)设计原则C1Defense ComesOutsidethe 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 映射数据库事务 RollbackCheckpoint 恢复文件系统Copy-on-Write操作前保存状态容器Namespace 隔离Trust Domain 隔离金融预授权→确认Grant 门控航天安全模式有界委托Agent OS 应用场景隔离设计ETCLOVG 层不可逆操作Grant 门控(支付/邮件/物理动作→人确认)G文件修改Checkpoint/SnapshotE多 AgentTrust Domain 隔离 (不共享凭证)G探索性任务Sandbox 副本 (试错后才 Commit)E长任务有界委托(步骤/时间/资源上限)L不可逆度分级可逆 ←------------------------------------------→ 不可逆 读取 写文件 发消息 API 调用 支付 物理动作 (自动) (快照) (可撤) (幂等) (人确) (禁止)设计原则I1按不可逆度分级越不可逆越需要强门控。I2Agent 默认操作空间 完全可逆。进入不可逆区域需 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-SSession append-only fact log唯一事实源记录发生了什么 (facts, 非 commands)INV-CContext Window Session 的有损投影状态估计非完整状态INV-D约束层级: Prompt Structure Environment Verification Human可靠性递增Defense in DepthINV-R路径排序: Rule API CLI MCP GUI Free-form LLM确定性递减优先走确定性路径INV-Pprogress.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_back3.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保证含义服务于P1Output Provenance (输出溯源)每个 Agent 输出附带完整证据链触发源→路由决策→执行证据→验证判定可控P2State Traceability (状态可追溯)任何系统状态变更可追溯到用户意图→Grant→Task→Action→状态变化可恢复P3Invariant Monitoring (不变量守护)5 条 INV 的运行时持续校验违反即告警 进入 safe mode可控 可恢复P4Decision Reproducibility (决策可复现)给定 fact log 切片可重建当时的 Context Window 和决策依据可持续优化P5External 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 层冗余反馈约束确定性优先隔离主力范式EExecution△△★★★★★★约束 隔离TTool★★★★★★★★★△确定性优先CContext△★★★★★★△闭环反馈LLifecycle★★★★★★★★★反馈 隔离OObservability△★★★△★★△闭环反馈VVerification★★★★★★△△冗余 投票GGovernance△△★★★★★★★约束 隔离4.2 E – Execution Environment端上云端沙箱OS 权限 TEEmicroVM / 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 LLMCapability 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 Contexttask 结束自动Episodic Memory长期用户主动Preference Memory永久GDPRKVCache Memory推理周期LRUCompaction 4 策略Auto / Micro / Reactive / History SnipContext 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