1. 为什么“隔离内网”这四个字直接改变了 AI Agent 的工程打法先把场景说清楚。所谓隔离内网通常指物理隔离或逻辑强隔离的办公网、生产网、研发网机器不能直接访问公网装个包要走内部镜像源拉个模型权重得靠审批流把文件摆渡进来。在这种环境里做 AI Agent和你在大平层里用云端 API 拼一个 Demo完全是两码事。公网环境下你随手pip install一个 SDK、调一个在线大模型接口就能跑通的东西到了内网每一步都要重新回答三个问题依赖从哪来、模型在哪跑、数据怎么不出门。我前后在三个不同隔离级别的内网里落地过 Agent 工程从最初“把公网方案硬搬进来结果处处撞墙”到后来形成一套相对稳定的打法踩的坑足够写一本小册子。这篇就把这套经验完整摊开讲。核心结论先摆在这隔离内网下 AI Agent 的工程重心不是模型能力而是“可离线、可审批、可审计、可降级”这四件事。模型选型反而是相对靠后的问题因为在内网里一个 7B 到 14B 的本地模型配上好的工具编排往往比一个调不通的云端大模型更管用。这篇文章适合三类人看。第一类是被派到内网环境做 AI 落地的工程师手里有需求但发现公网那套教程全部失效第二类是负责内网平台建设的人需要判断 Agent 框架、MCP 协议、Skills 机制这些新东西到底能不能搬进隔离环境第三类是做技术选型和审批材料的人需要知道哪些环节会成为卡点、要提前准备什么。我会把架构选择、MCP 与 Skills 的落地方式、审批链设计、离线依赖管理、以及实测中的坑一层层拆开讲。先给一个整体判断避免你走弯路。内网 Agent 的架构本质上是一个“本地模型 本地工具服务 审批网关 审计日志”的四件套。公网流行的 Agent 编排框架大多假设你能随时访问外部服务这个假设在内网直接不成立所以框架要么裁剪要么自研轻量编排层。MCP 这类协议的价值在内网反而更大因为它把“工具调用”标准化了标准化意味着可审计、可审批、可替换。Skills 机制则解决了“能力按需加载”的问题避免把一堆用不上的工具全塞进上下文。下面逐层展开。2. 内网 Agent 的架构选型哪些公网方案能搬哪些必须换2.1 先明确内网 Agent 的能力边界在动手选框架之前必须先画一条线这个 Agent 到底要干什么。内网场景下Agent 的典型任务集中在几类——内部知识库问答、工单与审批流的自动处理、代码仓库的检索与辅助、日志与告警的分析归因、以及跨内部系统的数据搬运与格式转换。这些任务的共同点是数据敏感、流程固定、结果需要可追溯。它们和公网上那种“帮我写篇小红书文案”“自动发消息”的开放域任务性质完全不同。这个差异直接决定了架构。开放域任务需要模型有很强的泛化和创造力所以大家拼命追大参数模型内网任务大多是受约束的流程执行模型更多扮演“理解意图 选择工具 组织结果”的角色真正的执行逻辑应该落在确定性的工具服务里。我见过太多团队一上来就想在内网部署一个“什么都能干”的通用 Agent结果模型能力不够、工具又没编排好最后变成一个答非所问的聊天框。所以第一步是收敛范围。我的做法是列一张任务清单每个任务标注三件事输入是什么、输出是什么、中间需要调用哪些内部系统。凡是中间步骤超过五步、或者需要跨三个以上系统的任务第一版一律不做留给后续迭代。这个收敛动作看起来保守但它能让你的第一版 Agent 在两周内跑起来而不是在架构讨论里耗三个月。2.2 编排框架的取舍为什么我最后选了轻量自研层公网主流的 Agent 编排框架比如各种基于 ReAct、Plan-and-Execute 的实现设计时默认你能访问外部 LLM API 和外部工具。搬到内网问题立刻暴露框架内部可能硬编码了某些外部服务的调用、依赖的某些库在内网镜像源里没有、或者它的可观测性组件需要上报到外部。裁剪这些依赖的工作量有时候比自己写一个编排层还大。我最终的方案是自研一个轻量编排层核心逻辑不超过几百行一个任务解析器、一个工具注册表、一个执行循环、一个结果聚合器。执行循环就是标准的“模型输出工具调用意图 → 解析 → 调用本地工具 → 把结果回填 → 继续”但每一步都加了审计钩子和超时控制。这样做的好处是完全可控没有黑盒依赖出了问题能一行行调试。这里要解释一个关键取舍为什么不用现成的 Agent 框架而自研。理由有三。第一内网的依赖管理成本极高每引入一个第三方框架就要把它及其全部依赖搬进内网镜像源还要评估它的许可证和安全性这个成本远超自研。第二内网 Agent 的任务相对固定不需要框架提供的那些花哨能力比如多 Agent 协作、动态规划这些在受约束场景里反而是干扰。第三审计要求。自研层可以把每一次模型调用、每一次工具执行、每一次数据读写都记成结构化日志现成框架的日志格式往往不满足内网审计规范。当然自研不等于从零造轮子。模型推理用现成的本地推理框架工具服务用标准的 HTTP 或 RPC编排层只做“胶水”。这个边界要划清楚否则自研会失控。2.3 本地模型选型的真实考量内网不能调云端 API模型必须本地部署。这里的选择空间其实比想象中大。7B 到 14B 量级的开源模型经过量化后在单张消费级显卡甚至纯 CPU 上都能跑起来对于“理解意图 选工具”这类任务能力是够用的。我实测下来一个 14B 的指令微调模型在工具选择准确率上能到 85% 以上配合规则兜底整体可用性没问题。选型时要重点看三件事。第一是中文能力内网业务大量是中文工单、中文文档模型的中文理解直接决定效果。第二是工具调用格式的稳定性有些模型对结构化输出支持不好经常吐出格式错误的 JSON这会大幅增加编排层的解析负担。第三是量化后的性能衰减4-bit 量化通常损失可控但更激进的量化会让工具选择准确率明显下降这个要实测。还有一个容易被忽略的点模型许可证。内网部署要过合规审查模型的许可证必须允许商用和内部部署这一点在选型阶段就要确认别等部署完了才发现许可证有问题。3. MCP 在内网的价值把工具调用变成可审批的标准件3.1 MCP 到底解决了内网的什么问题MCP 这类协议的核心是把“模型如何调用外部工具”标准化。在公网它的价值是让工具生态互通在内网它的价值被放大了因为标准化意味着可审计、可审批、可替换。想象一下如果没有标准协议每个工具都是一套自定义的调用方式审计人员根本没法统一审查“这个 Agent 到底能访问哪些系统、能做什么操作”。有了 MCP所有工具都以统一的 server 形式注册每个 server 暴露哪些能力、需要什么权限一目了然。我在内网落地时把每个内部系统的访问都封装成一个 MCP server。比如工单系统一个 server、代码仓库一个 server、日志平台一个 server。每个 server 的配置文件里明确列出它暴露的工具列表和每个工具需要的权限。审批的时候审批人看的不是代码而是这份工具清单——“这个 Agent 能读工单、能改工单状态、能查日志但不能删数据”这种颗粒度的审批才是有意义的。3.2 内网 MCP server 的部署形态内网部署 MCP server最稳妥的形态是本地进程 本地回环通信。也就是说MCP server 和 Agent 编排层跑在同一台或同一组机器上通过本地端口通信不经过任何外部网络。这样做的好处是数据不出机器审计日志集中而且延迟低。具体部署时我会给每个 MCP server 单独配置一个受限的运行账户这个账户只有访问对应内部系统的最小权限。比如工单 server 的运行账户只能调工单系统的读接口和有限的写接口不能碰其他系统。这是内网安全的基本功但在 Agent 场景下尤其重要因为 Agent 会自主决定调用哪个工具一旦某个 server 权限过大模型的一次误判就可能造成越权操作。还有一个实操细节MCP server 的启动和健康检查要纳入内网现有的服务管理体系。别搞一套独立的进程管理否则运维会疯。我一般把 MCP server 做成标准的内部服务用内网已有的服务注册和监控体系来管这样运维团队不用学新东西。3.3 工具描述的写法直接决定模型选得准不准这一点是内网 Agent 落地里最容易被低估的。MCP server 暴露的每个工具都有一段描述文本模型就是靠这段描述来判断“当前任务该用哪个工具”。描述写得含糊模型就会乱选。我踩过的坑是早期工具描述写得太技术化比如“query_ticket_db”模型根本不知道这是干嘛的后来改成“根据工单编号查询工单的详细信息和当前状态”选择准确率立刻上去了。写工具描述有几条经验。第一用业务语言而不是技术语言模型理解的是语义不是函数名。第二明确写出工具的输入和输出尤其是输入参数的格式和含义这能减少模型传错参数的概率。第三如果两个工具功能相近一定要在描述里写清楚区别和适用场景否则模型会在两者之间反复横跳。第四描述里可以带上“什么时候不该用这个工具”的提示这对减少误调用很有效。4. Skills 机制让 Agent 按需加载能力而不是全量塞入4.1 Skills 和 MCP 的分工很多人会把 Skills 和 MCP 搞混其实它们解决的是不同层面的问题。MCP 解决的是“工具怎么被标准化调用”Skills 解决的是“能力怎么被组织和按需加载”。一个 Skill 通常是一组相关的指令、工具组合和领域知识的封装它描述的是“完成某类任务的方法”而不是单个工具。在内网场景下Skills 的价值在于控制上下文和权限的粒度。如果所有工具都常驻在 Agent 的上下文里一方面上下文会被撑爆模型选择困难另一方面权限管理会变得很粗因为所有工具对所有任务都可见。用 Skills 把能力分组比如“工单处理 Skill”“日志分析 Skill”“代码检索 Skill”Agent 在处理具体任务时只加载对应的 Skill上下文干净权限也清晰。4.2 内网 Skills 的组织方式内网里组织 Skills我建议按业务域而不是按技术类型来分。按技术类型分比如“数据库 Skill”“HTTP Skill”会导致一个业务任务需要同时加载好几个 Skill反而更乱。按业务域分一个 Skill 内部可以包含多个 MCP 工具、若干提示词模板和领域知识片段Agent 加载一个 Skill 就能完整处理一类任务。每个 Skill 的目录结构我一般这样组织一个描述文件说明这个 Skill 干什么、什么时候用一个工具清单列出它依赖的 MCP 工具一组提示词模板以及可选的领域知识文件。这个结构简单但足够清晰审批的时候也好看——审批人看一个 Skill 目录就知道这个能力包能干什么。4.3 Skill 加载的触发逻辑Skill 什么时候被加载这个逻辑要设计好。最简单的做法是让模型自己判断但内网场景下我更倾向于规则优先 模型兜底。也就是说先根据任务来源或关键词匹配到候选 Skill如果匹配明确就直接加载匹配不明确时再让模型从 Skill 列表里选。这样做的好处是行为可预测审计的时候能解释“为什么这个任务加载了这个 Skill”。规则优先还有一个实际好处减少模型调用次数。内网模型推理资源通常紧张能省一次调用就省一次。我实测下来规则优先能把平均模型调用次数降低三成左右对整体吞吐提升明显。5. 审批链设计内网 Agent 绕不过去的那道关5.1 审批到底审什么内网做 Agent审批是绕不过去的。但很多团队把审批做成了形式主义审批人签个字就过了这既没起到风控作用又拖慢了迭代。我的做法是把审批拆成三个层次每个层次审不同的东西。第一层是能力审批审的是这个 Agent 能访问哪些系统、能执行哪些操作。这一层在 Agent 上线前一次性完成审的是 MCP 工具清单和 Skill 清单。第二层是变更审批Agent 新增工具、修改工具描述、调整 Skill 组合时触发审的是变更内容。第三层是运行时审批针对高风险操作比如写操作、批量操作、跨系统数据搬运在 Agent 实际执行前需要人工确认。这三层里第一层和第二层是流程性的第三层是实时的。很多团队只做了第一层结果 Agent 上线后模型误判导致越权写操作出了事才发现没有运行时拦截。5.2 运行时审批的实现方式运行时审批的实现核心是在编排层里加一个“拦截点”。当 Agent 决定调用某个被标记为高风险的 MCP 工具时编排层不直接执行而是生成一条审批请求推送到审批系统等人工确认后再继续。这个拦截点要设计得足够轻不能因为加了审批就让整个流程卡死。实操上有几个细节要注意。第一审批请求要带上足够的上下文让审批人知道“Agent 为什么要做这个操作、基于什么信息”否则审批人只能盲批。第二要有超时机制审批长时间没响应要能自动降级或终止不能无限等待。第三审批结果要回写到审计日志形成完整链路。5.3 审批粒度怎么定才不拖垮效率审批粒度是个平衡问题。粒度太粗风控形同虚设粒度太细Agent 每做一步都要审批效率归零。我的经验是按“操作的影响范围”来定只读操作不审批单条写操作记录不审批批量写操作和跨系统操作审批删除类操作一律审批。这个分级覆盖了绝大多数风险场景同时把审批量控制在可接受范围。还有一个技巧是白名单机制。对于高频且低风险的操作组合可以预先审批成白名单Agent 执行时直接放行。白名单要定期复核避免权限沉淀。6. 离线依赖管理内网工程里最磨人的部分6.1 依赖摆渡的完整流程内网装不了公网的包所有依赖都要靠摆渡。这个流程听起来简单做起来极其磨人。我的标准流程是在公网环境用pip download或类似方式把包及其全部依赖下载到本地目录生成依赖清单和哈希校验值然后通过内网的文件摆渡流程把整个目录传进去在内网用离线安装方式安装。这里的关键是依赖的完整性。pip download默认只下载直接依赖间接依赖要加参数才能下全。我一般用pip download -d ./packages -r requirements.txt配合--no-binary之类的选项确保所有依赖都下全。下完之后要在干净环境里验证一遍离线安装能成功别等摆渡进去了才发现缺包那就要重走一遍流程。6.2 内部镜像源的搭建与维护长期做内网 Agent靠手动摆渡不现实必须搭内部镜像源。内部镜像源的作用是把公网的包同步进来内网机器直接从镜像源装。搭建镜像源本身不难难的是维护——要定期同步、要处理同步失败、要管理版本。我的做法是只同步实际用到的包不做全量镜像。全量镜像体积巨大且大部分用不上维护成本高。具体是维护一份“允许清单”清单里的包才同步新增包要走申请。这样镜像源体积可控安全审查也好做。6.3 模型权重的摆渡与校验模型权重文件通常几个 GB 到几十 GB摆渡是个体力活。我的经验是分块传输加哈希校验传完之后逐块校验确保没有损坏。权重文件损坏是内网部署里很隐蔽的坑模型能加载但输出乱码排查半天才发现是文件传输出了问题。另外模型权重也要纳入版本管理。不同版本的权重对应不同的行为Agent 上线后如果权重被悄悄替换行为会变审计链路就断了。所以权重的哈希值要记录在案每次加载都校验。7. 实测中那些文档不会写的坑7.1 模型输出格式不稳定导致的解析失败这是最高频的坑。内网模型在工具调用时经常吐出格式不标准的 JSON比如多了个逗号、少了引号、或者把 JSON 包在自然语言里。编排层的解析器必须足够健壮我的做法是三层解析先尝试标准 JSON 解析失败则用正则提取 JSON 片段再解析再失败则让模型重新生成一次。三层下来解析成功率能到 99% 以上。7.2 上下文长度与工具数量的矛盾工具一多上下文就长模型选择准确率反而下降。我实测发现当常驻工具超过 15 个时选择准确率开始明显下滑。解决办法就是前面说的 Skills 机制按需加载把常驻工具控制在 10 个以内。7.3 审计日志的存储与检索审计日志量很大每次模型调用、每次工具执行都要记。如果直接写文件检索困难如果写数据库写入压力大。我的方案是结构化日志写本地文件按天滚动同时异步同步到内网的日志平台。检索走日志平台原始文件保留用于合规审查。7.4 模型推理资源的争抢内网 GPU 资源通常紧张多个 Agent 任务并发时容易争抢。我的做法是给 Agent 推理单独划一个资源池和训练任务隔离同时加请求队列和限流避免把推理服务打挂。8. 从零到一落地内网 Agent 的实操顺序把上面的经验串成一条可执行的路径。第一步收敛任务范围列出首批要支持的任务清单每个任务标注输入输出和依赖系统。第二步搭建本地模型推理服务选一个中文能力好、工具调用稳定的模型量化后部署实测工具选择准确率。第三步封装 MCP server每个内部系统一个配置最小权限运行账户写好工具描述。第四步自研轻量编排层实现执行循环、审计钩子、超时控制和运行时审批拦截点。第五步组织 Skills按业务域分组设计规则优先的加载逻辑。第六步搭建内部镜像源和依赖摆渡流程。第七步接入审批系统和审计日志平台。第八步小范围试点收集失败案例迭代工具描述和 Skill 组合。这个顺序里模型和编排层是基础MCP 和 Skills 是能力组织审批和审计是合规保障依赖管理是工程支撑。任何一步跳过都会在后面付出代价。我个人最大的体会是内网 Agent 的成败八成取决于工程细节而不是模型能力。把工具描述写清楚、把审批粒度定合理、把依赖管理做扎实比换一个更大的模型有用得多。
1. 为什么“隔离内网”这四个字直接改变了 AI Agent 的工程打法先把场景说清楚。所谓隔离内网通常指物理隔离或逻辑强隔离的办公网、生产网、研发网机器不能直接访问公网装个包要走内部镜像源拉个模型权重得靠审批流把文件摆渡进来。在这种环境里做 AI Agent和你在大平层里用云端 API 拼一个 Demo完全是两码事。公网环境下你随手pip install一个 SDK、调一个在线大模型接口就能跑通的东西到了内网每一步都要重新回答三个问题依赖从哪来、模型在哪跑、数据怎么不出门。我前后在三个不同隔离级别的内网里落地过 Agent 工程从最初“把公网方案硬搬进来结果处处撞墙”到后来形成一套相对稳定的打法踩的坑足够写一本小册子。这篇就把这套经验完整摊开讲。核心结论先摆在这隔离内网下 AI Agent 的工程重心不是模型能力而是“可离线、可审批、可审计、可降级”这四件事。模型选型反而是相对靠后的问题因为在内网里一个 7B 到 14B 的本地模型配上好的工具编排往往比一个调不通的云端大模型更管用。这篇文章适合三类人看。第一类是被派到内网环境做 AI 落地的工程师手里有需求但发现公网那套教程全部失效第二类是负责内网平台建设的人需要判断 Agent 框架、MCP 协议、Skills 机制这些新东西到底能不能搬进隔离环境第三类是做技术选型和审批材料的人需要知道哪些环节会成为卡点、要提前准备什么。我会把架构选择、MCP 与 Skills 的落地方式、审批链设计、离线依赖管理、以及实测中的坑一层层拆开讲。先给一个整体判断避免你走弯路。内网 Agent 的架构本质上是一个“本地模型 本地工具服务 审批网关 审计日志”的四件套。公网流行的 Agent 编排框架大多假设你能随时访问外部服务这个假设在内网直接不成立所以框架要么裁剪要么自研轻量编排层。MCP 这类协议的价值在内网反而更大因为它把“工具调用”标准化了标准化意味着可审计、可审批、可替换。Skills 机制则解决了“能力按需加载”的问题避免把一堆用不上的工具全塞进上下文。下面逐层展开。2. 内网 Agent 的架构选型哪些公网方案能搬哪些必须换2.1 先明确内网 Agent 的能力边界在动手选框架之前必须先画一条线这个 Agent 到底要干什么。内网场景下Agent 的典型任务集中在几类——内部知识库问答、工单与审批流的自动处理、代码仓库的检索与辅助、日志与告警的分析归因、以及跨内部系统的数据搬运与格式转换。这些任务的共同点是数据敏感、流程固定、结果需要可追溯。它们和公网上那种“帮我写篇小红书文案”“自动发消息”的开放域任务性质完全不同。这个差异直接决定了架构。开放域任务需要模型有很强的泛化和创造力所以大家拼命追大参数模型内网任务大多是受约束的流程执行模型更多扮演“理解意图 选择工具 组织结果”的角色真正的执行逻辑应该落在确定性的工具服务里。我见过太多团队一上来就想在内网部署一个“什么都能干”的通用 Agent结果模型能力不够、工具又没编排好最后变成一个答非所问的聊天框。所以第一步是收敛范围。我的做法是列一张任务清单每个任务标注三件事输入是什么、输出是什么、中间需要调用哪些内部系统。凡是中间步骤超过五步、或者需要跨三个以上系统的任务第一版一律不做留给后续迭代。这个收敛动作看起来保守但它能让你的第一版 Agent 在两周内跑起来而不是在架构讨论里耗三个月。2.2 编排框架的取舍为什么我最后选了轻量自研层公网主流的 Agent 编排框架比如各种基于 ReAct、Plan-and-Execute 的实现设计时默认你能访问外部 LLM API 和外部工具。搬到内网问题立刻暴露框架内部可能硬编码了某些外部服务的调用、依赖的某些库在内网镜像源里没有、或者它的可观测性组件需要上报到外部。裁剪这些依赖的工作量有时候比自己写一个编排层还大。我最终的方案是自研一个轻量编排层核心逻辑不超过几百行一个任务解析器、一个工具注册表、一个执行循环、一个结果聚合器。执行循环就是标准的“模型输出工具调用意图 → 解析 → 调用本地工具 → 把结果回填 → 继续”但每一步都加了审计钩子和超时控制。这样做的好处是完全可控没有黑盒依赖出了问题能一行行调试。这里要解释一个关键取舍为什么不用现成的 Agent 框架而自研。理由有三。第一内网的依赖管理成本极高每引入一个第三方框架就要把它及其全部依赖搬进内网镜像源还要评估它的许可证和安全性这个成本远超自研。第二内网 Agent 的任务相对固定不需要框架提供的那些花哨能力比如多 Agent 协作、动态规划这些在受约束场景里反而是干扰。第三审计要求。自研层可以把每一次模型调用、每一次工具执行、每一次数据读写都记成结构化日志现成框架的日志格式往往不满足内网审计规范。当然自研不等于从零造轮子。模型推理用现成的本地推理框架工具服务用标准的 HTTP 或 RPC编排层只做“胶水”。这个边界要划清楚否则自研会失控。2.3 本地模型选型的真实考量内网不能调云端 API模型必须本地部署。这里的选择空间其实比想象中大。7B 到 14B 量级的开源模型经过量化后在单张消费级显卡甚至纯 CPU 上都能跑起来对于“理解意图 选工具”这类任务能力是够用的。我实测下来一个 14B 的指令微调模型在工具选择准确率上能到 85% 以上配合规则兜底整体可用性没问题。选型时要重点看三件事。第一是中文能力内网业务大量是中文工单、中文文档模型的中文理解直接决定效果。第二是工具调用格式的稳定性有些模型对结构化输出支持不好经常吐出格式错误的 JSON这会大幅增加编排层的解析负担。第三是量化后的性能衰减4-bit 量化通常损失可控但更激进的量化会让工具选择准确率明显下降这个要实测。还有一个容易被忽略的点模型许可证。内网部署要过合规审查模型的许可证必须允许商用和内部部署这一点在选型阶段就要确认别等部署完了才发现许可证有问题。3. MCP 在内网的价值把工具调用变成可审批的标准件3.1 MCP 到底解决了内网的什么问题MCP 这类协议的核心是把“模型如何调用外部工具”标准化。在公网它的价值是让工具生态互通在内网它的价值被放大了因为标准化意味着可审计、可审批、可替换。想象一下如果没有标准协议每个工具都是一套自定义的调用方式审计人员根本没法统一审查“这个 Agent 到底能访问哪些系统、能做什么操作”。有了 MCP所有工具都以统一的 server 形式注册每个 server 暴露哪些能力、需要什么权限一目了然。我在内网落地时把每个内部系统的访问都封装成一个 MCP server。比如工单系统一个 server、代码仓库一个 server、日志平台一个 server。每个 server 的配置文件里明确列出它暴露的工具列表和每个工具需要的权限。审批的时候审批人看的不是代码而是这份工具清单——“这个 Agent 能读工单、能改工单状态、能查日志但不能删数据”这种颗粒度的审批才是有意义的。3.2 内网 MCP server 的部署形态内网部署 MCP server最稳妥的形态是本地进程 本地回环通信。也就是说MCP server 和 Agent 编排层跑在同一台或同一组机器上通过本地端口通信不经过任何外部网络。这样做的好处是数据不出机器审计日志集中而且延迟低。具体部署时我会给每个 MCP server 单独配置一个受限的运行账户这个账户只有访问对应内部系统的最小权限。比如工单 server 的运行账户只能调工单系统的读接口和有限的写接口不能碰其他系统。这是内网安全的基本功但在 Agent 场景下尤其重要因为 Agent 会自主决定调用哪个工具一旦某个 server 权限过大模型的一次误判就可能造成越权操作。还有一个实操细节MCP server 的启动和健康检查要纳入内网现有的服务管理体系。别搞一套独立的进程管理否则运维会疯。我一般把 MCP server 做成标准的内部服务用内网已有的服务注册和监控体系来管这样运维团队不用学新东西。3.3 工具描述的写法直接决定模型选得准不准这一点是内网 Agent 落地里最容易被低估的。MCP server 暴露的每个工具都有一段描述文本模型就是靠这段描述来判断“当前任务该用哪个工具”。描述写得含糊模型就会乱选。我踩过的坑是早期工具描述写得太技术化比如“query_ticket_db”模型根本不知道这是干嘛的后来改成“根据工单编号查询工单的详细信息和当前状态”选择准确率立刻上去了。写工具描述有几条经验。第一用业务语言而不是技术语言模型理解的是语义不是函数名。第二明确写出工具的输入和输出尤其是输入参数的格式和含义这能减少模型传错参数的概率。第三如果两个工具功能相近一定要在描述里写清楚区别和适用场景否则模型会在两者之间反复横跳。第四描述里可以带上“什么时候不该用这个工具”的提示这对减少误调用很有效。4. Skills 机制让 Agent 按需加载能力而不是全量塞入4.1 Skills 和 MCP 的分工很多人会把 Skills 和 MCP 搞混其实它们解决的是不同层面的问题。MCP 解决的是“工具怎么被标准化调用”Skills 解决的是“能力怎么被组织和按需加载”。一个 Skill 通常是一组相关的指令、工具组合和领域知识的封装它描述的是“完成某类任务的方法”而不是单个工具。在内网场景下Skills 的价值在于控制上下文和权限的粒度。如果所有工具都常驻在 Agent 的上下文里一方面上下文会被撑爆模型选择困难另一方面权限管理会变得很粗因为所有工具对所有任务都可见。用 Skills 把能力分组比如“工单处理 Skill”“日志分析 Skill”“代码检索 Skill”Agent 在处理具体任务时只加载对应的 Skill上下文干净权限也清晰。4.2 内网 Skills 的组织方式内网里组织 Skills我建议按业务域而不是按技术类型来分。按技术类型分比如“数据库 Skill”“HTTP Skill”会导致一个业务任务需要同时加载好几个 Skill反而更乱。按业务域分一个 Skill 内部可以包含多个 MCP 工具、若干提示词模板和领域知识片段Agent 加载一个 Skill 就能完整处理一类任务。每个 Skill 的目录结构我一般这样组织一个描述文件说明这个 Skill 干什么、什么时候用一个工具清单列出它依赖的 MCP 工具一组提示词模板以及可选的领域知识文件。这个结构简单但足够清晰审批的时候也好看——审批人看一个 Skill 目录就知道这个能力包能干什么。4.3 Skill 加载的触发逻辑Skill 什么时候被加载这个逻辑要设计好。最简单的做法是让模型自己判断但内网场景下我更倾向于规则优先 模型兜底。也就是说先根据任务来源或关键词匹配到候选 Skill如果匹配明确就直接加载匹配不明确时再让模型从 Skill 列表里选。这样做的好处是行为可预测审计的时候能解释“为什么这个任务加载了这个 Skill”。规则优先还有一个实际好处减少模型调用次数。内网模型推理资源通常紧张能省一次调用就省一次。我实测下来规则优先能把平均模型调用次数降低三成左右对整体吞吐提升明显。5. 审批链设计内网 Agent 绕不过去的那道关5.1 审批到底审什么内网做 Agent审批是绕不过去的。但很多团队把审批做成了形式主义审批人签个字就过了这既没起到风控作用又拖慢了迭代。我的做法是把审批拆成三个层次每个层次审不同的东西。第一层是能力审批审的是这个 Agent 能访问哪些系统、能执行哪些操作。这一层在 Agent 上线前一次性完成审的是 MCP 工具清单和 Skill 清单。第二层是变更审批Agent 新增工具、修改工具描述、调整 Skill 组合时触发审的是变更内容。第三层是运行时审批针对高风险操作比如写操作、批量操作、跨系统数据搬运在 Agent 实际执行前需要人工确认。这三层里第一层和第二层是流程性的第三层是实时的。很多团队只做了第一层结果 Agent 上线后模型误判导致越权写操作出了事才发现没有运行时拦截。5.2 运行时审批的实现方式运行时审批的实现核心是在编排层里加一个“拦截点”。当 Agent 决定调用某个被标记为高风险的 MCP 工具时编排层不直接执行而是生成一条审批请求推送到审批系统等人工确认后再继续。这个拦截点要设计得足够轻不能因为加了审批就让整个流程卡死。实操上有几个细节要注意。第一审批请求要带上足够的上下文让审批人知道“Agent 为什么要做这个操作、基于什么信息”否则审批人只能盲批。第二要有超时机制审批长时间没响应要能自动降级或终止不能无限等待。第三审批结果要回写到审计日志形成完整链路。5.3 审批粒度怎么定才不拖垮效率审批粒度是个平衡问题。粒度太粗风控形同虚设粒度太细Agent 每做一步都要审批效率归零。我的经验是按“操作的影响范围”来定只读操作不审批单条写操作记录不审批批量写操作和跨系统操作审批删除类操作一律审批。这个分级覆盖了绝大多数风险场景同时把审批量控制在可接受范围。还有一个技巧是白名单机制。对于高频且低风险的操作组合可以预先审批成白名单Agent 执行时直接放行。白名单要定期复核避免权限沉淀。6. 离线依赖管理内网工程里最磨人的部分6.1 依赖摆渡的完整流程内网装不了公网的包所有依赖都要靠摆渡。这个流程听起来简单做起来极其磨人。我的标准流程是在公网环境用pip download或类似方式把包及其全部依赖下载到本地目录生成依赖清单和哈希校验值然后通过内网的文件摆渡流程把整个目录传进去在内网用离线安装方式安装。这里的关键是依赖的完整性。pip download默认只下载直接依赖间接依赖要加参数才能下全。我一般用pip download -d ./packages -r requirements.txt配合--no-binary之类的选项确保所有依赖都下全。下完之后要在干净环境里验证一遍离线安装能成功别等摆渡进去了才发现缺包那就要重走一遍流程。6.2 内部镜像源的搭建与维护长期做内网 Agent靠手动摆渡不现实必须搭内部镜像源。内部镜像源的作用是把公网的包同步进来内网机器直接从镜像源装。搭建镜像源本身不难难的是维护——要定期同步、要处理同步失败、要管理版本。我的做法是只同步实际用到的包不做全量镜像。全量镜像体积巨大且大部分用不上维护成本高。具体是维护一份“允许清单”清单里的包才同步新增包要走申请。这样镜像源体积可控安全审查也好做。6.3 模型权重的摆渡与校验模型权重文件通常几个 GB 到几十 GB摆渡是个体力活。我的经验是分块传输加哈希校验传完之后逐块校验确保没有损坏。权重文件损坏是内网部署里很隐蔽的坑模型能加载但输出乱码排查半天才发现是文件传输出了问题。另外模型权重也要纳入版本管理。不同版本的权重对应不同的行为Agent 上线后如果权重被悄悄替换行为会变审计链路就断了。所以权重的哈希值要记录在案每次加载都校验。7. 实测中那些文档不会写的坑7.1 模型输出格式不稳定导致的解析失败这是最高频的坑。内网模型在工具调用时经常吐出格式不标准的 JSON比如多了个逗号、少了引号、或者把 JSON 包在自然语言里。编排层的解析器必须足够健壮我的做法是三层解析先尝试标准 JSON 解析失败则用正则提取 JSON 片段再解析再失败则让模型重新生成一次。三层下来解析成功率能到 99% 以上。7.2 上下文长度与工具数量的矛盾工具一多上下文就长模型选择准确率反而下降。我实测发现当常驻工具超过 15 个时选择准确率开始明显下滑。解决办法就是前面说的 Skills 机制按需加载把常驻工具控制在 10 个以内。7.3 审计日志的存储与检索审计日志量很大每次模型调用、每次工具执行都要记。如果直接写文件检索困难如果写数据库写入压力大。我的方案是结构化日志写本地文件按天滚动同时异步同步到内网的日志平台。检索走日志平台原始文件保留用于合规审查。7.4 模型推理资源的争抢内网 GPU 资源通常紧张多个 Agent 任务并发时容易争抢。我的做法是给 Agent 推理单独划一个资源池和训练任务隔离同时加请求队列和限流避免把推理服务打挂。8. 从零到一落地内网 Agent 的实操顺序把上面的经验串成一条可执行的路径。第一步收敛任务范围列出首批要支持的任务清单每个任务标注输入输出和依赖系统。第二步搭建本地模型推理服务选一个中文能力好、工具调用稳定的模型量化后部署实测工具选择准确率。第三步封装 MCP server每个内部系统一个配置最小权限运行账户写好工具描述。第四步自研轻量编排层实现执行循环、审计钩子、超时控制和运行时审批拦截点。第五步组织 Skills按业务域分组设计规则优先的加载逻辑。第六步搭建内部镜像源和依赖摆渡流程。第七步接入审批系统和审计日志平台。第八步小范围试点收集失败案例迭代工具描述和 Skill 组合。这个顺序里模型和编排层是基础MCP 和 Skills 是能力组织审批和审计是合规保障依赖管理是工程支撑。任何一步跳过都会在后面付出代价。我个人最大的体会是内网 Agent 的成败八成取决于工程细节而不是模型能力。把工具描述写清楚、把审批粒度定合理、把依赖管理做扎实比换一个更大的模型有用得多。
