1. 为什么“隔离内网”是 AI Agent 落地的真实分水岭很多人第一次接触 AI Agent都是在公网环境里跑通一个 Demo调个云端大模型 API接几个 MCP 工具本地起个服务看着它自动查资料、写文件、跑命令感觉“智能体时代真的来了”。但只要把同样的需求搬到隔离内网——也就是那种物理隔离、没有外网出口、甚至连 pip 源都要走内部镜像的环境——绝大多数方案会当场趴窝。这不是模型能力的问题而是整个工程链路的设计前提变了。我在过去一年多里前后参与过三个不同规模的内网 Agent 项目一个是制造业的工艺文档问答与工单辅助一个是金融后台的代码审查助手还有一个是能源行业的设备日志分析。它们的共同点是运行环境完全隔离不允许任何形式的外网连接所有依赖必须离线可获取所有数据不出内网。这三个项目踩过的坑基本覆盖了内网 Agent 工程化的全部核心难点。先说清楚一个概念边界。这里讲的“隔离内网”指的是与互联网物理断开或逻辑强隔离的网络环境常见于对数据安全有硬性要求的场景。它和“公司内网但能上外网”完全是两回事。前者意味着你不能依赖任何云端服务包括模型推理、向量检索、工具调用、依赖下载全部要在内网自建。这个约束直接决定了架构选型也决定了后面所有工程细节的走向。那为什么还要在内网做 Agent因为内网恰恰沉淀了最有价值的私有数据和最刚性的自动化需求。公网 Agent 能做的事内网往往更需要做只是不能用公网那套“调 API 云服务”的轻量打法。你需要把模型、工具、编排、存储全部搬进内网还要保证它们能协同工作。这就是“工程实战”四个字的重量所在。这篇文章会围绕内网 Agent 的完整落地链路展开从模型怎么进内网、MCP 工具层怎么设计、Skills 能力怎么组织到并发怎么扛、调试怎么做、部署怎么稳。每一部分我都会给出可复现的思路和踩坑记录而不是停留在概念层面。如果你正准备在内网环境里搭一套 Agent或者已经在做但卡在某个环节下面的内容应该能帮你少走不少弯路。2. 模型进内网本地推理服务的选型与显存账本2.1 内网模型部署的三条路线对比模型是 Agent 的大脑内网环境下你没法调云端 API只能本地部署。目前主流有三条路线各有明确的适用边界。第一条是本地推理框架直接加载开源权重比如用 vLLM、SGLang、Ollama 这类工具在内网服务器上跑量化后的模型。这条路线灵活度最高模型完全可控但需要你有 GPU 资源并且要自己处理显存、并发、上下文长度这些工程问题。第二条是内网已有的模型服务平台。很多企业早就建了内部的推理网关封装了统一的 API 接口。这种情况下你不需要关心底层推理只要按平台规范调用即可。好处是运维成本低坏处是模型版本和参数可能不由你控制Agent 的 prompt 设计要迁就平台的限制。第三条是CPU 推理或小模型方案。当 GPU 资源紧张时用 7B 以下的量化模型在 CPU 上跑或者用专门优化过的推理引擎。这条路线速度慢但对于低频、非实时的 Agent 任务比如夜间批处理文档是可行的。我的建议是优先复用内网已有的模型服务没有的话再自建 vLLM。自建时不要一上来就追求大模型先用 7B 到 14B 的量化版本把链路跑通验证 Agent 的编排逻辑没问题再考虑升级模型。很多团队卡在“模型不够聪明”上反复换模型其实问题往往出在工具设计和 prompt 编排上。2.2 显存怎么算一个能直接套用的估算方法内网部署最现实的问题就是显存。我给你一个粗略但实用的估算公式帮你判断一张卡能不能跑起来。模型权重的显存占用大致等于参数量 × 精度字节数。FP16 是 2 字节INT8 是 1 字节INT4 是 0.5 字节。比如一个 14B 模型用 INT4 量化权重约占 7GB。但这只是起点实际还要加上 KV Cache 和推理框架的开销。KV Cache 的估算稍微复杂一点公式是2 × 层数 × 隐藏维度 × 序列长度 × 批大小 × 精度字节数。以 14B 模型为例假设 40 层、隐藏维度 5120、序列长度 4096、批大小 4、FP16算下来 KV Cache 大约 2 × 40 × 5120 × 4096 × 4 × 2 ≈ 13.4GB。这个数字很吓人所以实际部署时要么限制序列长度要么用 PagedAttention 这类技术优化要么降低批大小。把权重和 KV Cache 加起来再留 2 到 3GB 给框架本身就是你的显存底线。一张 24GB 的卡跑 14B INT4 模型序列长度控制在 4096、批大小控制在 2 到 4是比较稳的配置。如果显存不够优先降序列长度和批大小而不是盲目换更小的模型——上下文长度对 Agent 任务的影响往往比模型参数量更大。提示内网部署前一定要用真实业务数据做压测不要只看模型能不能加载。很多问题比如长上下文下的显存溢出、并发请求下的 OOM只有在真实负载下才会暴露。2.3 模型服务的接口封装与降级策略内网模型服务跑起来后Agent 层需要一个统一的调用接口。这里有个容易被忽略的点不要把模型调用写死在业务代码里。我见过太多项目Agent 逻辑里直接硬编码了某个模型的 endpoint 和参数结果模型一换整个代码要大改。正确的做法是抽象一层模型网关统一处理请求路由、超时重试、参数适配和降级。比如主模型超时了自动切到备用的小模型请求量超过阈值时排队或返回友好提示。这层网关在内网环境里尤其重要因为内网的模型服务往往不如云端稳定可能因为运维重启、资源争抢而短暂不可用。降级策略要提前设计。Agent 任务通常有多个步骤如果某一步的模型调用失败是重试、跳过还是终止整个任务我的经验是关键决策步骤失败就终止并告警非关键的润色、总结步骤失败可以降级到规则处理。这样既保证核心流程的可靠性又不会因为一个次要环节拖垮整个任务。3. MCP 工具层内网 Agent 的“手脚”怎么接3.1 MCP 协议在内网场景下的价值与限制MCPModel Context Protocol这两年被讨论得很多它的核心价值是给模型和外部工具之间定了一套标准接口。模型不需要知道每个工具的具体实现只要按协议描述能力就能调用。这在公网环境里很优雅但在内网里MCP 的落地要考虑几个现实问题。首先是工具服务的部署位置。MCP Server 通常是一个独立进程Agent 通过 stdio 或 HTTP 和它通信。内网环境下如果 Agent 和工具在同一台机器stdio 最简单如果跨机器就要走内网 HTTP这时候要考虑服务发现和网络策略。很多内网环境对端口开放管得很严跨机器的 MCP 调用往往卡在防火墙配置上。其次是工具的能力边界。内网 Agent 能调用的工具必须是内网可访问的资源。比如查数据库、读内部文档、调内部 API、操作内部系统。公网那些“搜索网页”“调用第三方服务”的工具在内网完全用不了。所以 MCP 工具层的设计本质上是把内网已有的能力封装成模型能理解的接口。最后是协议版本和兼容性。MCP 还在演进不同版本的字段和交互方式可能有差异。内网环境升级困难一旦选定某个版本可能要长期维护。我的建议是工具层尽量薄把业务逻辑放在工具实现里协议层只做参数转换和结果封装。这样即使协议升级改动量也可控。3.2 从零设计一个内网 MCP 工具以“工单查询”为例假设内网有一个工单系统Agent 需要根据用户描述查询相关工单。我们来设计这个 MCP 工具。第一步是定义工具的输入输出。输入应该是结构化的比如{ keyword: 设备故障, status: open, limit: 10 }。输出也要结构化包含工单 ID、标题、状态、创建时间等字段。这里的关键是不要让模型直接拼 SQL 或调原始 API而是给它一个语义清晰的接口。模型擅长理解自然语言不擅长构造精确的查询语句。第二步是实现工具逻辑。工具内部去调工单系统的内部 API 或查数据库做好参数校验、权限检查、结果裁剪。注意结果不能太大否则会撑爆模型的上下文。一般限制返回 10 到 20 条每条只保留关键字段。第三步是写清楚工具描述。MCP 工具的 description 字段是模型决定要不要调用它的唯一依据。描述要说明这个工具做什么、什么时候用、参数怎么填、返回什么。比如“根据关键词和状态查询工单列表适用于用户询问某个问题的处理进度或历史记录”。描述写得越清楚模型调用越准确。第四步是处理异常。内网系统经常有各种意外API 超时、权限不足、数据格式不对。工具要把这些异常转换成模型能理解的错误信息而不是直接抛堆栈。比如返回{ error: 查询超时请稍后重试 }模型看到后可以决定重试还是告知用户。3.3 工具编排让 Agent 学会“先查什么、再查什么”单个工具好做难的是多个工具的编排。内网 Agent 面对的任务往往需要组合多个工具先查工单再查相关文档再查设备日志最后汇总。如果让模型自由发挥它可能乱调一气效率低还容易出错。我的做法是用 Skills 把常见任务流程固化下来。Skills 可以理解为一组预定义的“操作手册”告诉 Agent 在什么场景下按什么顺序调用哪些工具。比如“工单分析”这个 Skill明确规定了先调工单查询工具拿到工单后调文档检索工具找相关方案最后调日志工具看设备状态然后汇总。这样做的好处是可控。内网环境对稳定性要求高不能让 Agent 每次都即兴发挥。Skills 把最佳实践沉淀下来既提高了成功率也方便后续优化——哪个环节出问题直接改对应的 Skill 就行。工具编排还要考虑失败处理。如果查工单成功但查文档失败是继续还是终止我的经验是核心数据必须拿到辅助数据可以缺失。工单信息是核心文档检索失败可以降级为“未找到相关文档”但不影响主流程。这种分级处理要在 Skill 里写清楚。4. Skills 能力组织把“经验”变成 Agent 可复用的资产4.1 Skills 和 Prompt 的区别为什么不能只靠提示词很多人觉得Agent 的能力不就是靠 prompt 吗写一段详细的提示词告诉模型怎么做不就行了在内网场景下这个思路很快会撞墙。Prompt 的问题是不可复用、不可测试、不可维护。当你有十几个任务场景时每个都写一大段 prompt很快就会失控。改了一个场景的 prompt可能影响另一个场景想测试某个场景的效果没有标准化的输入输出新人接手根本看不懂这些 prompt 之间的逻辑关系。Skills 的本质是把 prompt、工具调用、流程控制、异常处理打包成一个可复用的单元。一个 Skill 有明确的触发条件、输入参数、执行步骤和输出格式。它比 prompt 更结构化比硬编码更灵活。在内网 Agent 工程里Skills 是能力沉淀的主要载体。举个例子公网 Agent 可能靠一段长 prompt 就能完成“总结一篇文章”。但内网 Agent 要完成“分析一份设备故障报告并生成处理建议”涉及读文件、查历史工单、检索知识库、调用模型总结、格式化输出这一整套流程必须封装成 Skill才能保证每次执行都稳定。4.2 一个 Skill 的完整结构从触发到输出我来拆解一个实际用过的 Skill 结构。以“设备故障分析”为例。触发条件当用户输入包含设备编号、故障描述或者明确要求分析故障时触发。触发条件要写得具体避免误触发。比如不能只写“用户提到设备”而要写“用户提供了设备编号并描述了异常现象”。输入参数设备编号必填、故障现象必填、时间范围可选默认最近 7 天。参数要明确类型和是否必填方便校验。执行步骤第一步根据设备编号查设备档案确认设备类型和所属系统第二步根据故障现象和时间范围查历史工单看是否有类似问题第三步检索知识库中的故障处理方案第四步如果有实时日志接口拉取相关时段的日志摘要第五步把所有信息汇总调用模型生成分析报告。输出格式结构化的报告包含故障可能原因、历史相似案例、建议处理步骤、需要进一步确认的信息。格式固定方便后续系统消费。异常处理设备编号查不到返回“设备不存在请确认编号”历史工单查询超时降级为“未获取到历史工单建议人工核查”知识库无匹配标注“未找到相关方案”。这个结构看起来繁琐但正是这种繁琐保证了稳定性。内网 Agent 不是玩具它要嵌入真实业务流程每一步都要可预期、可追溯。4.3 Skills 的版本管理与灰度发布Skills 写多了就需要管理。内网环境没有公网那么方便的 CI/CD但基本的版本管理不能少。我的做法是用 Git 管理 Skills 定义文件每个 Skill 一个目录包含定义文件、测试用例、变更记录。Skill 的每次修改都走代码评审确保改动可控。内网 Git 服务比如 GitLab 私有部署完全能满足这个需求。灰度发布也很重要。新 Skill 或修改后的 Skill先在小范围用户或低风险场景试用观察一段时间再全量。内网环境出问题排查成本高宁可慢一点也不要一次性铺开。还有一个经验Skills 要可观测。每次 Skill 执行记录触发条件、输入参数、执行步骤、耗时、结果状态。这些日志在内网里是排查问题的唯一依据。不要觉得日志占空间关键时刻它能救命。5. 并发与性能内网 Agent 怎么扛住真实负载5.1 内网 Agent 的并发瓶颈到底在哪公网 Agent 谈并发瓶颈通常在 API 限流或网络延迟。内网 Agent 的瓶颈完全不同主要在三个地方模型推理、工具调用、上下文管理。模型推理是最大的瓶颈。一张 GPU 卡同时只能处理有限的请求超了就要排队。如果 Agent 任务本身需要多轮模型调用比如先规划、再执行、再总结单次任务的模型调用次数可能是 5 到 10 次并发能力会被进一步压缩。工具调用是第二个瓶颈。内网工具往往连接的是老旧系统响应慢、并发低。比如查一个内部数据库单次查询可能要 2 到 3 秒并发一高就拖垮整个流程。上下文管理是第三个瓶颈。Agent 任务通常需要维护较长的上下文包括对话历史、工具返回结果、中间状态。上下文越长模型推理越慢显存占用越高。并发请求一多上下文管理就成了显存杀手。5.2 用队列和限流把并发“削峰填谷”内网 Agent 不能像公网那样弹性扩容所以必须做请求队列和限流。核心思路是不让请求直接打到模型和工具上而是先进队列由调度器按系统承载能力逐步消费。具体做法是Agent 接收请求后先做轻量校验和预处理然后放入任务队列比如 Redis 队列或内存队列。调度器根据当前模型和工具的负载情况控制并发消费的数量。模型推理并发设为 2 到 4工具调用并发设为 5 到 10具体数值根据压测结果调整。队列还要有优先级。实时交互请求优先批处理任务靠后。用户在前台等结果不能让他排半小时队。批处理任务可以夜间跑慢慢消费。限流要配合超时和重试。模型调用超时设为 30 到 60 秒工具调用超时设为 10 到 20 秒。超时后根据任务类型决定重试还是降级。重试要有次数上限避免雪崩。5.3 上下文压缩让长任务不撑爆显存上下文压缩是内网 Agent 的必修课。一个复杂任务跑下来上下文可能累积到几万 token直接塞给模型既慢又贵显存角度。我的压缩策略分三层。第一层是工具结果裁剪工具返回的数据只保留模型决策必需的部分比如查工单只返回标题、状态、摘要不返回完整描述。第二层是中间结果摘要每完成一个步骤用模型或规则把结果压缩成简短摘要替换掉原始的长文本。第三层是历史对话窗口只保留最近 N 轮对话更早的对话压缩成背景摘要。这三层做下来上下文通常能控制在 4000 到 8000 token模型推理速度和显存占用都可控。压缩会损失一些细节但对于大多数内网任务关键信息保留就够了。注意上下文压缩要谨慎处理关键信息。比如设备编号、工单 ID 这类标识符压缩时不能丢否则后续步骤会找不到对应数据。我的做法是维护一个“关键信息表”压缩时把这些字段单独保留。6. 调试与可观测内网环境下的“盲调”怎么破6.1 内网调试的困境没有外网日志就是眼睛公网开发时你可以随时打开浏览器看请求、用各种在线工具分析、甚至临时开个隧道调试。内网环境这些都没有你只能靠日志和本地复现。这让调试难度陡增。我踩过最深的坑是Agent 在内网跑着跑着结果不对但没有任何报错日志里只有“任务完成”。排查了半天才发现是某个工具返回了空结果模型基于空结果编了一个看似合理的答案。这种“静默失败”在内网 Agent 里非常常见因为模型不会报错它会“自信地胡说”。所以内网 Agent 的调试核心是全链路日志。每一次模型调用、每一次工具调用、每一次 Skill 执行都要记录输入、输出、耗时、状态。日志要结构化方便检索和分析。不要用 print用正经的日志框架输出 JSON 格式方便后续处理。6.2 构建可回放的任务追踪链路光有日志还不够还要能回放。一个 Agent 任务涉及多个步骤出问题时你需要知道每一步发生了什么。我的做法是给每个任务分配一个 trace ID所有相关日志都带上这个 ID。任务执行过程中每一步的输入输出都记录到追踪系统里。出问题时用 trace ID 把所有日志拉出来按时间顺序还原整个执行链路。更进一步可以记录模型的实际 prompt 和返回。这在内网调试时极其有用。很多时候问题出在 prompt 上——模型理解错了或者工具描述有歧义。看到实际 prompt问题往往一目了然。追踪系统不用很复杂内网环境用文件加简单的检索工具就行。关键是要坚持记录不要等到出问题才想起来加日志。6.3 用“影子模式”验证 Skill 改动Skill 改动后怎么验证直接上生产风险太大。我的经验是用影子模式新版本 Skill 和旧版本并行运行新版本只记录结果不实际生效对比两者的输出差异。跑一段时间确认新版本没问题再切换。影子模式在内网环境特别实用因为内网没有方便的 A/B 测试基础设施。用影子模式你可以在不影响业务的前提下验证改动积累足够的样本后再决策。还有一个技巧构造回归测试集。把历史任务中典型的、边界的情况整理成测试用例每次 Skill 改动后跑一遍看结果是否符合预期。这个测试集不用很大几十个用例就能覆盖大部分场景。内网环境自动化测试不好做但手动跑回归测试集是值得的。7. 部署与运维让内网 Agent 稳定跑下去7.1 内网部署的依赖管理离线包怎么打内网部署最大的痛点是依赖。公网一句pip install搞定的事内网要提前把所有依赖打包带进去。我的做法是在公网环境准备一个完整的离线依赖包。用pip download把所有 Python 依赖下载到本地目录包括间接依赖。模型权重、工具二进制、配置文件全部打包。然后通过内网允许的方式比如内部文件服务器、移动介质传进去。打包时要注意版本锁定。内网环境升级困难依赖版本一旦确定就不要轻易改。用requirements.txt锁定精确版本避免“在我机器上能跑”的问题。还要准备依赖安装脚本。内网服务器可能没有网络安装脚本要能离线执行处理各种环境差异Python 版本、系统库、CUDA 版本。这个脚本要提前在类似环境测试过不要到了现场才发现装不上。7.2 服务编排Agent 各组件怎么协同启动内网 Agent 通常由多个组件构成模型服务、MCP 工具服务、Agent 编排服务、队列、日志系统。这些组件怎么启动、怎么协同要有明确的编排方案。简单场景可以用脚本加进程管理比如写一个启动脚本按顺序拉起各个服务用 supervisor 或 systemd 管理进程。复杂场景可以用容器编排但内网环境容器镜像的获取和更新也是个问题要提前规划。启动顺序很重要。模型服务要先起来工具服务其次Agent 编排服务最后。Agent 启动时要检查依赖服务是否就绪没就绪就等待或告警。不要假设所有服务都能同时起来内网环境启动慢是常态。健康检查不能少。每个服务要有健康检查接口Agent 定期探测。发现服务不健康及时告警并尝试重启。内网环境人工干预成本高能自动恢复的尽量自动恢复。7.3 日常运维监控什么、告警什么内网 Agent 上线后运维是长期工作。监控和告警要抓住重点不要什么都监控否则告警疲劳。必须监控的指标模型服务的 GPU 显存和利用率、请求队列长度、任务成功率、平均任务耗时、工具调用失败率。这些指标直接反映系统健康度。必须告警的场景模型服务不可用、队列积压超过阈值、任务成功率骤降、工具调用大面积失败。告警要分级严重的立即通知一般的汇总日报。日志轮转和清理也要规划。内网磁盘空间有限日志不能无限增长。设置合理的轮转策略保留最近 N 天的详细日志更早的归档或清理。最后分享一个运维心得定期做故障演练。手动停掉某个服务看系统能不能正确告警和恢复。内网环境出问题时现场往往很紧张提前演练过处理起来就有底。我在一个项目里坚持每月做一次演练后来真的遇到模型服务崩溃时团队五分钟内就恢复了因为流程已经跑熟了。内网 AI Agent 工程没有银弹它是一堆细节的堆叠模型要能跑、工具要能通、Skills 要能复用、并发要能扛、问题要能查、部署要能稳。每一环都不难难的是把它们串起来并在隔离环境下持续运转。我最大的体会是不要追求一步到位先把最小链路跑通再逐步加固。内网环境变化慢但一旦跑顺它的稳定性和数据安全性是公网方案给不了的。 隔离内网AI Agent工程实战：模型部署、MCP工具与Skills编排
1. 为什么“隔离内网”是 AI Agent 落地的真实分水岭很多人第一次接触 AI Agent都是在公网环境里跑通一个 Demo调个云端大模型 API接几个 MCP 工具本地起个服务看着它自动查资料、写文件、跑命令感觉“智能体时代真的来了”。但只要把同样的需求搬到隔离内网——也就是那种物理隔离、没有外网出口、甚至连 pip 源都要走内部镜像的环境——绝大多数方案会当场趴窝。这不是模型能力的问题而是整个工程链路的设计前提变了。我在过去一年多里前后参与过三个不同规模的内网 Agent 项目一个是制造业的工艺文档问答与工单辅助一个是金融后台的代码审查助手还有一个是能源行业的设备日志分析。它们的共同点是运行环境完全隔离不允许任何形式的外网连接所有依赖必须离线可获取所有数据不出内网。这三个项目踩过的坑基本覆盖了内网 Agent 工程化的全部核心难点。先说清楚一个概念边界。这里讲的“隔离内网”指的是与互联网物理断开或逻辑强隔离的网络环境常见于对数据安全有硬性要求的场景。它和“公司内网但能上外网”完全是两回事。前者意味着你不能依赖任何云端服务包括模型推理、向量检索、工具调用、依赖下载全部要在内网自建。这个约束直接决定了架构选型也决定了后面所有工程细节的走向。那为什么还要在内网做 Agent因为内网恰恰沉淀了最有价值的私有数据和最刚性的自动化需求。公网 Agent 能做的事内网往往更需要做只是不能用公网那套“调 API 云服务”的轻量打法。你需要把模型、工具、编排、存储全部搬进内网还要保证它们能协同工作。这就是“工程实战”四个字的重量所在。这篇文章会围绕内网 Agent 的完整落地链路展开从模型怎么进内网、MCP 工具层怎么设计、Skills 能力怎么组织到并发怎么扛、调试怎么做、部署怎么稳。每一部分我都会给出可复现的思路和踩坑记录而不是停留在概念层面。如果你正准备在内网环境里搭一套 Agent或者已经在做但卡在某个环节下面的内容应该能帮你少走不少弯路。2. 模型进内网本地推理服务的选型与显存账本2.1 内网模型部署的三条路线对比模型是 Agent 的大脑内网环境下你没法调云端 API只能本地部署。目前主流有三条路线各有明确的适用边界。第一条是本地推理框架直接加载开源权重比如用 vLLM、SGLang、Ollama 这类工具在内网服务器上跑量化后的模型。这条路线灵活度最高模型完全可控但需要你有 GPU 资源并且要自己处理显存、并发、上下文长度这些工程问题。第二条是内网已有的模型服务平台。很多企业早就建了内部的推理网关封装了统一的 API 接口。这种情况下你不需要关心底层推理只要按平台规范调用即可。好处是运维成本低坏处是模型版本和参数可能不由你控制Agent 的 prompt 设计要迁就平台的限制。第三条是CPU 推理或小模型方案。当 GPU 资源紧张时用 7B 以下的量化模型在 CPU 上跑或者用专门优化过的推理引擎。这条路线速度慢但对于低频、非实时的 Agent 任务比如夜间批处理文档是可行的。我的建议是优先复用内网已有的模型服务没有的话再自建 vLLM。自建时不要一上来就追求大模型先用 7B 到 14B 的量化版本把链路跑通验证 Agent 的编排逻辑没问题再考虑升级模型。很多团队卡在“模型不够聪明”上反复换模型其实问题往往出在工具设计和 prompt 编排上。2.2 显存怎么算一个能直接套用的估算方法内网部署最现实的问题就是显存。我给你一个粗略但实用的估算公式帮你判断一张卡能不能跑起来。模型权重的显存占用大致等于参数量 × 精度字节数。FP16 是 2 字节INT8 是 1 字节INT4 是 0.5 字节。比如一个 14B 模型用 INT4 量化权重约占 7GB。但这只是起点实际还要加上 KV Cache 和推理框架的开销。KV Cache 的估算稍微复杂一点公式是2 × 层数 × 隐藏维度 × 序列长度 × 批大小 × 精度字节数。以 14B 模型为例假设 40 层、隐藏维度 5120、序列长度 4096、批大小 4、FP16算下来 KV Cache 大约 2 × 40 × 5120 × 4096 × 4 × 2 ≈ 13.4GB。这个数字很吓人所以实际部署时要么限制序列长度要么用 PagedAttention 这类技术优化要么降低批大小。把权重和 KV Cache 加起来再留 2 到 3GB 给框架本身就是你的显存底线。一张 24GB 的卡跑 14B INT4 模型序列长度控制在 4096、批大小控制在 2 到 4是比较稳的配置。如果显存不够优先降序列长度和批大小而不是盲目换更小的模型——上下文长度对 Agent 任务的影响往往比模型参数量更大。提示内网部署前一定要用真实业务数据做压测不要只看模型能不能加载。很多问题比如长上下文下的显存溢出、并发请求下的 OOM只有在真实负载下才会暴露。2.3 模型服务的接口封装与降级策略内网模型服务跑起来后Agent 层需要一个统一的调用接口。这里有个容易被忽略的点不要把模型调用写死在业务代码里。我见过太多项目Agent 逻辑里直接硬编码了某个模型的 endpoint 和参数结果模型一换整个代码要大改。正确的做法是抽象一层模型网关统一处理请求路由、超时重试、参数适配和降级。比如主模型超时了自动切到备用的小模型请求量超过阈值时排队或返回友好提示。这层网关在内网环境里尤其重要因为内网的模型服务往往不如云端稳定可能因为运维重启、资源争抢而短暂不可用。降级策略要提前设计。Agent 任务通常有多个步骤如果某一步的模型调用失败是重试、跳过还是终止整个任务我的经验是关键决策步骤失败就终止并告警非关键的润色、总结步骤失败可以降级到规则处理。这样既保证核心流程的可靠性又不会因为一个次要环节拖垮整个任务。3. MCP 工具层内网 Agent 的“手脚”怎么接3.1 MCP 协议在内网场景下的价值与限制MCPModel Context Protocol这两年被讨论得很多它的核心价值是给模型和外部工具之间定了一套标准接口。模型不需要知道每个工具的具体实现只要按协议描述能力就能调用。这在公网环境里很优雅但在内网里MCP 的落地要考虑几个现实问题。首先是工具服务的部署位置。MCP Server 通常是一个独立进程Agent 通过 stdio 或 HTTP 和它通信。内网环境下如果 Agent 和工具在同一台机器stdio 最简单如果跨机器就要走内网 HTTP这时候要考虑服务发现和网络策略。很多内网环境对端口开放管得很严跨机器的 MCP 调用往往卡在防火墙配置上。其次是工具的能力边界。内网 Agent 能调用的工具必须是内网可访问的资源。比如查数据库、读内部文档、调内部 API、操作内部系统。公网那些“搜索网页”“调用第三方服务”的工具在内网完全用不了。所以 MCP 工具层的设计本质上是把内网已有的能力封装成模型能理解的接口。最后是协议版本和兼容性。MCP 还在演进不同版本的字段和交互方式可能有差异。内网环境升级困难一旦选定某个版本可能要长期维护。我的建议是工具层尽量薄把业务逻辑放在工具实现里协议层只做参数转换和结果封装。这样即使协议升级改动量也可控。3.2 从零设计一个内网 MCP 工具以“工单查询”为例假设内网有一个工单系统Agent 需要根据用户描述查询相关工单。我们来设计这个 MCP 工具。第一步是定义工具的输入输出。输入应该是结构化的比如{ keyword: 设备故障, status: open, limit: 10 }。输出也要结构化包含工单 ID、标题、状态、创建时间等字段。这里的关键是不要让模型直接拼 SQL 或调原始 API而是给它一个语义清晰的接口。模型擅长理解自然语言不擅长构造精确的查询语句。第二步是实现工具逻辑。工具内部去调工单系统的内部 API 或查数据库做好参数校验、权限检查、结果裁剪。注意结果不能太大否则会撑爆模型的上下文。一般限制返回 10 到 20 条每条只保留关键字段。第三步是写清楚工具描述。MCP 工具的 description 字段是模型决定要不要调用它的唯一依据。描述要说明这个工具做什么、什么时候用、参数怎么填、返回什么。比如“根据关键词和状态查询工单列表适用于用户询问某个问题的处理进度或历史记录”。描述写得越清楚模型调用越准确。第四步是处理异常。内网系统经常有各种意外API 超时、权限不足、数据格式不对。工具要把这些异常转换成模型能理解的错误信息而不是直接抛堆栈。比如返回{ error: 查询超时请稍后重试 }模型看到后可以决定重试还是告知用户。3.3 工具编排让 Agent 学会“先查什么、再查什么”单个工具好做难的是多个工具的编排。内网 Agent 面对的任务往往需要组合多个工具先查工单再查相关文档再查设备日志最后汇总。如果让模型自由发挥它可能乱调一气效率低还容易出错。我的做法是用 Skills 把常见任务流程固化下来。Skills 可以理解为一组预定义的“操作手册”告诉 Agent 在什么场景下按什么顺序调用哪些工具。比如“工单分析”这个 Skill明确规定了先调工单查询工具拿到工单后调文档检索工具找相关方案最后调日志工具看设备状态然后汇总。这样做的好处是可控。内网环境对稳定性要求高不能让 Agent 每次都即兴发挥。Skills 把最佳实践沉淀下来既提高了成功率也方便后续优化——哪个环节出问题直接改对应的 Skill 就行。工具编排还要考虑失败处理。如果查工单成功但查文档失败是继续还是终止我的经验是核心数据必须拿到辅助数据可以缺失。工单信息是核心文档检索失败可以降级为“未找到相关文档”但不影响主流程。这种分级处理要在 Skill 里写清楚。4. Skills 能力组织把“经验”变成 Agent 可复用的资产4.1 Skills 和 Prompt 的区别为什么不能只靠提示词很多人觉得Agent 的能力不就是靠 prompt 吗写一段详细的提示词告诉模型怎么做不就行了在内网场景下这个思路很快会撞墙。Prompt 的问题是不可复用、不可测试、不可维护。当你有十几个任务场景时每个都写一大段 prompt很快就会失控。改了一个场景的 prompt可能影响另一个场景想测试某个场景的效果没有标准化的输入输出新人接手根本看不懂这些 prompt 之间的逻辑关系。Skills 的本质是把 prompt、工具调用、流程控制、异常处理打包成一个可复用的单元。一个 Skill 有明确的触发条件、输入参数、执行步骤和输出格式。它比 prompt 更结构化比硬编码更灵活。在内网 Agent 工程里Skills 是能力沉淀的主要载体。举个例子公网 Agent 可能靠一段长 prompt 就能完成“总结一篇文章”。但内网 Agent 要完成“分析一份设备故障报告并生成处理建议”涉及读文件、查历史工单、检索知识库、调用模型总结、格式化输出这一整套流程必须封装成 Skill才能保证每次执行都稳定。4.2 一个 Skill 的完整结构从触发到输出我来拆解一个实际用过的 Skill 结构。以“设备故障分析”为例。触发条件当用户输入包含设备编号、故障描述或者明确要求分析故障时触发。触发条件要写得具体避免误触发。比如不能只写“用户提到设备”而要写“用户提供了设备编号并描述了异常现象”。输入参数设备编号必填、故障现象必填、时间范围可选默认最近 7 天。参数要明确类型和是否必填方便校验。执行步骤第一步根据设备编号查设备档案确认设备类型和所属系统第二步根据故障现象和时间范围查历史工单看是否有类似问题第三步检索知识库中的故障处理方案第四步如果有实时日志接口拉取相关时段的日志摘要第五步把所有信息汇总调用模型生成分析报告。输出格式结构化的报告包含故障可能原因、历史相似案例、建议处理步骤、需要进一步确认的信息。格式固定方便后续系统消费。异常处理设备编号查不到返回“设备不存在请确认编号”历史工单查询超时降级为“未获取到历史工单建议人工核查”知识库无匹配标注“未找到相关方案”。这个结构看起来繁琐但正是这种繁琐保证了稳定性。内网 Agent 不是玩具它要嵌入真实业务流程每一步都要可预期、可追溯。4.3 Skills 的版本管理与灰度发布Skills 写多了就需要管理。内网环境没有公网那么方便的 CI/CD但基本的版本管理不能少。我的做法是用 Git 管理 Skills 定义文件每个 Skill 一个目录包含定义文件、测试用例、变更记录。Skill 的每次修改都走代码评审确保改动可控。内网 Git 服务比如 GitLab 私有部署完全能满足这个需求。灰度发布也很重要。新 Skill 或修改后的 Skill先在小范围用户或低风险场景试用观察一段时间再全量。内网环境出问题排查成本高宁可慢一点也不要一次性铺开。还有一个经验Skills 要可观测。每次 Skill 执行记录触发条件、输入参数、执行步骤、耗时、结果状态。这些日志在内网里是排查问题的唯一依据。不要觉得日志占空间关键时刻它能救命。5. 并发与性能内网 Agent 怎么扛住真实负载5.1 内网 Agent 的并发瓶颈到底在哪公网 Agent 谈并发瓶颈通常在 API 限流或网络延迟。内网 Agent 的瓶颈完全不同主要在三个地方模型推理、工具调用、上下文管理。模型推理是最大的瓶颈。一张 GPU 卡同时只能处理有限的请求超了就要排队。如果 Agent 任务本身需要多轮模型调用比如先规划、再执行、再总结单次任务的模型调用次数可能是 5 到 10 次并发能力会被进一步压缩。工具调用是第二个瓶颈。内网工具往往连接的是老旧系统响应慢、并发低。比如查一个内部数据库单次查询可能要 2 到 3 秒并发一高就拖垮整个流程。上下文管理是第三个瓶颈。Agent 任务通常需要维护较长的上下文包括对话历史、工具返回结果、中间状态。上下文越长模型推理越慢显存占用越高。并发请求一多上下文管理就成了显存杀手。5.2 用队列和限流把并发“削峰填谷”内网 Agent 不能像公网那样弹性扩容所以必须做请求队列和限流。核心思路是不让请求直接打到模型和工具上而是先进队列由调度器按系统承载能力逐步消费。具体做法是Agent 接收请求后先做轻量校验和预处理然后放入任务队列比如 Redis 队列或内存队列。调度器根据当前模型和工具的负载情况控制并发消费的数量。模型推理并发设为 2 到 4工具调用并发设为 5 到 10具体数值根据压测结果调整。队列还要有优先级。实时交互请求优先批处理任务靠后。用户在前台等结果不能让他排半小时队。批处理任务可以夜间跑慢慢消费。限流要配合超时和重试。模型调用超时设为 30 到 60 秒工具调用超时设为 10 到 20 秒。超时后根据任务类型决定重试还是降级。重试要有次数上限避免雪崩。5.3 上下文压缩让长任务不撑爆显存上下文压缩是内网 Agent 的必修课。一个复杂任务跑下来上下文可能累积到几万 token直接塞给模型既慢又贵显存角度。我的压缩策略分三层。第一层是工具结果裁剪工具返回的数据只保留模型决策必需的部分比如查工单只返回标题、状态、摘要不返回完整描述。第二层是中间结果摘要每完成一个步骤用模型或规则把结果压缩成简短摘要替换掉原始的长文本。第三层是历史对话窗口只保留最近 N 轮对话更早的对话压缩成背景摘要。这三层做下来上下文通常能控制在 4000 到 8000 token模型推理速度和显存占用都可控。压缩会损失一些细节但对于大多数内网任务关键信息保留就够了。注意上下文压缩要谨慎处理关键信息。比如设备编号、工单 ID 这类标识符压缩时不能丢否则后续步骤会找不到对应数据。我的做法是维护一个“关键信息表”压缩时把这些字段单独保留。6. 调试与可观测内网环境下的“盲调”怎么破6.1 内网调试的困境没有外网日志就是眼睛公网开发时你可以随时打开浏览器看请求、用各种在线工具分析、甚至临时开个隧道调试。内网环境这些都没有你只能靠日志和本地复现。这让调试难度陡增。我踩过最深的坑是Agent 在内网跑着跑着结果不对但没有任何报错日志里只有“任务完成”。排查了半天才发现是某个工具返回了空结果模型基于空结果编了一个看似合理的答案。这种“静默失败”在内网 Agent 里非常常见因为模型不会报错它会“自信地胡说”。所以内网 Agent 的调试核心是全链路日志。每一次模型调用、每一次工具调用、每一次 Skill 执行都要记录输入、输出、耗时、状态。日志要结构化方便检索和分析。不要用 print用正经的日志框架输出 JSON 格式方便后续处理。6.2 构建可回放的任务追踪链路光有日志还不够还要能回放。一个 Agent 任务涉及多个步骤出问题时你需要知道每一步发生了什么。我的做法是给每个任务分配一个 trace ID所有相关日志都带上这个 ID。任务执行过程中每一步的输入输出都记录到追踪系统里。出问题时用 trace ID 把所有日志拉出来按时间顺序还原整个执行链路。更进一步可以记录模型的实际 prompt 和返回。这在内网调试时极其有用。很多时候问题出在 prompt 上——模型理解错了或者工具描述有歧义。看到实际 prompt问题往往一目了然。追踪系统不用很复杂内网环境用文件加简单的检索工具就行。关键是要坚持记录不要等到出问题才想起来加日志。6.3 用“影子模式”验证 Skill 改动Skill 改动后怎么验证直接上生产风险太大。我的经验是用影子模式新版本 Skill 和旧版本并行运行新版本只记录结果不实际生效对比两者的输出差异。跑一段时间确认新版本没问题再切换。影子模式在内网环境特别实用因为内网没有方便的 A/B 测试基础设施。用影子模式你可以在不影响业务的前提下验证改动积累足够的样本后再决策。还有一个技巧构造回归测试集。把历史任务中典型的、边界的情况整理成测试用例每次 Skill 改动后跑一遍看结果是否符合预期。这个测试集不用很大几十个用例就能覆盖大部分场景。内网环境自动化测试不好做但手动跑回归测试集是值得的。7. 部署与运维让内网 Agent 稳定跑下去7.1 内网部署的依赖管理离线包怎么打内网部署最大的痛点是依赖。公网一句pip install搞定的事内网要提前把所有依赖打包带进去。我的做法是在公网环境准备一个完整的离线依赖包。用pip download把所有 Python 依赖下载到本地目录包括间接依赖。模型权重、工具二进制、配置文件全部打包。然后通过内网允许的方式比如内部文件服务器、移动介质传进去。打包时要注意版本锁定。内网环境升级困难依赖版本一旦确定就不要轻易改。用requirements.txt锁定精确版本避免“在我机器上能跑”的问题。还要准备依赖安装脚本。内网服务器可能没有网络安装脚本要能离线执行处理各种环境差异Python 版本、系统库、CUDA 版本。这个脚本要提前在类似环境测试过不要到了现场才发现装不上。7.2 服务编排Agent 各组件怎么协同启动内网 Agent 通常由多个组件构成模型服务、MCP 工具服务、Agent 编排服务、队列、日志系统。这些组件怎么启动、怎么协同要有明确的编排方案。简单场景可以用脚本加进程管理比如写一个启动脚本按顺序拉起各个服务用 supervisor 或 systemd 管理进程。复杂场景可以用容器编排但内网环境容器镜像的获取和更新也是个问题要提前规划。启动顺序很重要。模型服务要先起来工具服务其次Agent 编排服务最后。Agent 启动时要检查依赖服务是否就绪没就绪就等待或告警。不要假设所有服务都能同时起来内网环境启动慢是常态。健康检查不能少。每个服务要有健康检查接口Agent 定期探测。发现服务不健康及时告警并尝试重启。内网环境人工干预成本高能自动恢复的尽量自动恢复。7.3 日常运维监控什么、告警什么内网 Agent 上线后运维是长期工作。监控和告警要抓住重点不要什么都监控否则告警疲劳。必须监控的指标模型服务的 GPU 显存和利用率、请求队列长度、任务成功率、平均任务耗时、工具调用失败率。这些指标直接反映系统健康度。必须告警的场景模型服务不可用、队列积压超过阈值、任务成功率骤降、工具调用大面积失败。告警要分级严重的立即通知一般的汇总日报。日志轮转和清理也要规划。内网磁盘空间有限日志不能无限增长。设置合理的轮转策略保留最近 N 天的详细日志更早的归档或清理。最后分享一个运维心得定期做故障演练。手动停掉某个服务看系统能不能正确告警和恢复。内网环境出问题时现场往往很紧张提前演练过处理起来就有底。我在一个项目里坚持每月做一次演练后来真的遇到模型服务崩溃时团队五分钟内就恢复了因为流程已经跑熟了。内网 AI Agent 工程没有银弹它是一堆细节的堆叠模型要能跑、工具要能通、Skills 要能复用、并发要能扛、问题要能查、部署要能稳。每一环都不难难的是把它们串起来并在隔离环境下持续运转。我最大的体会是不要追求一步到位先把最小链路跑通再逐步加固。内网环境变化慢但一旦跑顺它的稳定性和数据安全性是公网方案给不了的。