小节三：Session 和 Run 到底有什么区别——多轮会话里最容易混淆的两个概念

这是这一节最重要的工程边界之一。

很多早期 Agent 项目会直接：

session_id == run_id

Demo 可以。

但后面很快会出问题。

Session 是“长期会话”

例如：

Session：
“帮我持续处理这个项目”

用户在这段 Session 中可能连续提出：

先分析错误
继续修
再跑测试
最后总结

整个过程都属于同一个 Session。

Run 是“具体一次任务执行”

比如：

Run 1：
分析测试失败

Run 2：
修复依赖问题

Run 3：
重新执行完整测试

每个 Run 有自己的：

status
start_time
end_time
steps
error

所以：

Session 1
 ├─ Run 1
 ├─ Run 2
 └─ Run 3

为什么一个 Session 要多个 Run？

因为用户不会总是一次说完全部需求。

例如：

10:00
User：
先帮我定位问题。

Run 1 完成。

10:20
User：
可以，按这个方案修。

Run 2。

11:00
User：
再帮我跑完整测试。

Run 3。

但三次任务共享：

Conversation
Project Context
Working Memory
历史 Tool 信息

所以属于同一 Session。

一个简单 Session / Run 结构

from dataclasses import dataclass, field


@dataclass
class Run:
    run_id: str
    goal: str
    status: str = "READY"


@dataclass
class Session:
    session_id: str
    runs: list[Run] = field(
        default_factory=list
    )

真正课程后面会把 Run 设计得更完整。

这里先理解关系。

Working Memory 属于谁？

这是一个需要工程判断的问题。

简单 Agent：

Session = 一个持续任务

Working Memory 放 Session。

复杂系统：

同一 Session 内多个独立 Run

更适合：

Session-level Memory
+
Run-level Working Memory

例如 Session-level：

这个项目使用 Python 3.9
用户要求最小修改

Run-level：

当前 Run 正在排查 requests 缺失

后面我们会逐渐把这种层次细化。

现在先保持：

Session.working_memory

方便理解。

如果把这里的演进关系画出来，就能看到为什么课程现在先用简单方案，而不是一开始就把 Memory 拆得很复杂：

当前课程默认“一段 Session 主要围绕一个持续任务”，因此 Session.working_memory 足够直观。等同一 Session 内出现多个相对独立的 Run 后，再拆成 Session-level Memory 和 Run-level Working Memory，会比一开始就堆很多层次更容易维护。

Tool History 属于谁？

也类似。

Session Tool History：

整个会话里调用过什么

Run Tool History：

当前 Run 调用了什么

真实项目可以：

Run 保存原始 Tool Calls
Session 通过 runs 聚合

本节为了简化，先把 Tool History 放 Session。

等进入 Run 和 Trace 章节再演进。

Session 什么时候结束？

可以有多种策略。

用户主动：

关闭会话

系统自动：

30 天无活动 → EXPIRED

任务完成不一定等于 Session 关闭。

比如 Run 完成以后，用户还可能继续追问。

所以：

Run COMPLETED

不应该自动：

Session CLOSED

这也是二者必须分离的原因。

把关系压缩成一张图，就是“Session 管长期上下文，Run 管一次执行生命周期”：

这里尤其要注意，某个 Run 结束只代表这一轮任务执行结束，并不代表整个会话结束。用户完全可以在同一个 Session 里先定位问题、再修复、最后做完整验证；三次 Run 共享上下文，但每个 Run 又能独立记录自己的状态、步骤和错误。