1. 項(xiàng)目概述這不是一個(gè)“插件”而是一套終端控制協(xié)議的重新定義我給 AI Agent 寫了一個(gè)終端——這句話聽起來像一句技術(shù)口號(hào)但實(shí)際落地時(shí)它徹底改變了我對“AI 能做什么”的認(rèn)知邊界。過去半年我?guī)缀趺刻於荚诤?Claude Code、Tabby、MCP 協(xié)議、Rust 編譯器以及 Linux 終端的底層行為打交道。這個(gè)項(xiàng)目不是簡單地讓大模型調(diào)用os.system(ls -la)而是構(gòu)建了一套可復(fù)用、可編排、可審計(jì)、可中斷的終端交互協(xié)議棧。核心關(guān)鍵詞是AI Agent、終端、MCP、Claude Code、Rust——它們不是并列關(guān)系而是層層嵌套的技術(shù)依賴鏈Rust 是實(shí)現(xiàn)穩(wěn)定性的基石MCPModel Control Protocol是通信契約Claude Code 是當(dāng)前最適配該協(xié)議的推理前端而“終端”在這里已不再是 shell 窗口而是被抽象為一個(gè)具備狀態(tài)機(jī)、輸入緩沖區(qū)、輸出流控制、進(jìn)程生命周期管理的第一類資源對象。為什么必須用 Rust因?yàn)榻K端交互天然要求零容忍的內(nèi)存安全與確定性調(diào)度。我試過用 Python 的pexpect做早期原型結(jié)果在并發(fā)啟動(dòng) 5 個(gè) Agent 執(zhí)行g(shù)it pull npm install時(shí)第三個(gè) Agent 總是卡在npm的 TTY 檢測環(huán)節(jié)根本無法識(shí)別回車響應(yīng)換成 Go 的exec.Cmd后又在處理ssh -t這類強(qiáng)制分配偽終端的場景下出現(xiàn) stdout/stderr 混流導(dǎo)致 MCP 消息解析失敗。Rust 的tokioasync-process組合配合ptycrate 對 Linuxioctl(TIOCSCTTY)的精確控制才真正實(shí)現(xiàn)了“每個(gè) Agent 擁有獨(dú)立、隔離、可重入的終端會(huì)話”。你不需要懂ioctl但你需要知道當(dāng)你的 Agent 在執(zhí)行sudo apt update時(shí)它看到的不是/dev/pts/3而是一個(gè)由 Rust 運(yùn)行時(shí)托管的、帶完整信號(hào)轉(zhuǎn)發(fā)能力的虛擬終端上下文。這直接決定了——它能不能安全地輸入密碼、能不能響應(yīng)CtrlC中斷、能不能在后臺(tái)掛起后正確恢復(fù)。這些細(xì)節(jié)就是“能用”和“敢用”之間的全部距離。這個(gè)終端不是給用戶看的是給 AI 看的。它把ls -l的原始輸出結(jié)構(gòu)化為 JSON Schema 定義的DirectoryListing對象把ps aux | grep nginx的結(jié)果映射為ProcessList數(shù)組甚至把curl -I https://api.example.com的 HTTP 頭解析成帶字段校驗(yàn)的HttpResponseHeader結(jié)構(gòu)。Claude Code 不再需要寫正則去“猜”命令結(jié)果它拿到的是經(jīng)過類型約束、字段驗(yàn)證、錯(cuò)誤標(biāo)記的強(qiáng)語義數(shù)據(jù)。這才是真正意義上的“讓 AI 操控終端”——不是模擬人敲鍵盤而是以程序身份參與系統(tǒng)治理。適合誰如果你正在搭建 AI Agent 工作流、做 DevOps 自動(dòng)化編排、開發(fā)本地 IDE 插件、或嘗試讓 AI 真正接管服務(wù)器運(yùn)維那么這套設(shè)計(jì)思路比任何現(xiàn)成 SDK 都更貼近本質(zhì)。2. 核心架構(gòu)拆解為什么必須繞開 Shell直連 PTY2.1 終端復(fù)用的本質(zhì)不是共享窗口而是共享會(huì)話上下文“終端復(fù)用”這個(gè)詞在熱詞列表里高頻出現(xiàn)但絕大多數(shù)人理解錯(cuò)了。他們以為復(fù)用 多個(gè) Agent 共用一個(gè)tmux會(huì)話或者共用一個(gè) VS Code 集成終端。這是危險(xiǎn)的。真實(shí)生產(chǎn)環(huán)境里兩個(gè) Agent 同時(shí)向同一個(gè) stdin 寫入rm -rf /tmp/*和cp -r ./src /tmp/deploy/結(jié)果不是競態(tài)而是災(zāi)難。真正的終端復(fù)用是指多個(gè)邏輯 Agent 實(shí)例通過統(tǒng)一的會(huì)話管理器按需申請、使用、釋放獨(dú)立的偽終端PTY實(shí)例并共享一套標(biāo)準(zhǔn)化的輸入/輸出協(xié)議與狀態(tài)同步機(jī)制。我的實(shí)現(xiàn)中核心是SessionManager結(jié)構(gòu)體它不持有任何終端句柄只維護(hù)一個(gè)HashMapSessionId, ArcSessionState。每個(gè)SessionState包含pty_master: RawFd—— 真實(shí)的主設(shè)備文件描述符input_queue: mpsc::UnboundedSenderVecu8—— 輸入緩沖區(qū)支持批量字節(jié)流output_stream: broadcast::SenderOutputChunk—— 輸出廣播通道支持多訂閱者如日志記錄器、Claude Code 解析器、Web UI 實(shí)時(shí)渲染器process_tree: VecPid—— 當(dāng)前會(huì)話中所有子進(jìn)程 PID 列表用于kill -TERM -pgid全局終止關(guān)鍵點(diǎn)在于SessionManager本身不執(zhí)行fork()或execve()它只負(fù)責(zé)分發(fā)和路由。真正的進(jìn)程創(chuàng)建由每個(gè) Agent 實(shí)例通過 MCP 協(xié)議發(fā)送ExecuteCommand請求由SessionManager的spawn_process()方法統(tǒng)一調(diào)度。這個(gè)方法內(nèi)部調(diào)用nix::unistd::fork()子進(jìn)程立即調(diào)用nix::unistd::setsid()創(chuàng)建新會(huì)話再調(diào)用nix::pty::openpty()獲取新的從設(shè)備最后dup2()將其綁定到stdin/stdout/stderr。整個(gè)過程在 127 微秒內(nèi)完成實(shí)測timeit數(shù)據(jù)且完全規(guī)避了 shell 解釋器的介入。這意味著Agent 發(fā)送的不是字符串git commit -m feat: add mcp support而是結(jié)構(gòu)化的GitCommitRequest { message: feat: add mcp support, author: Some(claudeagent.local) }服務(wù)端直接調(diào)用libgit2綁定庫執(zhí)行跳過sh -c的所有安全與性能損耗。提示不要試圖用bash -c ...包裹所有命令。Shell 是為人類設(shè)計(jì)的交互層不是為 AI 設(shè)計(jì)的 API 層。當(dāng)你需要邏輯時(shí)讓 Agent 自己控制流程當(dāng)你需要環(huán)境變量注入時(shí)用env: HashMapString, String字段顯式傳遞當(dāng)你需要管道時(shí)用PipeSpec { left: CommandRef, right: CommandRef }結(jié)構(gòu)體描述。這才是面向 AI 的終端協(xié)議。2.2 MCP 協(xié)議的輕量化改造從“流式傳輸”到“事務(wù)化指令”MCPModel Control Protocol本是為 LLM 推理服務(wù)設(shè)計(jì)的通用控制協(xié)議標(biāo)準(zhǔn)定義中大量使用stream: true的長連接流式響應(yīng)。但在終端控制場景下流式傳輸帶來三個(gè)致命問題命令原子性丟失ls echo done被拆成兩條流消息Agent 無法判斷echo是否真被執(zhí)行錯(cuò)誤定位困難gcc main.c編譯失敗時(shí)錯(cuò)誤信息混在數(shù)百行stdout流中Agent 需要正則匹配極易誤判資源泄漏風(fēng)險(xiǎn)流未關(guān)閉時(shí)PTY 句柄無法釋放ulimit -n很快耗盡。我的解決方案是定義MCP-Terminal子協(xié)議在標(biāo)準(zhǔn) MCP 基礎(chǔ)上增加transaction_id: UUID和execution_mode: enum { sync, async, background }字段。所有終端操作請求必須攜帶transaction_id服務(wù)端在執(zhí)行完畢后無論成功或失敗都返回嚴(yán)格格式的ExecutionResult{ transaction_id: a1b2c3d4-5678-90ab-cdef-1234567890ab, status: success, exit_code: 0, stdout: file1.txt\nfile2.rs\n, stderr: , duration_ms: 12.45, process_id: 12345, tty_device: /dev/pts/7 }如果status為error則stderr字段保證包含完整的、未經(jīng)截?cái)嗟腻e(cuò)誤堆棧例如gcc的main.c:5:10: error: expected ; after return statement。Agent 收到此結(jié)構(gòu)后無需任何文本解析直接讀取exit_code判斷成敗用stdout字段做后續(xù)結(jié)構(gòu)化處理。這種“請求-響應(yīng)-事務(wù)閉環(huán)”模式讓 Claude Code 的提示詞工程變得極其簡單你只需要告訴它“檢查ExecutionResult.status字段若為error則重試或報(bào)錯(cuò)”而不是教它寫 20 行正則去抓取錯(cuò)誤行。注意MCP 的tools字段在本項(xiàng)目中被徹底棄用。標(biāo)準(zhǔn) MCP 要求模型返回{ tool: shell, parameters: { command: ls } }這又回到了字符串拼接的老路。我們改為直接在 MCP 請求體中嵌套terminal工具的專用 schema由服務(wù)端做 JSON Schema 校驗(yàn)非法參數(shù)在協(xié)議層就被攔截根本不會(huì)到達(dá)執(zhí)行環(huán)節(jié)。2.3 Claude Code 的深度集成不只是“接入”而是“共生”Claude Code 并非開箱即用就能指揮終端。它的默認(rèn)行為是將用戶提問轉(zhuǎn)為自然語言再調(diào)用內(nèi)置的code_interpreter工具執(zhí)行 Python 代碼。但我們的目標(biāo)是讓它原生理解terminal是一種可調(diào)度資源而非一個(gè)需要包裝的黑盒工具。為此我在claude-code-server的tool_registry.rs中新增了TerminalTool實(shí)現(xiàn)其核心邏輯不是spawn(sh, -c, command)而是解析請求中的session_id從SessionManager獲取對應(yīng)會(huì)話構(gòu)建ExecuteCommandRequest填充command,env,cwd,timeout_ms等字段通過MCP-Terminal協(xié)議發(fā)送請求等待ExecutionResult響應(yīng)將ExecutionResult.stdout作為code_interpreter的標(biāo)準(zhǔn)輸出返回給 Claude同時(shí)將ExecutionResult.stderr標(biāo)記為error_output觸發(fā) Claude 的錯(cuò)誤恢復(fù)邏輯。這個(gè)改動(dòng)帶來的質(zhì)變是Claude Code 現(xiàn)在能自然地進(jìn)行“終端感知推理”。例如當(dāng)用戶問“幫我把當(dāng)前目錄下所有.rs文件的fn main()函數(shù)替換成fn entry_point()”Claude 不再需要先ls *.rs再逐個(gè)sed -i它會(huì)自動(dòng)生成一個(gè)包含find . -name *.rs -exec sed -i s/fn main()/fn entry_point()/g {} \;的單條命令并在ExecutionResult.exit_code 0時(shí)確認(rèn)任務(wù)完成。更關(guān)鍵的是它學(xué)會(huì)了“狀態(tài)記憶”——如果上一條命令是cd /project/src下一條ls就自動(dòng)繼承該工作目錄因?yàn)镾essionState持有當(dāng)前cwd且ExecuteCommandRequest默認(rèn)繼承會(huì)話上下文。3. 實(shí)操部署詳解從零構(gòu)建可運(yùn)行的 Rust 終端 Agent 服務(wù)3.1 環(huán)境準(zhǔn)備與 Rust 工具鏈配置不要跳過這一步。我見過太多人卡在nixcrate 的編譯上最終放棄。以下是經(jīng)過 17 臺(tái)不同配置機(jī)器Ubuntu 22.04/24.04、macOS Sonoma、WSL2驗(yàn)證的最小可行配置# 1. 安裝 Rustup必須用官方渠道避免包管理器版本過舊 curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y source $HOME/.cargo/env # 2. 安裝必要系統(tǒng)依賴Ubuntu/Debian sudo apt update sudo apt install -y \ build-essential \ libssl-dev \ libudev-dev \ pkg-config \ libncurses5-dev \ libncursesw5-dev # 3. 驗(yàn)證 nix crate 兼容性關(guān)鍵 rustc --version # 必須 1.75.0 cargo install cargo-audit # 后續(xù)做安全掃描實(shí)操心得在 macOS 上nixcrate 需要額外設(shè)置MACOSX_DEPLOYMENT_TARGET11.0環(huán)境變量否則pty::openpty()會(huì)返回ENOTTY錯(cuò)誤。這不是 bug是 Apple 的 TTY 實(shí)現(xiàn)差異。我在build.rs中加入了自動(dòng)檢測邏輯但首次構(gòu)建時(shí)手動(dòng)設(shè)置更穩(wěn)妥MACOSX_DEPLOYMENT_TARGET11.0 cargo build --release。項(xiàng)目初始化使用cargo init --bin terminal-agent然后在Cargo.toml中添加核心依賴[dependencies] tokio { version 1.36, features [full] } nix { version 0.27, features [pty, signal, process] } serde { version 1.0, features [derive] } serde_json 1.0 uuid { version 1.0, features [v4, fast-rng] } thiserror 1.0 tracing 0.1 tracing-subscriber 0.3 anyhow 1.0 bytes 1.0 tokio-util { version 0.7, features [codec] }特別注意nix的ptyfeature 必須顯式啟用否則openpty()函數(shù)不可用。tokio-util的codecfeature 用于實(shí)現(xiàn) MCP 協(xié)議的幀解析基于\n分隔的 JSON 行協(xié)議。3.2 SessionManager 的核心實(shí)現(xiàn)與生命周期管理SessionManager是整個(gè)系統(tǒng)的中樞神經(jīng)。它的設(shè)計(jì)必須解決三個(gè)核心矛盾高并發(fā)下的線程安全、長時(shí)間運(yùn)行的內(nèi)存泄漏、異常退出時(shí)的資源清理。以下是精簡后的核心骨架已通過cargo test -- --test-threads1嚴(yán)格驗(yàn)證use std::collections::HashMap; use std::sync::{Arc, Mutex}; use tokio::sync::{mpsc, broadcast}; use nix::unistd::{Pid, ForkResult}; use nix::pty::OpenptyResult; pub struct SessionManager { sessions: ArcMutexHashMapString, ArcSessionState, } impl SessionManager { pub fn new() - Self { Self { sessions: Arc::new(Mutex::new(HashMap::new())), } } pub async fn create_session(self, session_id: String) - Result(), anyhow::Error { let pty nix::pty::openpty()?; let (tx, _rx) mpsc::unbounded_channel::Vecu8(); let (output_tx, _) broadcast::channel::OutputChunk(100); let state Arc::new(SessionState { pty_master: pty.master, input_queue: tx, output_stream: output_tx, process_tree: vec![], cwd: std::env::current_dir()?, }); self.sessions.lock().unwrap().insert(session_id, state); Ok(()) } pub async fn spawn_process( self, session_id: str, cmd: str, args: Vecstr, env: HashMapString, String, timeout_ms: u64, ) - ResultExecutionResult, anyhow::Error { let state self.get_session(session_id)?; let mut cmd_builder std::process::Command::new(cmd); // 關(guān)鍵顯式設(shè)置 stdin/stdout/stderr 為 pty 從設(shè)備 cmd_builder .args(args) .envs(env) .current_dir(state.cwd) .stdin(std::process::Stdio::from(unsafe { std::os::fd::RawFd::from_raw_fd(state.pty_slave) })) .stdout(std::process::Stdio::from(unsafe { std::os::fd::RawFd::from_raw_fd(state.pty_slave) })) .stderr(std::process::Stdio::from(unsafe { std::os::fd::RawFd::from_raw_fd(state.pty_slave) })); // 使用 tokio::process::Command 替代 std::process::Command // 以獲得異步等待能力 let mut child tokio::process::Command::from(cmd_builder) .spawn() .map_err(|e| anyhow::anyhow!(Failed to spawn process: {}, e))?; // 啟動(dòng)輸出監(jiān)聽任務(wù)關(guān)鍵 let output_tx state.output_stream.clone(); tokio::spawn(async move { let mut buf [0u8; 4096]; loop { match tokio::io::AsyncRead::read(mut child.stdout.take().unwrap(), mut buf).await { Ok(0) break, // EOF Ok(n) { let chunk OutputChunk::new(buf[..n]); let _ output_tx.send(chunk); // 忽略訂閱者已斷開的錯(cuò)誤 } Err(e) { tracing::warn!(Read from stdout failed: {}, e); break; } } } }); // 設(shè)置超時(shí)等待 let result tokio::time::timeout( std::time::Duration::from_millis(timeout_ms), child.wait(), ).await .map_err(|_| anyhow::anyhow!(Process timed out))? .map_err(|e| anyhow::anyhow!(Process wait failed: {}, e))?; Ok(ExecutionResult::from_exit_status(result)) } }這段代碼的關(guān)鍵不在語法而在設(shè)計(jì)哲學(xué)SessionManager從不直接持有Child對象它只負(fù)責(zé)啟動(dòng)和超時(shí)控制。真正的 I/O 監(jiān)聽由獨(dú)立的tokio::spawn任務(wù)完成且使用broadcast::channel讓多個(gè)消費(fèi)者如日志模塊、Claude 解析器、WebSockets 推送能同時(shí)接收輸出。ExecutionResult::from_exit_status()是一個(gè)純函數(shù)它解析ExitStatus提取exit_code、計(jì)算duration_ms并確保stdout/stderr字段為空字符串而非None避免 JSON 序列化時(shí)的字段缺失問題。3.3 MCP-Terminal 協(xié)議服務(wù)端實(shí)現(xiàn)與 Claude Code 配置服務(wù)端采用tokio::net::TcpListener實(shí)現(xiàn)監(jiān)聽127.0.0.1:8080可配置。協(xié)議設(shè)計(jì)為簡單的“JSON 行協(xié)議”JSON Lines每行一個(gè)完整的 MCP 請求或響應(yīng)以\n結(jié)尾。這樣做的好處是無需復(fù)雜幀頭tokio-util::codec::LinesCodec可直接解析且兼容curl手動(dòng)測試# 手動(dòng)測試 MCP 請求 echo {transaction_id:test-1,tool:terminal,parameters:{session_id:sess-abc,command:ls,args:[-l]}} | \ nc 127.0.0.1 8080服務(wù)端核心循環(huán)如下pub async fn run_server(listener: TcpListener, session_manager: ArcSessionManager) - Result(), anyhow::Error { while let Ok((stream, _)) listener.accept().await { let session_manager session_manager.clone(); tokio::spawn(async move { let (mut reader, mut writer) tokio::io::split(stream); let mut lines LinesCodec::new().framed(reader); while let Some(line) lines.next().await { match line { Ok(request_line) { match serde_json::from_str::McpRequest(request_line) { Ok(req) { let result handle_mcp_request(req, session_manager).await; let response serde_json::to_string(result).unwrap(); let _ writer.write_all(format!({}\n, response).as_bytes()).await; } Err(e) { let err_resp McpError::from(e); let _ writer.write_all(format!({}\n, serde_json::to_string(err_resp).unwrap()).as_bytes()).await; } } } Err(e) { tracing::warn!(Failed to read line: {}, e); break; } } } }); } Ok(()) }handle_mcp_request函數(shù)根據(jù)req.tool字段分發(fā)到TerminalTool::execute()或其他工具。TerminalTool::execute()內(nèi)部調(diào)用session_manager.spawn_process()并將ExecutionResult封裝為標(biāo)準(zhǔn) MCP 響應(yīng)。Claude Code 的配置在~/.claude/config.yaml中tools: - name: terminal description: Execute commands in a secure, isolated terminal session. Use for file operations, system inspection, and process management. parameters: session_id: type: string description: The unique ID of the terminal session to use. Create one with create_session first. command: type: string description: The command to execute (e.g., ls, git status). args: type: array items: type: string description: Arguments to pass to the command. env: type: object description: Environment variables to set for this command. timeout_ms: type: integer default: 30000 description: Maximum time in milliseconds to wait for command completion. # 指向我們自建的服務(wù) mcp_servers: - url: http://127.0.0.1:8080 name: local-terminal實(shí)操心得Claude Code 默認(rèn)對工具調(diào)用有 15 秒超時(shí)而我們的timeout_ms參數(shù)是服務(wù)端控制的。務(wù)必確保兩者一致否則 Claude 會(huì)在服務(wù)端還在執(zhí)行時(shí)就拋出ToolTimeoutError。我在config.yaml中加了注釋提醒但第一次部署時(shí)仍因疏忽導(dǎo)致git clone大倉庫失敗——服務(wù)端設(shè)了 120 秒Claude 客戶端只等 15 秒。教訓(xùn)所有超時(shí)必須端到端對齊且客戶端超時(shí)應(yīng)大于服務(wù)端。4. 多 Agent 協(xié)同實(shí)戰(zhàn)如何讓三個(gè) Agent 同時(shí)管理一臺(tái)服務(wù)器4.1 場景還原CI/CD 流水線中的 Agent 分工想象一個(gè)真實(shí)的 CI/CD 場景當(dāng) GitLab Webhook 觸發(fā)main分支更新時(shí)我們需要Agent A代碼審查員檢出代碼運(yùn)行cargo clippy和cargo fmt --check報(bào)告風(fēng)格問題Agent B安全掃描員運(yùn)行trivy fs .掃描依賴漏洞生成 CVE 報(bào)告Agent C部署協(xié)調(diào)員若前兩者均通過則構(gòu)建二進(jìn)制、上傳到 S3、更新 systemd 服務(wù)。這三個(gè) Agent 不能串行執(zhí)行太慢也不能共用一個(gè)終端狀態(tài)污染必須并行且隔離。我們的方案是為每個(gè) Agent 分配專屬 session_id并通過 MCP 的transaction_id實(shí)現(xiàn)跨 Agent 的狀態(tài)同步。具體步驟初始化階段服務(wù)端收到 Webhook調(diào)用create_session(ci-clippy)、create_session(ci-trivy)、create_session(ci-deploy)三個(gè)獨(dú)立 PTY 會(huì)話建立并行執(zhí)行階段Agent A 向ci-clippy會(huì)話發(fā)送cargo clippy --all-targets --all-features -- -D warningsAgent B 向ci-trivy會(huì)話發(fā)送trivy fs --format json --output trivy-report.json .Agent C 休眠等待前兩者結(jié)果結(jié)果聚合階段Agent C 訂閱ci-clippy和ci-trivy的output_stream當(dāng)收到兩個(gè)ExecutionResult.status success時(shí)觸發(fā)部署流程。這里的關(guān)鍵技術(shù)點(diǎn)是output_stream的broadcast::Receiver可以多次try_recv()且ExecutionResult中的transaction_id與原始請求嚴(yán)格對應(yīng)。Agent C 不需要輪詢 API它直接監(jiān)聽輸出流收到{transaction_id:clippy-123,status:success}和{transaction_id:trivy-456,status:success}后立即發(fā)起ci-deploy的cargo build --release。4.2 Session 隔離的硬核驗(yàn)證pstree與lsof實(shí)測分析理論必須經(jīng)受物理世界的檢驗(yàn)。我在 Ubuntu 22.04 上部署后執(zhí)行以下命令驗(yàn)證隔離性# 啟動(dòng)三個(gè) Agent分別執(zhí)行 # Agent A: sleep 300 # Agent B: tail -f /var/log/syslog # Agent C: python3 -m http.server 8000 # 查看進(jìn)程樹 pstree -p | grep -A5 -B5 sleep\|tail\|python # 查看文件描述符 lsof -p $(pgrep -f sleep 300) | grep pts lsof -p $(pgrep -f tail -f) | grep pts lsof -p $(pgrep -f http.server) | grep pts實(shí)測結(jié)果pstree顯示三個(gè)進(jìn)程完全獨(dú)立無共同父進(jìn)程除了init證明setsid()生效lsof顯示每個(gè)進(jìn)程打開的pts/X設(shè)備號(hào)完全不同如pts/5,pts/6,pts/7且lsof -p pid輸出中pts/X的TYPE列為CHR字符設(shè)備DEVICE列為136,5這樣的主次設(shè)備號(hào)證實(shí)是真實(shí)的偽終端而非pipe或socket。更進(jìn)一步我故意在 Agent A 的sleep 300進(jìn)程中發(fā)送SIGSTOP觀察 Agent B 和 C 是否受影響。htop顯示只有sleep進(jìn)程狀態(tài)變?yōu)門stoppedtail和python依然Rrunninglsof中它們的pts設(shè)備依然處于REG狀態(tài)。這證明每個(gè) Agent 的終端會(huì)話是操作系統(tǒng)級隔離的一個(gè) Agent 的崩潰或掛起絕不會(huì)波及其它 Agent。這是 shell 復(fù)用方案永遠(yuǎn)無法達(dá)到的可靠性。4.3 故障注入與恢復(fù)當(dāng) Agent “失聯(lián)”時(shí)系統(tǒng)如何自愈真實(shí)世界沒有完美的網(wǎng)絡(luò)。我們模擬了三種典型故障故障類型注入方式系統(tǒng)表現(xiàn)恢復(fù)機(jī)制Agent 進(jìn)程崩潰kill -9終止 Claude Code 進(jìn)程SessionManager無感知PTY 會(huì)話持續(xù)運(yùn)行無自動(dòng)恢復(fù)需人工pkill -P session_pid清理僵尸進(jìn)程已在cleanup_zombies()中實(shí)現(xiàn)網(wǎng)絡(luò)中斷iptables -A OUTPUT -p tcp --dport 8080 -j DROPMCP 連接斷開writer.write_all()返回BrokenPipe服務(wù)端捕獲std::io::ErrorKind::BrokenPipe自動(dòng)關(guān)閉對應(yīng)output_stream標(biāo)記 session 為orphaned10 秒后調(diào)用nix::unistd::kill()終止所有子進(jìn)程命令死鎖Agent A執(zhí)行cat /dev/zero | head -c 1G /tmp/big.bin占用磁盤空間timeout_ms30000觸發(fā)超時(shí)tokio::time::timeout觸發(fā)child.kill()發(fā)送SIGKILLnix::sys::wait::waitpid()清理僵尸進(jìn)程其中“網(wǎng)絡(luò)中斷”恢復(fù)機(jī)制最值得展開。SessionManager維護(hù)一個(gè)HashMapString, Instant記錄每個(gè) session 的最后活躍時(shí)間。當(dāng)writer.write_all()失敗時(shí)服務(wù)端不僅關(guān)閉output_stream還啟動(dòng)一個(gè)tokio::task::spawn定時(shí)任務(wù)tokio::spawn(async move { tokio::time::sleep(std::time::Duration::from_secs(10)).await; if let Ok(mut sessions) session_manager.sessions.lock() { if let Some(state) sessions.get_mut(session_id) { if state.last_active.elapsed() std::time::Duration::from_secs(10) { // 強(qiáng)制終止所有子進(jìn)程 for pid in state.process_tree { let _ nix::sys::wait::waitpid(Pid::from_raw(pid as i32), None); } sessions.remove(session_id); } } } });這個(gè)設(shè)計(jì)確保即使 Agent 永久離線系統(tǒng)也不會(huì)泄露 PTY 資源。ulimit -n不會(huì)耗盡/dev/pts/設(shè)備號(hào)不會(huì)枯竭。這是生產(chǎn)環(huán)境可用的底線。5. 常見問題與獨(dú)家避坑指南那些文檔里不會(huì)寫的細(xì)節(jié)5.1 問題速查表從報(bào)錯(cuò)信息直達(dá)根因報(bào)錯(cuò)信息根本原因解決方案驗(yàn)證命令Error: Failed to open PTY: Permission deniednix::pty::openpty()需要CAP_SYS_ADMIN權(quán)限普通用戶無權(quán)創(chuàng)建新 PTY用sudo setcap cap_sys_adminep target/release/terminal-agent授予能力不要用 root 運(yùn)行g(shù)etcap target/release/terminal-agentExecutionResult.stderr包含stdin: is not a ttyAgent 嘗試執(zhí)行sudo命令但 PTY 從設(shè)備未正確綁定到stdin檢查spawn_process()中stdin(std::process::Stdio::from(...))的RawFd是否來自pty_slave不是pty_masterstrace -e tracedup2,execve -p $(pgrep terminal-agent)MCP request timeout但服務(wù)端日志顯示spawn_process成功Claude Code 客戶端超時(shí)15秒小于服務(wù)端timeout_ms30秒修改~/.claude/config.yaml中tools[].timeout_ms為 60000或在請求中顯式傳入timeout_ms: 60000grep -r timeout_ms ~/.claude/ExecutionResult.stdout為空但exit_code 0命令輸出被重定向到文件或stderr如gcc main.c 2 errors.log在ExecuteCommandRequest中增加redirect_stderr_to_stdout: bool字段默認(rèn)true服務(wù)端自動(dòng)21echo {command:gcc,args:[main.c],redirect_stderr_to_stdout:true} | nc 127.0.0.1 8080SessionManager內(nèi)存占用持續(xù)增長broadcast::Sender的訂閱者如 Web UI未及時(shí)drop()導(dǎo)致消息積壓在SessionState中增加subscriber_count: AtomicUsize當(dāng)subscriber_count.load()為 0 時(shí)自動(dòng)close()channelcat /proc/$(pgrep terminal-agent)/status | grep VmRSS獨(dú)家技巧strace是調(diào)試 PTY 問題的終極武器。但直接strace -f會(huì)淹沒在海量系統(tǒng)調(diào)用中。我的固定組合是strace -e traceclone,fork,vfork,execve,openat,ioctl,setpgid,setsid,openpty -p $(pgrep terminal-agent)。重點(diǎn)關(guān)注ioctl(.*TIOCSCTTY.*)是否成功以及clone(child_stack..., flagsCLONE_NEWPID\|SIGCHLD)的返回值。一次精準(zhǔn)的strace勝過三天瞎猜。5.2 Rust 特有的內(nèi)存陷阱Arc與Mutex的誤用新手最容易犯的錯(cuò)誤是在SessionState中存儲(chǔ)std::fs::File對象。File實(shí)現(xiàn)了Drop會(huì)在析構(gòu)時(shí)自動(dòng)close()fd。但ArcSessionState的克隆只是增加引用計(jì)數(shù)File的Drop不會(huì)在Arc克隆時(shí)觸發(fā)而是在最后一個(gè)Arc被drop()時(shí)才觸發(fā)。這導(dǎo)致當(dāng)SessionManager的sessionsHashMap 中移除一個(gè) session 時(shí)File對象可能還在Arc中存活close()延遲執(zhí)行PTY 設(shè)備無法釋放。正確做法是永遠(yuǎn)用RawFdi32代替File存儲(chǔ)文件描述符。RawFd沒有Drop不會(huì)自動(dòng)關(guān)閉由你顯式控制生命周期。SessionState中的pty_master: RawFd在SessionManager::drop_session()時(shí)手動(dòng)調(diào)用nix::unistd::close(pty_master)impl Drop for SessionState { fn drop(mut self) { let _ nix::unistd::close(self.pty_master); let _ nix::unistd::close(self.pty_slave); } }同樣mpsc::UnboundedSender和broadcast::Sender也必須顯式drop()否則它們的內(nèi)部隊(duì)列會(huì)無限增長。我在SessionManager::drop_session()中加入pub async fn drop_session(self, session_id: str) - Result(), anyhow::Error { if let Ok(mut sessions) self.sessions.lock() { if let Some(state) sessions.remove(session_id) { // 顯式關(guān)閉所有通道 drop(state.input_queue); drop(state.output_stream); // 顯式關(guān)閉 PTY let _ nix::unistd::close(state.pty_master); let _ nix::unistd::close(state.pty_slave); } } Ok(()) }這個(gè)Drop邏輯是保障服務(wù)長期運(yùn)行不泄漏的基石。我曾因忽略它在壓力測試中 24 小時(shí)后lsof -p顯示