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