1. 项目缘起为什么要在隔离内网里跑 Agent先交代一下背景。我所在的团队负责集团内部的一套业务中台前阵子接到一个需求把 AI Agent 落地到生产环境让业务人员通过自然语言就能查询订单数据、生成经营报表、自动跟进异常工单。听起来是当下很常见的“AI Agent 搭建”需求但有个硬性条件——整套系统要部署在隔离内网里和公网彻底断开。这一下就把很多现成的方案挡在门外了。平时大家聊 AI Agent 开发默认都是调云端大模型 API配上 LangChain 或者 LangGraph 这类框架再挂几个外部工具就能跑起来。但在隔离内网环境下事情完全变了大模型要自己部署知识库要自己搭向量化要本地跑外部依赖一个都不能用。等于说别人是在装修好的毛坯房里添置家具我们得从打地基开始把整栋楼盖起来。这篇文章想记录的就是这次“隔离内网下 AI Agent 工程实战”的完整过程。我会把架构设计、模型选型、Agent 编排、RAG 知识库、工程化部署这几个核心环节逐个拆开讲重点说清楚每一步为什么这么做、踩了哪些坑、最后怎么解决的。如果你也遇到类似场景——企业内网、数据不出域、不能直连外部大模型服务——那这篇文章应该能帮你少走不少弯路。先说一下这套系统最终长什么样。用户在内网的 Web 界面上输入问题系统先做意图识别和任务规划然后调度不同的工具去查询内部系统数据再结合本地知识库的内容生成回答。整个过程全部跑在内网模型推理、向量检索、Agent 决策、工具调用都在自己的服务器上完成。核心链路是“自然语言 → 任务规划 → 工具调用 → 知识检索 → 结果生成”也就是目前 AI Agent 的主流架构范式模型负责思考和决策工具负责执行知识库负责补充上下文。下面我从头梳理这次实践的完整技术路径。2. 总体架构与核心设计思路2.1 四层架构从模型到应用的清晰分层当时我们遇到的第一个问题就是架构怎么搭。网上关于 AI Agent 主流架构的资料很多但绝大多数是围绕云端 API 展开的。我们根据隔离内网的特点把整个系统拆成了四层。第一层是模型层负责推理能力。这一层必须私有化部署因为不能调用外部接口。我们选择了开源模型具体选型和量化策略后面专门说。第二层是 Agent 编排层负责理解用户意图、拆解任务、决定调用哪些工具、怎么组合结果。这是整个 Agent 的核心大脑。第三层是工具层负责对接内部系统。比如订单查询、工单处理、报表生成这些动作都是通过封装内部 API 或者直接操作数据库来实现的。第四层是应用层就是用户真正看到的东西——一个 Web 交互界面以及面向管理员的配置后台。这个分层思路看起来简单但实际设计时有一个关键决策让 Agent 编排层和工具层彻底解耦。为什么因为在隔离内网部署 Agent最大的变数就是工具。内部系统的接口可能随时调整今天调这个 API明天可能就换了参数。如果 Agent 逻辑里硬编码了工具细节那工具一改整个 Agent 就得跟着改。所以我们在一开始就约定Agent 只面向“工具描述”编程不面向“工具实现”编程。工具层向上暴露标准化的接口描述Agent 根据描述决定调用方式。后面工具改了只需要更新描述信息Agent 不用动。2.2 框架选型的取舍LangGraph 与自研轻量编排框架选型上我们纠结了很久。LangChain 生态最成熟文档多、社区广但缺点是抽象层级太多出问题的时候排查链路很长。尤其是在内网环境没有办法去查在线文档和社区 issue一切都得靠自己读源码、打日志。LangGraph 相对更灵活对流程控制的能力更强但也更底层需要自己写不少胶水代码。最终我们选了 LangGraph 作为基础框架但没有完全照搬默认的 Agent 实现而是自己写了编排逻辑。主要考虑有三点一是 LangGraph 的图结构非常适合表达“规划-执行-反思”的循环流程这在 Agent 的迭代式任务处理中非常有用二是它在状态管理和持久化方面做得不错方便我们后续做会话记忆和任务恢复三是它的依赖相对干净离线安装的难度可控。不过这里要提一个实际经验别迷信框架。LangGraph 只是给了你一个骨架具体的提示词模板、工具调用策略、上下文管理策略都必须根据你自己的业务场景去调。在隔离内网环境下调试成本高所以建议先在单机环境把整套流程跑通再往集群里迁移。我们就是先在一台 GPU 服务器上把原型跑起来验证了整个链路没问题才开始考虑横向扩展的事。2.3 适配层设计解决内网环境的后顾之忧隔离内网环境有一个容易被忽视的问题依赖管理。平时开发的时候pip install 一条命令就能装好所有包。但内网环境没有公网源所以必须提前准备离线依赖包。我们的做法是搭了一个内网 PyPI 镜像源把项目需要的所有依赖包全部提前下载好上传到内网的 Nexus 仓库服务器上。这项工作看起来不起眼但如果不提前做好项目开发中期突然要装一个新库那真是寸步难行。另外模型服务也需要适配层。我们的方案是在模型层前面加了一个统一接入网关对外暴露一套兼容接口。这样做的好处是以后如果想换更强的新模型只需要在网关层做适配业务层完全不受影响。网关层还顺带解决了几个问题请求日志的统一记录、用户级的接口限流、模型调用的成本统计。这些在公网环境可能有很多现成 SaaS 工具但在内网环境下都得自己造轮子。3. 内网模型服务搭建从选型到推理优化3.1 开源模型选型与量化策略模型私有化部署是隔离内网环境下 AI Agent 实战的第一步也是最重要的一步。模型决定了下限后面所有的 Agent 能力和 RAG 效果都建立在这个基础上。我们当时对比了几款主流开源模型。最初考虑的是参数量在 70 亿到 140 亿之间的模型原因很现实内网 GPU 资源有限而且要在保证效果的前提下尽量降低推理延迟。经过评测我们最终选择了 Qwen 系列作为主力模型。主要原因有三点中英文能力均衡、工具调用指令遵循能力不错、社区生态完善离线部署资料也比较全。参数量选择上我们做了个折中方案主模型用 72B 的量化版本跑复杂推理和工具调用同时部署一个小参数模型专门处理简单任务。为什么要这样设计因为在实际运营中你会发现大部分用户问题其实没那么复杂比如“查询订单 12345 的状态”这种问题用大模型跑完全是浪费算力。小模型响应快、成本低足够handle这类简单意图。而遇到复杂的数据分析、报表解读、多步骤规划任务再交给大模型处理。量化策略是一个值得细说的点。我们测试了 FP16、INT8、INT4 三种精度。FP16 效果最好但对显存要求太高INT8 在效果和资源占用之间最均衡INT4 省显存最明显但复杂推理场景下会出现明显的效果下降。最终我们选择 INT8 作为部署方案配合 KV Cache 量化在保证效果的同时把显存占用压缩到了可接受范围。实际测试下来在单卡 80G 的 A800 上128K 上下文窗口下基本没有压力。3.2 推理服务部署vLLM 与动态批处理调优模型推理框架选的是 vLLM。原因很直接它在高并发场景下的吞吐表现明显优于其他框架。vLLM 的连续批处理机制可以动态调度请求把不同请求的推理过程拼接在一起执行大大提升了 GPU 利用率。部署的时候有几个关键参数值得记录一下。max-model-len 决定模型支持的最大上下文长度我们设为 128K因为 Agent 任务经常需要塞入大量的工具返回结果和知识片段。gpu-memory-utilization 设为 0.9给推理过程预留足够的显存余量。此外我们开启了 automatic-dynamic-prefill-caching把重复的上下文前缀缓存起来避免重复计算。这个特性在 Agent 场景下特别有用因为同一会话的多次调用往往共享相同的前缀内容。推理服务的接口层我们没有直接用 vLLM 自带的 OpenAI 兼容接口而是做了一层薄封装。封装的主要目的是加上了更细粒度的权限控制和审计日志。在隔离内网环境里安全问题同样存在只是威胁模型不同。审计日志可以记录每一次模型调用涉及的用户、请求内容和消费的 token 数量为后续的成本核算和安全追溯提供依据。这里补充一个与很多公网场景不同的小细节内网环境下不用考虑网络延迟和拥塞问题但需要考虑另一件事——并发模型实例的管理。如果只有一个模型实例挂在前端网关后面那当推理服务的负载过高时所有 Agent 任务都会变慢。我们的做法是部署了多个推理副本通过网关做简单的轮询负载均衡。实际运营中发现当并发请求超过一定阈值时轮询策略会出现某些副本忙死、某些空闲的情况。后来改成基于活跃请求数的动态调度策略效果好了很多。3.3 在线部署中的显存与性能调参实操显存优化是模型私有化部署绕不开的课题。我们 72B 模型用 INT8 量化后模型权重本身大约需要 75G 显存剩余空间留给 KV Cache。128K 长上下文场景下KV Cache 的占用不可小觑。我们实际压测发现如果完全不做限制单个长会话请求的 KV Cache 可以轻松吃掉 20G 以上显存。应对方法有几个。第一开启 vLLM 的 PagedAttention 特性这是它默认开启的能够把 KV Cache 分成小块按需分配显存利用率显著提升。第二应用层配合做好上下文压缩控制每次请求的有效长度。第三针对不能超过 128K 的死限制在网关层做了长度预检超出即拒绝防止 OOM 导致整个推理服务崩溃。生产环境里一次 OOM 的影响面很大因为所有用户的请求都会打到同一个服务池上。我们在上线初期就吃过这个亏后来把长度预检和请求排队机制都补上了整体稳定性才上来。性能调优方面除了模型推理本身还涉及到 Agent 框架和数据链路的配合。模型推理只占端到端延迟的一部分工具调用耗时、知识检索耗时、结果生成耗时各占一部分。我们做端到端性能分析时发现如果知识库里检索不到相关内容Agent 会浪费时间在无效的检索循环里。后来我们在检索环节加了相关性阈值判断低于阈值直接跳过检索步骤端到端延迟下降了约 30%。这类优化只有放在整体架构视角下才能发现单独看模型推理层是找不出来的。4. Agent 核心链路规划、工具调用与记忆管理4.1 任务规划从意图识别到子任务分解Agent 编排层的核心任务是把用户的自然语言输入转化为可执行的内部操作序列。我们在 LangGraph 里定义了一个状态机主要状态包括意图识别、任务规划、工具选择、工具执行、结果综合、反思修正这几个环节。意图识别是整个链路的第一步。用户输入先经过一个轻量分类器判断请求属于“知识问答”、“数据分析”、“操作执行”还是“闲聊”类别。这个分类器我们直接用一个小模型来做基于指令模板让模型输出结构化结果。分类准确率测试下来在 95% 以上。为什么要单独做意图识别因为在隔离内网环境里很多用户问题涉及到内部系统的敏感性如果一上来就让 Agent 直接调工具容易产生误操作。意图识别相当于一个前置闸门可以过滤掉大量不合理请求。任务规划是更复杂的环节。比如用户说“统计上个月各区域销售额的环比变化并找出异常区域”这个任务需要拆解成查询订单数据 → 按区域分组 → 计算环比 → 识别异常 → 生成报告。Agent 需要将这个大任务分解成一系列子任务并确定子任务之间的依赖关系。我们在 LangGraph 中实现了一套基本的规划器主要逻辑是给模型一个当前可用工具列表和各自能力描述让它分析用户问题决定需要调用哪些工具、按什么顺序调用。这里有一个很关键的工程细节工具描述的质量直接影响任务规划的成功率。明文描述必须具体、明确比如“按日期范围查询销售订单汇总数据返回按区域维度聚合的结果”而不是笼统说“查询订单数据”。我们花了很多精力打磨每个工具的描述文本效果立竿见影——任务规划准确率从一开始的 70% 提升到了 90% 以上。4.2 工具调用机制与内网服务接入规范工具层是 Agent 真正落地能力的载体。我们内部系统有订单服务、库存服务、工单服务、报表服务等多个模块。每个模块都有自己独立的接口协议有些是 HTTP 接口有些是内部 RPC。为了让 Agent 能够统一调度这些服务我们为每个模块编写了标准化的工具适配器。工具适配器的核心是两层设计。第一层是描述层包含工具的名称、用途、参数说明、返回值格式示例这些信息以 JSON Schema 的形式提供给模型。第二层是执行层负责把模型的工具调用请求翻译成内部系统的实际接口调用。JSON Schema 是工具调用机制中最重要的部分。模型根据工具描述生成执行参数然后由执行层验证并转发请求。一开始踩过不少坑比如模型生成的参数格式不符合内部接口要求、参数缺漏、或者参数类型错误。后来我们引入了两个方案一是利用模型支持的工具调用约束强制模型按照规定的 JSON Schema 输出结构化参数二是在执行层加入严格的参数校验逻辑对不符合规范的调用请求直接返回错误信息让模型根据错误信息重新生成。内网服务接入规范这块我们还做了权限设计。不同用户对工具的调用权限不同比如普通运营人员只能查询订单数据不能执行批量修改操作。Agent 在执行工具调用之前先通过用户身份信息做权限校验。这就引出一个值得注意的问题工具参数中关于用户身份的信息应该由应用层注入而不是让模型直接生成。否则用户可以通过自然语言让 Agent 冒用他人身份这是一个安全漏洞。4.3 记忆管理方案短窗口与长期向量记忆结合Agent 的记忆管理在公网场景下往往容易忽略但在内网实际运营中记忆能力直接决定了用户体验。我们采用的是“短期上下文 长期向量记忆”两级方案。短期上下文本质上就是会话历史。每次对话时把当前会话的最近若干轮内容拼接到提示词中让模型理解对话的来龙去脉。这块有个工程细节上下文窗口有限而有些会话历史很长不能无限制地塞进去。我们的方案是做轮次裁剪保留最近 10 轮对话的完整内容超过 10 轮的旧内容进行摘要化处理。摘要由模型生成用简洁的几句话概括早期对话的关键信息这样既保留了对话上下文又不至于把长度撑爆。长期向量记忆解决的是跨会话的知识保留问题。比如用户之前问过“华东区的 KPI 口径是什么”过了一周又问“上次提到的那个指标”Agent 需要能从历史会话中检索到相关上下文。我们的做法是每轮对话结束后将用户问题和 Agent 回答提取关键信息向量化后存入向量数据库。新会话开始时先用用户当前输入去检索相关历史记录把检索到的高相关片段拼接到提示词中。这个机制上线后很多用户都反馈 Agent 感觉“有记忆了”体验提升明显。记忆管理还有一个细节值得说明敏感信息过滤。隔离内网环境下的业务数据往往涉及保密要求Agent 的记忆模块不该把所有历史对话内容都存在向量库里。我们的方案是存储前做一轮敏感数据检测对包含用户手机号、身份证号、内部编号等敏感信息的内容进行脱敏处理。这个策略在合规层面很重要也减少了下游误用风险。5. RAG 与内网知识库让 Agent 真正懂业务5.1 知识库建设的完整流水线在隔离内网里跑 Agent最大的优势恰恰是可以访问内部的知识文档。但也正因为内网数据多、杂、格式不统一RAG 系统的搭建复杂度远超预期。我们的知识库建设分成三个环节文档解析、文本切分、向量化入库。文档解析这一步处理的文件类型包括 Markdown、Word、PDF、Excel 等。隔离内网环境有一些特有的文档格式比如历史遗留的 WPS 文档、老旧的报表文件。为了统一处理我们开发了一个解析服务先把各种格式转换为中间格式再从中间格式提取纯文本和结构化表格。这步的坑在于表格转成纯文本后语义信息会丢失。后来我们的方案是对于表格内容保留其原始结构化形式单独以 JSON 格式存储检索的时候遇到表格类型知识则走专用解析逻辑。文本切分策略直接决定了检索质量。我们测试了固定长度切分、段落切分、语义切分几种方式。固定长度切分最简单但容易切断语义完整的段落。段落切分效果好一些但遇到很长的段落时单条记录超长导致向量化效果不佳。最终我们采用了一种混合策略正文按语义段落切分段落过长时再按固定长度二次切分同时保留段落间的关系信息。每块文本还额外拼接了来源文档的标题和上下文摘要相当于给每块知识增加了元数据。这个细节很重要因为检索时可以通过元数据做过滤大幅提升检索的精准度。5.2 向量检索与混合检索策略向量数据库选型是我们花了不少精力的一项工作。对比了 Milvus、Elasticsearch、Chroma 等方案后最终选了 Milvus。理由是Milvus 支持分布式部署性能表现稳定社区活跃度也不错。在隔离内网环境里我们无法依赖云端服务Milvus 的私有化部署能力很关键。检索策略方面单纯依赖向量检索效果并不理想。原因是内网文档中存在大量专业术语、内部简称和特定编号这类内容的向量化效果天然较弱。用户搜索“销售一部”可能文档里写的是“销售一中心”向量相似度不够。所以我们在向量检索之外还引入了一个轻量级关键词检索通道两个通道的检索结果通过 RRF倒数排名融合算法做合并重排最终得到综合相关性排名。这个混合检索策略上线后检索召回率提升了约 20 个百分点效果非常明显。重排环节也很重要。初检结果可能有一堆候选内容真正有用的只有其中一小部分。我们使用一个专门的小模型做重排对候选内容进行精细的相关性打分只保留 Top-5 进上下文。这里有一个心得重排模型在隔离内网环境下的部署也要离线准备并且要对内部数据做针对性微调。通用重排模型在业务数据上的表现有限微调后提升非常明显。5.3 知识库更新与数据同步机制内网知识库的一个显著特点是内容更新频繁。业务规则、操作手册、产品说明这些文档几乎是按周在变。如果知识库不能及时同步Agent 给出的回答就可能是过期的信息这种错误在业务场景里的影响很大。我们做了一套定时增量更新机制。每天凌晨任务调度器扫描知识库源目录的文件变更情况对新增、修改、删除的文件分别做处理。修改的文件会重新解析、重新切分、重新向量化并用新的向量替换旧的向量删除的文件会把对应的向量记录同步删除。增量更新机制上线后知识库的时效性问题基本解决了。但增量更新也有一个副作用上下文漂移。如果一篇文档在对话过程中被更新了之前基于旧版本生成的回答可能就不准确了。我们的应对方案是在回答里标注“基于 XX 版本的知识库生成”并且在知识库管理的后台里记录版本变更历史。用户看到回答后可以知道这是基于哪个版本的内容如果怀疑过期可以手动触发强制刷新。这个设计虽然简单但在实际运营中很实用。6. 工程化部署与常见问题排查6.1 容器化部署与内网环境的离线安装策略整个系统最终要交付给运维团队统一部署所以容器化是必经之路。我们把所有组件——模型推理服务、Agent 编排服务、知识库服务、工具适配服务、前端应用——全部打包为 Docker 镜像。镜像仓库用的是内网 Harbor所有镜像在构建阶段就推送到内网仓库。隔离内网环境下的容器部署有几个特殊问题要提前准备。第一是基础镜像获取。系统依赖的 Python 基础镜像、CUDA 运行时镜像默认都来自公网仓库必须提前拉取并重新打标签推到内网仓库。第二是 pip 依赖包离线安装。我们在构建镜像时使用离线 wheel 包安装依赖不走公网源。第三是模型权重文件的打包。模型权重文件非常大甚至超过单个镜像的合理大小我们的方案是作为独立的卷挂载到容器中避免镜像体积过大导致分发困难。容器化给后续运维带来了很大便利。模型的升级、Agent 逻辑的更新都只需要更换对应的镜像重启服务即可。而且在多副本部署场景下容器编排工具还能帮我们实现滚动更新避免服务中断。不过这里要提醒一下内网环境的磁盘资源和网络带宽都是有限的镜像版本号管理如果不规范很容易积累大量历史镜像把仓库撑爆。我们后来加了镜像清理策略只保留最近 10 个版本。6.2 日志监控与链路追踪体系Agent 系统的日志监控比普通 Web 系统复杂得多。一个完整的请求链路可能是用户输入 → 模型推理 → 工具调用 → 再次模型推理 → 知识检索 → 生成回答。任何一个环节出现问题整个链路就会失败。而且失败可能是静默的Agent 表面上回答了但回答内容完全不是用户想要的。为了快速定位问题我们搭建了一套全链路日志追踪体系。每次请求从入口开始生成一个唯一的 trace_id贯穿整个 Agent 执行链路的所有环节。每个环节的输入输入、耗时、状态码都会记录到日志中心。排查问题时只需要拿着 trace_id 去检索就可以看到整个请求在每一个环节的详细轨迹。这套体系上线后排查效率提升非常明显。举个例子某次用户反馈 Agent 回答“无法查询订单数据”但订单系统数据显示一切正常。通过 trace_id 追踪后发现是工具适配器在解析模型生成的参数时出了问题——模型生成了一个不在参数定义范围内的枚举值执行层校验失败又没有正确的错误回传机制只能告诉用户“无法查询”。找到根因后我们在工具适配层加了参数值域规约机制模型生成的参数超出范围时自动映射到最近的有效值这个问题就解决了。另一个容易忽略的监控点模型推理服务的令牌消耗统计。在内网环境中虽然没有直接的成本压力但令牌消耗数据可以反映系统负载情况和用户行为特征。我们按月对令牌消耗做汇总分析发现某些时段的消耗明显偏高进一步优化了推理服务的资源调度策略。6.3 高频问题排查实录与解决策略问题一Agent 执行链路过长的超时控制Agent 执行多步骤任务时如果某一步陷入循环或者工具响应超时整个请求就会卡住。我们的方案是引入全局超时机制和重试策略。单步工具调用超时设为 30 秒超过直接返回错误信息全局规划超时设为 3 分钟超时则中断当前任务返回已完成的中间结果。此外对超时工具调用尝试一次重试重试仍失败则跳过该步骤不阻塞后续任务。这个设计起初担心会影响任务完成率实际上线后我们发现效果不错。因为工具超时往往是个别服务临时抖动跳过一步不会影响整个任务的交付。遇到真正的持久性故障全局日志会很快暴露出来。问题二模型产生幻觉回答与业务事实不符这是 Agent 系统内网落地时最容易遭受质疑的点。模型的生成结果表面看起来头头是道但引用了一个不存在的报表编号或者把上月的销售额算错了。解决这块问题我们做了两个动作。第一是在提示词层面强化约束明确要求模型在涉及具体数字和编号的内容时只能引用检索到的事实不能自行推断。第二是在应用层引入事实核验机制当 Agent 回答中包含具体业务指标时用正则规则提取关键数字和编号去内部系统再次查询比对。比对不一致时回答会被打上一个“需人工复核”的标识。这个机制虽然还不能做到完全自动化但人工复核的工作量降到了可接受范围。问题三并行请求下的上下文混乱一个容易忽略的工程隐患Agent 是有状态的用户在 Web 界面上连续发起多个请求时如果后端没有隔离会话状态上一个请求的工具调用结果可能被错误地混入下一个请求的上下文中。我们的方案是所有会话状态严格绑定 session_id每个请求处理前先加载属于自己会话的状态处理完成后再写回。并且对会话状态的并发访问加了锁防止多个请求同时修改同一个会话的记忆数据。这个问题在早期测试阶段就暴露出来了当时表现为用户提第二个问题时Agent 会莫名提到第一个问题的内容。定位后发现是状态管理不当导致的会话串线问题。修复后这个问题就再没出现过。问题四离线环境依赖包缺失开发过程中随着项目推进难免要引入新的 Python 依赖包。在隔离内网环境里发现缺包是一件很头疼的事。我们的经验是在项目初期就做一次完整的依赖收集把所有可能用到的包都提前备好包括间接依赖。后续新增依赖时先在一台可以访问外网的机器上下载好 wheel 包再拷贝进内网仓库。由于这个流程需要人工操作所以我们养成了“代码合并前先确认依赖是否齐备”的团队习惯避免带病上线。7. 一些实战复盘与后续扩展思考这段内容算是整个项目结束后我的个人复盘。隔离内网下做 AI Agent 工程和公网环境最大的差别在于你能依赖的只有自己。所有云端组件都要本地化所有在线服务都要离线替代连调试的手段都受限。但也正因为如此整个系统的技术栈会非常收敛每一个组件都是经过仔细考量和实际验证后才留下来的。这种收敛其实是一种优势——系统更透明问题更容易定位运维也更可控。我个人在实际操作中最大的体会是AI Agent 的工程复杂度远超大多数人的预期。外面很多 Demo 演示看起来很惊艳但那是在理想条件下跑通的。一旦进入真实业务场景要面对的是各种边界条件、权限规则、数据质量问题、工具不稳定因素。这些问题的处理往往占整个项目工作量的一大半。如果这个项目后续还有迭代空间我会优先考虑两个方向。一是让 Agent 具备更强的自我反思能力当前版本的 Agent 在任务规划出错后虽然能够尝试修复但修复策略还比较机械。未来可以引入更细粒度的失败分析机制让 Agent 学会从历史失败中总结模式。二是把知识库的运营自动化当前知识库的更新虽然做成了自动化但文档质量审核、过时内容清理、知识冲突检测这些环节还是依赖人工。如果能用 Agent 来自动处理这些问题整个知识库的运营成本又会降一个台阶。最后再分享一个小技巧关于提示词模板的管理。Agent 系统的提示词会随着迭代不断变化我们早期把提示词直接硬编码在代码里结果每次调试都要改代码、走发版流程效率很低。后来专门做了一个提示词管理平台运营人员可以直接在线编辑和测试提示词不用动代码。版本管理和灰度发布也都放到了这个平台上。建议所有做 Agent 工程的团队都重视这件事提示词就是 Agent 的代码值得用工程化的方式去管理。这次隔离内网的 Agent 实战前前后后花了大半年时间。回头来看收获最大的不是某几个具体的技术方案而是建立了一套“如何在内网环境里系统性地构建 AI 应用”的方法论。这套方法论从模型部署、Agent 编排、知识库建设到工程化运维已经沉淀成了团队内部的落地方案模板。如果你也正在或者准备在隔离内网环境下搭建 AI Agent希望这篇实战复盘能给你一些参考。方法不一定通用但踩坑的经验应该是相通的。