[Feature]: KubernetesSandbox复用，TTL，单实例多租户并发问题

[oyx888]

KubernetesSandbox 复用，有人提出claimOwned 来解决这个问题，目前是不能复用；
复用之后，目前框架不具备清理pod，目前我们线上的使用方法是获取的时候写入活跃时间戳，xxljob定时清理；
单实例agent并发时，不同用户不同session对话，第一个完成的能正常走完流程，观察源码sandbox会被置空导致后续对话全线崩溃；
希望尽早解决这些问题，谢谢！

[oss-maintainer]

Issue Evaluation

Category: enhancement | Status: Evaluated

Three related concerns around KubernetesSandbox:

1. Reuse — currently a sandbox cannot be reused once claimed; the proposed claimOwned idea points at ownership-aware reuse, but today reuse is not supported.
2. Lifecycle cleanup — the framework does not GC pods; your current workaround (write an active timestamp on acquire + xxl-job cleanup) shows the missing capability is framework-managed TTL/reaping.
3. Single-instance multi-tenant concurrency — with one agent instance serving different users/sessions concurrently, the first flow to finish clears the sandbox reference, causing subsequent sessions to fail.

Feasibility: needs-discussion for (1) and (2) (design + ownership model); item (3) behaves more like a concurrency defect in sandbox state management and may deserve its own focused bug report with a reproduction.
Scope: agentscope-extensions sandbox (Kubernetes).
Compatibility: reuse/TTL must be opt-in to avoid changing current single-tenant behavior.

Could you open a separate bug issue for item (3) with a minimal reproduction (number of concurrent sessions, observed stack/log)? That will let us treat the concurrency defect separately from the reuse/TTL feature work.

---

Automated evaluation by github-manager-bot

[oyx888]

Issue Evaluation

Category: enhancement | Status: Evaluated

Three related concerns around KubernetesSandbox:

1. Reuse — currently a sandbox cannot be reused once claimed; the proposed claimOwned idea points at ownership-aware reuse, but today reuse is not supported.
2. Lifecycle cleanup — the framework does not GC pods; your current workaround (write an active timestamp on acquire + xxl-job cleanup) shows the missing capability is framework-managed TTL/reaping.
3. Single-instance multi-tenant concurrency — with one agent instance serving different users/sessions concurrently, the first flow to finish clears the sandbox reference, causing subsequent sessions to fail.

Feasibility: needs-discussion for (1) and (2) (design + ownership model); item (3) behaves more like a concurrency defect in sandbox state management and may deserve its own focused bug report with a reproduction. Scope: agentscope-extensions sandbox (Kubernetes). Compatibility: reuse/TTL must be opt-in to avoid changing current single-tenant behavior.

Could you open a separate bug issue for item (3) with a minimal reproduction (number of concurrent sessions, observed stack/log)? That will let us treat the concurrency defect separately from the reuse/TTL feature work.

Automated evaluation by github-manager-bot

第3项我已经提过bug了，#2849

[oyx888]

Issue Evaluation  问题评估

Category: enhancement | Status: Evaluated类别: enhancement | 状态: 已评估

Three related concerns around KubernetesSandbox:关于 KubernetesSandbox 有三个相关的问题需要解决：

1. Reuse — currently a sandbox cannot be reused once claimed; the proposed claimOwned idea points at ownership-aware reuse, but today reuse is not supported.重用——目前沙盒在被占用的状态下是无法重用的；提出的 claimOwned 方案提出了一种具有所有权管理的重用方式，但目前还不支持这种重用功能。
2. Lifecycle cleanup — the framework does not GC pods; your current workaround (write an active timestamp on acquire + xxl-job cleanup) shows the missing capability is framework-managed TTL/reaping.生命周期清理——该框架不执行垃圾回收操作；你目前的解决方案是在获取资源后加上一个活动时间戳，然后执行 xxl 作业清理。不过，这种解决方案未能解决缺失的功能需求，即框架级的管理功能，比如回收不再需要的资源。
3. Single-instance multi-tenant concurrency — with one agent instance serving different users/sessions concurrently, the first flow to finish clears the sandbox reference, causing subsequent sessions to fail.单实例多租户并发机制——通过一个代理实例同时服务于不同的用户或会话。首先完成某个任务的流程会清除沙盒引用，这会导致后续的会话无法正常运行。

Feasibility: needs-discussion for (1) and (2) (design + ownership model); item (3) behaves more like a concurrency defect in sandbox state management and may deserve its own focused bug report with a reproduction.可行性：需要讨论第(1)项和第(2)项的内容（设计方案及所有权模式）；第(3)项则更像是沙箱状态管理中的并发缺陷，可能需要单独提交一个详细的缺陷报告，并附上可复现的示例。 Scope: agentscope-extensions sandbox (Kubernetes).范围：agentscope-extensions 沙盒（Kubernetes）。 Compatibility: reuse/TTL must be opt-in to avoid changing current single-tenant behavior.兼容性：复用/TTL 功能必须采用用户自愿参与的方式来实现，以避免改变当前仅适用于单个用户的行为模式。

Could you open a separate bug issue for item (3) with a minimal reproduction (number of concurrent sessions, observed stack/log)? That will let us treat the concurrency defect separately from the reuse/TTL feature work.您能否为项目 3 创建一个单独的缺陷报告？在报告中简要描述一下重现该问题的条件，比如同时进行的会话数量、观察到的堆栈/日志等。这样我们就可以将并发问题与重用/超时机制的相关工作分开处理。

Automated evaluation by github-manager-bot由 github-manager-bot 进行的自动化评估

第 1 点最初的原因就是"沙箱不能复用"。 claimOwned 只是实现手段，不是动机。 最初痛点（现象层面）——在你们的并发生产场景里，同一会话要跨多轮/多条消息持续对话，沙箱 pod 需要在回合之间保持存活、能被后续消息重新 attach。但上游做不到，（代码根因）——harness 的 KubernetesSandbox.shutdown() 无条件等于 SDK 的 terminate()（closeConnection() + 删除 SandboxClaim → pod 一起没），没有"只释放、不销毁"的路径。所以一个 claim 只要被占用、会话一结束就被删掉，生命周期里只有 create 和
destroy，不存在"保留待复用"。结果就是沙箱不可复用。于是要解决的真正问题——把沙箱从"用完即焚"改成"可保留、可重新 attach"，让后续回合不用每次从 warm pool 重建 + 重灌工作区（冷启动/状态丢失的成本）。claimOwned=false 正是给 shutdown() 打开"只关连接、留 pod"这条原来不存在的路径。第 2 点的原因最初痛点（现象层面）——claimOwned=false 让会话结束后 pod 不再被销毁，等于"释放"和"回收"彻底分开了。此时框架里没有任何一方会去删 pod：默认模式是"谁结束谁删"（shutdown 即 terminate），但复用模式下结束不再删。如果不补清理手段，空闲/残留 pod会无限累积、占着集群资源不释放。根因——框架假设了单租户语义："沙箱结束 = 资源该回收了"，所以不需要 TTL。一旦打开复用，这个假设失效，但框架又没有提供可插拔的回收点。我们判断回收策略（空闲多久算超时、删哪些）属于部署侧决定，不该写死进框架。于是我自己使用外部框架做回收点每次拿到/attach 沙箱时，在 claim 上写 agentscope.io/last-activity 活跃时间戳（best-effort，失败则退回创建时间），线上用 xxljob 定时扫超时未活跃的 claim 删掉，竞态兜底：若两轮之间 pod 恰好已被 xxljob 回收，resume() 找不到 claim 就用同一 claimName 重建并从 workspace 快照恢复，续跑无感。希望尽快解决，我们生产环境几百号人同时用测出来的结果，目前都只是简单临时修复了下能使用