先别急着找算法工程师。前阵子有个传统行业的负责人问我公司想把AI用起来但合同、设计稿、售后工单又不敢随便传上公网怎么办我的回答很直接——把模型搬到公司内网而不是把核心数据搬到模型那边。这句话听起来像口号真做起来其实就是两件事数据不出域开发入口内网化后者能把开发门槛拉低到“懂HTTP请求就行”。这两年AI开发的内网化趋势比很多人想象中更明显。企业数据留在内网不是因为技术保守而是因为敏感数据一旦出域风险和责任都不可控AI开发门槛降到最低也不是靠某个“零代码平台”一步到位而是靠模型服务化、接口标准化、工具链低代码化这三层配合。这套思路我帮好几家单位落地过有制造业、有医院、有设计类团队期间踩了不少坑也沉淀了一些可复制的经验。下面把完整过程拆给你看。1. 数据留内网这件事先要解决“敢不敢”和“划哪里”1.1 外部AI服务为什么越用越心虚很多企业内部不是没有AI应用而是大家私下都在用信息部门却不知道。员工把需求文档粘贴到网页对话里把客户信息整理成Prompt让公网模型总结甚至把核心系统导出的报表发给外部工具分析。单个行为看起来量不大但聚少成多数据实际上已经离开了企业的网络边界。真正麻烦的不是“理论风险”而是实际场景。客服知识库、合同条款、产品图纸、薪酬制度每一类数据都有明确的归属和保密要求。把这类内容放到一个你无法控制日志去向的平台上一旦出了问题连取证都做不到。更现实的是合规审计人家问你数据存哪了、谁能看、管理员能不能删你答不上来这个问题就过不去。也有人一开始觉得用大厂成熟的API服务不是更方便吗调用稳定、效果不错、按量付费前期成本看着低。但等业务真正跑起来企业会发现自己面对的是几个隐形问题Token费用随调用量线性上涨私有数据的上下文越传越多上游模型策略调整时你的应用行为可能跟着变一旦业务中断或接口调整你没有替代方案。这些问题不像安全那么激烈但一样能卡住项目上线。所以我在帮客户规划时建议的原则是数据有分级能留在内网的任务坚决不出去。普通公开文档训练内部通用助手没问题但涉及经营数据、客户数据、生产参数的场景模型再方便也要先画出一条物理边界。这条边界画清楚“敢不敢”的问题就解决了一半。1.2 内网AI平台的典型边界与三个区把数据留在内网不等于整栋楼断网跑一个孤岛。更务实的做法是把AI能力拆成三个区按需共享、按权限访问。算力区放GPU服务器或工作站负责跑模型推理。这里不存业务源数据只做计算。数据区放知识库、业务系统数据、文档的抽取结果。RAG应用主要从这里读内容。应用区放AI应用、Agent编排、前端页面和API网关。员工通过内部门户访问接口由网关卡一道权限。三个区之间用防火墙规则做些基础限制例如只允许应用区访问数据区的指定服务端口算力区不对办公网直接暴露。VM分开、VLAN隔离、防火墙白名单这三件套在企业内网足够用了。别一开始就上零信任、微隔离那种重型方案先把物理边界梳理清楚后面再逐步加固。我记得有个非遗服饰设计团队给出的例子特别形象。她们把过去手工整理的3000余种传统纹样和200余种针法参数放在内网数据库和文件服务器里再接入本地部署的AI辅助设计系统。设计师在内部系统里输入“要一个带凤凰纹样的袖口设计”系统在本地知识库检索后结合模型给出线稿。数据不出内网设计师也不会用个人账号把素材带到外部工具里这样传统文化资料的价值才能安全积累下来。1.3 AI开发要的人手没有想象中那么多另一个让企业犹豫的点是“我不会训练模型”。这个顾虑可以放下了。现在做企业内部AI开发默认路径不是从零预训练而是用成熟开源模型做二次开发和系统集成。模型是别人训练好的你只需要做好三类工作部署模型服务、接入企业数据、设计应用逻辑。说白了信息部门一个熟悉Linux、会调接口的工程师再把业务方人员拉进来做测试反馈就差不多可以启动最小项目了。没有大模型算法背景并不妨碍干活因为难度已经从前沿研究转移到了工程落地。反过来讲如果建立一个AI应用团队需要先招一群算法博士那门槛永远降不下来但如果是把AI能力当成一个内部基础设施去推普通工程师完全可以接得住。2. 模型选型和内网部署先把“AI开发门槛”拆解到能跑2.1 不同业务任务匹配不同参数规模部署模型之前先明确一个核心区分企业内部大多数任务是“文档密集型”和“规则密集型”不是“复杂推理密集型”。常见场景比如制度问答、请假政策解释、合同要素抽取、售后工单分类这类任务对语言理解有一定要求但不需要在脑子里解一道高数题。把问题捋清楚之后模型参数的选型就有依据了。我这边落地过的经验是7B到14B参数的模型能覆盖大多数通用对话、文案改写、文本分类、客服问答。单卡24GB显存的机器就能跑得很好速度快、部署简单适合作为企业默认模型。32B左右的模型在长文档总结、结构化信息抽取、较复杂的SQL生成或代码辅助上表现更稳。需要双卡或48GB以上显存机器。70B以上适合强推理或高专业度任务。但硬件成本和运维复杂度明显上升如果不是核心场景不建议上来就奔着最大参数去。如果有人问“那个几百B参数的模型不更聪明吗”我会反问一句你业务里需要它聪明到解奥数题吗大部分企业场景更需要的是稳定、快、可干预、数据不出门。选择能力刚好够用的模型比追逐最强模型划算得多。好用的国产开源模型现在很多例如阿里千问的Qwen2.5系列从0.5B到72B都有另外还有各类垂直微调版本。单看技术细节Qwen2.5-7B-Instruct的对话能力已经比两年前的很多大模型强得多完全能担起内部基础服务的工作。2.2 用Ollama把对话模型跑起来的完整过程我最早帮客户部署时习惯直接在服务器上编译Transformers那一套代码装环境能折腾两三天。后来发现内部项目更重要的是快速验证于是开始用Ollama这一类推理工具。它把模型下载、加载、API服务都简化了特别适合内网环境快速验证。一个典型的部署流程如下第一步准备一台装有Linux系统的服务器或者虚拟机。如果实际环境只有Windows Server也可以但后面我会单独讲Windows下的坑。有GPU最好没有GPU拿纯CPU也能跑小模型只是响应会慢一些。第二步安装Ollama。能联网的话直接下载官方安装包然后做离线分发。更多时候是内网机器需要先在允许联网的机器上把安装包和模型文件拉到本地再用U盘或内网文件服务器拷进生产机。模型文件导入目录后Ollama会自动识别。第三步配置服务监听地址。默认Ollama会监听127.0.0.1也就是只能本机访问这样就失去了服务化的意义。需要让模型服务绑定内网IP# 编辑系统服务配置 sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf EOF [Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_MODELS/data/ollama/models EOF sudo systemctl daemon-reload sudo systemctl restart ollama这里把模型存储目录也改到独立数据盘避免系统盘被模型文件塞满。改完后用命令行验证ollama list curl http://127.0.0.1:11434/api/generate -d {model: qwen2.5:7b, prompt: 你好}第四步在服务器防火墙里放行11434端口但要注意限制来源IP为办公网段不要放开成谁都能访问的地址。我一般会建议安全团队只放开内部资产网段的访问明确写清“这个端口不对公网开放”。如果后续要对接外部移动办公场景也要走堡垒机和统一入口不应该绕过防火墙规则直接转发。跑通之后团队里的前端、后端、运维人员都能把模型当成内网里的一个HTTP服务来用。拿一段Python代码调用也很简单import requests resp requests.post( http://10.10.10.20:11434/api/generate, json{model: qwen2.5:7b, prompt: 把这段话改成正式通知, stream: False} ) print(resp.json()[response])这时候再回头看“AI开发门槛”会发现门槛已经下降了好几级不需要懂模型推理细节不需要管GPU显存调度只需要会发HTTP请求就可以把大模型能力接进业务系统。注意把模型服务监听到0.0.0.0后务必在防火墙限制来源网段。这是一个经常被忽略但非常关键的安全动作。2.3 高并发场景再考虑vLLMOllama适合快速验证和中小规模使用但并发一高会暴露一些性能短板。如果企业要做内部AI平台几十上百人同时用我会推荐用vLLM这类推理框架。它支持Continuous Batching可以把不同请求动态拼到同一批计算里GPU利用率比逐请求推理高不少还自带OpenAI兼容接口。vLLM的部署一般先下载模型到本地目录然后启动服务。我自己常用的启动命令长这样python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-14B-Instruct \ --served-model-name qwen14b \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --host 0.0.0.0 \ --port 8000 \ --api-key internal-ai-key-here几个参数拆开讲tensor-parallel-size如果一张卡放不下模型可以改成2让模型并行跑在多张卡上。如果只有一张卡保持1。gpu-memory-utilization限制显存使用比例别把显存全占满否则连SSH和监控都受影响。max-model-len控制模型最大上下文长度内部场景设到8K够用太大会明显增加显存占用和首字延迟。如果只是给几十个人用Ollama已经足够。但如果你要做平台化统一上vLLM更合适。实际对比下来两者可以共存Ollama承担快速实验模型切换vLLM承担正式接入的在线服务。模型文件用同样的格式不会浪费太多存储但换来的是开发灵活性。2.4 部署完后先做个“接口验收”模型服务起来后很多人高兴得太早直接用网页测试一下就认为完成了。我习惯多花十分钟做一轮接口验收确认三件事服务可以被其他机器访问响应格式稳定鉴权生效。用curl就能做curl http://10.10.10.20:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer internal-ai-key-here \ -d {model: qwen14b, messages: [{role: user, content: 你好}], max_tokens: 100}如果这里能正常返回说明模型这层已经可以作为内部基础设施了。这时候团队里任何一个开发都能用类似代码做调用门槛已经低到不能再低。3. 把“模型能力”包装成内部团队都听得懂的API3.1 统一模型网关让业务代码只认一个地址模型部署完成之后一个很容易失控的地方是团队里每个人各自连不同端口、不同框架、不同鉴权方式。今天有人连Ollama的11434明天有项目用vLLM的8000后天有人又在自己电脑上起了个Python服务。这样开发体验很混乱权限和安全边界也难统一。我建议在模型服务外面再包一层统一的模型网关或者至少做一个内部域名。业务开发只配一个Base URL和一组内部Key不用关心背后是Ollama还是vLLM。接口统一走OpenAI兼容格式因为这是目前生态最通用的协议Dify这类编排工具、LangChain这类开发框架都能直接对接。内部接口地址可以定义为http://ai.internal.example.com/v1这个地址不直接对应某台服务器而是由内部DNS解析到网关。网关负责把请求转给合适的模型服务同时记录调用日志。这样一来信息部门能知道谁在调模型、每个应用消耗多少Token、有没有异常请求而不是一团黑盒。这一步不要省。哪怕一开始只有一两个应用提前把域名和Key机制定下来后面的项目都能直接沿用避免每个人一套私货接口。3.2 用编排工具把知识库接上大模型模型服务只是发动机企业内部真正用得多的场景其实是“让AI根据企业自己的知识库回答问题”。最典型的做法是RAG也就是检索增强生成。简单理解就是先把企业文档切片、向量化后存进向量库用户提问时先在知识库里检索出相关片段再把这些片段连同问题一起交给大模型生成回答。这样模型不需要记住全部资料但每次回答都有依据来源幻觉会小很多而且知识更新只要重灌对应文档就行不用重新训练模型。市面上能做这事的低代码编排工具不少我实际对比过的有Dify、FastGPT等。这些工具大多支持对接内部模型服务做到文档上传、切片、向量化、检索、生成一套流程。拿我比较常用的Dify举例用docker compose启动一套然后配置模型供应商。模型供应商的类型中选择Ollama或OpenAI-API-compatible填上内网模型服务地址即可。随后创建知识库上传企业制度文档系统会自动做切片和向量化。创建应用时选择“聊天助手”类型关联这个知识库一个企业知识问答机器人就出来了。知识库配置里几个参数很关键分块大小我试下来中文场景300到500字比较合适。太小则上下文碎片化太大则检索命中精度下降。块重叠一般设置50左右避免把关键句刚好切散。检索Top-K通常取3到5返回太多了模型容易抓不住重点。相似度阈值建议设0.35到0.45之间太低会返回一堆无关内容。真正在做的时候最大的工作量不是配置参数而是清洗文档。Word里各种层级标题、表格嵌套、页眉页脚如果不先做一轮格式规范检索效果会差得让人头疼。我一般会要求业务方先交出规范化的PDF或Markdown再从源头清理排版而不是让工具自动处理所有格式问题。另外要提醒一点知识库的向量化要用本地部署的Embedding模型。如果向量化还在调用公网服务那知识库里的文档内容等于还是出去了数据边界就形同虚设。本地Embedding模型建议选BGE这类开源中文模型几GB的模型文件就能跑得很好甚至不需要很高级的显卡。3.3 普通开发者的AI应用学习路线怎么走把RAG跑通之后我猜有不少人会问我“接下来该怎么学”。我给团队的建议是一条非常接地气的路线先会调接口再做知识库最后学Agent。别上来就啃论文。第一步会调模型接口。把内部模型的Chat Completion接口当成一个高级函数输入一段文本输出一段文本。你能写一个Python脚本调通就算入门。第二步做RAG。把公司文档导入本地知识库搭一个能回答业务问题的机器人。这个阶段能接触到Embedding、向量检索、Prompt模板这些概念但它们都是工具不需要从原理推导一遍。第三步学Agent。让模型调用业务接口或工具去完成具体任务。比如模型回答“我可以帮你查审批进度”背后是调用了一个查询接口。这一步才开始涉及规划、工具调用、记忆管理。这个路线走下来一个原本做传统管理系统开发的工程师两到三个月就能做出能用的业务场景。而整个过程都发生在内网环境中数据和模型不离开公司的网络边界训练出的Prompt效果、流程编排经验也都是企业自己的资产。4. Agent开发让AI从“聊天”变成“办事”4.1 Agent不是“全自动跑起来”就好很多企业把“AI应用开发”理解成聊天机器人做到RAG以后就觉得产品到头了。实际上真正体验到价值的是让AI连着内部系统去干活也就是现在的Agent智能体。例如员工问“这个月请假还剩几天帮我提交一下年假流程”Agent不仅要识别意图还要从HR系统查询剩余天数再发起OA流程。Agent的难点不在大模型本身而在权限和流程控制。AI如果要调用内部数据中心就必须暴露接口而每一个接口都意味着能力边界。这里有一个安全上的反直觉点越“聪明”的Agent越容易在用户暗示下做出计划外动作。如果不在架构上做约束一个简单Prompt注入就可能让Agent调用它本不该能调用的接口。所以我在Agent架构里一定会加一层“工具注册表”。每次新增工具接口前必须登记工具描述、所需权限和默认允许的调用条件。Agent在执行任务时不能自己去访问任意数据库而是由编排层根据用户身份和策略做鉴权再决定“这个工具能不能给这个用户调用”。4.2 落地时用“权限白名单 审批”给Agent画圈Agent的规划能力越强越需要外部规则兜底。我通常会在Agent系统里内置两种开关权限白名单和高危动作审批。权限白名单解决的是“能做什么”的问题。比如某个内部Agent只能读取市场部的公开资料库不能写财务系统只能创建工单不能删除工单。这个是静态配置独立于模型逻辑之外。Agent脑子里想到什么并不重要重要的是执行层只认白名单。高危动作审批解决的是“关键步骤不能自动完成”的问题。例如Agent可以向客户发催款邮件草稿但真正点击发送前要回传一个待确认卡片由对应业务人员点击确认后才执行。这个“人工确认点”设计得好不好往往决定系统敢不敢真正商用。我在其中一个售后场景里做过类似设计。团队把维修手册、备件清单和客户历史工单做成了知识库又接入了查询备件库存和创建维修单两个工具。Agent收到用户的故障描述后会做三件事检索维修手册定位可能故障点查备件库存判断有没有货生成初步处理建议工单。整个过程中只有“创建工单”被允许自动执行涉及金额的加急审批一律弹确认。上线之后实际效果并不只是响应变快更重要的是经验沉淀。老维修工的判断路径被模型以“检索生成”的方式复现出来了新员工第一次遇到问题也能按图索骥。这件事的开发周期并不长三人团队花了三周左右没有写复杂的训练代码主要时间花在梳理维修手册和接口设计上。4.3 多个Agent并行开发时怎么互相不“打架”等单Agent跑顺了很多企业会走向多Agent并行。市场部要一个文案助手客服部要一个知识问答助手生产部要一个异常分析助手这些Agent如果都各自连模型、各自建知识库很快会把底层模型资源打满而且知识口径会变得五花八门。多AI并行开发的关键是底层共享、应用层隔离。底层的模型服务与Embedding服务由信息部门统一构建所有Agent共享同一套基础能力上层每个Agent有自己的向量空间、Prompt模板、工具白名单互不干扰。Model层面同一个Qwen模型就可以支撑多个Agent知识库向量空间可以按业务分区工具权限按业务线隔离。开发流程上也建议这样管理每个Agent先跑在一个独立的开发环境里用仿真的工具Mock数据测试测试通过以后再申请接入正式业务系统的测试接口。这样一个Agent出问题不会影响其他Agent的正常使用。从内部支持角度说这一步才是“平台化”真正开始的地方。4.4 案例复盘三个人做出一套生产可用Agent交代一下具体背景。我之前陪一个中等规模制造型企业做售后助手团队配置很精简一个懂Java后端、一个懂运维、一个懂业务的售后主管三个人都算不上AI算法专业人士。服务器是采购的双卡工作站系统是Ubuntu总共花费十几万。他们没有从零训练任何模型全程是“开源模型编排平台业务接口”的组合。第一周他们部署好了模型和知识库把近三年的设备维修记录做了清洗导入做出问答原型。第二周开始对接内部系统的备件库存查询接口并给Agent加了白名单机制。第三周给业务部门演示当时线上参会两三百人一开始大家担心AI乱说、不安全等看到Agent列出的回答都带有原始维修工单编号可以点进去核对时质疑声音小了很多。后来他们继续迭代逐步接入了质检报告、设备参数、售后政策慢慢变成了部门离不开的日常工具。这个案例说明内网AI开发门槛真的已经降到“不养算法团队也能做”的程度。但前提有三条模型服务化、接口标准化、权限边界清晰。这三条做好了Agent的数量和质量都能持续叠加。5. 内网AI平台的运维与排坑比开发更考验耐心5.1 服务器和容器平台能上Linux就不要硬Windows前面提到有人问Windows Server 2016上装Docker的问题。说实话这个组合能跑但体验不是一般的折腾。Docker Desktop在Windows上依靠Hyper-V或WSL2老版本的Server 2016对WSL2支持有限很多Linux镜像会启动失败尤其是GPU相关的容器在Windows下的设备映射折磨过不少人。我的建议是如果只有Windows Server优先在Hyper-V里开一台Linux虚拟机把Docker和模型部署都放在虚拟机内完成。即便性能有一点损耗也比直接跟Windows容器死磕省时间。对医院、国企这类环境尤其适用因为他们服务器往往预装Windows Server但底层跑Linux容器仍然是主流。另外一个运维教训是固定好服务器操作系统的内核版本、驱动版本、CUDA版本并写成一份内部文档。AI平台不像传统应用那样升级频率低驱动和框架一换模型可能就起不来了如果没有记录出问题时会非常被动。5.2 内网没法直接拉镜像和模型怎么离线部署内网服务器不能访问外部镜像仓库是常态。最常见的做法是离线导入流程并不复杂第一步在一台允许联网的中转机上拉取所需Docker镜像然后保存为文件。docker pull langgenius/dify-api:latest docker save langgenius/dify-api:latest -o dify-api.tar第二步把tar文件通过内网文件服务器、U盘或拷贝工具传到内网服务器。第三步在内网服务器上导入镜像。docker load -i dify-api.tar模型文件和Embedding模型也一样先把模型目录完整下载再把它拷贝到内网服务器的模型目录里。用Ollama时模型应放在OLLAMA_MODELS指向的目录下也可以用ollama create从一个本地Modelfile创建。拷完之后记得用curl验证一下服务能正常加载模型。如果企业已经有了内部镜像仓库或私有仓库更规范的做法是把镜像推到那边统一管理。后期服务器扩容只要从仓库拉取就可以省去一次次拷U盘的辛劳。5.3 服务起得来但局域网访问不了先查这四件事这类问题几乎每个刚部署的人都会遇到一次大部分原因就那么几个。模型服务绑定的IP不对。可能仍在127.0.0.1只允许本机访问改成0.0.0.0或具体业务网卡IP即可。防火墙没有放行对应端口。Linux的firewalld或ufw默认会拦截外部访问需要按内网网段放行。服务器有多个网卡服务绑定到了另一个管理网口业务网内的机器到达不了。部署时可以临时查看IP并确认出口网卡。客户端访问用了localhost配置。本地测试没问题同事电脑当然不行要把Base URL改成服务器内网IP或内部域名。我见过最长的一次排查持续了两天最后发现是服务器上跑了个防火墙脚本每隔一段时间就重置规则把之前放行的端口全关了。这类问题往往不在标准排查路径里需要结合业务环境和运维脚本一起看。所以每次碰到连通性问题第一件事是检查规则是否真的生效而不是反复重启服务。5.4 性能不够的时候先判断瓶颈再调优内部AI应用最常见的抱怨是“回答太慢”和“并发一高就卡死”。很多人的第一反应是加显卡但加显卡之前值得先做一轮判断。看GPU利用率时如果GPU利用率很低但显存已经占满可能模型太大或上下文太长此时适合降低并发数或增加多卡分摊。如果GPU利用率高但每个请求还是慢可能是单张卡的算力确实用满了或者模型参数对硬件来说偏高。如果模型很快但前端转圈实际问题可能出在业务系统接口或数据库查询上和AI推理无关。在线服务的调优方向上我最常做的是控制max-model-len和并发配置。默认支持长上下文的模型如果不限长度一个长文档请求就可能把整张卡的显存都占住后续所有用户排队。要把max-model-len按业务实际需要收紧到8K或4K内部任务很少真的需要一次性处理几十万字。另外Prompt变长会显著增加计算量。有的业务方图省事把几千字的知识库内容全塞进Prompt这会拖慢速度并增加成本。应该改成检索后只把最相关的片段拼进去。一个典型的RAG回答请求输入Token应该在几百到一千左右而不是整篇文章。5.5 安全底线不能上线后再补内网AI平台的安全不单是防火墙规则。最需要关注的是模型服务层的“越权”模型。模型本身没有安全意识它只会按上下文做补全真正负责安全的是外围控制层。所以内部AI平台至少要配套这几件事统一账号登录别拿匿名请求直接开放给全员审计日志记录谁在什么时间问了什么、调用了哪些工具业务系统接Agent的数据库账号全给最小权限别用DBA账号文件导出的动作要能被追溯。最后说一个经验先做内部红蓝评估很有必要。即便你的系统只在内网流传也要找安全团队按“内部服务暴露面”的角度检查一遍看看模型运维端口有没有意外开放到某个开发VLAN检查Agent工具调用日志有没有被异常绕过。等数据和Agent规模扩大以后再补安全代价只会更高。我把这些过程反复跑了几次之后最大的感受是企业内网AI开发并不是技术比拼而是“分级、服务化、边界控制”这三件事的组合功夫。只要模型数据在自己的地盘里、接口足够标准、权限边界足够清晰哪怕一个很小的技术团队也能把AI开发门槛压到让业务人员敢用、能用、愿意用。