在隔离内网里跑 AI Agent，是我今年做得最折腾、也最有成就感的一个项目。所谓"隔离内网"，就是和公网物理隔离的办公/生产网络，很多金融、政企、科研单位都是这种环境。标题里这两个词凑到一起，麻烦就开始叠加：Agent 天生依赖调用外部模型 API、联网搜索、实时查询知识库，而这些能力在断网条件下几乎全被砍掉。更麻烦的是，很多决策层以为"内网部署大模型 = 在内网装个 OpenWebUI 聊天"，实际上真要落地一个能完成多步骤任务的 Agent，从模型推理、依赖环境、工具调用、知识库到并发控制，每一层都是坑。这篇文章就是我自己从头到尾跑通的一线经验，适合正在做私有化部署、又在隔离网络环境里干活的工程师参考。
1. 隔离内网里跑 Agent，核心问题不是模型，而是"断网"
1.1 内网环境的真实情况：比你想的更严苛
很多第一次接触隔离内网的人，会把"隔离"理解成"没外网而已，其他都一样"。实际进去之后你会发现，情况远比想象中复杂。
首先，内网机器不能直接访问公网，这不只是浏览器打不开的问题。它意味着所有软件源、pip 源、npm 源、模型仓库（比如 HuggingFace）、Docker Hub 全部不可达。你在外网一条pip install就能装完的依赖，在内网里要么提前打包好带进去，要么就自己折腾离线轮子包编译——而很多中大型项目依赖一多，依赖树的离线收集本身就是个大工程。
其次，内网往往还有安全管控，比如禁止 U 盘插拔记录审计、禁止私自安装未经审批的软件、网络策略里只开放几个固定的端口。很多团队做着做着才发现，不是技术跑不通，是流程上根本不允许随意把公网上下载的东西拷进去。所以第一步不是写代码，是先搞清楚"介质准入"和"软件审批"的规矩。
再有，内网的硬件条件通常和外网开发机不一样。GPU 型号可能老旧（比如 Tesla T4、P40 甚至 K80），显存有限，驱动版本被 IT 统一锁死，cuda 版本不能随便升级。这就导致你在外网用最新框架训练好的模型，拿到内网里可能直接加载失败——版本兼容问题在离线环境下会被无限放大。
这些限制叠加在一起，决定了隔离内网里的 AI Agent 工程，本质上是一个"全链路离线交付"的问题。你交付的不只是一个 Python 服务，而是一整套可以脱离公网独立运行的应用生态。
1.2 "连接能力"被砍掉，Agent 就不成立了？
一个标准的 AI Agent 工作流，通常包含模型推理、工具调用、记忆管理、知识检索几个环节。拿 LangChain 生态举例，日常我们用 OpenAI 接口封装好的模型，用 Tavily 搜索工具查资料，用 SerpAPI 查新闻，用各种 API 操作业务系统。这些在公网环境下开箱即用，但在隔离网里全部失效。
那 Agent 是不是就废了？不是。关键在于把"外部连接能力"替换成"内网自有能力"。模型接口可以替换成本地推理服务；网络搜索可以替换成内网知识库检索（RAG）；外部 API 工具可以替换成内网业务系统的 HTTP 接口；记忆存储可以替换成内网数据库。本质上 Agent 需要的不是"公网"，而是"可调用的能力源"，只要这些能力源能在内网落地，Agent 就能跑起来。
这里我踩过一个很痛的点：最开始我试图让 Agent 直接通过调用内部知识库 API 来实现检索增强，结果被网络策略拦住了，因为那个知识库系统跑在另一个隔离网段，只有特定的服务账号能访问。后来我们干脆在内网单独部署了一套向量数据库，把知识文档全部本地化，才彻底绕开这个问题。所以架构设计上，第一步就要盘点内网能用的资源，而不是先假设Agent 什么都能干。
2. 整体架构设计：先想清楚哪些东西要本地化
2.1 核心选型：LangGraph 编排 + FastAPI 服务层 + vLLM 推理
隔离内网的 Agent 技术选型，我最终定下来的组合是：LangGraph 负责 Agent 的流程编排，FastAPI 封装对外服务接口，vLLM 承担本地大模型推理。
先说为什么是 LangGraph。Agent 的核心能力是多步骤任务编排，经典 LangChain 的AgentExecutor在复杂业务面前已经力不从心：缺少状态管理，多分支跳转要靠自己 hack，对循环和条件路由的控制也不够直接。LangGraph 把 Agent 的每一步抽象成图节点，节点之间通过状态对象传递数据，支持循环、条件分支、甚至人工介入（human-in-the-loop），这套逻辑非常契合生产环境的真实需求。而且它在离线环境下跑的是纯 Python 包，不依赖网络服务，天然适合内网部署。
FastAPI 没什么好纠结的，就是一个轻量、异步、自带接口文档的 Web 框架，用来暴露 Agent 的调用接口。你当然也可以用 Django，但 FastAPI 和 LangGraph 这种异步密集型的任务配合更顺畅，而且离线环境下依赖更少。
vLLM 是推理层的核心。它支持高并发推理、PagedAttention 显存管理、连续批处理，比直接用 Transformers 的generate方法吞吐量高出一个量级。隔离内网里 GPU 资源通常有限，一个 Agent 任务要反复多次调用模型（思考、调用工具、再思考），推理性能直接决定 Agent 的响应速度，所以这块不能省。
2.2 系统分层与交互链路
整体架构我分成了四层：
- 接入层：FastAPI 服务，负责鉴权、参数校验、请求排队，把外部请求转换成 Agent 任务。
- 编排层：LangGraph 图定义，负责 Agent 的 ReAct 循环，比如"分析问题 → 选择工具 → 执行调用 → 汇总结果"。
- 能力层：包括本地部署的大模型推理服务（vLLM）、向量数据库（Milvus/Elasticsearch）、业务系统 API 网关、内部数据库。
- 数据层：配置文件、业务文档、知识库向量索引、对话历史存储。
交互链路大致是：用户请求 → FastAPI 接口 → LangGraph 开始任务 → LLM 推理（vLLM）→ 判断是否需要工具 → 调用内网工具/检索向量库 → 再次推理 → 输出结果 → 返回用户。
这套链路里有一个非常容易忽略的点：用户请求上下文和 LLM 请求上下文是两套体系。用户发给 Agent 的可能是"帮我写一份三季度分析报告"，但真正传给 LLM 的，是经过提示词封装的系统指令、历史对话、工具描述、检索到的知识片段拼起来的长文本。内网落地时，这块的 token 占用和显存占用要提前估算，否则并发一上来，显存先爆了。
2.3 为什么坚持内外网双环境开发
隔离内网项目能不能只在内网开发？理论上可以，实际上效率太低了。我的做法是：外网开发环境负责代码编写、依赖验证、模型试跑；内网只做部署、集成测试和最终验收。两个环境之间通过离线介质同步（代码打包、依赖快照、模型文件拷贝），并且严格记录版本号。
这么做有几个好处：外网环境有完整的工具链，调试方便；外网能直接拉取最新的开源包和模型，省去内网搬运的麻烦；内网环境则保持干净稳定，只运行验证过的版本。但这里要提醒一下：两个环境的 Python 版本、CUDA 版本、系统库版本必须尽量一致，否则经常出现在外网好好的，一到内网就缺libgomp.so.1或者GLIBC版本不够的情况。我建议一开始就统一使用 Docker 镜像来固化环境，后面会把具体做法展开讲。
3. 离线模型部署全流程：从镜像到推理服务
3.1 模型选型：Qwen 系列是内网部署的稳妥之选
隔离内网场景下，模型选型的第一原则不是效果最强，而是"能跑、好搬、可控"。我在对比了十几个模型之后，主用 Qwen 系列。
原因很直接：Qwen 的中文能力强，对 Agent 场景的指令遵循能力也够用；模型权重在 HuggingFace 和 ModelScope 上都能下载，方便提前准备离线包；社区生态完善，遇到问题有处可查。相比 Llama 系列，Qwen 的中文词表利用效率更高，同样显存下能塞下更多有效上下文。
根据显存选择模型，我的经验参考如下：
| 显存大小 | 推荐模型 | 量化方式 | 备注 |
|---|---|---|---|
| 8GB | Qwen2.5-7B-Instruct | AWQ 4bit 量化 | 够跑简单工具调用 |
| 16GB | Qwen2.5-7B-Instruct | 不量化 / FP16 | 效果和速度平衡 |
| 24GB | Qwen2.5-14B | FP16 / AWQ | 复杂推理能力更好 |
| 48GB+ | Qwen2.5-32B / 72B | FP16 或 INT8 | 多 Agent 并发推荐 |
这个表是个参考底座，实际还要结合你的并发需求来调整。有一点要特别提醒：不要迷信"量化无损"的说法。AWQ 4bit 量化之后模型的数学推理和长文本能力会有肉眼可见的下降，如果你要 Agent 处理严谨的报表分析，尽量上不量化的版本，或者用 INT8 折中。
3.2 离线环境导入模型与推理镜像
模型到了内网，搬运是个技术活。我的标准做法是在有外网的机器上先把模型权重下载下来，保存成一个目录，然后用移动硬盘/光盘介质按要求审批后带进内网。模型权重文件通常很大（7B 模型 FP16 大约 15GB），建议下载的时候直接用huggingface-cli带断点续传，避免下到一半重新开始。
下一步是处理推理环境。我强烈建议用 Docker 而不是直接在宿主机上配环境，因为 vLLM 对 CUDA、Torch 版本的依赖非常敏感，直接配很容易陷入依赖地狱。在外网环境里，把 vLLM 官方镜像拉下来，然后把模型目录挂载进去跑一遍，确认没问题之后，用docker save导出镜像 tar 包，带进内网，再用docker load导入。
这是一条成本低、成功率高的离线迁移链：
# 在外网机器上 docker pull vllm/vllm-openai:latest docker save vllm/vllm-openai:latest -o vllm-image.tar # 模型文件也一起移到内网，例如放在 /data/models/qwen2.5-7b/ # 在内网机器上 docker load -i vllm-image.tar docker run -d --gpus all \ --name vllm-server \ -v /data/models/qwen2.5-7b:/model \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /model \ --served-model-name local-qwen \ --max-model-len 8192 \ --gpu-memory-utilization 0.9这里你可能会遇到一个非常尴尬的问题：镜像 tar 包动辄几个 GB，审批流程又长又烦。我的经验是提前问清楚内网有没有统一的镜像仓库（Harbor），有的话直接用仓库中转，没有才走物理介质。Harbor 通常允许网段内机器访问，效率比人肉搬运高太多。
3.3 推理参数与资源估算
内网跑 Agent，和跑普通聊天机器人很不一样。聊天机器人每次请求是一个来回，Agent 一次任务可能要调用五六次模型，而且每次还带着越来越长的上下文。所以推理服务的参数设置要围绕 Agent 场景调。
--max-model-len我建议根据实际任务长度来设，不要贪大。很多团队上来就设 32768，觉得长上下文好，结果显存都被 KV Cache 占了，并发能力直线下降。如果你的 Agent 任务是本地知识库问答，一次任务大概也就 3k-6k token，设 8192 完全够用，并发能力反而能翻倍。
--gpu-memory-utilization一般设 0.85-0.9，给 CUDA context 留一点余量。但如果你边上还要跑 Embedding 模型或者别的服务，要手动减到 0.7 左右，否则会 OOM。
还有一个很实际的参数是--max-num-seqs，它控制 vLLM 同时处理多少请求。默认值是 256，但如果你每请求的上下文都很长，建议调低到 32-64，不然显存被打满，请求全在排队，平均延迟反而恶化。这个参数没有绝对标准，得拿自己的真实请求去压测。
4. 应用服务层落地：FastAPI + LangGraph 调度实现
4.1 工程代码结构
应用服务层的代码组织，我比较推荐这种结构：
agent-service/ ├── app/ │ ├── main.py # FastAPI 入口 │ ├── config.py # 配置管理（模型地址、工具列表、知识库地址） │ ├── api/ │ │ ├── routes.py # 对外接口 │ │ └── schemas.py # 请求/响应模型 │ ├── agent/ │ │ ├── graph.py # LangGraph 图定义 │ │ ├── nodes.py # 各个图节点的逻辑 │ │ └── state.py # Agent 状态对象 │ ├── tools/ │ │ └── registry.py # 工具注册与分发 │ └── rag/ │ └── retriever.py # 知识库检索封装 ├── requirements.txt └── Dockerfile这个结构谈不上多高级，但很实用。核心思路是：API 层和 Agent 层完全解耦，Agent 层不关心请求来自哪；工具层独立注册，新增一个工具就是加一个函数，不影响主流程；配置外部化，模型地址、知识库地址这些环境相关的信息都走环境变量，内网外网一套代码。
为什么要这么拆？因为隔离内网环境的特殊之处在于：部署时会频繁调整资源地址、认证方式等配置。如果这些信息被硬编码在代码里，每次调整都要重新过审批、重新打包。拆出来之后，内网部署只需要改环境变量，代码根本不用动。
4.2 关键实现细节：状态管理、工具注册与条件路由
LangGraph 的核心是StateGraph。Agent 的每一步都在往 state 里写数据，节点函数读 state、处理、再写回。以 ReAct 模式为例，state 至少要有三块：messages（对话历史）、tool_calls（本轮要调用的工具列表）、retrieved_docs（知识检索返回的相关片段）。
工具注册我用了装饰器模式，每加一个工具就是一个普通函数，挂上注册表：
# tools/registry.py TOOL_REGISTRY = {} def register_tool(name, description): def decorator(func): TOOL_REGISTRY[name] = {"func": func, "description": description} return func return decorator @register_tool("query_internal_db", "查询内部业务系统的订单数据，输入是订单编号") def query_internal_db(order_id: str): # 在这里调用内网业务 API return {"order_id": order_id, "status": "已发货", "amount": 299.00}这个设计的好处是，LLM 生成的工具调用请求到了服务端，只需要查表分发，不需要写一堆if/else。而且工具的 description 可以直接拼进 prompt，让模型知道"我现在能用什么工具、什么时候该用"。
LangGraph 的条件路由是 Agent 能不能"动起来"的关键。我的经验是，不要让模型每次都有百分之百的自由度，而是设置明确的边界：先尝试工具调用，如果工具返回结果，就进入"观察-总结"节点；如果模型判断不需要工具，直接走"生成最终回答"节点。遇到多次工具调用失败（比如业务接口超时），要设置最大重试次数，然后走兜底回答。
4.3 一个贴近业务的示例：查订单 + 分析原因
举个具体例子，假设业务方要一个"订单异常排查 Agent"：用户问"订单号 20250112 为什么还没发货？"，整个流程是这样的：
- 模型收到问题，判断需要查询内网业务系统；
- 调用
query_internal_db工具，传入订单号； - 工具返回该订单状态："已支付，但库存锁定失败，异常原因代码 E401"；
- 模型看到 E401，判断需要查一下异常原因表，调用
query_exception_dict工具； - 工具返回"E401 = 仓库库存不足，系统自动拦截发货"；
- 模型汇总结果，返回给用户："订单因为库存不足被系统拦截，建议联系仓库补货后手动解锁"。
这个看起来很简单的流程，实际上经历了 5 次模型推理。如果每次推理 3 秒，总响应就要 15 秒，这还是单请求。所以应用层一定要做异步设计，内部跑 Agent 任务用asyncio或者独立线程池，不能把 FastAPI 的 worker 卡死等模型推理。
5. 隔离网内知识库与向量检索实战
5.1 向量库选型与离线化
Agent 要在隔离网里回答企业内部问题，光靠 LLM 自身参数知识远远不够，必须挂企业内部知识库。这就是 RAG 的场景。
向量数据库的选型，我在 Milvus 和 Elasticsearch 之间纠结过。最终选了 Milvus，一是它是专门的向量库，相似度检索性能好；二是支持 Milvus Lite 单机模式，离线部署非常简单；三是官方提供离线安装包，不需要在线拉取依赖。如果你所在环境已经有一套 Elasticsearch 在跑，那也不一定非要引入新组件，ES 的dense_vector功能也能做向量检索，关键是看团队已有的运维能力。
向量库的部署比大模型简单很多，可以直接用 Docker 跑一个单机 Milvus，初始化一个 collection，然后把文档切片灌进去。整个流程是：文档解析 → 文本分块 → Embedding 向量化 → 写入向量库；查询时：问题向量化 → 相似度检索 → 取 TopK 片段 → 拼进 prompt。
5.2 中文切词与 Embedding 模型
这里我要专门说一个内网场景下的坑：Embedding 模型的选择直接决定检索质量。很多团队图省事，直接拿一个通用 embedding 模型跑，结果中文检索效果差得离谱——"苹果"和"水果"语义匹配度很高，但和"iPhone"匹配度反而低，因为模型没学好中文语境。
我的建议是优先选择专门针对中文优化的 embedding 模型，比如 BAAI/bge-m3 或者 GTE 系列。bge-m3 支持中英双语，维度较低（1024 维），显存占用不大，离线部署无压力。Embedding 模型跑在 CPU 上也能凑合，但并发高的时候延迟会明显上升，最好放 GPU 上，或者单独分配一个 4GB 显存的推理服务。
文本切块的 size 和 overlap 参数也需要调。我踩过的教训是：不要把文档切得太碎，比如固定 200 字一块，这样很多语义完整的段落被拦腰截断，检索出来的片段前言不搭后语，LLM 根本没法用。比较稳的参数是 chunk_size=512、overlap=50，既保证上下文连贯，又不会让单片段信息密度太低。如果你的文档是固定结构的制度文件，可以考虑按章节标题切块，效果会比固定窗口好得多。
5.3 检索增强的效果调试
检索效果不好，不要急着换模型，先检查三个地方：
第一是查询改写。用户问题通常很短，"帮我看看 XX 设备为什么报警"，直接拿原句去检索，效果一般。我的做法是：先用 LLM 把用户问题改写成适合检索的关键词形式，比如"XX设备 报警 原因 排查"，再做 embedding 检索，命中率高很多。
第二是 TopK 的设置。TopK 太大，很多不相关片段混进来，干扰 LLM 作答；太小，有用的信息丢了，模型只能瞎编。我一般先设 5，看回答质量再调整。最有效的办法是人工标一批测试问法，对比不同 TopK 下的回答准确率，用数据说话。
第三是最近还测过 rerank。第一次检索先取 TopK 较宽（比如 20 条），然后接一个 rerank 模型精排，取前 5 条进 prompt。这个方案在隔离内网里完全可行，因为 rerank 模型很小，CPU 就能跑。加了 rerank 之后，回答质量提升非常明显，强烈建议有条件就上。
6. 并发、稳定性与性能优化
6.1 请求排队与连接池
Agent 服务和底层模型推理服务之间，连接管理是最容易出问题的地方。vLLM 本身支持并发请求，但如果应用层的 HTTP 客户端不做连接复用，每次都新建连接，性能损耗很大。我用的httpx.AsyncClient会显式设置连接池大小和 keep-alive，避免频繁握手。
更关键的是一层"排队设计"。vLLM 一次能处理的并发是有限的，假设单卡 7B 模型实测并发 8 路时延迟还能接受，第 20 路请求进来时延迟就会不可控。我在 FastAPI 层加了一个信号量（asyncio.Semaphore），限制同时进入 Agent 编排层的请求数，多的请求先排队等。配合一个简单的等待提示返回，用户体验比全部挤进模型导致整体超时要好得多。
有人可能觉得排队会影响体验，但你要知道，在隔离内网里，用户主要是内部员工，他们对"任务在排队"是有预期的。真正不能接受的是"点了按钮，20 秒后报错"——那才叫失败。
6.2 超时、重试与降级策略
模型推理超时、业务 API 超时、知识库检索超时，内网环境网络波动少，但系统故障并不少。我给整个链路设计了三层超时：接口层整体超时（比如 120 秒）、单次模型推理超时（60 秒）、工具调用超时（10-15 秒）。任何一层超时都要有明确的日志和返回信息。
重试策略要尤其小心。LLM 推理超时重试没问题，但工具调用（比如写数据库、发审批流）超时后重试要带上幂等控制，否则重复提交就是事故。我在这块吃过亏：Agent 调用内部接口发起了一个审批流程，第一次请求超时实际已成功，Agent 又自动重试了一遍，结果流程被提交了两次。后来所有写操作都由调用方生成唯一的 request_id，服务端根据 request_id 做幂等，才从根上解决。
降级策略也要提前想好。如果模型服务挂了呢？一个高可用的设计是预置多个模型实例做负载均衡，但内网资源有限，退而求其次必须保证失败信息足够友好："系统繁忙请稍后重试"，而不是让前端拿到一个晦涩的异常堆栈。
6.3 性能压测与优化记录
这轮压测我用的是 Locust，模拟 20 个并发持续 5 分钟。初始结果是惨不忍睹的：平均响应时间 75 秒，成功率只有 40%。一个一个排查，发现了三个热点问题：
第一是 Embedding 模型的请求串行阻塞。Agent 每次检索知识库都要做一次问题向量化，而这个调用是同步的，导致请求在做检索的时候整个 worker 被卡住。改成异步调用后，这个瓶颈立刻缓解。
第二是上下文不断膨胀。Agent 在一次任务里，每一轮推理都会把之前的工具调用结果重新塞进上下文，导致越到后面单次推理的 prefill 时间越长。我做了优化：只保留最近两轮的工具调用详情，更早的细节压缩成一句摘要，上下文长度控制住了，推理速度恢复。
第三是模型服务的max-num-seqs默认值太高。16GB 显存卡上，同时处理太多请求导致显存紧张，部分请求被强制排队等待。手动调低参数后，整体吞吐反而提升……压测数据从平均 75 秒降到了 22 秒，成功率回到 97% 以上。
7. 常见问题与排查技巧实录
7.1 问题速查表
| 现象 | 可能原因 | 排查命令/方法 |
|---|---|---|
| vLLM 启动即崩溃 | CUDA 版本与 torch 不匹配 | nvidia-smi查看驱动版本，用对应 CUDA 版本的镜像 |
| 模型加载 OOM | gpu-memory-utilization设置过高 | 调低到 0.7 或关闭其他显存进程 |
| 中文回答乱码或效果差 | 模型词表与实际任务不匹配 | 换 Qwen 系列，而不是 Llama |
| 工具调用一直失败 | LLM 生成的函数名与注册表不一致 | 打印模型原始输出，看函数名和参数 JSON 是否合法 |
| 检索知识库命中不相关文档 | 分块太大/太小，未加查询改写 | 按 512 字切块，加 LLM 查询改写，考虑加 rerank |
| 请求全部超时 | 并发打满，未做排队 | 加信号量排队，调低 vLLMmax-num-seqs |
| 数据同步到内网后运行报缺包 | 依赖未完整收集 | 在开发环境用pip download收集所有依赖，或直接用镜像 |
| 内网无法解析模型服务的域名 | DNS 没配置 | 直接用 IP 访问，或者在内网 DNS 加一条记录 |
7.2 几个容易忽略的小坑
第一个坑是时区问题。内网业务系统返回的订单时间可能是 UTC，模型做推断的时候没意识到时区差异，给用户的分析直接错了一天。我的做法是在 prompt 里明确注入当前时区和当前时间：一个变量current_datetime在每次请求开始时赋值。
第二个坑是日志里的敏感信息。Agent 在处理业务数据时，日志里很容易泄露出内部订单号、员工信息、甚至合同金额。隔离内网对数据安全的要求极高，我专门做了一个日志脱敏中间件，把手机号、身份证、金额字段打码后再写日志，否则审计过不了。
第三个坑是 Python 虚拟环境和 Docker 的墙中墙问题。有时候你打包了一个镜像进入内网，启动后发现容器里面的 Python 代码是对的，但内网没有libaio、libGL这种底层系统库，程序跑不起来。所以建立镜像的时候尽量用官方基础镜像，不要用slim版本，省掉一堆底层依赖的麻烦。
7.3 运维工具：离线巡检脚本
隔离内网的运维比外网麻烦，因为没有监控 SaaS 可用。我写了一个离线巡检 shell 脚本，每隔一段时间跑一次，检查 GPU 使用情况、模型服务健康状态、知识库连通性、磁盘剩余空间。脚本不依赖任何外部监控系统，日志直接写到本地文件，超过阈值就触发告警通知。
这个脚本其实非常简单，核心就几条命令：nvidia-smi看显存，curl探测 vLLM 的/health端点，df -h看磁盘，然后用grep简单判断阈值。但就是这么个不起眼的东西，在我出差期间帮团队发现了两次显存泄漏问题和一次磁盘写满事故。在内网环境，别迷信花哨的监控系统，先把手里的基础命令用好。
最后再说一个心得：隔离内网做 Agent，最大的阻碍不是技术，而是"想到但做不到"——你想用某个新框架，得先过审批；你想升级某个依赖，得先验证不影响现有业务；你发现自己用错了模型，重新搬运一次模型文件又是几天时间。所以在这个环境下干活，节奏必须稳：先设计清楚、路径验证一遍、然后严格执行，每一步都留好回滚方案。这种"慢工出细活"的姿态，反而让最终交付的系统比很多快速迭代的公网项目稳定得多。至少在我这边，项目上线至今没有再因为部署环境问题翻过车，这大概就是隔离内网逼出来的好处。
