Dify Agent调用插件超时:PluginDaemonInternalServerError: killed by timeout

错误链路全景

这是一个3 层架构的超时杀进程错误:

scss 复制代码
Plugin (Python) ──[SSE]──▶ Plugin Daemon (Go) ──[HTTP]──▶ Dify API (Python)
                              │
                          ⏱️ 计时器
                        (600s 默认)

第 1 层 --- 根源:Plugin Daemon (Go)

错误消息 "killed by timeout" 来源于 langgenius/dify-plugin-daemon 仓库的 Go 代码,它出现在两处:

位置 文件 场景
SSE 流处理 internal/service/base_sse.go Agent 执行过程中,Daemon 通过 SSE 与插件通信,超时后写回 "killed by timeout"
端点处理 internal/service/endpoint.go 插件端点调用超时,返回 HTTP 500

Go 端的关键逻辑:

go 复制代码
// 伪代码示意
timer := time.NewTimer(time.Duration(maxExecutionTimeout) * time.Second)
select {
case <-timer.C:
    // 超时 → 杀死插件进程,返回错误
    writeData(InternalServerError("killed by timeout"))
case <-done:
    // 正常完成
}

第 2 层 --- Dify API 客户端转换

base.py 中,当 Daemon 返回 HTTP 500 时:

python 复制代码
# 第 266 行
except httpx.HTTPStatusError as e:
    if e.response.status_code < 500:
        raise PluginDaemonClientSideError(...)
    else:
        raise PluginDaemonInternalServerError(description=str(e))

然后 _handle_plugin_daemon_error 方法(第 380 行)根据错误类型名反序列化:

python 复制代码
case PluginDaemonInternalServerError.__name__:
    raise PluginDaemonInternalServerError(description=message)

最终错误格式为:req_id: 15279e8a2e PluginDaemonInternalServerError: killed by timeout


第 3 层 --- 消费方

  • endpoint.py:在 delete_endpoint() 中捕获 PluginDaemonInternalServerError,用于区分"真的错误"和"已删除"(幂等删除逻辑)
  • provider.py:将 PluginDaemonInternalServerError 映射为重试/降级策略

超时控制点

有两个独立的 600 秒超时配置,含义不同:

配置项 位置 默认值 作用
PLUGIN_MAX_EXECUTION_TIMEOUT Plugin Daemon 容器环境变量 600s ⚠️ Daemon 杀死插件进程的超时
PLUGIN_DAEMON_TIMEOUT API 容器环境变量 600s Dify API 等待 Daemon HTTP 响应的超时

配置文件位置:

文件 内容
api/configs/feature/__init__.py:236 PLUGIN_DAEMON_TIMEOUT Pydantic 字段定义
api/core/plugin/impl/base.py:44-55 构建 httpx.Timeout 实例
docker/docker-compose-template.yaml:232 API 端: PLUGIN_DAEMON_TIMEOUT=${PLUGIN_DAEMON_TIMEOUT:-600.0}
docker/docker-compose-template.yaml:554 Daemon 端: PLUGIN_MAX_EXECUTION_TIMEOUT=${PLUGIN_MAX_EXECUTION_TIMEOUT:-600}
docker/envs/core-services/plugin-daemon.env.example:13 PLUGIN_MAX_EXECUTION_TIMEOUT=600
docker/envs/core-services/api.env.example:12 PLUGIN_DAEMON_TIMEOUT=600.0

根因总结

req_id: 15279e8a2e PluginDaemonInternalServerError: killed by timeout 表示:

  1. Agent 执行时间超过了 PLUGIN_MAX_EXECUTION_TIMEOUT(默认 600 秒 / 10 分钟)
  2. Plugin Daemon (Go) 的计时器先于插件完成触发
  3. Daemon 杀死了插件子进程
  4. Daemon 向 Dify API 返回 HTTP 500,错误消息为 "killed by timeout"
  5. Dify API 将其转换为 PluginDaemonInternalServerError

可能的原因

  • Agent 的 LLM 调用特别慢(如模型响应时间长、被限流)
  • Agent 需要多轮工具调用,每轮积累后总耗时超过 600s
  • 工具调用本身执行缓慢(如外部 API 响应慢)
  • 插件进程资源不足导致执行缓慢
  • PLUGIN_MAX_EXECUTION_TIMEOUT 设置过小(默认 600s)

解决方案方向

  1. 增大超时 :在 docker-compose 环境变量中调大 PLUGIN_MAX_EXECUTION_TIMEOUT(如 1200
  2. 减小 Agent 执行复杂度:减少最大迭代轮数、使用更快的模型
  3. 检查工具性能:排查 Agent 使用的工具是否存在慢调用
相关推荐
新知图书19 分钟前
8.4 处理智能体的工具调用与输出解析《LangGraph开发AI Agent实践》
人工智能·agent·ai agent·智能体
冬奇Lab25 分钟前
开源项目第197期:skill-up — 阿里巴巴出品的 Agent Skills 评测与进化工具,评测闭环 + 自动修复
人工智能·开源·资讯
玫瑰互动GEO26 分钟前
海外GEO优化案例-ChatGPT搜索关键词排名GEO优化案例详解(含RAG机制与Tokenization技术拆解)
人工智能·ai·chatgpt·geo优化
冬奇Lab26 分钟前
Code Agent 解剖(10):agent 崩了怎么恢复,对话历史存在哪?
人工智能·开源·agent
IanSkunk30 分钟前
视光中心建设复盘:从流程断层到组织能力的落地路径
大数据·人工智能
AI备案指南-满满33 分钟前
人工智能拟人化互动服务安全自评估报告的评估要点有哪些?
人工智能·算法·安全·机器人·大模型备案·算法备案
围炉聊科技1 小时前
OpenAdapt 源码拆解:录制一次,如何实现确定性回放
人工智能
SLD_Allen1 小时前
字节跳动飞连(Feilian)AI智能体零信任安全治理深度技术研究报告
网络·人工智能·安全·智能体安全
IT_陈寒1 小时前
Redis的DEL命令居然没删干净数据?这个坑我爬了半天
前端·人工智能·后端
熊猫钓鱼>_>2 小时前
鸿蒙ArkUI全手势操作实战指南:6大基础手势从原理到落地避坑
人工智能·深度学习·华为·架构·harmonyos·arkui·tapgesture