[Bug]: sticky loader session 会无条件复用旧会话

[SiyaoWang686]

Summary

sticky loader session 会无条件复用旧会话，导致 loader 更新后的能力集/环境/工作区/driver 可能根本不生效。UpdateLoader 只改配置并刷新内存态，没有清掉已有 binding 或强制新建会话；后续运行时只要是 sticky policy，就直接拿旧 session 返回，运行中的 session 甚至完全不做任何重对齐。agent-compose/pkg/agentcompose/
loader_manager.go:147 agent-compose/pkg/agentcompose/loader_manager.go:1182 agent-compose/pkg/agentcompose/loader_manager.go:1334
这在和 OctoBus 联动时尤其危险：你把 loader 的 capset_ids 从 A 改成 B，后续任务仍可能继续拿着旧 session 的 CAP_TOKEN、旧 capset tags 和旧 guide 跑，等于权限收敛和能力切换都不即时生效

Steps to reproduce

1. 创建一个 loader：

   • session_policy = sticky
   • capset_ids = ["A"]

2. 运行一次这个 loader。

   • 它会创建一个 sticky session，假设 session id 是 sess-1
   • sess-1 会带上：
     • CAP_TOKEN
     • tag capset=A
     • 以及按 A 渲染出来的 capability guide

3. 更新同一个 loader：

   • 仍然是同一个 loader_id
   • session_policy 还是 sticky
   • 把 capset_ids 从 ["A"] 改成 ["B"]

4. 再运行一次这个 loader。

Expected behavior

当 loader 使用 sticky session policy 时，sticky 只能保证“尽量复用同一个会话”，但前提是这个会话仍然和当前 loader 配置一致。

因此在 loader 被更新后，如果这些会影响 session 语义的字段发生变化：

• capset_ids
• env
• workspace_id
• driver
• guest_image
• 以及其他会改变会话运行上下文的配置

系统应当执行下面两种行为之一：

1. 不再复用旧 sticky session，直接创建一个新 session。
2. 或者显式让旧 sticky session 失效，并重建到与新配置一致的状态。

对 OctoBus 联动场景，预期尤其应该是：

• loader 的 capset_ids 从 A 改成 B 后，后续运行不能继续使用绑定到 A 的旧 session。

• 新运行得到的 session 应带有新的 capability 绑定：

  • 新的 capset tags
  • 与新会话对应的 CAP_TOKEN
  • 按新的 capset 集合重新生成的 capability guide

• 如果旧 session 仍被保留，也不能再被这个 loader 继续复用。

Actual behavior

• 你第一次运行 sticky loader 时，会创建一个 session，并把它记录到 loader_binding。

  • 之后即使你更新了 loader 的关键配置，比如：

    • capset_ids
    • env
    • workspace_id
    • driver
    • guest_image

  • 系统也不会清理这个已有 binding。

  • 下一次运行时，代码仍然先查这个旧 binding。

  • 如果旧 session 还在运行，就直接返回这个旧 session。

  • 如果旧 session 没在运行，也只是 resume 它。

  • 整个过程中不会基于更新后的 loader 配置重新创建 session，也不会校验旧 session 的 capability/env/workspace/driver 是否已经过期。

Version or commit

No response

Runtime driver

None

Logs