内网环境怎么办：没有外网时 Agent 还能做什么

很多企业的开发环境是内网隔离的，没有外网访问。这种情况下 agent 的可用性会大幅下降，但并非完全不可用。我把可行方案梳理一下。 先说问题。agent 的核心能力依赖模型推理，而模型服务通常在外部。内网环境下，这条路直接断了。表现是调用超时、证书错误、连接被拒。 方案一：私有化部署模型。把模型部署在内网，让 agent 指向内部推理服务。MiMo Code 走 MIT 开源，这条路走得通，代价是需要 GPU 资源和运维投入。Claude 侧也有自托管环境的公测，面向 Team 和 Enterprise 用户。适合对数据外流有硬性要求、且有一定基础设施投入能力的团队。 方案二：代理转发加白名单。在边界上放一个代理，只放行模型 API 这一个目标，且记录全部流量。这样既满足了外网访问需求，又保持了可控性。落地要点是白名单要精确到域名，不要开成通配；日志要能关联到具体会话。 方案三：分阶段使用。把 agent 用在不需要外网的环节，比如本地的代码格式化、静态分析、脚本生成这类有本地模型或者规则引擎就够的活。外网相关的复杂任务仍然走人工。 方案四：离线知识库。把团队的规范、排查手册、常见问题整理成结构化文档，配合本地检索。这不能替代模型推理，但能显著提升信息获取效率。 实操提醒： 一，提前测试。别等要用的时候才发现不通，网络策略的审批周期往往比预期长。 二，证书问题。内网环境的证书链经常不完整，HTTPS 调用很容易失败。这个坑在外部环境也存在，前面聊过一个类似的案例：本地缺少 CA 证书导致所有 API 调用直接失败，排查时表现为"秒返回空结果"，很容易误判成服务故障。 三，文档化。把内网环境的配置方式写进团队手册，新人不用重新踩一遍。 一句话：内网不是不能用 agent，是用法不同。先解决"能不能连通"，再谈"好不好用"。