企业官网建设流程全解析

1. 项目概述：这不是写个“智能体循环”，而是在重演操作系统内核的诞生逻辑

“从零写出DSH内核——第八篇：AgentLoop（Agent驱动）”这个标题，乍看像是一篇技术博客的普通连载，但如果你在底层系统、AI工程或自主智能体架构领域摸爬滚打过几年，就会立刻意识到：它背后站着一个极其危险又极其诱人的命题——把大模型的推理能力，嵌进操作系统的血液里，让它像进程调度器一样呼吸、等待、唤醒、抢占、协作。不是调用API，不是封装接口，而是让LLM成为内核可感知、可管理、可中断、可审计的一等公民。这已经远远超出了“AI Agent开发”的范畴，直指“认知操作系统”（Cognitive OS）的雏形。

我第一次看到这个标题时，手边正调试一个卡在context长度瓶颈上的多跳任务系统。当时的想法很朴素：能不能让模型自己决定“现在该不该继续思考？要不要查资料？要不要切到另一个子任务？”——结果发现，所有现有框架都在应用层打补丁：LangChain的Executor、LlamaIndex的QueryEngine、甚至自研的StateMachine，全都是在用户态模拟“循环”，一旦遇到IO阻塞、资源争用或策略变更，整个流程就僵死在Python线程里，连个信号都收不到。而DSH内核的AgentLoop，恰恰是从最底层撕开了一道口子：它把“思考”定义为一种新型的可调度实体（schedulable entity），把“提示词工程”翻译成内核态的上下文切换指令，把“工具调用”抽象为受控的系统调用（syscall）门禁。你不需要再写while not done: step = agent.think(); if step.is_tool(): call_tool()这种脆弱的胶水代码；你只需要注册一个Agent描述符，内核就会像调度一个POSIX线程那样，在合适的时机把它拉起来、喂数据、等响应、存状态、切出去——整个过程对上层完全透明。

这个设计解决的绝不是“怎么让AI更聪明”的问题，而是“怎么让AI在真实复杂系统中活下来”的生存问题。它面向的不是算法研究员，而是那些天天和OOM、deadlock、race condition搏斗的系统工程师；不是追求SOTA指标的博士生，而是要给工业质检机器人写稳定控制逻辑的嵌入式开发者。它要求你同时理解LLM的token流特性、Linux的CFS调度器原理、Rust的ownership模型，以及——最关键的——如何让一个概率性、非确定性的大模型，在一个确定性、强约束的内核环境中，不崩、不漏、不骗人。所以这篇内容，本质上是一份认知计算时代的内核移植手册：它告诉你，当“思考”成为一种基础资源，操作系统该长什么样子。

2. 核心设计思路拆解：为什么必须是“Loop”，而不是“Chain”或“Graph”

2.1 从应用层胶水到内核原语：一次范式迁移的必然性

几乎所有主流Agent框架（AutoGen、Microsoft Semantic Kernel、OpenAGI）都采用“Chain-of-Thought + Tool Calling”的链式结构。它的典型流程是：用户输入 → LLM生成Thought → 解析Thought中的Tool Call → 执行Tool → 获取Result → 拼回Prompt → 再次LLM生成 → …… 循环往复。这个模式在demo场景下流畅得像德芙，但一落地就暴露三大结构性缺陷：

• 状态不可见性：整个循环的中间状态（当前思考深度、已调用工具列表、失败重试次数、资源消耗计数）全部散落在Python对象的属性里，内核无从感知。当系统内存告急时，你无法像kill一个失控进程那样，优雅地暂停一个正在疯狂生成token的Agent；你只能粗暴地os.kill()整个Python进程，连最后的上下文快照都留不下。

• 调度不可控性：链式执行是单线程阻塞的。LLM推理（哪怕本地部署）本质是GPU密集型IO等待，期间CPU空转；而Tool调用（如数据库查询、HTTP请求）又是网络IO等待，期间GPU闲置。现有框架无法像内核调度器那样，在LLM等待GPU kernel返回时，把CPU时间片切给另一个等待网络响应的Agent——它们被死死锁在同一个Python线程栈里。

• 安全不可审计性：Tool调用是通过字符串解析动态dispatch的，if "search" in thought: call_search_api()。这种模式无法做静态权限检查。你无法在编译期或加载期声明：“此Agent仅允许调用/api/v1/files/read，且每次读取不超过1MB”，因为调用路径是运行时动态拼接的。

DSH内核的AgentLoop，正是为根除这三大缺陷而生。它把“Agent执行”从一个应用层的控制流（Control Flow），升格为内核层的数据流（Data Flow）。具体来说，它引入了三个核心原语：

1. Agent Descriptor（AD）：一个结构化配置，声明Agent的身份（UID）、能力集（允许的Syscall列表）、资源配额（最大token数、最长执行时间、内存上限）、初始上下文（system prompt + initial memory）。它被加载进内核的agent_table，像task_struct之于进程。

2. Agent Context Switch（ACS）：当Agent需要“思考”时，它不直接调用LLM，而是触发一个特殊的sys_agent_think()系统调用。内核捕获该调用，保存当前CPU寄存器、GPU context（通过CUDA Stream同步点）、以及Agent私有内存页表，然后根据调度策略（如优先级+公平性）选择下一个可运行的Agent，恢复其上下文——整个过程与context_switch()函数逻辑同构。

3. Controlled Syscall Gate（CSG）：Agent的任何外部交互（文件读写、网络请求、数据库查询）都必须通过预定义的Syscall接口。内核在sys_call_table中为每个Agent Descriptor维护一个白名单，只有匹配的syscall号+参数签名才被放行。例如，sys_file_read(ad_id, fd, buf, count)会先校验ad_id对应的Descriptor是否授权了file_read能力，且count < ad.quota.max_read_size，否则直接返回EPERM。

提示：这种设计不是为了炫技，而是为了构建“可验证的智能”。当你能像审计open()系统调用那样审计sys_tool_search()，你就拥有了对AI行为进行形式化验证的基础。这是通往可信AI的必经之路。

2.2 Loop的本质：一个事件驱动的状态机，而非无限递归

很多人误以为“AgentLoop”就是while True: think(); act();。这是致命误解。真正的AgentLoop，是一个由内核事件驱动的有限状态机（FSM），其状态转换完全由外部事件触发，而非内部逻辑决定。DSH内核定义了五个核心状态：

关键洞察在于：Loop的“循环”感，来自内核调度器的周期性tick，而非Agent代码里的while。Agent本身是无状态的——它没有while循环，没有for迭代，它只是一组被动响应事件的handler。当它处于THINKING状态时，内核在后台监控GPU的SM occupancy；一旦检测到kernel launch完成且output buffer有新token，就自动触发状态迁移至WAITING_IO。整个过程对Agent代码完全透明，它只需关心“我收到了什么输入”和“我应该输出什么token”，其余全是内核的事。

这种解耦带来的好处是颠覆性的。你可以用同一个Agent Descriptor，在不同硬件上跑出完全不同的性能曲线：在A100上，THINKING状态可能持续200ms（高吞吐）；在Jetson Orin上，它可能被拆成10次短THINKING（低延迟），每次只生成16个token，然后立刻切走——而这一切，无需修改Agent一行代码，只需调整内核调度器的think_quantum参数。这才是真正意义上的“Write Once, Run Anywhere”。

2.3 为什么选Rust而非C？所有权模型是AI安全的基石

DSH内核选择Rust作为实现语言，绝非跟风。在AgentLoop这个场景下，Rust的ownership和borrow checker提供了C语言根本无法企及的安全保障，直击AI系统最脆弱的环节：内存安全与并发安全。

想象一个经典漏洞：Agent在THINKING状态时，LLM生成了一个恶意tool call，比如{"tool": "file_write", "args": {"path": "/etc/passwd", "content": "root:x:0:0:root:/root:/bin/bash:/usr/bin/python3"}}。如果内核用C实现，sys_file_write()函数需要从Agent的私有内存区读取path和content字符串。一个微小的越界读（off-by-one）或use-after-free，就可能导致内核直接崩溃，或者更糟——被利用来提权。而Rust的编译器强制要求：任何对Agent内存的访问，都必须通过一个&AgentMemory引用，且该引用的生命周期（lifetime）被严格绑定到当前syscall的执行上下文中。一旦sys_file_write()函数返回，引用自动失效，后续任何尝试访问都将被编译器拦截。

更精妙的是Arc<Mutex<AgentState>>的运用。Agent的全局状态（如execution_count,total_token_used）需要被多个内核线程（调度器、IO子系统、监控模块）并发读写。在C中，这需要手动加spinlock或rwlock，极易因疏忽导致deadlock。而在Rust中，Arc（原子引用计数）确保状态对象的生命周期由引用数自动管理，Mutex则提供线程安全的互斥访问——且这一切都在编译期验证。你无法写出“忘记unlock”的代码，因为MutexGuard的Droptrait会在作用域结束时自动释放锁。

注意：这不是理论优势。我们在某次压力测试中，故意注入了10万次并发的sys_agent_think()调用，C版本内核在第3721次调用时因task_struct链表指针被覆盖而panic；而Rust版本稳定运行了72小时，dmesg日志里只有干净的[INFO] Agent 0x1a2b: state transition READY -> THINKING。编译器的静态检查，真的救了命。

3. 核心细节与实操要点：从概念到可运行代码的关键跨越

3.1 Agent Descriptor的二进制格式与加载机制

Agent Descriptor（AD）是AgentLoop的“身份证”，其设计必须兼顾内核效率与用户易用性。DSH内核采用了一种混合格式：文本配置（YAML）用于开发，二进制blob（BLOB）用于运行时加载。这种分离避免了内核中解析YAML的复杂性，同时保留了人类可读性。

一个典型的AD YAML如下：

# agent_web_research.yaml metadata: name: "web_researcher" version: "1.0.0" author: "dev_team" spec: # 能力白名单：只允许调用这些Syscall capabilities: - syscall: "sys_http_get" params: ["url", "timeout_ms"] limits: {max_url_len: 2048, max_timeout_ms: 30000} - syscall: "sys_llm_think" params: ["prompt", "max_tokens"] limits: {max_prompt_len: 4096, max_tokens: 512} # 资源硬限制 resources: cpu_time_ns: 3000000000 # 3秒CPU时间 gpu_mem_mb: 2048 # 2GB GPU显存 ram_mb: 1024 # 1GB系统内存 # 初始上下文 context: system_prompt: | You are a web research assistant. Your goal is to answer user questions by searching the web. Always cite sources. Never hallucinate. initial_memory: []

这个YAML文件会被专用工具dsh-adgen编译成一个紧凑的二进制BLOB（约2KB），其内存布局严格对齐：

[0x00] u32 magic (0xD5H5A7E) // 魔数，校验完整性 [0x04] u32 version // AD版本号 [0x08] u64 name_hash // name的FNV-1a哈希，用于O(1)查找 [0x10] u32 cap_count // 能力条目数 [0x14] u32 cap_offset // 能力数组偏移（相对于BLOB起始） [0x18] u32 ctx_offset // 上下文数据偏移 [0x1C] u32 reserved[4] // 保留字段，供未来扩展 [0x2C] [cap_count * 32] bytes // 能力数组：每项含syscall_id, param_mask, limit_struct [0x??] [ctx_data] // system_prompt + initial_memory的序列化数据

加载过程由内核函数load_agent_descriptor()完成：

1. 用户空间通过ioctl(fd, DSH_IOC_LOAD_AD, &blob_ptr)传递BLOB地址；
2. 内核使用copy_from_user()安全拷贝BLOB到内核空间临时缓冲区；
3. 校验magic和version，解析cap_count，分配struct agent_desc内存；
4. 关键步骤：遍历能力数组，对每个syscall_id，调用register_syscall_hook(syscall_id, ad_id)，在内核的syscall_gate中为该AD建立专属钩子；
5. 将struct agent_desc*插入全局agent_table[ad_id % AGENT_TABLE_SIZE]哈希桶；
6. 返回ad_id（一个32位整数），供后续sys_agent_think(ad_id)调用。

实操心得：dsh-adgen工具必须内置严格的语法检查。我们曾因一个YAML缩进错误，导致cap_count被解析为0xFFFFFFFF，内核在遍历能力数组时直接越界访问，触发了BUG_ON()。后来在dsh-adgen中加入了--validate模式，它会模拟内核加载流程，提前报错。这个教训告诉我们：Agent Descriptor的编译期验证，比运行时防御更重要。

3.2 Agent Context Switch的GPU-aware实现

传统OS的context_switch()只处理CPU寄存器（r15-r12,rbp,rbx,r8-r11）和页表基址（CR3）。AgentLoop的ACS必须额外处理GPU上下文，这是性能瓶颈所在。DSH内核针对NVIDIA GPU，实现了基于CUDA Stream的轻量级上下文切换：

• GPU Context = CUDA Stream + Memory Pool：每个Agent Descriptor关联一个独立的cudaStream_t和一个cudaMemPool_t。cudaStream确保Agent的LLM推理kernel按序执行；cudaMemPool则隔离其GPU显存，防止一个Agent的OOM影响其他Agent。

• Switch Out（保存）：

  1. 调用cudaStreamSynchronize(stream)，等待当前所有kernel完成；
  2. 调用cudaMemPoolExportToShareableHandle(&handle, pool, cudaMemHandleTypePosixFileDescriptor, 0)，导出一个可共享的句柄（实际是/dev/nvidia-uvm的fd）；
  3. 将stream、handle、current_token_pos（当前LLM输出buffer的写入位置）打包进agent_context结构体，存入内核内存。

• Switch In（恢复）：

  1. 从agent_context中取出handle，调用cudaMemPoolImportFromShareableHandle(&imported_pool, handle, cudaMemHandleTypePosixFileDescriptor, 0)，重建内存池；
  2. 创建新的cudaStream_t，并将其绑定到imported_pool；
  3. 将current_token_pos作为llama_eval()的n_past参数传入，确保LLM从上次中断处继续生成。

这个方案的精妙之处在于：它避开了代价高昂的GPU显存拷贝（cudaMemcpy）。cudaMemPoolExport/Import只是交换内存池的元数据，毫秒级完成。实测数据显示，在A100上，一次完整的ACS（CPU+GPU）耗时稳定在12.7±0.3μs，而纯CPU的context_switch()是0.8μs。这意味着GPU上下文切换的开销，被控制在了CPU切换的15倍以内——对于一个需要频繁IO等待的Agent，这个代价完全可以接受。

注意：此方案依赖CUDA 11.7+的cudaMemPoolAPI。如果你的环境是旧版CUDA或AMD GPU，DSH内核提供了降级模式：使用cudaMallocAsync()配合cudaStreamCreateWithFlags(CU_STREAM_NON_BLOCKING)，虽然无法完全避免显存碎片，但保证了功能正确性。

3.3 Controlled Syscall Gate的权限模型与审计日志

CSG是AgentLoop的安全心脏。它不是一个简单的if-else白名单检查，而是一个分层的、可审计的权限控制系统。DSH内核的CSG包含三个层级：

1. Descriptor-Level Whitelist（描述符级白名单）：最外层。sys_agent_think(ad_id)被调用时，内核首先查agent_table[ad_id]，获取其capabilities数组。如果请求的syscall_id不在数组中，立即返回EPERM。这是最快的失败路径。

2. Parameter-Level Validation（参数级校验）：通过白名单后，进入参数校验。以sys_http_get(ad_id, url_ptr, timeout_ms)为例：

   • copy_from_user()安全拷贝url字符串到内核缓冲区；
   • 检查strlen(url) <= ad.capabilities[i].limits.max_url_len；
   • 使用memchr()扫描url中是否包含非法字符（如../、%00），防止路径遍历；
   • 校验timeout_ms是否在[100, ad.capabilities[i].limits.max_timeout_ms]范围内。

3. Runtime Quota Enforcement（运行时配额强制）：最内层。每次成功执行一个Syscall，内核更新Agent的实时配额：

   // 在sys_http_get()末尾 let http_cost = estimate_http_cost(url, timeout_ms); // 基于URL长度、超时值估算 if ad.stats.total_network_cost.fetch_add(http_cost, Ordering::Relaxed) > ad.spec.resources.network_quota_mb { // 配额超限，记录审计日志，返回ENOSPC audit_log!(ad_id, "NETWORK_QUOTA_EXCEEDED", http_cost); return -ENOSPC; }

所有CSG的调用，无论成功或失败，都会生成一条结构化审计日志，写入内核环形缓冲区（log_buf）：

[2024-06-15T14:23:45.123Z] AD=0x1a2b SYSCALL=sys_http_get STATUS=SUCCESS URL_LEN=42 TIMEOUT_MS=5000 COST_KB=12.4 [2024-06-15T14:23:45.124Z] AD=0x1a2b SYSCALL=sys_llm_think STATUS=FAILURE REASON=GPU_OOM TOKENS_USED=482 MAX=512

这些日志可通过dmesg -t | grep "AD="实时查看，也可由用户空间守护进程dsh-auditd持续消费，写入ELK或Prometheus。我们曾用这套日志定位了一个隐蔽bug：某个Agent在THINKING状态时，因prompt中混入了不可见的Unicode字符，导致LLM tokenizer异常，反复重试sys_llm_think()，最终耗尽了GPU显存配额。日志清晰地显示了连续17次STATUS=FAILURE REASON=GPU_OOM，为排查节省了数小时。

4. 完整实操流程：从零构建一个可运行的Web Research Agent

4.1 环境准备与内核模块编译

DSH内核是一个可加载的Linux内核模块（.ko文件），而非独立内核。这极大降低了实验门槛。以下是详细步骤（基于Ubuntu 22.04 LTS, Kernel 5.15）：

步骤1：安装依赖

sudo apt update sudo apt install -y build-essential linux-headers-$(uname -r) \ libssl-dev libelf-dev libdw-dev zlib1g-dev \ python3-pip curl git # 安装Rust工具链（必须1.70+） curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y source $HOME/.cargo/env rustc --version # 应输出 rustc 1.70.0 or later

步骤2：获取DSH内核源码

git clone https://github.com/dsh-os/dsh-kernel.git cd dsh-kernel git checkout v0.8.0-agentloop # 确保检出第八篇对应版本

步骤3：配置与编译DSH内核使用Kbuild系统，但增加了Rust支持。编译前需配置：

# 生成默认配置 make defconfig # 启用AgentLoop相关选项（编辑 .config） # CONFIG_DSH_AGENTLOOP=y # CONFIG_DSH_SYSCALL_GATE=y # CONFIG_DSH_GPU_SUPPORT=y # CONFIG_DSH_CUDA_BACKEND=y # 保存后编译 make -j$(nproc) # 编译完成后，生成 dsh_kern.ko ls -lh dsh_kern.ko # -rw-r--r-- 1 user user 1.2M Jun 15 14:20 dsh_kern.ko

步骤4：加载内核模块

# 加载模块（需root） sudo insmod dsh_kern.ko # 检查是否加载成功 sudo dmesg | tail -5 # 应看到：[ 1234.567890] DSH Kernel v0.8.0 loaded. AgentLoop ready. # 创建设备节点 sudo mknod /dev/dsh0 c 240 0 sudo chmod 600 /dev/dsh0

提示：首次加载可能触发modprobe警告，忽略即可。关键看dmesg输出是否包含AgentLoop ready.。如果失败，请检查CONFIG_DSH_*是否全部启用，并确认CUDA驱动已正确安装（nvidia-smi应能正常工作）。

4.2 编写并编译Agent Descriptor

我们以“Web Researcher”为例，创建agent_web_research.yaml（内容见3.1节）。接下来用dsh-adgen工具编译：

# 进入tools目录 cd tools/adgen # 编译adgen工具 cargo build --release # 生成BLOB ./target/release/dsh-adgen --input ../examples/agent_web_research.yaml \ --output ../examples/agent_web_research.adb # 检查BLOB ls -lh ../examples/agent_web_research.adb # -rw-r--r-- 1 user user 2.1K Jun 15 14:25 ../examples/agent_web_research.adb

dsh-adgen会输出详细的校验报告：

INFO dsh_adgen > Validating YAML... INFO dsh_adgen > Parsing capabilities... OK (2 items) INFO dsh_adgen > Validating system_prompt length... OK (128 chars) INFO dsh_adgen > Generating binary blob... OK (2148 bytes) INFO dsh_adgen > Writing to ../examples/agent_web_research.adb

4.3 用户空间Agent程序：一个真实的main.c

真正的Agent程序，是一个极简的C程序，它只做三件事：加载AD、启动Loop、处理结果。以下是完整代码（examples/web_researcher.c）：

#include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <string.h> #include "dsh_ioctl.h" // DSH内核定义的ioctl命令 int main(int argc, char *argv[]) { if (argc != 2) { fprintf(stderr, "Usage: %s <question>\n", argv[0]); return 1; } int fd = open("/dev/dsh0", O_RDWR); if (fd < 0) { perror("open /dev/dsh0"); return 1; } // Step 1: Load Agent Descriptor struct dsh_ad_load load_req; load_req.ad_blob = malloc(4096); // 分配足够空间 load_req.ad_size = 0; // 从文件读取BLOB int ad_fd = open("../examples/agent_web_research.adb", O_RDONLY); load_req.ad_size = read(ad_fd, load_req.ad_blob, 4096); close(ad_fd); int ad_id; if (ioctl(fd, DSH_IOC_LOAD_AD, &load_req) < 0) { perror("DSH_IOC_LOAD_AD"); free(load_req.ad_blob); close(fd); return 1; } ad_id = load_req.ad_id; // ioctl返回分配的ad_id printf("Loaded Agent with ID: 0x%x\n", ad_id); // Step 2: Prepare input prompt char prompt[4096]; snprintf(prompt, sizeof(prompt), "User question: %s\nAnswer concisely with sources.", argv[1]); // Step 3: Start AgentLoop via sys_agent_think() struct dsh_agent_think think_req; think_req.ad_id = ad_id; think_req.prompt = prompt; think_req.prompt_len = strlen(prompt); think_req.max_tokens = 512; // 主循环：内核会自动处理Think->Wait->Run->Think... int ret; while (1) { ret = ioctl(fd, DSH_IOC_AGENT_THINK, &think_req); if (ret == 0) { // 成功！检查think_req.output_buffer printf("Agent output: %s\n", think_req.output_buffer); break; // 简单起见，只执行一次 } else if (ret == -EAGAIN) { // 内核表示Agent正在WAITING_IO，稍后重试 usleep(10000); // 等待10ms continue; } else { perror("DSH_IOC_AGENT_THINK"); break; } } free(load_req.ad_blob); close(fd); return 0; }

编译与运行：

# 编译用户程序 gcc -o web_researcher examples/web_researcher.c -Itools/ # 运行（需root权限，因为访问/dev/dsh0） sudo ./web_researcher "What is the current version of Kubernetes?"

预期输出：

Loaded Agent with ID: 0x1a2b Agent output: The current stable version of Kubernetes is v1.28.0, released on May 22, 2023. Source: https://kubernetes.io/docs/home/

实操心得：DSH_IOC_AGENT_THINK的EAGAIN返回值是关键。它不是错误，而是内核在说：“你的Agent刚发起了一个HTTP请求，现在正在等网络响应，别急着再来问，先睡会儿。”很多新手会把它当成错误处理，导致程序立即退出。记住：AgentLoop的“循环”，是由内核事件驱动的，用户空间的while只是一个轮询壳子。

4.4 性能调优与参数实验：量化理解AgentLoop

AgentLoop的性能不是黑盒，所有关键参数都可通过/proc/sys/dsh/接口动态调整。以下是几个最重要的参数及其调优指南：

实验：测量不同think_quantum下的吞吐量

# 设置量子为10ms echo 10000000 | sudo tee /proc/sys/dsh/think_quantum_ns # 运行100次请求，记录总时间 time for i in {1..100}; do sudo ./web_researcher "k8s version" > /dev/null; done # 输出：real 2m15.32s → ~0.76 req/sec # 设置量子为100ms echo 100000000 | sudo tee /proc/sys/dsh/think_quantum_ns time for i in {1..100}; do sudo ./web_researcher "k8s version" > /dev/null; done # 输出：real 1m42.89s → ~0.97 req/sec

结果表明：增大think_quantum提升了吞吐量（减少了上下文切换次数），但单次响应时间变长。最佳值需根据SLA权衡。我们的生产环境采用动态策略：交互式Agent用10ms，后台批处理Agent用500ms，由用户空间调度器统一管理。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 “Agent stuck in WAITING_IO forever” —— 网络服务未就绪的静默失败

现象：运行./web_researcher后，程序卡在ioctl(..., DSH_IOC_AGENT_THINK)，dmesg里不断刷[INFO] Agent 0x1a2b: state transition THINKING -> WAITING_IO，但从不变成RUNNING_TOOL。

排查思路：

1. 首先确认Tool Service是否运行：ps aux | grep "dsh-tool-http"。AgentLoop的HTTP工具是一个独立的用户空间守护进程，它监听内核的netlinksocket接收请求。
2. 如果进程不存在，启动它：sudo ./tools/tool_http/dsh-tool-http --port 8080。
3. 检查内核日志是否有连接拒绝：sudo dmesg | grep "HTTP_TOOL_CONNECT"。常见原因是dsh-tool-http绑定的端口被占用，或防火墙阻止。

根本原因：DSH内核的CSG在WAITING_IO状态时，会通过netlink向dsh-tool-http发送请求。如果该进程未启动，netlink发送会失败，但内核不会立即报错，而是进入超时等待。这是设计使然——它假设Tool Service是高可用的，短暂不可用应由超时机制处理。

解决方案：

• 启动Agent前，务必先启动所有依赖的Tool Service。
• 在dsh-tool-http启动脚本中加入健康检查：

  #!/bin/bash ./dsh-tool-http --port 8080 & PID=$! # 等待端口就绪 while ! nc -z localhost 8080; do sleep 0.1; done echo "Tool HTTP service ready on port 8080"

5.2 “GPU OOM during sys_llm_think” —— 显存配额与模型尺寸的精确匹配

**现象