先别急着找算法工程师。前阵子有个传统行业的负责人问我，公司想把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] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_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 高并发场景再考虑vLLM
Ollama适合快速验证和中小规模使用，但并发一高会暴露一些性能短板。如果企业要做内部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. 把“模型能力”包装成内部团队都听得懂的API
3.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开发门槛压到让业务人员敢用、能用、愿意用。
