五种驯服不确定性的范式

问题空间在构建解决方案之前必须精确定义问题。本部分回答三个问题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 采样