尧图网页设计 
隔离内网这个词做AI应用开发的兄弟一听就懂不是简单没网而是模型、依赖、工具链、知识库、监控全部要私有化。网上那些开箱即用的云端API、现成的大模型服务、在线编排平台到了隔离环境里全变成摆设。我最近刚好把一个AI Agent项目从公网演示环境完整迁移到隔离内网踩了不少坑也把整个工程思路理顺了。这篇文章就围绕“隔离内网下AI Agent工程”这件事把设计思路、技术选型、部署细节、并发处理、问题排查完整过一遍尤其适合正在做企业内部智能助手、数据分析辅助、自动化运营这类场景的朋友参考。1. 为什么要在隔离内网里做 Agent 工程1.1 先搞清楚“隔离内网”到底隔离了什么很多人以为隔离内网只是不能上外网实际拆解下来隔离的东西比想象中多得多。第一层是网络出口控制。普通办公网虽然也有防火墙但至少能访问公网API、拉取开源镜像、访问代码仓库隔离内网通常有严格的访问控制策略要么物理隔离要么只留了一条受控的代理通道而且这条通道往往还要审批、备案。第二层是软件供应链隔离。nuget、pip、npm、docker hub这些公共源要么连不上要么速度极慢你必须提前准备好本地镜像仓库。第三层是数据出域限制。业务数据不能出内网意味着任何依赖云端计算的环节都要砍掉或者改造。最后还有一层容易被忽略时间同步、DNS解析、证书管理这些基础设施在隔离环境里经常有各自的坑。这些隔离对AI Agent项目是致命的。大模型的推理能力、知识库的向量检索、工具调用的外部服务全部依赖网络生态。你就想想一个Agent要“联网搜索”来回答用户问题在隔离内网里这个工具直接废掉一个Agent要调用第三方AI绘画接口也直接不可用。所以隔离内网做Agent本质上不是把公网方案搬进来而是从架构层面重新设计一条离线可跑的链路。1.2 隔离内网会砍掉 Agent 的哪些“手脚”AI Agent的核心能力可以简单分成三块大脑、记忆、手脚。大脑是LLM的规划与推理能力记忆是上下文和知识库手脚是调用外部工具执行动作。在隔离内网环境下受限最严重的就是“手脚”和“大脑的供应渠道”。工具层面典型的受限项包括公网搜索引擎API、云厂商的大模型服务、公开的天气/股票/地图等开放接口、在线代码执行沙箱、公网对象存储。这意味着原本“搜索一下再回答”的Agent必须替换成“检索内部知识库再回答”原本“把文件转成PDF再发出去”的Agent必须替换成调用内网文档转换服务。这不仅仅是替换API地址而是整个工具的抽象层和降级策略都要重写。模型层面不能用云端模型必须在本地GPU或CPU上部署开源模型随之而来的就是显存规划、量化选择、推理服务选型这些完整的工程问题。但换个角度想隔离内网也给Agent落地带来了确定性。公网模型API经常有版本升级、限流、内容策略变动而内网部署的模型版本可控、行为稳定。内网服务接口虽然要挨个打通但一旦打通权限边界和调用关系是清晰的反而更容易做审计和追溯。1.3 隔离内网里引入 Agent 的实际价值场景不是所有隔离内网都需要Agent但有四类场景非常典型。内部知识问答助手是最常见的。把制度文档、技术文档、项目文档切块后写入向量库员工用自然语言提问Agent通过RAG从知识库检索并组织回答减少翻文档的时间。数据分析辅助也很实用。让Agent对接内部数据库和数据仓库用自然语言查询来生成SQL、做图表这种场景不需要访问外网纯粹依赖内网数据就能闭环。自动化运营是另一个方向比如内网环境下自动生成内容草稿、定时调用内部系统发消息、批量处理工单Agent在这里扮演“流程调度员”的角色。研发提效同样重要让Agent理解内部代码库、自动生成代码审查意见、补充测试用例这类场景对数据隔离的要求通常也很高。我个人的判断是隔离内网反而是AI Agent最容易产生实际价值的土壤因为这里业务规则明确、数据结构清晰、权限边界可控Agent不会像在公网里那样“四处乱撞”反而能老老实实把一条业务流程走通。2. 整体设计思路与模块拆解2.1 架构选型控制面与执行面分离设计隔离内网的Agent架构我建议大家先想一个问题Agent的调度控制和实际动作执行是不是一定要绑定在同一个进程里我一开始也习惯把所有东西写在一个Python服务里后来发现隔离内网环境有两个特殊矛盾一是推理服务通常部署在GPU服务器上而业务服务可能部署在普通CPU服务器上两者物理分离二是工具调用涉及内网多个系统的账号权限如果所有Agent共用同一套凭据风险太高。于是我把架构拆成了控制面和执行面两个层次。控制面负责对话管理、意图识别、规划编排、状态维护可以理解成Agent的“大脑皮层”它不直接操作业务系统只决策下一步做什么。执行面负责具体的工具调用是Agent的“手脚”包括检索知识库、查询数据库、调用内部API、执行运维脚本等。执行面由控制面通过统一的工具网关调用工具网关里统一管理认证、鉴权、限流和审计。这种架构的优势在隔离内网里非常明显。控制面和执行面可以分别扩容控制面需要的是CPU和内存执行面如果包含模型推理则需要GPU资源分配起来互不干扰。更重要的是安全工具网关把Agent对业务系统的访问收敛到一个点出问题的时候只需要审计这一个点而不是在几十个Agent实例里翻日志。2.2 核心组件离线化设计模型、知识库、工具的本地替代先看模型层。隔离内网无法使用云端大模型必须部署开源模型。目前主流的选择思路是通用对话能力用7B到14B的模型本地单卡就能跑更强的任务如复杂推理、长文本分析用32B甚至更大规模对应多卡推理或多机部署。部署方案上追求吞吐量就用vLLM追求简单就用Ollama需要跟Java生态结合还要看看TGI。模型权重文件必须在有网的机器上提前下载好最好把huggingface格式转成更紧凑的格式再通过移动介质或内网传输通道拷进去。然后是Embedding模型和向量数据库。隔离内网意味着无法使用公网向量检索服务需要本地部署Embedding模型用bge、gte这类中英文效果好的模型配合Milvus、Elasticsearch或Qdrant。还有一个容易被忽略的组件是重排模型RAG场景下召回率再高如果排序不对回答质量一样上不去离线环境里本地部署一个bge-reranker模型能显著提升准确性。最后是工具层。原则很简单外部工具找不到替代就干脆不接入。把“公网搜索”替换成“内部知识库搜索”把“调用云端翻译”替换成“本地NLP模型翻译”把“查股票行情”替换成“查询内部行情系统”。工具不在多在于每个工具都要有明确的输入输出定义和失败降级路径。我在实际项目里的底线是所有工具调用必须有超时和重试机制因为内网服务虽然稳定但偶发的慢查询一样会拖垮整个Agent链路。2.3 技术栈选型为什么我用了 Python FastAPI LangGraph技术栈这块很多团队会纠结。我的建议是主链路用Python编排框架用LangGraphAPI服务用FastAPI并发瓶颈节点可以用Rust或者Go单独写旁路组件但不要一开始就用Rust重写整个Agent。选Python的理由很直白整个AI生态都在Python里。模型推理客户端、Embedding库、向量数据库驱动、数据处理工具几乎都有成熟的Python包团队招人也容易。你如果在Java技术栈成熟的团队里用Spring AI也是一个合理选择Spring AI跟Spring Boot的集成度确实高但LangGraph在复杂Agent编排上的表达能力还是更强如果你的核心需求是“多步骤、有条件跳转、可回滚的Agent流程”我建议以LangGraph为主链路语言写Python服务Java系统通过接口对接就好。FastAPI的优势在隔离内网里也很明显异步原生支持、自动生成OpenAPI文档、性能足够应对中等并发。而且它的StreamingResponse做SSE流式输出非常顺手这个能力对Agent体验至关重要——Agent思考可能要几十秒如果不流式输出用户等三秒就开始焦虑等十秒就以为系统挂了。3. 核心环节落地实操3.1 离线部署 LLM 推理服务显存估算与启动参数离线部署大模型推理第一步不是敲命令而是算显存。以常见的Qwen系列为例7B模型FP16权重约14GB加上KV Cache和激活值单卡24GB勉强能跑32GB比较舒服如果做4bit量化权重降到约4GB12GB到24GB显卡都能跑。32B模型FP16权重约64GB4bit量化后约17GB通常需要两张24GB卡或者一张80GB卡。这个估算公式可以简单记一下显存占用约等于权重大小加上KV Cache预留KV Cache又跟最大并发数和上下文长度成正比上下文越长、并发越高显存消耗越大。启动参数里有一个很关键的选项是--max-model-len这个值决定了模型能接受的最大上下文长度。设小了长文档分析直接被截断设大了KV Cache占用飙升。实际项目中如果Agent需要处理几千字的内部文档建议设成16K到32K然后根据并发需求反推显存预留。代码示例vLLM部署OpenAI兼容接口大致是这样python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-14B-Instruct-AWQ \ --served-model-name local-qwen \ --max-model-len 16384 \ --gpu-memory-utilization 0.92 \ --dtype auto \ --host 0.0.0.0 \ --port 8000启动之后验证一下接口是否正常工作curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: local-qwen, messages: [{role: user, content: 你好}] }在隔离内网里这一步做完相当于“大脑”就位了。后续Agent服务只需要把OpenAI兼容接口地址指向这个本地推理服务代码里完全不用区分这是公网模型还是本地模型这层抽象能省掉后面大量麻烦。3.2 用 LangGraph 编排多步骤 Agent 流程模型服务就位之后核心就是Agent编排。我拿一个“内部知识助手并具备自动上报工单能力”的典型场景来拆解。Agent接收到一个用户请求之后先判断这是不是个需要走完整流程的任务。如果用户只是问“报销流程是什么”直接走RAG检索回答就行但如果用户说“帮我查一下我的报销单审批到哪一步了如果卡住了就催一下”那就要先查询工单系统再根据状态决定是否调用催办接口。这种有条件跳转的流程用LangGraph表达非常清晰。先定义状态from typing import TypedDict, Annotated from langgraph.graph import StateGraph, END from langgraph.checkpoint.memory import MemorySaver class AgentState(TypedDict): messages: list intent: str need_tool_call: bool tool_records: list final_answer: str再定义节点函数def plan_step(state: AgentState) - AgentState: # 调用本地LLM判断意图输出是否要工具调用 ... def retrieve_step(state: AgentState) - AgentState: # 从向量库检索知识库内容 ... def query_ticket_step(state: AgentState) - AgentState: # 调用内网工单系统API ... def generate_answer_step(state: AgentState) - AgentState: # 综合上下文生成最终回答 ...然后构建图用条件边控制流程分支graph StateGraph(AgentState) graph.add_node(plan, plan_step) graph.add_node(retrieve, retrieve_step) graph.add_node(query_ticket, query_ticket_step) graph.add_node(answer, generate_answer_step) graph.set_entry_point(plan) graph.add_conditional_edges( plan, lambda state: query_ticket if state[need_tool_call] else retrieve, {query_ticket: query_ticket, retrieve: retrieve} ) graph.add_edge(query_ticket, answer) graph.add_edge(retrieve, answer) graph.add_edge(answer, END) agent graph.compile(checkpointerMemorySaver())实际跑起来你就会发现这种编排方式的优势是每个步骤都可以单独记录耗时、错误、输入输出出问题时能精准定位是模型问题、检索问题还是内网API问题而不是整个链路突然报一个无意义的错误。3.3 FastAPI 提供服务与流式输出实现Agent编排完成之后对外提供服务我用FastAPI封装了一层。最基础的是一个流式对话接口因为Agent场景响应时间通常比较长等整个流程跑完再一次性返回体验非常差。用SSE协议让前端逐步收到内容用户能看到“正在检索知识库”“正在生成回答”这样的过程反馈心理感受完全不同。核心实现大概是这样import json from fastapi import FastAPI from fastapi.responses import StreamingResponse app FastAPI() app.post(/api/agent/chat) async def agent_chat(request: dict): async def event_generator(): # 这里把LangGraph的逐步输出转换为SSE格式 async for event in agent.astream({messages: [request[message]]}): yield fdata: {json.dumps(event, ensure_asciiFalse)}\n\n return StreamingResponse(event_generator(), media_typetext/event-stream)这里有一个很关键的坑必须提醒FastAPI的异步接口里不要直接调用同步阻塞的LangGraph方法。Agent流程里有LLM推理调用、可能有向量检索、还有内网API请求这些同步操作会阻塞事件循环导致整个服务并发能力崩塌。正确做法是使用run_in_executor把同步逻辑扔到线程池里跑或者用独立的worker进程执行Agent任务。如果你需要更强的并发隔离可以引入Taskiq或Celery做任务队列API网关收到请求后先返回任务ID前端轮询任务状态这种模式适合更重的后台任务场景。4. 并发与稳定性让 Agent 扛住真实业务压力4.1 先想清楚 Agent 请求的“不合理”特征做Agent并发之前一定要理解Agent请求和普通Web请求的本质区别。普通接口往往在几百毫秒内返回一个进程能轻松处理大量请求而Agent请求的特点是“长连接、长耗时、多轮工具调用”。我实测过内部知识助手这个场景一次典型请求要经过意图识别、向量检索、重排、LLM生成四个阶段总体耗时经常在5秒到15秒之间复杂任务甚至要30秒以上。如果按传统Web服务“一个请求占用一个worker”的模式来算一台4核8G的机器并发稍微上来一点CPU就会被跑满然后所有请求集体变慢形成雪崩。所以Agent服务的并发设计不能套用普通接口的思路。另一个容易被忽略的问题是“放大效应”。一次用户提问在Agent内部可能拆成多次LLM调用、多次工具调用。如果LLM接口超时设置成60秒工具调用超时设置成30秒那单次请求的最坏等待时间会成倍放大。我在设计时会把每个环节的超时时间单独配置并在编排图里给每个节点做失败分支宁可让单次请求快速失败也不要让它挂在某个内网API上无限等待。4.2 并发优化三板斧推理放量、任务排队、结果缓存第一板斧是推理侧优化。vLLM自带continuous batching可以在一个推理进程内动态合并多个请求大幅提升GPU利用率。同样一张A100显卡使用vLLM部署的吞吐量通常比原生transformers推理高出几倍。如果并发需求再大就做多副本横向扩展前面用负载均衡分发请求每个副本只持有部分显存。但要注意多个推理副本共享同一份模型权重GPU显存会被乘以副本数资源规划时得算清楚。第二板斧是任务排队。不是所有请求都要实时返回很多后台分析类任务可以放进队列异步处理。比如“分析这一批工单的热点问题并生成报告”这类任务耗时以分钟计完全没有必要占用在线推理资源。我把FastAPI服务里的任务分成两类需要交互的在线任务走流式接口后台繁重任务走队列由独立worker异步执行用完再汇报结果。这样在线推理的GPU资源不会被后台任务挤占。第三板斧是缓存。Agent场景的重复查询比例其实不低尤其是企业内部知识问答很多问题翻来覆去就那么几个。我在服务里加了两层缓存第一层是语义缓存把用户问题向量化后去向量库找语义相近的已答问题命中就直接返回缓存答案第二层是前缀缓存对LLM推理使用带有前缀缓存能力的推理引擎相同系统提示词和知识库上下文能复用KV Cache减少重复计算。4.3 隔离内网环境里的资源规划与配额控制在隔离内网里做资源规划比公网环境要严苛得多因为扩容要提前申请硬件没法临时弹一台云主机。我的经验是先做容量测算再提需求避免盲目采购或者反复补充申请。容量测算的维度包括模型推理服务器的显存与带宽、知识库向量库的磁盘与内存、Agent业务服务的CPU和内存、日志与监控系统的存储。模型推理是最核心的资源一条经验值是一条GPU并发推理链路大约占固定显存2000个活跃用户规模下实测同时在线推理请求往往在20到40之间一张80G显卡跑14B量化模型基本够用如果要更大的模型或更高并发就要做多副本。配额控制同样重要。同一个Agent服务里可能有多个场景比如知识问答、工单处理、数据分析不同场景的优先级不同。我用了一个简单的令牌桶限流机制给高优先级场景分配更多配额低优先级场景超限时直接返回“系统繁忙”而不是让所有请求都挤在一起互相拖垮。5. 常见问题排查与避坑实录5.1 模型加载慢、显存不足怎么处理隔离内网里最典型的问题就是模型加载慢。刚部署的时候vLLM加载14B模型经常要花3到5分钟用户认为服务挂了其实是在加载模型。解决方案是做一个预热脚本服务启动后自动发一个简单请求让模型完成加载和权重初始化再对外宣告“就绪”。另外模型权重的存储介质影响也很大机械硬盘加载大模型权重极度痛苦换SSD或NVMe速度提升非常明显。显存不足也是高频问题。排查方法是用nvidia-smi实时观察显存占用然后逐步降低--gpu-memory-utilization但要留出空间给KV Cache。如果两个模型同时跑在同一张卡上互相抢显存导致OOM就要果断拆分到不同卡或者不同机器。另一个隐性问题是显存碎片化。长时间运行后即使总显存足够新请求也可能分配不到连续显存块而报OOM。我遇到过vLLM跑了一周后开始频繁OOM的情况重启服务又恢复。后续解决方案是给推理服务加上定时健康检查发现连续失败就自动重启同时记录重启前的日志用于根因分析。5.2 工具调用超时与内部服务依赖问题Agent工作流里工具调用的超时是隔离内网项目里排查最多的故障点。现象往往是Agent判断需要调用工具然后一直转圈最后超时报错。第一步排查内网网关。很多内网API通过网关暴露网关限流或者鉴权过期是导致调用失败的常见原因。我在工具调用层统一加了日志埋点记录每次调用的耗时、返回码和错误信息这样就很容易看出是网络层不通、鉴权失败还是对端服务超时。第二步排查DNS和网络策略。隔离内网的服务发现经常有环境差异A环境的服务域名在B环境不一定解析得通部署到新环境前先确认目标服务的连通性。第三步是重试策略。内网服务偶发抖动很常见我给工具调用封装了一层带指数退避的重试但重试次数不要超过3次重试再多对服务本身就是压力。这里有一个原则供参考工具调用是Agent系统里最脆弱的环节先于LLM做降级设计。我在每个工具定义里都写了“失败时返回什么给LLM”比如工单系统挂了就明确告诉LLM“当前无法查询工单系统请让用户稍后再试”而不是让LLM自己瞎编一个结果。5.3 知识库检索不准回答质量上不去RAG类Agent最头疼的问题就是检索不准。检索不准的直接表现是LLM生成内容时引用了不相关的文档片段或者关键信息根本没被召回。排查时我会先看召回结果本身。用调试脚本直接调用向量检索接口打印出top10的结果肉眼判断是不是相关。如果不相关优先检查chunk切分策略。内部文档经常是表格、流程图、代码片段混杂如果按固定长度切分表格被切断、代码被切断语义完整性就没了。我个人经验是结构化文档按标题层级切分表格和代码单独处理这样召回的片段才具备独立含义。再往下检查Embedding模型的适配度。通用Embedding模型对行业术语的理解往往不够好如果团队预算允许用领域数据微调Embedding模型效果提升非常明显。最后加一层重排用交叉编码器对召回结果精排虽然增加了一点延迟但准确率提升值回票价。混合检索也是值得尝试的方法。向量检索擅长语义相近的匹配但精确关键词匹配比如工单号、设备型号反而不如BM25两个通道的结果做融合后取topN能兼顾两种场景。5.4 离线可观测性没有云端工具怎么追踪链路公网环境里LangSmith这类在线链路追踪工具非常方便隔离内网里则完全不可用。我早期直接用print日志出问题的时候根本不知道是哪个环节出的问题非常痛苦。后来我搭了一套轻量级的离线可观测方案。日志层用structlog输出结构化日志每条日志带上trace_id和span_id从请求入口生成一个trace_id贯穿意图识别、检索、工具调用、LLM生成全链路。加一层中间件把所有环节的性能数据上报到Prometheus包括请求量、耗时分布、工具调用成功率、LLM首token延迟这些指标。界面上用Grafana做看板出问题先看指标再根据trace_id查日志定位效率大幅提升。监控告警也必须有。我配置了三个核心告警工具调用失败率超过5%就告警、LLM平均首token延迟异动告警、服务健康检查失败告警。这些告警通过内部消息通道推送给值班人员能让问题在用户感知之前就被处理掉。隔离内网虽然比公网“看不见”但可观测性建设恰恰是隔离环境里最值得投入的一环。我个人在实际操作中的体会是隔离内网做AI Agent最考验人的不是模型能力或者算法技巧而是工程化基本功。网络受限逼着你把每个环节都想清楚模型怎么部署、依赖怎么管理、工具怎么抽象、故障怎么排查、链路怎么追踪。这些做好之后Agent在隔离内网里的稳定性其实可以做到比公网环境更高因为少了外部服务的不可控因素所有环节都在自己手里。后续如果还想继续深入可以考虑用内网积累的数据对模型做领域微调或者把Agent接入内部工单、审批、知识管理这些系统做更多自动化流程这些方向都能让这套基础设施发挥更大的价值。 隔离内网AI Agent工程实战：从模型部署到全链路排查
隔离内网这个词做AI应用开发的兄弟一听就懂不是简单没网而是模型、依赖、工具链、知识库、监控全部要私有化。网上那些开箱即用的云端API、现成的大模型服务、在线编排平台到了隔离环境里全变成摆设。我最近刚好把一个AI Agent项目从公网演示环境完整迁移到隔离内网踩了不少坑也把整个工程思路理顺了。这篇文章就围绕“隔离内网下AI Agent工程”这件事把设计思路、技术选型、部署细节、并发处理、问题排查完整过一遍尤其适合正在做企业内部智能助手、数据分析辅助、自动化运营这类场景的朋友参考。1. 为什么要在隔离内网里做 Agent 工程1.1 先搞清楚“隔离内网”到底隔离了什么很多人以为隔离内网只是不能上外网实际拆解下来隔离的东西比想象中多得多。第一层是网络出口控制。普通办公网虽然也有防火墙但至少能访问公网API、拉取开源镜像、访问代码仓库隔离内网通常有严格的访问控制策略要么物理隔离要么只留了一条受控的代理通道而且这条通道往往还要审批、备案。第二层是软件供应链隔离。nuget、pip、npm、docker hub这些公共源要么连不上要么速度极慢你必须提前准备好本地镜像仓库。第三层是数据出域限制。业务数据不能出内网意味着任何依赖云端计算的环节都要砍掉或者改造。最后还有一层容易被忽略时间同步、DNS解析、证书管理这些基础设施在隔离环境里经常有各自的坑。这些隔离对AI Agent项目是致命的。大模型的推理能力、知识库的向量检索、工具调用的外部服务全部依赖网络生态。你就想想一个Agent要“联网搜索”来回答用户问题在隔离内网里这个工具直接废掉一个Agent要调用第三方AI绘画接口也直接不可用。所以隔离内网做Agent本质上不是把公网方案搬进来而是从架构层面重新设计一条离线可跑的链路。1.2 隔离内网会砍掉 Agent 的哪些“手脚”AI Agent的核心能力可以简单分成三块大脑、记忆、手脚。大脑是LLM的规划与推理能力记忆是上下文和知识库手脚是调用外部工具执行动作。在隔离内网环境下受限最严重的就是“手脚”和“大脑的供应渠道”。工具层面典型的受限项包括公网搜索引擎API、云厂商的大模型服务、公开的天气/股票/地图等开放接口、在线代码执行沙箱、公网对象存储。这意味着原本“搜索一下再回答”的Agent必须替换成“检索内部知识库再回答”原本“把文件转成PDF再发出去”的Agent必须替换成调用内网文档转换服务。这不仅仅是替换API地址而是整个工具的抽象层和降级策略都要重写。模型层面不能用云端模型必须在本地GPU或CPU上部署开源模型随之而来的就是显存规划、量化选择、推理服务选型这些完整的工程问题。但换个角度想隔离内网也给Agent落地带来了确定性。公网模型API经常有版本升级、限流、内容策略变动而内网部署的模型版本可控、行为稳定。内网服务接口虽然要挨个打通但一旦打通权限边界和调用关系是清晰的反而更容易做审计和追溯。1.3 隔离内网里引入 Agent 的实际价值场景不是所有隔离内网都需要Agent但有四类场景非常典型。内部知识问答助手是最常见的。把制度文档、技术文档、项目文档切块后写入向量库员工用自然语言提问Agent通过RAG从知识库检索并组织回答减少翻文档的时间。数据分析辅助也很实用。让Agent对接内部数据库和数据仓库用自然语言查询来生成SQL、做图表这种场景不需要访问外网纯粹依赖内网数据就能闭环。自动化运营是另一个方向比如内网环境下自动生成内容草稿、定时调用内部系统发消息、批量处理工单Agent在这里扮演“流程调度员”的角色。研发提效同样重要让Agent理解内部代码库、自动生成代码审查意见、补充测试用例这类场景对数据隔离的要求通常也很高。我个人的判断是隔离内网反而是AI Agent最容易产生实际价值的土壤因为这里业务规则明确、数据结构清晰、权限边界可控Agent不会像在公网里那样“四处乱撞”反而能老老实实把一条业务流程走通。2. 整体设计思路与模块拆解2.1 架构选型控制面与执行面分离设计隔离内网的Agent架构我建议大家先想一个问题Agent的调度控制和实际动作执行是不是一定要绑定在同一个进程里我一开始也习惯把所有东西写在一个Python服务里后来发现隔离内网环境有两个特殊矛盾一是推理服务通常部署在GPU服务器上而业务服务可能部署在普通CPU服务器上两者物理分离二是工具调用涉及内网多个系统的账号权限如果所有Agent共用同一套凭据风险太高。于是我把架构拆成了控制面和执行面两个层次。控制面负责对话管理、意图识别、规划编排、状态维护可以理解成Agent的“大脑皮层”它不直接操作业务系统只决策下一步做什么。执行面负责具体的工具调用是Agent的“手脚”包括检索知识库、查询数据库、调用内部API、执行运维脚本等。执行面由控制面通过统一的工具网关调用工具网关里统一管理认证、鉴权、限流和审计。这种架构的优势在隔离内网里非常明显。控制面和执行面可以分别扩容控制面需要的是CPU和内存执行面如果包含模型推理则需要GPU资源分配起来互不干扰。更重要的是安全工具网关把Agent对业务系统的访问收敛到一个点出问题的时候只需要审计这一个点而不是在几十个Agent实例里翻日志。2.2 核心组件离线化设计模型、知识库、工具的本地替代先看模型层。隔离内网无法使用云端大模型必须部署开源模型。目前主流的选择思路是通用对话能力用7B到14B的模型本地单卡就能跑更强的任务如复杂推理、长文本分析用32B甚至更大规模对应多卡推理或多机部署。部署方案上追求吞吐量就用vLLM追求简单就用Ollama需要跟Java生态结合还要看看TGI。模型权重文件必须在有网的机器上提前下载好最好把huggingface格式转成更紧凑的格式再通过移动介质或内网传输通道拷进去。然后是Embedding模型和向量数据库。隔离内网意味着无法使用公网向量检索服务需要本地部署Embedding模型用bge、gte这类中英文效果好的模型配合Milvus、Elasticsearch或Qdrant。还有一个容易被忽略的组件是重排模型RAG场景下召回率再高如果排序不对回答质量一样上不去离线环境里本地部署一个bge-reranker模型能显著提升准确性。最后是工具层。原则很简单外部工具找不到替代就干脆不接入。把“公网搜索”替换成“内部知识库搜索”把“调用云端翻译”替换成“本地NLP模型翻译”把“查股票行情”替换成“查询内部行情系统”。工具不在多在于每个工具都要有明确的输入输出定义和失败降级路径。我在实际项目里的底线是所有工具调用必须有超时和重试机制因为内网服务虽然稳定但偶发的慢查询一样会拖垮整个Agent链路。2.3 技术栈选型为什么我用了 Python FastAPI LangGraph技术栈这块很多团队会纠结。我的建议是主链路用Python编排框架用LangGraphAPI服务用FastAPI并发瓶颈节点可以用Rust或者Go单独写旁路组件但不要一开始就用Rust重写整个Agent。选Python的理由很直白整个AI生态都在Python里。模型推理客户端、Embedding库、向量数据库驱动、数据处理工具几乎都有成熟的Python包团队招人也容易。你如果在Java技术栈成熟的团队里用Spring AI也是一个合理选择Spring AI跟Spring Boot的集成度确实高但LangGraph在复杂Agent编排上的表达能力还是更强如果你的核心需求是“多步骤、有条件跳转、可回滚的Agent流程”我建议以LangGraph为主链路语言写Python服务Java系统通过接口对接就好。FastAPI的优势在隔离内网里也很明显异步原生支持、自动生成OpenAPI文档、性能足够应对中等并发。而且它的StreamingResponse做SSE流式输出非常顺手这个能力对Agent体验至关重要——Agent思考可能要几十秒如果不流式输出用户等三秒就开始焦虑等十秒就以为系统挂了。3. 核心环节落地实操3.1 离线部署 LLM 推理服务显存估算与启动参数离线部署大模型推理第一步不是敲命令而是算显存。以常见的Qwen系列为例7B模型FP16权重约14GB加上KV Cache和激活值单卡24GB勉强能跑32GB比较舒服如果做4bit量化权重降到约4GB12GB到24GB显卡都能跑。32B模型FP16权重约64GB4bit量化后约17GB通常需要两张24GB卡或者一张80GB卡。这个估算公式可以简单记一下显存占用约等于权重大小加上KV Cache预留KV Cache又跟最大并发数和上下文长度成正比上下文越长、并发越高显存消耗越大。启动参数里有一个很关键的选项是--max-model-len这个值决定了模型能接受的最大上下文长度。设小了长文档分析直接被截断设大了KV Cache占用飙升。实际项目中如果Agent需要处理几千字的内部文档建议设成16K到32K然后根据并发需求反推显存预留。代码示例vLLM部署OpenAI兼容接口大致是这样python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-14B-Instruct-AWQ \ --served-model-name local-qwen \ --max-model-len 16384 \ --gpu-memory-utilization 0.92 \ --dtype auto \ --host 0.0.0.0 \ --port 8000启动之后验证一下接口是否正常工作curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: local-qwen, messages: [{role: user, content: 你好}] }在隔离内网里这一步做完相当于“大脑”就位了。后续Agent服务只需要把OpenAI兼容接口地址指向这个本地推理服务代码里完全不用区分这是公网模型还是本地模型这层抽象能省掉后面大量麻烦。3.2 用 LangGraph 编排多步骤 Agent 流程模型服务就位之后核心就是Agent编排。我拿一个“内部知识助手并具备自动上报工单能力”的典型场景来拆解。Agent接收到一个用户请求之后先判断这是不是个需要走完整流程的任务。如果用户只是问“报销流程是什么”直接走RAG检索回答就行但如果用户说“帮我查一下我的报销单审批到哪一步了如果卡住了就催一下”那就要先查询工单系统再根据状态决定是否调用催办接口。这种有条件跳转的流程用LangGraph表达非常清晰。先定义状态from typing import TypedDict, Annotated from langgraph.graph import StateGraph, END from langgraph.checkpoint.memory import MemorySaver class AgentState(TypedDict): messages: list intent: str need_tool_call: bool tool_records: list final_answer: str再定义节点函数def plan_step(state: AgentState) - AgentState: # 调用本地LLM判断意图输出是否要工具调用 ... def retrieve_step(state: AgentState) - AgentState: # 从向量库检索知识库内容 ... def query_ticket_step(state: AgentState) - AgentState: # 调用内网工单系统API ... def generate_answer_step(state: AgentState) - AgentState: # 综合上下文生成最终回答 ...然后构建图用条件边控制流程分支graph StateGraph(AgentState) graph.add_node(plan, plan_step) graph.add_node(retrieve, retrieve_step) graph.add_node(query_ticket, query_ticket_step) graph.add_node(answer, generate_answer_step) graph.set_entry_point(plan) graph.add_conditional_edges( plan, lambda state: query_ticket if state[need_tool_call] else retrieve, {query_ticket: query_ticket, retrieve: retrieve} ) graph.add_edge(query_ticket, answer) graph.add_edge(retrieve, answer) graph.add_edge(answer, END) agent graph.compile(checkpointerMemorySaver())实际跑起来你就会发现这种编排方式的优势是每个步骤都可以单独记录耗时、错误、输入输出出问题时能精准定位是模型问题、检索问题还是内网API问题而不是整个链路突然报一个无意义的错误。3.3 FastAPI 提供服务与流式输出实现Agent编排完成之后对外提供服务我用FastAPI封装了一层。最基础的是一个流式对话接口因为Agent场景响应时间通常比较长等整个流程跑完再一次性返回体验非常差。用SSE协议让前端逐步收到内容用户能看到“正在检索知识库”“正在生成回答”这样的过程反馈心理感受完全不同。核心实现大概是这样import json from fastapi import FastAPI from fastapi.responses import StreamingResponse app FastAPI() app.post(/api/agent/chat) async def agent_chat(request: dict): async def event_generator(): # 这里把LangGraph的逐步输出转换为SSE格式 async for event in agent.astream({messages: [request[message]]}): yield fdata: {json.dumps(event, ensure_asciiFalse)}\n\n return StreamingResponse(event_generator(), media_typetext/event-stream)这里有一个很关键的坑必须提醒FastAPI的异步接口里不要直接调用同步阻塞的LangGraph方法。Agent流程里有LLM推理调用、可能有向量检索、还有内网API请求这些同步操作会阻塞事件循环导致整个服务并发能力崩塌。正确做法是使用run_in_executor把同步逻辑扔到线程池里跑或者用独立的worker进程执行Agent任务。如果你需要更强的并发隔离可以引入Taskiq或Celery做任务队列API网关收到请求后先返回任务ID前端轮询任务状态这种模式适合更重的后台任务场景。4. 并发与稳定性让 Agent 扛住真实业务压力4.1 先想清楚 Agent 请求的“不合理”特征做Agent并发之前一定要理解Agent请求和普通Web请求的本质区别。普通接口往往在几百毫秒内返回一个进程能轻松处理大量请求而Agent请求的特点是“长连接、长耗时、多轮工具调用”。我实测过内部知识助手这个场景一次典型请求要经过意图识别、向量检索、重排、LLM生成四个阶段总体耗时经常在5秒到15秒之间复杂任务甚至要30秒以上。如果按传统Web服务“一个请求占用一个worker”的模式来算一台4核8G的机器并发稍微上来一点CPU就会被跑满然后所有请求集体变慢形成雪崩。所以Agent服务的并发设计不能套用普通接口的思路。另一个容易被忽略的问题是“放大效应”。一次用户提问在Agent内部可能拆成多次LLM调用、多次工具调用。如果LLM接口超时设置成60秒工具调用超时设置成30秒那单次请求的最坏等待时间会成倍放大。我在设计时会把每个环节的超时时间单独配置并在编排图里给每个节点做失败分支宁可让单次请求快速失败也不要让它挂在某个内网API上无限等待。4.2 并发优化三板斧推理放量、任务排队、结果缓存第一板斧是推理侧优化。vLLM自带continuous batching可以在一个推理进程内动态合并多个请求大幅提升GPU利用率。同样一张A100显卡使用vLLM部署的吞吐量通常比原生transformers推理高出几倍。如果并发需求再大就做多副本横向扩展前面用负载均衡分发请求每个副本只持有部分显存。但要注意多个推理副本共享同一份模型权重GPU显存会被乘以副本数资源规划时得算清楚。第二板斧是任务排队。不是所有请求都要实时返回很多后台分析类任务可以放进队列异步处理。比如“分析这一批工单的热点问题并生成报告”这类任务耗时以分钟计完全没有必要占用在线推理资源。我把FastAPI服务里的任务分成两类需要交互的在线任务走流式接口后台繁重任务走队列由独立worker异步执行用完再汇报结果。这样在线推理的GPU资源不会被后台任务挤占。第三板斧是缓存。Agent场景的重复查询比例其实不低尤其是企业内部知识问答很多问题翻来覆去就那么几个。我在服务里加了两层缓存第一层是语义缓存把用户问题向量化后去向量库找语义相近的已答问题命中就直接返回缓存答案第二层是前缀缓存对LLM推理使用带有前缀缓存能力的推理引擎相同系统提示词和知识库上下文能复用KV Cache减少重复计算。4.3 隔离内网环境里的资源规划与配额控制在隔离内网里做资源规划比公网环境要严苛得多因为扩容要提前申请硬件没法临时弹一台云主机。我的经验是先做容量测算再提需求避免盲目采购或者反复补充申请。容量测算的维度包括模型推理服务器的显存与带宽、知识库向量库的磁盘与内存、Agent业务服务的CPU和内存、日志与监控系统的存储。模型推理是最核心的资源一条经验值是一条GPU并发推理链路大约占固定显存2000个活跃用户规模下实测同时在线推理请求往往在20到40之间一张80G显卡跑14B量化模型基本够用如果要更大的模型或更高并发就要做多副本。配额控制同样重要。同一个Agent服务里可能有多个场景比如知识问答、工单处理、数据分析不同场景的优先级不同。我用了一个简单的令牌桶限流机制给高优先级场景分配更多配额低优先级场景超限时直接返回“系统繁忙”而不是让所有请求都挤在一起互相拖垮。5. 常见问题排查与避坑实录5.1 模型加载慢、显存不足怎么处理隔离内网里最典型的问题就是模型加载慢。刚部署的时候vLLM加载14B模型经常要花3到5分钟用户认为服务挂了其实是在加载模型。解决方案是做一个预热脚本服务启动后自动发一个简单请求让模型完成加载和权重初始化再对外宣告“就绪”。另外模型权重的存储介质影响也很大机械硬盘加载大模型权重极度痛苦换SSD或NVMe速度提升非常明显。显存不足也是高频问题。排查方法是用nvidia-smi实时观察显存占用然后逐步降低--gpu-memory-utilization但要留出空间给KV Cache。如果两个模型同时跑在同一张卡上互相抢显存导致OOM就要果断拆分到不同卡或者不同机器。另一个隐性问题是显存碎片化。长时间运行后即使总显存足够新请求也可能分配不到连续显存块而报OOM。我遇到过vLLM跑了一周后开始频繁OOM的情况重启服务又恢复。后续解决方案是给推理服务加上定时健康检查发现连续失败就自动重启同时记录重启前的日志用于根因分析。5.2 工具调用超时与内部服务依赖问题Agent工作流里工具调用的超时是隔离内网项目里排查最多的故障点。现象往往是Agent判断需要调用工具然后一直转圈最后超时报错。第一步排查内网网关。很多内网API通过网关暴露网关限流或者鉴权过期是导致调用失败的常见原因。我在工具调用层统一加了日志埋点记录每次调用的耗时、返回码和错误信息这样就很容易看出是网络层不通、鉴权失败还是对端服务超时。第二步排查DNS和网络策略。隔离内网的服务发现经常有环境差异A环境的服务域名在B环境不一定解析得通部署到新环境前先确认目标服务的连通性。第三步是重试策略。内网服务偶发抖动很常见我给工具调用封装了一层带指数退避的重试但重试次数不要超过3次重试再多对服务本身就是压力。这里有一个原则供参考工具调用是Agent系统里最脆弱的环节先于LLM做降级设计。我在每个工具定义里都写了“失败时返回什么给LLM”比如工单系统挂了就明确告诉LLM“当前无法查询工单系统请让用户稍后再试”而不是让LLM自己瞎编一个结果。5.3 知识库检索不准回答质量上不去RAG类Agent最头疼的问题就是检索不准。检索不准的直接表现是LLM生成内容时引用了不相关的文档片段或者关键信息根本没被召回。排查时我会先看召回结果本身。用调试脚本直接调用向量检索接口打印出top10的结果肉眼判断是不是相关。如果不相关优先检查chunk切分策略。内部文档经常是表格、流程图、代码片段混杂如果按固定长度切分表格被切断、代码被切断语义完整性就没了。我个人经验是结构化文档按标题层级切分表格和代码单独处理这样召回的片段才具备独立含义。再往下检查Embedding模型的适配度。通用Embedding模型对行业术语的理解往往不够好如果团队预算允许用领域数据微调Embedding模型效果提升非常明显。最后加一层重排用交叉编码器对召回结果精排虽然增加了一点延迟但准确率提升值回票价。混合检索也是值得尝试的方法。向量检索擅长语义相近的匹配但精确关键词匹配比如工单号、设备型号反而不如BM25两个通道的结果做融合后取topN能兼顾两种场景。5.4 离线可观测性没有云端工具怎么追踪链路公网环境里LangSmith这类在线链路追踪工具非常方便隔离内网里则完全不可用。我早期直接用print日志出问题的时候根本不知道是哪个环节出的问题非常痛苦。后来我搭了一套轻量级的离线可观测方案。日志层用structlog输出结构化日志每条日志带上trace_id和span_id从请求入口生成一个trace_id贯穿意图识别、检索、工具调用、LLM生成全链路。加一层中间件把所有环节的性能数据上报到Prometheus包括请求量、耗时分布、工具调用成功率、LLM首token延迟这些指标。界面上用Grafana做看板出问题先看指标再根据trace_id查日志定位效率大幅提升。监控告警也必须有。我配置了三个核心告警工具调用失败率超过5%就告警、LLM平均首token延迟异动告警、服务健康检查失败告警。这些告警通过内部消息通道推送给值班人员能让问题在用户感知之前就被处理掉。隔离内网虽然比公网“看不见”但可观测性建设恰恰是隔离环境里最值得投入的一环。我个人在实际操作中的体会是隔离内网做AI Agent最考验人的不是模型能力或者算法技巧而是工程化基本功。网络受限逼着你把每个环节都想清楚模型怎么部署、依赖怎么管理、工具怎么抽象、故障怎么排查、链路怎么追踪。这些做好之后Agent在隔离内网里的稳定性其实可以做到比公网环境更高因为少了外部服务的不可控因素所有环节都在自己手里。后续如果还想继续深入可以考虑用内网积累的数据对模型做领域微调或者把Agent接入内部工单、审批、知识管理这些系统做更多自动化流程这些方向都能让这套基础设施发挥更大的价值。