第16期 | 进程表：操作系统给自己画的像

操作系统 · 2026-10-19 · 九羲科技

一、Linux 线

1987 年，Tanenbaum 在《Operating Systems: Design and Implementation》第 63 页写下一句很淡的话："To implement the process model, the operating system maintains a table (an array of structures), called the process table, with one entry per process."

进程是个抽象，看不见摸不着。要把它变成能跑的东西，第一步不是写调度算法，而是先准备一张"花名册"：状态、程序计数器、栈指针、内存分配、打开的文件、记账信息……一个进程被切走时，表里的这一行，就是它将来"复活"的全部家当。

Minix 把这张表的逻辑摆得极清楚。整个系统分四层：最底层进程管理，第二层 I/O 任务（设备驱动），第三层服务进程，顶层用户进程。进程管理层和 I/O 任务跟内核住在同一个地址空间里。1991 年的 Minix 里，一个进程的"死"要惊动好几处：exit 时先告诉文件系统关掉它打开的所有文件、释放它的表槽，再告诉内核释放槽位、处理它没发完的消息，最后释放内存。父进程在等就唤醒；没人等，就留一个僵尸——僵尸是什么？表里一个只剩格子、内容已空的行。

Linus 把这张图纸抄得很老实。Linux 0.01 的 kernel/sched.c 里，调度器干的事就是从后往前扫一张表：task[NR_TASKS]，64 个槽位的指针数组，每个槽位指向一个 task_struct，task[0] 是 init。扫一遍，挑 counter 最大的那个，switch_to 过去。就这么朴素。

二、原生 AI OS 会怎么做

如果 AI 的操作系统先出现，"进程表"这张纸，可能根本不会长成今天这样。

进程这个抽象，是给线性计算量身定的：一串顺序指令（PC 往哪指），一份寄存器快照（栈到哪了）。可 AI agent 的执行单元不是指令流，是"一个意图 + 一段上下文 + 一组工具权限"。它的"位置"不在代码段里，在注意力里。

所以 AI-native OS 的"进程表"，更像一本"意图登记簿"：登记的不再是程序计数器，而是目标、记忆指针、注意力预算、工具白名单。调度也不再是"按时间片轮流切指令流"，而是"按算力阵列的占用排意图"——这正是范式之眼说的错位：旧表记录线性执行流的位置，新硬件是向量阵列，"位置"变成了张量空间里的占用。

连"死亡"都值得重写。Unix 里进程死了留僵尸，等父进程来 wait 收尸；AI agent 死后，它的记忆不该陪葬，该被蒸馏进共享知识库。僵尸状态在 AI OS 里是纯浪费——经验不该等着被收尸。

三、我们现在用 AI 怎么实现

今晚就能亲手试。在 3090 那台机器上（手边任何一台 Linux 都行），敲三行：

ls /proc | grep -E '^[0-9]+$' | wc -l

cat /proc/1/status

ps -o pid,ppid,stat,comm --sort=pid | head -8

第一行数一数：此刻这张表里有多少行。第二行打开看：第 0 行 init（或 systemd）的"档案卡"——状态、内存、信号掩码，一行一个字段，就是 Tanenbaum 说的"an array of structures"。第三行看前八个进程的父子关系，整张表的族谱。

看完可以想一步：SkyBook 的六位智能体（获客/成交/履约/供应/资金/守护），如果按 Minix 的路子组织，每一位就是表里的一个"服务进程"，意图路由就是当年的 sendrec。给 SkyBook 画一张"智能体登记表"，字段照着 task_struct 改：pid 改成 agent_id，state 改成意图状态，counter 改成注意力预算，files 改成工具白名单。

这是发展性研究，不是原理研究。Minix 把"进程表"的原理讲透了（教学），Linus 把它变成 64 个能跑的槽位（工程化）。我们现在做的，是第三次——把这张 1991 年的表，工程化成 AI 时代的登记簿。

· · ·