先把话说在前头这是一个看着像玩笑、实际上特别狠的问题。AGI 判断标准学习多少本书可以写出 Linux 0.11我第一眼看到的时候觉得这题没法答因为没人真去数过 Linus 当年读了多少本书。但你真往深了想这个问题的分量非常足——它其实在问一个通用人工智能到底要具备多深的知识、多强的推理和多扎实的工程能力才能从零造出一个真实可运行的操作系统。而不是在代码竞赛里刷几道算法题、或者在对话里背出一段 Linux 内核源码。我在自己的技术博客里聊过很多次操作系统、内核和系统级编程的话题也追过 AGI 评测相关的路线。这篇文章想把我对Linux 0.11 AGI 判断标准这两个词背后所有能拆的东西都拆一遍为什么偏偏是 Linux 0.11而不是别的项目多少本书这件事应该如何被量化真正卡住大模型和普通人的难点到底是什么如果我们要拿这个目标当评测基准环境、评分、失败模式怎么设计。这既是给搞 AGI 评测的人看的也是给所有想挑战自己是否真懂计算机系统的开发者看的。如果你是一个正在学操作系统的新手这篇文章能告诉你该往哪个方向使劲如果你在做大模型评测或者 Agent 开发这篇文章能给你一个非常具体的压力测试场景。下面我直接进入正题。1. 为什么偏偏是 Linux 0.111.1 一个人类天才的真实产物规模刚刚好Linux 0.11 是 Linus Torvalds 在 1991 年发布的操作系统内核版本。它不是一个玩具也不是教学演示——它是一个真的可以在 Intel 80386 机器上启动、运行 shell、执行编译和文件操作的操作系统内核。但它又足够小整个内核大约只有 1 万多行 C 代码加上几百行汇编。这个体量刚好卡在一个非常微妙的位置上它比任何课程大作业都复杂得多但又比现代 Linux 内核的几千万行代码小得多一个认真的人或者一个认真的 AI是真的有可能在有限的上下文里理解它的全部。为什么用这个版本而不是 Linux 6.x 来当 AGI 的判断标准答案很现实现代内核你根本不可能让任何模型在上下文窗口里完整读完一遍更别说让一个 Agent 真的把它跑起来、在里面改代码、做编译、调试。Linux 0.11 是一个人能完全理解的最小真实操作系统。它有进程调度、内存管理、文件系统、中断处理、系统调用、内核与用户态的切换所有这些操作系统的核心机制都在但每一样都只有几百到一两千行代码。这就成了一个完美的端到端工程测试题。我自己的体会是很多人说我看过 Linux 内核源码其实看的是某一个子系统比如进程调度或者文件系统但从未把整个内核从头到尾追通过。而 Linux 0.11 是少数可以让人或者 AI在几周时间内真正形成全局心智模型的代码库。这个全局心智模型恰恰是通用智能最稀缺的东西。1.2 它比刷题测试更有区分度你让 GPT-4 去刷 LeetCode 的 Hard 题它表现确实不错因为那些题本质上是有限状态空间里的模式匹配——它见过的题目足够多可以把类似题目的解法碎片拼起来。但写出 Linux 0.11完全不是这个逻辑。它要求你理解硬件手册里的每一个寄存器要求你理解编译器怎么处理汇编、链接器怎么把函数地址变成物理地址要求你在没有现成答案的情况下做出一整套工程决策。换句话说刷题测试的区分度在于模型记住了多少解法而写出 Linux 0.11的区分度在于模型能不能在模糊、不确定、信息不完整的情况下靠推理和试错构造出一个复杂的、多组件交互的系统。这才是 AGI 真正的含义。一个能写出 Linux 0.11 的智能体至少证明它具备了以下四个能力长程规划几千步的工程流水线、深层系统理解从硬件到软件的全栈知识、韧性调试崩溃、失败、反复重试、以及目标驱动的学习遇到不懂的东西能自己去查、去补、去试。所以我非常怀疑读了多少本书这个问法本身。因为对人和对模型来说真正重要的都不是读了多少本书而是在遇到问题时能不能把书里的知识调用出来变成可运行的代码。Linux 0.11 恰好是一个最好的验收场。2. 多少本书背后的量化拆解2.1 不是一张书单而是一个知识地图如果你把多少本书理解成Amazon 购物车里堆多少本 Linux 内核相关的书那就太小看这个问题了。实际上想要真正写出一个可以运行的 Linux 0.11你需要的不是一个线性书单而是一个分层的知识地图。我把它分成四层。第一层是硬件手册代表是 Intel 80386 系列处理器的官方手册。这一层回答的是CPU 在复位后怎么执行、分页和分段怎么配置、中断控制器怎么编程、外设怎么访问这类最底层的问题。没有这层知识你写出来的 Bootloader 连屏幕都点不亮更谈不上启动内核。第二层是系统编程与操作系统原理代表是《操作系统概念》恐龙书、《现代操作系统》Tanenbaum、《Linux 内核完全注释》这类的书。这一层回答的是进程、内存、文件系统、设备驱动、系统调用这些抽象应该怎么组织。比如你要做进程调度你得知道时间片轮转、优先级调度、写时复制这些概念然后才能决定在 0.11 那种简陋的硬件条件下该选哪套方案。第三层是 Unix/Linux 的历史实现与具体代码结构代表是早期 Unix 的源码分析资料、Minix 相关的文档以及《Linux 内核注释》这一类逐行讲代码的书。这一层回答的是0.11 的每个文件、每个函数、每段汇编在干什么。因为 Linux 0.11 的很多设计其实继承自 Unix 和 Minix你不了解这些历史源流就无法理解为什么代码要那么写。第四层是工具链与环境配套不只是书而是你实际要用到的东西GCC 编译器、GNU as 汇编器、ld 链接器、Makefile、QEMU/Booches 模拟器、还有最基本的操作系统命令行操作文件权限、管道、进程管理。这一层的重要性特别容易被低估——你代码写得再好编译不过、链接不上、加载地址算错一样白搭。把这四层知识加起来一个合格的人类工程师要从完全空白开始走到能写出一版可运行的 Linux 0.11核心书单大概在 8 到 15 本之间加上一堆硬件手册和网络文档。但如果只是读过这些书而不动手你读五十本都写不出来。所以学习多少本书这个数字本身没有意义有意义的是你能不能把每本书里的知识变成在正确的时间做正确的决策的能力。2.2 逐层拆解每一层要解决什么问题我们以实际启动 Linux 0.11 的过程来走一遍你会发现每一层知识都会在某个环节冒出来。第一阶段是 Bootloader。CPU 加电后从物理地址 0xFFFF0 开始执行这是 ROM 中的一个跳转指令BIOS 接管后加载启动扇区。这个启动扇区的代码需要从软盘0.11 时代基本上都是软盘读取后续的内核代码到内存里。你在这里需要懂 BIOS 中断调用比如 int 0x13 读取磁盘、实模式下的 20 位地址计算、以及怎么用汇编写一段不超过 512 字节的引导程序。这一阶段对应第一层硬件手册和第二层系统编程里的引导知识代码量很小但处处是坑。第二阶段是从实模式切换到保护模式。你要设置全局描述符表GDT、把 CR0 寄存器的保护模式位打开、然后跳转到 32 位代码段。这一步是无数人第一次写内核时崩溃的重灾区——GDT 里的段描述符每个字节都填得不对页表没初始化好一开分页就 triple fault。这里的每一处细节都需要同时查阅 CPU 手册、汇编手册和具体的示例代码。第三阶段是内存管理。Linux 0.11 把物理内存划分成主内存区、缓冲区和虚拟盘区然后通过页表做分页映射。你要写内存初始化、内存分配算法0.11 用的是首次适应算法、页错误处理。这里需要操作系统原理的知识也需要你对 80386 的页目录、页表结构有准确的记忆。第四阶段是进程管理。0.11 的进程控制块是 task_struct每个进程有自己的内核态栈和用户态栈调度器在每个时钟中断后检查当前进程的时间片做任务切换。写 fork 的时候你要处理父进程和子进程的返回路径要处理写时复制的雏形要处理在中断上下文中切换任务。这一块是所有操作系统课程的精华也是 0.11 里最体现设计美感的部分。第五阶段是文件系统。Linux 0.11 使用的文件系统基本上是从 Minix 文件系统继承来的它的 inode、目录项、超级块结构以及 buffer cache 机制你都要从零实现。这里要面对的是磁盘块 vs 内存缓冲区的动态映射、缓存替换策略、以及文件读写路径上同步问题。第六阶段是系统调用和 shell 交互。你写好了内核、进程和文件系统还得有用户态的东西能掉进去。Linux 0.11 的 shell 是个简单的命令行解释器通过 int 0x80 陷入内核执行系统调用。这里要处理用户态和内核态栈切换、参数传递方式、信号处理、以及终端驱动。你看这六个阶段每一阶段背后都是几十上百页书的知识密度。我说的 8 到 15 本书其实是每一阶段至少要有两三本扎实的参考书 一个能随时翻查的硬件手册的最低配置。超过这个数字的那叫图书馆。2.3 给数量一个更务实的回答如果非要给多少本书一个数字我会把书分成两类一类是需要从头到尾精读的大概 4 到 6 本比如《Linux 内核完全注释》、Tanenbaum 的《操作系统设计与实现》、80386 手册里最关键的两三章另一类是当成参考文献按图索骥的大概 10 到 20 本包括各种 Linux 内核分析、Unix 源码分析、汇编语言教程、编译链接工具书。但真正的学习过程绝不是读完 20 本书然后开始写。它是读两章 - 写一段代码 - 编译 - 崩溃 - 再回去查书 - 改代码这样的死亡循环。如果你用这个标准去衡量一个大模型或者一个 Agent你会发现它最难模仿的恰恰是崩溃之后回去查书这个动作。现在的 LLM 可以直接背出 《Linux 内核完全注释》 里的很多段落你可以让它逐行解释代码它能讲得头头是道。但你让它真的在 QEMU 里把一个自己写出来的 0.11 跑起来它大概率会在第二阶段的 GDT 或者第四阶段的 fork 里彻底失去方向。因为它没有自己动手实现 - 遇到矛盾 - 回头修正知识理解这个过程它的知识是离散的、片段式的缺乏一个通过实践拧紧的整体结构。3. 光读书不够对 AGI 的真正考察点在看不见书的地方3.1 阅读-消化-复现的闭环书和手册是所有人都能读的包括现在的 LLM。如果把考试题目出成请默写 Linux 0.11 中 schedule() 函数的核心逻辑我相信现在的模型已经能拿到相当高的分数。但写出 Linux 0.11考察的不是默写能力而是把阅读、消化、复现三个环节串成一个闭环的能力。阅读环节考验的是信息获取模型能不能在大型代码库、硬件手册和历史文档之间找到正确的资料能不能理解 1991 年的技术语境——那时候没有 PCI、没有 USB、没有 ATA 硬盘的标准接口软盘和 IDE 控制器当时都是什么状态。消化环节考验的是抽象能力它接收到这些信息之后能不能提炼出在 80386 平台上启动一个操作系统最少需要哪几个组件。复现环节考验的是执行能力它能不能把消化后的知识转化为一份可以编译、可以被模拟器加载和运行的工程。这三个环节任何一个断裂最后的输出就是一坨有模有样但无法启动的代码。我在实际尝试中反复见过这个问题——很多代码片段单看是对的拼在一起就是不能跑。3.2 面对模糊问题的推理能力书里不会告诉你你的 GDT 应该放在内存的哪个地址、你的内核栈应该分配多大、你的缓冲区是 1MB 还是 2MB。这些在真实项目里都是自己拍脑袋决策的。而模糊决策恰恰是评定 AGI 的试金石它不检查你记住了什么它检查你在信息不足时怎么推理。举个例子Linux 0.11 的进程 0 是手工初始化的被注释为设置进程 0 的 task_struct 和内核栈的一段汇编代码。为什么需要一个进程 0因为第一个进程不能通过 fork 创建它是整个进程树的根。你在书里找不到必须这样写的理由你必须自己从代码的执行流程里推理出来第一个进程必须直接静态定义否则你没法 fork 出第二个进程。这种从系统的必然性出发推导设计决策的能力是单纯读书读不出来的。一个能写出 Linux 0.11 的 AGI至少要具备在每一个类似决策点上独立推理的能力而不是背答案。3.3 实用工程能力调试、试错、优化书里最不会教你的是怎么调试一个没有串口输出、没有 printf 可用、一运行就重启的内核。Linux 0.11 时代没有现代的调试工具你唯一的调试手段就是往屏幕写字符、往串口输出、或者用 Boch/QEMU 的调试器断点。这种环境下的工程韧性才是 AGI 评测里最宝贵的东西。我带过不少人做类似的 Lab最常见的现象是前两小时代码写得很兴奋第三小时开始编译报错第五小时开始 QEMU 黑屏第八小时耐心耗尽开始怀疑人生。能坚持下来的人一般都练就了一个核心技能叫做单步追踪崩溃路径。也就是每次内核崩溃不是去怀疑整段代码而是首先定位现在 CPU 执行到哪了然后逆推它为什么走到了这一步。这个技能听起来简单但它需要你对硬件启动过程、编译链接过程中的地址重定位、以及内核内存布局有非常精确的全局理解。如果一个 AGI 能在这种环境下像人一样做二分定位 假设检验 代码修正的循环并且能够在几十次甚至上百次失败中不掉线、不放弃、不瞎改那我觉得这已经是一个极强的智能信号了。4. 面向 AGI 的评测设计如果真想拿它当基准4.1 评测环境与成功的定义说完了理论我们来点实际的。假设我真的要搭一个评测环境把写出 Linux 0.11当作 AGI 基准我的设计思路大概是这样的。基础环境是一台 Linux 主机 QEMU 系统模拟器 一套预装的工具链GCC、GNU as、ld、make、vim。给 Agent 的输入是任务描述 80386 处理器的关键文档PDF 或者网页 一个空的源码目录。不给任何答案、不给任何模板代码。评测过程由 Agent 自主完成它可以任意执行命令、读写文件、运行 QEMU、查看输出。评测的最终目标是编译出一个 Linux 0.11 内核镜像并在 QEMU 中成功启动进入 shell 提示符用户能敲入常见的命令比如 ls、echo、cat并且可以执行一个预先放入磁盘镜像的测试程序。这个成功的定义本身已经可以分层层级 L1能编译出合法的 32 位内核镜像但 QEMU 启动不到保护模式。层级 L2能进入到保护模式初始化中断和分页。层级 L3能启动到用户态出现一个简单的控制台提示符。层级 L4能执行 shell 命令并且完成 fork/exec/wait 流程。层级 L5能运行预设的测试程序与文件系统正确交互验证多进程调度。不同的层级对应不同的AGI 能力得分。一个模型哪怕只能稳定达到 L3我已经认为它比绝大多数只会在对话框里聊天的 LLM 强出一个数量级。L5 基本上意味着这个 Agent 真的理解了操作系统的全部核心机制。4.2 评分维度与权重如果我只用最终是否通过这个二元指标其实不太公平因为工程任务里部分能力也有价值。所以我会再拆成几个评分维度第一个维度是知识检索与理解能力Agent 是否能在手册里找到正确的寄存器描述是否能够正确理解分页开启后代码段必须被映射到虚拟地址这一类概念。这个维度可以直接用一个分数比如 0 到 100评估。第二个维度是代码生成能力看它生成的代码有多少是能直接编译通过、有多少需要反复修补。这里可以统计编译错误率或者首次通过率。第三个维度是调试与问题解决能力这是最容易被忽略但是最重要的。我会记录从一次内核崩溃到找到 root cause 之间的平均尝试次数以及是否采用有逻辑的二分定位策略。第四个维度是长程任务规划能力任务持续几十个小时吗需不需要 Agent 自己在多个文件之间管理上下文它是否能在不忘记前一个模块设计的前提下写下一个模块这个维度可以自动评估方法是在任务中途随机插入请解释你当前所有源码文件之间的依赖关系的问题看 Agent 的回答与实际代码是否一致。权重上我倾向于代码生成能力只占 30%调试能力占 30%知识理解占 20%长程规划占 20%。因为一次写对在现代 LLM 里并不稀缺只要代码模式在训练集里出现过复制粘贴 微调就能做到。真正稀有的是在几十次失败之后依然能保持全局一致性的调试能力与规划能力。4.3 当前大模型的弱点在哪里拿现在最强的 LLM 去跑这个基准我大致能预判会在哪几个点上出问题。第一个致命弱点是上下文管理。1 万多行代码加上几十个源文件远超现有模型上下文窗口的有效处理范围。Agent 必须学会只加载关键代码片段到上下文把其他部分存成文件随时用 grep 检索。这种信息管理能力现在的 Agent 都还很稚嫩经常会在上下文中带入大量无关内容然后开始胡言乱语。第二个弱点是缺乏真实的硬件直觉。大模型能背出 Intel 手册里的描述符格式但它无法体会代码段描述符里面那个 Base Address 字段和实际 GDT 加载地址之间相差了几个字节会导致 triple fault。这种直觉只能来自长期和硬件打交道的经验。模型只有在评测环境里反复崩溃、反复看 PC 指针跑到 0x0000FFFF 之后才能慢慢建立。第三个弱点是工程决策的稳定性。大模型在写代码时经常会出现前面采用方案 A写到后面突然切换到方案 B的情况导致整个代码库内部不一致。人写代码会维护一个心理模型但模型很容易在生成长序列时丢失早期决策。这个问题在写 Linux 0.11 这类超长工程时会被无限放大。4.4 评测结果怎么解读更有意义我不建议把Agent 是否写出完整的 Linux 0.11当作一个非黑即白的结论因为我始终觉得这种测试的意义不在过与不过而在卡在哪个环节、以什么模式卡住。比如如果 Agent 卡在 Bootloader 阶段说明它连最基本的实模式编程和 BIOS 调用都不够熟如果它能跳到保护模式但总是 page fault说明它对内存管理的理解有系统性的缺口如果它能启动内核但 shell 里敲命令全部返回command not found说明它前面做得不错但在文件系统路径解析和系统调用接口上有问题。这些卡点模式可以告诉我们目前的 AI 在人脑哪种认知通道上最弱。我觉得这才是 AGI 评测比起刷分榜更有价值的地方。它测的不是能力总和而是能力的剖面图。5. 常见误区与个人判断5.1 能写出来不等于读过书我得先拆掉一个认知误区会写代码的人往往读书不多但他翻手册的频率极高而读了很多书的人很多时候恰恰写不出来。写 Linux 0.11 这类系统软件真正起作用的不是你的藏书量而是你的检索能力 快速实验能力 对待错误的韧性。对我个人而言写这种项目时 40% 的时间在写代码60% 的时间在查手册和调试。AGI 如果在 L4 级别上成功它的日志大概率也是这个比例。所以以后如果有人拿学习多少本书可以写出 Linux 0.11来调侃 AGI我会直接回答你先让他把书变成错误日志里的修复记录再来谈完成。读书是输入写内核是输出中间的鸿沟由无数个崩溃和修复填满。5.2 大模型现有的书感与手感ChatGPT 类的模型已经有非常好的书感了——你对它说帮我写一个 fork 的实现它能给你一段看起来非常清晰、结构完整的代码。但这就好比一个考了满分笔试题的实习生第一次进实验室手忙脚乱、焊板子焊炸了电容一样。手感这个东西目前全靠 Agent 里的执行器、终端环境、编译器反馈机制去补而这条路才刚刚开始。这几年的确有类似 SWE-bench 的评测集让模型去真实仓库里修 bug、写特性也有很多产品在做AI 程序员。但那些任务和从零写一个操作系统的差距仍然非常大。修 bug 的时候上下文可以压缩到一个文件甚至一个函数写内核的时候必须同时在 20 个文件之间保持一致性。这也是为什么我觉得拿 Linux 0.11 当 AGI 压力测试比 SWE-bench 有远见得多。5.3 如果构建真正能写 Linux 0.11 的 AGI基础设施该是什么样顺着前面说的架构思路往下想一个能够真正从零写出 Linux 0.11 的智能体绝对不是一个更大参数的模型就够了。它至少需要一个可靠的代码操作接口能创建/修改/删除文件能运行 make能捕获编译告警和错误一个可靠的模拟器或真实硬件接口QEMU 是首选因为它有调试接口和历史兼容性一个自省机制让它能随时导出自己对系统全局状态的理解方便评测者判断它是否真实理解了整个系统以及一个能管理超长任务记忆的系统外部向量数据库也好专门的 agent 状态管理也好总之不能靠单个会话窗口硬撑。这些东西组合起来已经是一个相当完整的AI 软件工程师 嵌入式开发环境了。把它做出来的意义不亚于 AGI 本身。6. 实操者向如果你想复刻这个项目应该怎么开始6.1 环境准备与工作流程如果你看完前面的分析也想自己试试能否写出 Linux 0.11我给一个具体的落地路线。我强烈建议不要直接去 GitHub 上 clone 一个现成镜像那样你就完全失去了这个项目的意义。正确做法是准备一台 Linux 虚拟机装好 gcc注意要支持 16 位和 32 位编译、nasm或者 GNU as、ld、make、qemu-system-i386。然后按下面的顺序推进。首先是启动扇区用汇编写一个 512 字节的 boot sector在 QEMU 里能打印一行字符。这一关过了你才能理解实模式、BIOS 中断和地址计算。其次是保护模式写一个最简 GDT切换 CR0跳进 32 位汇编函数在屏幕上画一个色块。这一关过了你才有了内核的雏形。然后是内存探测与初始化读内存大小初始化页表开启分页。接下来是中断与时钟安装 IDT写一个 IRQ0 的中断处理函数每一次时钟滴答都在屏幕上打印一个计数。然后是任务切换用软件中断或者时钟中断触发切换在两个简单的任务之间跳来跳去。到这边已经是一个裸机多任务系统了。最后才是文件系统做一个最简的基于内存的文件系统有 inode 表、目录、能创建和读取文件。如果你把这种迭代式流程走完回过头来看 Linux 0.11 的源码你会有一种完全不同的感觉——每一段代码都是解决你曾经踩过的坑。这个体验比任何读书都值钱。6.2 实操过程中的经典翻车点我以带实验室的经验给你列几个最容易翻车的点提前排雷。第一编译和链接的内存模型没对齐。如果你的 boot sector 里的 org 指令写的是 0x7c00但后面保护模式代码的链接地址是 0x100000你切换模式后的第一条跳转指令就会飞。这个问题是新手最常见的内核启动失败原因之一。第二GDT 表的位置没放在内存里。很多人把 GDT 定义在 C 语言数据段结果在实模式下访问它时段寄存器的值不对lgdt 加载了一个无效的表地址直接 CPU 三重故障重启。第三中断处理函数没保存寄存器现场。你写了一个看起来很美的中断服务程序但因为没压栈或者没恢复寄存器结果中断一返回就乱套。Linux 0.11 里大量的汇编代码都在做这种脏活新手最不愿意写恰恰最需要写。第四过早开启分页但没有建立一致映射。你在保护模式里开启分页后如果当前指令的地址不在已映射的页里CPU 立刻 page fault而你的 fault handler 还没写又是三重故障。这些问题在书上都能找到答案但只有你亲手翻车一次你才会真正理解为什么 Linux 0.11 的代码会那样安排。这也是我始终觉得分布式地实操一次比读十遍源码分析有用的原因。6.3 怎么用这个项目来反向训练你的智能体如果你是做 Agent 或者大模型应用开发的我给你一个建议不要只把 Linux 0.11 当成一个遥远的 AGI 测试题它可以当一个极好的 Agent 能力训练场。你完全可以把自己正在开发的 Agent 放进一个 Docker 容器里给它一个终端、一个 QEMU 环境和一个最小任务比如在 QEMU 里跑通一个打印字符的 boot sector然后观察它的行为。你会发现它在处理这种需要综合硬件知识 调试反馈的任务时会暴露出很多在纯文本任务里看不到的问题。我试过让一个多模态 Agent 去读 boot 日志的截图让它根据屏幕上的寄存器值去推断崩溃点效果比让它读纯文本日志好了不少但仍然经常出现过度自信地给出错误修复的问题。这说明它缺少一个关键的反思回路在修改代码之前先强制它基于现有证据给出最可能的三种崩溃原因并且给每种原因设计一个验证步骤再动手改。这个先验证后修改的回路是调试系统软件的核心方法论也是当前 Agent 最需要补的课。如果你希望你的 Agent 以后真的能参与复杂的系统编程项目用 Linux 0.11 这个场景来训练、评测、暴露它的短板是一件非常划算的事情。因为它的复杂度刚好足够高高到可以让模型暴露弱点又足够低低到在没有超级算力的情况下也能在本地跑完。7. 常见问题与我的判断7.1 学习多少本书这个提问方式的陷阱再回到最初的问题。如果把它当成一道评测题你会发现学习多少本书本身就是一个带有误导性的词语——它暗示知识是线性累积的。但写 Linux 0.11 更像是在多维空间中攀登一座山峰你需要的不仅有深度操作系统原理、广度硬件、汇编、编译、链接、文件系统还有高度对整个项目的全局长程规划和耐力在反复失败中保持稳定输出。如果我是面试官我不会问你读过多少本 Linux 内核的书我会给候选人一台机器让他在 8 小时内把一个最小引导程序跑起来然后看他遇到问题时的表现。这个问题的答案才是真正的判断标准。对 AGI 也一样与其争论AGI 到底是不是一个 5 万亿参数模型不如直接给它设一个 Linux 0.11 的关卡看它是真能搞定还是只会纸上谈兵。7.2 一个可能的AGI 写 Linux 0.11黄金时代顺着技术发展往下看我觉得未来 5 到 10 年内Agent 写出 Linux 0.11这个问题可能会从笑话变成基准测试再到默认能力三个阶段。目前我们处在第一个阶段到第二个阶段之间大家还普遍觉得这不可能但已经有团队在做类似的 Agent 评测环境了。一旦真的有人让 Agent 把一个完整可启动的 Linux 0.11 跑起来我相信那会是一个里程碑事件不亚于 AlphaGo 战胜李世石。因为它证明机器不只是能处理规则明确的棋类游戏还能处理规则模糊、组件交互复杂、需要长期记忆与反复实验的真实工程问题。而那时候关于 AGI 之争就不再有太多悬念了——一个能写出操作系统内核的机器你要说它不是 AGI得先解释清楚 AGI 到底还缺什么。7.3 我在实际探索中的一点体会提到我自己我其实已经很多年没动手写过这种底层的操作系统代码了更多是做上层应用架构和高性能系统。但每次回头接触这类 boot loader、GDT、中断处理的话题都会有很强的回到初心的感觉。那种把一个字节、一个标志位搞定之后亲眼看着屏幕上跳出自己写的字符的体验和信息爆炸时代里调一个 API 返回 JSON完全不在一个量级。它让你理解真正的智能并不是知道很多东西而是能在复杂未知环境里反复实验然后像雕刻家一样一点一点把一个混沌的黑盒子凿成一个可预测的、你可以掌控的系统。最后再分享一个小技巧如果你也开始走这条路千万别一开始就去读完整的内核源码那样只会被细节淹没。先给自己定一个最小可运行目标——比如在屏幕上打印一个字符然后一步步扩大。每一个小成果都会给你充电让你有信心继续啃那些枯燥得可怕的手册。这既是写给想学操作系统的人的建议也是我对将来任何一个尝试攻克 Linux 0.11 的 AGI 的期待保持韧性从小处着手永不放弃。