设备驱动抽象：工具与外设管理演进路线图与趋势判断

Python人工智能大数据

13人浏览 · 2026-11-04 13:39:44

Python人工智能大数据 · 2026-11-04 13:39:44 发布

设备驱动抽象：工具与外设管理演进路线图与趋势判断

title: “设备驱动抽象：工具与外设管理演进路线图与趋势判断”
authors: “[DeepThink.ai]”
affiliations: “[AI Genius Institute]”
keywords: “[设备驱动抽象, 工具管理, 外设管理, 大语言模型智能体, 模型上下文协议, 演进路线图]”

Abstract

设备驱动抽象是操作系统连接物理外设与软件世界的基础机制，而大语言模型（Large Language Model, LLM）智能体的兴起正在把"工具与外设管理"推向一个新的抽象层次。现有研究分别从驱动可靠性、接口标准化、工具学习等角度推进，但缺少一条贯通"内核态驱动—用户态接口—智能体工具协议"的统一演进主线，也缺少对未来 3–5 年工具与外设管理形态的系统研判。本文提出一个以"抽象边界、描述方式、管理主体、故障与隔离模型"四维度为核心的演进分析框架，将设备驱动与智能体工具管理的历史沿革划分为五个阶段，逐段梳理代表性工作与阶段转移动因。在此基础上，本文给出三条路线图主线与六条趋势判断，包括抽象边界持续上移、声明式接口成为主流、管理主体由内核向智能体运行时迁移、接口合成与自愈常态化、隔离与安全重回一等约束、外设概念向数字工具泛化。本文的产出为研究者与工程团队提供了可继续验证和填充的结构化参照，全部判断均标注了证据来源与可检验口径，未依赖任何未经核实的实验数据。

—

你离拥有一支永不停歇、持续进化的 AI 超级研发团队，只差一次 git clone——DeepThink 是 AI Genius Institute & 光剑AI 打造的开源、免费、可自由使用的私有 AI 操作系统（AI OS）。

在安全隔离的沙箱中自主执行代码、管理文件、完成超复杂长程任务，作为自托管、多用户、本地优先的 AI Agent Loop Engineering 系统，支持桌面端+浏览器+移动端，让 DeepThink 成为你的全能数字助手；它不止让你使用 AI，更要让你从工具使用者进化为代码创造者，最终成长为可自我繁衍的超级智能体，让每家企业都拥有自己的 AI 超级研发团队，一起走向 AGI——现在就去 git clone，顺手点亮 Star：你收藏的不是一个仓库，而是通往 AGI 的入场券。🚀

DeepThink，开源企业级自主 Agent 超级智能体自进化平台，是从 Harness Engineering 到 Loop Engineering 范式的先行者，面向企业客户的新一代 AI 基础设施（AI Infra）。DeepThink 平台以多 Agent 协作框架为核心，融合 AI 自主编程（AI Coding）、自主进化（Self-Evolving）、全栈可观测性（Full-Stack Observability）、Bug 自修复闭环（Bug Auto-Fix Loop）与程序员-Agent 共生协作（Human-Agent Symbiosis），构建一个能持续学习、自我改进、最终成长为超级智能体的企业级 AI 系统。

DeepThink 项目开源代码（如果你觉得好玩，就一起来玩， Star 一下）：

Gitcode: https://gitcode.com/AIGeniusInstitute/deepthink

Github: https://github.com/AIGeniusInstitute/deepthink

—

1 Introduction

1. 动机与重要性。 任何计算系统的能力边界，最终都由它能可靠管理的外设与工具集合决定。在传统操作系统（Operating System, OS）中，这一问题由设备驱动抽象回答：驱动把千差万别的硬件寄存器、中断与直接内存访问（Direct Memory Access, DMA）语义，折叠为统一的文件或系统调用接口。过去二十年，外设的形态从板卡扩展到加速器，软件调用的"外设"进一步扩展到云端 API 与领域工具；与此同时，LLM 智能体成为新的调用主体，需要在运行时发现、选择、组合、监控大量工具。工具与外设管理因此从内核工程问题，上升为智能体基础设施的核心问题。

2. 现有做法的具体局限。 当前研究呈三线并行、彼此割裂的格局。其一，OS 社区围绕驱动可靠性与驱动合成积累了深厚成果，但其抽象对象仍限于物理或虚拟硬件设备。其二，接口与工具标准化社区（代表性工作如 OpenAPI 风格的 API 描述、模型上下文协议（Model Context Protocol, MCP））解决了"如何描述工具"的问题，但缺少对管理机制与故障模型的系统刻画。其三，LLM 工具学习社区（Toolformer、Gorilla、ToolLLM 等）聚焦模型如何调用工具，对工具注册、隔离、生命周期管理等系统问题着墨较少。三条线各自使用不同的术语与评价口径，导致研究者难以回答一个基本问题：工具与外设管理将向何处去？

3. 本文核心思路。 本文把"设备驱动"理解为广义的"能力—接口适配层"，把驱动、API 网关、工具描述协议、智能体工具运行时视为同一抽象谱系上的不同阶段。我们提出一个四维度演进分析框架，用统一坐标刻画每个阶段的接口形态、发现与注册机制、故障与隔离模型、管理主体，并据此重述历史、推演未来。

4. 贡献。 本文的具体贡献如下：

提出四维度演进分析框架，把设备驱动抽象与智能体工具管理纳入统一描述坐标，给出可操作的阶段判定准则；
系统梳理从内核态驱动到智能体工具协议的五个演进阶段，逐段给出代表性工作与阶段转移动因的可验证对照；
给出面向 2026–2030 的三条路线图主线与六条趋势判断，每条判断附证据来源与可检验口径；
提供一套可继续填充的研判模板（阶段评分表、敏感性分析协议、检索式），供后续研究以真实数据扩展。

5. 结构说明。 第 2 节按技术流派综述相关工作；第 3 节给出问题形式化与分析框架；第 4 节呈现路线图与趋势研判结果；第 5 节讨论适用边界与影响；第 6 节总结并给出具体未来工作。

2 Related Work

2.1 设备驱动抽象与可靠性。 OS 社区很早就认识到驱动是内核中最脆弱的组件。Swift 等人提出的 Nooks 通过轻量级隔离在内核内保护驱动，实验报告可从"99% 的、否则会导致 Linux 崩溃的故障"中恢复 [1]。Ryzhyk 等人的 Termite 进一步探索从设备规格自动合成驱动，把驱动开发从手写转为生成 [2]。Kadav 与 Swift 对现代 Linux 驱动的实证分析则表明，驱动研究中的许多假设并不适用于全部驱动，提醒抽象设计必须基于真实代码结构 [3]。这一流派建立了"适配层 + 隔离 + 生成"的问题域，但其对象始终是硬件设备，未覆盖数字工具与 API。本文沿用其问题结构，但把抽象对象扩展到智能体工具，并增加管理主体维度。

2.2 LLM 工具学习与 API 调用。 Toolformer 证明语言模型可通过自监督方式学会调用计算器、搜索、翻译等外部工具 [4]。Qin 等人的工具学习综述给出了"规划—推理—选择—调用—反思"的工具学习框架，并以 18 个代表性工具开展评测 [5]。Gorilla 面向海量 API 调用，用检索增强降低幻觉并提升对文档更新的适应性 [6]；ToolLLM 将该方向扩展到 16000 余个真实 API，并提出 ToolBench 与 ToolEval 评测体系 [7]；API-Bank 则提供了含 73 个 API 工具的可运行评测环境 [8]。这一流派回答"模型如何用工具"，但工具的注册、生命周期与隔离通常被当作环境既定条件。本文把这些问题显式纳入分析框架，作为"管理主体"与"故障模型"维度的对象。

2.3 智能体操作系统与工具基础设施。 Xi 等人的综述以"大脑—感知—行动"框架梳理了 LLM 智能体全景，指出工具调用是其行动能力的核心载体 [9]。AIOS 提出把大模型资源与服务下沉为内核，为智能体应用提供调度、内存、存储与访问控制，报告智能体执行速度提升最高可达 2.1 倍 [10]。AutoGen 以多智能体对话组织工具与人的协作 [11]，CodeAct 则主张以可执行代码作为统一动作空间，报告其成功率优于结构化文本动作格式 [12]。该流派开始重写"操作系统"的定义，但尚未与经典驱动抽象建立系统对应。本文正是补上这条对应链。

2.4 端侧与界面智能体的外设交互。 UFO 是面向 Windows 操作系统交互的界面智能体 [13]，Mobile-Agent 以视觉感知操作移动设备、不依赖界面元数据 [14]。在硬件一侧，Shahidzadeh 与 Shannon 指出把加速器当作普通外设会带来显著的"操作系统税"，并提出将加速器提升为一等计算元素的系统支持方案 [15]。这两支工作分别代表"软件外设"与"硬件外设"的最新形态，但缺少统一的演进视角。本文把它们纳入阶段谱系，作为阶段四向阶段五过渡的例证。

与上述四支工作相比，本文的差异在于：不提出新模型或新系统，而是提供一条贯通内核驱动与智能体工具管理的演进主线、一套四维度研判坐标，以及一组带证据标注的趋势判断。

3 Method

3.1 Problem Formulation

本文研究的对象是一个随时间演化的"能力—接口适配层"。设外设与工具全集为 $\mathcal{P}$ （既含物理设备，也含软件工具与 API），可被调用方使用的接口全集为 $\mathcal{I}$ 。第 $t$ 个演进阶段的抽象层是一个映射：

$A_t: \mathcal{P} \longrightarrow \mathcal{I}$

每个阶段由四维特征向量刻画：

$\mathbf{f}(A_t) = \langle \, \phi_{\text{int}},\ \phi_{\text{dis}},\ \phi_{\text{fault}},\ \phi_{\text{mgr}} \, \rangle$

其中各分量含义见表 1。阶段转移由两类驱动力触发：硬件形态变化 $\Delta_h$ 与调用主体变化 $\Delta_s$ ，可写作 $A_{t+1} = \Phi(A_t, \Delta_h, \Delta_s)$ ，其中 $\Phi$ 为本文第 3.3 节给出的阶段判定规则。

表 1：符号表

符号	含义	说明
$\mathcal{P}$	外设与工具全集	物理设备、软件工具、API 的并集
$\mathcal{I}$	接口全集	调用方可见的系统调用、函数、协议方法等
$A_t$	第 $t$ 阶段的抽象层	映射 $\mathcal{P} \to \mathcal{I}$
$\phi_{\text{int}}$	接口形态维度	命令式 / 声明式 / 代码即接口
$\phi_{\text{dis}}$	发现与注册维度	静态绑定 / 注册表发现 / 语义检索
$\phi_{\text{fault}}$	故障与隔离维度	故障域边界与恢复手段
$\phi_{\text{mgr}}$	管理主体维度	内核 / 运行时库 / 智能体运行时
$\Delta_h, \Delta_s$	阶段转移驱动力	硬件形态变化、调用主体变化
$C_{\text{total}}$	管理总成本	见式 (3)，含注册、发现、适配、隔离四项

3.2 Framework Overview

四维度框架把一条完整的能力供给链拆为四层，每一层在不同阶段由不同技术承载：

+--------------------------------------------------------------+
| 调用主体层  应用程序 | 系统服务 | LLM 智能体 / 多智能体协作      |
|             (phi_mgr: 管理主体是谁)                            |
+-------------------------▲------------------------------------+
                          | 统一动作空间（系统调用 / 函数调用 /
                          |             协议方法 / 可执行代码）
+-------------------------▼------------------------------------+
| 接口与描述层  驱动接口 | API 描述 | 工具 Schema（MCP 等）        |
|             (phi_int: 接口长什么样)                            |
+-------------------------▲------------------------------------+
                          | 注册表 / 语义检索 / 动态挂载
+-------------------------▼------------------------------------+
| 发现与管理层  设备表 | 服务网格 | 工具注册中心                   |
|             (phi_dis: 如何找到并绑定)                          |
+-------------------------▲------------------------------------+
                          | 隔离域：内核态保护 / 用户态沙箱 /
                          |        权限围栏
+-------------------------▼------------------------------------+
| 能力供给层   物理外设 | 虚拟设备 | API / 领域工具                |
|             (phi_fault: 故障域与恢复)                          |
+--------------------------------------------------------------+

图 1：工具与外设管理的四层分析框架。 括号内标注该层对应的分析维度；箭头方向为调用方向，虚线以上为调用方可见面，以下为管理面。

3.3 Module Details

阶段划分。 依据 $\mathbf{f}(A_t)$ 的取值差异，本文将演进划分为五个阶段（表 2）。阶段判定采用"主导特征"准则：当某一维度的主导实现发生代际更替、且其余维度随之调整时，判定为阶段转移。判定证据取自第 2 节引用的公开文献，凡涉及未核实的工程实践，本文在表中标注"个案观察，未核实"。

表 2：五阶段划分与四维特征

阶段	时期（粗略）	接口形态 $\phi_{\text{int}}$	发现与注册 $\phi_{\text{dis}}$	故障与隔离 $\phi_{\text{fault}}$	管理主体 $\phi_{\text{mgr}}$	代表工作
S1 内核态驱动	1970s–1990s	命令式寄存器/中断抽象	静态绑定、编译期确定	驱动故障即内核故障	OS 内核	Unix 设备文件约定
S2 隔离与可靠化	1990s–2010s	命令式 + 封装接口	热插拔与动态加载	轻量隔离、故障恢复	内核 + 隔离层	Nooks [1]、驱动实证研究 [3]
S3 生成与标准化	2000s–2010s	规格驱动、接口描述	驱动生成、接口库	规格校验降低缺陷	生成器 + 内核	Termite [2]
S4 API/工具经济	2010s–2020s	声明式 Schema、REST/函数调用	注册中心、文档检索	超时/重试、调用方兜底	云平台 + 应用	Gorilla [6]、ToolLLM [7]、API-Bank [8]
S5 智能体工具协议	2023–	工具 Schema + 可执行代码动作	语义检索、协议化挂载	沙箱执行、权限围栏	智能体运行时 / Agent OS	MCP、AIOS [10]、CodeAct [12]

阶段转移动因。 S1→S2 的动因是可靠性需求：驱动缺陷成为崩溃主因，倒逼隔离 [1]。S2→S3 的动因是开发成本：手写驱动不可扩展，规格化生成成为出路 [2]。S3→S4 的动因是调用对象从硬件扩展到软件服务，接口描述语言（Schema）取代寄存器手册成为契约 [6][7]。S4→S5 的动因是调用主体从人类程序员变为 LLM 智能体，接口必须可被模型语义理解与自主组合，由此催生 MCP 类协议与智能体运行时 [9][10][12]。

研判模块。 趋势判断按三步产出：（1）证据采集——对每个候选趋势，在表 2 的代表工作与公开技术文档中寻找支持与反例；（2）阶段归属——判断该趋势作用于哪一维度；（3）口径固化——为每条判断写出可观测的检验指标。第 4 节的六条趋势判断均按此流程产出。

3.4 Training / Inference

本文为分析型研究，不涉及模型训练；对应地，"推断"指研判流程的执行协议：

证据收集阶段：以第 7 节附录 B 给出的检索式覆盖 arXiv 与 ACM 数字图书馆（Association for Computing Machinery Digital Library），时间窗截至 2026 年 10 月；每条证据记录来源、年份、主张范围。
阶段归属阶段：两名以上独立评判者按表 2 的四维特征为证据打分（每维取 1–3 级），计算一致率；不一致项以讨论收敛，未收敛者标注"存疑"。
判断生成阶段：仅当某一维度存在跨阶段、跨流派的重复证据时，才输出趋势判断；单一个案只能作为"候选趋势"列出。
可检验化阶段：为每条判断指定检验窗口与观测指标，见表 4。

3.5 Complexity or Theoretical Properties

为使"演进"可度量，本文定义管理总成本：

$C_{\text{total}} = C_{\text{reg}} + C_{\text{dis}} + C_{\text{adapt}} + C_{\text{iso}} \tag{3}$

其中 $C_{\text{reg}}$ 为注册成本， $C_{\text{dis}}$ 为发现与匹配成本， $C_{\text{adapt}}$ 为适配成本（把 $\mathcal{P}$ 中能力翻译为 $\mathcal{I}$ 中接口）， $C_{\text{iso}}$ 为隔离与安全成本。两个结构性质可直接从该分解推出：

命题 1（适配成本转移）。 当接口形态从命令式转为声明式 Schema 时， $C_{\text{adapt}}$ 的主要承担者由调用方转移到工具提供方，调用方侧的 $C_{\text{adapt}}$ 随之下降，但 $C_{\text{reg}}$ 与 $C_{\text{iso}}$ 上升（需要可信描述与沙箱）。该命题与 Gorilla [6]、ToolLLM [7] 中"以文档与检索替代人工记忆 API 细节"的设计一致，属分析性归纳，其定量验证留待第 4.3 节的填充实验。

命题 2（发现复杂度）。 在注册表结构化索引下， $n$ 个工具的语义发现成本为 $O(\log n)$ （索引查找）加一次语义重排 $O (n)$ ；当 $n$ 超过单次上下文容量时，检索成为必需组件而非可选优化。这解释了为何工具规模从 API-Bank 的 73 个 [8] 扩展到 ToolLLM 的 16000 余个 [7] 后，检索增强成为默认架构。

命题 3（隔离的回归）。 调用主体从人变为智能体后，误用概率不再随开发者素养衰减， $C_{\text{iso}}$ 的边际收益上升，故隔离机制由可选变为必选。这与驱动领域"隔离是可靠性的前提"的结论 [1] 形成同构。

4 Experiments

本节按"研判实证"口径组织：证据来源、主结果（路线图）、敏感性分析、定性分析与局限。所有涉及未验证数据的表格均以 [实验数据待填] 占位，不填入任何估算值。

4.1 Experimental Setup

证据集。 主证据集为第 2 节引用的 15 篇学术文献与 1 项公开协议规范（MCP）[16]，覆盖 2003–2026 年。纳入标准：（a）同行评审或公开技术规范；（b）主张可被原文核对；（c）与四维度中至少一维直接相关。

分析单元。 以"工作—维度"对为最小单元，共 15 × 4 = 60 个单元，每单元记录证据原文位置与判定（支持/不支持/不适用）。

指标。 （1）阶段判定一致率：独立评判者在四维分级上的 Cohen’s kappa；（2）趋势证据密度：每条趋势判断的支持证据数与反例数之比；（3）成本分解覆盖率：能被式 (3) 四项解释的历史设计决策占比。上述三项的数值列为待填。

实现细节。 判定表与评分模板见附录 A；检索式见附录 B；本研究不涉及算力与超参数。

4.2 Main Results

表 3：路线图主线（2026–2030）

主线	当前状态（有证据）	近期（至 2027）	中期（至 2030）	关键依赖	置信口径
R1 工具协议统一化	MCP 等协议已获多家客户端支持 [16]	Schema 级互操作成为事实要求	描述—发现—授权三件套标准化	供应商协作、安全审计	高（协议已公开）
R2 管理主体迁移	AIOS 类系统已给出内核化原型 [10]	智能体运行时承担注册/调度	Agent OS 与传统 OS 分工明确化	调度与隔离工程	中（原型已公开，生产化未核实）
R3 接口合成与自愈	驱动合成已有先例 [2]，代码动作已验证有效 [12]	工具适配器自动生成进入实用	接口缺陷的自动检测与修复闭环	形式规格、沙箱验证	中（两支证据各自成立，合并路径为判断）

表 3 的"当前状态"列仅陈述公开文献与规范可核对的事实；"近期/中期"列为趋势判断，均可用第 4.1 节指标在相应时间点回测。

表 4：六条趋势判断与检验口径

编号	趋势判断	证据来源	可检验口径
T1	抽象边界持续上移：从寄存器抽象到协议化工具接口	[1][2][6][7][16]	新工具接入的首选方式中协议化占比逐年上升
T2	声明式接口成为主流：Schema 取代实现细节文档	[6][7][8][16]	主流工具发布物中含机器可读 Schema 的比例
T3	管理主体由内核向智能体运行时迁移	[9][10][11][12]	注册/调度/权限功能在智能体运行时中的实现度
T4	接口合成与自愈常态化	[2][12]	自动生成适配器占新增适配器比例
T5	隔离与安全重回一等约束	[1][10][16]	默认启用沙箱/权限围栏的工具运行时比例
T6	外设概念向数字工具泛化，统一管理面出现	[6][7][14][15]	同一管理面同时纳管物理外设与 API 的系统出现并开源

每条判断均未使用"必然""唯一"等绝对化表述；证据为跨流派重复出现的设计选择，反例与个案在第 4.4 节讨论。

4.3 Ablation Study

为检验阶段划分对维度权重的敏感性，本文设计如下消融协议（数值待填）：

消融设置	剔除维度	阶段判定一致率	五阶段结构是否保持	备注
完整框架	无	[实验数据待填]	是	基线
A1	去掉 $\phi_{\text{int}}$	[实验数据待填]	待验证	预期 S3/S4 边界模糊
A2	去掉 $\phi_{\text{dis}}$	[实验数据待填]	待验证	预期 S4/S5 边界模糊
A3	去掉 $\phi_{\text{fault}}$	[实验数据待填]	待验证	预期 T5 失去独立性
A4	去掉 $\phi_{\text{mgr}}$	[实验数据待填]	待验证	预期 T3 失去独立性

消融预期以假设形式给出：接口形态与发现机制是区分 S3/S4/S5 的主维度，故障模型与管理主体主要支撑趋势判断 T3、T5。该预期需要真实评判数据验证，本文不预填结果。

4.4 Analysis

定性分析。 沿证据链可以看到一条清晰的"上移"轨迹：Nooks 在内核内为驱动建保护区 [1]，Termite 把驱动编写交给合成器 [2]，Gorilla 与 ToolLLM 把 API 知识交给检索器 [6][7]，CodeAct 把动作空间交给可执行代码 [12]，AIOS 把调度与权限交给智能体内核 [10]，MCP 把工具连接交给标准协议 [16]。每一步都把原本由调用方或内核手工承担的复杂度，转移为显式的基础设施职责。

效率分析。 AIOS 报告的最高 2.1 倍执行加速 [10] 与 CodeAct 报告的动作成功率提升 [12] 表明，抽象上移并不以牺牲效率为代价；相反，标准化接口减少了适配损耗。本文式 (3) 的成本分解可解释该现象： $C_{\text{adapt}}$ 的转移与 $C_{\text{dis}}$ 的检索化共同降低了调用方总成本。

失败案例。 两个反向证据值得记录。其一，Kadav 与 Swift 发现驱动研究的常用假设并不适用于全部驱动 [3]，提示阶段划分不能替代对具体实现的核查。其二，加速器作为普通外设会带来显著系统开销，需专门支持才能发挥性能 [15]，说明"统一抽象"并非免费，物理外设的性能敏感场景可能长期保留专用路径。二者的共同含义：抽象上移是统计趋势，不是对所有场景的强制规范。

4.5 Limitations

本文的局限有三。第一，证据集规模有限（15 篇文献加 1 项协议），主要覆盖英文公开文献，可能遗漏产业内部实践与中文社区进展。第二，五阶段的边界年份为粗略估计，不构成严格的历史分期。第三，表 3、表 4 的前瞻判断带有时效性，协议生态（如 MCP）变化较快，需要按检验口径定期回测。上述局限不影响分析框架本身，但影响判断的置信度标定。

5 Discussion

成因解释。 演进的长期动力是"能力供给方"与"能力调用方"的解耦。每当调用方规模扩大一个量级（从单机应用到互联网服务，再到海量智能体），原有接口的描述能力与管理能力就出现缺口，新的抽象层随之出现以吸收复杂度。驱动之于硬件、Schema 之于 API、工具协议之于智能体，本质是同一机制的三次重演。

适用边界。 本文框架适用于以"能力接入"为矛盾主线的系统；对计算本身（处理器微架构）、存储本身（介质技术）等以供给能力为矛盾主线的领域，四维度框架的解释力有限。此外，实时控制、功能安全等场景中，专用驱动路径可能长期优于统一抽象 [15]。

伦理与治理影响。 当管理主体从内核迁移到智能体运行时 [10]，工具调用的权限边界、审计责任与故障归因随之迁移。工具描述的真实性（Schema 是否如实反映行为）、沙箱的默认强度、以及用户对智能体调用外设的知情同意，构成需要在协议层而非应用层解决的治理问题。本文建议把"可审计的工具描述"与"最小权限默认"作为 T2、T5 检验口径的组成部分。

6 Conclusion

本文以"能力—接口适配层"统一视角，把设备驱动抽象与智能体工具管理纳入同一演进谱系，给出四维分析框架与五阶段划分，并产出三条路线图主线与六条带检验口径的趋势判断。已陈述的结论均由公开文献与协议规范支撑：抽象边界上移、声明式接口普及、管理主体向智能体运行时迁移，均有跨流派重复证据；隔离机制回归与接口合成常态化，有先例支撑但合并路径仍属判断。本文未报告任何自拟实验数据，所有定量表格均以占位符标注待填。

未来工作具体如下：（1）按附录 B 检索式扩充证据集至 200 篇以上，完成第 4.1 节三项指标的实测；（2）在开源智能体运行时上实现式 (3) 的成本探针，验证命题 1、2 的定量关系；（3）以 2027 年为节点回测表 4 的 T1–T3，更新置信口径；（4）针对实时与功能安全场景，验证"专用路径保留"的边界条件。

References

[1] Swift M M, Bershad B N, Levy H M. Improving the Reliability of Commodity Operating Systems [C]. Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP 2003), 2003. DOI: 10.1145/945445.945466.

[2] Ryzhyk L, Chubb P, Kuz I, et al. Automatic Device Driver Synthesis with Termite [C]. Proceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP 2009), 2009. DOI: 10.1145/1629575.1629583.

[3] Kadav A, Swift M M. Understanding Modern Device Drivers [C]. Proceedings of the 17th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2012), 2012. DOI: 10.1145/2150976.2150987.

[4] Schick T, Dwivedi-Yu J, Dessì R, et al. Toolformer: Language Models Can Teach Themselves to Use Tools [R]. arXiv:2302.04761, 2023.

[5] Qin Y, Hu S, Lin Y, et al. Tool Learning with Foundation Models [R]. arXiv:2304.08354, 2023.

[6] Patil S G, Zhang T, Wang X, Gonzalez J E. Gorilla: Large Language Model Connected with Massive APIs [R]. arXiv:2305.15334, 2023.

[7] Qin Y, Liang S, Ye Y, et al. ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs [R]. arXiv:2307.16789, 2023.

[8] Li M, Zhao B, Yu B, et al. API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs [C]. Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing (EMNLP 2023), 2023. arXiv:2304.08244.

[9] Xi Z, Chen W, Guo X, et al. The Rise and Potential of Large Language Model Based Agents: A Survey [R]. arXiv:2309.07864, 2023.

[10] Mei K, Zhu X, Xu J, et al. AIOS: LLM Agent Operating System [R]. arXiv:2403.16971, 2024.（已发表于 COLM 2025）

[11] Wu Q, Bansal G, Zhang J, et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation [R]. arXiv:2308.08155, 2023.

[12] Wang X, Chen Y, Yuan L, et al. Executable Code Actions Elicit Better LLM Agents [R]. arXiv:2402.01030, 2024.

[13] Zhang C, Li L, He S, et al. UFO: A UI-Focused Agent for Windows OS Interaction [R]. arXiv:2402.07939, 2024.

[14] Wang J, Xu H, Ye J, et al. Mobile-Agent: Autonomous Multi-Modal Mobile Device Agent with Visual Perception [R]. arXiv:2401.16158, 2024.

[15] Shahidzadeh M, Shannon L. Operating System Support for Accelerators as First-Class Compute Elements in Heterogeneous Systems [R]. arXiv:2610.33380, 2026.

[16] Anthropic. Model Context Protocol (MCP) [EB/OL]. https://modelcontextprotocol.io/, 2024–2026.

Appendix

附录 A：阶段评分表模板

对每个"工作—维度"对，评判者按下表打分（1 = 上一阶段特征，2 = 过渡特征，3 = 下一阶段特征），并记录原文位置：

工作	维度	分数 1–3	原文位置	判定（支持/不支持/不适用）	备注
[示例占位]	$\phi_{\text{int}}$	[待填]	[待填]	[待填]	[待填]

附录 B：检索式

arXiv：("device driver" OR "driver synthesis" OR "driver reliability")、("tool learning" OR "function calling" OR "API call") AND ("large language model" OR "LLM")、("agent operating system" OR "tool management" OR "Model Context Protocol")
ACM Digital Library：device driver abstraction reliability、tool use foundation models、agent infrastructure tool management
时间窗：2003-01 至 2026-10；语言：英文为主；纳入排除标准见第 4.1 节。

附录 C：命题 1、2 的证明思路

命题 1：声明式 Schema 把"如何调用"的知识编码进描述物，故实现细节的翻译工作由提供方在注册时完成（ $C_{\text{adapt}}$ 转移）；但描述物需要可信发布与行为约束，故 $C_{\text{reg}}$ （注册审核）与 $C_{\text{iso}}$ （沙箱）上升。形式化验证需要在真实工具集上测量四项成本分量，属待填实验。