企业官网建设流程全解析

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 的成败，八成取决于工程细节而不是模型能力。把工具描述写清楚、把审批粒度定合理、把依赖管理做扎实，比换一个更大的模型有用得多。