【免费下载链接】AxisAgenticAxisAgentic: An Extensible Runtime and Trajectory-Collection Framework for Long-Horizon Agents.项目地址https://gitcode.com/gh_mirrors/ax/AxisAgentic点击查看免费下载跑多轮搜索、抓取、推理的长时程任务时长上下文 Agent 最容易栽在两个坑上上下文越滚越长关键事实被“淹没”而遗忘窗口快满时模型被迫截断或胡言思路直接跑偏。AxisAgentic 是一个面向长时程 AI 智能体的可扩展运行时与轨迹采集框架它用两套互补的上下文管理策略来正面解决这两个问题上下文压缩context_compression定时把旧对话摘要成结构化状态块Discard-All 在 token 用量逼近窗口上限时清空全部工具调用历史、干净重启任务。下面用尽量少的代码讲清楚这两个机制的原理、差异和配置方法。一、为什么长上下文 Agent 会“失忆”长任务比如 BrowseComp 这类多轮网页搜索基准中Agent 每一轮都会把搜索/抓取结果塞进对话prompt token 数量持续攀升。后果有三层关键信息被稀释几百轮之后模型对“已经确认的事实”和“已排除的候选”记忆模糊开始重复搜索、反复改口撞上限prompt 超过模型 context window请求被拒或触发finish_reasonlength任务直接失败注意力跑偏临近窗口上限时模型质量普遍下滑答案开始漂移。AxisAgentic 的做法是让“模型实际可见的上下文”与“完整轨迹日志”分离轨迹日志_full_conversation始终只追加append-only一条消息都不删保证回放、评估和 SFT 导出时能精确重建每一轮模型看到的上下文真正发给模型的 prompt 则由若干**运行时标记marker**重放生成——压缩和丢弃都只记录为标记而非破坏性删改历史。这套契约集中在 agentic/contracts/markers.py整体架构见 docs/architecture.zh-CN.md。二、机制一上下文压缩Context Compression——定时摘要旧事变“状态板”上下文压缩是“软管理”每隔 N 轮 assistant 输出把中间段的旧对话交给一个专门的摘要 LLM压缩成一份结构化状态总结插回对话里顶替那些旧消息最近 N 轮和系统提示 任务描述则原样保留。2.1 三段式切分历史管理器 ContextCompressionManager 会把可见对话切成三段片段内容处理方式prefix开头 system 消息 第一条 user 消息任务描述永不压缩earlier中间的旧对话摘要压缩recent最近recent_window轮约 2 倍条数消息原样保留对应源码逻辑在 _split_history。2.2 摘要不是“读后感”而是九栏状态板很多项目的压缩只是让模型“总结一下”结果摘要质量参差。AxisAgentic 的摘要工具 ContextCompressionTool 用一套严格的系统提示强制模型按九个固定键输出 JSON 状态块confirmed_facts已确认事实必须附来源和置信度current_hypothesis当前假设rejected_paths已排除的搜索路径dismissed_candidates已放弃的候选答案open_questions未解决的阻塞点answer_attempts正在冲刺的最终答案候选conflict_candidates互相冲突的候选值search_state搜索策略与覆盖进度retry_policy需要重试/改写的路径提示词还特别强调不能把猜测写成确认事实、不能复制原始推理链、重复搜索要合并成策略行——这正是防“遗忘”和防“跑偏”的关键新上下文里只保留决策必需的信息且每条都带证据状态。2.3 滚动更新previous_summary 接力每次压缩都会把上一次的摘要作为previous_summary传入新摘要 旧状态 新对话增量合并见 maybe_compress。这样即使任务跑了几百轮状态板始终是一份“当前最新的全量认知”而不是不断叠加的历史包袱。2.4 关键参数配置位于 recipe/web_search/configs/default.yamlagent: context_compression: enabled: false # 默认关闭高预算长任务建议开启 interval: 10 # 每 N 轮 assistant 输出触发一次 recent_window: 10 # 最近 N 轮原样保留只压缩更早部分 llm: base_url: null # 摘要模型端点可另配小模型降本 model_name: null api_key_env: COMPRESSION_LLM_API_KEY经验上当max_turns调到 650 之类的高预算档位时官方建议同时开启压缩见 default.yaml 中的注释避免长 rollout 一路滚进上下文上限。三、机制二Discard-All——token 逼近上限干脆清空重启如果说压缩是“定期大扫除”Discard-All 就是“断舍离”一旦观测到的 prompt token 用量超过上下文窗口的某个比例就丢弃全部工具调用历史只保留 system 提示 原始问题让模型从干净上下文重新开题。这个策略对齐了 DeepSeek-V3.2 / Kimi K2.5 / Qwen3.5 在 BrowseComp 上的公开做法见 discard_all_manager.py 模块说明。3.1 触发条件看真实 token 用量而不是估数DiscardAllManager 是无状态策略器触发逻辑只有三条should_trigger模型服务返回的最近一次 prompt token 数trigger_ratio× context window默认 0.80距上次重置至少间隔min_turns_between轮默认 3防止“前缀本身逼近阈值”时反复空重置可见对话必须比前缀多有内容可丢否则不触发。因为依赖 provider 上报的真实用量Discard-All 要求配置model.context.limit_detection: provider_error两者互斥校验在配置加载时 fail-fast。3.2 重置时保留了什么✅ 全部 system 消息 第一条 user 消息任务本体❌ 其余所有 assistant / tool 消息注意这同样不是物理删除——运行时只是追加一个discard_all标记build_discard_all_marker重放时把可见对话截断到前缀长度。完整轨迹原封不动SFT 导出与线上看到的 prompt 保持逐字节一致。3.3 配套护栏max_tool_calls 全局上限Discard-All 配置还带一个max_tool_calls默认 1800DiscardAllConfig跨整个 attempt 的工具调用总闸不因重置而清零。撞线后强制模型输出最终答案而不是硬终止——保证再长的任务也有体面的收尾。编排器侧的执行与日志见 orchestrator._maybe_apply_discard_all。四、两种机制怎么选维度上下文压缩Discard-All触发时机每 N 轮默认 10prompt token 超过窗口 80%对历史的态度摘要保留认知状态全部丢弃、干净重启额外成本每次触发一次摘要 LLM 调用无额外 LLM 调用知识保留好结构化状态板差依赖重新搜索依赖条件需配置摘要端点需 provider 上报真实 token 用量适用场景长预算、希望“记住”窗口有限、宁可贵一点重复搜索新手建议窗口较大如 256K且任务允许长跑 → 先试context_compression成本是每 10 轮一次小模型调用窗口偏小或端点 token 上限严格 → 用discard_all零额外调用代价是重启后重新搜索两者互斥只能开一个配置层强制校验都没开默认状态时运行时也有兜底generation_limit_recovery 会在撞上下文限制时回滚重试或重试任务空答案兜底empty-finalization始终开启。五、配套的“水位计”Context Length Tracker两个机制背后还有一个共同的底层设施——ContextLengthTracker。它维护可见对话的增量 token 估计支持cheap按字符估算 增量累加等多种 estimator并用 provider 上报的input_tokens在线校准比例消息逐段追加回滚rollback时可精确回退估算值保证回滚、压缩、重置三种操作下的计数一致。也就是说无论运行时当前处于“完整历史”“压缩后”还是“重置后”的状态发给模型的 prompt 长度始终有账可查。对话状态机本体在 agentic/conversations/conversation_runtime.py行为测试覆盖在 tests/test_context_compaction.py 与 tests/test_discard_all.py可以对照阅读验证机制细节。六、上手清单复制配置cp recipe/web_search/configs/default.yaml my-search-run.yaml按第二节或第三节选择一种机制把enabled改为true并核对interval/recent_window或trigger_ratio用 dry-run 校验配置python -m recipe.web_search.runners.run_eval_config \ --config my-search-run.yaml --dry-run跑完后在任务日志里搜[ContextCompression]与discard-all reset关键字确认触发节奏是否符合预期更完整的参数说明见 docs/configuration.zh-CN.md 与 docs/getting-started.zh-CN.md。写在最后长上下文 Agent 的“不遗忘、不跑偏”不是靠一味堆大窗口解决的。AxisAgentic 的答案是把上下文管理做成可观测、可回放、可选策略压缩机制用九栏状态板保住认知Discard-All 用干净重启兜住上限两者共用同一套只追加轨迹契约——模型看到什么轨迹就记什么。理解这两套机制也就理解了当前长时程 Agent 工程里上下文治理的主流思路。赞分享【免费下载链接】AxisAgenticAxisAgentic: An Extensible Runtime and Trajectory-Collection Framework for Long-Horizon Agents.项目地址https://gitcode.com/gh_mirrors/ax/AxisAgentic点击查看免费下载相关推荐Firecrawl Web Agent长任务不丢记忆的秘诀上下文压缩Compaction机制详解Firecrawl Web Agent长任务不丢记忆的秘诀上下文压缩Compaction机制详解 web agentFirecrawl Web AgenOpenClaw 如何理解并调整会话压缩 Compaction让长对话不超上下文OpenClaw 如何理解并调整会话压缩 Compaction让长对话不超上下文 每个模型都有上下文窗口context window即一次能处理的最大AI 应用AI Agent交互助手后端即时通讯网关ok-ww 鸣潮后台自动战斗指南一键日常声骸刷取简单教程实现后台挂机ok ww 鸣潮后台自动战斗指南一键日常声骸刷取简单教程实现后台挂机 ok wwok wuthering waves是一个基于图像识别的开源鸣潮自动化GUI 自动化计算机视觉RPA人工智能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考