一句话看懂：掘金作者 SFLYQ 在 2026 年 9 月 29 日发布文章，分享了一套名为 internal-mcp 的内网 AI Agent 工程方案：不改动现有内网系统的前提下，把内网 API 封装成 MCP Tools 供 AI 调用，并用审批、留痕、凭据托管来兜底风险。
事件核心：发生了什么
在不少公司的开发流程里，需求评审读 TAPD、写方案同步 Wiki、开发阶段建 API 文档并自动提 GitLab MR、测试阶段取用例查缺陷，都发生在隔离内网。AI Coding Agent 想参与，就要面对 SSO、令牌、Cookie 各不相同的登录体系。前期各端各自写 skills script 登录调 API，复用性差、门槛高、凭据散落各处。
作者给出的 internal-mcp 方案是：用 SystemAdapter 把各内网系统的登录与调用差异封装起来，内网接口按需授权后动态生成 MCP Tools，命名形如 {system}_{api_key}；写操作不直接执行，只生成待审批单，人工在管理台确认后才落地并写入执行日志。凭据用 AES-256-GCM 加密存储、明文不回显，令牌 401 后自动重登。管理台跑在 127.0.0.1:6688，MCP 端点在 127.0.0.1:6677/mcp，持久化用单文件 SQLite。文中提到已覆盖 Apidoc、TAPD、Confluence、ELK、GitLab、内网发布系统 Sparrow 等系统。作者明确表示思路通用，但因接入的是公司内网系统，不开源。
为什么重要
2025 年以来 MCP 已成为 AI 客户端连接外部工具的事实标准，但企业内网的存量系统短期内不可能都改造出 MCP 能力。这套方案的价值不在技术深度，而在工程取舍：把“接口不改造”和“权限不放大”同时成立——Agent 依然以个人账号权限调用，效果等同于人手动登录操作，不产生越权。它示范了一种常见路径，即在隔离网络里给 AI 补上下文，而不是先推进系统改造。对正在评估 AI 工程化落地的团队，这是比“全量接入 MCP”更现实的一步。
对用户/开发者/创作者的影响
对开发者，写操作强制人工审批、调用全程留痕，意味着 AI Agent 可以被放进真实开发流程，而不只是本地问答。对平台与安全团队，凭据加密托管和系统级、接口级双重开关，缓解了 MCP Tools 过多造成的上下文污染与误调用。对想做类似项目的团队，需要注意方案依赖自建管理台与常驻服务，且未开源，直接复用的成本主要在适配层——每个内网系统仍要写一套登录与调用实现。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是这套模式能否沉淀出通用的 SystemAdapter 抽象，降低逐系统适配成本；二是 MCP 生态若推出更标准的鉴权与授权规范，自建审批层是否会被替代；三是 Skills 编排在标准化流程（如测试环境发布）中的稳定性，是否真能替代多轮对话式的工具调用。
来源：juejin
