从 Demon 到制度

Maxwell’s Demon 做的事，和 harness 工程师做的事，结构上是同一件事：读取系统状态，做出判断，维持局部有序。观测 context，过滤噪声，控制信息注入。分拣逻辑本身是成立的。

但 Demon 靠的是持续在场的个案判断。一个 Demon，手动判断，不可复制，出故障没有接替者，出错了也不知道是哪一步出了问题。这不是实现不够好——是”个案判断”模式本身的结构性上限。

把分拣规则写成制度，你就有了一个操作系统。

什么走哪个通道，什么触发什么操作，异常情况如何处理——这些本来在 Demon 脑子里的判断，一旦编码成规则，就可以复制、可以审计、可以在 Demon 不在时继续运行。从个案判断到制度化机制，这是一次跃迁。也是 harness 工程正在发生的事。

Karpathy 的直觉

2023 年 11 月，Andrej Karpathy 在一场 LLM 入门演讲里提出了一个框架：

“I think it’s a lot more correct to think about it as the kernel process of an emerging operating system.”

他的映射：context window 是 RAM，互联网是磁盘，代码解释器和浏览器是外设。这是一个系统论直觉——LLM 是这个新计算系统的中心进程，像 OS kernel 那样协调所有资源。

方向对，但层次还没有分开。这个直觉把执行层和编排层压缩在同一个”kernel process”里，没有说清楚谁是 CPU、谁是 kernel。

两年之后，这个直觉被拆开了。

从直觉到两层映射

2025 年，Karpathy 在 YC AI 创业学校的演讲里用一个历史类比说清楚了当前的位置：我们处在 LLM 的 1960 年代——算力昂贵，集中在云端，ChatGPT 像大型机的终端界面，用完断开连接。个人算力时代还没到来。

2026 年 3 月 31 日，Python 之父 Guido van Rossum 问：什么是 agent？Karpathy 用两行回答：

这不是推翻 2023 年的说法，是给它加了一层精度。2023 年的直觉：LLM 是这个新兴 OS 的”kernel process”——那个协调所有资源的中心进程。2026 年把这个整体直觉分成两层：执行层（LLM 是 CPU，跑 token 计算）和编排层（Agent 是 kernel，做所有策略决策）。一个系统论直觉，拆成了两个可以独立工程化的层次。

这个精化过程本身就是论点：即使是提出这个类比的人，也用了三年才把它说清楚。类比在工程实践中成熟，不是在一次顿悟里完成的。

补完第三层

Karpathy 给了 LLM（CPU）和 Agent（kernel）。还缺一层。

OS 不只是 kernel。Kernel 是 OS 的核心，但 OS 是一个完整的栈：kernel 管理资源，驱动连接硬件，系统调用层暴露接口，用户态工具让外部程序可以使用这一切。去掉任何一层，OS 都不能独立运行。

Harness 是完整的 OS：

架构关系保留了。CPU 执行指令，不决定执行什么。Kernel 编排资源、调度进程、执行边界——执行层之上的决策层。完整 OS 把这些都包在里面：内存子系统、调度算法、权限模型、进程间通信，五十年工程积累让硬件变得可用的全部机制。

OS 用 50 年打磨出四根支柱：内存管理、调度、信任边界、协作协议。同样的工程问题在 agent harness 里重现，形状略有不同——有时候是直接的结构映射，有时候类比在某一点断裂，而断裂处指向的正是 OS 50 年里没走到的设计空间。

四根支柱里，最直觉的是内存——因为 context window 的有限性是 harness 工程师每天都在感受的约束。

延伸阅读

• Karpathy, A. (2023). Intro to Large Language Models. YouTube. — 本章 OS 类比的源头：Karpathy 在这场演讲里第一次把 LLM 定位为”新兴操作系统的 kernel process”，从 context window = RAM 到代码解释器 = 外设，系统论直觉的完整版本

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• LLM-OS Analogy — 本文的核心论点：从 Karpathy 2023 到 2026 的三层映射演化
• LLM-OS — “LLM 作为操作系统”这一概念的技术展开
• Harness Engineering — 本文将 harness 定位为”完整 OS”，这里有更完整的工程视角
• Agentic Systems — Agent = kernel 这一层映射的工程实体
• Andrej Karpathy — 本文多处引用其 OS 类比的演化过程

内存层次结构

Context window 的有限性不是临时的工程限制，不会随着窗口扩大而消失。这是一个更古老的问题在新计算范式里的重现——OS 已经解决过一次了。

内存的物理现实

计算机的存储是分层的，原因只有一个：快速存储很贵，便宜的存储很慢。这个约束在每一代存储技术上都成立——从磁芯到 DRAM 到 SSD 到 NVMe，从未例外。

CPU 寄存器访问在 1 纳秒以内，但只有几十字节——多一个字节也放不下。L1/L2 cache 在几纳秒，几兆字节。RAM 在 100 纳秒，几十 GB。磁盘是毫秒级，但可以装下 TB。每跨一层，速度掉一个数量级，容量涨一个数量级，这个规律从没有被打破过。

这个金字塔的设计原则是局部性：程序倾向于反复访问同一批数据（时间局部性），以及访问相邻位置的数据（空间局部性）。把最近用过的、最常用的数据放在快速层，其余放在慢速层，整体性能接近最快的存储。

虚拟内存是这个金字塔的关键创新：程序以为自己有连续的大内存空间，OS 在背后把最活跃的页面放在 RAM，其余放在磁盘。程序访问一个不在 RAM 里的地址，硬件触发 page fault，OS 把对应的页从磁盘读进来，替换出一个最少用的页，然后继续执行——程序对这个过程一无所知。这叫透明性：底层的搬运不需要程序配合。

Agent 系统的内存金字塔

对应关系是直接的：

核心问题不变：用有限的快速存储，模拟对无限慢速存储的访问。Context window 是 RAM——容量有限，但推理时 LLM 直接访问；向量库是磁盘——容量大，但每次检索都需要额外操作。

虚拟内存的 agent 实现

UC Berkeley 的 MemGPT（2023）把这个问题做成了显式的系统设计。Main context = RAM（LLM 直接访问），archival memory = 磁盘（外部存储）。当 agent 需要历史记录，通过函数调用从 archival memory 读入 context——这是 page fault 的 agent 版本。Context 接近上限时，压缩摘要写回外部存储——这是 page eviction。

结构上，这是同一个设计模式：“用有限快速存储模拟无限慢速存储”，在不同计算层的重现。

但有一个差异要指出：OS 的 page fault 对进程完全透明，由硬件在进程不知情的情况下触发和处理。MemGPT 的”page fault”则是 LLM 主动生成的函数调用——LLM 知道自己在做检索，并决定何时检索什么。透明性这一维度是倒置的。资源管理层的同构是真实的；透明度的设计哲学相反。

这个区别不是缺陷，是自然语言推理系统的结构性特征：LLM 必须主动参与自己的内存管理，因为它本身就是判断”什么信息现在需要”的那个系统。

基础设施下沉

MemGPT 是研究原型，Anthropic 的 Compaction API 把同样的思路变成了生产基础设施。当 context 接近上限，API 服务端自动执行摘要压缩，生成 compaction block，从压缩后的状态继续对话。

这是 OS 历史里一个熟悉的轨迹：研究里出现的虚拟内存概念，最终被下沉到 OS kernel，让应用程序不再需要手动管理物理内存。Compaction API 在做同样的下沉——把本来需要 harness 工程师自己搭建的分页系统变成基础设施层的标配。

断裂点：page fault 的代价不对称

OS 的 page fault 只加延迟，不改变计算结果。磁盘上的数据和 RAM 里的一模一样，搬运是精确复制，不引入错误。程序在 page fault 之前和之后的行为完全一致，只是慢了一点。

Agent 的”page fault”则不然。如果从外部存储检索到的信息不相关——哪怕它语义上接近，内容上不准确——它不只是让 agent 慢下来，它会主动伤害推理质量。Chroma 在 18 个前沿模型上的研究（包括 GPT-4.1、Claude 4、Gemini 2.5、Qwen3）量化了这一点：distractor interference 机制下，与目标语义相关但内容不正确的内容，对模型性能的损害超过了内容完全缺失的情况。

错误的上下文比缺失的上下文更糟——在 distractor interference 的实验条件下如此。OS 内存管理从来不用担心这个：磁盘上存的内容不会”不对”，只会”读不到”。Agent 系统的”内存管理”多了一个维度：不只是数据在不在，还有数据对不对。

窗口变长不消灭管理需求

一个自然的问题：context window 越来越长（从 4K 到 1M），管理的必要性会随之消失吗？

RAM 容量从 256MB 增长到 64GB，没有消灭虚拟内存——反而催生了更复杂的内存管理系统（更大的页表、更精细的页替换算法、NUMA 架构）。原因是局部性依然存在：程序并不均匀地访问所有内存，热点数据仍然需要优化。

Context window 同理。1M context 意味着可以放入更多信息，也意味着注意力稀释的问题更严重。Chroma 的数据是跨模型一致的：随着输入长度增加，模型性能下降——不是因为窗口不够大，而是因为注意力是稀缺的。更长的 context 里，信号被稀释得更厉害。

管理需求不会随容量扩展而消失；它随着系统复杂度的增长而增长。

调度解决的是另一个方向的问题：不是”什么信息在 context 里”，而是”谁在什么时候用 LLM”。多个 agent 共享一个推理引擎，仲裁机制是必要的——这是 OS kernel 的另一个核心职责。

延伸阅读

• Packer, C. et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560. — 把 OS 虚拟内存的设计模式显式移植到 agent 系统的第一篇论文：main context = RAM，archival memory = 磁盘，函数调用 = page fault
• Chroma. (2025). Context Rot: How Long Contexts Degrade LLM Performance. research.trychroma.com. — 量化了本文的核心断裂点：错误的上下文比缺失的上下文更糟，跨 18 个前沿模型一致成立

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• Context Management — 本文讨论的内存层次结构，在工程实践中对应的管理机制
• Context Compression — 文中 Compaction API 所做的”page eviction”背后的压缩技术
• Virtual Context Management — MemGPT 式的虚拟内存方案在 agent 系统中的完整展开
• Context Rot — Chroma 研究量化的”注意力稀释”现象的详细资料
• MemGPT — 本文引用的虚拟内存研究原型的项目资料
• Anthropic — Compaction API 的提供方，正在将虚拟内存机制下沉为基础设施

调度

调度解决的是一个古老的问题：多个需求者竞争同一个稀缺资源，谁先用，用多久，用完之后谁接上。

这个问题 OS 已经解决了 50 年。

OS 调度简史

最早的批处理系统没有调度。程序一个接一个跑，上一个跑完才能跑下一个。程序做 IO 时 CPU 空在那里，什么也不做——那个年代的 CPU 利用率报告读起来像一份尴尬报告。

时间片轮转（Round Robin）是第一次真正的突破：每个进程分配一个固定时间片，时间到了强制切换。CPU 利用率提升了，但问题随之暴露——所有进程得到相同的时间，不管它们的工作是否同样紧急。一个实时报警进程和一个后台日志压缩进程轮流占用 CPU，这在直觉上就是错的。

优先级调度解决了这个直觉问题，代价是引入了另一个：如果高优先级进程源源不断地涌入，低优先级进程就永远排不上队——饥饿。一个理论上正确的设计，在实践中可以把某些进程永久搁置。

Linux 的 CFS（完全公平调度器）把这个问题从”谁的优先级高”换了一个问法：追踪每个进程被”亏欠了多少 CPU 时间”，优先补偿亏欠最多的。这不是公平性的退步，而是公平性定义的精化。cgroups 在此之上加了预算管理：每个进程组最多能消耗多少 CPU，超了就限速。

五十年的演化轨迹：从”有没有调度”到”公平”到”优先”到”亏欠最多优先”，每一步都是被上一步的失败逼出来的。

Harness 的调度：编排决策

Harness 里的调度发生在应用层，管的不是”哪个 inference request 先进 GPU 队列”，而是哪个任务值得执行、什么顺序执行、是否并行。这是 orchestrator 的核心职责——agent 系统的 kernel 在做 kernel 该做的事。

对照关系是直接的：

越来越多的编排模式正在出现——从严格串行到完全去中心化，覆盖的调度哲学谱系和 OS 50 年的演化基本吻合。

Harness 的调度：成本 ROI

这是 OS 调度没有的一个维度。

OS 的 cgroups 问的是：这个进程组最多能用多少 CPU？这是计算资源配额——CPU 时间是内部成本，不是逐次显性计费的。

Harness 面对的是一个更复杂的问题：这个任务值得花多少 token？

Token 是显性成本，每次推理都可以精确计量，harness 的调度目标函数因此变了：不只是”资源能不能完成任务”，还要问”完成这个任务值不值得花这么多 token”。OS 从来不需要问这个问题——CPU 时间是内部记账，不是逐次计费。

这个差异渗透进每一个调度决策：任务优先级不再只是”谁更紧急”，还有”质量要求和 token 预算是否匹配”；模型路由不是”最强的模型最好”，而是”这个步骤对推理精度的要求值不值得更高的单次成本”；任务截断不只是超时逻辑，而是”继续消耗的期望收益是否高于截断损失”。

Token 预算 = cgroups，但目标函数不同：OS 的调度追求吞吐量和公平性，harness 的调度还要追求质量/成本比。这个比值 OS 从来没有计算过，因为 CPU 时间不是按决策计费的。

断裂点：语义终止条件

OS 调度有一个可靠的终止机制：进程跑完了，退出码非零表示失败，调度器知道它结束了。时间也可以作为终止条件——超时 kill。这些都是精确的、非歧义的信号。

Agent 调度在这里遇到了 OS 没有的问题：什么时候算完，是一个语义判断，不是一个机器可以直接检测的状态。

考虑这样一个场景（用于说明结构）：编辑 agent 审阅一篇文章后批注”语气需要更专业”，写作 agent 修改后交回，编辑 agent 发现”太干了，需要更生动”——两个 agent 都在工作，都在消耗 token，但系统没有在向目标收敛。这不是死锁（没有人停下来等待），是活锁：持续活动，零进展，账单在跑。

OS 的超时机制可以检测活锁，但不能解决它的根本问题。OS 的进程有退出码，agent 没有。“这篇文章改好了”是什么意思——什么状态算”好”——是一个语义判断，不是时间或状态机可以精确捕捉的。

这是 OS 调度进入 agent 世界时必须新发明的那一块：语义终止条件。AgenticOS Workshop（ASPLOS 2026）把”语义感知调度”列为核心研究议题，正是因为这个问题在 OS 工具箱里没有现成答案。

调度正交于模型能力

更强的 CPU 没有消灭 CFS——进程还是要争 CPU 时间。更便宜的存储没有消灭虚拟内存调度——页面替换算法还在运行。

更强的 LLM 不消灭 harness 的调度需求，反而在两个方向上加剧：能接更复杂的任务，需要更多 agent 协作，编排决策维度更高；每次推理更贵（能力越强通常定价越高），成本 ROI 的权衡更重要，不是更不重要。

调度是 kernel 层的核心职责之一，不随计算能力的增长而消失。

调度决定谁在什么时候运行。信任边界决定运行时能做什么——工具权限、数据访问范围、越权行为的防护。这是另一根支柱，也是 agent 系统和传统 OS 差异最尖锐的地方。

延伸阅读

• Mei, K. et al. (2025). AIOS: LLM Agent Operating System. COLM 2025. arXiv:2403.16971. — 在系统层把 FIFO/RR 调度实现了一遍，和本文讨论的 harness 层编排调度正交互补；读完本文再读这篇，能看到调度问题在两个不同层次上的完整面貌
• AgenticOS Workshop. (2026). 1st Workshop on OS Design for AI Agents. ASPLOS 2026. — 本文提到的”语义终止条件”和”AgentCgroup token 预算管理”在这个 workshop 里被列为核心研究议题，是断裂点指向的前沿

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• Agent Scheduling — 本文讨论的调度问题在工程层面的详细展开
• Agent Resource Control — token 预算 = cgroups 这一映射的资源控制机制
• Task Lifecycle — 调度决策的对象：任务从创建到终止的完整生命周期
• Long Running Agents — 长时间运行的 agent 对调度机制的特殊需求
• AIOS — 本文引用的 LLM Agent Operating System 项目资料

信任边界

OS 不信任它运行的程序。

这不是工程选择，是设计原则：用户程序可能有 bug，可能被入侵，可能恶意。OS 假设最坏情况，通过两个独立机制来限制损害：权限（程序能做什么）和资源隔离（程序能看到什么）。两者缺一不可——只有权限没有隔离，程序可以读到任何数据；只有隔离没有权限，程序可以对可见的数据做任何操作。

Harness 面对同样的结构问题，重新发明了这两个机制。

权限维度：工具调用 = 系统调用

OS 的系统调用是用户程序访问特权资源的唯一合法入口。程序不能直接操作硬件、网络栈、文件系统——只能通过 syscall 请求 kernel 代为执行，kernel 在执行前验证权限。

Agent 的工具调用结构完全相同：agent 不能直接发邮件、修改数据库、执行命令，只能通过 tool call 请求 harness 代为执行，harness 在执行前验证权限。Syscall 是 agent 系统里的 tool call。

生产级 agent 系统已经在重新发明这个结构。核心原则和 OS 安全一脉相承：deny 优先于 allow——拒绝永远比允许有更高的优先级，任何层级设置的 deny 不可被更低层级 override。

权限模式形成一个谱系，从完全手动确认到完全自动执行——就像 OS 从受限用户态到 root 的不同信任级别。权限范围的层级嵌套也是 OS 风格的：组织策略覆盖项目配置，项目配置覆盖用户偏好，但 deny 是单向的。这和 ring 保护的逻辑相同：ring 0 的约束对 ring 3 不可见、不可逾越。

权限侧断裂点：CPU 可以被说服

OS 进程不会被”说服”去做越权操作。

进程不理解自己在执行什么——它只是按指令集跑二进制代码。你可以注入恶意代码，但恶意代码至少受指令集的约束：没有合法指令序列的程序就是不会运行。即使注入成功，攻击者控制的代码依然在 OS 的权限系统里运行，syscall 的访问控制依然有效。

Agent 在这里遇到了 OS 从未面对的问题：这个 OS 的 CPU 可以被语言改写行为。

一条精心构造的 prompt injection 不需要找到代码漏洞，不需要提升权限——只需要使 agent 表现出越权行为（无论底层机制是”指令跟随”还是”上下文劫持”，可观测的效果相同）。自然语言没有类型系统，没有编译器，没有”这条指令无效”的机制。权限边界在架构层面，攻击面在语义层面。

在 OS 里，你只需要信任 kernel 的逻辑，不需要信任 CPU 本身——CPU 是确定性的执行硬件。在 agent 系统里，这个假设失效了：LLM 既是执行引擎，又是理解输入的那个系统，而输入可以是攻击向量。

Execute-Only Agents（ASPLOS 2026，Tiwari & Williams）提出了一个结构性回应：把规划层和执行层分进两个安全域，执行层不接受自然语言指令，只处理预批准的操作集。不能被语言说服的组件，才是真正的安全边界。这不是在权限系统上打补丁，而是从架构上消灭攻击面。

资源维度：数据的可见性分层

OS 的文件系统权限通过 owner/mode 把数据分成三层可见性：内核独占的（/proc、/lib，用户进程只读或不可见）、系统管理的共享资源（/etc，受控写入）、用户的私有空间（~/，完全读写）。三层的设计原理是同一个：不同信任级别的实体看到不同的数据，写权限严格递增。

Agent 系统面对同样的分层需求。平台提供的不可变基础（基础配置、内置能力）对 agent 只读；跨 session 的共享状态（全局配置、共享知识）只能通过受控接口修改；当前 session 的工作区完全归当前 session 所有。三层结构和 OS 文件系统同构——不是巧合，是相同约束（多租户、最小权限、审计需求）逼出来的相同解法。

OS 在这一层还有一个经典策略：fork() 的 Copy-on-Write。父子进程共享同一份物理页，只在写时才复制。Agent session 初始化时可以用同样的策略——共享层的数据不做全量拷贝，只在 agent 需要修改时才创建私有副本。延迟复制，只在写时分配，避免不必要的初始化开销。

两层防御的完整性

权限维度防止 agent “做错事”——调用了不该调用的工具，执行了不该执行的操作。资源维度防止 agent “看错数据”——访问了不该访问的信息，污染了不该污染的共享状态。

两者的威胁模型不同，防御机制不同，但互补：权限系统被 prompt injection 绕过时，资源隔离是第二道防线；资源隔离被错误配置时，权限系统是第一道防线。这是纵深防御，不是单点防护。

权限和隔离解决了”agent 独自工作时”的信任问题。当 agent 需要协作——和人类协作，和其他 agent 协作——信任边界之间需要有通信通道。这是下一根支柱要解决的问题。

延伸阅读

• OpenAI. (2025). Unrolling the Codex Agent Loop. openai.com/engineering. — 信任边界的另一种生产实现：每个任务在独立沙箱中运行，网络默认关闭，文件系统隔离；和本文讨论的权限+资源双维度防御形成互补视角

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• Claude Code Permission System — 本文讨论的 deny-first 权限模式的生产级实现
• Permission Modes — 从完全手动到完全自动的权限谱系详解
• Permission Rules Hierarchy — deny 优先于 allow 的层级嵌套规则
• Agent Sandboxing — 资源维度隔离的工程机制
• LLM Security — “CPU 可以被说服”这一断裂点对应的安全研究
• Guardrails — 权限与隔离之上的约束边界框架

协作协议

隔离创造了安全，也创造了孤岛。

两个进程不能直接读对方的内存——这是信任边界设计的结果，也是 IPC 存在的原因。OS 在维持进程隔离的前提下，提供了精确的通信通道：管道、消息队列、共享内存、socket。核心特性一个：字节精确。进程 A 发了什么，进程 B 收到的就是什么，一个比特都不会变。

Agent 系统里的协作有两种本质不同的形态：human-agent（人类委托 agent），和 agent-agent（agent 之间通信）。两者共享同一个断裂点，但断裂的位置不同。

Human-Agent：通过 ACI 间接委托

OS 把用户意图翻译成硬件操作。用户点击”保存”，OS 把它变成一串 IO 系统调用——缓冲区刷新，文件系统元数据更新，磁盘写入。这条翻译链是精确的：用户的操作通过 GUI 事件系统被捕捉为确定性的 API 调用，最终到达硬件。

Agent 做同样的事，但通信介质不同。

用户说”帮我整理一下这份报告”，agent 把它变成一串工具调用——读文件，分析结构，重组段落，输出结果。这条翻译链的起点是自然语言，不是 API 调用。

ACI（Agent-Computer Interface）是这条翻译链的接口设计标准。 Anthropic 在 SWE-bench agent 的实践里发现，花在优化工具接口上的时间比优化 prompt 更多——工具名称要自解释，错误信息要让 agent 能理解，参数设计要防误（比如强制绝对路径而非相对路径，消除了 agent 在切换目录时的一类系统性错误）。

ACI 是 agent 系统的系统调用接口设计学：站在 LLM 的角度设计接口，就像当年的 OS 工程师站在程序员的角度设计 syscall API。区别不在结构，在介质——一边是类型安全的函数签名，一边是自然语言。

这条翻译链的断裂点在意图解释的不确定性。

“整理报告”是什么意思——保留原意改格式，还是重写使其更清晰，还是精简到原来的一半——取决于 agent 的解释。用户的意图是模糊的，agent 的执行是离散的，两者之间的映射是概率性的。这和 OS 的”保存文件”操作有本质差异：那是一个确定性的 API 调用，没有解释空间。

Karpathy 在 2025 年的演讲里把这个方向称为”让基础设施主动适配 LLM”——llm.txt 让网站直接提供 LLM 可读的内容，文档以 markdown 提供而非 HTML。这是 ACI 从单工具接口扩展到整个基础设施层的方向：不是让 LLM 去读懂为人类设计的界面，而是重新设计界面让 LLM 直接可用。

Agent-Agent：通过 A2A 直接通信

进程间通信是对称的：进程 A 和进程 B 都是 OS 下的进程，用同一套 IPC 机制通信。

Agent 之间的通信不那么对称——不同框架开发的 agent，不同语言写的 agent，不同公司部署的 agent，它们之间如何通信？

Google 的 A2A 协议（Agent-to-Agent，2025 年 4 月）是走向标准化的第一个尝试。三个核心组件：

• Agent Card：每个 agent 发布一份能力声明（JSON），描述自己能做什么、支持什么通信模式——类比 /proc 文件系统里的进程能力信息，让调用方可以在运行时发现对方能做什么
• HTTPS + JSON-RPC：确定性传输层，统一消息格式。用已经成熟的 web 基础设施承载 agent 通信，而不是重新发明网络协议
• OAuth 身份验证：跨组织 agent 通信的身份验证，解决”我怎么知道这个 agent 是谁”的问题

A2A 试图做的事，和 TCP/IP 当年做的事结构上相似：把分散的、私有的、框架内的通信协议，统一成一套跨实现的标准——让不同 OS 上的进程可以通信，让不同框架里的 agent 可以通信。

断裂点：语义信道的结构性衰减

OS 的 IPC 是字节精确的，A2A 的传输层也可以是字节精确的。但 agent 通信的断裂点不在传输层。

Agent A 生成一段摘要传给 agent B。这段摘要是 A 对原始信息的有损压缩：保留了 A 认为重要的部分，丢弃了 A 认为不重要的细节。但 A 的判断是概率性的，不是确定性的。B 基于这段摘要推理，可能进一步丢弃细节，变异语义。链条越长，衰减越多——A → B → C → D 之后，到 D 手里的信息可能已经面目全非。

这个问题两种协作形态都有，但机制不同：

• Human-Agent：人类意图在被翻译成 agent 行动的过程中，模糊性引入解释分歧
• Agent-Agent：agent 输出在被传递给下一个 agent 的过程中，压缩引入信息丢失

A2A 用确定性协议（HTTPS/JSON-RPC）包裹自然语言内容，减少了传输层的损耗。但无法消除语义层的衰减：消息里的自然语言内容依然是有损的，协议层无法校验语义完整性。

这是信道噪声在协作链路上的具体实例化：自然语言没有纠错码，每次传递都是一次有损的语义变换。结构化消息格式（JSON schema 约束字段，而非自由文本）减少衰减——但 agent 间需要传递的很多内容本质上是非结构化的判断和推理，无法完全结构化。

通信复杂度正交于模型能力

更强的进程不消灭 IPC 的需求——进程还是需要和其他进程通信，还是需要调用系统资源。

更强的 LLM 不消灭协作协议的需求。能接更复杂的任务，但复杂任务往往需要更多 agent 协作——更多的 human-agent 委托链，更多的 agent-agent 通信跳数。通信复杂度随任务复杂度增长，模型能力的提升不会使其减少。

通信协议的设计空间正交于推理能力。

每根支柱都当场指出了 OS 类比在哪里断裂。放在一起看，这些裂缝指向一个共同的方向——而不是随机散落的设计问题。

延伸阅读

• Anthropic. (2025). Building Effective Agents. anthropic.com/engineering. — ACI 设计原则的一手来源：为什么花在优化工具接口上的时间比优化 prompt 更多，工具名、错误信息、参数设计如何影响 agent 表现
• Factory.ai. (2025). Evaluating Context Compression for AI Agents. — 本文”语义信道衰减”论点的实证支撑：量化了信息在 agent 间传递时的有损程度

概念与实体

本文涉及的核心概念与实体，在项目知识库中有更详细的资料：

• ACI — 本文讨论的 Agent-Computer Interface 设计标准的详细资料
• A2A Protocol — Agent-to-Agent 协议的技术规格与设计动机
• Agent Card — A2A 协议中 agent 能力声明机制的详解
• Agent Interoperability — 跨框架、跨组织 agent 通信的互操作性问题
• Tool Design — ACI 原则在工具层面的具体工程实践
• Google — A2A 协议的发起方

类比的边界与超越

精确的断裂点，比模糊的相似更有价值。

把四根支柱的裂缝放在一起看，它们不是随机的设计问题——每一个都指向同一个根源。类比有用，它在哪里终止同样重要。

六个断裂点

这六个断裂点有一个共同的根源：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 与体系结构的顶级会议