Dify模型CLI反代使用中无法调用工具与子代理

背景

随着 AI 应用开发门槛的降低，Dify 等开源 LLM 应用平台被广泛用于构建对话、Agent、工作流等场景。然而，在实际部署中，用户往往需要将模型请求通过反向代理（反代）转发到自己的 API 网关（如 NewAPI），以便统一管理 API 密钥、限流、日志等。同时，部分用户希望在命令行界面（CLI）中直接调用这些经过反代的模型，以实现脚本化或自动化任务。但反代后的模型在 CLI 环境下的能力并不总是完整，尤其是在需要调用工具或子代理（subagent）时，常出现功能缺失的问题。

核心内容

原文标题为《dify模型怎么反代在cli中进行使用》，来源是 LINUX DO 社区 AI 板块。帖主陈述其已有的尝试：通过 chatflow 接入 NewAPI，然后在 codex（可能指 Dify 内置的代码执行节点或类似环境）中使用。帖主发现，这种配置下模型“似乎只能进行对话，无法调用工具或 subagent”。帖主向社区求助：“有佬友有解决方案吗”。该帖子共有 2 条回复，但原文未展示回复的具体内容。

简言之，帖主的场景是：

• 目标：在 CLI 环境中使用经过反代的 Dify 模型。
• 当前方案：通过 Dify 的 chatflow 串联 NewAPI 作为模型后端，然后在 codex 中调用该模型。
• 问题：该方案仅支持纯对话，模型不具备调用工具或子代理（subagent）的能力。
• 期望：获得在原方法基础上修复该问题的解决方案。

关键要点

• 反代模型的使用场景：用户希望将 Dify 模型通过 NewAPI 反代后，在 CLI 或 codex 中直接调用。
• 现有尝试的路径：chatflow → NewAPI → codex 中使用，但功能受限。
• 具体缺失的功能：无法调用工具（tool）和子代理（subagent），仅能完成普通对话。
• 问题的技术本质：反代后的模型接口可能未完整暴露工具调用/函数调用（function calling）能力，或 codex 环境与模型之间的协议不兼容。
• 社区求助：帖主尚未获得明确解决方案，寻求其他用户经验。

意义与影响

该提问反映了当前 AI 应用工程中的一个常见痛点——模型能力在反代或中转环节中被降级。许多开发者为了管理和安全目的使用网关（如 NewAPI），但这类中转层如果未正确转发工具调用相关的结构化输出（如 function call 参数），就会导致 Agent 或工具链无法正常工作。这一问题阻碍了 Dify 等平台在自动化脚本（CLI）中的深度应用，也暴露了反代方案需要额外配置来保持模型原生能力的必要性。如果能够解决此问题，将推动更多开发者将 AI 工作流从 UI 界面迁移到 CLI，实现更灵活的批处理、CI/CD 集成等高级场景。同时，这也提示 AI 平台和网关工具需完善对工具调用协议的支持，降低用户的使用摩擦。