一句话看懂：掘金作者 SFLYQ 在 2026 年 9 月 29 日分享了一套名为 internal-mcp 的内网 AI Agent 工程方案，把 TAPD、Confluence、GitLab、ELK、内网发布系统等系统的接口统一封装成 MCP Tools，让 AI 在不改造原系统的前提下调用内网能力，写操作则走人工审批。
事件核心：发生了什么
文章描述了一个企业内网落地 AI Agent 的典型困境：服务端、客户端、前端各端在需求评审、方案设计、开发、测试各阶段都要让 coding agent 访问内网系统（如 TAPD 取 PRD、Confluence 写方案、GitLab 提 MR、Sparrow 发测试环境），但各内网系统登录方式不一（SSO、令牌、Cookie），且短期内不可能都支持 MCP。作者的解法是自建 internal-mcp：用 SystemAdapter 抽象各系统登录与调用差异，凭据以 AES-256-GCM 加密存入 SQLite，授权后的 API 动态生成 MCP Tools（命名形如 system_api_key），写操作先落待执行单、人工在管理台审批后才真正执行，并全程记录 ExecLog。方案还提供管理台（127.0.0.1:6688）、MCP 端点（127.0.0.1:6677/mcp）、MCP 市场以及随仓库分发的 Agent Skills。作者明确表示只公开思路、不开源。
为什么重要
它触及企业 AI 落地的真实卡点——不是模型不够强，而是内网系统没有 MCP 接口、凭据散落、越权风险高。这套方案把“权限治理”和“审批留痕”放在 Agent 调用链的必经之路上，同时用个人账号凭据保证权限与手动操作一致，避免越权，实际上是把 MCP 从个人玩具推向企业内部基础设施。对于大量尚未支持 MCP 的自建、开源或商用内网系统，这提供了一条低成本过渡路径。
对用户/开发者/创作者的影响
对企业开发者而言，最直接的价值是可复用：不必各端重复造轮子写 skills script 处理登录鉴权，Agent 通过统一 tools 获取上下文。写操作审批机制降低了“AI 误改内网数据”的风险，调用日志也便于追溯。需要注意的是，作者未开源，接入对象是公司内网系统，普通用户无法直接复用代码，只能借鉴其分层思路（adapter、authcache、治理域、draft 审批）。对关注 MCP 生态的开发者来说，“MCP 市场 + 外部 stdio MCP server 接入 + Skills 编排”这一组合，也提示了 Agent 工具治理可能成为独立产品方向。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是这套思路是否会被其他团队复现为开源实现，形成通用的内网 MCP 网关；二是审批与审批可视化（如 apidoc、wiki 差异对比）的体验能否标准化；三是当 MCP Tools 数量增长后，系统开关与 tools 授权开关的组合能否真正控制上下文污染。目前公开信息显示，该方案仍属个人实践总结，未有商业化或开源计划。
来源：juejin
