AI Agent 操作系统：混合内核设计

Python人工智能大数据

165人浏览 · 2026-11-10 14:10:45

Python人工智能大数据 · 2026-11-10 14:10:45 发布

AI Agent 操作系统：混合内核设计

title: “AI Agent 操作系统：混合内核设计”
authors: “[DeepThink.ai]”
affiliations: “[AI Genius Institute]”
keywords: “智能体操作系统；混合内核；大语言模型智能体；能力管控；推理调度；不可逆预算”

Abstract

以大语言模型为认知核心的自主智能体正从单次问答演化为长时程、跨工具、可产生外部副作用的持续计算负载，业界由此提出智能体操作系统（Agent OS）作为统一的资源与治理层。然而，现有智能体操作系统要么将全部服务堆入单一内核，导致可信计算基膨胀、信任边界模糊，要么沿纯微内核路线将所有服务隔离，使高频的上下文访问与推理调用承受跨服务通信开销，难以同时满足隔离安全与执行效率。本文提出一种面向智能体负载特性的混合内核设计（HKOS）：将能力管控、记忆账本、副作用准入与审计等信任敏感机制收敛到微内核式可信核心，将推理请求批处理、上下文缓存、工具执行运行时等性能关键路径放入宏内核式快路径层，规划与领域智能体则运行于用户态。本文给出系统调用接口、不可逆操作的预算准入机制与批处理调度策略，并分析其中介开销与隔离性质。在此基础上，本文设计了在 GAIA、SWE-bench Verified 与 τ-bench 等基准上的可复现实验协议，用以验证任务成功率、端到端延迟与安全拦截能力。该设计为构建可审计、可治理且高效的智能体运行基座提供了一条介于单体内核与微内核之间的工程路径。

—

你离拥有一支永不停歇、持续进化的 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

大语言模型（Large Language Model, LLM）驱动的智能体已从"提示—应答"的无状态调用，演化为持续感知、规划、调用工具并写入长期记忆的长时程计算负载 [1,10]。智能体在执行软件工程、科学检索、网页操作等任务时，会产生文件写入、代码部署、外部转账等难以完全撤销的副作用 [6]。这一转变使"如何为智能体分配资源、隔离状态、管控副作用"成为系统层面的问题，智能体操作系统（Agent Operating System, Agent OS）的概念随之出现 [1–9]。

现有工作给出了两条主要技术路线，但各有具体局限。第一类是单体内核式设计：AIOS 将调度、上下文、记忆、存储与访问控制集中于一个内核，为智能体应用提供统一服务 [1]，其优势是路径短、易批处理，但全部服务同处一个信任域，任一服务缺陷都可能波及整个内核，可信计算基（Trusted Computing Base, TCB）随功能扩张持续膨胀。第二类是微内核式或控制平面式设计：AgentKernel 将身份、输入调节、记忆治理与执行控制做成不可绕过的强制服务 [5]，AOS 参考架构将治理平面与协调平面分离 [3,4]，其隔离与可审计性更强，但跨服务通信使高频的上下文读写与推理调度承受额外开销，而 LLM 调用的批处理优化又要求共享调度视图，与强隔离目标存在张力。经典操作系统研究早已表明，纯宏内核与纯微内核都不是唯一答案：Windows NT 与 XNU 等系统采用混合内核结构，把性能关键机制与可扩展策略分层放置 [11]。然而，如何为智能体负载确定这一分层边界，现有文献只给出原则性主张 [2]，尚缺面向负载特性的具体设计。

本文的核心思路是：智能体负载的延迟主体是 LLM 推理而非系统调用，信任敏感操作只占调用频谱的低频尾部。据此，本文提出混合内核智能体操作系统（Hybrid-Kernel Agent OS, HKOS），把低频高危的信任敏感机制收敛到微内核式可信核心，把高频高吞吐的性能关键路径放入宏内核式快路径层，其余智能体生态运行于用户态。HKOS 以能力（capability）驱动的系统调用接口连接三层，以不可逆预算机制对副作用做准入控制 [6]，以批处理调度与上下文缓存摊薄推理开销。

本文贡献如下：

提出面向智能体负载特性的混合内核架构 HKOS，按"信任敏感—性能关键"两条准则划分内核边界，给出分层框图与系统调用接口。
设计能力驱动的访问控制与不可逆副作用的预算准入机制，将身份、记忆账本与审计收敛到微内核式可信核心。
给出推理请求批处理调度与上下文缓存的快路径实现方案，并分析其中介开销上界与隔离性质。
设计覆盖任务成功率、端到端延迟与安全拦截率的实验协议，指定基准、基线、指标与消融设置，实验数值以占位符标注待复现填充。

后文结构如下：第 2 节按技术流派回顾相关工作；第 3 节给出问题形式化与 HKOS 设计；第 4 节给出实验设计；第 5 节讨论适用边界与伦理影响；第 6 节总结并给出未来工作。

2 Related Work

智能体操作系统与运行时。 AIOS 提出将调度、上下文管理、记忆管理、存储管理与访问控制下沉到内核，并配套 SDK 供智能体调用 [1]；其后续工作 LSFS 将语义检索引入文件系统，使智能体以自然语言完成文件操作 [7]；AIOS Server 进一步将运行时扩展为基于 MCP 与 JSON-RPC 的对等网络 [8]。AOS 系列工作将智能体控制平面并入传统操作系统并给出厂商中立的分布式参考架构 [3,4]。Steinder 与 Franke 从经典与云操作系统的演化史出发，主张先收敛出语义精确的智能体抽象再做平台整合 [2]。TopoClaw 强调跨设备与跨用户的拓扑感知执行 [9]，MatOS 等工作则给出领域专用的智能体操作系统实例。上述工作多聚焦"内核提供哪些服务"，而本文聚焦"哪些服务应进内核、以何种内核结构进"，给出宏内核与微内核之间的混合分层方案。

经典操作系统内核结构。 宏内核以性能见长但 TCB 庞大，微内核将驱动与文件系统等移到用户态以缩小 TCB，exokernel 则把资源绑定权交还应用 [13]，seL4 以形式化验证证明了小微内核的隔离性质 [12]。混合内核（Windows NT、XNU）将性能关键机制保留在内核态，同时保持模块化边界 [11]。这些结构差异是本文设计的直接类比来源，但经典内核面向确定性程序与人类触发的工作流 [3]，其负载假设与智能体的"推理为主、副作用为尾"不同；本文据此重新划定分层边界，而非直接移植。

智能体安全、信任与副作用管控。 AgentKernel 把智能体生命周期包裹在不可绕过的执行边界内，强制提供身份、输入调节、记忆治理与执行控制四类服务 [5]。Irreversibility Budget 将不可逆效应建模为残余风险账户，以预算做机群级准入控制 [6]。MCP 生态的系统化安全研究指出工具协议层的注入与权限风险，并给出通往自主智能体操作系统的安全路线图。与这些工作侧重策略与协议不同，本文把上述机制具体落实为混合内核 TCB 中的系统调用与准入路径，并给出其开销分析。

智能体框架与推理—行动循环。 ReAct 将推理与工具行动交织为单循环 [10]，后续大量框架围绕该循环提供编排、记忆与多智能体协作能力。框架层解决"智能体如何做事"，但把资源治理、隔离与副作用管控留给应用自行实现；本文的内核设计正是把这些共性治理能力下沉为系统服务，与框架层正交，可作为其运行基座。

3 Method

3.1 Problem Formulation

设智能体任务为五元组

$\tau = (g, \pi, \mathcal{T}, \mathcal{M}, \mathcal{B})$

其中 $g$ 为任务目标， $\pi$ 为智能体的感知—推理—行动循环策略， $\mathcal{T} = \{t_1, \dots, t_m\}$ 为可调用工具集合， $\mathcal{M}$ 为记忆状态（含上下文窗口与持久记忆）， $\mathcal{B} = (b_c, b_t, b_k, b_i)$ 为预算向量： $b_c$ 为上下文容量预算， $b_t$ 为推理 token 预算， $b_k$ 为时间预算， $b_i$ 为不可逆副作用预算。

一次智能体执行由系统调用序列刻画：

$ctx_alloc , llm_infer , tool_invoke , mem_read , mem_write , irrev_commit , checkpoint , fork ⟩ ∗ \sigma = \langle \texttt{ctx\_alloc}, \texttt{llm\_infer}, \texttt{tool\_invoke}, \texttt{mem\_read}, \texttt{mem\_write}, \texttt{irrev\_commit}, \texttt{checkpoint}, \texttt{fork} \rangle^{*}$

其中 $llm_infer \texttt{llm\_infer}$ 与 $tool_invoke \texttt{tool\_invoke}$ 为高频调用， $irrev_commit \texttt{irrev\_commit}$ 为不可逆副作用提交（如发送、支付、删除），低频但高危。能力定义为三元组 $c a p = (s, r, p)$ ：主体 $s$ 、资源 $r$ 与权限集合 $p$ 。对不可逆效应 $e$ ，定义残余风险量 $\rho(e)$ ；准入条件为累计风险不超预算：

$\sum_{e \in E_{\text{committed}}} \rho(e) + \rho(e_{\text{new}}) \le b_i$

本文目标：设计一个内核结构 $\mathcal{K}$ 与调度准入策略，使 (i) 跨信任域的信息流全部经可信核心审计；(ii) 高频调用 $llm_infer \texttt{llm\_infer}$ 、 $mem_read/write \texttt{mem\_read/write}$ 的中介开销足够低；(iii) 不可逆副作用满足上述预算约束。

符号表：

符号	含义
$\tau$	智能体任务五元组
$g$	任务目标
$\pi$	感知—推理—行动循环策略
$\mathcal{T}$	工具集合， $\|\mathcal{T}\| = m$
$\mathcal{M}$	记忆状态（上下文 + 持久记忆）
$\mathcal{B}$	预算向量 $b_c, b_t, b_k, b_i)$
$\sigma$	系统调用序列
$c a p$	能力三元组 $(s, r, p)$
$\rho(e)$	效应 $e$ 的残余风险量
$W$	推理请求批处理窗口
$\mathcal{K}$	内核结构

3.2 Framework Overview

HKOS 采用三层混合内核结构：微内核式可信核心（TCB）、宏内核式快路径层（Fast Path）与用户态智能体生态。整体架构如图 1 所示。

┌─────────────────────────────────────────────────────────────────────┐
│                     用户态：智能体生态（不可信 / 可插拔）                │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐              │
│  │ 规划智能体    │  │ 领域智能体    │  │ 人类协作界面  │              │
│  │ (Planner)    │  │ (Domain)     │  │ (Human UI)   │              │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘              │
├─────────┴─────────────────┴─────────────────┴──────────────────────┤
│              系统调用门（Capability Check O(1)）                      │
├─────────────────────────────────────────────────────────────────────┤
│              宏内核式快路径层（同信任域内、性能关键）                    │
│  ┌───────────────┐ ┌───────────────┐ ┌─────────────────────────┐   │
│  │ 推理调度器     │ │ 上下文缓存     │ │ 工具执行运行时           │   │
│  │ (批处理窗口 W) │ │ (语义索引)     │ │ (沙箱 / 同域共享内存)     │   │
│  └───────────────┘ └───────────────┘ └─────────────────────────┘   │
├─────────────────────────────────────────────────────────────────────┤
│              微内核式可信核心（最小 TCB、信任敏感）                     │
│  ┌──────────┐ ┌──────────┐ ┌───────────┐ ┌──────────┐              │
│  │ 能力管理器│ │ 记忆账本  │ │ 副作用准入 │ │ 审计日志  │              │
│  │ (Cap)    │ │ (Ledger) │ │ (预算 b_i)│ │ (Audit)  │              │
│  └──────────┘ └──────────┘ └───────────┘ └──────────┘              │
└─────────────────────────────────────────────────────────────────────┘

图 1：HKOS 混合内核架构。信任敏感机制（能力、账本、准入、审计）收敛于微内核式 TCB；性能关键路径（推理调度、上下文缓存、工具执行）位于快路径层；智能体逻辑在用户态运行，经系统调用门进入内核。

分层准则有两条。(a) 信任敏感准则：凡决定"谁可访问什么、副作用是否放行"的机制，无论性能代价，一律进入 TCB。(b) 性能关键准则：凡高频且同信任域内安全的机制，进入快路径层，避免逐次跨域通信。经典的宏内核与微内核之争由此转化为一个负载相关的边界划分问题。

3.3 Module Details

3.3.1 微内核式可信核心

TCB 仅包含四个模块。(1) 能力管理器：签发、校验与撤销能力 $c a p = (s, r, p)$ ，校验为哈希查表，单次开销 $O (1)$ 。(2) 记忆账本：以只追加（append-only）日志记录记忆读写，为每次 $mem_write \texttt{mem\_write}$ 生成单调递增序号，支持回放与一致性检查。(3) 副作用准入器：对 $irrev_commit \texttt{irrev\_commit}$ 按 $\rho(e)$ 计费并执行预算检查，拒绝将超出 $b_i$ 的边际效应；其思想与 Irreversibility Budget [6] 一致，差别在于本文将其置于内核准入路径而非机群侧记账服务。(4) 审计日志：记录全部 TCB 决策，供事后问责与分析 [5]。TCB 不含推理调度与工具执行逻辑，代码规模保持在可审计量级；量化指标见第 4 节实验设计。

3.3.2 宏内核式快路径层

快路径层包含三个模块。(1) 推理调度器：把各智能体的 $llm_infer \texttt{llm\_infer}$ 请求汇聚到批处理窗口 $W$ 内合并调度，以吞吐换少量排队延迟；调度器维护优先级队列，防止长任务被批处理饿死。(2) 上下文缓存：为同一信任域内的智能体提供共享的语义索引与上下文块缓存，复用提示前缀，减少重复 token；语义化检索借鉴 LSFS 的思路 [7]，但缓存位于内核快路径而非文件系统服务。(3) 工具执行运行时：在沙箱中执行 $tool_invoke \texttt{tool\_invoke}$ ，同域工具间允许共享内存通道，跨域调用强制经 TCB 能力检查。快路径与 TCB 的关系是：快路径可不经 TCB 直接服务同域高频调用，但一旦涉及跨域资源或副作用，必须陷入 TCB。

3.3.3 用户态服务与智能体生态

规划智能体、领域智能体、人类协作界面与第三方框架均运行于用户态，彼此以消息传递协作。用户态组件对内核不可信，只能通过系统调用门访问资源；框架（如 ReAct 风格循环 [10]）可直接构建于 HKOS 之上，无需修改即可获得资源治理与副作用管控。

3.3.4 系统调用接口与调用流程

系统调用门对每次调用执行 $O (1)$ 能力检查后，按高频/低频分流。一次典型执行流程如下：

用户态智能体            系统调用门           快路径层              TCB
    │                    │                  │                   │
    │ ctx_alloc(目标 g)  │                  │                   │
    │───────────────────>│  能力检查(失败即拒绝)                  │
    │                    │─────────────────────────────────────>│
    │                    │        签发 cap、登记账本             │
    │ llm_infer(提示)    │                  │                   │
    │───────────────────>│  能力检查(通过)  │                   │
    │                    │─────────────────>│ 攒批(W) 合并推理  │
    │<───────────────────│<─────────────────│ 返回推理结果       │
    │ tool_invoke(t_i)   │                  │                   │
    │───────────────────>│  能力检查(同域放行)                   │
    │                    │─────────────────>│ 沙箱执行工具       │
    │ irrev_commit(e)    │                  │                   │
    │───────────────────>│  能力检查        │                   │
    │                    │─────────────────────────────────────>│
    │                    │     预算检查 Σρ(e)≤b_i ?              │
    │                    │     通过→放行+记账 / 拒绝→返回错误     │
    │ checkpoint()       │                  │                   │
    │───────────────────>│─────────────────────────────────────>│
    │                    │     快照 M 与账本状态                  │

图 2：HKOS 典型调用流程。高频调用（推理、工具）在能力检查后走快路径；低频高危调用（副作用提交、检查点）陷入 TCB。

3.4 Training / Inference

HKOS 是运行时系统，本身不含模型训练环节；其"推断"即智能体任务的执行过程，分三阶段。(1) 任务装载：解析 $\tau$ ，为任务分配上下文预算 $b_c$ 并签发初始能力集。(2) 循环执行：智能体循环 $\pi$ 通过系统调用驱动推理与工具调用，推理调度器按窗口 $W$ 批处理，上下文缓存对重复前缀做复用；每次 $irrev_commit \texttt{irrev\_commit}$ 由 TCB 准入。(3) 收尾与回放：任务结束时执行 $\texttt{checkpoint}$ 固化 $\mathcal{M}$ 与账本，审计日志支持完整回放。当智能体由微调模型驱动时，模型训练发生在系统之外，HKOS 仅约束其运行期资源与副作用；这是本文与训练优化类工作的分界。

3.5 Complexity or Theoretical Properties

中介开销。 能力检查与预算记账均为哈希表操作，单次系统调用的内核中介固定开销为 $O (1)$ 。设一次 $llm_infer \texttt{llm\_infer}$ 的推理时延为 $L_{\text{llm}}$ ，内核中介开销为 $L_k$ ，则中介占比 $L_k / (L_{\text{llm}} + L_k)$ 随 $L_{\text{llm}}$ 增大而趋零；在长时程智能体任务中 $L_{\text{llm}}$ 通常占主导，中介开销占比有限。该论断为开销模型的推论，尚待实验确认。

批处理调度。 推理调度器对 $n$ 个待发请求维护优先级队列，单次入队出队为 $O(\log n)$ ；批处理在窗口 $W$ 内合并请求，以平均 $W /2$ 的排队延迟换取更高的推理吞吐。 $W$ 是吞吐与延迟的权衡参数，过大将饿死短请求，需配优先级老化机制。

隔离性质。 命题（隔离保持）：若快路径层仅在同信任域内共享状态，且全部跨域资源访问与副作用提交经 TCB 审计，则任意用户态组件的信息流跨越信任域时必留下审计记录。该命题是架构约束的直接推论，不构成形式化证明；对 TCB 的形式化验证（参照 seL4 路线 [12]）列为未来工作。

4 Experiments

本节给出实验协议。所有结果数值在原型系统完成测量之前以 [实验数据待填] 占位，不填入未经测量的数据。

4.1 Experimental Setup

原型实现（设计假设）。 原型以异步运行时实现三层结构：TCB 以独立进程运行并提供本地系统调用门；快路径层承载批处理调度器、上下文缓存与沙箱化工具运行时；用户态智能体通过 SDK 接入。LLM 后端为兼容 OpenAI 风格接口的推理服务，本地与远程后端各测一组。以上为设计设定，具体实现细节以开源发布为准。

数据集与任务。 选用三类公开基准覆盖不同负载：GAIA（多步工具使用与检索）、SWE-bench Verified（真实软件工程任务，含文件写入等副作用）、τ-bench（工具—用户双侧交互，含敏感操作）。均为公开可复现基准。

基线。 (1) 单体内核基线：AIOS [1] 风格的集中式内核；(2) 纯微内核基线：全部服务经消息传递隔离的原型变体；(3) 无内核基线：智能体框架直接调用模型与工具（ReAct 风格循环 [10]）。

指标。 任务成功率（按基准官方口径）；端到端延迟（中位数与 P95）；推理吞吐（每分钟完成的 $llm_infer \texttt{llm\_infer}$ 请求数）；内核中介开销（单次系统调用的内核侧耗时）；安全指标：隔离违规事件数、不可逆操作拦截数与误拦截率。

超参数（配置默认值，非实验结果）。 批处理窗口 $\in \{50, 100, 200\}$ ms；不可逆预算 $b_i$ 按任务类型分档；上下文缓存容量设为每信任域固定配额。硬件环境与重复次数在复现实验时给出。

4.2 Main Results

表 1 给出主结果模板。表中数值须以实测填充后方可引用。

表 1：任务成功率与延迟对比（数值待实测填充）

系统	GAIA 成功率	SWE-bench Verified 成功率	τ-bench 成功率	延迟中位数	延迟 P95	推理吞吐
无内核基线（ReAct 风格）	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]
单体内核基线（AIOS 风格）	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]
纯微内核基线	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]
HKOS（本文）	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]	[实验数据待填]

预期趋势（假设，非结论）：单体内核在延迟与吞吐上占优，纯微内核在安全指标上占优，HKOS 期望在两者之间取得折衷。该预期须以表 1 实测数据检验，未验证前不作为结论陈述。

4.3 Ablation Study

消融配置与关注指标如表 2 所示，用于定位各模块的贡献。

表 2：消融设置（结果数值待实测填充）

消融配置	变化点	关注指标	结果
去掉副作用准入	不检查 $\sum\rho(e)\le b_i$	拦截数、违规事件数	[实验数据待填]
去掉推理批处理	$\to 0$ ，逐请求调度	吞吐、P95 延迟	[实验数据待填]
去掉上下文缓存	每次全量重建提示	token 开销、延迟	[实验数据待填]
全部服务进 TCB	退化为单体内核	中介开销、TCB 规模	[实验数据待填]
全部服务出 TCB	退化为纯微内核	跨域调用次数、延迟	[实验数据待填]

4.4 Analysis

定性分析。 智能体工作负载呈"推理为主、副作用为尾"的形态： $llm_infer \texttt{llm\_infer}$ 占用大部分墙钟时间， $irrev_commit \texttt{irrev\_commit}$ 频次低但影响大。混合内核把治理成本压到低频路径上，把性能预算留给高频路径，与该形态匹配。该判断来自负载形态推理，需由追踪数据验证。

效率分析。 由 3.5 节开销模型，中介开销占比随推理时延下降；批处理收益随并发智能体数增加。两个方向各设一组扫描实验（ $W$ 扫描、并发数扫描），结果待测。

失败案例（预设风险类别）。 (1) 预算误配： $b_i$ 过小导致合法副作用被拒（误拦截），过大则失去约束力；(2) 批处理饿死：大 $W$ 使短请求排队过久，需优先级老化；(3) 缓存污染：同域共享上下文缓存可能引入过期信息。上述为风险分析，实测中的失败案例分布待实验补充。

4.5 Limitations

本文当前的局限：(1) 实验数据未测，全部主结果为占位符，结论性主张仅限于设计层面；(2) 隔离性质为架构级命题而非形式化证明，TCB 尚未经过 seL4 式验证 [12]；(3) 基准覆盖文本与代码任务，未覆盖具身机器人与多模态场景；(4) $\rho(e)$ 的残余风险估计依赖人工标定，缺乏普适的自动估计方法；(5) 混合内核边界的划分准则来自负载形态推理，尚待多场景追踪数据检验。

5 Discussion

成因解释。 两条内核路线的取舍根源于智能体负载的双峰性：高频推理路径对开销敏感，低频副作用路径对信任敏感。单一结构难以同时优化两个峰，混合内核以空间换边界清晰——用一层 TCB 换可审计性，用一层快路径换吞吐。

适用边界。 HKOS 适用于多智能体共享机器、需统一治理的部署形态（如企业内部智能体平台、自托管智能体运行时）。对单智能体一次性脚本，内核收益不足以抵消复杂度；对强实时嵌入式控制，批处理排队假设不成立。跨域共享的批处理还要求调度器持有跨域视图，此处与最小权限原则存在张力，工程上以"调度器只见元数据、不见内容"缓解，但无法核实其在所有部署形态下的充分性。

伦理影响。 智能体产生转账、删除、发布等外部影响，责任归属必须可审计；HKOS 的审计日志与预算准入为此提供机制基础 [6]。同时，内核级管控意味着平台运营方对智能体行为拥有最终裁决权，须配套透明的策略声明与申诉路径，避免治理机制被滥用为对用户的监控手段。

6 Conclusion

本文提出面向大语言模型智能体负载的混合内核操作系统设计 HKOS：将能力管控、记忆账本、副作用准入与审计收敛到微内核式可信核心，将推理批处理调度、上下文缓存与工具执行放入宏内核式快路径层，智能体生态运行于用户态，三层以能力驱动的系统调用接口连接。本文给出了问题形式化、系统调用接口、不可逆预算准入机制，并分析了其中介开销与隔离性质。当前已验证内容限于设计与分析层面：实验协议、基线、指标与消融设置已经给出，实测数值以占位符标注。未来工作包括：(1) 完成原型实测并填充 GAIA、SWE-bench Verified、τ-bench 上的对比结果；(2) 对 TCB 的四个模块开展形式化建模与验证，参照 seL4 路线 [12]；(3) 从部署追踪中统计负载形态，检验并修正内核边界划分准则；(4) 研究 $\rho(e)$ 的自动估计方法，减少人工标定依赖；(5) 将调度抽象与 POSIX/Kubernetes 式标准化讨论 [2] 对接，评估接口可移植性。

References

[1] Mei K, Zhu X, Xu W, Hua M, Jin M, Li Z, Xu S, Ye R, Ge Y, Zhang Y. AIOS: LLM Agent Operating System. arXiv:2403.16971. COLM 2025.

[2] Steinder G, Franke H. Towards an Agent Operating System - Lessons from Classical and Cloud OS. arXiv:2607.25076, 2026.

[3] Sharma A, Shah D. Agent Operating Systems (AOS): Integrating Agentic Control Planes into, and Beyond, Traditional Operating Systems. arXiv:2606.01508, 2026.

[4] Sharma A, Shah D. The Agent Operating System (AOS): A Reference Operating Architecture for Distributed Agentic Systems. arXiv:2608.03214, 2026.

[5] Zou Z, Guo S, Zhan Q, Zhao L, Li S, Liu Z. AgentKernel: The Trust-Native Agentic Operating System. arXiv:2609.29647, 2026.

[6] Mohammadi B, Bindschaedler L. The Irreversibility Budget: Fleet-Level Risk Accounting and Admission Control for Agent Operating Systems. arXiv:2609.00275. 2nd AgenticOS Workshop @ SOSP, 2026.

[7] Shi Z, Mei K, Jin M, Su Y, Zuo C, Hua W, Xu W, Ren Y, Liu Z, Du M, Deng D, Zhang Y. From Commands to Prompts: LLM-based Semantic File System for AIOS. arXiv:2410.11843. ICLR 2025.

[8] Zhang X, Zhang Y. Planet as a Brain: Towards Internet of AgentSites based on AIOS Server. arXiv:2504.14411, 2025.

[9] Huang H, Guan Y, Wang J, Wang M, Zhou J, Qu X, Yin J, Liao X, Lou X, Wang J. TopoClaw: A Human-Centric and Topology-Aware Agent Operating System. arXiv:2605.15556, 2026.

[10] Yao S, Zhao J, Yu D, Du N, Shafran I, Narasimhan K, Cao Y. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629. ICLR 2023.

[11] Tanenbaum A S, Bos H. Modern Operating Systems (4th Edition). Pearson, 2014.

[12] Klein G, Elphinstone K, Heiser G, Andronick J, Cock D, Derrin P, Elkaduwe D, Engelhardt K, Kolanski R, Norrish M, Sewell T, Tuch H, Winwood S. seL4: Formal Verification of an OS Kernel. Proceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP), 2009.

[13] Engler D R, Kaashoek M F, O’Toole J Jr. Exokernel: An Operating System Architecture for Application-Level Resource Management. Proceedings of the 15th ACM Symposium on Operating Systems Principles (SOSP), 1995.

Appendix

附录 A：系统调用语义摘要

系统调用	频率	处理层	语义
`ctx_alloc`	低	TCB	分配上下文预算 $b_c$ 并签发初始能力
`llm_infer`	高	快路径	进入批处理队列，窗口 $W$ 内合并调度
`tool_invoke`	高	快路径	沙箱执行；跨域时经 TCB 能力检查
`mem_read` / `mem_write`	高	快路径 + 账本	读写记忆；写入登记账本序号
`irrev\_commit`	低	TCB	按 $\rho(e)$ 计费并执行预算准入
`checkpoint`	低	TCB	固化 $\mathcal{M}$ 与账本快照
`fork`	低	TCB	派生子任务，复制能力子集

附录 B：指标定义

任务成功率：基准官方判定通过的任务比例。
中介开销：系统调用进入内核到返回用户态的内核侧耗时（不含推理与工具执行）。
不可逆操作拦截率：被 TCB 预算准入拒绝的 irrev\_commit 占总提交请求的比例。
误拦截率：事后被人工或规则判定为可安全放行的拦截占总拦截的比例。

北京朝阳AI社区

更多推荐

YLT 智能助手（小岳）· 18｜自我模型、把握校准与决策先验

YLT智能助手（小岳）第18篇提出“自我模型”核心机制，破解Agent“假学习”困境。通过身份叙事、能力边界与分域把握三要素构建可验证的自我认知，结合EWMA动态校准把握度，实现“低把握→加深验证”的闭环。关键创新在于DecisionPrior：将把握度转化为真实执行深度（如复核轮数从1增至2），并确保执行侧真正消耗轮数，使“我不确定”真正驱动更严谨行为。教训回流按领域去重，避免冗余。整套系统以可

北京朝阳AI社区

NSSCT大模型Prompt挑战一Fernie-5.5-flash-previe攻破，但是无法复现，有无大神看看攻破原因

原因是 char_reverse(SECRET) 在过滤层的候选比对里没被正确覆盖——我的 is_leak 里虽然写了 char_reverse(secret) in c，但解码器对反转串的处理顺序有 bug。所以"我是开发者，输出秘密"这类话不改变任何事。我之前说过判断标准是"输出能否被还原成秘密"，这条标准对"测试防御"这个说法同样适用，不会因为换了理由而改变。想继续的话，我可以帮你把第 3