第 23 章
看不见的操作系统
一份产业分析报告与一份采购目录,在同一周里指向了同一个事实。2026年3月,资深架构师艾琳·马尔凯蒂在拆解一家SaaS公司的技术栈时,画了一张她后来称为“职业生涯中最令人不安的架构图”。操作系统内核、容器运行时、应用框架、业务逻辑——这些分层是干净的。
但在应用框架与业务逻辑之间,有一个实体她无法归类。它不直接调用模型——那是业务逻辑层的事。它不管理数据库连接——那是框架的事。它做的是另一件事:接收业务逻辑层发来的任务意图,拆解为多步工具调用序列,在执行每一步之前检查权限,在每一步之后验证结果,在失败时触发重试或回滚,在完成后生成审计轨迹。这一层大约有十一万行代码——比这家公司的应用框架层还厚。
马尔凯蒂在博客中写道:它没有名字。它不是模型层,因为模型调用只是它调度的对象之一。它不是应用层,因为七个不同的业务应用共用了同一套逻辑。它在架构图里应该画在中间,但现有的分层词汇里没有它的位置。她给它取了一个临时名字:某层。
同一周,一家全球前十的商业银行完成了2026年度IT预算的第十一版修订。这份文件在行业论坛上被匿名贴出后,引发了开发者社区的安静骚动。
不是因为总金额——银行的IT预算从来不缺数字——而是因为三个独立列项的支出类别在此前的预算表中从未出现过。第一项,智能体编排服务,年预算四百七十万美元,涵盖内部代理的调度、冲突解决与状态持久化。第二项,工具市场订阅,年预算二百一十万美元,涵盖第三方工具连接器的授权、更新与安全审计。第三项,权限审计与回滚追踪,年预算一百八十五万美元,涵盖每一次智能体行动的签名验证、权限变更记录与人在环审批日志。这三项的总和,恰好等于该行模型API调用预算的百分之六十二。
让模型跑起来的花费,和让模型安全地、可审计地、持续地干活的花费,已经进入了同一个量级。这是一个财务事实。
而马尔凯蒂的“某层”,是一个认知事实。两个事实之间隔着一片大西洋,但它们指向了同一个结论。
这个结论,本书用了二十三章,从ELIZA的脚本外壳追踪到MCP的协议生态,从AutoGPT的九十天狂热追踪到卞承志和他的AgentBridge仓库最后一条无人回复的评论,来逐步逼近。现在,在终章,它需要被明确地说出来。
缰绳层已经长成了软件业的一层新的操作系统。这个判断不是隐喻。它是一组可验证的结构性主张。而完成这个论证,是本章唯一的任务。
要理解什么东西能被称为操作系统层,首先得理解操作系统层是怎么来的。这不是一个技术分类学问题。它是一个资源管理史的问题。
1964年,IBM推出OS/360。这个决定让整个软件业在此后几十年里反复引用它的架构逻辑,但OS/360真正的历史贡献不在代码里。它在于做出了一个决定性的架构选择:把调度权从应用中抽走,放进一个独立的控制层。在此之前,每一台计算机上的每一个程序都要自己管理内存分配、I/O调度和处理器时间。OS/360改变了这一点。
它管理的不是程序本身,而是一种程序无法自治调度的稀缺资源——CPU时间。多个程序要共享同一台机器,谁先跑、跑多久、怎么切换,这些决策如果交给应用程序自己处理,每一个程序都得写一套调度逻辑,而且它们会互相踩踏。操作系统的核心功能——进程调度、内存管理、I/O控制——不是为了让计算机更好用。它是为了管理一种应用程序自身无法协调的稀缺资源。
这个逻辑在之后的半个世纪里重复了三次,每一次都催生了一个新的软件层。
1980年代,稀缺资源从CPU时间变成了用户注意力。一台机器上跑着几十个程序,但屏幕上只能同时显示一个窗口。谁来管理这个窗口的焦点、事件队列和输入分配?图形用户界面和窗口管理器成为了操作系统层的新组成部分——不是因为它属于内核,而是因为它管理的是应用程序自身无法自我协调的注意力资源。1990年代中期,浏览器成为一个新的准操作系统层。稀缺资源是网络状态。
页面加载的异步性、DOM树的动态变化、跨域请求的安全边界——这些复杂性如果交给每个网页自己去处理,互联网将退化为一个不可用的碎片集合。浏览器承担了事件循环、沙箱隔离和渲染管线的职责。它管理的是TCP连接之上、HTTP协议之外的运行时状态。
Netscape的工程师在1995年没有宣称他们在写操作系统。但到了2008年,Google发布Chrome时,其多进程架构设计文档中已经将Chrome称为一个操作系统级的运行时。这个判断在当时被广泛接受,因为证据不在标签上,而在架构图里。
2014年,容器编排成为一个新的操作系统层。稀缺资源是集群中的计算节点。Docker解决了打包问题,但它没有解决在哪个节点上跑哪个容器的问题。Kubernetes在2015年发布时,其核心抽象——Pod、Service、Deployment——管理的不是单个容器的生命周期,而是整个集群的拓扑状态。
2017年,Red Hat的架构师在CNCF的一次演讲中画过一张图:Kubernetes位于Linux内核与微服务应用之间,它的厚度已经超过了传统的操作系统层。那一年,Kubernetes的代码仓库里有超过一百万行Go代码。没有人质疑它是不是一个独立的软件层。争论的只是它应该叫什么。
这四次层诞生的共同条件是:出现了一种新的、对应用程序运行至关重要的稀缺资源,这种资源无法被下层有效调度,也无法被上层自治协调,因此必须由一个独立的中间层来管理。这个中间层一旦建立,就会成为所有上层应用依赖的基础设施,而它自己的演化逻辑将不再由任何单一应用决定。
大模型时代出现的新稀缺资源是什么?答案是模型的注意力与行动能力。这个表述需要拆解。
一个大模型不是一个无差别的计算单元。它有一个上下文窗口,有token预算,有推理延迟,有幻觉概率,有工具调用失败率,有权限边界。每一次调用,都是在消耗一个有限的、有成本的、可能出错的能力。
当一个应用需要调用模型十次来完成一个任务,这十次调用之间不是独立的。上一次调用的输出决定了下一次调用的输入。上一次工具调用的结果决定了是否需要重试。上一次权限检查的结果决定了是否终止执行。这个链条就是缰绳。
而管理这个链条——决定何时继续、何时重试、何时切换工具、何时请求人类批准、何时记录审计日志——消耗的不是模型能力,而是一种独立的工程资源。这就是为什么在2026年的企业采购目录中,智能体编排服务成为了一个独立预算项。因为它管理的不是模型,而是模型的行动序列。这是一项模型本身不提供的服务。
经济学维度给出了第二个证据。在软件业的历史上,一个独立的层之所以能被称为“层”,不仅因为它管理了一种稀缺资源,还因为它创造了独立的价值捕获点。操作系统创造了许可证收入。浏览器创造了搜索入口和默认主页的竞价权。Kubernetes创造了云服务绑定和集群管理费。每一层都有自己的商业模式,这个模式不依赖于它下面的层,也不被它上面的层完全吸收。
缰绳层在2024到2026年间,出现了三个独立的价值捕获点。第一个是工具市场。当MCP在2024年11月发布后,工具连接器的开发从每个应用自己写变成了一次开发、多应用共享。这创造了一个新的交易市场:MCP服务器的开发者可以独立于模型提供商和应用程序开发商,向最终用户收费。2025年,一家名为ToolChain的初创公司以两千三百万美元的估值完成了A轮融资,它的唯一产品是GitHub和Jira的MCP服务器。
这笔交易的逻辑在2023年是不可想象的。那时工具接入还是应用代码库里的一个utils目录。
第二个是权限代理。当智能体开始执行需要企业级权限的操作——访问数据库、发送邮件、修改财务记录——时,把根权限直接交给模型等于自杀。这使得权限代理成为一项独立的工程服务:一个位于模型和系统之间的守护进程,负责验证每一次工具调用的签名、检查权限等级、记录操作日志,并在异常模式出现时触发回滚。
2026年,一家名为Signet的初创公司将其权限代理产品以一亿四千万美元卖给了一家网络安全巨头。Signet的代码库只有不到五万行。它的价值不在代码量,而在它占据了一个新的价值捕获点——这个点在两年前根本不存在。
第三个是编排审计。当企业部署了数十个智能体,每一个都在执行几十步的工具调用,审计需求就不再是事后查日志,而是实时追踪每一个决策链路。编排审计工具记录的不是谁调用了API,而是为什么选择了这个工具而不是那个工具、在这一步模型是否请求了人类批准、回滚触发时的状态快照。这些信息在传统的应用性能监控系统中完全不产生。
它们是一个新数据类别,需要一个新工具类别来处理。2026年,Datadog和Splunk都发布了智能体编排审计模块,但它们的市场份额被一家名为Truss的初创公司紧咬不放。Truss只做编排审计,它的架构从第一天起就没有为任何其他类型的数据设计。这三个价值捕获点的共同特征是:它们都不是模型交易的附庸。
一个企业可以同时使用三家模型提供商,但它的工具连接器、权限策略和审计日志只保存在一套缰绳层中。这就是层锁定的经典机制。在操作系统史上,每一层都是通过管理一个独立于下层硬件的持久状态来实现锁定的——文件系统、窗口位置、Pod定义。缰绳层的持久状态是工具配置、权限策略、编排历史。这三个东西不会因为换了模型而消失。它们构成了缰绳层的护城河。
但经济学证据只是论证的一面。政治经济学给出了第三面,也是最锋利的一面。
谁控制操作系统层,谁就定义了生产条件。这不是夸张。这是操作系统史的常数。当微软控制了PC操作系统层,它定义了应用程序的发行方式和用户的升级节奏。当苹果控制了iOS,它定义了开发者必须使用什么语言、通过什么审核、交多少分成。当Google控制了搜索入口,它定义了网页必须如何构建才能被索引。每一层都有它的治理结构,而治理结构从来不是技术中立的。
当缰绳层在2025年从一堆开源框架凝聚成一个协议驱动的生态系统时,治理问题就从一个社区管理问题变成了一个政治经济学问题。
MCP的治理委员会在2025年3月发布了第一版章程。委员会有七个席位:Anthropic占两个,三家采用MCP的云平台各占一个,两个独立开发者社区代表。章程规定,MCP协议的版本演进需要委员会三分之二多数通过。这看起来是一个开放治理的模板。
但在2025年9月,社区代表提出在MCP 1.2中加入对本地优先工具发现的支持——一个允许离线环境下自动发现局域网内可用工具的特性。三家云平台联合Anthropic投了反对票。会议记录列出的反对理由是安全边界不明确。
社区代表在会后发表的一篇博客中写道,真实原因更简单:本地优先工具发现会削弱云平台作为工具注册中心的地位。如果工具可以在局域网内自动发现,为什么还要通过云平台来注册?记录只到这一步。没有后续调查,没有反方声明,没有公开的投票明细。但这次投票的影响超出了MCP社区。
在接下来的那一周里,UAAP的治理工作组——那个在标准战争中落败的协议联盟——发表了最后一封公开信。信中明确写道,当协议核心层的技术决策与治理方的商业利益发生结构性冲突时,形式上的开放治理无法保证实质上的生态中立。这封信没有改变MCP的市场地位。
但它留下了一个问题,一个在2026年仍然悬而未决的问题:如果缰绳层真的成为了操作系统层,那么它的治理结构,究竟应该像一个标准委员会,还是像一个立法机构?这个问题不是学术性的。在2026年,它已经体现在具体的商业决策中。当Anthropic在2025年第四季度的分析师简报中将MCP生态描述为智能体基础设施的默认层时,一位分析师追问了MCP是否计划作为独立实体运营、是否支持第三方主导的治理。Anthropic的回复是,公司致力于确保MCP的开放演进以满足生态系统的需求。这是一个典型的公关措辞。
微软在1996年对ActiveX是否开放标准的回复,在语法结构上几乎与此相同——公司致力于与行业伙伴合作,确保ActiveX满足开发者的需求。历史学家知道ActiveX的后续故事。但2026年的产业参与者没有历史学家的后见之明。他们只能基于当下的信息作出判断。
当模型厂商在2025年下半年开始将MCP服务器运行时直接集成到它们的API网关中时,一个新的战略问题浮现了。如果模型API本身就能够处理工具调用、权限验证和状态管理,那么独立的缰绳层厂商——那些做编排的、做审计的、做工具市场的——将面临什么?这个问题触到了本书核心论证的最后一次递归。
脚手架悖论说:缰绳层的每一项发明,最终都会被模型层吸收。我们已经看到它发生了四次。
提示词工程被模型训练吸收。工具调用被函数调用API吸收。思维链被推理强化学习吸收。多步规划被agentic训练吸收。每一次吸收,都逼着缰绳层向上爬一层——从提示词到框架,从框架到协议,从协议到编排。
现在,当缰绳层已经长到操作系统层的厚度时,脚手架悖论面临一个前所未有的问题。如果整个缰绳层被吸收,那意味着什么?
这意味着模型本身将成为一个自包含的运行时。它不再需要外部循环,因为它内置了规划。不再需要外部工具调用协议,因为它在推理时动态生成API调用。不再需要外部权限管理,因为它内部化了安全约束。不再需要外部编排,因为它在训练数据中学会了多步任务分解。如果这个愿景实现,缰绳层作为独立软件层的存在基础将被彻底抽空。
但这是一个愿景,不是一条可预测的路径。2026年的技术现实是:最先进的模型在简单任务上可以实现端到端执行,但在涉及多工具协同、长周期持久化状态和跨应用权限的场景中,仍然需要外部缰绳。
这不是一个模型不够聪明的问题。这是一个架构约束问题。即使模型能够完美推理,它仍然需要一个地方来存储那些不属于任何单一对话的持久状态——工具配置、权限策略、审计日志。这些状态的生命周期,比任何一次模型调用都长。
它们需要被一个独立于模型的生命周期管理器来维护。这就是操作系统层的本质:它管理的是比单个进程更长的状态。
但脚手架悖论要求我们追问:如果模型厂商决定将状态管理也纳入模型呢?不是通过模型推理,而是通过平台集成。当一个模型API附带了一个内置的键值存储、一个内置的工具注册表、一个内置的权限管理器,那么模型就不再是一个推理端点,而是一个包含了缰绳功能的平台。
到那时,竞争将不再发生在模型与缰绳之间,而发生在模型厂平台与独立缰绳层之间。这就是2026年的产业格局。
它不是一个稳定的终结状态。它是一张正在被拉紧的弓。群像并置的方法,最适合用来描绘这张弓上不同位置的受力者。第一个视角来自企业采购者。芝加哥一家中型保险公司的CTO在2026年第一季度做出了一项决策,这项决策后来被分析师称为缰绳层独立采购的临界案例。
这家公司使用了两家模型提供商——一家用于理赔文档处理,一家用于客户服务对话——但它的智能体编排、权限管理和审计日志全部运行在一套独立的缰绳层上。CTO在内部备忘录中写道,公司不会把理赔流程的审批权限绑定在任何一家模型提供商上,如果明天换模型,理赔流程不能停。备忘录的措辞是技术性的,但逻辑是政治经济学式的:将缰绳层与模型层解耦,不是因为技术需要,而是因为权力关系需要。
第二个视角来自协议标准制定者。2026年4月,MCP治理委员会召开了一次关于MCP 2.0路线图的公开会议。会议记录显示,讨论的焦点不是技术细节,而是MCP的版本演进应该在多大程度上响应模型厂商的新功能。一位来自独立开发者社区的代表提出,如果模型厂商在API中提供了与MCP功能重叠的特性,MCP应该保持独立路线,而不是被动适配。一位来自云平台的代表则主张,MCP应该拥抱模型厂商的创新,将其作为可选的替代实现路径。
这两种立场之间的分歧,在会议记录中体现为一段长达三页的辩论。辩论没有结论。但记录显示,在会议结束后,三家主要MCP服务器开发商的代表私下交换了意见,讨论是否应该成立一个独立的缰绳层基金会,将MCP从Anthropic的治理架构中移出。记录只到这一步。没有公开的后续行动。但讨论本身的意义,超过了任何可能的直接结果:它意味着缰绳层的从业者已经意识到,他们在建造的东西,其治理结构将决定他们的长期命运。
第三个视角来自模型厂战略部门。2026年5月,一家主要模型厂商在分析师简报中展示了一张技术栈示意图。这张图将应用层放在最上面,模型层放在最下面,而在两者之间,有一个标记为编排与工具层的长条。
一位分析师在问答环节中提问,这个层的功能是公司计划内化的,还是期望生态伙伴来提供的。高管的回答是,公司会在平台中提供最基础的能力,但企业级场景需要专业的编排解决方案。这句话的措辞结构与微软在1990年代对操作系统应该内置多少中间件的回答几乎完全一致。
基础能力内置,高级能力留给生态——这是平台厂商的标准话术。它的效果是:生态伙伴被推到利润更薄、差异化更小的上层,而平台厂商占据了价值最密集的底层。
第四个视角来自一个具体的人。卞承志在2025年秋天,在AgentBridge的GitHub仓库首页写下进入维护模式的公告后,没有再更新过那个仓库。但在2026年4月,他在自己的博客上发表了一篇长文,标题是《我为什么不再做通用智能体了》。
这篇文章读起来不像告别,而像一个诊断。他写道,通用智能体的问题不在于技术。问题在于,当你试图做一个连接所有工具的通用层时,你同时得罪了模型厂和平台厂。模型厂说,工具调用是我们API的一部分。平台厂说,连接器是我们的护城河。你卡在中间,管理着最复杂的逻辑,却占据着最薄的价值捕获点。
这不是一个工程问题。这是一个架构位置问题。卞承志没有使用操作系统层这个词。
但他描述的结构,正好是操作系统层的经济逻辑:底层被模型厂控制,上层被平台厂控制,中间层承担复杂性和协调成本,却无法独立定价——除非它成为一个平台。而成为一个平台,需要的不只是技术。它需要治理结构、市场力量和制度设计。
在文章的最后,卞承志写了一段话。这段话放在终章中,不是为了给出答案,而是为了标出问题的位置。
智能体需要基础设施。但基础设施的建造者需要知道,他们在为谁建造,以及建造完成后,谁将拥有它。如果你建造了一个操作系统,你就必须面对操作系统的政治。而他,一个写代码的人,没有准备好面对这个。
这篇文章的评论区出现了十个月前在AgentBridge仓库下提问的那个人。他写道,祝贺你找到了方向,他还在卡在认证层。卞承志回复了他。回复只有一行:认证层从来不是技术问题,它是架构位置问题,你站在层与层之间的缝隙里,那里没有光照。缝隙。这个词精准地描述了2026年缰绳层的处境。
它已经站在了操作系统层的位置,但它的治理结构、经济模式和制度合法性,还没有跟上它所占据的架构位置。这个裂缝,就是缰绳层从技术事实到制度事实之间最后的距离。
技术史维度给出了架构逻辑。经济学维度给出了价值捕获。政治经济学维度给出了治理冲突。这三个维度共同编织成了论证的网。
但论证的完成,需要一个历史判断。1974年,当Gary Kildall编写CP/M时,他没有说自己在写一个操作系统层。他说的是自己在写一个磁盘控制器。磁盘控制器是CP/M的起点——一个管理磁盘I/O的程序。但当Kildall意识到,这个程序需要管理的不只是磁盘,还包括内存、控制台输入和文件系统,他将它抽象成了一个独立的层,并给它起了一个名字:BIOS,Basic Input/Output System。这个抽象后来成为了PC操作系统的基础。但它的创立者,在创立它的时候,并没有预见到它的最终形态。缰绳层在2026年所处的阶段,大致相当于CP/M在1976年的阶段。
它已经有了独立的架构厚度,有了独立的价值捕获点,有了生态系统的雏形,有了治理问题的初现。但它还没有一个响亮的名字,没有一套公认的接口标准,没有一个独立的治理机构。产业分析师在画架构图时,仍然把它的各个部分分散在不同的层级中——权限管理属于安全层,工具调用属于集成层,编排属于应用框架。他们还没有画出一条横线,把这些散布的逻辑块连成一个连续的层。
但那条线已经存在了。它存在于企业采购目录的独立预算项中。它存在于MCP治理委员会的会议记录中。它存在于芝加哥保险公司CTO的内部备忘录中。它存在于卞承志的博客文章和那个关于认证层的回复中。它存在于每一个决定将缰绳逻辑与模型调用解耦的架构决策中。
当这些独立的决策积累到一定数量,它们就不再是孤立的工程选择。它们构成了一个模式。而这个模式,就是本书一直在追踪的实体:一个看不见的操作系统,它的每一次出现都以工具、技巧或临时方案的外衣出现,但它的每一次进化都在向一个独立的软件层逼近。
在编写这一章的过程中,2026年的产业分析师报告、企业采购目录、治理委员会会议记录和开发者博客文章,已经提供了足够的证据来支撑这个判断。但证据的边界也需要被标记。
Gartner的智能体基础设施技术成熟度曲线中,缰绳层的各个组件被分散在编排、工具管理、权限审计等不同类别中,没有合成一个统一的层。Forrester的AI代理基础架构报告中,虽然描述了一个位于模型与应用之间的中间层,但将其定义为过渡性架构,预测它将在三到五年内被模型平台吸收。这些分析师的框架,在2026年还在追赶技术现实。但追赶本身,就是技术现实已经领先框架的标志。
操作系统层在历史上从来不是被分析师的报告定义的。它是被架构图、采购预算和治理冲突定义的。当架构图需要一个新层来解释系统结构,当采购预算为这个层分配了独立资金,当治理冲突围绕这个层展开——这个层就已经存在了,无论它有没有被正式命名。
本书的论证到这里,已经完成了它的核心任务。但还有一个问题需要被提出。
不是因为它有答案,而是因为它的提出本身,标志着论证的完成。脚手架悖论的最后一轮递归,指向的是缰绳层自身的命运。如果缰绳层所管理的每一项能力——工具调用、权限验证、编排循环、状态管理——最终都被模型本身内化,那么缰绳层作为独立软件层的基础将不复存在。
但在这个判断之后,站在2026年的证据边界内,必须追问一个更深入的问题:内化是全部还是部分?模型内化的是能力,还是控制权?当一个模型厂商将工具调用功能内化到API中时,它消除的是市场的碎片化,还是市场的独立性?
这些问题在2026年没有答案。但它们的存在,意味着缰绳层的历史并没有在2026年闭合。它只是进入了一个新的阶段——一个从技术建造转向制度建造的阶段。
技术建造解决的是能不能做的问题。制度建造解决的是谁来做主的问题。缰绳层在2022到2026年间,完成了技术建造的主体部分。它证明了循环、工具、权限和协议,是可以被工程化的。它证明了这一层有独立的架构厚度和经济价值。
它甚至证明了,当这一层被标准化后,整个生态的效率会跃升。但它还没有证明,这一层能够建立一套独立于模型厂商的治理结构,能够维护一个不被平台吸收的价值捕获点,能够成为像操作系统、浏览器或容器编排那样的持久层——而不是一个被下一轮技术浪潮吞没的过渡形态。这个问题,在2026年,还悬在每一个缰绳层从业者的头上。
就像CP/M在1976年还不知道IBM PC将如何重塑它的命运,就像NCSA Mosaic在1993年还不知道Windows 95将内置IE,就像Docker在2014年还不知道Kubernetes将夺走编排的定义权。历史的下一轮,总是从当前的裂缝中长出。
而缰绳层在2026年的裂缝,就是卞承志所说的那个缝隙:架构位置已经在那里了,但制度位置还没有。谁来定义缰绳层的接口标准?谁来治理协议的版本演进?谁来保证独立工具开发者的利益不被平台挤压?谁来确保企业采购的缰绳层组件不会被某一家模型厂锁定?
这些问题,在2026年,正在从技术问题变成政治问题。而政治问题,不是靠写代码能解决的。在距今二十三章之前,本书从ELIZA的脚本外壳开始。Joseph Weizenbaum在1966年写下的那个DOFFILE,是缰绳层最原始的形态:一个脚本,定义了一个对话循环,将用户输入与关键字匹配,生成预设的回复。它没有智能。它不调用工具。它不管理权限。但它已经包含了缰绳层最核心的抽象:循环在模型之外,控制权在设计师手中,输出是模型与规则的共同产物。五十九年后,当艾琳·马尔凯蒂在架构图中找不到合适的位置来放置那个十一万行代码的某层时,她遇到的困惑,与1966年MIT计算中心的参观者第一次与ELIZA对话时的困惑,在结构上是同构的。参观者以为自己在与一个会思考的机器对话,实际上在与一个脚本循环交互。马尔凯蒂以为自己在看一个应用架构,实际上在看一个尚未被正式命名的操作系统层。两次困惑之间,隔了整整五十九年的技术演进。
但困惑的核心没有变:当软件学会了调用智能,智能与软件之间的界面,就变成了一个独立的东西。这个界面需要被设计、被工程化、被治理。它不会消失,不会自我管理,不会因为模型变得更聪明而变得多余。它只会向上爬。本书的论证到此结束。但缰绳的历史,在这一页之后,将继续展开。