★ FEATURED ARTICLE 1. 为什么要在隔离内网里折腾 AI Agent先把场景说清楚。所谓隔离内网就是那种物理上跟公网断开、或者只允许极少数白名单流量进出的环境。银行的核心机房、制造业的产线控制网、科研院所的算力集群、还有一些对数据外流零容忍的团队基本都是这个形态。在这种环境里跑 AI Agent跟在公网上拿个 API Key 随便调模型完全是两码事。我最早接触这个方向是因为一个做工业质检的朋友找我吐槽。他们车间里有一套视觉检测系统想加一个能自动分析缺陷报告、生成维修建议的 Agent但整个车间网络跟外网是物理隔离的连 pip install 都跑不通。他试过把模型权重拷进去结果发现依赖装不上、工具调不通、日志也没法回传折腾了两周基本原地踏步。这个痛点其实非常普遍。公网环境下搭 AI Agent你有一堆现成的东西可以用模型 API、MCP 服务市场、各种 Skills 包、在线调试工具。但一旦进了内网这些东西全部失效你得从零开始把整条链路重新搭一遍。而这条链路涉及的东西又特别杂——模型怎么部署、Agent 框架怎么选、工具怎么注册、MCP 协议怎么在内网里跑通、Skills 怎么管理和分发、并发怎么扛、日志怎么留。所以这篇东西想解决的问题很明确在没有任何公网依赖的前提下把一套可用的 AI Agent 工程完整落地到隔离内网里。适合谁看两类人。一类是已经会用 Coze、Dify 这类平台搭 Agent但一进内网就懵的开发者另一类是有内网部署经验但没接触过 Agent 这套新范式的运维或后端工程师。两类人凑一起基本就是这个项目的典型团队配置。我会按真实项目的推进顺序来讲先定架构再解决模型和框架然后是 MCP 和 Skills 这两个内网里最容易被卡住的环节接着是并发和工程化最后是排查经验。每一块都会给到能直接抄的参数和配置也会说清楚为什么这么选。2. 内网 AI Agent 的整体架构怎么定2.1 先想清楚哪些东西必须在内网哪些可以妥协架构设计的第一步不是画图是做减法。很多人一上来就想把公网那套完整搬进来结果发现根本跑不动。我的经验是先把组件分成三类必须在内网模型推理服务、Agent 运行时、工具执行环境、数据存储。这些涉及核心数据和算力出不去。可以在内网但需要离线包Agent 框架、MCP 服务端、Skills 运行时、依赖库。这些是纯软件只要能搞到离线安装包就行。可以完全砍掉在线模型 API、云端向量库、第三方工具市场、遥测上报。这些在内网里没有任何存在意义直接删。这个分类看起来简单但实际做的时候很多人会犹豫。比如向量库有人觉得可以放外面但你的知识库数据一旦出去就违反了隔离原则所以必须内网化。再比如遥测很多框架默认会往上报数据内网里这些请求全部会超时拖慢启动速度必须关掉。2.2 推荐的三层架构我实际落地下来比较稳的架构是三层第一层是模型服务层。用 vLLM 或者 Ollama 在内网服务器上起推理服务对外暴露 OpenAI 兼容的接口。为什么强调 OpenAI 兼容因为绝大多数 Agent 框架和工具链都默认支持这个协议你只要把 base_url 指到内网地址就行不用改代码。模型选型上如果显存够比如 A100 80G 或者多卡上 32B 级别的模型效果比较稳如果只有消费级显卡7B 到 14B 也能跑但复杂推理任务会吃力。第二层是 Agent 运行时层。这一层跑 Agent 框架负责编排、工具调用、上下文管理。框架选型后面细说但核心要求是能离线部署、能自定义工具、能接 MCP。第三层是工具与能力层。这一层包含 MCP 服务、Skills 包、以及各种自定义工具。它们通过标准协议跟运行时通信是整个 Agent 能力的来源。三层之间用内网 HTTP 或者 Unix Socket 通信全部走内网地址不依赖任何外部 DNS。这个架构的好处是每一层都可以独立升级和替换比如你换模型不用动 Agent 代码加工具不用重启运行时。2.3 一个容易忽略的点时间同步和证书内网环境里有两个坑特别隐蔽。第一个是时间同步。Agent 的上下文管理、缓存、日志都依赖时间戳如果内网机器时间不一致会出现缓存命中错乱、日志顺序颠倒的问题。建议在内网里起一个 NTP 服务所有节点对时。第二个是 HTTPS 证书。内网服务之间如果要用 HTTPS你得自己签证书而且要让所有客户端信任这个 CA。很多人图省事直接用 HTTP但如果你的内网有安全审计要求HTTP 是过不了的。自签证书的流程不复杂用 openssl 生成 CA再给每个服务签证书把 CA 分发到所有节点的信任库里就行。这一步建议在项目初期就做掉不然后面改起来很麻烦。3. 模型部署内网里怎么把大模型跑起来3.1 推理框架选型对比内网部署模型绕不开推理框架的选择。我实际用过的几个方案对比如下框架优势劣势适用场景vLLM吞吐高支持连续批处理OpenAI 兼容好显存要求高配置略复杂有 GPU 服务器追求并发Ollama部署极简模型管理方便并发能力弱不适合生产单机测试、小团队llama.cppCPU 也能跑资源占用低速度慢大模型吃力无 GPU 环境TGI功能全支持多种量化依赖较重升级麻烦有运维团队的环境我的建议是如果有 GPU 且要扛并发直接上 vLLM如果只是几个人用Ollama 足够如果完全没有 GPUllama.cpp 配合量化模型是唯一选择。3.2 vLLM 内网部署实操假设你有一台 8 卡 A100 的服务器想部署一个 32B 的模型。步骤大概是这样首先把模型权重和 vLLM 的离线包拷进内网。vLLM 的依赖比较多建议在一台同架构的公网机器上用pip download把所有依赖下下来打包成 whl 目录再拷进去用pip install --no-index --find-links安装。启动命令大概长这样python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-32B-Instruct \ --served-model-name qwen-32b \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --port 8000 \ --host 0.0.0.0这里几个参数值得说一下。tensor-parallel-size是张量并行度一般设成 GPU 数量或者其约数4 卡跑 32B 比较合适。gpu-memory-utilization控制显存占用比例0.9 是留一点余量给系统。max-model-len是最大上下文长度设太大显存会爆32K 对大多数 Agent 场景够用。启动之后用 curl 测一下curl http://内网IP:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen-32b,messages:[{role:user,content:你好}]}能返回结果就说明模型服务通了。3.3 模型选型的几个实际考量内网里选模型不能只看榜单分数。我踩过的坑包括有些模型对中文支持差工具调用格式不稳定长上下文容易丢信息。实际项目里我比较推荐 Qwen 系列和 DeepSeek 系列中文和工具调用都比较稳。另外要注意模型的工具调用能力。Agent 的核心就是调工具如果模型不能稳定输出结构化的工具调用请求整个 Agent 就是废的。测试方法很简单给模型一个工具定义让它调用看输出格式对不对。多测几轮看稳定性。还有一个隐藏问题是量化。内网显存紧张的时候会用 AWQ 或 GPTQ 量化模型但量化会损失一些推理能力尤其是工具调用这种需要精确格式的任务。我的经验是能用 FP16 就别量化实在不行用 INT8INT4 要谨慎测试。4. Agent 框架与 MCP 协议的内网落地4.1 框架选型的核心标准内网选 Agent 框架标准跟公网完全不一样。公网看生态、看文档、看社区活跃度内网只看三条能不能离线部署、能不能自定义工具、能不能接 MCP。我实际评估过的几个框架LangChain 生态最全但依赖最重离线部署要处理一大堆包AutoGen 多 Agent 协作强但配置复杂Spring AI 对 Java 团队友好还有一些轻量框架比如 smolagents依赖少但功能也少。如果团队是 Python 背景我推荐 LangGraph 或者直接基于 OpenAI SDK 自己写一层薄封装。自己写的好处是完全可控没有隐藏的网络请求内网里最怕的就是框架偷偷往外发请求然后卡住。4.2 MCP 协议到底是什么为什么内网里重要MCP 全称 Model Context Protocol简单说就是一套让模型和工具之间标准化通信的协议。你可以把它理解成 Agent 世界的 USB 接口——不管什么工具只要实现了 MCPAgent 就能用。为什么内网里 MCP 特别重要因为内网里你没法用现成的工具市场所有工具都得自己接。如果没有统一协议每接一个工具就要写一套适配代码维护成本爆炸。有了 MCP工具提供方只要实现一次服务端所有 Agent 都能复用。MCP 的核心概念有三个Resources资源比如文件、数据库、Tools可调用的函数、Prompts预置提示词模板。Agent 通过标准化的 JSON-RPC 跟 MCP 服务端通信。4.3 内网 MCP 服务端的部署MCP 服务端可以用 Python 或 TypeScript 写。内网部署的关键是传输方式。MCP 支持 stdio 和 SSE 两种传输stdio 适合同机进程通信SSE 适合跨机。内网跨机场景建议用 SSE走内网 HTTP。一个最简单的 MCP 服务端示例Pythonfrom mcp.server import Server from mcp.server.sse import SseServerTransport from mcp.types import Tool, TextContent app Server(internal-tools) app.list_tools() async def list_tools(): return [ Tool( namequery_database, description查询内网数据库, inputSchema{ type: object, properties: { sql: {type: string, description: SQL 语句} }, required: [sql] } ) ] app.call_tool() async def call_tool(name: str, arguments: dict): if name query_database: result execute_sql(arguments[sql]) return [TextContent(typetext, textstr(result))]部署的时候用 uvicorn 起服务绑定内网地址。Agent 端配置 MCP 服务地址就能发现并调用这些工具。4.4 Skills 体系在内网怎么管理Skills 这个概念最近很火本质上是把一组相关的工具、提示词、知识打包成一个可复用的能力单元。公网环境有各种 Skills 市场可以下载内网里你得自己建一套管理机制。我的做法是建一个内网的 Skills 仓库用 Git 管理。每个 Skill 是一个目录包含manifest.yaml描述 Skill 的名称、版本、依赖、入口tools/工具实现prompts/提示词模板knowledge/相关知识文档Agent 启动时从仓库拉取 Skills 清单按需加载。这样版本可控也方便审计。Skills 的加载要注意懒加载。如果一次性把所有 Skills 都加载进上下文token 会爆。正确做法是先用一个轻量的路由判断当前任务需要哪些 Skill再动态加载对应的工具定义。5. 并发与工程化让 Agent 在内网真正扛住压力5.1 并发瓶颈到底在哪很多人以为 Agent 的并发瓶颈在模型推理其实不全是。我实测下来瓶颈通常出现在三个地方模型推理这是最明显的vLLM 的连续批处理能缓解但显存是硬上限。工具调用如果工具是同步阻塞的比如查数据库并发一高就排队。上下文管理每个请求都要拼装上下文如果上下文很长CPU 和内存开销都不小。所以优化并发要三管齐下不能只盯着模型。5.2 模型层的并发优化vLLM 本身支持连续批处理但有几个参数要调--max-num-seqs 256 \ --max-num-batched-tokens 8192 \ --enable-chunked-prefillmax-num-seqs控制同时处理的请求数max-num-batched-tokens控制批处理的 token 总量enable-chunked-prefill让长请求分块处理避免阻塞短请求。这几个参数要根据显存和实际负载调没有万能值。如果单机扛不住就上多实例加负载均衡。内网里可以用 Nginx 做反向代理把请求分发到多个 vLLM 实例。5.3 工具层的异步化改造工具调用是并发杀手。解决办法是把所有工具改成异步的。数据库查询用异步驱动HTTP 调用用 aiohttp文件操作用线程池包装。Agent 框架层面要确保工具调用是并发执行的。有些框架默认串行调工具一个请求要等所有工具跑完才返回这在多工具场景下非常慢。改成并发之后多个工具同时跑总耗时取决于最慢的那个。5.4 上下文与缓存的工程化上下文管理有两个优化点。第一是缓存相同或相似的请求可以复用推理结果。内网里可以用 Redis 做缓存key 用请求的 hash。第二是上下文压缩长对话历史用摘要替代原文减少 token 消耗。还有一个容易被忽略的点是连接池。Agent 跟模型服务、MCP 服务、数据库之间的连接都要用连接池避免每次请求都新建连接。这个在低并发时看不出问题高并发时是致命的。6. 常见问题与排查技巧实录6.1 内网部署典型问题速查问题现象可能原因排查方向模型服务启动后无响应显存不足或端口占用查 nvidia-smi 和 netstatAgent 调用工具超时工具服务未启动或网络不通用 curl 直接测工具端点MCP 服务发现失败传输方式配置错误检查 SSE 地址和防火墙并发一高就报错连接池耗尽或显存溢出查连接数和 GPU 显存响应内容乱码编码不一致统一用 UTF-8启动极慢框架在尝试外网请求抓包看是否有外部连接6.2 几个我踩过的坑坑一框架偷偷发外网请求。有些框架启动时会检查更新、上报遥测内网里这些请求会一直超时重试导致启动慢甚至卡死。解决办法是设置环境变量禁用遥测或者用 hosts 把这些域名指向 127.0.0.1。坑二依赖版本冲突。内网装包不像公网能自动解决依赖经常出现 A 包要 numpy 1.xB 包要 numpy 2.x 的情况。建议用虚拟环境隔离或者干脆用容器把每个服务打包好。坑三日志没地方看。内网里没有云日志服务所有日志得自己收集。建议统一用文件日志加轮转关键服务再配一个内网的日志聚合比如 Loki。坑四模型输出不稳定。同样的输入模型有时候调工具有时候不调。这通常是提示词的问题要在系统提示里明确要求工具调用的格式并且给几个 few-shot 示例。6.3 性能调优的实操心得调优这件事我的原则是先测量再优化。内网里没有现成的监控你得自己埋点。至少要在三个地方打日志请求进入时间、模型返回时间、工具返回时间。这样能快速定位瓶颈在哪一段。另外一个心得是压测要贴近真实。很多人压测就用简单的问答结果上线后发现真实请求都是长上下文加多工具调用性能差好几倍。压测数据要从真实场景里采样。最后说一个关于 Skills 的经验。内网里 Skills 的版本管理特别重要因为没法随时更新。我的做法是每个 Skill 都打 tagAgent 配置里锁定版本号升级时先在测试环境验证再灰度到生产。这样避免了一个 Skill 更新导致整个 Agent 崩掉的情况。这套东西搭下来从零到能用大概需要两到三周主要时间花在依赖打包和调试上。一旦跑通后续加工具、加 Skill 就很快了。内网 AI Agent 工程的难点从来不是某个单点技术而是把整条链路在受限环境里拼起来并且让它稳定运行。
阅读完成 · 觉得有帮助？
