Agent 搭建过程中上下文管理的思考
上下文裁剪本质上是不可逆的删除。在 Pickel-Agent 的实现中，更稳健的设计是“完整持久化 + 按需检索”的双轨架构。
在 Agent 系统中，上下文裁剪本质上是不可逆的删除，轻易丢弃上下文的代价极高。
在 Pickel-Agent 的早期开发中，针对上下文管理尝试过多种方案：固定窗口滑动裁剪、裁剪后级联压缩、压缩后再接模型重写，以及向量化 RAG 检索。这些方案共同面临一个核心困境：
在固定的 Token 预算内，缺乏通用的先验判据来决定哪些信息可以被安全丢弃。
用户后续的指令关联范围无法预判。一次看似无关紧要的失败尝试，往往是防止模型重复试错的负证据；一段被摘要抹去的工具调用细节，恰好是定位执行边界的关键依据。一旦将原始信息从持久记录中清除，系统便丧失了回溯与再解释的可能。
从“预先裁剪”转向“持久化后按需检索”
面对这一限制，更为稳妥的架构思路是：原始上下文完整落盘存储，按需构造模型可见窗口。
两种思路的工程前提截然不同：
- 预先裁剪：假设系统能够实时判断信息的长远价值，在不可逆的状态下做减法；
- 持久化检索：承认实时判断的不确定性，完整保留会话现场，通过显式查询提取当前所需切片。
这使得系统关注点从“如何聪明地删减”转变为“如何构建高效的召回链路”。承认预先取舍的局限，转而依赖结构化调取机制，系统的容错率更高。
结构化上下文系统：OpenViking 的分层抽象
字节跳动的 OpenViking 将自身定义为面向 Agent 的 Context Database。其核心价值在于将扁平的向量检索升级为接近文件系统的层级抽象：将记忆（Memory）、资源（Resources）和技能（Skills）组织成显式目录树，通过 L0/L1/L2 的分层摘要进行递归展开与渐进式披露。
相比传统打平后做向量相似度匹配的 RAG 黑盒，这种分层结构让上下文的组织路径具备了可观测性与可调试性。排查上下文缺失时，开发者能清楚定位信息处于哪一层级与检索节点。
实时主链路与深度检索链路的解耦
在 Pickel-Agent 的设计中，最终没有让 OpenViking 全量接管实时主会话上下文，主要出于以下工程权衡：
- 意图路由开销：分层检索需要精确的意图识别与查询规划，在单轮会话中额外增加路由判断会引入不确定性；
- 实时交互延迟：分层摘要与递归检索在主链路中带来显著的时延放大，严重影响对话流的响应性能；
- 调试归因困难：混合方案同时包含本地窗口策略与外部检索机制，导致状态边界模糊，增加了 Badcase 归因难度。
通用框架如果试图在单条链路内兼顾极端实时性与深度持久化，往往会带来不必要的抽象开销。
快慢双轨架构设计
因此，Pickel-Agent 采用快慢双轨结构：
- 本地轻量窗口（Fast Path）：负责实时交互，维护当前轮次所需的最小滑动上下文，保障端到端低时延；
- 外部上下文系统（Slow Path）：封装为标准
Skill，供 Agent 在需要深度召回（如跨会话追溯、用户长期偏好对齐、知识库长文本挖掘）时主动调用。
快慢解耦避免了单一框架通吃所有场景引发的架构臃肿，让渐进式披露与分层检索仅在适合慢思考的场景中触发。
上下文沉淀与版本化：Git for Context
OpenClaw 与 Hermes 所探索的技能提炼、模式沉淀与行为演化，更适合在外部上下文层中异步完成。该层天然具备完整的对话轨迹、工具调用日志与统计特征，利于离线运行模式识别与 Skill 提取。
进一步的演进方向是为 Agent 上下文引入类似 Git 的版本控制机制：对会话状态、提炼的 Skill 以及外部资源实现提交、差异比对（Diff）、分支与回滚。使上下文不再只是临时装配的 Prompt 文本，而是演变为可审计、可演进的系统级状态底座。
总结
- 上下文裁剪属于不可逆的有损操作，在复杂长程任务中容易造成关键约束丢失；
- 采用“完整存储 + 按需投影”替代“预先裁剪压缩”，保证系统具备回溯与再归因能力；
- 建立快慢双轨机制：轻量本地滑动窗口服务于实时对话，外部结构化上下文服务于深度召回与经验提炼；
- 引入版本控制思维，推动 Agent 上下文向可追溯、可审计的状态基础设施演进。