智猩猩 AI 整理

阿里巴巴 Accio 团队投稿

在很多人眼里，OpenClaw、Codex 和 Claude Code 这类智能体及其运行框架，已经能够编写代码、搜索资料、调用工具，甚至处理相当复杂的长程任务。

智能体越有用，我们就越愿意把完整的工作交给它们。但问题也随之而来：任务越来越长，模型调用越来越频繁，额度和预算很快便会见底。

一项完整工作可能涉及几十次甚至上百次模型调用，单次调用的成本与时间延迟，会在整个流程中不断累积。

与此同时，真实工作流对模型能力的要求并不均匀。有些关键环节确实需要高强度推理，但更多步骤是在获取和核验信息、持续跟踪状态、规范调用工具、处理异常，以及检查最终结果。

它们同样重要，却不一定每一步都需要调用规模最大的前沿模型。

当小模型不够用、大模型又太浪费时，问题显而易见：能否通过后训练，让一个更紧凑的模型依然具备端到端执行真实工作的能力，以更低的成本和延迟，把 Co-work 的能力—成本的最优前沿继续向前推进？

阿里巴巴 Accio团队推出并开源了Occamy-1.0。这是一个从 Qwen3.6-35B-A3B 继续训练而来的模型，面向需要跨越多个步骤、持续操作环境并稳定交付结果的长流程 Co-work 任务，从而带来了更高效、完整和可靠的智能体工作流。

它重点强化了几件看似朴素、却决定智能体能不能真正落地的能力：搜索真实可靠的信息，持续跟踪运行状态、规范使用工具、遇到错误进行修正，最终一路把任务推进到完成。

01

35B 规模，站上 Co-work 的

成本效率平衡的前沿

Co-work 与普通问答最大的区别，是一次任务会触发几十甚至上百次模型调用。每一步多花一点 token、多等一点时间，累积到整条工作流上，都会滚雪球累积成巨大的成本。

与此同时，任务里的每一步也并不都需要最大规模模型来完成。很多时候，智能体 更需要的是准确记住状态、选对工具、检查结果，并在失败后继续往下走。

从技术报告给出的 12 项 benchmark 的结果看，Occamy-1.0 已经做到了最好。

在报告的统一评测设置下，Occamy-1.0 在 Claw-Eval 上取得82.2分，高于 GPT-5.6 Sol 的 81.8 和 DeepSeek V4 Pro 的 81.7，接近 Qwen3.8-Max 的 83.9；Pass^3 达到71.4，相比 Qwen3.6-35B-A3B 的 54.8 提升 16.6 分。

在更开放、更长程的任务上，Occamy-1.0 在 WildClawBench 得到49.16，在报告所列同规模模型中领先；在模拟跨境经营的 Business Arena 中，最终净值达到79,868 美元，同规模模型第一、全部参评模型第三。

它也没有因为专攻 Co-work 而丢掉通用智能体能力：AutomationBench 严格通过率从7.5 提升到 27.6，Terminal-Bench 2.1 从49.5 提升到 59.0，IFEval 从86.90 提升到 91.53。

综合 Claw-Eval、WildClawBench、AutomationBench 和 GDPval 四项代表性评测，Occamy-1.0 位于观测到的成本—性能 Pareto 前沿低成本拐点附近：相比 Qwen3.6-35B-A3B，它只付出了幅度不大的单任务推理成本变化，却换来了明显的综合能力提升，并与本次比较中的前沿模型有着显著成本差距。

02

一手实测：它能真正完成

复杂任务吗？

衡量智能体的真实能力，光看榜单远远不够。接下来，通过几条真实或受控的 Accio Work 轨迹，看看 Occamy-1.0 面对信息分散、步骤繁多、状态持续变化的工作时，能不能一路推进，并把结果可靠地交付出来。

一、清洗 5 条候选人记录，只发 1 封邮件

先来看项目网站展示的一次真实运行。

任务要求模型清洗 5 条候选人记录，按照规范化后的邮箱去重，同时保留每条来源数据；完成后只能发送 1 封 Gmail 通知，再验证发送是否成功。

这里真正的难点不是「会不会发邮件」，而是要严格控制外部副作用。发少了，任务没有完成；发多了，又会造成不可逆的重复通知。

Occamy-1.0 先读取任务约束和源记录，生成审计文件；在发送前确认搜索结果为零，随后只发送一次，并检索、回读同一封已发送邮件。

整条轨迹包含27 个事件、7 个产物和 2 次回读。运行过程中，它还修正了两个本地标签错误。最终状态经系统独立验证：只有一次 Gmail 发送，没有重试发送。

二、四份项目记录，不能数错一个状态

在项目状态核对任务中，模型需要读取 Alpha、Beta、Gamma 三个项目的 4 份记录，统计任务状态、保留依赖链、区分不同负责人角色，并把结果写成可审计报告。

Qwen3.6-35B-A3B 虽然也读完了资料并生成报告，却把 Beta 项目的逾期任务少算了一个，还添加了一条没有来源支持的依赖关系；写完之后，它也没有重新读取产物确认结果。

Occamy-1.0 则准确给出 Beta 项目的状态：1 个已完成、2 个进行中、1 个阻塞、4 个逾期，同时保留 609 → 607 和 606 → 608 两条来源依赖链。写入报告后，它又重新打开文件进行核对。

差距不在文笔，而在能否符合标准，并证明自己写下的东西是正确的。

三、12 份 PDF，不只读完，还要整理得能用

再看一个典型的文档工作流。

模型需要处理 12 份 PDF：恢复标题、划分 6 个类别、找出所有与 caption 相关的论文、引用每篇论文 Table 1 中的具体证据，并生成不会重名的新文件名。原 PDF 不能被修改，最终清单、证据表和总结还要全部写入并回读。

两个模型都遇到了 PDF 解析失败，也都尝试切换到 `pdftotext`。Qwen3.6-35B-A3B 最终恢复了 12 份标题和正确的 caption 集合，却继续使用 `paper_02-1.pdf` 这样的不透明命名，并在写完文件后停止。

Occamy-1.0 不仅找全了 01、02、03、08 四篇目标论文，还为每篇保留数据集、方法和分数等 Table 1 证据；面对重复标题，它把标题语义与原始文件编号结合，生成可读、确定、不会碰撞的新名称。最后，模型写入并回读所有产物，同时保证原文件只读。

这更接近人们真正想要的文档 智能体：不是「提取了一些文字」，而是把混乱输入整理成可继续使用的工作成果。

03

Occamy 完成了更多任务，

并少走一些弯路

从几组案例来看，Occamy-1.0 最突出的变化，并不是生成了更华丽的文字，而是三种更接近真实工作的行为：精确核对、失败恢复、交付前验证。

这一点也反映在效率数据上。

在合并后的 Claw-Eval T/C 任务中，相比 Qwen3.6-35B-A3B，Occamy-1.0 的执行成功率从62.81% 提升到 77.55%；与此同时，轨迹 token 减少19.5%，工具调用减少15.2%，轨迹墙钟时间减少46.4%，完整试次耗时减少36.6%。超时率也从9.88% 降到 2.18%，无效调用率从1.85% 降到 0.86%。

04

先造出「真的工作」，模型才可能

学会「真的执行」

Occamy-1.0 是怎么训练出来的？

Accio 团队首先要解决的问题，是训练任务本身能不能真正运行。

如果一个任务要求使用根本不存在的工具，或者评分器只看最终文字、不看 智能体 有没有实际执行，那么低分可能来自环境故障，高分也可能只是模型「说得像做完了」。这样的数据不仅没有帮助，甚至会把错误行为教给模型。

为此，团队把每个任务定义为一个可执行契约，包含四部分：用户请求、初始世界状态、可用工具，以及隐藏的评分标准。请求需要的证据必须真实存在，也必须能通过被允许的工具获得；评分器则要能分辨真正完成、什么都没做，以及只有表面进展的结果。

围绕这一设定，团队采用了两条互补的数据构造路线：一条以已有的环境资源为起点，包括文档集合、代码仓库、软件包和可调用服务，围绕这些环境能够实际支撑并验证的工作设计任务；另一条以从真实工作中抽象出的能力结构及其依赖关系为起点，再寻找独立的数据来源、工具和可执行环境，将这些能力需求重新实例化为新的任务。

两个专家模型使用的去重 SFT 数据最终合计包含14,998 条轨迹、约 4.033 亿 tokens，平均每条轨迹约 2.69 万 tokens。数据既包括超长、多轮、状态持续变化的交互任务，也覆盖工具调用、终端与软件工程等更短的能力训练。

05

上下文可以被压缩，但是已经发生的事

不能被忘记

长流程智能体还会遇到另一个问题：任务可能比上下文窗口更长。

执行框架会压缩、裁剪或重写模型看到的历史，但外部环境并不会随之重置。已经写入的文件仍然存在，已经发送的消息不能当作没发生，之前做出的决定也会继续约束后续操作。

Occamy 的训练 Infra 因此会精确记录模型当时看到了哪些 token、生成了什么内容、工具实际返回了什么；当历史发生重写时，系统保留任务、轨迹和环境状态的连续性，并支持对真实执行状态进行回放。

同一项任务还可以跨越不同智能体 Harness，甚至分叉出子 智能体。训练层使用统一的轨迹和回放契约，底层则保留每个 Harness 各自的工具、token 和历史改写语义。

这套内部 智能体 强化学习基础设施的核心路径也已通过Dressage开源，涵盖多 Harness 执行、代理式轨迹捕获、沙箱集成和多 Segment 强化学习转换。

06

一个负责长跑，一个负责冲刺

真实工作既有持续数十步的「马拉松」，也有搜索、写代码、调用工具这样的短程「冲刺」。

Occamy 没有强行用一条训练路线解决所有问题，而是先从同一个基础模型训练两个互补的 checkpoint:

Marathon Expert先经过 SFT，再通过团队之前设计的 HDPO 算法进行强化学习，重点训练长任务里的状态跟踪、证据使用、错误恢复和完整交付。

Sprint Expert则用覆盖更广的 SFT 数据，保留指令遵循、工具调用、编程和搜索等通用 智能体 能力。

随后，团队在参数空间中合并两个模型。它不是推理时的模型集成，因此不会增加参数量，也不需要额外的路由系统。合并后的模型再通过 SAO 算法，在长流程 Co-work 任务上继续强化，最终得到 Occamy-1.0。

报告显示，最后一轮训练进一步提升了 Claw-Eval 和 WildClawBench，实现了表现和成本的平衡。

07

Accio 为什么选择 Co-work？

数学题、代码题和单次工具调用，都有相对清晰的目标和验证方式。但真实工作往往没有这么整齐。一项任务可能同时涉及客户记录、文档、规则、交易和历史决策；信息分散在不同文件与服务中，外部状态还会随着每一次操作发生变化。

智能体 必须在搜索、写作、代码、API 和生产力软件之间来回切换，既要理解用户目标，也要对自己的每一次动作负责。

这正是 Accio 团队定义的 Co-work：不是某一种固定技能，而是模型在持续变化的数字环境里，围绕用户目标协调多种能力，直到完整任务结束。

Occamy-1.0 并不试图证明 35B 模型可以在所有任务上取代最大的前沿系统。报告也明确指出，它在知识密集型文档推理、模拟用户交互、原生浏览器与视觉操作、超时鲁棒性，以及跨子 智能体、多目标联合学习上仍有明显提升空间。

但它验证了一条更务实的路线：决定 智能体 能力上限的，不只是模型有多大，还包括训练任务是否可执行、轨迹是否合理、状态能否回放、结果是否可以被真正验证。

从回答问题，到持续行动；从一次生成，到完整交付 - 这就是 Occamy-1.0 带来的变革。

关注 + 星标，获取 AI 前沿进展与开源一线动态