1. 项目概述：当大语言模型成为操作系统级服务

最近在折腾一个本地知识库项目时，我遇到了一个典型困境：为了调用一个大语言模型来处理文档，我需要先启动一个模型服务进程，然后在应用代码里通过HTTP客户端去请求它。这本身没什么问题，但当我尝试把这个应用打包成Docker镜像，或者想在另一台没有GPU的机器上测试时，整个流程就变得异常繁琐。这让我开始思考一个更根本的问题：为什么我们调用一个模型，不能像调用一个本地文件读写函数那样直接、自然？为什么AI能力不能像操作系统的线程调度、内存管理一样，成为一种基础设施级别的服务？

这正是“将大语言模型嵌入为操作系统级API”这个想法吸引我的地方。它不是一个具体的工具或框架，而是一种设计范式的转变。简单来说，它主张将大语言模型的能力，通过操作系统内核或系统服务的方式暴露给上层所有应用程序，就像今天的进程可以通过系统调用（syscall）请求CPU时间、申请内存、读写文件一样。应用程序开发者无需关心模型在哪里运行、如何加载、用什么协议通信，他们只需要像调用 open() 或 malloc() 一样，调用一个类似 llm_inference() 的系统调用，传入提示词和参数，操作系统就会安全、高效地返回推理结果。

这个想法之所以被部分研究者视为“被忽视的AI安全与隐私网关”，是因为它从架构层面重构了AI能力的供给方式。在当前的“应用-模型服务”分离架构下，安全和隐私是附加的、事后补救的挑战。而当模型成为操作系统的一部分时，安全（如访问控制、输入输出审查）和隐私（如数据不出本地、计算过程受保护）可以成为从底层就被设计和保障的核心特性。这就像文件系统的权限管理是操作系统内核的功能，而不是每个应用程序自己再去实现一遍。

对于开发者、企业IT管理员乃至个人用户，理解并探索这一范式都具有现实意义。它意味着更简化的AI应用开发体验、更统一和强制的安全策略、以及从根本上杜绝敏感数据外流的可能性。虽然这听起来有些“未来感”，但其中的核心思想——即通过系统层抽象来管理关键且敏感的计算资源——在计算机发展史上已被反复验证是行之有效的路径。

2. 核心思路与架构价值解析

2.1 从“服务化”到“系统化”的范式迁移

当前，大语言模型的部署和使用主流是“服务化”范式。无论是云端托管的API（如OpenAI的接口），还是本地部署的模型服务（如通过 ollama 、 vLLM 或 TGI 启动的HTTP服务），模型都是一个独立的、网络可达的服务端点。应用程序通过HTTP、gRPC等网络协议与之交互。

这种范式有几个固有的痛点：

  1. 性能开销 ：即使模型和应用程序在同一台物理机上，网络栈（TCP/IP、HTTP解析）也会引入不必要的延迟和CPU开销。对于需要低延迟交互的应用（如实时翻译、代码补全），这是不可忽视的损耗。
  2. 资源管理复杂 ：每个模型服务进程独立管理自己的GPU内存、计算队列和生命周期。当多个应用需要调用同一个模型时，要么每个应用启动一个实例（浪费资源），要么共享一个服务端（需要复杂的连接池和负载均衡管理）。
  3. 安全边界模糊 ：应用程序通常需要将包含敏感信息的提示词明文发送给模型服务。即使服务在本地，也需要信任该服务进程不会泄露数据。安全策略（如哪些应用可以访问哪些模型）往往在应用层或网络层实现，缺乏统一的、内核级别的强制力。

“系统化”范式旨在解决这些问题。其核心思想是： 将大语言模型视为一种系统资源，由操作系统内核或一个特权系统服务进行统一管理、调度和提供 。类比一下：

  • CPU/内存是资源 -> 由操作系统内核通过系统调用（如 fork , mmap ）提供。
  • 文件是资源 -> 由文件系统驱动和VFS层通过系统调用（如 open , read , write ）提供。
  • 大语言模型也是资源 -> 应由一个“模型管理子系统”通过新的系统调用（如 llm_load , llm_prompt ）提供。

在这种架构下，应用程序对模型的调用，从“网络请求”降级为“本地函数调用”乃至“系统调用”，性能潜力巨大。更重要的是，安全和隐私控制可以下沉到系统调用层面。操作系统可以基于调用者的进程ID、用户ID、安全上下文等信息，实施强制访问控制（MAC），决定其是否有权使用某个模型，甚至可以对输入输出进行实时审查或脱敏。

2.2 作为安全与隐私“网关”的深层逻辑

为什么说这种架构是一个“被忽视的网关”？因为它在AI能力供给的入口处，天然地设立了一个检查点。

1. 统一的身份与权限管理： 在操作系统中，一切行为主体都是进程，而进程隶属于用户。当应用通过系统调用请求模型推理时，内核可以精确知道是“哪个用户的哪个进程”在发起请求。基于此，我们可以建立类似文件权限的模型访问控制列表（ACL）：

  • root 用户可以加载、卸载任何模型。
  • 用户 alice 可以运行 llama3 模型，但无法运行 gpt-4 级别的商用模型。
  • 来自沙盒环境的进程只能访问经过特殊审核的“安全模型”。 这种控制是全局的、强制的，应用程序无法绕过。这从根本上防止了恶意软件滥用本地AI能力。

2. 数据流的可控与可审计： 所有输入模型的提示词和模型输出的结果，都需要经过内核或特权服务传递。这提供了一个绝佳的拦截和审计点。

  • 隐私保护 ：可以植入“隐私过滤器”模块。例如，当检测到提示词中包含身份证号、银行卡号等模式时，自动将其替换为占位符，再发送给模型计算。确保原始敏感信息从未离开过受保护的内核空间或安全飞地（如Intel SGX, AMD SEV）。
  • 内容安全 ：同样，可以对模型的输出进行实时审查，过滤掉违反策略的内容（尽管这本身是个难题，但至少有了实施的可能）。
  • 审计日志 ：所有模型调用都可以被内核审计子系统记录，形成不可篡改的日志，便于事后追溯和合规检查。

3. 计算环境的隔离： 操作系统可以利用现有的硬件虚拟化或容器隔离技术，为模型推理创造一个安全的执行环境。模型权重和中间计算过程可以被隔离在一个受保护的内存区域，即使宿主操作系统被攻破，攻击者也难以提取模型权重或窥探推理数据。这对于保护企业专有模型或处理医疗、金融等敏感数据的场景至关重要。

注意 ：将模型嵌入操作系统层，并不意味着要把数十GB的模型参数塞进内核。更可行的设计是，模型权重以“只读”或“加密”的形式存储在持久化介质上，由一个运行在用户态但具有特权的“模型守护进程”管理。内核只负责提供安全的通信通道（如特殊的进程间通信机制IPC）和强制访问控制。这个守护进程与内核紧密协作，共同构成“模型子系统”。

3. 实现路径与关键技术点探讨

将这一构想落地，需要跨越从系统设计到具体实现的多个层次。这里我们探讨一条可能的渐进式路径和涉及的关键技术。

3.1 渐进式实现的三层架构

一个稳健的实现不会一蹴而就地修改内核，而是可以采用分层架构，逐步深化集成。

第一层：用户态系统服务（模型守护进程） 这是最容易实现的起点。我们创建一个以 root 权限运行的系统守护进程（例如 llmd ），它独占GPU资源，负责加载和管理模型。应用程序通过一个本地Unix Domain Socket（或更高效的如 io_uring ）与这个守护进程通信。守护进程实现简单的权限检查（基于连接进程的UID/GID）。这本质上还是一个C/S架构，但通信换成了本地IPC，去除了网络栈开销，并且有了一个统一的控制点。许多现有的本地模型服务软件（如 ollama ）可以看作是这个模式的雏形，但它们缺乏系统级的集成和强制安全策略。

第二层：内核模块与虚拟设备驱动 为了更彻底的安全控制和性能优化，我们可以引入内核模块。思路是将大语言模型推理抽象为一个 虚拟字符设备 （如 /dev/llm0 ）。应用程序像读写文件一样，通过 open 、 ioctl 、 mmap 等系统调用与这个设备交互。

  • open(“/dev/llm/llama3”, O_RDONLY) ：请求打开（加载） llama3 模型。
  • ioctl(fd, LLM_IOCTL_PROMPT, &prompt_struct) ：发送一个推理请求。
  • 通过 mmap 将模型输出映射到用户空间，实现零拷贝数据传输。 内核模块负责：
  1. 权限验证（检查进程是否有权访问该设备文件）。
  2. 将请求转发给用户态的 llmd 守护进程（通过内核与用户态之间的特殊接口）。
  3. 管理 llmd 守护进程的生命周期和资源隔离。 这一层将安全控制从用户态提升到了内核态，实现了真正的强制访问控制。

第三层：专用系统调用与硬件集成 这是最深入的集成层次。操作系统内核定义一组全新的系统调用，例如：

  • sys_llm_load(const char* model_id, int flags)
  • sys_llm_prompt(int handle, const struct llm_prompt* prompt, struct llm_result* result) 内核直接管理模型元数据、调度推理请求到可用的硬件（GPU、NPU）。这需要内核包含一个轻量级的运行时调度器，并能与厂商的驱动深度交互。同时，可以借助现代CPU的机密计算技术（如Intel TDX, AMD SEV-SNP），在硬件加密的安全飞地（TEE）中执行整个推理流程，确保即使云服务商也无法窥探模型和数据。

3.2 核心挑战与应对思路

挑战一：内核的稳定与安全 内核是系统的基石，其代码必须极度稳定和安全。将复杂的AI推理运行时（如PyTorch、TensorFlow）放入内核是不可想象的。因此，必须坚持 微内核思想 ：内核只做最核心的调度、通信和访问控制，复杂的模型加载、计算图优化、算子执行等任务，交给一个或多个运行在用户态或硬件安全飞地中的“模型服务进程”。内核通过定义良好的、安全的IPC机制与它们交互。

挑战二：异构硬件的支持 AI加速硬件百花齐放（NVIDIA GPU, AMD GPU, Intel GPU, 各种NPU）。操作系统级的API必须抽象出一个统一的设备层。可以借鉴Linux的 DRM（Direct Rendering Manager） 和 Compute Accelerator 框架的思路，为AI加速器定义标准的内核接口。硬件厂商提供符合该接口的驱动，将设备注册到系统的“AI加速器池”中。模型子系统从这个池中按需分配资源。

挑战三：动态性与资源管理 模型可能很大（数十GB），无法常驻内存。需要实现类似虚拟内存的“模型换入换出”机制。内核需要根据模型的“热度”和可用GPU内存，智能地决定哪些模型权重保留在GPU显存，哪些被换出到主机内存甚至NVMe SSD。这涉及到复杂的缓存算法和预取策略。

挑战四：生态系统与兼容性 如何让现有的AI应用（基于PyTorch、Transformers库开发）无缝迁移？一个可行的方案是提供 兼容层库 。例如，提供一个 libllm 用户态库，它实现了PyTorch或Hugging Face transformers 的部分前端接口，但底层通过系统调用与内核的模型子系统通信。这样，开发者只需链接这个库，少量修改甚至不修改代码，就能将应用从传统的服务调用模式切换到系统调用模式。

4. 原型设计与实操模拟

为了更具体地理解，我们设计一个在Linux系统上的简化原型。这个原型位于上述“三层架构”的第一层与第二层之间，旨在验证核心概念。

4.1 环境与工具准备

我们假设在一个安装了NVIDIA GPU和CUDA的Ubuntu Linux系统上进行实验。需要以下工具和库：

  • CUDA Toolkit & cuDNN ：用于GPU推理。
  • 一个轻量级LLM推理引擎 ：例如 llama.cpp （GGUF格式模型）或 TensorRT-LLM 。它们提供C++ API，易于集成。
  • Linux内核头文件与开发工具 ：用于编译内核模块。
  • 一个简单的模型 ：例如 Qwen2.5-1.5B-Instruct 的GGUF量化版，体积小，适合实验。

我们的目标不是实现完整的生产系统，而是搭建一个概念验证（PoC），包含以下组件：

  1. 一个虚拟字符设备驱动（内核模块）。
  2. 一个用户态模型守护进程（ llmd ）。
  3. 一个测试用的客户端程序。

4.2 内核模块：虚拟设备驱动

首先，我们创建一个内核模块 llm_dev.ko ，它注册一个字符设备。

// llm_dev.c (简化示例)
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/uaccess.h>
#include <linux/slab.h>

#define DEVICE_NAME "llm"
#define MAX_MINORS 8 // 支持最多8个模型实例

static int major_num;
static struct class* llm_class = NULL;
static struct cdev llm_cdev;

// 当用户态程序打开设备文件时调用
static int llm_open(struct inode *inode, struct file *file) {
    int minor = iminor(inode);
    printk(KERN_INFO "llm: Device opened for model slot %d by process %d\n", minor, current->pid);
    // 这里可以添加基于 current->pid/uid 的权限检查
    return 0;
}

// 处理ioctl命令
static long llm_ioctl(struct file *file, unsigned int cmd, unsigned long arg) {
    switch(cmd) {
        case LLM_LOAD_MODEL: {
            // 从用户空间拷贝模型路径等信息
            // 然后通过 netlink 或其他IPC通知用户态守护进程加载模型
            break;
        }
        case LLM_SUBMIT_PROMPT: {
            // 将提示词转发给用户态守护进程，并等待结果
            break;
        }
        default:
            return -ENOTTY;
    }
    return 0;
}

static struct file_operations fops = {
    .owner = THIS_MODULE,
    .open = llm_open,
    .unlocked_ioctl = llm_ioctl,
    // 可能还需要实现 mmap, poll 等
};

static int __init llm_init(void) {
    // 动态申请主设备号
    major_num = register_chrdev(0, DEVICE_NAME, &fops);
    // 创建设备类和在/dev下创建设备节点，例如 /dev/llm0, /dev/llm1
    llm_class = class_create(THIS_MODULE, DEVICE_NAME);
    for (int i = 0; i < MAX_MINORS; i++) {
        device_create(llm_class, NULL, MKDEV(major_num, i), NULL, "llm%d", i);
    }
    printk(KERN_INFO "llm: Character device registered with major %d\n", major_num);
    return 0;
}

static void __exit llm_exit(void) {
    for (int i = 0; i < MAX_MINORS; i++) {
        device_destroy(llm_class, MKDEV(major_num, i));
    }
    class_destroy(llm_class);
    unregister_chrdev(major_num, DEVICE_NAME);
    printk(KERN_INFO "llm: Module unloaded\n");
}

module_init(llm_init);
module_exit(llm_exit);

这个模块创建了 /dev/llm0 到 /dev/llm7 的设备文件。用户态程序通过 open 打开这些文件，通过 ioctl 发送命令。内核模块在这里充当了一个安全的“接线员”，它验证权限，并将具体的负载工作通过进程间通信（IPC）转发给用户态守护进程。我们选择使用 Netlink 套接字作为IPC机制，因为它专为内核与用户态通信设计，比 ioctl 传递大量数据更灵活高效。

4.3 用户态守护进程 (llmd)

llmd 是一个特权进程（通常以 root 或特定系统用户运行），它完成繁重的实际工作：

  1. 监听Netlink套接字 ：接收来自内核模块的指令（如 LOAD_MODEL , RUN_PROMPT ）。
  2. 管理模型生命周期 ：根据指令加载GGUF模型文件到GPU内存，维护一个模型句柄池。
  3. 执行推理 ：调用 llama.cpp 的C API执行实际的提示词补全。
  4. 返回结果 ：将推理结果通过Netlink发回给内核模块，再由内核模块拷贝到用户态客户端的内存空间。
// llmd.c (核心逻辑片段)
#include <linux/netlink.h>
#include <stdio.h>
#include <string.h>
// 假设的 llama.cpp 简化头文件
#include “llama.h”

struct llm_model_pool {
    int slot_id;
    struct llama_model* model;
    struct llama_context* ctx;
} model_pool[MAX_MINORS];

void handle_kernel_request(struct nlmsghdr *nlh) {
    struct llm_req *req = NLMSG_DATA(nlh);
    switch(req->cmd) {
        case LLM_LOAD_MODEL: {
            int slot = req->slot;
            const char* path = req->data;
            // 加载模型到 GPU
            model_pool[slot].model = llama_load_model_from_file(path, /* params */);
            model_pool[slot].ctx = llama_new_context_with_model(model_pool[slot].model, /* ctx params */);
            // 发送加载成功应答回内核
            send_ack_to_kernel(slot, SUCCESS);
            break;
        }
        case LLM_SUBMIT_PROMPT: {
            int slot = req->slot;
            char* prompt = req->data;
            // 使用llama.cpp进行推理
            llama_tokenize(model_pool[slot].ctx, prompt, ...);
            llama_completion(model_pool[slot].ctx, ...);
            char* output = llama_get_output(model_pool[slot].ctx);
            // 将output通过Netlink发送回内核
            send_result_to_kernel(slot, output);
            break;
        }
    }
}

int main() {
    // 创建Netlink套接字，绑定到自定义协议号
    // 进入事件循环，监听内核请求
    while(1) {
        receive_from_kernel(&nlh);
        handle_kernel_request(&nlh);
    }
    return 0;
}

4.4 客户端应用示例

一个简单的客户端程序看起来会非常直观：

// client.c
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <string.h>
#include <unistd.h>

#define LLM_DEVICE “/dev/llm0”
#define LLM_LOAD_MODEL _IOW(‘L’, 1, char[256])
#define LLM_SUBMIT_PROMPT _IOWR(‘L’, 2, struct llm_prompt_req)

struct llm_prompt_req {
    char prompt[1024];
    char result[4096];
};

int main() {
    int fd = open(LLM_DEVICE, O_RDWR);
    if (fd < 0) { perror(“open”); return 1; }

    // 1. 加载模型
    char model_path[] = “/opt/models/qwen2.5-1.5b-instruct-q4.gguf”;
    if (ioctl(fd, LLM_LOAD_MODEL, model_path) < 0) {
        perror(“ioctl LOAD_MODEL”); close(fd); return 1;
    }

    // 2. 提交提示词
    struct llm_prompt_req req;
    snprintf(req.prompt, sizeof(req.prompt), “Translate ‘Hello, world’ to French.”);
    if (ioctl(fd, LLM_SUBMIT_PROMPT, &req) < 0) {
        perror(“ioctl SUBMIT_PROMPT”); close(fd); return 1;
    }

    printf(“Model replied: %s\n”, req.result);
    close(fd);
    return 0;
}

这个客户端程序完全不知道模型在哪里运行、如何加载。它只是与一个标准的设备文件交互。所有的安全检查和资源调度，都发生在这个 ioctl 调用之下，由内核和 llmd 守护进程协作完成。

实操心得 ：在实现这个PoC时，最大的挑战在于内核态与用户态之间高效、安全地传递数据（尤其是模型输出可能很长）。Netlink适合传递控制消息，但对于大块数据，更好的方式是让内核模块分配一块内核内存，将其映射（ mmap ）到客户端进程的用户空间。 llmd 将推理结果写入这块内存，客户端可以直接读取。这实现了零拷贝，性能最优。但这需要仔细设计同步机制（如信号量），防止读写竞争。

5. 潜在问题、挑战与演进思考

即使实现了上述原型，距离一个成熟可用的操作系统级LLM API还有很长的路，会面临一系列深刻挑战。

5.1 性能与并发调度

问题 ：操作系统内核的调度器是为CPU任务设计的，其调度单元是线程/进程，考虑的是时间片、优先级、I/O等待。而LLM推理是 计算密集 且 内存带宽密集 型任务，并且对延迟有不同要求（有的需要流式输出，有的可以批处理）。如何在内核中设计一个高效的“AI任务调度器”？

思路 ：

  1. 异构调度 ：需要扩展调度器，使其能感知GPU/NPU等设备。调度器不仅要分配CPU时间，还要分配GPU计算流、显存带宽和显存空间。这需要与设备驱动深度整合。
  2. 请求批处理与流式响应 ：内核的模型子系统应该具备将来自多个进程的、请求同一模型的提示词动态批处理（Dynamic Batching）的能力，以最大化GPU利用率。同时，对于流式输出需求，内核需要支持将模型生成的token实时地、增量地推送给客户端进程，而不是等待全部生成完毕。这要求设备驱动和IPC机制都支持类似“管道”的能力。
  3. 服务质量（QoS） ：系统需要能区分不同请求的优先级。例如，交互式对话应用的请求应该比后台批量文档处理的请求拥有更高的优先级，获得更低的延迟。

5.2 安全模型的深度集成

问题 ：前面提到了内核可以进行权限检查，但AI安全远不止“谁能访问”。还包括：提示词注入防护、输出内容过滤、训练数据泄露防范、模型权重防盗等。

思路 ：

  1. 可插拔的安全钩子（Security Hooks） ：在模型子系统的关键路径上（如 llm_prompt 系统调用入口、结果返回前）设置钩子函数。安全模块（可以是独立的内核模块，如 llm_security ）可以注册到这些钩子上，对输入输出进行实时扫描和过滤。这类似于Linux的LSM（Linux Security Modules）框架。
  2. 基于机密计算的推理飞地 ：最彻底的安全方案是利用CPU的TEE技术。内核在调度一个推理任务时，可以将其分配给一个在硬件加密飞地中运行的“可信模型服务”。飞地内的代码和数据（包括模型权重和输入数据）对外部（包括内核和root用户）完全不可见。这为隐私计算提供了硬件级保障。但这需要AI推理框架（如 llama.cpp ）能够被编译并在受限的飞地环境中运行，挑战巨大。
  3. 模型水印与溯源 ：系统可以在模型输出中，以不可察觉的方式嵌入调用者ID、时间戳等水印信息。一旦模型输出被不当泄露，可以追溯源头。

5.3 生态兼容与开发者体验

问题 ：如何让数百万现有的、基于Python和高级AI框架（PyTorch, TensorFlow, JAX）开发的应用程序，平滑地迁移到这套新的系统API上？

思路 ：

  1. 提供兼容性动态库 ：如前所述，开发一个 libllm 库，它实现PyTorch的 nn.Module 或Hugging Face transformers 的 PreTrainedModel 的部分接口。当应用调用 model.generate(input_ids) 时， libllm 在底层将其转换为对 llm_prompt 系统调用的封装。对于许多应用，可能只需更换模型加载行，或设置一个环境变量指向这个兼容库。
  2. 标准化中间表示（IR） ：操作系统模型子系统可以定义一种中立的、高效的模型表示格式（类似于ONNX，但更底层）。各大AI框架负责将模型编译到此格式。这样，子系统只需维护一个针对该IR的优化运行时，而不需要支持所有前端框架。这降低了内核的复杂性。
  3. 丰富的工具链 ：需要配套的命令行工具来管理系统中的模型，例如 llmctl list （列出已加载模型）、 llmctl load /path/to/model （加载模型）、 llmctl grant user alice access llama3 （授权用户访问模型）。这些工具是良好用户体验的关键。

5.4 对现有操作系统设计的冲击

问题 ：这不仅仅是增加几个系统调用。它可能深刻改变操作系统的资源视图、安全模型和编程范式。

演进思考 ：

  • 资源视图 ：操作系统需要从只管理CPU、内存、I/O设备，扩展到管理“模型”这种新型的一等公民资源。 top 和 htop 命令可能需要增加一列显示GPU显存占用和模型推理队列长度。
  • 安全模型 ：传统的自主访问控制（DAC）和基于角色的访问控制（RBAC）可能不够用。可能需要引入基于属性的访问控制（ABAC），例如“只有来自安装了最新安全补丁的容器镜像的进程，才能访问财务摘要模型”。
  • 编程范式 ：异步和非阻塞编程将更加重要。 llm_prompt 系统调用很可能立即返回一个未来句柄（future handle），应用程序通过 poll 或类似 io_uring 的完成队列来获取结果，以避免阻塞整个线程。

将大语言模型嵌入为操作系统级API，是一个从“应用层功能”到“系统层基础设施”的升维思考。它通过将AI能力内化为系统的核心服务，为解决安全、隐私、性能和易用性难题提供了一个统一且强大的框架。虽然前路充满工程挑战，但每一次计算范式的重大进步，无论是虚拟内存、网络栈还是图形界面，都伴随着操作系统层面的深度支持。AI普及的下一站，或许真的就在操作系统内核之中。对于开发者和系统架构师而言，现在开始关注和思考这一方向，或许能让我们在下一波技术浪潮中占据先机。

# 操作系统
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

数字人交互源码：一体机私有化部署方案

avatar AI Agent技术社区

AI Agent 30天速成｜Day5 笔记

摘要Prompt强制要求保留数字、订单、计算结果、工具参数等关键信息工具调用记录不参与摘要，永久保留在短期记忆压缩后保留最少2轮原始对话，避免完全依赖摘要导致信息缺失。

avatar AI Agent技术社区
cover

15种AI Agent设计模式，做Agent的人迟早都要用上

avatar AI Agent技术社区