隔离内网部署AI Agent光模型下载就够喝一壶的更别提Skill编排、工具调用、镜像拉取这些连锁问题。这篇实战笔记就是把我在产线环境里从零搭起一套Agent服务的完整过程复盘一遍从架构选型到踩坑修复都摊开讲希望能给正在做同类项目的人省点弯路。1. 先想清楚隔离内网里的Agent到底卡在哪几环1.1 隔离环境给Agent带来的三个现实约束先说背景。这次项目面对的是一个完全隔离的机房网络物理上与公网断开只有一台跳板机做审批流后的文件摆渡。要在这种环境里落地AI Agent第一个要解决的问题不是模型聪不聪明而是整套链路能不能闭环。约束一模型权重和依赖包怎么进网。Agent要跑起来模型文件少则几个GB多则几十GB加上Python依赖、容器镜像、各类工具链全部要经过审批、刻盘、摆渡、校验这个过程。一次漏传一个依赖版本后面就是连环炸。约束二工具调用接不到外部系统。Agent的价值一大半在能干活干活意味着要调内部工单API、查询数据库、读写内部知识库。这些系统在隔离网里往往没有统一网关接口协议五花八门Agent适配成本比想象中高很多。约束三运行时环境带病上线。隔离网里的机器通常没有外网源可配pip、apt、npm全都要走离线镜像。一旦某个间接依赖没有被提前打包动手装的时候才发现缺包整个排期就被动。所以做这类项目我建议动手前先画一张部署边界图哪些组件放内网哪些允许通过摆渡间接更新哪些干脆不碰网络。我的边界划分是这样——Agent运行时和模型推理服务全放内网知识库、工单系统走内网已有接口只有模型权重和依赖包的更新走摆渡流程。1.2 一张拓扑图讲清楚部署边界不画正式拓扑了用文字把边界说清楚。核心节点有三个模型推理服务放在一台带GPU的GPU服务器上跑开源模型权重比如DeepSeek系蒸馏版本对外只暴露一个HTTP端口供内网Agent调用。Agent运行时放在一台普通服务器上承载对话编排、工具调度、上下文管理它只访问三样东西——模型服务地址、内部API网关、向量数据库。内部API网关把工单系统、搜索系统、通知系统这些已有服务做一层统一封装Agent不直接连业务库一律走网关。这三个节点之间用内网DNS互相解析不需要任何公网链路。这版设计的基本原则是Agent吃到的每一口数据都来自内网可信源模型的权重和配置全部本地化。1.3 先从最小可用闭环开始头一回在隔离环境做Agent千万别一上来就规划全套多模态、大而全的Skill市场。我的建议是先用最小的功能闭环验证链路通不通。我当时的闭环是用户在内网IM里发一条工单申请 → Agent识别意图 → 检索内部知识库找标准填单模板 → 调用工单API完成创建 → 把回执返回用户。这五步虽然看起来简单但它覆盖了Agent最关键的三个能力——意图理解、知识检索、工具调用。链路通了后面加能力只是堆积木链路不通模型再强大都是摆设。注意隔离网里做Agent链路验证顺序比功能丰富度重要得多。宁可先做一个土到掉渣但能跑的闭环也别先堆一堆花哨Skill然后发现模型服务根本调不通。2. 运行时选型Rust和Python混搭这个场景下我为什么这么选2.1 Python生态的天然优势与内网痛点AI Agent领域的主流框架和中间件十有八九是Python写的。LangChain、LlamaIndex、各类Agent SDK生态非常成熟社区例子多遇到问题搜一下就有答案。这确实是Python最硬的优势。但搬到隔离内网里Python这套就有三个明显痛点一是依赖解析麻烦。一个Agent项目进来十几MB代码requirements.txt拉出来一两百个间接依赖。内网没有PyPI源全走离线轮子打包的话光是选对每个依赖的版本号、处理依赖冲突就得花掉不少工时。二是部署环境敏感。Python对系统python版本、libc版本、OpenSSL版本都有要求稍微偏一点就起不来。隔离网里运维环境经常是老CentOS、老glibc跑新版Python应用经常被绊倒。三是资源占用偏高。Agent运行时本来就常驻内存如果用Python做编排层一个进程吃几百MB是常态内网机器配置普遍一般多开几个实例就紧张。2.2 Rust在隔离环境的独特价值Rust这边的情况是反向的。它的生态比Python薄很多现成的Agent编排库少得可怜很多能力需要自己手搓。但它在隔离内网里的工程价值非常高。最直接的优点是编译产物是单一静态二进制可以做到完全不依赖目标机的Python环境、库版本、系统组件。我编译好的Agent编排服务直接拷贝到内网机器上就能跑唯一要保证的是目标系统的glibc版本别太老实测2.17以上基本都能跑。这就把内网装依赖这整个环节直接绕过去了。Rust的另一个价值是并发能力。Agent要同时处理多个会话、多个工具调用Rust的异步运行时tokio在这类IO密集型场景下表现非常好几十路并发吃的内存比Python同规模场景低一个量级。内网机器的资源本来就不宽裕省一点是一点。还有一个隐藏优点安全性和稳定性。隔离网里出问题排查链路很长Rust编译期就能挡掉空指针、数据竞争这些问题运行期出诡异bug的概率比动态语言低很多。我在内网环境里线上panic的次数比以前用Python跑服务时少太多了。2.3 我在生产里用的混合架构实际操作上我没有走全Python或者全Rust这种非此即彼的路线而是按组件分层编排层用Rust负责接收用户请求、维护会话上下文、调度Skill、调用模型服务。这一段对稳定性要求最高用Rust把核心链路焊死。离线数据处理用Python知识库的文本清洗、向量化预处理、批量导入这些一次性或低频任务用Python写起来效率最高跑完就结束不常驻。模型服务独立成层推理框架用什么语言写的不重要关键是把HTTP服务能力暴露出来任何语言都能调。这样分层的好处是高频、常驻、稳定性要求高的部分由Rust兜底低频、逻辑复杂、开发速度优先的部分用Python加速模型层只认协议不绑定语言。我跑了大半年这套结构非常稳。2.4 选型对照表我整理了一个简单的选型对照方便你根据自己团队的情况判断维度Python方案Rust方案我的建议开发速度快生态丰富慢需手搓组件小团队原型可以Python优先部署复杂度高依赖解析麻烦低单二进制拷贝即用隔离网优先考虑Rust资源占用高低内网机器紧张选Rust生态成熟度很成熟偏早期Agent能力扩展靠Python补排查难度运行时错误多编译期挡掉很多坑链路不可自查时Rust更省心提示如果团队里没人写过Rust不要硬上。可以在编排层用Python但把部署流程做成容器镜像整体摆渡用Docker镜像把依赖全部锁进一层。这也是可行的替代方案。3. 模型层落地把DeepSeek系权重装进内网服务器的完整链路3.1 权重选择与量化策略模型是Agent的脑子这块选不对后面全白干。在隔离内网里我优先推荐DeepSeek系的开源可商用权重。原因很简单效果够用、权重可控、社区资料多。具体型号选择要看你的硬件条件有单张24GB以上显存的GPU直接上32B级别的量化版处理复杂指令和长上下文都更稳。只有16GB显存的卡用14B级别的Q4量化版本日常工单处理、知识问答完全够。纯CPU机器跑只能考虑7B级别的Q4量化速度慢一点但作为特定任务的专用模型可以接受。权重下载要在公网环境搞定比如家里、办公网下载完后做SHA256校验——我吃过一次亏摆渡到内网才发现文件损坏白跑一趟流程。校验完再用摆渡机刻盘或走审批流进入内网。量化工具我用过GGUF格式配合llama.cpp/Ollama也用过AWQ、GPTQ的方案。说实话在通用任务上Q4_K_M的GGUF性价比最高显存需求低速度尚可模型质量损失在可接受范围内。真要追求极致质量再上FP16/AWQ。3.2 模型服务框架Ollama还是vLLM模型权重进来了还得有一个推理服务框架把它跑成HTTP API。内网场景我在Ollama和vLLM之间选择了Ollama作为主力。Ollama的优势是一条命令启动、模型管理简单、自带OpenAI兼容接口。对于Agent场景来说调用方只需要一个兼容Chat Completions协议的接口Ollama完全够用。而且它对显存的利用更佛系不追求极致吞吐反而适合内网这种并发量不高、稳定性优先的环境。vLLM强在高并发和吞吐优化适合多用户高频调用的场景。但它在内网的部署复杂度明显高——依赖torch全家桶、CUDA版本要匹配、显存规划不好容易OOM。如果团队没有专门的推理优化经验不建议一上来就用vLLM。我的部署方式是先装Ollama用一条命令拉取本地模型索引然后启动服务并监听内网IP地址最后用curl从同一内网的另一台机器发请求验证。全流程不超过十分钟。启动后要把服务绑定到0.0.0.0而不是默认的127.0.0.1否则Agent服务在另一台机器上永远连不上——这个坑我在后面专章讲。3.3 Skill机制把Agent能力插件化离线也能装技能搜索引擎里经常看到DeepSeek harness附带skill怎么部署到内网服务器这类问题。这里说的harness就是Agent的编排框架、Skill就是挂在Agent身上的能力插件。部署Skill的本质是把Agent从聊天机器人升级成能干事的工作流执行器。我在内网部署Skill分三类第一类系统类Skill。比如查服务器状态、执行定时任务、解析日志。这类Skill的后端逻辑写好后编译进Agent主程序配置一个描述文件声明这个Skill能干什么、需要什么参数Agent识别到用户意图后就会按需调用。第二类业务类Skill。比如创建工单、查询库存、发送通知。核心逻辑不是写在Agent里而是写在内网API网关的某个服务上。Skill只做一件事把用户请求映射成API调用参数再把API结果格式化成用户能看懂的回答。相当于Skill是手、网关服务是工具。第三类知识类Skill。基于向量数据库的检索增强能力Agent在处理问题时先从隔离网内的知识库捞相关文档片段再拼进上下文交给模型生成答案。这类Skill对内网专属知识的支撑最关键。Skill的配置文件我建议用JSON格式结构固定name、description、parameters、command或api_endpoint。Agent运行时读这个文件来决定什么情况下该调用哪个Skill。注意Skill描述写得越清楚Agent调用得越准。我遇到过Skill描述太模糊导致模型胡乱调用的情况比如把查天气的Skill拿去应答查工单的请求。把description写成类似即使内部工单系统状态参数为工单编号work_order_id这样带参数的句子误调用率会直线下降。3.4 验证闭环从模型层打到业务层模型服务和Skill都就位后一定要做一次端到端验证而不是只测模型对话。我的验证流程是这样的先从Agent运行时直接发起一次模型调用确认接口通然后调用一个纯内部的计算Skill确认工具链路通最后模拟真实场景让Agent自己去理解需求→检索知识→调Skill→返回结果。隔离网环境里出问题最麻烦的就是不知道是哪一层挂的。所以我的做法是每一层都留一个专门的诊断接口模型层有health接口编排层有debug日志网关层有统一的traceID。链路一通到底出问题十分钟内能定位。4. 内网穿透在这个场景里的真正用途远程联调与临时接入4.1 先说清楚穿透解决的是访问问题不是网络依赖问题内网穿透这个词很敏感我先限定一下边界这里讨论的是内网开发场景里开发人员需要从外部网络接入内网测试环境进行远程联调这一合法且高频的需求——比如出差时临时要看一眼内网Agent服务的运行日志、给客户演示时让外部网络访问内网的演示环境、边缘设备没有公网IP但需要统一管理。这不是在做任何绕过网络边界的事情而是在授权的工程场景下解决人够不着服务的问题。在纯隔离内网里做Agent大部分时间是不需要穿透的。但是有两个场景穿透确实能救命场景一远程联调。Agent服务在内网跑得好好的但开发人员在办公网这边要调试新功能每次都要走跳板机加一堆审批效率极低。这时候在内网的一台开发机上起一个穿透隧道办公网这边用本地端口映射的方式直连开发机上的调试端口不碰任何生产数据联调完隧道立刻关掉。场景二临时演示。客户想看效果但演示环境没有公网IP拉专线又不现实。用穿透工具把内网演示环境的Web端口映射到一个公网临时域名演示时开、演示完关完全可控。4.2 穿透的工作原理用大白话讲穿透的本质很简单内网里的某台机器主动去连接一台有公网IP的中间服务器建立一条长连接隧道。外部用户访问中间服务器上的某个端口时中间服务器把请求原封不动地通过隧道转给内网机器内网机器处理完再把响应原路返回。关键点是连接是内网主动发起的所以不需要在内网边界路由器上做端口映射也不需要对内网的防火墙开入站策略。这是穿透相比纯端口映射的优势。我在内网Agent项目里用穿透只把它当临时运维通道看从不把它当永久暴露口子用。生产流量不该走穿透穿透只服务开发和演示这些临时场景。4.3 实操配置nps自建和frp自建的两种选择内网穿透工具我常用两个frp和nps。说下我的选型逻辑。frp是老牌工具性能好、配置简单Go写的单二进制部署特别适合内网环境——直接拷贝进去就能跑不用装依赖。我的最小化配置长这样# frps服务端配置公网中转机上 [common] bind_port 7000 token 你的自定义token # frpc客户端配置内网开发机上 [common] server_addr x.x.x.x server_port 7000 token 你的自定义token [agent-dev] type tcp local_ip 127.0.0.1 local_port 8080 remote_port 18080配置完内网开发机上的8080端口就会被映射到公网中转机的18080端口办公网这边访问公网IP:18080就等于访问内网开发机的127.0.0.1:8080。测试完关掉frpc进程隧道即断。nps的特点是带Web管理面板可以可视化管理多个隧道、看流量统计适合团队里多人共用一台中转机的情况。但它多一个数据库依赖部署时稍微重一些。两个选一个就行。单就打一个Agent调试端口frp两分钟就能搞定要团队化运营多个隧道的上nps。4.4 穿透安全红线哪些事情一定不能做内网穿透是空间换时间的临时手段安全边界一定要划清楚。我给自己定了几条铁律一是只用token认证还不够最好配合中转机防火墙做来源IP白名单。只有指定IP段能访问中转机的穿透端口其他人一律拒绝。二是隧道内的流量建议走TLS加密。frp本身就支持TLS配置里开一下就行——穿透链路穿的是公网传输内容又是内网服务的请求和响应不想被人抓包看明文必须加密。三是穿透端口用完即关、不设开机自启。这条路只该在需要联调的那几个小时里存在联调结束立刻关掉frpc进程并把中转机的端口释放。四是绝不把穿透用于生产环境长期在线。生产链路就应该老老实实内网闭环穿透永远只是开发和演示的辅助工具。谁要是拿穿透把生产Agent的接口长期挂公网那是在制造风险。5. 从部署到稳定运行我在内网环境里踩过的坑和完整排查链路5.1 坑一Ollama服务只监听127.0.0.1Agent永远连不上现象Agent服务在B机器上跑调用A机器的Ollama接口各种超时报错。排查过程我先在A机器上curl了一次本机接口通然后从B机器ping A机器通再从B机器telnet A机器11434端口不通。问题定位在Ollama的监听地址上。原因Ollama默认监听127.0.0.1只允许本机访问。内网环境里模型服务跟Agent运行时是两台不同机器必须改监听地址。解决设置环境变量OLLAMA_HOST0.0.0.0重启Ollama服务再从B机器验证一次连接。后续建议把模型服务的地址统一写进Agent配置中心不要每次改完服务忘了改客户端。5.2 坑二Agent容器里解析不到内网DNS域名现象Agent和模型服务都在同一套内网DNS里从宿主机解析没问题但Agent跑在Docker容器里一访问内网域名就报could not resolve host。排查过程进容器后nslookup内网域名失败检查容器网络模式是bridge模式用的是Docker默认DNS检查内网DNS服务器地址没配置进容器。原因Docker容器的/etc/resolv.conf默认指向宿主机的系统DNS但内网DNS服务器地址是单独的容器根本不知道往哪儿查。解决docker-compose里给服务加上dns配置显式指定内网DNS服务器地址或者直接用host网络模式让容器和宿主机共享网络栈。隔离内网里没有端口冲突问题的话host模式最简单省事。5.3 坑三上下文一长接口就开始报错现象短对话一切正常对话超过十来轮后模型接口开始返回奇怪错误有的直接是HTTP 500。排查过程先看模型服务日志报的是上下文超长再看Agent侧的上下文管理逻辑发现它把每轮对话的全部原始消息都拼进去从来没有做压缩。原因模型有固定的上下文窗口比如32K token。Agent端如果没有做上下文裁剪或摘要压缩垃圾消息越攒越多迟早把窗口塞爆。解决在Agent编排层加了上下文管理策略——对话超过一定轮次后把早期历史压缩成摘要工具调用的中间结果只保留最终结论不保留原始大段报文系统提示词固定位不随对话轮次增长。提示这里的token就是模型计费和上下文长度的单位Agent工程的token管理本质上就是给每段内容分配预算。预算花完了结果质量直接断崖。5.4 坑四离线安装Python依赖装到一半发现缺包现象内网机器上用离线轮子装Agent的Python辅助模块装到某个包的时候报错说缺另一个版本的依赖但离线包里没有。排查过程用pip download在公网机器上把所有依赖打包成wheelhouse时发现有些包是最新版本而内网机器上的Python版本太旧导致轮子不兼容pip自动尝试找其他版本但离线索引里没有。原因离线打包环境跟目标运行环境的Python版本、系统架构不一致。打包时用的Python 3.11目标机是3.8一堆编译型包没有对应版本的wheel。解决以后所有离线打包都严格在与目标环境一致的容器里做先起一个同样Python版本和系统版本的容器再在里面执行pip download -r requirements.txt。装的时候直接用pip install --no-index --find-linkswheelhouse -r requirements.txt避免pip偷偷去连网络。5.5 把排查链路标准化每层留探针别靠猜内网环境最大的工程问题不是某个具体bug而是链路太黑。模型、编排、网关、数据库散在不同机器上出了问题第一反应是猜猜来猜去浪费半天。我后来把排查链路标准化了四步走第一步问Agent运行时的出口日志看它调了什么、参数是什么、返回了什么。第二步问模型服务的access log确认请求有没有到模型层。第三步问网关的traceID一次业务请求从两端同时查比对时间戳。第四步最后一招才看代码。代码一般是没错的错的是环境。这套四步法看起来朴素但真能救命。特别是链路长、机器多的隔离环境先看流经日志、再看请求数据、最后翻代码的顺序可以少走很多弯路。最后再分享一个我个人的习惯隔离内网的Agent项目从第一天起就要把可观测性当成第一等公民。模型选型选错了可以换架构不顺畅可以调但链路黑盒这个问题往往要等到出大事时才发现来不及补。每一层都要有日志、有探针、有验证接口这比任何花哨的Agent能力都重要。另外如果你们团队还没接触过Rust别急着跟风重写——先把业务闭环跑通再考虑用Rust优化最不稳定的那一段。工程的事稳定压倒一切。