上周刚把一个基于RAG的AI Agent从开发机迁进某单位的隔离内网从模型搬运到链路调通前前后后折腾了两周。白天在内网机房里对着显卡驱动和离线依赖较劲晚上回工位补文档整个过程远比想象中麻烦。这篇文章把我踩过的坑、验证过的方案、留下来的配置原原本本梳理一遍给后面要在隔离内网环境里做AI Agent落地的同行一个参考。你可以把这篇东西当成一份“离线交付复盘”。不管你是要在政企内网、医疗数据域、能源生产网这类物理隔离环境里部署Agent还是产品本身要打包成私有化交付物交给客户文章里的思路都能直接复用。全文不涉及任何在线服务依赖所有组件都以离线介质方式进入目标网络讲清楚“模型怎么搬、依赖怎么补、Agent怎么编排、出了问题怎么查”这条完整链路。1. 隔离内网里跑Agent先想清楚这四件事1.1 隔离不是“没网”是“渠道单一”很多人一听“隔离内网”第一反应是“没网怎么跑大模型”。实际上隔离内网里基础设施比想象中齐全有DNS、有内部NTP、有企业级软件源镜像、有统一的日志平台甚至可能有算力集群。缺的只是一条通向公网的出口。这个区别决定了Agent工程的打法。在外网环境里做AI Agent缺什么就pip install、拉个镜像、下个模型顺手得很。进了隔离内网每一次依赖引入都要提前规划模型文件通过什么介质进入、Python包走离线whl还是内网PyPI镜像、容器镜像用docker save还是直接重新构建、模型推理依赖的CUDA和驱动版本由谁提供。所以第一件事不是写代码而是把Agent运行所需的全部物料列成清单逐项确认来源。我在项目里是分成四类来盘的物料类别典型内容进入内网的方式模型权重LLM主模型、Embedding模型、重排模型导出后经隔离介质光盘/专用摆渡U盘导入运行时Python解释器、CUDA驱动、gcc、Rust工具链内网软件源或离线安装包依赖包PyPI wheels、crates、npm包pip download离线打包、cargo vendor容器资产Docker镜像、Helm Chart、模型镜像docker save后再docker load这个表看起来啰嗦但漏掉任何一项都可能让整条链路卡住。我第二次进现场时所有代码和模型都拷好了结果发现Agent框架依赖的一个系统库在目标机器上缺失而机器没有外网权限只能回头重新走审批流程补介质。这类事情一次就长记性。1.2 先画部署拓扑再谈Agent能力隔离内网环境里Agent从来不是“一个进程”那么简单它是多层服务协作的产物。我的建议是进场第一步先画部署拓扑明确每个组件落在哪台机器上、走什么端口、依赖谁。一个典型的隔离内网Agent部署拓扑长这样GPU推理节点跑vLLM或Ollama承载主模型和Embedding模型的推理服务端口通常用8000/11434这类固定端口CPU应用节点跑Agent编排服务、API网关、任务队列这里要求不高32核64G起步向量数据库节点Milvus单机版或Elasticsearch存知识库切片工具服务节点内网的订单系统、工单系统、数据库代理Agent通过HTTP调用这些接口拓扑确定之后Agent的每个动作都能映射到具体节点和服务上。POC阶段最容易栽的坑就是用开发机的架构去套生产环境。开发机上模型和代码在同一台机器、Redis和向量库都在本机一切“正常”一进隔离内网就发现网络策略没开、跨节点调用超时、共享存储权限不对——这些事故拓扑规划阶段就该用一张网络策略申请单解决。我的习惯是画完拓扑马上去申请网络策略列出每一对“调用方-被调用方”的IP和端口。隔离内网对端口管控极严申请流程又长这事越早做越省心。2. 离线模型与依赖供给先把“家底”盘清楚2.1 模型文件怎么合法合规地搬进内网模型是整个Agent的大脑但模型文件也往往是体积最大、搬运最痛苦的物料。以7B模型为例FP16权重约14GB带分词器和配置一起打包后通常16GB左右如果做RAG还要加Embedding模型几百MB到1GB不等和重排模型。一个完整的Agent方案模型物料轻松超过30GB。搬运方案我按介质类型给三个选择光盘DVD/蓝光适合单文件不超过4.7GB/25GB的场景缺点是写入慢、容量受限专用摆渡U盘大多数单位允许用登记过的U盘导数据速度快、可反复使用隔离网闸/光盘摆渡一体机如果单位有自动化摆渡设备走流程审批后效率最高模型文件进入内网后第一件事是校验哈希。模型在源端下载时记录SHA256进内网后重新计算比对防止传输损坏或介质异常。这一步不能省我遇到过Embedding模型文件损坏但体积看起来正常的场景跑起来才发现向量维度全是NaN排查了整整一个下午。模型选择上给个实操建议内网Agent尽量选允许商业使用的开源模型同时把模型来源、许可证、版本号写进交付文档。你不想在项目验收时被问“这个模型哪来的、授权链条是什么”时答不上来。现在主流通用模型在7B/14B这个档位上中英文问答和工具调用已经足够支撑业务Agent使用。2.2 Python依赖、Rust工具链与容器镜像的离线准备先聊Python依赖。千万别指望内网有完整的PyPI镜像很多单位的内网源包不全。我在外网开发机上用pip download把项目依赖全部拉下来指定目标平台和Python版本命令大致这样pip download -r requirements.txt -d ./offline_packages \ --platform manylinux2014_x86_64 \ --python-version 3.10 \ --only-binary:all:这样会得到一个纯whl文件的目录进内网后一条命令装完pip install --no-index --find-links./offline_packages -r requirements.txt要点是加--only-binary:all:防止把需要现场编译的源码包带进去。隔离内网机器上往往没有完整编译工具链你不想现场编译pydantic-core这类Rust扩展编一次半小时起步。如果确实存在没有预编译whl的包那就只能在外网准备好对应平台的wheel再带入内网。Rust工具链的离线准备相对简单。Rust官方支持cargo vendor把依赖连同license一起打成vendor目录cargo vendor ./vendor然后在工程里配置.cargo/config.toml使用本地vendor源。全程不联网编译时间也比在线拉取稳定很多。如果你的Agent用Rust写这一步几乎是必须的。容器镜像推荐一个省事的方法在外网把镜像构建并验证好后docker save成tar包进内网再docker load。注意save的时候用docker save -o导出整个镜像不要用export——export丢层启动必翻车。docker save -o agent_all_in_one.tar agent_all_in_one:1.0 # 内网侧 docker load -i agent_all_in_one.tar如果你连Docker Hub都不能访问可以在外网配代理后docker pull或者要求对方提供内网私有镜像仓库地址。有的单位有Harbor那最舒服直接把镜像push到内网仓库即可。2.3 算力规划显存怎么算Agent跑得动跑不动取决于显存怎么分配。我总结了一个快速估算公式适用于大多数主流模型所需显存 ≈ 模型参数量 × 每参数字节数 × 系数(KV Cache等开销)FP16精度下每参数2字节INT8量化下每参数1字节INT4量化下每参数约0.5字节举例说明一个7B模型FP16推理纯权重就要14GB加上KV Cache和激活值单并发下16-20GB显存是底线。14B模型FP16对应28GB权重单卡24GB放不下必须量化到INT8约14GB。 实际项目里还有并发需求每增加一路并发KV Cache开销线性增长所以“能放进去”和“能跑业务”是两回事。选型经验内网Agent起步阶段建议用7B-INT8或14B-INT8级别模型配一张24GB显卡单卡搞定主模型。Embedding模型放CPU跑即可开源Embedding模型在CPU上做批量向量化速度完全够用。把GPU资源让给主模型无论是响应速度还是上下文长度体验都好很多。3. Agent核心引擎编排架构与token理解3.1 主流Agent架构怎么选AI Agent的主流架构拆开看就四种ReAct推理-行动循环、Plan-and-Execute先规划再执行、多智能体协作Multi-Agent、以及Graph/Workflow编排。隔离内网环境里选哪种我的判断标准是看工具链规模和业务确定性。如果Agent只需要调用两三个工具比如查库存、查订单、回答制度问题ReAct单Agent架构足够一个循环里反复推理-调用-观察-再推理如果Agent要处理复杂任务比如“帮我写一份招标分析报告”需要检索文件、做图表、生成摘要等多个步骤Plan-and-Execute更合适。先让模型生成步骤清单再逐个步骤调用工具如果业务本身就是多角色协作比如售前咨询、售后处理、技术专家三个角色协同才需要考虑多智能体架构。多智能体在隔离内网里的通信成本和管理复杂度会明显上升我给这个项目的选型是Plan-and-Execute加ReAct混合先用规划模块把用户意图拆成任务列表每个任务内部用ReAct循环执行。好处是主线清晰、中途可控坏处是链路过长时token消耗大所以后面还要配合上下文管理。3.2 为什么有人用Rust写Agent有人非Python不可最近关于“Rust写Agent”的话题热度很高。从工程角度看Rust写Agent的优势非常具体编译产物是单一二进制扔到内网任何x86机器上直接跑不需要解释器、不需要装依赖内存占用比Python的进程模型低一个量级线程处理高并发请求更稳。但Rust生态相比Python还是落后一截。LangChain、LlamaIndex、MCP的Python SDK成熟度和例程量都远超Rust。如果你团队里全是Python出身强行Rust等于自找苦吃。我的建议是分层混搭调度骨架、通信层、鉴权路由这种“离业务远”的模块用Rust写稳、省资源、易部署策略逻辑、工具解析、Prompt模板这类“离模型近”的模块用Python写迭代快隔离内网对性能和资源敏感这种混合架构能兼顾稳定性和开发效率。实际操作中我见过有人用一个Rust写的轻量调度器去启停Python子进程通过内部HTTP或Unix Socket通信既拿到了Rust的稳定也没丢掉Python的便利。3.3 token是什么为什么在Agent里要盯紧它很多刚接触Agent的同事会问“token是什么意思”。简单说token是模型处理文本的基本单位。英文里一个单词通常拆成1-2个token中文里一个字大约占1-2个token。你调用一次模型传入的Prompt和返回的结果都会被换算成token数量同时受模型上下文窗口限制。在Agent里token消耗比单纯聊天恐怖得多。因为Agent每一轮工具调用都要把“系统提示词历史对话工具调用过程工具返回结果”全部重新发给模型。我做过一次统计一个Plan-and-Execute架构的Agent完成“查询订单并发邮件”这种任务前后4轮工具调用累计消耗超过8000 token。如果模型上下文窗口是32K看起来还够但Agent执行中途还要追加知识库检索片段往往不够用。所以隔离内网的Agent一定要做三层控制对话历史裁剪超过N轮就摘要压缩而不是无脑拼全文工具结果截断只截取关键字段不要让数据库返回的几百行灌进Prompt上下文预算分配给知识库片段分配固定占比比如30%其余留给工具调用和对话我用过一个简单技巧在Prompt模板里加一个context_limit变量每次工具调用的结果先做字符串截断限制在500字符以内。大多数业务场景根本不需要把完整查询结果丢给模型给它前五行“最重要数据”就够。单独说一个数字概念如果你用7B模型跑Agent上下文窗口通常是8192或32768。一个上下文窗口的token不只是吃显存还直接影响响应速度。把token管好Agent的速度能快一倍。4. 把知识库和工具接成Agent的“手和脚”4.1 RAG在隔离内网怎么做Agent要回答业务问题光靠模型训练时学到的知识远远不够必须接入内部知识库。这就是RAG检索增强生成的活儿。隔离内网里做RAG和公网的区别在于Embedding模型必须离线跑向量数据库必须选内网可部署的版本文档切分规则要贴合业务。我用的是这套链路文档解析PDF/Word/Excel统一转成纯文本用内网部署的解析服务不要用在线文档API文本切分按章节和段落切块单块控制在200-500字块之间保留少量重叠向量化用本地Embedding模型对每块文本生成向量存库写入Milvus或Elasticsearch元数据里带上文档来源、部门、更新时间检索用户提问后同样用Embedding模型向量化问题从向量库召回TopK重排用重排模型或简单的BM25混合对召回结果打分取前3-5块作为上下文实测下来切分规则对回答质量的影响比选哪个向量库大得多。内网制度文档、产品手册、操作指南这三类文档的切分策略都得单独调。制度文档按条款切产品手册按功能模块切操作指南按操作步骤切。千篇一律按固定字数切检索出来的东西上下文割裂Agent引用起来就会胡说。4.2 工具调用的落地姿势Agent在隔离内网里能做什么完全取决于你能给它接什么工具。不像公网有几百种现成API内网工具大多是自研系统、老旧Web Service、数据库存储过程。接入方式五花八门但落到Agent视角无非是把它们抽象成API。我的建议是用MCPModel Context Protocol的思路来统一工具暴露层。不需要引什么重框架核心思想是给每个工具写一份JSON Schema描述工具名、参数结构、返回格式、用途说明。Agent根据描述决定要不要调用、传什么参数。举一个实际例子我做一个“订单查询Agent”它的工具注册表里有一项{ name: query_order, description: 根据订单号查询订单状态和物流信息, parameters: { type: object, properties: { order_id: { type: string, description: 完整订单号 } }, required: [order_id] } }Agent看到这个描述后用户说“查一下订单123456”它会自动把语义转成工具调用query_order(order_id123456)。工具返回值再回到上下文由模型生成自然语言回复。隔离内网调用工具要额外做三件事设置超时建议短工具5秒、长任务30秒以上、做重试指数退避、对所有工具返回做格式清洗。内网系统稳定性参差不齐500、504、连接超时都是家常便饭Agent调度层要能容忍偶发故障而不是一失败就整体崩溃。4.3 一个完整的客服问答Agent样例拿“隔离内网客服问答Agent”举例把它完整跑一遍用户提问帮我查一下工单5678的处理进度顺便告诉我责任人的联系方式。Agent的处理流程意图识别判定为“查询信息获取”复合意图生成计划Step1调用工单查询工具Step2根据返回结果判断是否需要查询通讯录调用工具query_ticket(ticket_id5678)返回工单状态“处理中”检查返回结果发现缺少责任人联系方式触发第二步调用query_employee(owner张三)汇总输出生成最终回答“工单5678当前状态处理中责任人是张三电话分机8088”这个流程看着简单但每个中间步骤都在消耗token和时间。如果知识库里恰好有一份“工单处理标准答复模板”RAG检索会把这部分内容塞进Prompt让Agent措辞更规范——这就是RAG和Agent结合的价值。隔离内网环境里建议把这类高频流程固化成“Agent技能模板”预置好工具调用顺序和Prompt模板避免每次都由模型自由发挥。模型的自由发挥意味着不可控的token开销和偶发错误在交付项目里“稳定且可解释”比“智能且灵活”重要得多。5. 常见问题与排查实录5.1 我踩过的六个坑第一个坑是GPU显存看着够用但并发后OOM。7B模型FP16部署后单并发占用约15GB显存加一路并发KV Cache多占2GB左右。如果上线后发现显存不足优先检查是否没有开启vLLM的continuous batching或者并发参数设得太大。第二个坑是Embedding模型话太多。有的Embedding模型在预处理阶段会打印大量日志每条日志都带时间戳严重拖慢批量向量化速度。解决办法是把日志级别调到ERROR顺手关掉进度条。第三个坑是离线源里缺个别包。pip download拉下来一堆whl客户环境装到一半发现某个传递依赖没有。解决方法是装完后立刻跑一遍pip check把所有缺漏补一次再提交交付物。第四个坑是工具调用超时。内网老系统的接口响应经常超过10秒Agent直接把这次调用判定为失败最后回答用户“查询不到”。针对稳定系统可以把超时放宽到30秒并加一次重试。第五个坑是上下文被历史对话冲爆。Agent跑了二十几轮后模型开始遗忘最初的系统指令回答风格漂移。解决办法是在每轮对话时做History摘要把旧内容压缩成一段短摘要保留。第六个坑是安全审查不通过。项目交付时对方安全团队要求Agent记录所有工具调用日志、模型可解释性说明、越权访问防控机制。这些最好从设计阶段就加事后补往往很被动。5.2 排查速查表现象可能原因排查命令/手段解决方案模型加载失败权重文件损坏sha256sum对比源端哈希重新导入模型介质首token延迟高GPU未启用/精度设置过高nvidia-smi查看GPU利用率开启vLLM、调整量化精度回答开始胡编知识库未命中/上下文过长查看检索recall结果优化切分规则、增大检索TopK工具调用总是失败超时/鉴权/网络策略curl手动调工具服务调整超时参数、核对网络策略内存泄漏式增长Python进程未释放旧会话观察内存曲线定时重启Worker或用Rust做调度层并发一上来就卡模型推理服务未做并发配置查看推理服务日志开continuous batching限制max_concurrency5.3 离线部署的验收清单项目收尾前我通常按这个清单自查也建议你直接用模型文件哈希校验通过许可证文档齐全所有Python/Rust依赖已打入离线包pip check无报错镜像已load进内网仓库并且能docker run起来模型推理服务启动后用内网测试脚本连续拨打100次P99延迟达标知识库完成首轮索引构建检索测试覆盖Top10高频问题工具调用全部连通超时和重试机制生效日志按天滚动工具调用记录完整可追溯启动脚本和部署文档在内网环境实际演练过一遍我个人在实际操作中的体会是隔离内网下做AI Agent最难的不是算法也不是模型而是把一条链路上的每一项“隐形依赖”都暴露出来并逐一解决。先别追求多智能体协同、别追求花哨的推理框架老老实实把一条“提问-检索-调用工具-生成回答”的链路跑通跑稳跑得可监控再考虑扩展能力。这套活儿本质上拼的是工程组织的细致程度谁把离线物料和网络策略梳理得越早谁在现场就越从容。