类比的边界与超越¶
精确的断裂点，比模糊的相似更有价值。
把四根支柱的裂缝放在一起看，它们不是随机的设计问题——每一个都指向同一个根源。类比有用，它在哪里终止同样重要。
六个断裂点¶
| 维度 | OS | Agent | 工程后果 |
|---|---|---|---|
| CPU 可信度 | 进程不理解自己执行的内容，不会被说服越权 | LLM 可被 prompt 改写行为 | 信任边界必须延伸到 CPU 层（Execute-Only） |
| page fault 代价 | 只加延迟，数据精确复制 | 可能加错误（distractor interference） | 内存管理不只是"在不在"，还有"对不对" |
| 调度终止条件 | 时间/退出码，确定性信号 | "完成"是语义判断 | 需要语义终止条件，OS 工具箱没有 |
| 通信精度 | 字节精确，有 CRC 可验证 | 自然语言，无语义校验和 | 每次传递都是有损变换，结构化格式减少但不消灭衰减 |
| 确定性 | 同输入同输出 | 同输入不同输出（温度参数） | 测试不能依赖精确断言，需要统计验证 |
| 身份稳定性 | PID 不可被用户态程序篡改 | System prompt 可被 injection 改写 | Agent 身份是开放问题，密码学签名方向待成熟 |
这六个断裂点有一个共同的根源：OS 的 CPU 是确定性的执行硬件，agent 的 CPU 是统计性的语言模型。Karpathy 的 2026 年定义——"LLM = CPU (dynamics: statistical and vague not deterministic and precise)"——把这个差异精确地嵌进了类比本身。
断裂不是失败，是地图上的标记¶
每个断裂点指向一个 OS 范式没有覆盖的设计空间：
CPU 可信度 → Execute-Only Agents 是一个方向：把语言理解和执行分进两个安全域，执行层不被语言说服。硬件级的可验证执行（attested execution）是另一个方向：密码学证明某段代码按预期运行。这两个方向都在研究中，没有成熟的工业答案。
page fault 代价 → 语义感知内存管理：不只是 LRU（最近最少用），还要考虑信息质量。"这条历史记录是否还有效"和"这条历史记录多久没被访问"是两个不同的维度，当前的 context management 工具主要解决后者。
语义终止条件 → AgenticOS Workshop 把这列为核心研究议题。时间约束是粗糙的代理：不是"结果是否令人满意"，而是"还没有超时"。更精细的解法可能需要明确的目标状态定义（"什么算完成"写进 agent 的初始化逻辑），或者基于收敛检测的自动判断。
通信精度 → 结构化协议（A2A 的 JSON-RPC）是在确定性传输层包裹非确定性语义。更进一步的方向是：给关键信息打上显式标签，区分"事实"（不允许被摘要丢弃）和"上下文"（可以有损压缩）。
确定性 → 传统软件测试建立在一个前提上：同输入同输出。断言写死，CI 亮绿灯，部署。当 CPU 是统计性的，这个前提消失了——同一个 prompt 跑两次可能拿到结构不同的回答。测试策略被迫从精确匹配转向统计验证：多次采样取分布，用语义相似度替代字符串相等，用 LLM-as-judge 替代硬编码断言。"通过"不再是二元判断，而是置信区间。
身份稳定性 → 最开放的问题。Grimlock（ASPLOS 2026）用 eBPF 在内核层监控 agent 行为，提供可观测性，但不解决 system prompt 本身的完整性。密码学签名的 system prompt——类似代码签名——是理论上的方向，实践中的挑战还没有被系统性解决。
OS 思维的迁移价值¶
OS 工程师在调度、内存、隔离、权限、通信上积累了 50 年的设计直觉：在大多数工作负载下，为什么抢占式调度优于协作式？为什么虚拟内存比直接管理物理内存更好？为什么最小权限原则值得为之增加复杂性？
这些直觉背后有具体的失败案例，有实验数据，有工程代价的精确量化。不是抽象原则，是从痛苦里学来的东西。
当 harness 工程师面对"多个 agent 竞争 LLM 推理资源，怎么仲裁"这个问题时，不需要从零探索设计空间——OS 调度的历史告诉他，批处理够用但 CPU 利用率低，时间片轮转更公平但切换有开销，优先级调度有饥饿问题。这些是可以直接迁移的设计直觉，不需要重新用失败案例来积累。
类比给了工程师一张地图，知道带什么工具进入新的设计空间。断裂点告诉工程师，地图在哪里开始失效，需要开始自己绘图。
四个透镜，同一个系统¶
这一章是第四个透镜。
正交性给了两股力的分解：模型能力和 harness 工程是正交方向，投资在正交方向上的设计不会被模型迭代清零。
控制论给了骨架：observer-controller-plant 的三角，必要多样性的约束，反馈回路的拓扑。Harness 工程的本质是控制系统设计。
熵给了动力学：为什么系统在没有主动维护时倾向于退化，为什么分拣信息有不可消除的代价，为什么 Demon 的个案判断不可扩展。
操作系统（本章）给了制度：把 Demon 的判断写成规则，把控制论的结构写成四根可工程化的支柱，把熵的管理从直觉变成有工具可用的系统方法。四根支柱——内存管理、调度、信任边界、协作协议——和六个断裂点是同一个框架的不同维度，不是独立的工程问题。
四个透镜叠在一起，harness 的结构才完整：不只是正确方向上使力，不只是反馈回路，不只是抗熵机制——是一个有内存、有调度、有信任边界、有通信协议的完整操作系统，运行在一个统计性的、可被语言改写行为的 CPU 上。
Maxwell's Demon 读取状态，做判断，维持秩序。OS 把这件事制度化了。Harness 工程师正在把 OS 重新发明一遍——这次，CPU 是概率性的。
延伸阅读¶
- Tiwari, M. & Williams, R. (2026). Execute-Only Agents: Rethinking Security for LLM-Based Systems. AgenticOS Workshop, ASPLOS 2026. — 本文六个断裂点中"CPU 可信度"问题的结构性回应：把规划层和执行层分进两个安全域，从架构上消灭攻击面
概念与实体¶
本文涉及的核心概念与实体，在项目知识库中有更详细的资料：
- Agent OS — 本文梳理的六个断裂点所在的"OS for agents"研究方向
- LLM Security — "CPU 可被说服"和"身份稳定性"两个断裂点对应的安全研究
- Harness Engineering — 本文结论：harness 正在重新发明 OS，断裂点是需要新发明的地方
- Context Management — "page fault 代价不对称"断裂点在工程层面的应对
- ASPLOS — AgenticOS Workshop 的主会场，OS 与体系结构的顶级会议