防呆功能-防应用/MCP间互相调用成环导致后端服务无限嵌套请求

[liukewia]

例行检查

• [x] 我已确认目前没有类似 features
• [x] 我已确认我已升级到最新版本
• [x] 我已完整查看过项目 README，已确定现有版本无法满足需求
• [x] 我理解并愿意跟进此 features，协助测试和提供反馈
• [x] 我理解并认可上述内容，并理解项目维护者精力有限，不遵循规则的 features 可能会被无视或直接关闭

功能描述 现有功能：

1. fastgpt内可创建应用（简易应用/工作流），应用可以api形式导出api key供外部调用；fastgpt工作流http组件可以api调用方式调另一应用；http组件内url、header key、header value可以变量形式从应用全局变量/http组件变量/调用时传入变量获取变量值。
2. v4.9.6 开始fastgpt可导入mcp或导出应用为mcp，那么也可以导入已导出为mcp的应用为新mcp。工作流内可拖入已导入的mcp工具

根据以上，应用可通过http组件/mcp方式调用其他应用，正常使用带来很高灵活配置空间，但如果错误使用，可能造成：

1. 单应用无限调用自己，如应用a导出api key，再在工作流内http组件配置调用自己，或工作流内拖入该应用本身的mcp以调用自己；
2. 多应用间调用成环，通过上面第一点的方式，假设有应用a,b,c，可能配置出调用链为 a -> b -> c -> a 或类似的调用链

进而导致后端服务被自己疯狂请求，资源耗尽，无法处理正常请求。

至于防呆功能实现，可考虑以下两种但不限于此，欢迎大家讨论：

1. 提前预防此类错误配置。如在工作流保存/运行/调试时检测调用环。优点：提前检测，起到预防作用，不影响外部调用速度；缺点：无法处理变量方式注入变量至http组件；逻辑较复杂导致复杂应用检测时间长。
2. 外部调用接口时检测，如 /chat/completions 接口或 mcp runtool 时检测成环。优点：实现简单，只用检测调用时的调用链，且能处理变量注入；缺点：影响外部调用速度

检测成环方式： 1.api key调用方式：通过api key查appid，再查该app的nodes是否调用了其他http组件/fastgpt应用导出的mcp 2.mcp调用方式：通过mcp key查appid，再查该app的nodes是否调用了其他http组件/fastgpt应用导出的mcp

应用场景 防止恶意攻击/正常用户错误配置打挂服务

相关示例