Feature Request: 支持本地 Agent 节点注册机制，实现云端 FastGPT 安全调用内网 MCP 工具

[TianLanSky]

Feature Request: 支持本地 Agent 节点注册机制，实现云端 FastGPT 安全调用内网 MCP 工具

描述

当前 FastGPT 的 MCP 工具集成要求 MCP Server 必须部署在公网可访问的地址（通过 SSE 或配置 mcpServerProxyEndpoint）。但在实际业务场景中，许多需要调用的工具（如 SSH、本地系统命令、内网 API、文件操作等）运行在本地或内网环境，无法直接暴露公网端点。这导致云端 FastGPT 应用无法利用这些强大的本地能力，而自建本地 Agent 又会失去 FastGPT 提供的对话记录、多用户管理、监控等运营能力。

背景与痛点

使用场景：我基于 Python 开发了一套运维排障工具，通过自定义 MCP Server 提供 SSH 连接、系统命令执行等能力。当 Agent 运行在本地时，调用非常顺畅。但在尝试使用 FastGPT 云端应用（SaaS 或云部署版）调用这些工具时，由于 MCP Server 位于 127.0.0.1 或内网，无法与云端通信。

当前解决方案的局限：

1. 使用内网穿透（如 frp、ngrok）将本地 MCP 暴露为公网地址。但这引入了严重的安全风险（将 SSH 权限暴露公网），且配置复杂，企业级场景难以接受。
2. 自建本地 Agent（直接调用 DeepSeek API 等）。但这样做会失去云端平台的运营能力，包括对话记录留存、用户管理、应用发布、监控告警等，不适合产品化与团队协作。

用户需要在“本地工具能力”与“云端运营能力”之间二选一，这严重限制了 FastGPT 在企业内部运维、个人助手、物联网控制等场景的落地。

建议方案

参考近期爆火的 OpenClaw 架构设计，建议引入 “本地 Agent 节点注册机制”，实现云端与本地之间的安全双向通信。具体包含：

1. Gateway 节点接收能力
   FastGPT 服务端开放一个 长连接接入端口（如 WebSocket/SSE），支持本地节点主动发起连接并注册自身信息（包括可用的 MCP Tools、鉴权凭证等）。

2. 轻量级本地 Client
   提供一个官方的轻量级客户端（如 Python/Node.js 版），用户运行在本地环境。该客户端通过 Token 认证主动连接 FastGPT Gateway，注册本地可用的 MCP Tools，并维持心跳。

3. 指令下发与结果回传
   当 FastGPT 应用需要调用某个本地 MCP Tool 时，通过已建立的长连接通道将任务下发至指定本地 Client 执行，执行结果原路返回。整个过程无需在本地开放入站端口，极大降低安全风险。

4. 权限与安全沙箱
   在 FastGPT 应用配置中增加对该本地节点的权限控制，如限制可执行的命令范围、访问路径、操作频率等，防止恶意提示词造成本地系统破坏。

预期收益

• 安全性：本地无入站端口暴露，所有通信由本地 Client 主动发起，大幅降低攻击面。
• 扩展性：支持云端应用调度任意内网/本地资源，使 FastGPT 真正成为“物理世界操作大脑”。
• 运营能力保留：用户无需放弃 FastGPT 的对话记录、用户管理、监控等运营功能，即可获得本地工具能力。
• 对标竞争力：填补 FastGPT 在“本地 Agent”领域的空白，应对 OpenClaw 等新兴框架的挑战。

补充信息

• 竞品参考：OpenClaw 的 Pi-embedded 架构（Gateway + 本地节点主动连接）已经验证了此模式的可行性。
• 已有需求关联：目前社区有通过 mcp-client 等方案临时解决，但都需要公网暴露，未从架构层面解决安全与易用性问题。
• FastGPT 版本：v4.14.8，已支持 MCP 鉴权，证明团队重视安全性，本建议与此方向一致。

希望官方能考虑此方案，助力 FastGPT 拓展更多企业级与个人场景。感谢！