企业官网建设流程全解析

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 推理框架选型对比

内网部署模型，绕不开推理框架的选择。我实际用过的几个方案对比如下：

我的建议是：如果有 GPU 且要扛并发，直接上 vLLM；如果只是几个人用，Ollama 足够；如果完全没有 GPU，llama.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 就别量化，实在不行用 INT8，INT4 要谨慎测试。

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 接口——不管什么工具，只要实现了 MCP，Agent 就能用。

为什么内网里 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 服务端示例（Python）：

from 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( name="query_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(type="text", text=str(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-prefill

max-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 内网部署典型问题速查

6.2 几个我踩过的坑

坑一：框架偷偷发外网请求。有些框架启动时会检查更新、上报遥测，内网里这些请求会一直超时重试，导致启动慢甚至卡死。解决办法是设置环境变量禁用遥测，或者用 hosts 把这些域名指向 127.0.0.1。

坑二：依赖版本冲突。内网装包不像公网能自动解决依赖，经常出现 A 包要 numpy 1.x，B 包要 numpy 2.x 的情况。建议用虚拟环境隔离，或者干脆用容器把每个服务打包好。

坑三：日志没地方看。内网里没有云日志服务，所有日志得自己收集。建议统一用文件日志加轮转，关键服务再配一个内网的日志聚合（比如 Loki）。

坑四：模型输出不稳定。同样的输入，模型有时候调工具，有时候不调。这通常是提示词的问题，要在系统提示里明确要求工具调用的格式，并且给几个 few-shot 示例。

6.3 性能调优的实操心得

调优这件事，我的原则是先测量再优化。内网里没有现成的监控，你得自己埋点。至少要在三个地方打日志：请求进入时间、模型返回时间、工具返回时间。这样能快速定位瓶颈在哪一段。

另外一个心得是压测要贴近真实。很多人压测就用简单的问答，结果上线后发现真实请求都是长上下文加多工具调用，性能差好几倍。压测数据要从真实场景里采样。

最后说一个关于 Skills 的经验。内网里 Skills 的版本管理特别重要，因为没法随时更新。我的做法是每个 Skill 都打 tag，Agent 配置里锁定版本号，升级时先在测试环境验证，再灰度到生产。这样避免了一个 Skill 更新导致整个 Agent 崩掉的情况。

这套东西搭下来，从零到能用大概需要两到三周，主要时间花在依赖打包和调试上。一旦跑通，后续加工具、加 Skill 就很快了。内网 AI Agent 工程的难点从来不是某个单点技术，而是把整条链路在受限环境里拼起来，并且让它稳定运行。