Agent 会话要按树保存而不是消息列表
消息列表装不下的东西
| 内容 | 为什么必须存 |
|---|---|
| Tool Call / Tool Result | 决定模型下一轮看到什么;丢了就复现不出当时的判断 |
| 压缩摘要(compaction) | 长会话的历史已被替换成摘要,不存就无法恢复上下文 |
| 分支 / 当前 leaf | 会话可以从某个节点分叉,得知道「现在在哪一支」 |
| 模型切换、活动工具 | 同一会话可能换过模型 |
典型一轮的实际结构:用户说「帮我润色当前笔记」→ Agent 调读取工具 → 工具返回正文 → Agent 调写入工具 → 工具返回待确认提案 → Agent 回复「已准备好修改,请确认」。这些都要按类型落库,服务重启后据此重建上下文,而不是只靠内存。
与之配套的执行状态
会话内容之外还要有「这一轮请求」的状态记录(如 AiTurn):请求幂等 ID、状态(running / succeeded / failed / interrupted)、执行者、lease 过期时间、对应的用户/助手节点、最终输出、错误码。
它解决三件事:浏览器超时重试同一请求不会重复执行(幂等)、进程崩溃后能判断这轮是否还活着(lease 可接管)、失败可归因(错误码与输出分离)。
相关
- 阻塞式工具与提案确认 —— Tool Result 里那一环为什么必须回到 loop
- Agent Harness 不只是 Tool Loop —— 会话与生命周期是 harness 的一部分
- 上下文成本由基础上下文和会话数决定 —— 存了树不代表要全塞给模型
- 更新时序要由本地最新状态决定 —— 谁是最新节点要靠显式记录