为什么Raven的Curator上下文管理值得学习Agent驱动的上下文工程方案【免费下载链接】RavenThe Harness of Harnesses: a trusted, persistent, self-evolving multi-agent ecosystem for all-domain collaboration.项目地址: https://gitcode.com/gh_mirrors/raven35/RavenRaven 是一个可信、持久、可自我进化的多智能体开源生态而它内部的Curator上下文管家是一套 Agent 驱动的上下文管理方案当对话变长、上下文窗口面临挤爆压力时它会自动整理历史消息让主 Agent 始终在有限预算里拿到最关键的信息。本文将从原理、机制到可落地的工程思路带你拆解这套被很多开发者称为教科书级的上下文工程实践。1️⃣ 为什么上下文管理是 Agent 的头号难题任何用过 AI Agent 的人都会遇到同样的烦恼对话越聊越长历史消息不断膨胀逼近模型的上下文窗口上限Token 成本失控每次都把全量历史塞给大模型账单越来越疼关键信息被稀释简单截断丢掉的不只是废话还有用户早先给的约束和决定。常见的粗暴解法各有硬伤直接截断会丢信息有损摘要压缩后原文再也回不来。Raven 的 Curator 给出了第三条路——让一个专门的内部 Agent 来编辑上下文但所有决策都要通过确定性代码校验。2️⃣ Curator是什么不回答用户的幕后编辑在 Raven 的上下文引擎里整个系统提示词由 6 个有序 Segment 组成而 Curator 就是第 6 段Segment 6它同时产出两样东西注入系统提示词的# Curator Working State工作笔记经过预算裁剪后的历史消息*history。关键设计是Curator 是一个有边界的内部 Agent 循环它从不回答用户、从不执行面向用户的工具。它只有三件事可做——检查紧凑的清单Manifest、归档/检索消息、提交一份结构化的上下文计划ContextPlan而最终由确定性的装配器校验并真正组装消息。这个LLM 出主意、代码做决定的分层是整套方案最值得学习的骨架。3️⃣ 快慢双通道只在有压力时才花 LLM 的钱Curator 的处理流程分为 Fast Path快速通道和 Slow Path慢速通道判断依据是一行配置阈值默认 0.603.1 快速通道不拥挤时直接放行当历史总 token 数低于可用历史预算 × 0.60时Curator零 LLM 调用历史消息原样通过。这意味着日常短对话完全不付出任何上下文管理的额外成本。相关逻辑见 CuratorSegmentBuilder.build阈值配置在 ContextConfig。3.2 慢速通道小模型编辑上下文一旦历史超过压力阈值Curator 才启动一个最多 12 步的有界 Agent 循环用一个便宜的小模型可通过context.curator_model单独指定默认跟随对话模型完成编辑工作。它手里有 8 个专用工具工具作用curator_search_history在紧凑清单里按关键词/相关度搜索不加载全文curator_check_budget检查候选方案是否超出 token 预算curator_archive_messages把旧消息无损归档到磁盘curator_retrieve_archived按引用取回已归档内容可限 token 上限curator_read_memory读取长期记忆与工作笔记curator_set_relevance更新消息的相关度元数据curator_update_working_state更新目标、未决线索、已做决定curator_build_context提交最终计划必须是最后一步注意最后一步curator_build_context提交的计划不是直接生效而是由确定性的装配器校验——超预算、消息结构破损比如孤立的工具返回都会被打回并告知retry_allowed。LLM 只负责提议正确性由代码兜底。4️⃣ 三大核心机制让整理既聪明又安全4.1 Manifest 清单不读全文只读索引慢速通道从不直接面对庞杂的历史全文而是先由 Curator 为每条消息生成一个紧凑的元数据索引ManifestItemtoken 数、240 字符摘要、16 个以内关键词、相关度评分以及 protected受保护、pinned钉住、archived已归档三个状态标志。相当于给 Agent 一本目录而不是塞给它一整本书。4.2 Archive 归档无损逐出字字可回被编辑出窗口的旧消息不会被删除而是原文逐字写入磁盘默认在memory/.curator/archive按日期分目录并留下一个引用archive_ref。之后 Curator 需要时可以用curator_retrieve_archived按字取回。这与有损压缩Consolidation形成本质区别归档什么都不丢。4.3 Working State把被逐出的事实留在视野里Curator 还会维护一份提炼版会话笔记当前目标最多 8 条、未决线索最多 12 条、已做决定最多 20 条注入主 Agent 的系统提示词中。这样即使原始消息被移出窗口关键事实依然在场——Agent 不会忘了用户早先答应过什么。5️⃣ 安全网Pinned、受保护消息与确定性兜底上下文工程最怕好心办坏事——把不能丢的消息丢了。Curator 用三层保险化解Pinned钉住那些 Agent无法自行重新推导的指令性内容如默认钉住的子 Agent 编排指南local/subagent-dag-orchestration会被整轮工具交互钉住无论计划是否提到都会自动加入、归档时会被拒绝、预算裁剪时最后才动。同一个技能重新读取只会移动钉位而非叠加第二份pinned_message_ids。️Protected受保护会话开头的前 3 轮protect_first_n免于预算裁剪守住任务起点。Fail-Safe 兜底如果慢速通道出错或产不出合法计划立刻退回到纯确定性方案——受保护消息 相关度前 12 条 最近 16 条全程不调用 LLMfallback_plan。而且每一步都留痕每个回合的决策都会写入 trace 日志curator_start、fast_path、slow_path_accepted、fallback等事件出问题时可以直接复盘当时为什么这么裁剪。6️⃣ 我们能从 Curator 身上学到的 5 条上下文工程思路先验证后生效LLM 出计划确定性代码做校验把正确性从概率世界拉回规则世界快慢分流90% 的低压力回合零成本放行只在真正拥挤时才启动昂贵的整理流程无损归档代替删除逐出窗口的消息落盘可回溯忘记变成暂时看不见蒸馏 Working State用有上限的笔记目标/线索/决定补偿被逐出的信息给管家配个便宜模型整理是家务curator_model可单独指定小模型不占主模型的预算与配额。7️⃣ 上手路径从代码到测试想深入阅读这套 Agent 驱动的上下文管理实现推荐按以下顺序核心实现归档、清单、8 个工具、装配校验raven/context_engine/curator.pySegment 6 接线与快慢通道入口raven/context_engine/segments/curator.py统一上下文装配流水线raven/context_engine/assembler.py预算裁剪器raven/context_engine/history_trimmer.py相关配置项阈值、保护轮数、钉住技能等raven/config/raven.py术语定义Curator、Manifest、Archive、Fail-Safe 等CONTEXT.md行为测试适合当活的文档读tests/test_curator_context_engine.py如果想动手实验克隆仓库后即可运行相关测试观察快慢通道的行为差异git clone https://gitcode.com/gh_mirrors/raven35/Raven一句话总结Raven 的 Curator 证明了上下文管理不必在昂贵的大模型总结和粗暴截断之间二选一——用有边界的内部 Agent 做判断、用确定性代码做把关、用无损归档做后悔药才是长对话 Agent 真正可落地的上下文工程方案。【免费下载链接】RavenThe Harness of Harnesses: a trusted, persistent, self-evolving multi-agent ecosystem for all-domain collaboration.项目地址: https://gitcode.com/gh_mirrors/raven35/Raven创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考