System Agent 任务上下文隔离与快照机制设计思考

在迭代 fix-system-agent 智能系统 Agent 的过程里，我们遇到一个很容易被忽略、但在并发场景下会悄悄制造隐性 Bug 的问题：上下文污染。

当前多 Agent 调度流程中，会话上下文是随任务流转、就地修改的。当多个任务并行、任务重试、分支试错、子任务失败回滚时，上下文容易被脏数据篡改。典型现象：A 工单的上下文混入 B 工单的历史信息；重试时带着上一轮错误的中间结果继续执行；分支推演失败后，主流程上下文被污染，输出不可预期。这类问题复现概率不稳定，属于典型的偶现幻觉类问题，排查成本很高。

本文记录我们关于「上下文快照 + 读写隔离」的方案思考，属于架构层面的预研方案，供项目讨论。

一、现有上下文模型的问题

现有模式：共享上下文对象，各个 Agent 直接读写同一份会话 state。 优点：实现简单，不需要额外拷贝，开发速度快； 缺点集中在这几点：

1. 并发安全弱：多工单并发调度时，如果状态对象没有做隔离，存在上下文串扰风险；
2. 无法回滚：某个分支 Agent 试错失败、输出异常时，已经修改的上下文无法撤销，只能人工清空；
3. 缺少版本：无法查看一个任务在每一步 Agent 执行前后的上下文快照，调试时很难定位是哪一步篡改了状态；
4. 重试逻辑难写：重试子任务时，很难还原到 “执行该子任务之前” 的原始状态，容易叠加历史错误信息。

很多 Agent 项目早期都这么写，单任务串行跑的时候一切正常，一旦接入并发、自动重试、多分支探索，隐性问题就会集中爆发。

二、方案思路：引入上下文快照（Snapshot）机制

核心思路：不默认共享可变状态，在 Agent 调度节点做状态快照，实现写时复制（Copy-on-Write）。

1. 状态快照生成时机

在调度器分发任务给单个 Agent 之前，自动生成当前上下文的只读快照：

• 快照包含：会话 ID、trace_id、当前上下文 payload、时间戳、版本号、父快照 ID
• 传给 Agent 的是快照副本，Agent 在副本上做修改
• Agent 执行完成之后，由调度器决定：是否把新状态合并回主上下文；失败 / 拒绝时直接丢弃副本，主上下文保持不变。

一句话：Agent 只允许修改自己拿到的副本，主状态的变更由调度器统一管控。

2. 分支与重试场景适配

• 重试：直接加载上一个快照版本，重新分发，不受上一轮失败输出影响；
• 并行分支推演（比如多个方案并行评估）：每个分支基于同一个父快照独立演化，分支之间互不干扰；
• 人工回滚：支持根据版本号，一键恢复上下文到历史快照节点。

3. 隔离分层设计

两层上下文区分，降低理解成本：

• 基础只读上下文（Base Context）：工单基础信息、用户原始输入、固定配置，全程不可修改；
• 可变运行上下文（Runtime Context）：Agent 产生的中间结果、工具返回值、临时标记，这部分才做快照与拷贝。

基础信息固定不变，只有运行时中间状态需要快照，能减少拷贝开销。

4. 持久化与调试辅助

快照可以可选持久化到本地文件 / 数据库：

• 开发环境：默认开启快照持久化，方便回放、对比每一步上下文变化；
• 生产环境：可配置关闭持久化，只在内存中做副本隔离，控制内存开销；
• 配套调试工具：输入 trace_id + 版本号，查看该版本上下文，对比前后 diff。

三、需要权衡的工程代价

这个方案不是没有成本，也是我们内部讨论的重点：

1. 内存开销上升：频繁快照、长会话场景下，会保存多份上下文副本；可以增加自动清理策略，任务结束后自动回收快照，限制单任务最大快照数量；
2. 序列化开销：上下文对象序列化、深拷贝会带来少量耗时；对于短生命周期工单，影响很小；超长上下文场景需要做裁剪策略；
3. 复杂度提升：调度器需要管理版本链、快照树、合并策略，不再是简单的直接传参。

所以这个能力建议做成可选特性，通过配置开关控制：简单串行任务可以关闭快照，维持原有轻量模式；并发、重试、分支评估场景开启快照隔离。

四、后续可扩展方向

1. 增加上下文差异对比工具，自动输出两个快照之间的字段变更 diff；
2. 支持快照裁剪策略，自动丢弃老旧、非关键的中间快照，控制存储；
3. 结合前面提到的链路埋点，在 trace 链路里绑定每一步对应的快照版本，实现 “链路日志 + 状态快照” 联动排查；
4. 增加快照校验钩子，在合并回主上下文前，校验状态结构是否符合 schema，拦截非法状态写入。

很多 Agent 项目的稳定性瓶颈，不在于大模型本身，而在于状态管理。 上下文是 Agent 系统的 “内存”，不加隔离的可变共享状态，是并发、重试、分支场景下大量偶现问题的根源。快照隔离机制属于前置防御型设计，在项目规模还不大的时候引入，能避免后期业务复杂之后，大规模重构状态层。

当然，这只是一个设计提案，落地前还需要结合项目的并发量、上下文大小、业务复杂度做取舍。