为什么Occamy-1.0能在262K长上下文下不“失忆”？长时程连续性机制拆解

Occamy-1.0 是 Accio-Lab 开源的 35B 总参数 / 3B 激活参数的 co-work Agent 模型，原生支持 262,144 tokens 的长上下文窗口。长对话、多轮工具调用、文件与 API 结果不断堆入历史时，多数模型会“越聊越懵”——忘记最初的目标、丢步骤、重复调用工具。而 Occamy-1.0 正是针对这类长时程任务训练的，本文带你拆解它不“失忆”的四层机制：长上下文基座、混合注意力架构、高经济性 MoE，以及专为长时程执行的训练配方。

在 Claw-Eval、WildClawBench、AutomationBench、GDPval 四个 co-work 基准的汇总对比中（上图为 assets/aggregate-cost-performance.png），Occamy-1.0 位于经验 Pareto 前沿的“低成本拐点”附近：相比其起点 Qwen3.6-35B-A3B，能力大幅提升，单任务推理成本却只有小幅变化。

一、先看问题：Agent 场景的“失忆”是怎么发生的

普通问答模型只需要答对一个问题；而 co-work（协同工作）任务是有状态的：搜索、写代码、调 API、操作文件，几十上百步连续执行。此时“失忆”通常表现为：

• 🎯 忘记最初目标，开始做“看似合理但跑偏”的事；
• 🔁 重复调用同一个工具，或引用已失效的中间结果；
• ✂️ 上下文被压缩（compaction）后，关键约束（如用户偏好、硬性要求）丢失。

Occamy-1.0 的应对不是单一 trick，而是“架构 × 训练 × 使用约定”三层配合。

二、机制 1：262,144 tokens 的原生长上下文基座

Occamy-1.0 从 Qwen3.6-35B-A3B 检查点起步，保留其完整架构，262,144 tokens 是架构原生的上下文上限，而不是训练时硬撑出来的数字：

关键参数	数值	出处
max_position_embeddings	262,144	config.json
num_hidden_layers	40 层	config.json
SFT 训练序列长度	131,072 tokens	README.md

也就是说，模型在训练阶段就见过 128K 量级的超长轨迹，部署时把窗口开到 262K（SGLang 示例参数 --context-length 262144、vLLM 的 --max-model-len 262144，见 README.md 第 5 节），是“架构内插值 + 训练覆盖”共同保证的可靠区间，而不是外推赌博。

三、机制 2：线性注意力 + 全注意力混合，长上下文不“爆内存”

真正让 262K 窗口“用得起”的，是它的混合注意力设计。翻看 config.json 的 layer_types 字段可以发现一个非常规整的排布：每 3 层 linear_attention（线性注意力），插 1 层 full_attention（全注意力），由 full_attention_interval: 4 控制。

这种“3+1”结构是典型的成本—精度权衡：

• 线性注意力层：状态是固定大小的递归状态，不随序列长度线性膨胀，负责“顺流而下”地压缩传递历史信息，让长序列的显存和计算开销保持可控；
• 每第 4 层的全注意力层：保留完整的全局访问能力，随时可以“回头看”任意早期 token，锚定关键事实，防止信息在递归压缩中被稀释丢失。

换句话说，线性层管“跑得快、装得下”，全注意力层管“找得回、记得准”——这正是长上下文不“失忆”的架构根基。此外，rope_theta: 10000000 的大频移 RoPE 配合 0.25 的 partial_rotary_factor，也进一步支持了超长位置编码的稳定性。

四、机制 3：35B 总参数 / 3B 激活的 MoE，长上下文推理“负担得起”

长上下文不“失忆”的前提是你愿意真的把长历史喂进去。传统稠密模型每多一个 token 都要完整 35B 参数前向一遍，长窗口成本指数级痛感；Occamy-1.0 采用混合专家（Mixture-of-Experts）：

• 256 个专家，每个 token 只路由激活 8 个专家 + 1 个共享专家；
• 实际单 token 激活参数仅约 3B，推理开销接近小模型；
• 35B 的总参数量则保证了知识容量上限。

效果就是开头那张 Pareto 图：它落在“每任务成本约 0.06 USD”的低成本拐点，而性能追平了一倍以上的更大模型。对普通用户意味着——跑长会话、长 agent 任务的电费账单，不再是劝退理由。

五、机制 4：训练配方专为“长时程连续性”设计

架构只解决“能不能装”，训练才解决“装进去之后还认不认账”。README.md 第 4 节给出了 Occamy-1.0 的分阶段训练流水线：

Qwen3.6-35B-A3B
  ├─ Marathon Expert: SFT → HDPO ┐
  └─ Sprint Expert: SFT          ├─ 均匀合并 → SAO → Occamy-1.0

• Marathon Expert（马拉松专家）：专注“持续执行”——长时程交互数据平均轨迹长度达 95.8K tokens（88.4M tokens），并通过精度条件化的效率优化（HDPO）学会在长跑中保持准确率；
• Sprint Expert（短跑专家）：保留更广泛的通用 agent 能力，防止长跑特化导致“偏科”；
• 均匀合并 + SAO：两个专家在参数空间直接合并为一个检查点（无推理期路由/集成开销），再用单轨迹异步优化（SAO）在 co-work 混合任务上收尾。

同时，官方明确将“跨工具调用、委托执行、上下文压缩（context compaction）后的历史重写仍保持连贯”列为核心设计目标——也就是说，被压缩的历史摘要本身也是模型被反复训练的对象，压缩不再是失忆事故的高发区。

六、使用侧约定：保住“执行上下文”才能发挥机制

再强的模型也需要正确的使用姿势，Occamy-1.0 在 README.md 第 6 节给出了一条关键约定：

多轮 agent 运行时，保留服务端返回的完整 assistant 消息（含推理内容与工具调用），再按标准 OpenAI schema 追加工具结果。

这条约定落在聊天模板层：chat_template.jinja 中，preserve_thinking 参数控制历史轮次的 `