如何让长上下文Agent不遗忘、不跑偏？AxisAgentic上下文压缩与Discard-All双机制详解-平芜编程栈

【免费下载链接】AxisAgentic

AxisAgentic: 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_reason=length，任务直接失败；
注意力跑偏：临近窗口上限时，模型质量普遍下滑，答案开始漂移。

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.yaml：

agent: 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（默认 1800，DiscardAllConfig）：跨整个 attempt 的工具调用总闸，不因重置而清零。撞线后强制模型输出最终答案，而不是硬终止——保证再长的任务也有体面的收尾。编排器侧的执行与日志见 orchestrator._maybe_apply_discard_all。

四、两种机制怎么选？

维度	上下文压缩	Discard-All
触发时机	每 N 轮（默认 10）	prompt 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 工程里上下文治理的主流思路。