AI WINTER AND SPRING · CHAPTER 10

Agent Operating System

以状态管理、知识演化和独立验证构成 Agent Operating System,尝试跳出繁荣与寒冬循环。

那个名字

上一章结尾说,2026 年的人类手里多了 1985 年没有的三张牌。现在该把那三张牌摊开来看了。

它们不是技巧,不是 prompt 套路,不是某个框架的功能列表。它们是基础设施——三个让 Agent 从"可能可靠的魔法"变成"可被信任的工程系统"的底层能力。它们各自对应着前面九章诊断出的一个病灶群,各自有一个在软件工程史上已经被验证过的成熟形态。

把它们加在一起,就是这本书的最终判断的正面版本:Agent 要逃出"繁荣—寒冬"的循环,不能靠更大、更聪明、更多数据。要靠给它造一个操作系统。

那个操作系统的名字,就是这一章的标题——Agent Operating System

第一根支柱:State Management(状态管理)

专家系统没有检查点。MYCIN 的推理是一条单向流——规则触发、结论得出、结束。你不能在中间停下来存一个快照,不能在走错路时回滚到三步之前,不能把一条推理链分叉成两个候选并行探索。规则一旦加进规则库就加进去了,出问题只能事后排查,而且排查的过程本身又是另一条不可逆的推理链。

这是专家系统时代的状态管理能力:零。

2026 年的 Agent 系统,已经有了更好的东西。langgraph 把 Agent 建模成有状态图——每个节点是一个决策点,每条边是一次状态转移,整个执行过程可以被序列化、存档、回放。我们的对位台账就是一个原始的版本:每写一章,状态从"待埋"推进到"已埋"再到"已闭合",任何一步出错都可以定位到具体的状态迁移,然后退回去重做。

状态管理的本质,是把易失的推理上下文固化为可检查点的状态。它回答的问题是:"这个 Agent 现在在哪、它怎么到这里的、它能回到哪里去?"——这三个问题,1985 年的 MYCIN 一个都回答不了。2026 年的 Agent 能回答,前提是你给它造了状态层。

但这还不够。状态管理不只是"能存档"——它还要能演化。这就引出了第二根支柱。

第二根支柱:Knowledge Evolution(知识演化)

专家系统的规则库是静态的。加规则靠人——知识工程师访谈专家、写规则、测试、上线。删规则靠人——而且没人敢删,因为不知道删掉一条会影响哪些既有的正确推理。冲突检测靠人——XCON 后期一万七千条规则,任何一条改动都要验证它和其余全部规则的相容性。知识库不是一个能被维护的资产,它是一个只能增不能减的沉积层

这本书的史料库,是一种不同的东西。它是一份带状态标记(✅已核证 / ⚠️有出入 / ❓存疑)、带变更日志、带引用契约的可演化文档。当新的核证推翻了旧的结论——比如发现第五代机预算不是 8.5 亿美元而是约 4 亿——我们不删掉旧卡片,而是更新它、标注冲突、保留审计轨迹。当不同章节引用同一条史料时,它们引用的是同一个卡片 ID,改一处即处处生效。

这不是什么新发明。软件工程几十年前就解决了这个问题——它叫版本控制。Git 管理的是代码的演化,史料库管理的是知识的演化。专家系统的悲剧在于,它诞生在版本控制成为软件工程标配之前——规则库没有被当作"需要演化的代码"来管理,而是被当作"一次性写死的真理"来对待。

知识演化回答的问题是:"这个 Agent 脑子里的东西,能不能像软件一样被维护?"——能,条件是你把它从 prompt 里抽出来,固化成带版本、带审计、带冲突检测的工程资产。这就是"把易腐的上下文,固化为可演化的资产"这句话的精确含义。

但演化了还不够。演化的方向对不对?更新的知识是不是错的?这就引出了最关键、也最反直觉的第三根支柱。

第三根支柱:Verification(验证)

这一根最难,也最重要。

专家系统的验证和推理是同一套东西。你用规则库推理出诊断,也用规则库自检诊断是否合理——这是循环论证。一个 MYCIN 如果给出了错误诊断,没有任何独立的机制能发现这个错误,因为"判断对错"用的规则和"生成答案"用的是同一个规则库。

我们的 Agent 实验揭示了这个问题的当代版本,而且更隐蔽。那个 DENDRAL 升级版 Agent,在面对它工具库不覆盖的金属有机化合物时,没有承认自己不会,而是靠 LLM 的预训练记忆给出了看起来正确的答案——但绕过了工具校验层。模型"自信"地认为自己对了,而它用来判断"对不对"的能力,和它用来"生成答案"的能力,是同一个 LLM。这是循环论证的 2026 年版本。

验证层的本质,是把"判断对错"从"生成答案"里解耦出来。它必须独立。Fact-Checker 智能体不信任 Researcher 智能体的初判,用一手来源独立交叉复核——这是写作流水线里的验证层。METR 审查 SWE-bench 通过的 PR 能否被维护者真正合并——这是代码 Agent 的验证层。OpenAI 自己弃用一个被污染的基准——这是产业级的验证层自纠。

验证不信任推理。验证不信任"自信"。验证只信任独立于推理过程的、可复现的证据。这是三根支柱里最反直觉的一根——因为它要求你承认,Agent 自己说的"我做对了"没有任何可信度,除非有一个独立机制证实了它。

第九章元叙事段落里那句话,在这里有了精确的工程含义:这本书能写成,不是因为 Agent 可靠,而是因为 Fact-Checker 拦截了它的每一次不可靠。

三个支柱,一个操作系统

Agent OS 的状态管理、知识演化和独立验证三根支柱
Agent Operating System 以状态管理、知识演化和独立验证构成可恢复、可演化、可验证的基础设施。 TerminalAI 原创信息图,CC BY-NC-SA 4.0。

把三根支柱放在一起:

State Management    —— 把易失的推理上下文,固化为可检查点、可回滚的状态
Knowledge Evolution —— 把静态的知识沉积层,变成可版本化、可演化的工程资产
Verification        —— 把"自不自信"和"对不对"解耦,用独立验证不信任推理

它们不是三个独立的功能。它们是一个操作系统的三个层面——就像进程管理、内存管理、文件系统之于传统操作系统。没有进程管理,程序之间会互相踩踏;没有内存管理,数据会泄漏;没有文件系统,数据重启即失。Agent OS 的三根支柱对应着 Agent 时代的三个等价物:

传统 OS Agent OS 防止的病灶
进程管理 State Management 长程任务漂移(A3)
文件系统 Knowledge Evolution 规则/Prompt 爆炸(A1/A5)
权限与审计 Verification 脆弱性与评测危机(A4/A6)

这个类比的力度在于:没有人会指望一个没有操作系统的裸机能可靠地运行程序。那为什么要指望一个没有 Agent OS 的 Agent 能可靠地完成任务?

Devin 的复现鸿沟、SWE-bench 的评测危机、Agent 框架的洗牌——这些 2024 到 2026 年的乱象,本质上都是"在没有操作系统的裸机上跑程序"的后果。MCP(模型上下文协议)是这个操作系统的 I/O 层雏形——它标准化了 Agent 与外部世界的连接,就像 USB 标准化了硬件接口。但 I/O 层只是一个开始;上面还需要进程、内存、文件系统。

诚实的边界

到这一步容易把它说成万灵药。但 Agent OS 有它到不了的边界。

组合爆炸不会因为有了状态管理就消失。状态管理让爆炸可追踪——你能定位是哪两条规则冲突——但它不能让冲突不存在。一万七千条规则仍然有一亿多个两两配对,你只是能更快地找到出问题的那个。隐性知识也不会因为有了知识演化就变得可编码——Polanyi 的天花板还在那里,你只是让已经编码的那部分可以被维护。验证层能在事后抓住错误,但不能阻止错误发生。

更尖锐的是国家竞赛。第五代机的故事在"主权 AI"上重演,这不是工程能解决的问题——日本 1982 年的豪赌、美国 2023 年的 Code Red、各国今天对 AI 算力和人才的争夺,不会因为有人发明了一个好的 Agent 框架就消退。

Agent OS 能做的,是把灾难性坍塌降级为可控的工程问题。它不能保证 Agent 不犯错——但它能保证错误可被发现、可被回滚、可被修正,而不是像 XCON 那样,一万七千条规则失控时,整个系统无声地崩溃,直到维护团队花一年才搞清楚是哪条规则出了问题。

这就是 2026 年和 1985 年真正的区别:不是 Agent 比专家系统强,而是我们多了一个选择——把脆弱性当作工程问题来对待,而不是当作命运来接受。

收束

这本书从 1956 年的达特茅斯写起。那年夏天,McCarthy 在一份两页纸的提案里写下了"artificial intelligence"这个词,和一句信仰告白:"学习的每一个方面,原则上都能被精确描述,从而可由机器来模拟。"

七十年过去了。那句信仰告白仍然没有被证伪——也没有被证实。 McCarthy 设想的那种"能被精确描述从而可被模拟"的智能,在窄领域里实现了(DENDRAL、MYCIN、XCON、AlexNet、ChatGPT),但在开放世界里,每一次尝试都撞上了同一堵墙:开放世界的状态空间随规模超线性增长,永远比你能写下来的知识跑得更快。

这堵墙不是技术问题。它是认识论的。Polanyi 1958 年就指出过它,Dreyfus 1965 年就预言过它,Feigenbaum 1977 年就命名过它的瓶颈。但它不会因为被指认就消失。

那本书的收束不在这堵墙上。收束在墙的这一边——在那些已经学会和墙共存的工程实践里。

专家系统没有学会和墙共存,所以它坍塌了。它把知识当作一次性写死的真理,把推理当作不可逆的单向流,把验证当作自我循环。当规则的重量超过它能承受的极限,没有人能接住它。

Agent 有没有可能不一样?有可能。但前提是——我们把 Agent 当作一个需要操作系统的工程系统来对待,而不是当作一个"只要够大够聪明就能自己搞定一切"的魔法盒子。

三根支柱,构成一个操作系统,给了我们一个选择。

1956 年,McCarthy 给一个尚未存在的学科起了名字。七十年后,该给一个正在到来的东西起名字了。

Agent Operating System。

不是因为它已经存在,而是因为——如果 Agent 要逃出这个七十年的循环——它必须存在。

(全书完。本书全部史料均经独立核证,详见各章史料核证附录与 03-写作编排/史料库.md。本书写作过程本身是多智能体协作的实践,详见 03-写作编排/。本书包含一项作者亲自执行的 Agent 边界实验,详见 04-agent实验/。)