摘要: 当我们在构建 AI Agent 时,总觉得那种“分层查找工具”的感觉似曾相识。没错,你的直觉是对的。这不就是写 C 语言时的 ELF 符号表吗?本文带你从底层视角,看穿 AI 架构的本质。
引子:一种似曾相识的“既视感”
最近在研究 AI Agent(智能体)开发,尤其是给 AI 挂载各种 Skills(技能/工具)的时候,我产生了一种强烈的“既视感”。
你看,现在的 AI 工作流是这样的:
- AI 不直接回答,而是先看一眼手边的“工具说明书”。
作为一个写过底层代码的程序员,我不禁拍大腿:这不就是硬件加载 C 语言程序时的“ELF 格式”和“符号表查找”吗?!
太阳底下无新鲜事。今天我们就来聊聊,为什么最前沿的 AI 架构,其实是在复刻 50 年前的计算机底层智慧。
第一层:传统的智慧 —— ELF 与“符号表”
不管你是写 C 还是 Rust,当你的代码编译成可执行文件(比如 Linux 下的 ELF 文件)时,并不是把所有逻辑混成一团乱麻。
系统是如何找到 printf 这个函数的?它依靠的是“间接寻址”。
想象你去图书馆找书:
- 代码段(.text): 这是书架上具体的书(真正的逻辑)。
- 符号表(.symtab): 这是图书馆门口的检索电脑。
当程序运行通过总线去找代码时,它不会把整个内存翻个底朝天。它会先看符号表(Symbol Table)。
- 表里写着: “函数名叫
read_sensor,参数需要一个 int,它在内存地址 0x0800。” - 系统操作: 查表 -> 拿到地址
0x0800 -> 跳转执行。
重点是: 调用者不需要知道 read_sensor 里面是怎么由晶体管实现的,它只需要看懂这张“表”就够了。
第二层:AI 的进化 —— Skills 与“工具清单”
现在的 AI Agent,简直就是在这个机制上披了一层“自然语言”的皮。
当我们在 DeepSeek 或 GPT 中定义一个 Skill(比如“查询股价”)时,我们在做什么?我们在写一个 JSON Schema。
这个 JSON Schema,就是 AI 世界的“符号表”。
看看这个对比:
- 传统的符号表: 给编译器看。告诉它函数名和内存偏移量。
- AI 的工具清单: 给 LLM(大模型)看。告诉它函数名和“功能描述”(Description)。
AI 的运行逻辑是完全一样的:
- 查表: LLM 并不直接运行代码。它看了一眼 Prompt 里的工具清单(符号表),心里想:“用户问的是股价,这表里有个
get_stock_price 的描述很符合。” - 寻址: LLM 输出“我要调用
get_stock_price”。 - 执行: 你的 Python/Rust 后端程序(链接器)收到请求,去后台映射表中找到真正的代码逻辑,执行并返回。
硬核对比:一张表看懂前世今生
让我们把这层窗户纸彻底捅破:
| | |
|---|
| 核心目录 | 符号表 (Symbol Table) | 工具清单 (JSON Schema) |
| 目录里写了啥 | | |
| 查找机制 | 链接器 (Linker) | 模型推理 (Router) |
| 执行实体 | | |
| 瓶颈所在 | | 上下文窗口 (Context Window) |
| 设计哲学 | | |
灵魂拷问:为什么都要这么搞?
为什么 2024 年的 AI 架构,要走 1970 年代计算机架构的老路?把东西分层、搞个“中间层说明书”,不麻烦吗?
1. 为了省“带宽”
- 硬件: CPU 的总线宽度有限,不能给每个晶体管编个号。
- AI: 模型的 Context Window(上下文窗口)是昂贵的。你不能把几百万行代码全塞给 AI 读。你只需要给它看“目录”(几 K 的 Token)。这就相当于用最小的带宽,索引到了无限的能力。
2. 为了“解耦”
- AI: 只要工具描述(Prompt)不变,你后台是用 Python 写爬虫,还是用 Rust 写高性能计算,AI 根本不在乎。这让工程化变得极其稳定。
3. 为了“确定性”
- 这是最关键的。LLM 是概率模型,它天生爱“胡说八道”(幻觉)。
- 而代码(Hardware/Software)是确定性的逻辑。
- 这种架构是把 AI 的“灵性”和代码的“刚性”结合了起来。 AI 负责理解意图(查表),代码负责精准执行(干活)。
结语
所以,当你感觉 AI Skills 的设计像极了代码分模块查找时,不要怀疑,你的直觉非常敏锐。
计算机科学有一句名言: “任何问题都可以通过增加一个中间层来解决。”
- 在 AI 里,这个中间层叫 Function Calling Schema。
这就是技术的螺旋上升。看似是新的魔法,拆开来看,全是扎实的基本功。