1. 为什么隔离内网里的 AI Agent 是另一场游戏很多人第一次听到隔离内网跑 AI Agent脑子里浮现的画面是把一台服务器搬进机房拔掉网线然后让模型自己在那儿转。真到了现场你会发现事情完全不是这么回事。隔离内网意味着没有公网出口、没有在线模型 API、没有现成的包管理源、没有对象存储、没有可观测性 SaaS甚至连时间同步都可能要靠本地 NTP。你手里能用的只有内网里那几台机器、几个内部服务以及一堆审批流程。我在过去一年多里先后在三个不同规模的隔离环境里落地过 AI Agent 工程从最早的能跑就行到后来的能扛并发、能审计、能回滚中间踩的坑足够写一本小册子。这篇内容就是把这些经验摊开讲围绕AI Agent、MCP Tools、Skills、内网系统、API这几个核心词把隔离内网下从架构选型到并发压测的完整链路讲清楚。适合两类人看一类是正在或即将在内网环境里搭 Agent 的工程师另一类是想搞清楚Agent 工程和调个 API 写个 demo到底差在哪里的开发者。先说一个反直觉的结论隔离内网下AI Agent 最大的难点从来不是模型本身而是工具链的可用性和状态的可观测性。公网环境下你随手pip install一个包、随手调一个在线 API 就能解决的事在内网里可能要花两周走完安全评估、镜像同步、白名单开通。所以内网 Agent 工程的第一性原则是把不确定性收敛到最小把可复用的能力沉淀成 Skills把外部依赖全部抽象成 MCP Tools。这句话听起来像口号但它是后面所有架构决策的根。还有一个常见误解需要提前打破很多人以为内网 Agent 就是本地部署一个大模型 一个 ReAct 循环。实际上一个能上生产的隔离内网 Agent至少包含五层模型推理层、工具协议层MCP、技能编排层Skills、任务调度层、以及审计与限流层。少任何一层你都会在某个深夜被叫起来处理线上问题。下面我按这个分层逐层拆开讲。2. 模型推理层内网里怎么把 LLM 跑起来还不掉链子2.1 内网模型的三种部署形态与选型逻辑隔离内网里跑 LLM本质上只有三种形态选哪种取决于你的硬件和并发预期。第一种是单机全量部署把开源权重直接加载到一台带 GPU 的机器上用 vLLM 或类似推理框架起服务。优点是链路最短、延迟最低、没有网络跳数缺点是显存吃紧并发一上来就容易 OOM。适合日均调用量在几千次以内、并发不超过 10 的场景。第二种是多副本 前置负载同一份权重在多台机器上各起一个推理服务前面挂一个内网负载均衡。这是内网里最稳的形态因为单副本挂了不影响整体扩容也只是加机器。代价是显存成本翻倍而且模型版本必须严格一致否则同一个 prompt 在不同副本上输出不一致排查起来非常痛苦。第三种是推理网关模式把模型服务封装成一个统一的内网 API 网关所有 Agent 只认网关地址不关心后面是几个副本、什么框架。这种形态最适合多团队共用也是我目前最推荐的。网关层可以做鉴权、限流、路由、灰度、日志把模型当成一个内部 SaaS来运营。选型的核心判断标准其实就一条你的 Agent 是少数人低频用还是多人高频用。前者单机足够后者必须上网关。我见过太多团队一开始图省事单机部署结果业务方一接入QPS 直接打满连夜改成网关模式返工成本极高。2.2 显存与并发的真实换算关系内网部署最容易被低估的就是显存和并发的关系。很多人按模型参数量 × 2 字节估算显存然后发现实际占用是估算的两三倍。原因在于 KV Cache。KV Cache 的大小和并发数 × 上下文长度 × 层数 × 隐藏维度成正比长上下文场景下它甚至比模型权重还占地方。举个实际例子一个 7B 级别的模型权重 FP16 大约 14GB但如果你的 Agent 平均上下文是 8K token并发开到 16KV Cache 可能就要吃掉 20GB 以上。所以内网部署时上下文长度是一个必须提前约束的参数不能任由 Agent 无限拼接历史。我的做法是在 Agent 侧强制做上下文裁剪把历史对话压缩成摘要把工具返回结果做截断从源头控制 token 消耗。提示内网环境没有在线 token 计费很容易让人放松对 token 的警惕。但显存是硬约束token 超了就是 OOM比公网超预算严重得多。2.3 模型版本管理与灰度内网里换模型版本是件大事。公网 API 升级你无感内网换权重意味着要重新加载、重新压测、重新验证所有 Skills 的兼容性。我的经验是永远保留至少一个上一版本副本新版本先接 5% 流量。Agent 的输出对模型版本极其敏感同一个 prompt 换个版本可能工具调用格式就变了直接导致解析失败。具体做法是在推理网关里做版本路由Agent 请求里带一个model_version字段网关按权重分发。灰度期间重点观察三个指标工具调用成功率、单次任务平均步数、以及异常终止率。这三个指标任何一个抖动超过 10%就立刻回滚。3. MCP Tools把内网系统抽象成 Agent 能调用的手3.1 为什么内网 Agent 必须走 MCP 而不是硬编码在没有 MCP 之前内网 Agent 调用内部系统的方式基本是硬编码在 Agent 代码里写死某个内部 API 的地址、参数格式、鉴权方式。这种方式在工具有限时能跑但一旦工具数量超过十个代码就会变成一团乱麻。每加一个工具就要改 Agent 主逻辑每改一次就要重新测试整个链路。MCPModel Context Protocol的价值在于把工具从 Agent 代码里解耦出来变成一个独立的、可注册、可发现、可版本化的服务。Agent 只需要知道有哪些工具可用、每个工具需要什么参数不需要知道工具背后连的是哪个内部系统。这在隔离内网里尤其重要因为内网系统的接口经常变解耦之后改工具不影响 Agent 主体。我实际落地时的架构是这样的每个内部系统对应一个 MCP ServerServer 负责把内部 API 包装成标准化的工具描述。Agent 侧有一个 MCP Client启动时从各个 Server 拉取工具清单运行时按需调用。新增系统只需要部署一个新的 MCP Server 并注册Agent 侧零改动。3.2 内网 MCP Server 的注册与发现机制公网环境下 MCP 的发现机制相对宽松内网里必须自己造一套。我的方案是用一个轻量的内网注册中心每个 MCP Server 启动时向注册中心上报自己的地址、工具清单、健康状态。Agent 启动时从注册中心拉全量清单并定期刷新。这里有个坑工具清单的刷新频率不能太高也不能太低。太高会给注册中心压力太低会导致新工具上线后 Agent 长时间看不到。我实测下来 30 秒是一个比较平衡的值。另外注册中心必须做健康检查某个 Server 挂了要能及时从清单里摘除否则 Agent 会一直调用一个死掉的工具任务卡在那里直到超时。组件职责关键参数注册中心维护 Server 清单与健康状态心跳间隔 10s摘除阈值 3 次失败MCP Server包装内部 API 为工具单工具超时 30s重试 2 次MCP Client拉取清单、发起调用清单刷新 30s调用并发上限可配3.3 工具描述的质量决定 Agent 的智商这一点我要重点强调因为它最容易被忽视。Agent 能不能正确调用工具80% 取决于工具描述写得好不好而不是模型有多强。我见过太多团队把工具描述写成一句话然后抱怨 Agent 老是调错工具。好的工具描述应该包含四部分这个工具做什么、什么场景下用、每个参数的含义和取值范围、以及调用后的返回结构。尤其是什么场景下用这一条直接决定了 Agent 在多个相似工具之间的选择准确率。比如你有查询订单和查询物流两个工具如果描述里不写清楚区别Agent 大概率会混用。我的做法是给每个工具写一段使用示例用自然语言描述一个典型调用场景。实测下来加了使用示例之后工具选择准确率能从 70% 左右提升到 90% 以上。这个投入产出比非常高值得每个工具都认真写。3.4 内网工具的鉴权与权限收敛内网不等于安全工具鉴权必须做。我的方案是双层鉴权第一层是 Agent 到 MCP Server 的服务间鉴权用内网签发的短期凭证第二层是 MCP Server 到内部系统的业务鉴权用内部系统的原有凭证体系。更重要的是权限收敛。Agent 能调用的工具必须是白名单而且每个工具能操作的数据范围要受限。比如查询用户信息工具不能让 Agent 查全量用户必须带上调用方的身份只能查该身份有权限的数据。这一点在隔离内网里尤其关键因为内网数据往往比公网更敏感。注意千万不要给 Agent 开放删除修改类的高危工具除非有严格的人工确认环节。我踩过的坑是给了一个批量更新工具结果 Agent 在一次任务里误判差点批量改错数据。后来所有写操作都加了二次确认。4. Skills让 Agent 从会调工具进化到会干活4.1 Skills 与 Tools 的本质区别很多人分不清 Skills 和 Tools觉得都是Agent 能用的能力。其实两者层次完全不同。Tools 是原子能力Skills 是完成一类任务的编排逻辑。Tools 是查订单发消息读文件这样的单步操作Skills 是处理一个客户投诉生成一份周报这样的多步流程。打个比方Tools 是厨房里的刀、锅、铲Skills 是菜谱。有了菜谱Agent 才知道先切菜、再热锅、再下料而不是拿着刀乱挥。在隔离内网里Skills 的价值更大因为内网任务往往有固定的业务流程和合规要求不能靠 Agent 自由发挥。我落地 Skills 的方式是用声明式的方式描述流程而不是写死在代码里。每个 Skill 定义包含触发条件、所需 Tools、执行步骤、每步的输入输出、异常处理策略。Agent 运行时根据任务匹配 Skill然后按步骤执行。这样业务方改流程只需要改 Skill 定义不用动 Agent 代码。4.2 内网 Skills 的版本化与测试Skills 必须版本化这是血泪教训。内网里一个 Skill 可能被多个 Agent 复用改了之后如果没版本控制所有 Agent 行为都会变。我的做法是每个 Skill 带一个语义化版本号Agent 请求时指定版本新版本先在小范围 Agent 上验证。测试方面内网 Skills 的测试比公网难得多因为没有现成的评测集。我的方案是用历史任务回放做回归测试把过去真实执行过的任务日志存下来每次 Skill 变更后回放这批任务对比执行路径和结果。这个方法虽然土但非常有效能抓住大部分回归问题。4.3 用 Skills 组合出复杂业务流程单个 Skill 往往不够真实业务需要多个 Skill 串联。比如处理退款这个流程可能包含验证订单检查退款政策计算退款金额发起退款通知客户五个子 Skill。我的做法是引入一个编排层用有向图描述 Skill 之间的依赖关系Agent 按图执行。编排层要处理几个关键问题并行执行无依赖的 Skill 同时跑、条件分支根据上一步结果决定下一步、失败重试某步失败后重试或走备用路径、以及超时控制整个流程不能无限跑。这些在公网可以用现成的工作流引擎内网里我建议自己写一个轻量编排器因为引入重型引擎的部署和维护成本在内网里不划算。4.4 Skills 的复用与沉淀机制Skills 最大的价值在于复用。我见过团队每个项目都重写一遍读文件发通知这类基础 Skill浪费大量时间。正确的做法是建一个内网 Skill 仓库所有 Skill 集中管理新项目直接引用。仓库要解决三个问题一是检索让开发者能快速找到已有 Skill二是依赖管理一个 Skill 依赖哪些 Tools 和其他 Skill 要写清楚三是权限哪些 Skill 对哪些团队可见。我实测下来有了统一仓库之后新项目的 Skill 开发时间能缩短一半以上。5. 并发内网 Agent 扛住压力的真实做法5.1 内网 Agent 的并发瓶颈到底在哪很多人一提到并发就盯着模型推理其实内网 Agent 的瓶颈往往在别处。我压测过多个内网 Agent 系统瓶颈出现的顺序通常是工具调用等待 模型推理 编排层调度 网络 IO。工具调用等待是大头。因为内网工具背后连的是各种内部系统这些系统的响应时间参差不齐有的几十毫秒有的几秒。Agent 在等工具返回时是阻塞的并发一高大量请求就卡在等待上。所以工具调用的异步化是扛并发的第一要务。模型推理是第二瓶颈但相对可控因为可以加副本。编排层调度在并发上千时会成为瓶颈因为要维护大量任务状态。网络 IO 在内网里通常不是问题除非跨机房。5.2 异步化与任务队列的设计我的方案是把 Agent 执行拆成同步入口 异步执行两段。入口收到请求后立刻返回一个任务 ID实际执行丢到任务队列里由 worker 池消费。客户端拿任务 ID 轮询或通过回调获取结果。任务队列要选内网可部署的我一般用 Redis 或 RabbitMQ。关键参数是 worker 数量这个要根据工具调用的平均耗时来算。假设单任务平均耗时 5 秒其中 3 秒在等工具那么一个 worker 的吞吐大约是 0.2 QPS。要扛 100 QPS 就需要 500 个 worker这个数量级必须靠异步化才能撑住。并发目标worker 数队列长度单任务超时10 QPS5050060s50 QPS250200060s100 QPS500500090s5.3 限流、降级与熔断在内网的特殊性内网限流和公网逻辑不同。公网限流主要是保护自己内网限流还要保护下游内部系统。因为内网系统往往不是为高并发设计的Agent 一上来可能直接把某个老系统打挂。所以限流要分两层Agent 自身入口限流以及针对每个下游工具的调用限流。降级策略也要提前设计。当模型推理不可用时Agent 应该能降级到只调工具不推理的简单模式当某个工具不可用时应该能跳过该工具或走备用工具。熔断则要针对每个下游系统单独配置某个系统连续失败就暂时摘除避免拖垮整个 Agent。提示内网熔断的阈值要比公网保守。公网失败几次无所谓内网下游系统一旦被打挂恢复可能要几小时。5.4 压测方法与真实数据内网压测不能只压模型要压全链路。我的方法是录制真实任务日志然后按倍数回放。先录 1000 个真实任务然后按 10 倍、50 倍、100 倍并发回放观察各层指标。压测时要重点看四个数据任务成功率、P99 延迟、各工具调用耗时分布、以及资源占用GPU 显存、CPU、内存、连接数。我实测下来一个设计良好的内网 Agent 系统在 50 QPS 下 P99 延迟能控制在 15 秒以内成功率 99% 以上。超过这个量级就要考虑水平扩容了。6. 可观测性与审计内网 Agent 的保命符6.1 为什么内网 Agent 的日志比公网更重要公网 Agent 出问题你可以快速迭代、快速回滚。内网 Agent 出问题可能要走变更流程、要等审批恢复速度慢得多。所以内网 Agent 的可观测性必须做到事后能完整还原。每一次任务执行从入口请求到最终结果中间每一步的输入输出、耗时、状态都要记录下来。我的做法是给每个任务生成一个 trace ID贯穿整个执行链路。所有日志、指标、工具调用记录都带上这个 ID。出问题时拿 trace ID 一查整个执行过程一目了然。这个投入在平时看不出价值但一旦出事能帮你把排查时间从几小时缩短到几分钟。6.2 审计日志的字段设计与留存审计日志和普通日志不同它要满足合规要求字段设计要严谨。我一般包含这些字段任务 ID、调用方身份、任务类型、涉及的 Skills 和 Tools、每步的输入输出摘要、执行结果、时间戳、以及模型版本。留存策略要看内网合规要求一般至少保留 6 个月。存储上建议用内网的日志系统不要存在 Agent 本地否则机器一挂日志就没了。日志内容要注意脱敏尤其是涉及用户数据的字段不能明文存。6.3 指标监控与告警阈值内网 Agent 的核心监控指标我总结为四率一延迟任务成功率、工具调用成功率、Skill 完成率、异常终止率以及 P99 延迟。这五个指标任何一个异常都说明系统有问题。告警阈值要结合历史数据设定。我的经验是成功率低于 95% 告警P99 延迟超过历史均值 2 倍告警异常终止率超过 1% 告警。告警要分级轻微异常发通知严重异常直接电话。内网环境没有公网那么多自动化工具告警链路要提前打通。7. 内网 Agent 工程里那些没人告诉你的坑7.1 时间同步与超时判断的诡异问题内网机器如果时间不同步会导致超时判断错乱。我遇到过一次诡异的问题Agent 明明设置了 30 秒超时但任务经常在 5 秒就失败。排查半天发现是 Agent 机器和工具机器时间差了 25 秒工具返回的时间戳比 Agent 当前时间还早被判定为过期响应。内网里时间同步经常被忽视因为大家觉得内网嘛无所谓。实际上必须部署内网 NTP所有机器严格同步。这个坑不踩一次根本想不到。7.2 编码与字符集导致的数据错乱内网系统年代跨度大有的用 GBK有的用 UTF-8。Agent 在中间做数据传递时如果不做统一编码转换会出现乱码甚至数据截断。我的做法是在 MCP Server 层强制统一成 UTF-8所有进出数据都做转换。这个坑在处理中文数据时特别容易踩。7.3 大结果集的处理策略内网工具经常返回大结果集比如查询返回几万条记录。如果直接塞给模型token 直接爆掉。我的策略是在 MCP Server 层做结果裁剪默认只返回前 N 条同时返回总数和分页信息。Agent 如果需要更多再发起分页请求。这样既控制了 token又保留了获取全量数据的能力。7.4 模型幻觉在内网场景的放大效应内网场景下模型幻觉的危害比公网大得多因为内网操作往往涉及真实业务数据。我见过 Agent 幻觉出一个不存在的订单号然后工具调用失败整个任务卡死。防范幻觉的核心是让 Agent 的每一步都有工具验证不要让它凭记忆输出关键信息。所有涉及数据的操作必须先查再改不能直接改。8. 从零到一落地内网 Agent 的实操路线8.1 第一阶段跑通最小闭环不要一上来就搞大而全。第一阶段的目标是跑通模型 一个工具 一个 Skill的最小闭环。选一个最简单的内部系统做工具写一个最简单的 Skill验证整条链路能通。这个阶段重点不是功能而是把部署、鉴权、日志、监控这些基础设施搭起来。我一般建议这个阶段控制在两周内。超过两周说明架构有问题要重新审视。8.2 第二阶段工具与 Skill 的规模化闭环跑通后开始批量接入工具和 Skill。这个阶段的关键是建立规范工具描述怎么写、Skill 怎么定义、版本怎么管理、测试怎么做。规范建立得越早后面越省事。我见过团队前期不建规范接了二十个工具之后代码乱成一锅粥重构成本极高。8.3 第三阶段并发与稳定性打磨工具和 Skill 上量之后开始做并发和稳定性。这个阶段要做压测、限流、降级、熔断把系统从能用打磨到能扛。重点观察前面说的四率一延迟根据数据不断调优。8.4 第四阶段运营与持续迭代系统稳定后进入运营阶段。这个阶段的核心是持续收集反馈、优化 Skill、更新模型。内网 Agent 不是一次性的项目而是需要长期运营的系统。我建议建立一个月度复盘机制看看哪些 Skill 用得多、哪些工具老出错、哪些任务失败率高针对性优化。9. 一些个人体会隔离内网做 AI Agent本质上是在约束条件下做工程。约束越多越考验架构设计能力。公网环境下可以靠堆服务、堆 API 解决问题内网里每一层都要自己造每一个依赖都要自己维护。这听起来很苦但也正是内网 Agent 工程的价值所在——它逼着你把系统想清楚、把边界划明白。我最大的体会是内网 Agent 的成功90% 取决于工程能力10% 取决于模型能力。模型选哪个、多大参数在内网里反而不是最关键的。真正决定成败的是工具链是否稳定、Skills 是否可复用、并发是否扛得住、出问题是否能快速定位。这些才是内网 Agent 工程的硬功夫。最后分享一个小技巧在内网里做 Agent一定要先做减法再做加法。不要一上来就想支持所有场景先把一个场景做到极致把基础设施打磨扎实再逐步扩展。我见过太多项目因为贪大求全最后什么都没做好。慢就是快这句话在内网 Agent 工程里尤其成立。