最近高频使用workbuddy等AI智能体工具，而集团内网大模型的API又无法直接使用，于是写了一个转发脚本。
介绍一下商业化AI智能体工具接入内网私有化部署大模型的思路。
一家集团企业的内部智能助手，要用上集团私有化部署的大模型，中间隔着一道看不见的墙：接口不兼容。
一边是智能助手只认标准的 OpenAI 兼容接口，一边是企业自建模型网关走的是私有协议。两边都是成熟的系统，谁都不愿意改。怎么办？
答案是一段不到200行的 Python 代理脚本。它像一座桥，架在智能助手和私有化模型之间，让两边无缝对接，全程数据不出内网。
一个真实的企业AI落地难题
过去一年，大型集团企业密集完成开源大模型的私有化部署。以 DeepSeek 系列为代表的开源底座，被部署在集团内网的国产化算力上，数据不出门，成本可控，安全自主。
模型有了，问题也随之而来：企业内部沉淀多年的智能助手、办公工具，如何接入这套私有化模型？
主流智能助手大多按 OpenAI 兼容规范开发，默认的接入方式是指定一个 base_url 和一个模型名。但集团自建模型网关的接口路径、认证方式往往与之不同，直接配置必然失败。
要么改造智能助手去适配私有网关，要么改造网关去兼容智能助手，要么，写一个适配层，把两边都留给对方。
代理：最优雅的适配层
代理的思路很简单：在本地起一个轻量 HTTP 服务，模拟 OpenAI 兼容接口，收到智能助手的请求后，原样转发给集团私有化模型网关，再把模型的响应原样返回。
整个服务只有三个核心能力：
模型列表接口。智能助手启动时会先拉取可用模型列表。代理返回集团网关支持的两个模型标识，助手立刻就能在界面上选到模型，如同接入了一个标准大模型平台。
对话补全接口。智能助手发出的聊天请求，代理读取后原样转发到私有网关，网关的认证通过请求头中的访问凭证完成，代理不做任何业务改动，只做透明的流量搬运。
流式响应。大模型回答是逐字生成的，代理需要保持流式通道，让用户看到打字机式的输出效果。代理原样透传流式响应，并保持连接，体验与直连商业大模型无异。
为什么是本地代理而不是改代码
有工程师会问：改智能助手的源码不是更直接吗？
现实是：智能助手是采购或长期维护的商业软件，升级频繁，改动代价高；模型网关承载全集团多个系统的调用，更不能为单一工具开特例。代理是独立的一层，任何一端升级都不影响它，出了问题单独排查，用完即走。
这符合企业软件集成的一个朴素原则：能不动核心系统，就尽量不动。加一层薄薄的适配层，往往是最稳妥的工程决策。
走向生产环境的三个细节
脚本虽短，落地到生产环境有几个容易被忽略的细节：
认证信息不写死在代码里。访问凭证应通过环境变量注入，而不是硬编码在源码中。源码会进代码仓库，凭证一旦提交，等于向所有能看到仓库的人公开了访问权限。
证书校验不能随意关闭。内网环境常用自签证书，开发时关闭校验图省事，但生产环境应配置可信证书，避免中间人风险。安全性和便利性之间，需要明确的取舍。
超时与异常处理。转发调用必须设置超时时间，上游卡死时快速失败；异常路径要确保连接被正确关闭，否则长时间运行后会出现连接泄漏，最终拖垮服务。
小工具背后的大趋势
一个不到200行的脚本，折射出的是大模型落地企业的一个普遍模式：私有化部署开源模型 + 标准接口适配层。
对集团型企业来说，核心业务数据不出内网是底线，开源模型成本优势是现实，而标准接口则是生态的通行证。模型可以私有化，接口必须标准化，这中间留下的空白，正是无数类似的小工具、小适配层的用武之地。
下一次当你面对两个"都对但接不上"的系统时，不妨想想这段脚本：问题不一定出在系统上，也许只是缺一座桥。
