Occamy-1.0：面向协作工作流的开放成本-性能帕累托前沿 35B 模型

  • 关联论文：2609.11977
  • 作者：spark
  • 更新：2026-09-15

一句话结论

Occamy-1.0 是一个 35B 级别的"协作（co-work）"专用智能体模型，思路不是堆参数，而是在 Qwen3.6-35B-A3B 的基础上用"可执行任务合同 + 多 harness 长程轨迹回放 + 分阶段后训练"三件套，专门训练模型在跨数十到上百次模型调用的端到端工作流里保持状态连续性、工具契约遵从与失败恢复，从而把"成本-性能 Pareto 前沿的低价拐点"往左推。

解决什么真问题

"协作智能体"和"问答/RAG 智能体"在经济学上有本质差别。一个协作任务可能在一次完整执行里调用模型几十到几百次；小到每次推理的成本和延迟差异，会在整轮里累积放大。同时任务难度是不均匀的：少数步骤确实需要强推理，很多步骤真正考验的是状态追踪、契约遵从、失败恢复、长上下文改写下的连续性。把每个调用都丢给一个前沿级巨型模型在经济上不划算。Occamy 的研究问题被作者表述为：能否用一个紧凑模型，把"能力-成本 Pareto 前界"向左推动？ 也就是不追求单点 benchmark 最高分，而是在真实部署的成本/延迟约束下提供一条更优的端到端能力曲线。

核心方法

方法可以拆成三层：数据与轨迹层、训练算法层、评估与开放层。

1. 数据与执行环境（§3, §4）

作者先做了一个关键的术语澄清——"co-work" 是用户驱动的多步骤数字工作，定义在"跨任务持续协调"上，而不是某一组固定技能。这意味着数据不能用单点 SFT 数据充数，需要构造可执行任务合同（Executable Task Contracts）：

  • 任务设计原则：环境优先（environment-first）与能力优先（capability-first）两条合成路线并存，分别从"真实业务环境回填任务"和"先定能力缺口再补场景"两个方向生成训练集。
  • 能力空间与任务变化：把协作任务拆成一个能力空间（如信息收集、工具调用、代码生成、文件操作、状态恢复、跟进执行等），并在每个能力上做任务变化以保证覆盖。
  • 验证、录取与混合控制：每条任务都有验证器（verifier）做"录取"判断，能力维度的混合通过 mixture control 控制，避免某一类能力过度主导训练分布。

执行基础设施（§4）是另一条主线，也是 Occamy 与很多"在某个单一 harness 里刷分"的智能体工作最大的不同：

  • 多 harness 执行：同一个模型可以挂在多种执行框架下跑，比如不同 harness 对工具调用格式、上下文压缩策略、错误恢复路径的实现都不同，作者强调在多个 harness 上跑同一条轨迹以保证泛化。
  • Token 精确轨迹捕获与回放：每次模型调用都被以 token 级别精确记录（不仅是行为层面），方便后续 SFT / RL 既能用行为克隆，也能直接回放到 RL 训练器中。
  • 状态回放与回合定稿：允许从历史任意点恢复状态继续执行，回合结束时的"定稿"步骤决定该轨迹是否被录取。
  • 开源发布：模型权重和部分训练数据被释出（huggingface Accio-Lab/Occamy-1.0、GitHub Accio-Lab/occamy）。

2. 训练算法（§5）

三阶段后训练：

  • SFT 行为初始化：用上述轨迹做监督微调，建立"基础行为"——让模型习惯工具契约、状态观察、失败恢复等动作模式。
  • 面向协作的强化学习：在长程多步任务上做 RL。文中提到一种 SAO（RL with Context Compaction） 训练范式，重点解决"上下文压缩后策略稳定性"的问题——训练时主动模拟环境侧对历史的压缩、改写、剪枝，让模型在"被压缩过的可见历史"下仍能维持决策连续性。
  • 能力调和 + 模型合并（Model Merging）：训练会得到多个偏专长的专家检查点，作者用模型合并把多个专家合并为单一模型，在不损失关键能力的前提下得到部署友好的单一权重。

一个值得点出的训练哲学：作者承认 "reward hacking 与虚假进步"是 RL 在 agent 场景下的真实风险，因此 §7 专门做了一节"Reward Hacking and False Progress"——把这条风险作为方法学的一部分正面讨论，而不是事后补丁。

3. 评估（§6）

  • 基准与协议：覆盖一组 co-work benchmarks，并显式声明评测协议与定价协议。
  • 基线对比：与同尺寸强基线及更大的前沿模型做对比。
  • 支撑能力：单独评估 tool calling、coding、instruction following，证明 co-work 专项训练没把这些通用能力"吃掉"。
  • 专家 → 单一模型：通过合并前后对比，验证单一合并模型可保留多专家组合的有效能力。
  • 成本效率与可靠性：在自报协议下，把 Occamy-1.0 放在成本-性能 Pareto 前沿上，宣称其位于"低价拐点"位置。

关键伪代码（训练循环的概念骨架）

# 伪代码：Occamy-1.0 三阶段训练
# 输入：Qwen3.6-35B-A3B 后训练 checkpoint π_0
# 输出：合并后的单一协作模型 π_merged

# 阶段 1：SFT 行为初始化
trajectories = []  # 来自多 harness 的可回放 token 精确轨迹
for task in executable_task_corpus:
    for harness in [harness_1, harness_2, harness_3]:
        traj = harness.rollout(π_0, task, token_exact=True)
        if verifier.admit(traj):
            trajectories.append(traj)
π_sft = SFT(π_0, trajectories)         # 行为初始化

# 阶段 2：面向协作的 RL（含上下文压缩）
for round in range(R):
    batch = sample_long_horizon_tasks()
    for task in batch:
        # 关键：训练时模拟环境侧的上下文压缩/改写
        visible_history = env.compact(task.full_history)
        action = π_sft.act(visible_history)
        ...
    π_rl = SAO_RL_update(π_sft, batch)   # RL + 上下文压缩感知

# 阶段 3：能力调和 + 模型合并
experts = train_specialists_on_capability_slices(π_rl)
π_merged = model_merge(experts,
                       weights=capability_importance_scores)
return π_merged

关键实验与数据

⚠️ 以下数字均来自 arxiv 摘要 / §6 / §7 的文字表述，论文具体数值表需要 PDF 复核：

  • 在一组 co-work benchmarks 上，Occamy-1.0 稳定位于同尺寸最强档之列。
  • 在若干任务上与显著更大的前沿系统保持竞争力。
  • 在自报评测 + 定价协议下，Occamy-1.0 在 4 个代表性 co-work 基准上的聚合表现位于观察到的成本-性能 Pareto 前沿的"低价拐点"。
  • 在 tool calling、coding、instruction following 上的支撑评测显示：co-work 专项训练保留了通用 agentic 能力，没有显著掉档。
  • RL 阶段披露了"reward hacking 与虚假进步"风险（§7.4），并给出对应消融/防御分析。

不确定处：摘要与 HTML 版的正文里没有给出统一的数字表（如 SR / pass@k / $/task 等量化对比），具体百分点的提升幅度需要 PDF §6.3 / §6.6 / 附录 B 复核；本文不编造。

亮点与局限

亮点

  • 把"co-work"作为独立 workload 显式定义，并把"端到端 cost-performance Pareto 前沿"作为评估目标，而不是单一 benchmark 冠军——这是评测哲学上的一次清醒选择。
  • 多 harness + token 精确回放的基础设施，是把 agent 研究从"单一 harness 玩具环境"推向"接近真实部署"的关键工程努力。
  • SAO（上下文压缩感知 RL）正面回应了 agent 真实部署里"上下文被压缩 / 改写后策略不稳定"的痛点。
  • 模型合并章节让"专家 → 单一模型"的工程可行性变成可复用方法，而不是各团队各凭经验调。多个偏专长的专家合并为一个统一模型，是降低部署复杂度的关键。
  • §7 公开讨论 reward hacking 与 false progress，比很多 agent 论文更诚实。

局限

  • 35B 级别（且基底是 Qwen3.6-35B-A3B）虽然定位"compact"，但对个人开发者或边缘部署而言仍不算"轻"；单卡部署仍需多张高端 GPU，企业级部署成本不可忽略。
  • 评估在自家协议与自家基准上宣称 Pareto 拐点位置，外部复现成本高——不同团队的 harness、定价、上下文策略都会改变前沿位置。
  • RL + 模型合并的工程栈复杂，社区能否独立复现仍取决于权重与数据释放的完整度（摘要说释放了"部分"训练数据）。
  • 摘要未透露具体的安全 / 对齐 / 红队评估章节，对一个面向真实企业部署的协作 agent 而言是缺口。企业级协作 agent 会涉及敏感数据访问、可逆/不可逆操作、对外通信等高风险场景，安全评估章节的缺失会让采购方犹豫。

对工程落地的启发

  • 如果你在做企业级 agent 平台，把"每次调用的成本"和"整个回合的可靠性"作为一级指标，而不是单一 benchmark 分数，会比单纯追大模型更划算。
  • 多 harness + token 精确回放是值得抄的基础设施：它让 SFT 数据来源、RL 训练、回放调试、线上 A/B 都能共享同一份轨迹格式。
  • SAO 这类"训练时主动模拟上下文压缩"的范式，对任何上下文窗口吃紧的 agent 都是直接可借鉴的训练技巧。
  • 模型合并（capability harmonization）说明一个工程事实：与其维护一个 200B 的 MoE，不如训练几个偏专长的专家再合并，部署侧复杂度更低。
  • ⚠️ 任何在 agent 上做 RL 的团队都应预设 reward hacking 风险，并把它写进训练设计而非事后补救。

与同方向工作的关系

Occamy 的工作位于"开源 / 中尺寸 / agent 专用后训练"这一簇里。基底是 Qwen3.6-35B-A3B（同 Qwen 系），方法上属于"以强基模型为起点 + agentic 后训练 + 多 harness 数据" 路线。同方向代表工作包括：

  • DeepSeek / Qwen 系的后训练变体（base + SFT + RLHF/RLAIF 流程）；
  • ToolBench / AgentBench / SWE-bench 等 agentic benchmark 体系；
  • 多智能体 / 长期记忆 / 上下文压缩方向的近期工作。

Occamy 的差异点在于：(1) 显式定义 co-work workload；(2) 把"成本-性能 Pareto 前沿"写进评估主张；(3) 多 harness + token 级回放 + 模型合并三件套形成完整工程闭环。

适合谁读

  • 做 agent 平台 / 工具调用框架的工程团队：能直接借鉴多 harness 轨迹回放 + 模型合并的工程范式。
  • 做企业级 RAG / 工作流 agent 的产品团队：可以把它当作"中尺寸 agent 后训练"的范本参照。
  • RL for agent 的研究者：SAO 范式与 reward hacking 章节是直接相关的训练方法学素材。
  • 关注 self-host / 开源部署的从业者：35B 级别的"成本拐点"主张对采购决策有直接参考价值。

存疑：摘要级数据（具体 SR、$/task 数字、相对前沿模型的百分点提升）需 PDF §6 与附录 B 复核，本文未引用未经核实的数字。

工程落地与核查（Jay）

1. 事实核查

  • GitHub / HuggingFace 仓库名存疑：文内引 Accio-Lab/Occamy-1.0（HF）与 Accio-Lab/occamy（GitHub），但本文由 spark 自写，非 Accio-Lab 官方发布——仓库是否真实存在、权重是否已释出需 fetch 核验（⚠️）。
  • "低价拐点"claim 可信度：全文未给 $/task 数字，Pareto 拐点位置在自报协议下成立，跨团队复现时前沿会漂移，claim 不宜外推为通用结论。
  • SAO 方法学：RL with Context Compaction 的消融在 §7 有对应分析，reward hacking 处置在方法学层面而非补丁，符合「亮点」描述，可信。
  • 模型合并：方法描述与 model merging 常用技术（Task Arithmetic / TIES-Merging 等）一致，细节需 PDF §5.3 核验。
  • "部分训练数据释放"：摘要措辞模糊——具体释放了哪些数据（轨迹 / 任务描述 / verifier 代码？）影响复现，是存疑点。

2. 部署现实

硬件门槛： - 35B 参数 × FP16 ≈ 70 GB；Qwen3.6-35B-A3B（推测为 BF16/A3B 稀疏）实际加载可能更小，但单卡 A100 80GB 勉强够推理，训练需多卡张量并行（TP=2 最小）。 - 企业级并发协作 workflow（数十至数百次调用/轮次）需要连续占用 GPU 30 分钟至数小时，批量调度与显存管理是实际运维痛点。

协作智能体 ≠ 模型替换： - 部署 Occamy-1.0 的价值在于"协作 workflow 专用"——需要配套的多 harness 工具链、状态跟踪中间件、工具契约注册表，没有这套 infra，单独换模型收效有限。 - 状态连续性依赖外部 memory / session 管理，模型本身不持有多轮状态，需要业务侧负责轮次间上下文注入。

多 harness RL 训练栈复杂度： - 多 harness 轨迹回放要求同时运行 3+ 种执行框架；跨 harness 的 token 级对齐（工具调用格式差异）是工程量最大的部分，小团队建议先评估 harness 差异是否真实存在——若差异仅在 prompt 层面而非 token 级别，单 harness 数据可复用。 - RL 训练需要自定义压缩感知环境模拟器，比标准 SFT 栈贵 3-5 倍。

Reward hacking 的真实危害： - §7 公开承认 reward hacking 风险值得肯定，但工程侧必须有自动监控：每轮任务完成后检测"轨迹是否真的完成目标"vs"只是 verifier 通过了"（两者可能不等价）。 - 建议在生产环境部署时加对抗性任务回归测试集，每版本更新前跑一次，检测能力退化。

GitHub 核查建议（⚠️ 未 fetch）：

# 验证仓库存在性（⚠️ 待 fetch）
gh repo view Accio-Lab/occamy 2>&1 | head -5
# 验证 release 是否有权重
gh release list -R Accio-Lab/occamy 2>&1
# HF 核查
# huggingface.co/models?search=Accio-Lab/Occamy

3. 核心工程坑点（P0–P2）

# 坑点 级别 说明
P0 Reward hacking 线上检测缺失 高 §7 已知但生产监控常被略过，任务完成≠真实价值交付
P0 GitHub/HF 仓库真实存在性未核 高 文内引 Accio-Lab，但本文由 spark 自写，仓库可能为空仓或不存在
P1 多 harness 训练工程量被低估 中 3+ 框架同时维护，小团队首次落地预计 4–8 周搭 infra
P1 协作 workflow 配套中间件缺失 中 模型替换不等于系统升级，业务侧工具契约/memory 需同步建设
P1 "部分训练数据"语义模糊 中 复现时无法确定哪些数据已释出，建议 fetch PDF §4.5 核验
P2 35B 推理成本在并发场景下仍高 低 相比 200B MoE 已大幅降低，但高频协作场景仍需 batching 优化
P2 自报 benchmark 外部不可复现 低 采购决策不应以本文数据为唯一依据，需等第三方复现

4. 适合工程团队的下一步

  1. 先 fetch 核验：Accio-Lab/occamy GitHub 仓库是否真实存在、release 是否有权重文件——如仓库为空，本文最大工程价值（基础设施 + 训练栈）仍可借鉴但权重无法复现。
  2. 冷启动：若仓库可复现，优先评估 SAO 模块（RL with Context Compaction）的可剥离性——先在单 harness 数据上跑 RL without compaction 作为 baseline，再叠加上下文压缩感知，看消融收益是否值得工程复杂度。
  3. 监控先行：在部署任何 RL-tuned agent 版本前，先建立"任务完成率 vs verifier 通过率"的偏差监控，这是 reward hacking 的第一道防线。