開(kāi)局先交代一個(gè)背景我去年接手了一個(gè)“隔離內(nèi)網(wǎng)部署 AI Agent”的活兒環(huán)境非常典型——服務(wù)器所在的網(wǎng)段不接互聯(lián)網(wǎng)數(shù)據(jù)進(jìn)出全靠離線(xiàn)拷貝生產(chǎn)區(qū)連 DNS 都受限。當(dāng)時(shí)團(tuán)隊(duì)里討論最久的不是模型選哪家而是“Agent 在斷網(wǎng)環(huán)境里到底還跑不跑得起來(lái)”。折騰了小半年之后我可以負(fù)責(zé)任地說(shuō)隔離內(nèi)網(wǎng)不僅跑得起來(lái)而且跑完后你會(huì)發(fā)現(xiàn)很多在公網(wǎng)環(huán)境下被掩蓋的工程問(wèn)題全都浮出水面了。這篇文章就把那次實(shí)戰(zhàn)的思路、選型、步驟和踩坑記錄完整寫(xiě)出來(lái)希望能給同樣被困在內(nèi)網(wǎng)環(huán)境里做 AI Agent 的同學(xué)一點(diǎn)參考。AI Agent 聽(tīng)起來(lái)很玄核心其實(shí)就三件事讓模型理解任務(wù)、讓模型調(diào)用工具、讓模型記住上下文。放到隔離內(nèi)網(wǎng)里難點(diǎn)變成了“模型從哪來(lái)、工具如何暴露、依賴(lài)怎么裝上、效果怎么調(diào)試”。這四件事如果不在動(dòng)手前想清楚后面每一步都是在填坑。1. 整體設(shè)計(jì)與思路拆解1.1 為什么要在隔離內(nèi)網(wǎng)跑 AI Agent先說(shuō)動(dòng)機(jī)。很多團(tuán)隊(duì)做 Agent 第一反應(yīng)是接云端大模型 API反正聯(lián)網(wǎng)就行。但實(shí)際生產(chǎn)場(chǎng)景里研發(fā)或辦公內(nèi)網(wǎng)往往是隔離的原因無(wú)外乎三種一是數(shù)據(jù)敏感業(yè)務(wù)數(shù)據(jù)、代碼庫(kù)、用戶(hù)資料不允許出網(wǎng)二是合規(guī)要求金融、能源、政務(wù)行業(yè)的監(jiān)管明確規(guī)定了核心系統(tǒng)不得連接公共網(wǎng)絡(luò)三是穩(wěn)定優(yōu)先生產(chǎn)網(wǎng)絡(luò)要保證全年可用率不能把關(guān)鍵鏈路建立在一家云廠商的 API 上。這三種場(chǎng)景下AI Agent 的價(jià)值反而更大。斷網(wǎng)不等于斷智能內(nèi)網(wǎng)里有海量日志、知識(shí)庫(kù)、運(yùn)維腳本、數(shù)據(jù)庫(kù)這些傳統(tǒng)上要靠人去翻的東西正是 Agent 最擅長(zhǎng)處理的。比如說(shuō)內(nèi)網(wǎng)工單系統(tǒng)每天幾百條重復(fù)咨詢(xún)完全可以讓 Agent 先檢索本地知識(shí)庫(kù)生成草稿再由人工復(fù)核既省人力又不碰外網(wǎng)。這個(gè)階段最忌諱的事情是“先跑起來(lái)再說(shuō)”。我見(jiàn)過(guò)不少團(tuán)隊(duì)在內(nèi)網(wǎng)服務(wù)器上裝個(gè)框架模型文件用 U 盤(pán)拷進(jìn)去代碼一股腦丟上去結(jié)果 GPU 顯存不夠、依賴(lài)缺包、Agent 一回車(chē)就報(bào)錯(cuò)。先花半天把需求邊界和資源清單列清楚比什么都重要。1.2 架構(gòu)選型推理、編排、工具三層分離隔離內(nèi)網(wǎng)里做 Agent我最終把系統(tǒng)分成三層每一層都可以獨(dú)立替換推理層負(fù)責(zé)跑大模型對(duì)外提供 OpenAI 兼容的接口。選型時(shí)只考慮能離線(xiàn)運(yùn)行的推理引擎比如 Ollama、vLLM、llama.cpp我實(shí)測(cè)下來(lái)都可行。編排層負(fù)責(zé) Agent 的主循環(huán)——接收用戶(hù)問(wèn)題、調(diào)用模型、解析模型輸出的工具調(diào)用意圖、觸發(fā)工具執(zhí)行、把結(jié)果送回模型繼續(xù)生成。這一層是 Agent 的靈魂可以自研也可以基于 LangGraph、Dify 這類(lèi)框架。工具層把內(nèi)網(wǎng)里的實(shí)際能力包成接口比如查數(shù)據(jù)庫(kù)、調(diào)內(nèi)部 API、讀取文件系統(tǒng)、執(zhí)行運(yùn)維腳本。每個(gè)工具都必須有清晰的入?yún)⒑统鰠⒍x。為什么要拆三層而不是搞一個(gè)“全家桶”一體化系統(tǒng)因?yàn)楦綦x內(nèi)網(wǎng)最大的問(wèn)題是排障困難。一旦把推理、編排、工具混在一起出了問(wèn)題你根本不知道是模型卡了、代碼 bug還是內(nèi)網(wǎng)服務(wù)沒(méi)響應(yīng)。分層之后每一層都有獨(dú)立的日志和監(jiān)控點(diǎn)問(wèn)題可以迅速定位到具體環(huán)節(jié)。還有一點(diǎn)經(jīng)驗(yàn)不要把編排層和推理引擎耦合死。推理引擎今天用 Ollama明天可能因?yàn)樾阅軗Q vLLM只要它還兼容 OpenAI 的 Chat Completions 協(xié)議編排層就不用大改。所以我在編排層寫(xiě)的調(diào)用代碼都是基于標(biāo)準(zhǔn)接口的不綁定任何一家廠商的 SDK。1.3 為什么我用 Rust 寫(xiě)編排層這次實(shí)戰(zhàn)我用了 Rust 來(lái)寫(xiě)編排層這個(gè)選擇很關(guān)鍵。主流方案里Python 生態(tài)最豐富寫(xiě)起來(lái)最快但我最終選了 Rust原因很現(xiàn)實(shí)隔離內(nèi)網(wǎng)部署環(huán)境里能裝的東西有限Rust 編譯出來(lái)的單二進(jìn)制文件幾乎不需要運(yùn)行時(shí)依賴(lài)拷到目標(biāo)機(jī)器上直接就能跑Agent 編排本質(zhì)是大量 I/O 密集型任務(wù)模型推理要等待、工具調(diào)用要等待Rust 的異步運(yùn)行時(shí)在并發(fā)處理上很穩(wěn)不夸張地說(shuō)幾百個(gè)并發(fā)會(huì)話(huà)同時(shí)掛著問(wèn)題不大內(nèi)網(wǎng)環(huán)境通常會(huì)碰到各種格式的文本、協(xié)議解析Rust 對(duì)內(nèi)存安全性控制嚴(yán)格長(zhǎng)期跑在服務(wù)器上不容易漏內(nèi)存模型輸出的工具調(diào)用是 JSONRust 生態(tài)里 serde_json 的解析速度非常快Agent 一次決策循環(huán)里可能要 parse 好幾輪效率不是問(wèn)題。當(dāng)然 Rust 的上手成本確實(shí)高生命周期、所有權(quán)這些概念會(huì)把不少人卡住。我的建議是如果團(tuán)隊(duì)已經(jīng)有 Python 基礎(chǔ)可以先在 Python 里把 Agent 邏輯用 FastAPI 寫(xiě)通再將性能敏感的核心模塊用 Rust 替換。這次項(xiàng)目我是一開(kāi)始就定了 Rust因?yàn)槟繕?biāo)是把它作為一個(gè)長(zhǎng)期服務(wù)跑在內(nèi)網(wǎng)基線(xiàn)環(huán)境里省得后面再遷一次。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 離線(xiàn)大模型部署與量化選型隔離內(nèi)網(wǎng)部署 Agent第一關(guān)是模型文件怎么進(jìn)去。我在實(shí)際操作中的流程是在可以聯(lián)網(wǎng)的辦公機(jī)器上下載模型校驗(yàn) SHA256 哈希然后通過(guò)審批流程拷入內(nèi)網(wǎng)中轉(zhuǎn)機(jī)再分發(fā)到 GPU 服務(wù)器。這里特別提醒模型文件動(dòng)輒幾個(gè) GB 到幾十 GB一定要先做哈希校驗(yàn)再搬運(yùn)。我遇到過(guò)一次 U 盤(pán)拷貝的文件損壞模型加載到一半就報(bào)非法指令排查了一整天才發(fā)現(xiàn)是文件壞了。模型選型上我給了團(tuán)隊(duì)一個(gè)優(yōu)先級(jí)通用對(duì)話(huà)用 Qwen 系列或者 DeepSeek 系列這兩個(gè)系列對(duì)中文支持好且都有開(kāi)源授權(quán)可以?xún)?nèi)部商用代碼生成場(chǎng)景用 CodeLlama 或者 Qwen-Coder代碼能力明顯強(qiáng)于通用模型如果只是做簡(jiǎn)單意圖識(shí)別和工具調(diào)用7B 到 14B 的量化模型足夠不需要盲目上 70B。量化這一步特別重要。我的測(cè)試機(jī)器是一張 24GB 顯存的卡如果跑 FP16 的 14B 模型顯存直接爆掉。后來(lái)把模型量化成 GGUF 格式的 Q4_K_M文件體積縮到原來(lái)三分之一單卡能穩(wěn)定運(yùn)行生成速度反而因?yàn)轱@存占用降低而提升。要注意的是量化不是越高越好Q4_K_M日常使用的均衡點(diǎn)質(zhì)量損失可接受文件小Q5_K_M質(zhì)量要求高、顯存還夠的時(shí)候用Q8_0幾乎無(wú)損但文件大適合小模型或顯存很寬裕的場(chǎng)景。如果模型要跑 RAG 或者 Agent 工具調(diào)用我建議保底用 Q5_K_M因?yàn)楣ぞ哒{(diào)用對(duì)格式的穩(wěn)定性要求很高過(guò)度的量化會(huì)導(dǎo)致輸出 JSON 不合法。2.2 Skill 機(jī)制與函數(shù)調(diào)用怎么寫(xiě)Agent 能干活的核心是“工具調(diào)用”業(yè)界也叫 function calling有的框架里把一組工具封裝成“Skill”。在隔離內(nèi)網(wǎng)環(huán)境里Skill 不是錦上添花而是 Agent 為數(shù)不多能觸達(dá)真實(shí)業(yè)務(wù)的途徑。我見(jiàn)過(guò)不少失敗案例模型本身很聰明但工具定義寫(xiě)得一塌糊涂模型根本不知道該調(diào)用哪個(gè)、參數(shù)該怎么填。寫(xiě)好一個(gè) Skill 的關(guān)鍵是把函數(shù)的描述和參數(shù) Schema 寫(xiě)得極其詳細(xì)。舉個(gè)例子我寫(xiě)了一個(gè)“查詢(xún)內(nèi)網(wǎng)服務(wù)器狀態(tài)”的工具參數(shù)定義是{ name: query_machine_status, description: 根據(jù)主機(jī)名或內(nèi)網(wǎng) IP 查詢(xún)服務(wù)器的在線(xiàn)狀態(tài)、CPU 和內(nèi)存占用。只有拿到明確的主機(jī)名參數(shù)時(shí)才調(diào)用沒(méi)有主機(jī)名直接告訴用戶(hù)需要補(bǔ)充。, parameters: { type: object, properties: { hostname: { type: string, description: 服務(wù)器主機(jī)名例如 ops-01必填 }, ip: { type: string, description: 內(nèi)網(wǎng) IP 地址例如 10.10.1.5可選 } }, required: [hostname] } }這里我特意寫(xiě)了一句“沒(méi)有主機(jī)名直接告訴用戶(hù)需要補(bǔ)充”這個(gè)看似啰嗦的說(shuō)明實(shí)際測(cè)試?yán)飿O大降低了模型瞎猜參數(shù)的概率。模型不是真“懂”你業(yè)務(wù)它是在根據(jù)描述做模式匹配描述越接近人類(lèi)的表達(dá)習(xí)慣匹配越準(zhǔn)。Skill 的執(zhí)行權(quán)限也要打磨。隔離內(nèi)網(wǎng)里數(shù)據(jù)金貴Agent 每次調(diào)用工具其實(shí)都在“動(dòng)手操作”。我做了一個(gè)簡(jiǎn)單的黑白名單只讀工具查詢(xún)類(lèi)可以直接執(zhí)行寫(xiě)操作工具改配置、發(fā)指令必須由人工確認(rèn)后再放行。這個(gè)設(shè)計(jì)在交付時(shí)特別加分安全團(tuán)隊(duì)看了眼睛都亮了。2.3 記憶與上下文工程Agent 聊著聊著就“失憶”是內(nèi)網(wǎng)部署時(shí)最容易暴露的問(wèn)題。因?yàn)槟Ｐ陀猩舷挛拇翱谏舷迺?huì)話(huà)一長(zhǎng)早期的關(guān)鍵信息會(huì)被擠掉。我在這**個(gè)項(xiàng)目里把記憶分成兩層短期記憶就是當(dāng)前會(huì)話(huà)窗口內(nèi)的對(duì)話(huà)內(nèi)容直接拼接進(jìn)上下文喂給模型但要做滑動(dòng)窗口裁剪只保留最近幾輪。長(zhǎng)期記憶把用戶(hù)偏好、關(guān)鍵結(jié)論、實(shí)體信息存入內(nèi)網(wǎng)數(shù)據(jù)庫(kù)或者向量庫(kù)在每輪對(duì)話(huà)開(kāi)始前根據(jù)當(dāng)前問(wèn)題做相似度檢索把相關(guān)的歷史片段注入上下文。這種記憶架構(gòu)代碼量不大但收益非常明顯。我們的 Agent 服務(wù)里用戶(hù)經(jīng)常第二次登錄后問(wèn)“上次幫我查的那個(gè)服務(wù)器現(xiàn)在怎么樣了”如果沒(méi)有長(zhǎng)期記憶模型只能裝傻有長(zhǎng)期記憶它能從向量庫(kù)里撈回上次討論的主機(jī)名再做一次實(shí)時(shí)查詢(xún)這不就是真實(shí)有用的 Agent 體驗(yàn)。上下文裁剪還有一個(gè)重要原則相關(guān)的保留不相關(guān)的果斷丟棄。有些團(tuán)隊(duì)圖省事把所有歷史對(duì)話(huà)全塞給模型結(jié)果上下文爆炸模型反而抓不住重點(diǎn)。我在實(shí)現(xiàn)里做了個(gè)摘要機(jī)制超過(guò)窗口長(zhǎng)度后先把舊對(duì)話(huà)用模型生成一段壓縮摘要再把摘要加回上下文。實(shí)測(cè)下來(lái)摘要模式比簡(jiǎn)單截?cái)嗟臏?zhǔn)確率高不少。3. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 搭建最小可用的內(nèi)網(wǎng)智能體服務(wù)這一節(jié)我直接給出可以抄作業(yè)的流程完整走一遍從零到一的最小實(shí)現(xiàn)。第一步準(zhǔn)備一臺(tái) GPU 服務(wù)器。我們的配置是一張 24GB 顯存顯卡、64GB 內(nèi)存、1TB 固態(tài)操作系統(tǒng)是 Ubuntu 22.04。如果是純 CPU 環(huán)境只能跑 7B 量化模型速度大概每秒幾個(gè) token做那種不追求實(shí)時(shí)性的審批助手可以做對(duì)話(huà)體驗(yàn)會(huì)很吃力。第二步部署推理引擎。我用 Ollama 做演示因?yàn)樗鲜肿羁靸?nèi)置了對(duì) OpenAI 接口的兼容層。安裝很簡(jiǎn)單解壓后執(zhí)行一條命令即可。然后把模型文件用離線(xiàn)方式導(dǎo)入ollama serve # 在目錄里放入模型文件執(zhí)行導(dǎo)入 ollama create my-qwen --file ModelfileModelfile 里可以自定義模型的上下文長(zhǎng)度、溫度等參數(shù)。我一般把 context 設(shè)為 8192既保證對(duì)話(huà)連貫又不至于因?yàn)樯舷挛奶L(zhǎng)拖慢推理。第三步啟動(dòng)推理服務(wù)驗(yàn)證接口。Ollama 默認(rèn)監(jiān)聽(tīng) 11434 端口我用 curl 測(cè)一輪對(duì)話(huà)curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:my-qwen,messages:[{role:user,content:你好}]}看到正常的 JSON 返回推理層就通了。第四步寫(xiě)編排服務(wù)。用 Rust 做異步服務(wù)代碼邏輯可以抽象成這樣的循環(huán)async fn run_agent(user_input: String) - ResultString { let mut messages load_context(user_input).await?; loop { let resp llm_chat(messages).await?; // 判斷模型是否請(qǐng)求調(diào)用工具 if let Some(tool_call) resp.tool_calls { let result execute_tool(tool_call).await?; messages.push(format!(工具返回{}, result)); } else { return Ok(resp.content); } } }這里最關(guān)鍵的是“判斷模型是否請(qǐng)求調(diào)用工具”。我用的協(xié)議里模型會(huì)返回一個(gè)tool_calls數(shù)組里面包含函數(shù)名和參數(shù) JSON。代碼要做的就是從響應(yīng)里把這個(gè)數(shù)組解析出來(lái)先做合法性和權(quán)限校驗(yàn)再執(zhí)行對(duì)應(yīng)函數(shù)。我在這個(gè)階段踩過(guò)一個(gè)非常典型的坑模型的工具調(diào)用參數(shù)是 JSON 字符串里面嵌套了數(shù)組和轉(zhuǎn)義字符直接serde_json::Value解析會(huì)出現(xiàn)字段丟失。解決辦法是先校驗(yàn) JSON 語(yǔ)法再用強(qiáng)類(lèi)型結(jié)構(gòu)體反序列化任何一步失敗都向模型回傳“參數(shù)格式錯(cuò)誤請(qǐng)重新生成”。這個(gè)設(shè)計(jì)讓整個(gè)循環(huán)的穩(wěn)定性提升了太多。3.2 把內(nèi)部工具接進(jìn)來(lái)推理和編排跑通之后Agent 還只是個(gè)“會(huì)聊天的空殼”。真正體現(xiàn)價(jià)值的是把內(nèi)網(wǎng)里的系統(tǒng)接進(jìn)來(lái)。我這邊接了三個(gè)業(yè)務(wù)工具每個(gè)都不復(fù)雜數(shù)據(jù)庫(kù)查詢(xún)工具輸入自然語(yǔ)言或 SQL 條件工具內(nèi)部通過(guò)只讀賬號(hào)連上 MySQL執(zhí)行 SELECT 語(yǔ)句返回結(jié)果。整個(gè)過(guò)程嚴(yán)格遵守只讀限制賬號(hào)權(quán)限最小化。知識(shí)庫(kù)檢索工具內(nèi)部文檔系統(tǒng)導(dǎo)出成文本切塊后灌入向量數(shù)據(jù)庫(kù)。Agent 收到事實(shí)類(lèi)問(wèn)題時(shí)先向量檢索相關(guān)段落再把段落和問(wèn)題一起喂給模型。運(yùn)維狀態(tài)工具通過(guò)內(nèi)網(wǎng)接口讀取服務(wù)器監(jiān)控?cái)?shù)據(jù)返回 CPU、內(nèi)存、磁盤(pán)使用率。這些工具的接入路徑完全一致定義一個(gè) JSON Schema、實(shí)現(xiàn)一個(gè) Rust handler、注冊(cè)到工具列表里。注冊(cè)列表本身要傳給模型模型才知道有哪些工具可用。這里有一個(gè)內(nèi)網(wǎng)環(huán)境的特殊問(wèn)題傳輸給模型的工具描述不能太長(zhǎng)一次只能傳大約十幾個(gè)工具多了模型會(huì)“眼花”反而選錯(cuò)。如果工具數(shù)量超過(guò) 20 個(gè)我建議做工具分組先讓 Agent 判斷屬于哪個(gè)組再在該組內(nèi)選擇具體工具。3.3 并發(fā)、緩存與流式優(yōu)化Agent 部署到內(nèi)網(wǎng)后馬上會(huì)面臨真實(shí)用戶(hù)同時(shí)使用的壓力。推理引擎默認(rèn)是串行處理請(qǐng)求的一旦幾十個(gè)人同時(shí)問(wèn)問(wèn)題等候隊(duì)列會(huì)拉得很長(zhǎng)。我的優(yōu)化三板斧并發(fā)隊(duì)列在編排層為每個(gè)會(huì)話(huà)創(chuàng)建獨(dú)立任務(wù)異步等待推理結(jié)果而不是同步阻塞。Rust 的 Tokio 運(yùn)行時(shí)在這一層極其順手幾百個(gè)任務(wù)同時(shí)掛起也不占資源。前綴緩存內(nèi)網(wǎng)環(huán)境中很多用戶(hù)問(wèn)的問(wèn)題高度相似比如“員工的入職流程是什么”。我在編排層加了一個(gè)語(yǔ)義緩存相同的提問(wèn)在 24 小時(shí)內(nèi)直接返回歷史答案不再調(diào)用模型。實(shí)測(cè)緩存命中率能到 30% 左右GPU 壓力小了一大截。流式輸出把模型生成過(guò)程以 SSE 方式推給前端。用戶(hù)第一屏看到的是逐字出現(xiàn)的答案體驗(yàn)上比干等十幾秒再一次性返回好太多。實(shí)現(xiàn)上只要讓推理引擎以流式模式返回增量編排層做轉(zhuǎn)發(fā)即可。我在測(cè)試中還注意到推理引擎的批處理參數(shù)對(duì)吞吐影響很大。vLLM 在這點(diǎn)上比我用的 Ollama 更強(qiáng)它支持 Continuous Batching多個(gè)請(qǐng)求共享一個(gè) batch 計(jì)算吞吐能翻好幾倍。如果并發(fā)量超過(guò) 20 個(gè)同時(shí)在線(xiàn)建議把推理引擎換成 vLLM編排層不用動(dòng)因?yàn)樽叩亩际?OpenAI 兼容協(xié)議。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄實(shí)戰(zhàn)三個(gè)月我整理了一份問(wèn)題速查表基本上覆蓋了內(nèi)網(wǎng) Agent 項(xiàng)目里最高頻的故障。4.1 模型加載失敗與顯存不足模型加載到一半報(bào) OOM 或者 Illegal instruction這是最常遇到的。先說(shuō) OOM核心原因是模型量化檔位和顯存不匹配。我按經(jīng)驗(yàn)給一個(gè)估算公式顯存占用約等于模型參數(shù)量乘上量化后每參數(shù)字節(jié)數(shù)比如 14B 模型的 Q4 量化大約需要 14 × 0.5 7GB加上 KV Cache 和運(yùn)行時(shí)開(kāi)銷(xiāo)24GB 卡跑 14B Q4 很輕松。Illegal instruction 十有八九是 CPU 指令集不匹配或者模型文件損壞。解決辦法是在拷貝前算好 SHA256運(yùn)行前用工具檢測(cè) CPU 是否支持 AVX2。隔離內(nèi)網(wǎng)的舊機(jī)器經(jīng)常是五六年前的 CPU不支持新指令集我后來(lái)在部署腳本里直接加了一項(xiàng)硬件檢測(cè)。4.2 工具調(diào)用失靈與參數(shù)幻覺(jué)這是 Agent 項(xiàng)目里最讓人頭疼的問(wèn)題表現(xiàn)在模型明明調(diào)用了工具但參數(shù)完全是編的。比如查詢(xún)服務(wù)器狀態(tài)模型編了一個(gè)不存在的hostname。排查思路如下第一步檢查工具描述是否寫(xiě)清楚了字段的取值范圍和必填條件。描述里如果寫(xiě)了“如果不知道主機(jī)名請(qǐng)向用戶(hù)詢(xún)問(wèn)”基本能避免一半的幻覺(jué)。第二步檢查模型量化程度是否過(guò)高。我實(shí)測(cè) Q4 模型在簡(jiǎn)單工具調(diào)用上和 Q5 差距不大但涉及多個(gè)參數(shù)組合時(shí)Q5 明顯更少出錯(cuò)。如果業(yè)務(wù)對(duì)準(zhǔn)確性要求高直接上 Q5 量化。第三步加入工具結(jié)果校驗(yàn)。工具執(zhí)行后返回的錯(cuò)誤信息要原文喂回給模型讓它基于真實(shí)錯(cuò)誤修正調(diào)用參數(shù)。比如“查無(wú)此主機(jī)請(qǐng)確認(rèn)主機(jī)名”模型會(huì)意識(shí)地再問(wèn)用戶(hù)或者換一個(gè)工具。4.3 服務(wù)發(fā)現(xiàn)與日志觀測(cè)隔離內(nèi)網(wǎng)沒(méi)有現(xiàn)成的注冊(cè)中心的時(shí)候多個(gè) Agent 服務(wù)之間互相調(diào)用會(huì)非常麻煩。我的做法是統(tǒng)一維護(hù)一個(gè)靜態(tài)配置文件記錄所有內(nèi)部服務(wù)的內(nèi)網(wǎng) IP 和端口Agent 啟動(dòng)時(shí)讀取這個(gè)文件生成服務(wù)調(diào)用路由表。改動(dòng)配置時(shí)通過(guò)配置中心下發(fā)熱更新而不是停機(jī)重啟。日志觀測(cè)更要注意。隔離內(nèi)網(wǎng)不能接云端日志平臺(tái)我就在編排層自己做結(jié)構(gòu)化日志每條都帶上會(huì)話(huà) ID、模型調(diào)用耗時(shí)、工具調(diào)用結(jié)果、錯(cuò)誤碼。積累到本地日志系統(tǒng)后再用 Elasticsearch 或輕量級(jí)的 ClickHouse 做全文檢索。有一次用戶(hù)反饋“Agent 答非所問(wèn)”我查日志一看工具返回的是超時(shí)錯(cuò)誤但編排層沒(méi)把錯(cuò)誤傳給模型模型自己瞎編了一個(gè)答案。這就是日志的價(jià)值沒(méi)有日志這個(gè)問(wèn)題可能要在可視化界面上猜好幾天。再分享一個(gè)可觀測(cè)性的小工具在每個(gè) Agent 請(qǐng)求入口打一個(gè)唯一 request_id全鏈路所有日志帶上這個(gè) ID排障時(shí)只要拿到一個(gè) ID 就能串出完整鏈路。寫(xiě)在最后隔離內(nèi)網(wǎng)做 AI Agent最大的認(rèn)知轉(zhuǎn)變是不要把它當(dāng)成聯(lián)網(wǎng)應(yīng)用來(lái)做而是當(dāng)成一個(gè)內(nèi)網(wǎng)基礎(chǔ)設(shè)施來(lái)運(yùn)營(yíng)。模型、依賴(lài)、工具、日志、安全邊界每一層都要有離線(xiàn)預(yù)案。我個(gè)人體會(huì)最深的是公網(wǎng)環(huán)境下隨便能用 pip 裝依賴(lài)、隨便能用云端打標(biāo)注到了隔離內(nèi)網(wǎng)全都要提前打包、提前審批、提前驗(yàn)證。這種約束反而逼著你把所有外部依賴(lài)都鎖死、把每個(gè)環(huán)節(jié)都文檔化系統(tǒng)穩(wěn)定性和可維護(hù)性因此高了一個(gè)檔次。最后再分享一個(gè)細(xì)節(jié)這個(gè)項(xiàng)目里我沒(méi)有用任何復(fù)雜度高的編排框架核心循環(huán)用 Rust 手寫(xiě)也就是一兩百行的事情。框架帶來(lái)便利的同時(shí)也帶來(lái)了隱藏深度在沒(méi)法搜文檔、沒(méi)法問(wèn)外網(wǎng)社區(qū)的內(nèi)網(wǎng)環(huán)境里越是自己可控的原生代碼越能讓你在深夜排查問(wèn)題時(shí)睡得著覺(jué)。如果你的團(tuán)隊(duì)也面臨同樣的隔離環(huán)境建議從最小閉環(huán)開(kāi)始先把一個(gè)技能鏈路跑通再慢慢往上加記憶、加并發(fā)、加更多工具。這條路并不快但穩(wěn)。