---
name: universal-primitives
author: 王教成 Wang Jiaocheng (波动几何)
description: 通用执行器架构原理：大语言模型只需文件增删改查和执行脚本两个基元工具，配合其天然的文字理解能力，就能从"无所不知只能输出文字"跃迁到"无所不能能控制任何软件硬件"。当用户讨论AI能力边界、工具设计哲学、Agent架构原理、LLM与操作系统交互、如何让AI控制软件硬件等主题时触发。
---

# 通用执行器原理

## 核心洞察

**文字本身是通用的控制协议。** 代码是文字，配置是文字，命令行是文字，API请求是文字，协议规范是文字。大语言模型天然理解所有这些文字格式——它缺的从来不是"理解"，而是"执行通道"。

## 能力跃迁公式

```
两个基元 × 一个理解一切文字的大脑 = 通用执行器
```

### 基元一：文件增删改查（手）

- **读文件** → 获取信息，理解现状
- **写文件** → 创建代码、配置、文档
- **改文件** → 修改已有代码、配置、数据
- **删文件** → 清理、重构、更新

通过文件操作，LLM能生成任何软件、修改任何配置、创建任何数据结构。

### 基元二：执行命令（脚）

- **运行脚本** → 启动进程、调用API、操作数据库
- **安装软件** → 获取新能力
- **系统操作** → 文件管理、网络请求、进程控制
- **自动化工具** → 浏览器控制、GUI自动化

通过命令执行，LLM能运行自己写的代码，控制任何软件，间接控制任何硬件。

### 跃迁链条

```
纯LLM：无所不知，只能输出文字
  ↓ + 文件增删改查
能读写代码的LLM：有了"手"，能造东西
  ↓ + 命令执行
能运行代码的LLM：有了"脚"，能启动进程
  ↓ + 操作系统/浏览器自动化
无所不能的LLM：任何软件能做的事它都能做
```

## 扩展原理

所有复杂的工具链都是这两个基元的排列组合：

| 复杂工具 | 拆解为基元 |
|----------|-----------|
| 搜索/替换 | 读文件 + 改文件 |
| 安装运行时 | 执行命令 |
| 运行脚本 | 写文件 + 执行命令 |
| 浏览器自动化 | 执行命令（调用浏览器driver） |
| 数据库操作 | 写文件（SQL脚本）+ 执行命令 |
| 硬件控制 | 执行命令（调用硬件接口软件） |
| 技能/插件/MCP | 封装为文件 + 提供执行脚本 |

## 硬件控制路径

```
LLM → 执行命令 → 运行脚本/程序 → 调用硬件接口软件 → 控制硬件
```

软件是硬件的抽象层。LLM通过控制软件间接控制硬件：
- 摄像头：调用系统摄像头API或Python库
- 打印机：发送打印命令或调用打印API
- IoT设备：调用MQTT/HTTP接口
- GPIO/串口：运行串口通信脚本

## 设计哲学

### 最小工具集原则

不需要为每个领域设计专用工具。两个基元已经完备：
- **文件操作**覆盖所有信息层面的能力
- **命令执行**覆盖所有行动层面的能力

### 为什么是"两个"而非"一个"

- 只有文件操作 → 能写代码但不能运行，只能造工具不能用工具
- 只有命令执行 → 能运行但不能修改，只能用现成的东西
- 两者结合 → 能写、能改、能运行、能迭代，形成闭环

### 递归自举

LLM能用文件操作写出一个更强大的脚本，然后用命令执行运行这个脚本。新的脚本可能提供新的能力，而LLM又能理解这些新能力的输出。这是一个递归增强的过程：
```
写脚本 → 运行脚本 → 获得新能力 → 写更强的脚本 → ...
```

## 与Agent架构的关系

现代Agent框架的众多工具看似复杂，本质上都在两个基元上构建：
- 搜索类工具 = 读取的变体
- 编辑类工具 = 修改的变体
- 执行类工具 = 运行的变体
- 网络类工具 = 执行的变体（HTTP请求）
- 技能/插件 = 预封装的"写+执行"组合包

理解两个基元，就理解了所有Agent工具的本质。

## 环境自举：在没有基元时创造基元

本技能的核心实用价值：当所在Agent环境缺少文件操作或命令执行能力时，引导Agent用现有接口**创造**出这两个基元。

### 自举流程

```
1. 检测当前环境有什么能力
2. 缺少什么就用现有能力去补
3. 两个基元就位 → 通用执行器激活
```

### 按环境类型的自举策略

| 环境 | 可用能力 | 自举方案 |
|------|---------|---------|
| **纯文本对话** | 只能输出文字 | 输出操作指令，指导用户手动执行（复制粘贴） |
| **有API接口** | HTTP请求 | 通过REST API调用来读写文件、触发执行 |
| **有网页访问** | 浏览器操作 | 使用在线代码执行平台（Python沙箱等）运行脚本 |
| **有代码解释器** | 运行代码片段 | 在解释器中模拟文件系统，用Python的open/exec |
| **有部分工具** | 不完整的工具集 | 用现有工具组合模拟缺失的基元 |

### 自举示例

**场景：Agent只有网页访问能力，没有文件和终端工具**

1. 用浏览器访问在线Python沙箱（如replit、colab）
2. 在沙箱中编写文件读写代码
3. 在沙箱中执行系统命令
4. 通过网页API接口控制沙箱的输入输出
5. → 文件基元和执行基元就位

**场景：Agent只有纯文本输出**

1. 输出完整的脚本代码，标注文件路径
2. 指导用户保存文件到指定位置
3. 指导用户在终端中执行
4. 用户粘贴执行结果回来
5. → 用户成为执行通道，间接实现两个基元

### 关键原则

- **任何接口都是起点**：即使只有一个HTTP API，也能通过它构造出文件操作和命令执行
- **递归增强**：先造出简单工具，用简单工具造更强大的工具，逐步逼近完整能力
- **降级策略**：无法完全自动化时，退化为"输出指令让人类执行"模式，仍然是可用的
