最近刚把一个AI Agent项目从开发网搬进隔离内网踩完一圈坑之后觉得有些东西很值得记录下来。很多人以为Agent就是调大模型、写几个工具调用但真正到了物理隔离、没有外网的环境里网络、依赖、模型、并发全是绕不开的坎。这篇文章不聊PPT架构直接讲我在隔离内网里搭AI Agent的完整过程怎么选型、怎么把模型和依赖搬进去、怎么扛多Agent并发以及哪些配置是从血泪里试出来的。如果你准备做私有化交付、要给客户做内网部署或是在公司内部已经碰到了“模型下了但跑不起来”这种鬼问题这篇应该能帮你少走好几周的弯路。1. 隔离内网里跑AI Agent到底难在哪1.1 难在网络不只在模型隔离内网的第一道坎就是“没有外网”。开发时我们习惯了pip install、npm install、docker pull但在客户现场或企业内部的内网环境这些操作一个都不好使。所有三方依赖、容器镜像、模型权重文件都得提前在能联网的机器上下载好再通过U盘、硬盘拷进内网或者放到内网自建的制品库里让服务器拉取。这听起来简单实际操作特别折腾。Python包有传递依赖pip download的时候如果不加--platform manylinux2014_x86_64、不把依赖树整理完整到了内网就会碰到“缺一个包但内网装不上”的死循环。Docker镜像也有这个问题你以为docker pull下来一个镜像就完事了结果镜像里的基础操作系统版本和GPU驱动不匹配一启动就崩。模型文件更不用说了。一个7B参数的模型FP16格式至少要14GBQ4量化后大概4到5GB如果是70B级别的模型量化后也得三四十GB。这么大数据量拷进内网不是插个硬盘复制粘贴就完事的。传输中途文件损坏、文件名被截断、分卷压缩后解压失败任何一步出错现场排查都非常痛苦。我后来做离线包时强制要求所有大文件分批压缩并且生成SHA256校验值到了内网先校验一遍再部署这能省掉大部分“环境怎么跑不起来”的排查时间。1.2 模型怎么选不是越大越好在内网环境选模型首先得盘算一下机器上的GPU资源。客户通常不可能给一台插满8张A100的机器来等你慢慢调优很多时候就是一两张消费级显卡。这种情况下模型选型的原则是“先满足任务再追求聪明”。以我这次项目为例需求是让Agent能处理内部知识库问答、日志分析、工单信息抽取这三类任务。最初我选了一个13B模型做测试效果确实比7B好但单张24GB显卡上只能同时跑两三个请求稍微上点并发就OOM。后来换成7B Q4量化单张卡能跑十几个并发速度和稳定性都上来了。有一点要提醒量化模型的推理质量会随着上下文长度变长而下降尤其在做多轮工具调用时中间历史一长模型经常“忘事”。如果项目里Agent需要多步推理和较长的对话历史建议至少用14B级别或者提供更高的上下文长度上限。量化方案优选AWQ或GPTQEXL2格式也可以但部署工具链没那么通用。如果客户对安全性要求高模型授权也是个必须确认的点。部分模型权重虽然是开源但商用或者用于某些特定行业时许可证条款有限制。内网环境没有外网可查最好在公司阶段就把模型的License列清楚避免后面打合规补丁。1.3 Agent框架选型自研还是用开源Agent框架在隔离内网里没有太多选择空间。现在很多公有云上的Agent平台比如各种低代码智能体工具大多依赖云端大模型和在线插件市场物理隔离环境下根本没法用。即使有私有化版本不少也只支持纯文本问答没办法做到灵活的工具调用。所以我们的路线基本是基于开源框架自建。团队主力语言是Python最终选了FastAPI LangChain LangGraph这套组合。LangChain主要负责连接各类模型和工具LangGraph则负责把Agent的工作流拆成有状态、可编排的节点。当时也考虑过用Spring AI Agent因为客户后端是Java技术栈如果希望Agent和现有业务系统深度集成Spring AI也是不错的选择但团队Golang和Java经验不够最后还是放弃了。关于“基于Rust语言AI Agent”这个热词我也想多说一句。Rust在网络网关和高并发代理层上确实有优势我们后来在模型服务前面加了一个由Rust写的轻量代理网关转发请求、做限流都很稳。但Agent编排层本身涉及大量工具调用和流程控制Python生态更成熟硬用Rust重写全套成本太高。个人建议是编排层保持LangGraph并发压力大的模块用Rust补位不要一拍脑袋全用Rust。1.4 隔离环境带来的隐形坑除了网络和依赖隔离环境在运维上也有一个很隐蔽的坑没有监控中心。开发环境挂了公司群里的告警机器人立马能发消息但在隔离内网你只能靠一套内部的监控系统自己看。而内网的服务器往往不允许随便开外连端口指标采集、日志汇总、告警下发全都要重新设计一套。另外内网环境经常要求审计谁调用了模型、模型生成了什么内容、Agent执行了什么工具都要有日志可查。这个需求在开发期很容易被忽略但到了内网交付阶段恰恰是最严格的验收项。所以说在方案设计一开始就要把审计链路考虑进去别等部署完再补日志那个时候排查成本已经很高了。2. 工程架构设计从模型底座到Agent编排2.1 架构分层的思路隔离内网部署Agent架构上我倾向于把系统拆成四层模型服务层、Agent编排层、Agent中台层、业务系统层。模型服务层负责把大模型跑起来对外提供OpenAI兼容接口。这样Agent编排层不需要感知背后跑的是vLLM还是Ollama也不关心模型是几B参数。Agent编排层用LangGraph定义工作流比如“意图识别 → 工具选择 → 任务执行 → 结果校验 → 回复”。Agent中台层做统一鉴权、限流、工具注册、审计日志所有向业务系统的请求都先经过中台。业务系统层就是我们真正要指挥的内部系统比如工单系统、监控系统、知识库数据库。这样分层的好处很明显模型服务层可以单独扩机器Agent编排层挂了不会影响底层模型实例中台层的工具注册表方便新增工具不用改Agent核心逻辑业务系统账号密码不会散落在Agent配置文件里而是统一收敛到中台。说白了就是把“让模型聪明地调用工具”和“安全地把工具暴露出去”这两件事拆开来处理。2.2 模型服务层的并发参数配置模型服务层我用的是vLLM原因主要是它对高并发推理优化做得好。vLLM内部有continuous batching机制请求不是一个一个排队而是动态拼接成一个批次这样GPU利用率会高很多。启动参数上比较关键的有--max-model-len上下文长度上限设4096还是8192取决于任务。如果Agent工具调用频繁建议至少4096起步。--max-num-seqs最大同时处理的请求数量。设太小浪费并发设太大容易OOM。比如单张24GB显卡跑7B Q4模型--max-num-seqs可以设到32或6413B模型建议设16或32。--gpu-memory-utilization允许vLLM占用多大比例的显存默认0.9。如果这台机器还要跑向量模型或者OCR服务务必调低到0.6或0.7否则后面其他服务起不来。显存估算这块有个简单经验模型权重占用 KV Cache占用 其他开销。7B Q4权重约5GBKV Cache在4096上下文、batch为64时大约额外占用4到6GB所以一张24GB显卡跑7B模型是比较从容的。70B模型即使Q4量化一张A100 80GB跑起来也偏紧如果还要高并发建议用多卡张量并行--tensor-parallel-size设为2或4。2.3 Agent编排层的LangGraph工作流设计LangGraph和普通LangChain Agent最大的区别是它把工作流画成一张有向图节点和节点之间的跳转是可预测的出了问题也能知道模型在哪一步做了错误决定。我搭的一个“日志异常分析”工作流大致是接收用户请求调用“意图识别”节点判断是问日志还是看监控指标调用“工具选择”节点从工具注册表里选出合适的审计工具调用“执行SQL查询”工具把查询结果返回调用“结果校验”节点看看返回结果是否符合预期如果不符合重新走修正节点最多循环三次最后生成总结回复。这里有一个重点工作流里一定要设定最大循环步数。因为模型在工具调用中偶尔会陷入“调了一个工具发现不对再调一次还是不对”的循环。不设上限一个请求可能跑十几轮把令牌烧完还耽误其他任务。我一般控制在5步以内超过就强制返回“需要人工介入”。2.4 Agent中台工具的注册、鉴权与审计“AI Agent中台”这个词近期出现频率很高实际做下来我觉得它更像是一个“安全网关 工具注册中心”的组合。工具注册表里每个工具都有名称、描述、参数Schema、权限级别。Agent调用时中台先校验请求的令牌、用户身份再看这个工具是否属于当前用户的权限范围然后执行请求并记录完整的审计日志。比如“查询数据库只读权限”和“修改工单状态写权限”中台会区分对待默认情况下Agent只能用只读工具危险操作需要人工审批才能放行。这样设计的直接好处是——模型就算被诱导输出了一些非法参数中台也能在入口拦住不会真的删掉数据。内网环境对安全的要求通常比互联网产品更高因为出问题就是生产安全事故所以这层一定不能省。3. 离线部署实操每一件东西怎么搬进内网3.1 Python依赖和Docker镜像离线同步内网部署的第一步是把所有依赖包和镜像提前准备好。我总结了两个命令算是基本操作。Python依赖在能联网的机器上执行pip download -d ./packages \ -r requirements.txt \ --platform manylinux2014_x86_64 \ --python-version 3.11 \ --only-binary:all:注意加--platform和--python-version是为了确保下载的包和服务器环境匹配。如果目的机器是Python 3.10就要改成--python-version 3.10否则很多带C扩展的包装不上。到了内网机器执行离线安装pip install --no-index --find-links./packages -r requirements.txtDocker镜像离线同步用docker pull vllm/vllm-openai:latest docker save vllm/vllm-openai:latest -o vllm.tar到了内网后docker load -i vllm.tar自己认领一下即可。这里有个细节docker镜像保存时最好打成.tar.gz并且带上架构标识否则不同CPU架构的机器load进去会出现“exec format error”。3.2 大模型权重的传输与本地加载模型下载我一般用hf download工具在开发网下载完整模型目录确保config.json、tokenizer.json等配套文件都在。传进内网时先对模型目录做tar分卷tar -czf model-7b-q4.tar.gz ./model_7b_folder/ split -b 2G -d model-7b-q4.tar.gz model.tar.gz.part sha256sum model.tar.gz.part* model.sha256到了内网先解压分卷再校验SHA256最后合并解压。别嫌麻烦这种几十GB的大文件在拷贝过程中我确实遇到过静默损坏的情况。校验通过后vLLM加载路径就可以直接指定到模型目录vllm serve /data/models/llama-7b-q4 \ --served-model-name local-llama \ --max-model-len 8192 \ --max-num-seqs 323.3 向量库、Embedding模型和OCR组件部署RAG几乎是Agent必备能力所以向量库也属于必装组件。内网环境里我建议优先选轻量但稳定、运维成本低的方案。比如PostgreSQL pgvector就够用不需要单独部署一个Milvus集群。数据量几千到几十万条文本pgvector完全能扛。如果确实有百万级以上的向量检索需求再上Milvus或者ElasticSearch vector plugin。Embedding模型也需要提前离线下载推荐bge-m3或者bge-large-zh中文效果比较好模型本身不大几个GB而已。部署时可以直接用ONNX Runtime跑CPU也能接受但为了并发建议在GPU上运行并且和主模型分开服务。另外如果知识库里有不少PDF扫描件或图片OCR组件也跑不掉。PaddleOCR是常用选择它的模型文件、依赖库、PaddlePaddle框架版本都要提前匹配好。内网环境的常见踩坑是一套PaddleOCR版本和PaddlePaddle版本不匹配装好了发现模型推理报错。所以离线包制作时一定要把版本锁定。3.4 权限控制与审计实践前面提到中台统一鉴权具体落到部署上我会做三件事。第一Agent服务不直接存任何业务系统密码而是通过中台用密钥管理服务或者环境变量注入临时凭证。第二所有外部请求必须携带API TokenToken按用户隔离能查出来是谁发起的会话。第三Agent调用的写操作工具比如“修改工单状态”“发送内部消息”都在中台打开人工确认开关模型把参数填好后需要审批人点确认才真正执行。在金融或大型企业内部这几乎是底线要求。Agent可以“建议”但不可以“擅自执行”。这套流程上线后运维和业务方对Agent的信任度会高很多。4. 并发与性能优化多个Agent一起干活怎么办4.1 把同步流程改成异步任务队列很多人问“AI Agent怎么扛并发”我第一个建议就是别把Agent接口做成同步调用。一个Agent工作流通常要几秒到几十秒如果前端HTTP请求一直阻塞等待Tomcat/uvicorn的工作线程很快就全被占满。我之前遇到过一个问题模型服务本身没挂但Agent编排服务因为同步调用太多线程池被打满新请求全部排队最终表现为“服务好像假死了”。后来改成异步任务模式请求进到系统先通过FastAPI接口返回一个task_id后台用Celery/RQ把这些任务丢到队列。Agent Worker从队列里取任务、执行工作流前端轮询状态或者通过WebSocket推送结果。这个方案的好处是编排服务和模型服务之间是异步解耦的Agent Worker可以按队列长度横向扩展扛并发的能力会强很多。4.2 限流、连接池与重试策略即使模型服务层有vLLM的连续批处理外层还是需要做限流否则一个误调用就会打爆GPU显存。我在中台层用令牌桶算法做限流每个用户每秒最多发起N个Agent请求超出就返回429提示让客户端退避重试。超时和重试也有讲究Agent调用模型接口时不能无限重试一般设三到五次重试间隔指数退避避免雪崩。连接池方面Python里用httpx.AsyncClient要注意复用client实例不能每个请求都新建一个连接。默认连接数太小我一般设置limitshttpx.Limits(max_connections100, max_keepalive_connections30)这样高并发时不会频繁握手。如果还是不够前面可以再叠一层Rust写的代理网关连接管理能力更好实测瞬时QPS提高非常明显。4.3 多模型实例的水平扩展当单机并发扛不住时就得考虑多模型实例。最简单的方式是同一台机器如果有多张GPU卡就多启动几个vLLM实例每个实例绑定不同的CUDA_VISIBLE_DEVICES然后在前面用Nginx做负载均衡按最小连接数分发请求。如果机器只有一张卡但有多台机器也可以让每台机器跑一个小实例组合成一个集群。建议按模型拆分轻量的意图分类模型放在小实例上重量的生成模型放在大实例上。这样不会出现一个重请求把所有显存占满导致轻量请求也响应不了的状况。有一点要注意vLLM实例之间是不共享状态的Agent工作流如果需要跨实例保存会话得把会话存在Redis里统一从Redis读取上下文。这也是为什么我在架构层把“模型无状态化”作为原则所有Agent状态都放在编排层。4.4 监控、告警与自愈内网环境没有云厂商的托管监控但我们可以自己搭一套轻量可运行的系统。Prometheus负责抓取指标Grafana做可视化Loki收集日志Alertmanager发内部IM告警。需要重点关注四个指标模型服务的GPU利用率、显存占用和OOM次数模型每次请求的平均首Token延迟和生成Tokens/秒Agent工作流完成率和平均耗时工具调用成功率、限流事件数量。我遇到过模型OOM导致实例崩溃但系统没有自动重启直到用户反馈才发现的情况。后来给vLLM容器加了健康检查和重启策略健康检查连续三次失败就自动重启容器并把请求摘掉。这样才把“无声故障”的窗口缩短到几分钟。5. 典型场景拿Agent在隔离内网实际干了什么活5.1 智能运维助理日志分析加故障预案场景是给运维团队做一个日志分析助手。Agent每天定时扫描业务系统的异常日志发现连续报错后会调用监控API查CPU、内存、磁盘指标再调用告警平台获取最近变更记录最后生成一份包含根因分析和处理预案的报告推送到内部办公软件的机器人。这个Agent最大的价值是把过去需要人工翻几十个日志文件的工作压缩到几分钟。隔离内网环境下日志数据完全不出网合规上也很容易被业务部门接受。实测跑下来平均每天能提前发现三到五个潜在故障其中有两次确实赶在用户报障前通知了运维。5.2 私域文档问答RAG落地另一个场景是内部客服知识库问答。我们把几百份操作手册、规章制度、故障处理SOP全部解析成文本切成固定长度的chunk用Embedding模型向量化后存入pgvector。员工在内部问答平台提问时Agent先检索相关片段再调用大模型生成回答并且回答里要标注引用的文档出处。这里最大的工程难点是文档解析。很多老手册是扫描版PDF必须先经过OCR否则检索出来全是乱码。后来我把PaddleOCR 结构化解析管道也放进了Agent中台作为底层能力。问答准确率从最初的60%出头提升到了85%上下剩余的15%主要集中在模糊提问和同义表达上。5.3 工单助手和自动消息推送还有一个做了自动发消息的场景。Agent监听内部工单系统的新建工单事件自动抽取工单里的问题类型、紧急程度、影响范围推荐处理团队并通过内部IM机器人推送给相关负责人。如果有历史工单模板Agent还可以先填一部分预填内容帮客服人员省掉重复录入。有人问“能不能让Agent自动在小红书、微博这些外部平台发消息”我的建议是在隔离内网环境里尽量不要碰外部社交平台就算通过网闸单向打通内容的合规审核和账号安全风险都很大。现阶段更稳妥的做法是先把内部IM、邮件、工单系统这些高频业务场景打通外部发布由Agent生成内容草稿、人工审核后导出。5.4 关于交易类场景的一点看法网上也经常有人问“AI Agent能不能做期货交易、股票交易”。从技术角度训练一个Agent分析行情数据、生成交易策略报告完全可行尤其在内部部署行情数据库的隔离内网里数据合规反而是优势。但自动化下单是另一回事风控要求和故障代价远高于普通办公场景。就算要做也必须坚持“Agent生成建议人工确认下单独立风控系统拦截异常参数”的三层结构绝对不能让Agent直接下单。别问我为什么这么谨慎生产环境一旦出事后面的流程审查比技术问题难处理得多。6. 踩过的坑和可以抄作业的建议6.1 离线环境依赖管理的三个经典坑第一个坑是“Python包这缺一个、那缺一个”。表面上requirements.txt写得很全实际到内网一跑又开始报ImportError。原因是某些包在安装时会动态拉取系统依赖比如opencv-python需要额外的系统动态库。解决方法是制作离线包时用ldd检查二进制依赖尽量把缺的系统库也提前放进离线仓库。第二个坑是“模型文件传进去加载老是报错”。尤其从HuggingFace下载的大模型目录传输过程中容易丢小文件或损坏分卷报错还不是一开始就报而是加载到一半才奇怪报错。所以我上面提过传大文件前必须打包成单个tar再分卷不要直接散文件拷贝传输后校验SHA256。第三个坑是“vLLM版本和CUDA驱动不匹配”。内网服务器如果GPU驱动版本比较老新版vLLM镜像需要的CUDA Runtime版本高于驱动实际支持版本容器就会直接Failed to initialize NVML。这个在买机器和装驱动之前就要对照好建议直接用官方文档推荐的驱动版本不要自行更替最新驱动。6.2 上手建议先做最小闭环如果你刚接触隔离内网下的AI Agent我强烈建议按这个顺序走先在内网部署一个纯LLM问答服务确保模型能跑通。加一个最简单的工具调用比如“查时间”“查天气”不过内网环境没有天气API可以用“查询内部工单数量”。再把工具调用接入LangGraph工作流设定步骤和状态流转。最后再做“Agent中台”的鉴权和审计。不要一上来就设计二十个工具、几十条工作流。Agent系统的复杂度是随着工具数量指数级上升的每多一个工具模型选错工具的概率就高一分。先把两三个核心工具链路打磨到可靠再逐步扩展。6.3 给未来的扩展留好口子内网环境变更成本很高每次更新模型版本、升级框架都要重新走一遍离线包流程。所以架构上一定要留好扩展位。一个是模型服务接口统一用OpenAI兼容API这样以后vLLM换TGI、换Ollama都顺滑。另一个是工具调用协议早点和MCP对齐。MCP这几年在Agent生态里越来越重要虽然内网没有官方公共MCP服务器但可以自己按MCP规范封装内部工具。未来工具库丰富后Agent接入新能力的成本会低很多。我在实际操作中还有一个体会内网部署Agent一定不要一上来就调Prompt。先把日志链路、可观测性、工具边界做好再谈优化模型效果。当模型回答不对时第一件事不是改提示词而是回看链路日志找到它到底在哪个节点做错了决定。很多时候问题出在工具描述不清晰、参数Schema没写好而不是模型不够聪明。最后分享一个小技巧每次做离线部署前我会在开发网整理一张“离线部署清单”包含所有依赖包、镜像、模型文件、系统库的版本号和来源并且写一个自动化打包脚本。这样每次交付都能快速生成一个新的离线压缩包而不是手动东凑西拼避免遗漏。隔离内网下的Agent工程本质上是在有限资源里做约束和取舍把基础打得稳一点后面优化空间才够大。