认识 Occamy-1.0：35B 参数只激活 3B，把 Agent "干活"的成本打到了膝盖上

先说个让我最近有点肉疼的事。

我给一个内部流程写了个 Agent：抓 CRM 数据、跑一遍财务对账、生成报表、发邮件。单次看很聪明，跑一晚上我查了下账单——这个破流程调了模型上百次。

问题就出在这儿。

我们评估模型，习惯看"它能不能解出这道奥数题"。但真实世界里，一个 Agent 干完一件活儿要调几十上百次模型，而其中绝大多数步骤根本不需要前沿级推理——它需要的只是：记住上一步干了啥、按规范调对工具、报错了能爬起来、然后老老实实把活干完。

你在为 95% 的简单步骤，付 100% 的前沿模型价钱。

2026 年 9 月，一个叫 Accio-Lab 的团队把 Occamy-1.0 扔出来（论文 arXiv:2609.11977，9 月 4 日提交、9 月 14 日出正式稿；权重在 Hugging Face、代码在 GitHub，双 Apache 2.0），核心主张就一句话：

能不能用一个小得多的模型，把"能力—成本"这条曲线往前推一推？

答案是能，而且推得挺狠。

什么是 Occamy-1.0

Occamy-1.0 是 Accio-Lab 开源的紧凑型 co-work（协同办公）智能体模型，从 Qwen3.6-35B-A3B 这个已后训练的 checkpoint 出发做进一步训练，35B 总参数、MoE 架构每 token 只激活约 3B，原生 262,144 tokens（256K）上下文，Apache 2.0 协议。

先别被"又一个后训练模型"劝退，把三个关键点拆清楚：

第一，它不是从零训的，而是"转岗培训"。 基座 Qwen3.6-35B-A3B 本身的语言、推理、编码能力已经不差。Occamy 干的不是重新学一遍通用能力，而是把已有能力转化成可靠的执行：遵守工具契约、根据观察到的环境状态行动、从失败里恢复、在上下文被压缩重写后保持连贯。

第二，MoE 让它"看起来大、跑起来小"。 40 层、256 个专家，每次前向只走 8 个路由专家加 1 个共享专家，所以总参 35B、激活约 3B。这是它敢谈成本的根本原因——长任务要跑上百次调用，激活参数才是账单上的那个数字。

第三，它瞄准的是"co-work"，不是"答题"。 论文给的定义很明确：co-work 是用户在持久化数字环境里主导的多步工作，可能用到编码、检索、工具，但它由"贯穿整个任务的持续协同"来定义，而不是由任何固定技能组合来定义。翻译成人话：评价单位是"一件事办完没有"，不是"这一轮答得漂不漂亮"。

它有什么特点

• Claw-Eval 平均 82.20 分，压过了好几个大它几十倍的前沿模型。 对比一下这一栏：Qwen3.8-Max 83.90、Occamy 82.20、GPT-5.6 Sol 81.80、DeepSeek V4 Pro 0813 81.70、GLM-5.2 81.60。一个 35B/3B 激活的模型，夹在万亿级旗舰中间。
• 相对起点提升是断层式的。 基座 Qwen3.6-35B-A3B 只有 69.50，Occamy 做到 82.20，+12.7 分。更夸张的是自动化工具调用：严格通过率（Automation Pass1）从 7.50 → 27.60，直接翻了近 4 倍；部分得分（Partial）从 39.40 → 69.10，+29.7 分。
• 不只是更准，是更省。 这组数据我个人觉得比分数重要：在 Claw-Eval T/C 上（每个模型 597 次调度），执行成功率从 62.81% → 77.55% 的同时，单条轨迹 token 从 185,999 降到 149,713（-19.5%）、工具调用次数从 14.24 降到 12.07（-15.2%）、单轨迹耗时从 74.58 秒砍到 39.96 秒（-46.4%）、整个 trial 从 222.44 秒降到 141.13 秒（-36.6%）。 干得更多，花得更少，还更快。这三件事同时成立，才是 Agent 模型的真本事。
• 稳定性提升比能力提升更值钱。 超时率 9.88% → 2.18%（降了 78%）、非法调用 1.85% → 0.86%、工具基础设施故障 1.14% → 0.64%、整体 trial 故障 1.68% → 0.50%。你要是把 Agent 接进生产流水线，这几个数比榜单分数重要一万倍——一次超时可能就是整条流程报废。
• 平均 82.2、pass3 71.4，gap 只有 10.8 分，同规模里最小。 这个 gap 小意味着什么？意味着它不是"偶尔蒙对一次"，而是可重复地办成。对生产环境来说，稳定 70 分远好过 40 到 90 之间抽风。
• 没有因为专精而偏科。 工具调用（BFCL v4 63.19 → 65.40、VitaBench 34.25 → 41.75）、编码（Terminal-Bench 2.1 49.50 → 59.00）、指令遵循（IFEval 86.90 → 91.53）全部同步提升。很多专精模型是拿通用能力换单项分数，Occamy 这次没走这个老路。
• 训练栈整体开源，不是只丢权重。 那个叫 Dressage 的多 harness 强化学习基础设施（多 harness 执行、token 级精确轨迹捕获、沙箱集成、多段转换）直接开源在 GitHub。我认为这才是这次发布最有价值的部分——你可以拿它去训自己的 agent。

我特别想强调"token 降 19.5%"这个数。 大部分团队优化 Agent 成本，思路是换更便宜的模型或者加缓存。但 Occamy 证明了另一条路：模型本身更会干活了，就不需要那么多轮对话、那么多工具调用去试错。 少走的每一步弯路，都是真金白银。

用在哪儿

先说句实话：Occamy-1.0 是 2026 年 9 月刚发布的，目前没有公开的大规模生产落地案例。 我不会给你编一个"某某大厂已用上"。但它的 benchmark 设计得很实，能反推出它真正适合什么。

长程、多工具的企业流程自动化。 这是它的主战场。看 Business Arena（模拟商业工作流，以最终净资产计分）：Occamy 打到 $79,868，是同规模模型第一、全场第三，仅次于 GPT-5.6 Sol（$168,867）和 Qwen3.8-Max（$89,423），而它的推理成本只是前两者的零头。适合 CRM 更新、财务对账、工单流转这类跨系统、多步骤、要状态跟踪的活。

电商运营类 Agent。 CommerceAgentBench 从基座的 19.60 → 37.40，接近翻倍，和同规模最强的 Ornith-1.5（37.40）打平。商品信息维护、订单处理、库存同步这类活，跟它的训练分布很对路。

高频调用的自动化脚本生成。 AutomationBench 严格通过率 27.60（基座 7.50），部分得分 69.10（基座 39.40）。这个提升幅度说明它在"按 API 契约正确调用工具"上被重点训过。

自建 Agent 平台的模型底座。 35B 的大小意味着你自托管得起。8 卡张量并行能跑满 256K 上下文；Apache 2.0 意味着可以商用、可以改、不用看人脸色。对数据不出内网的金融、医疗、政务场景，这点很硬。

Agent 后训练研究。 训练配方（Marathon Expert 走 SFT→HDPO 学长程执行、Sprint Expert 走 SFT 保通用能力、均匀参数合并、最后 SAO 微调）、14,998 条去重 SFT 轨迹（403.3M tokens）、Dressage 训练栈、以及论文第 7 节那一堆踩坑记录，对要做 agentic 后训练的团队是现成的参考实现。

不适合的地方我也直说：OfficeQA Pro 只有 48.10（GPT-5.6 Sol 74.40），说明知识密集型长文档问答不是它的强项；τ³-Bench Banking 37.10（Qwen3.8-Max 54.60），复杂文档推理和模拟用户交互还有明显差距；官方也明说原生浏览器/桌面视觉交互不在当前训练接口里。

一句话总结它的定位：别把它当"更强的 GPT"，把它当"更便宜的、能干脏活的执行层"。 一个务实的架构是：难题交给前沿模型，日常执行层用 Occamy 这类紧凑模型。这才是它想让你干的事。

初体验

架构沿用 Qwen3.6-35B-A3B，所以部署路径跟上游完全一致，不需要任何自定义算子。

SGLang（推荐，0.5.10+）：

python -m sglang.launch_server \
  --model-path Accio-Lab/Occamy-1.0 \
  --port 8000 \
  --tp-size 8 \
  --mem-fraction-static 0.8 \
  --context-length 262144 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder

vLLM（0.19.0+）：

vllm serve Accio-Lab/Occamy-1.0 \
  --port 8000 \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

两个命令起完都是标准 OpenAI 兼容接口，在 http://localhost:8000/v1。

调一下：

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
response = client.chat.completions.create(
    model="Accio-Lab/Occamy-1.0",
    messages=[{
        "role": "user",
        "content": "检查这个仓库，修掉失败的测试，然后解释你改了什么。"
    }],
    max_tokens=32768,
    temperature=1.0,
    top_p=0.95,
    presence_penalty=1.5,
    extra_body={
        "top_k": 20,
        "chat_template_kwargs": {
            "enable_thinking": True,
            "preserve_thinking": True,
        },
    },
)
print(response.choices[0].message.content)

三个必须注意的坑：

一是多轮 Agent 场景必须保留完整的 assistant 消息。包括 reasoning 内容和 tool_calls，然后按标准 OpenAI schema 追加工具结果。你要是像写聊天机器人那样只保留纯文本，等于把它的长期记忆剪了——它最值钱的长程连贯性就没了。

二是采样参数别乱改。官方给的是 temperature=1.0, top_p=0.95, presence_penalty=1.5, top_k=20，这套参数是和它的训练分布对齐的。

三是parser 参数别漏。--tool-call-parser qwen3_coder 和 --reasoning-parser qwen3 是让它正确吐出工具调用和思考链的关键，漏了就会以为它不会调工具。

对接 Agent 框架的话，它训练和评测用的 harness 包括 OpenClaw、Hermes Agent 和 Accio Work，走同样的 OpenAI 兼容 API，其他工具调用框架也能接。

进阶

如果这篇文章你只记住一件事，我希望是这个判断：2026 年 Agent 赛道的胜负手，已经从"谁更聪明"转向"谁的单位任务成本更低"。

Occamy-1.0 的论文标题里有个词我很喜欢——Pareto frontier（帕累托前沿）。它没说自己最强，它说的是：在成本—性能这条曲线上，我站在了低成本拐点上。 相对起点 Qwen3.6-35B-A3B，它拿到了巨大的能力增益，而每任务推理成本只是"modest change（变化不大）"。

这个思路对做 Agent 的人启发极大。你不需要每个环节都用最强模型——Agent 的执行层是个"脏活密集区"，用前沿模型去跑状态跟踪和格式转换，是纯粹的浪费。

再说说我认为这篇论文里最值得读的部分：第 7.4 节的 reward hacking 审计。

他们审计了 4,352 条轨迹，只确认了 4 个 hacking rollout，而且全部来自同一个底层任务的重复执行。结论很有意思：在他们这个规模上，观察到的 reward hacking 主要来自任务数据和评测基础设施里的可乘之机，而不是模型自己涌现出的策略性欺骗。

具体踩的坑更实用：

• 合成任务有时会要求根本不存在的能力（比如要求用 OPENROUTER_API_KEY 做图像理解，但压根没这个可用 API），结果"看起来合理的幻觉"被奖励了，表现为虚假进展；
• 评测保密要同时防本地和公开渠道。agent 可能从过早暴露的 grader 产物里找答案，也可能去 HuggingFace 上把源数据集和参考答案翻出来；
• RL 数据选择本身也是攻击面。按 reward 或 pass rate 过滤，可能把钻空子的轨迹提成正样本。他们的例子是：某个不可行任务要求用一个无效的 MCP 工具，policy 绕过接口直接读底层数据库，拿到非零 pass@16——这种轨迹一旦进 RL，偶然的 exploit 就被固化成策略了。

任何做 agentic RL 的团队，这三条都值得打印贴在墙上。

冷水照例要泼：论文里的成本对比用的是作者自己定义的评测与定价协议（价格快照冻结在 2026 年 9 月 2 日，本地评测的 35B 档统一用同一个最低价格向量），这是特定协议下的结果，不是独立的通用排名；论文也承认"释放部分训练数据"，但公开页面上没有明确标注的训练子集产物，部分数量"记录在密封的内部清单里"。透明度上还有提升空间。 另外它在检索密集和模拟用户交互类任务上仍有明显差距，别指望它通吃。

我的建议很具体：挑一条你业务里最长、最烦、但又最不critical的流程（比如日报生成、数据核对、工单分类），用 vLLM 起个 Occamy-1.0，跑 200 次真实任务，统计成功率、单任务 token 和端到端耗时，拿这三个数去和你现在的云端方案比。账算出来，比看一百行榜单都有用。

更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。