容器沙箱的idle_timeout是如何判定的？是否有额外的判定细节？

[xuqingyan0217]

我把idle_timeout设为1h，agent调用沙箱执行脚本时，脚本内部是一个异步的run_pipeline，所以脚本很快就会结束，主要是做任务提交。
可我实际测试下来，任务已经超过了1h，沙箱还在，我只是把后台 worker 的 stdout/stderr 挂到 run.log；而如果我直接接到DEVNULL，沙箱会在脚本提交任务后直接消失。

[willem-bd]

回答：容器沙箱的 idle_timeout 判定机制

1. idle_timeout 的判定机制

DeerFlow 的 idle_timeout 判定是纯时间戳驱动的，与容器内部的进程状态、文件描述符或 stdout/stderr 无关。

核心逻辑在 aio_sandbox_provider.py 的 _cleanup_idle_sandboxes() 方法中：

def _cleanup_idle_sandboxes(self, idle_timeout: float) -> None:
    current_time = time.time()
    # ...
    for sandbox_id, last_activity in self._last_activity.items():
        idle_duration = current_time - last_activity
        if idle_duration > idle_timeout:
            # 标记为待销毁

判定条件：当前时间 - 最后活跃时间 > idle_timeout → 销毁沙箱。

活跃时间 _last_activity 的更新时机：

• acquire() — 沙箱被获取/复用时
• get() — 每次工具调用时（如 bash、read_file 等）
• release() — 沙箱被释放到 warm pool 时
• 沙箱被创建/发现/回收时

检查频率：后台线程每 60 秒 检查一次（IDLE_CHECK_INTERVAL = 60）。

双重检查：在真正销毁前会再次验证 last_activity 是否仍然超时（防止在标记和销毁之间有新的工具调用更新了时间戳）。

2. 关于你观察到的 stdout/stderr 行为差异

你观察到的现象（stdout/stderr → 文件时沙箱超过 1h 仍存活；→ DEVNULL 时立即消失）不是由 DeerFlow 的 idle_timeout 机制造成的。DeerFlow 的空闲检查完全不关心容器内部发生了什么。

可能的解释是 AIO sandbox 容器（agent-infra/sandbox）自身的进程生命周期管理：

• stdout/stderr → 文件：后台 worker 进程持续写入 run.log，AIO sandbox 容器内部可能检测到有活跃的子进程或打开的文件描述符，因此容器保持运行。
• stdout/stderr → DEVNULL：当后台 worker 的输出被丢弃时，AIO 容器可能认为没有活跃进程而自行退出。

关键区别：

• DeerFlow 的 idle_timeout 销毁沙箱时，会调用 self._backend.destroy(info) 停止 Docker 容器，并记录日志 "Destroying idle sandbox ..." 或 "Destroyed idle warm-pool sandbox ..."
• 如果是容器自行退出，DeerFlow 会在下次访问时检测到沙箱不健康，然后走 _drop_unhealthy_sandbox() 路径

你可以通过检查 gateway 的日志来区分这两种情况：

• 如果看到 Destroying idle sandbox 日志 → 是 idle_timeout 触发的
• 如果看到 in-process cache failed health check 或 Dropped unhealthy sandbox → 是容器自行退出的

3. 关于脚本快速结束后沙箱的存活

根据代码逻辑：

bash_tool() → ensure_sandbox_initialized() → provider.get(sandbox_id) → 更新 _last_activity
            → sandbox.execute_command(command) → HTTP 调用 AIO 容器 → 返回输出

脚本执行完后，_last_activity 会被更新为当前时间。之后如果没有新的工具调用：

• 如果沙箱处于 active 状态（在 _sandboxes 中），idle checker 会在 idle_timeout（你设的 1h）后销毁它
• 如果沙箱被 release() 到 warm pool，warm pool 中的沙箱也会在 idle_timeout 后被销毁（基于 release_timestamp）

4. 总结

问题	答案
idle_timeout 如何判定？	纯时间戳：current_time - _last_activity[sandbox_id] > idle_timeout
检查频率？	每 60 秒
stdout/stderr 是否影响？	不影响 DeerFlow 的 idle timeout 逻辑
为什么文件重定向时沙箱活得更久？	可能是 AIO sandbox 容器内部的进程管理行为，非 DeerFlow 控制
为什么 DEVNULL 时沙箱立即消失？	可能是 AIO 容器检测不到活跃进程而自行退出，非 idle timeout 触发

5. 建议

如果你想确保后台任务不被沙箱超时中断，有两个方向：

1. 增大 idle_timeout 或设为 0（禁用自动清理）
2. 检查 AIO sandbox 容器自身的配置，了解它如何管理子进程生命周期（这是 agent-infra/sandbox 项目的范畴）