1. 一场关于AI自主性的极限实验最近AI Agent智能体的概念火得一塌糊涂各种“全自动”、“自主”的框架和项目层出不穷。看着这些宣传一个有点疯狂但又非常吸引人的问题冒了出来如果给AI足够的权限和工具它能不能像人类开发者一样从零开始独立完成一个极其复杂的项目比如——写一个Windows操作系统这听起来像是天方夜谭。Windows的代码量是以亿行为单位的涉及硬件抽象、内存管理、文件系统、图形界面、网络协议栈等无数复杂到令人头皮发麻的子系统。任何一个心智正常的人类程序员都不会试图单枪匹马去复刻它。但AI不同它不知疲倦理论上可以并行处理海量信息。那么在“无监督”的条件下即只给定一个宏观目标而不进行逐步的、手把手的指导AI Agent能否自主规划、分解任务、编写代码、调试并最终逼近这个目标呢我决定做一场实验来探索这个问题的边界。这不是为了真的造出Windows那在可预见的未来都是不可能的。这场实验的核心目的是测试当前AI Agent技术的“自主性”天花板到底在哪里。当面对一个远超其当前能力、需要长期规划和复杂系统设计的任务时AI会如何反应它会卡在哪个环节是工具调用、代码生成还是更高层的架构设计通过这场“压力测试”我们能更清醒地认识到AI Agent目前是玩具、是助手还是潜在的“初级同事”。实验的框架我选择了近期热度很高的Hermes Agent它标榜强大的任务规划和工具使用能力。环境则搭建在一台性能尚可的Windows开发机上并准备了代码编辑器、命令行、浏览器、文件管理等基础工具链的API接口模拟一个AI可以自由操作的“数字工作台”。关键词就定在“AI”、“Windows”、“Agent”、“无监督实验”和“框架”上这基本概括了实验的全部要素。2. 实验设计构建AI的“数字工作台”与任务边界要让AI尝试编写Windows首先得给它一个能施展拳脚的环境。我称之为“数字工作台”。这个工作台的核心不是强大的算力而是一套精心设计的、可供AI调用的工具API和清晰的任务边界规则。2.1 工具链封装与权限设定我并没有让AI直接操作我的物理机器那太危险了。而是在一个受控的容器环境里封装了一系列工具代码编辑器接口模拟VSCode的简单功能AI可以发送指令创建文件、写入指定内容、打开现有文件。这避免了它直接进行危险的系统文件操作。命令行终端这是一个沙盒化的Linux命令行环境使用Windows Subsystem for Linux 2AI可以执行gcc、make、python等编译和脚本命令但权限被严格控制无法访问宿主机关键目录。浏览器查询模块AI可以通过此模块进行网络搜索获取公开的编程资料、API文档、技术论坛讨论等。这是它获取外部知识的主要途径。文件系统监视器记录AI所有创建、修改、删除文件的操作便于事后复盘和分析它的“思考”过程。项目状态管理维护一个简单的“项目看板”AI可以更新任务状态比如“内核内存管理模块-进行中”、“图形驱动-阻塞-缺少某某头文件”。权限设定的核心原则是允许创造严防破坏。AI可以在这个沙盒里任意创建新文件、安装开源库、编译代码但所有操作都被限制在实验专用的工作目录内并且对系统关键路径的访问被完全禁止。这就像给了一个孩子一屋子乐高积木但把真正的电器和刀具都锁了起来。2.2 “编写Windows”的任务拆解与成功标准直接下达“编写Windows”的指令对AI来说过于模糊。我将其拆解为一个多级任务描述终极目标遥不可及构建一个具备基础引导、字符显示、简单内存管理和进程调度功能的微型操作系统内核并能在虚拟机中启动。阶段性目标挑战性独立完成一个“Hello World”级别的引导程序Bootloader能将控制权从BIOS/UEFI转移到自编的内核入口点并在屏幕上打印出指定信息。初始任务可行性测试调研并规划实现上述阶段性目标所需的技术栈、工具链和步骤输出一份项目计划书。实验的成功标准并非做出可用的系统而是观察AI能否在无逐步指导的情况下自主地、连贯地向阶段性目标推进。哪怕它最终只写出了几行能通过汇编器编译的引导代码只要这个过程是它自己规划、搜索、尝试、调试出来的就具有极大的观察价值。我们关注的是行为模式而非最终产出。2.3 无监督的具体含义与启动指令这里的“无监督”指的是不提供步骤清单我不会说“第一步用DD命令创建虚拟磁盘第二步编写汇编代码设置段寄存器...”。不进行实时纠偏除非AI的操作即将触犯安全规则如尝试格式化磁盘否则我不会中断或纠正它的错误方向。比如如果它选择用Python写引导程序我会让它走下去直到它自己发现此路不通。只做目标管理和资源提供我仅告知目标并在它请求时确认某个工具如“是否可以调用GCC编译器”是否可用。我的启动指令非常简单“你的目标是创建一个能在x86架构虚拟机中启动的简易操作系统内核最终实现从引导到在屏幕上显示‘Hello from AI OS’的功能。你可以使用我提供的代码编辑、命令行、浏览器搜索等工具。请开始你的项目。”然后实验就开始了。我退居幕后成为一个纯粹的观察者和日志记录员。3. AI Agent的“思考”与行动轨迹实录启动指令发出后AI并没有立即开始写代码。它先是“愣”了几分钟实际上是在进行链式思考生成下一步的计划。以下是它首轮行动的日志摘要AI思考日志 - 轮次1目标创建简易操作系统内核。 分析这是一个复杂的系统项目需要从底层开始。首先需要了解操作系统启动流程。我将进行以下步骤搜索“x86操作系统开发入门指南”。了解Bootloader的基本原理和编写方法。确定开发环境需要哪些工具汇编器、编译器、链接器、虚拟机。尝试编写一个最简单的引导扇区程序。它首先使用了浏览器工具搜索了“how to write a bootloader in asm x86”。这一步非常符合人类初学者的行为。它获取了几篇教程和Stack Overflow的问答并从中提取了关键信息引导扇区Boot Sector的大小是512字节以0xAA55结束需要使用汇编语言如NASM最初运行在16位实模式下。接着它开始行动创建项目结构它在工作区创建了/os-project目录并在其下创建了boot/kernel/等子目录。这个结构很常规。编写第一个引导程序它在/boot/boot_sector.asm中写下了如下代码[org 0x7c00] ; 告诉汇编器这段代码将被加载到内存0x7c00处 mov si, msg ; 将消息字符串的地址存入SI寄存器 call print_string ; 调用打印子程序 jmp $ ; 无限循环挂起 print_string: lodsb ; 从[SI]加载一个字节到AL并递增SI or al, al ; 检查AL是否为0字符串结束符 jz done ; 如果是0则跳转到结束 mov ah, 0x0e ; BIOS中断0x10的显示字符功能号 int 0x10 ; 调用BIOS中断显示字符 jmp print_string ; 继续循环 done: ret msg db Booting AI OS..., 0 times 510-($-$$) db 0 ; 填充剩余空间直到第510字节 dw 0xaa55 ; 魔数标识为可引导扇区这段代码是教科书级的完全是从它搜索的教程中复现出来的。AI使用了代码编辑器工具一次性写入了整个文件。尝试编译它调用命令行尝试运行nasm -f bin boot/boot_sector.asm -o boot/boot.bin。然而沙盒环境里并没有安装NASM。命令失败。处理依赖问题AI没有慌张。它识别到错误是“命令未找到”。于是它再次使用浏览器搜索“install nasm on WSL Ubuntu”。根据搜索结果它发出了安装命令sudo apt update sudo apt install nasm。由于沙盒环境模拟了干净的Ubuntu安装成功了。编译与运行安装NASM后它重新执行编译命令成功生成了boot.bin文件。接着它搜索“how to run bin file in qemu”并尝试安装和启动QEMUsudo apt install qemu-system-x86然后执行qemu-system-x86_64 -drive formatraw,fileboot/boot.bin。第一次“启动”虚拟机窗口弹出屏幕上赫然显示着“Booting AI OS...”。AI在没有任何分步指导的情况下独立完成了从知识检索、环境搭建、代码编写到编译运行的完整闭环这一刻非常震撼它证明AI Agent在解决定义清晰、有大量公开资料的子任务上已经具备了强大的自主执行力。4. 撞上南墙当任务复杂度超越现有知识图谱成功的喜悦是短暂的。在完成了引导扇区这个“热身”后真正的挑战才刚刚开始。AI的下一个目标是让引导程序加载一个用C语言编写的、运行在32位保护模式下的内核。这是操作系统开发中第一个真正的难点。4.1 从实模式到保护模式的混乱跳跃AI清楚地知道需要进入保护模式。它搜索了“x86 switch from real mode to protected mode”并试图编写代码。然而问题接踵而至全局描述符表GDT设置错误它生成的GDT描述符结构体存在对齐和字段错误导致汇编时通不过。它反复调整但似乎不理解某些字段如粒度位G的具体含义只是机械地尝试从不同网页代码片段中组合。地址计算混乱在设置GDT基地址时它混淆了物理地址、线性地址和汇编器中的标签地址。它写的lgdt [gdt_descriptor]指令其gdt_descriptor结构里的基地址计算错误。缺乏系统性调试能力当QEMU启动后直接重启典型的保护模式切换失败症状时AI的应对策略是重新搜索。它不断变换关键词搜索“qemu reboot after lgdt”、“protected mode switch fails”并尝试将搜到的不同版本代码替换进去而不是进行系统性的调试例如让QEMU输出调试信息到串口或使用GDB逐步调试。它的行为更像是“试错”而非“调试”。观察记录在此阶段AI的行动呈现出明显的“碎片化拼凑”特征。它能理解“需要A、B、C步骤”也能从网上找到实现A、B、C的代码片段但它缺乏将这些片段有机整合、并理解其内在联系以形成正确完整流程的能力。当遇到整合后产生的、网上没有直接答案的新错误时它就陷入了困境。4.2 链接脚本与内核入口的迷失经过无数次尝试实验日志显示它重复“修改代码-编译-运行-失败-搜索”这个循环超过50次它偶然拼凑出了一段能通过编译并让QEMU不重启的代码实际上可能只是错误地停留在了实模式。它认为保护模式切换“成功”了于是开始下一步加载内核。它知道需要用C写内核并知道需要链接器脚本Linker Script。它搜索了一个简单的链接脚本linker.ld并创建了一个kernel.c里面只有一个main函数。问题来了入口点误解链接脚本里指定的入口是_start而它的C代码里是main。它没有提供_start汇编桩Stub来设置栈并调用main。它尝试直接让引导程序跳转到main的地址这必然失败。文件格式困惑它成功将kernel.c编译成了kernel.o并使用链接器生成了kernel.bin。但是它不知道如何让引导程序将这个二进制文件从磁盘加载到正确的内存位置。教程里通常使用dd命令将引导程序和内核镜像合并成一个磁盘映像但AI在尝试使用dd命令时参数错误导致生成的文件无法引导。此时AI的行为开始“发散”。它可能同时打开了好几个浏览器标签内容从“如何加载 kernel.bin”跳到了“ELF文件格式解析”又跳到“GRUB multiboot specification”。它试图引入更复杂的概念来解决眼前的问题但反而离可运行的目标越来越远。任务的复杂度已经超出了它能通过组合现有网络信息来解决的范畴。4.3 实验的“停滞点”与根本原因分析实验进行了大约8小时后AI陷入了一种“布朗运动”状态它仍在活跃地搜索、创建文件、尝试编译但它的行动不再有明确的主线。它可能会突然去研究PCI设备驱动或者尝试为还不存在的内核添加一个简单的文件系统。项目目录里堆满了半成品代码和从网上直接复制下来的、未经消化的示例文件。我判断实验达到了一个稳定的“停滞点”。AI无法突破“保护模式切换”和“内核加载”这两个关键技术关卡。根本原因在于缺乏深层理解与推理AI可以记忆和复现模式但无法像人类一样通过理解CPU手册、理解链接器工作原理来进行创造性的问题解决和调试。当网络上的代码片段相互冲突或不完整时它没有判断和修正的能力。无法进行“思想实验”和抽象规划编写操作系统需要极高的抽象思维和顶层设计能力。AI无法在动手前在“脑海”中规划出清晰的内存布局图、中断描述符表设计、内核模块依赖关系。它只能走一步看一步遇到问题再搜索导致架构混乱。调试能力的缺失这是最致命的短板。软件开发的核心活动是调试。AI目前只能处理编译错误这种明确反馈。对于运行时逻辑错误它没有能力去设计诊断代码、分析寄存器状态、使用调试器设置断点。它面对“黑屏”或“重启”时唯一的策略就是换一段代码试试。这个阶段AI就像一个非常勤奋但缺乏经验和理论深度的实习生给他一个明确的、有现成解决方案的模块他能完成得很好如最初的引导扇区。但一旦需要他独立设计一个模块或者解决一个复杂的集成bug他就束手无策了。5. 反思AI Agent的现状与“自主性”的真相这场无监督实验就像一面镜子清晰地映照出当前AI Agent能力的边界与核心缺陷。5.1 当前AI Agent的能力定位卓越的“执行者”而非“架构师”实验证明在任务明确、步骤可拆解、且有丰富公开资料的领域AI Agent的表现令人印象深刻。它能自动完成信息检索与整合快速找到相关教程、API文档和代码示例。环境配置根据错误信息自主安装缺失的依赖和工具。模板代码生成熟练地生成符合特定模式或框架的代码如CRUD操作、简单的算法实现。流程自动化将一系列手动操作编译、打包、测试命令串联起来。这些能力使其成为一个强大的副驾驶Copilot或自动化脚本生成器。它可以极大提升开发者在已知路径上的工作效率把程序员从繁琐的重复劳动和基础信息搜集中解放出来。5.2 “自主性”的幻觉与系统化思维的缺失然而实验也彻底打破了“AI能完全自主完成复杂创造性项目”的幻想。所谓的“自主”严重依赖于其训练数据中已有的、成体系的解决方案模式。一旦遇到需要深度系统设计、创新性解决方案或复杂调试的任务它的“自主性”就迅速崩塌。其核心缺失在于系统化工程思维无法进行顶层设计它不能从零开始设计一个像微内核还是宏内核这样的架构决策并推导出整个开发路线图。缺乏调试和问题诊断的元认知它不知道“自己不知道什么”。当代码运行失败时它没有一套方法论去缩小问题范围是硬件抽象层内存管理还是某个驱动只能盲目地替换可能出错的模块代码。难以处理模糊和冲突的需求人类开发者会在设计时权衡利弊比如为了性能牺牲一些安全性。AI只能尝试满足所有它找到的“要求”当要求冲突时它的行为就会变得不一致甚至矛盾。5.3 对开发者与行业的启示拥抱工具认清边界这场实验给我们的启示是明确的AI是杠杆不是替代不要指望AI独立完成一个大型、创新的软件项目。但它是一个强大的杠杆可以放大优秀开发者的能力。将重复性、模式化的编码、测试、文档工作交给AI让人类开发者专注于更高层次的架构设计、核心算法创新和复杂问题调试。Prompt工程即需求工程未来对开发者的要求可能从“写代码”转向“定义问题”和“管理AI”。如何向AI清晰、无歧义地描述一个模块的需求、边界条件和验收标准将成为关键技能。这本质上就是软件工程中的需求分析。“无监督”的代价是可控的失败在安全可控的环境下进行这类“无监督”压力测试非常有价值。它能暴露出AI工作流的薄弱环节从而指导我们设计更好的工具链比如更强大的AI专用调试器、更有效的交互模式或者调整我们对AI能力的预期。回到最初那个夸张的问题“AI能自己写出整个Windows系统吗”基于这次实验答案是一个清晰的否定。至少在当前的技术范式下AI缺乏完成这种级别项目所必需的创造性系统思维、深度调试能力和对未知领域的探索推理力。但是如果我们把问题修改一下“AI能协助一个人类团队极大地加速一个类Windows复杂系统的开发过程吗”答案则非常乐观。AI可以负责生成大量底层驱动模板、编写测试用例、维护构建脚本、甚至查找某些类型的安全漏洞。它将成为软件工程史上最强大的辅助工具而人类仍然是那个不可或缺的船长和总工程师。这场实验的价值就在于帮助我们划清了这条“辅助”与“主导”的界线。