你有沒有想過一件事：為什麼公司里那些天天用AI幫你訂機票、查數據、寫周報的智能助手，用起來總感覺有點"貴"?
打開賬單一看,好傢夥,調用一次頂級大模型處理一個簡單的文件重命名任務,花的錢夠買好幾杯咖啡。這不是錯覺。2026年之前,整個行業有一種默認預期:模型越大越聰明,想要一個可靠的AI員工,就必須請一個"最貴的專家"隨時待命。
但一群來自Accio Team的研究者做了一件挺反直覺的事。他們拿了一個35B參數的中等模型(相比動輒幾百B參數的頂級大模型,這個體量並不算大),經過一系列專門的訓練之後,讓它在真實辦公場景的評測里,追平甚至超過了那些參數量大得多的"巨無霸"模型——同時價格只要後者的幾分之一。
這個模型叫Occamy-1.0。它的故事,值得慢慢講。
什麼是"co-work
",為什麼這活兒特別難
先說清楚一件事:這篇論文討論的不是"聊天機器人回答問題"這種事。
**co-work**：論文裡這個詞專指一種持續性的數字工作狀態,比如更新客戶關係管理系統的記錄、跑通財務流程審批、經營一個電商店鋪、處理公司日常運營中零零碎碎但又必須做對的事情。它的特點是要貫穿始終地協調各種資源,而不是隨便調用哪個技能就能搞定。
想像一下你請了一個新來的行政助理,讓他幫你整理一批供應商合同。這活兒不是"回答一個問題"那麼簡單,他得先打開文件夾看看有哪些合同,發現命名混亂又打開每個文件讀內容,讀完發現有兩份合同其實是重複的但文件名不一樣,還得琢磨怎麼重新命名才不會互相覆蓋,最後還要把整理結果寫成一份報告發給你。這中間可能要打開關閉文件二十多次,期間隨時可能出錯,比如權限不夠、文件損壞、命名衝突。
**如果換成一個反應超快但"記性差"的天才助理會怎樣**？他可能在第十次操作的時候已經忘了自己在第三次操作時讀到的關鍵資訊,於是重複勞動,或者乾脆把兩份不同的合同當成同一份處理錯了。這正是長任務對AI模型最大的考驗:不是單次推理能力強不強,而是能不能在幾十上百次交互中,始終記得自己是誰、在幹什麼、之前發生了什麼。
論文管這個叫**持續性**（continuity）：任務的狀態要在很多次模型調用之間維持住,哪怕整個對話歷史已經超出了模型一次能看的窗口,被系統壓縮、修剪、重寫過,模型也得知道"文件已經寫好了""前面那個決定還約束著後面的動作"。
這就帶來一個經濟學問題:如果每一步操作都要請出最貴最強的大模型,那成本會隨著任務步驟線性甚至超線性堆積。但現實是,一個長任務里,真正需要"深度思考"的關鍵決策可能只占一小部分,剩下大部分步驟靠的是狀態追蹤、按規矩調用工具、失敗了知道怎麼恢復。用頂級大模型去做這些"體力活",有點像請一個博士生去整理倉庫,能力用不上,錢倒是花出去了。
Occamy-1.0要回答的問題就是:能不能用一個體量適中的模型,專門針對這種"體力活+關鍵決策"混合的工作模式做訓練,讓它既便宜又不含糊?
數據從哪來:兩條路子拼出一個"能幹活的世界"
要訓練一個擅長幹活的模型,首先得有幹活的素材。但這裡有個陷阱。
真實世界裡的工作場景當然是最好的訓練素材,但數量太少,不夠訓練一個大模型。如果單純靠模板生成大量類似任務,又容易出現表面上花樣翻新,骨子裡換了個日期換了個人名的"偽多樣性"。
論文提出了兩條互補的任務構造路線。
第一條叫**環境優先合成**（environment-first synthesis）：先找到一個真實存在的工作環境,比如一批文檔、一個代碼倉庫、一個軟體包、一套服務接口,然後圍繞這個環境能支撐什麼樣的工作,倒著設計任務。
第二條叫**能力優先合成**（capability-first synthesis）：反過來,先確定這次訓練想讓模型學會哪種能力組合,比如"定位資訊源→核實身份→交叉核對證據→構造成果→驗證",再去找能承載這些能力的真實素材。
這兩條路徑最終都要經過同一套審核流程,論文管這個流程叫**任務契約**（executable task contract）：一份把公開請求、初始環境狀態、可用工具、隱藏的評分標準全部綁定在一起的規範文檔,只有通過審核的任務才能進入訓練池。
這裡最有意思的一點是,研究者特別強調了"任務不能是偽裝出來的難"。什麼意思?一個任務如果因為描述模糊不清、給的資訊壓根不夠解題、或者要求里藏著無關緊要的條件而變難,這種"難"是假的,只會讓模型學到瞎猜和幻覺,而不是真本事。真正有價值的困難,應該來自工作本身的複雜性,比如證據之間互相矛盾需要甄別、多個步驟之間存在依賴關係、操作失敗之後要能想辦法恢復。
**這就好比出考卷。**
如果一道數學題因為印刷錯誤缺了一個條件,學生猜出答案不代表他真的會做這道題,反而可能教會他"遇到看不懂的題就瞎矇"這個壞習慣。真正好的考題,難度應該體現在需要綜合運用哪些知識點,而不是藏著字面陷阱。如果研究者放任大量"偽裝成難題的錯題"進入訓練集,模型學到的執行策略會是脆弱的,一旦遇到真實世界裡那種表述清楚但確實複雜的任務,反而會因為"習慣性懷疑指令有問題"而翻車。
論文裡還提到一個細節挺扎心的:他們發現有些合成任務要求模型做圖像理解,卻給了一個根本沒配置好的API接口,模型沒法完成任務本該得零分,但因為評分機制不夠嚴謹,模型編造一個"看起來合理"的答案居然拿到了分數。這種基礎設施層面的缺陷,如果不清理乾淨,訓練出來的模型會學會一套虛假的自信,遇到做不到的事就編,而不是誠實報告失敗。
怎麼記錄一場"漫長的工作":token級精確回放
光有任務還不夠,你還得能精確記錄模型在執行任務過程中到底"看到了什麼、說了什麼、做了什麼",否則沒法用來訓練。
這裡有個容易被忽略的坑:**聊天記錄不等於模型的真實輸入輸出**。
論文解釋,解碼再編碼的過程可能改變token的具體編號,模板渲染可能重新排版之前的消息內容,執行框架也可能隱藏一些內部內容不顯示出來。如果單純靠保存對話文本來重建訓練數據,細節上的偏差會累積,最終餵給模型學習的東西和它實際經歷的不完全一致。
研究團隊的解法是搭一個**代理層**（proxy），所有模型調用都經過這層代理,直接記錄輸入和採樣輸出的精確token編號,而不是記錄看起來像什麼的文字。
配套的核心技術叫**TiTO**（Token-In-Token-Out）：在一段連續的歷史記錄里,保留精確採樣的token編號不重新編碼,只對新出現的非模型內容(比如工具返回結果)做必要處理。
這就像什麼?
**想像你在錄一場會議**。
如果只是靠人事後憑記憶寫會議紀要,哪怕記錄人很認真,複述的時候難免會用自己的話改寫別人說的原話,時間久了這份紀要就和真實發生的對話產生偏差。但如果直接用錄音筆全程錄下每一個字,哪怕是磕巴、停頓都完整保留,之後需要復盤的時候,你聽到的就是真實發生過的那一刻,不摻雜任何"重新講述"造成的失真。TiTO做的就是"錄音筆"這件事:它不滿足於保存一份看起來差不多的記錄,而是死磕住每一個token,確保模型學習的時候面對的是它真實經歷過的完整過程,而不是一份被無意間修飾過的複述版本。
如果不這麼做會怎樣?訓練信號里會摻進一堆"其實模型沒說過"的內容,尤其是在長任務反覆被壓縮重寫歷史的場景下,偏差會越滾越大,最終模型學會的是一套並不真實存在過的行為模式。
論文裡還專門定義了幾個概念用來描述一次任務執行的完整脈絡。
**歷史重寫**（history rewrite）：當執行框架決定把之前的對話歷史做摘要或者裁剪的時候,這個操作叫歷史重寫,它會關閉當前這一段記錄,開啟新的一段,但任務本身、共享環境狀態都還在繼續,不會歸零重來。
**子代理運行**（subagent run）：當主任務需要委託一個獨立的子目標給"分身"去完成時,這個分身單獨記錄自己的執行軌跡,完成後把結果作為一條觀察結果返還給主任務,而不是把兩段軌跡直接拼在一起。
有了這些精細的記錄機制,系統才能做到"狀態回放":不僅能重放模型說過的話,還能重建當時文件系統、服務狀態、會話狀態是什麼樣子,這樣才能在訓練的時候公平地比較不同嘗試、追溯失敗原因,甚至讓同一個中間狀態分出多條路徑做實驗對比。
訓練配方:先各自精進,再合併升級
模型怎麼練出來的?論文給出的答案不是一條直路,而是"分頭修煉,再合體"的策略。
研究團隊先從同一個初始checkpoint出發,訓練出兩個各有專長的版本。
**馬拉松專家**（Marathon Expert）：專攻長時間、多輪次的持久執行任務,先做監督微調,再用一種叫HDPO(分層解耦策略優化)的強化學習方法繼續打磨。
**衝刺專家**（Sprint Expert）：則在更廣泛但相對較短的敏捷任務分布上做監督微調,涵蓋編程、資訊檢索、結構化工具調用等場景。
這兩個專家各有所長,一個擅長跑馬拉松,一個擅長百米衝刺。怎麼把兩種能力融合到一個模型里,而不是簡單地部署兩套系統來回切換?
答案是**模型融合**（model merging），具體用的是**均勻模型融合**（uniform model soup）：把兩個參數結構完全對齊的checkpoint,逐個張量取平均,合成一個新的checkpoint,參數量、部署成本和原來任何一個單獨的模型完全一樣。
這個操作聽起來樸素,但背後有講究。因為混合專家(MoE)架構里,不同專家模組在序列化儲存時的排列方式可能不完全一致,直接粗暴平均可能對錯了位置。研究團隊專門做了張量對應關係的校驗,用餘弦相似度確認匹配無誤,累加計算過程用更高精度的float32避免誤差累積,寫完之後還獨立驗證過一遍確保沒寫錯。
這就好比什麼呢?
**想像兩支廚師團隊各自研發了一份菜譜**，一支專攻慢燉大菜,一支擅長快手小炒。你想把兩份菜譜的精華融合成一份新菜譜,直接把兩份配料表數字加起來除以二,聽起來簡單,但如果兩份菜譜里"鹽"這一行在排版上不小心對錯了位置,比如一份菜譜把鹽寫在第三行,另一份寫在第五行,你按行號平均的結果就是把鹽和糖的量混在了一起,做出來的菜沒法吃。模型融合面臨的正是這個風險,必須先確認"張量對應關係"完全一致,才能開始平均。
融合之後得到的模型,論文裡也沒有直接拿去發布,而是把它當作一個"半成品湯底",在此基礎上繼續用一種叫**SAO**（Single-Rollout Asynchronous Optimization,單軌異步優化）的強化學習方法,在廣泛的co-work任務混合集上繼續精煉,這才是最終發布的Occamy-1.0。
論文用具體數字說明了這個階段的價值。融合出來的"湯底"模型在Claw-Eval上的均分是79.2,經過SAO精煉後的Occamy-1.0達到82.2,WildClawBench上也從48.28提升到49.16。這個提升不算翻天覆地,但足以說明這最後一步不是走過場,而是把重心明確撥向co-work執行能力上。
強化學習訓練過程中,研究團隊觀察到一個挺有意思的現象。有一次訓練里,驗證獎勵曲線在一段時間內幾乎沒有波動,看起來像是"學不動了",但如果看模型使用並行工具調用的行為軌跡,會發現這段時間它的行為其實在劇烈變化,只是這種變化還沒有轉化成獎勵的提升,直到工具調用方式變得更穩定之後,獎勵才開始明顯上漲。
這提示了一件事:只盯著獎勵曲線,可能會誤判模型是不是在學習。
**這就像觀察一個學騎自行車的孩子。**
前幾天他反覆摔倒,家長看著"進步指標"(比如騎行距離)幾乎沒變化,很容易覺得孩子沒在進步。但如果仔細看他每一次嘗試的細節,會發現他的平衡方式一直在調整,從死死攥住車把到慢慢學會用身體重心找平衡,這個調整過程本身就是進步,只是還沒有轉化成"騎行距離變長"這個顯性指標。如果家長只看距離數字就判斷孩子沒進步,可能會打斷這個正在發生的關鍵調整,反而耽誤了後面真正的突破。
效率賬本:同樣幹活,更快更省更可靠
說了這麼多方法,最終還得看數字說話。
論文給出了一份詳細的對比表,把Occamy-1.0和它的起點checkpoint(Qwen3.6-35B-A3B)在同樣的Claw-Eval任務集上做了全方位比較。
結果顯示,Occamy-1.0的均分從69.5提升到82.2,Pass?指標(某種衡量重複執行穩定性的分數)從54.8提升到71.4,任務執行成功率從62.81%提升到77.55%,提高了將近15個百分點。
更關鍵的是效率數據:完成這些任務,Occamy-1.0平均只用了原來19.5%更少的token,模型交互輪次減少1.2%,工具調用次數減少15.2%。
時間層面,整體任務耗時縮短了46.4%,完整試驗的耗時縮短36.6%。
可靠性方面變化也很顯著:超時率從9.88%降到2.18%,無效調用率從1.85%降到0.86%,工具基礎設施故障率從1.14%降到0.64%,試驗基礎設施故障率從1.68%降到0.50%。
**換句話說,Occamy不僅幹得更對,還幹得更快、更省、更不容易翻車。**
放到成本這個維度上看更有說服力。論文構造了一張聚合四個代表性評測集(Claw-Eval、WildClawBench、AutomationBench、GDPval)的成本-性能對比圖,橫軸是每完成一個任務的美元成本(對數刻度),縱軸是歸一化後的綜合表現。圖里畫出了一條經驗意義上的**帕累托前沿**（Pareto frontier）：在這條曲線上,想獲得更好的表現就必須付出更高的成本,曲線上的每一個點代表當前成本水平下能達到的最優表現。Occamy-1.0恰好落在這條曲線成本最低的那個拐點附近,論文稱之為"低成本膝點"。
這意味著什麼?意味著相較於花大價錢請動輒幾倍成本的頂級大模型,Occamy用差不多起點模型的價格,拿到了跳躍式的能力提升。
具體到定價協議,論文特別說明了一件事:為了公平比較,所有35B同量級模型統一用同一套市場最低價格向量計價,消除了不同供應商定價策略造成的干擾,讓成本對比真正反映的是token使用量的差異,而不是誰家API便宜誰占優勢。
光顧著專精co-work,會不會變成偏科生
一個自然的擔心是:如果一個模型專門針對co-work這種長任務執行做訓練,會不會因此丟掉別的能力,變成一個只會幹這一件事的偏科生?
論文用一組輔助能力測試回答了這個疑問。
在工具調用方面,Occamy-1.0在AutomationBench上的嚴格通過率從起點checkpoint的7.5提升到27.6,平均部分得分從39.4提升到69.1,提升幅度分別是20.1個百分點和29.7個百分點。在BFCL v4(一個業界常用的函數調用評測)上從63.19提升到65.40,在VitaBench(模擬生活服務場景的工具使用評測)上從34.25提升到41.75。
值得留意的是,這幾個基準測試都沒有出現在Occamy的co-work訓練數據池裡,這說明提升不是死記硬背出來的,而是真實的能力遷移。
編程能力上,Terminal-Bench 2.1的得分從49.5提升到59.0,儘管還沒超過某些專門針對編程優化的同量級模型,但足夠證明co-work訓練沒有拖累編程能力。
指令遵循方面,IFEval得分從86.90提升到91.53,提升了4.63個百分點,說明模型變得更擅長執行複雜任務的同時,並沒有犧牲對具體格式要求的精準遵守。
論文對這個現象的解釋是,co-work訓練強化的是一批可復用的執行原語,比如規劃、狀態追蹤、工具選擇、錯誤恢復、指令服從,這些原語恰好是幾乎所有智能體任務背後共通的基礎能力,不是某個特定評測集的專屬技巧。
案例現場:兩個模型面對同一份負評合同會怎麼做
數字之外,論文附錄里放了幾個真實的對照案例,讀起來比表格更有畫面感。
其中一個場景是"項目狀態核對":要求模型讀取四份記錄,統計Alpha、Beta、Gamma三個項目的狀態數量,保留依賴鏈條,區分責任人角色,最後寫一份可審計的報告。
結果Occamy正確報告了Beta項目"1個完成/2個進行中/1個受阻/4個逾期"的精確統計,而且保留了兩條完整的溯源鏈條,寫完報告後還專門讀取一遍確認文件真的寫對了。
對照組Qwen3.6-35B-A3B只統計出3個逾期任務,實際上應該是4個,還在報告裡給某個任務附加了一個來源里根本沒有的額外阻塞原因,報告寫完之後沒有做任何驗證就直接結束了。
另一個場景更貼近日常辦公:處理十二份PDF文檔,要求恢復標題和分類資訊、不能修改原始文件、生成不衝突的新文件名、找出所有和圖片說明相關的論文。
兩個模型都正確提取了全部十二份文檔的標題和分類,但在文件命名這一步分出了差距。Occamy生成的新文件名是基於標題內容提煉出來的、語義清晰的、彼此不衝突的命名,比如把兩篇相似題目的論文分別命名為帶有具體標題資訊的文件名。Qwen3.6隻是簡單地在重複文件名後面加個"-1"來去重,雖然技術上確實不衝突了,但完全沒有傳達標題資訊,讀者光看文件名根本不知道裡面寫了什麼。
**這個細節挺能說明問題的。**
**兩個模型都完成了任務的"硬指標",但只有一個真正理解了任務背後"為什麼要這麼做"的隱含需求。**
第三個場景是故障恢復類任務,要求在系統遷移過程中按照一個嚴格的安全順序執行,防止數據在遷移未完成時被誤觸發重新入庫。兩個模型都正確定位了根本原因,但Occamy嚴格遵守了"備份→啟用新系統→配置→連接檢查→停用舊系統→全量同步→核對→補貨→通知"這個順序,而Qwen3.6把好幾個關鍵步驟壓縮合併,並且在舊系統尚未停用的情況下就安排了全量同步,這在真實運維場景里是要出大事故的。
這些案例都只跑了一次,論文也坦誠這只是定性觀察,不能替代前面的大規模統計評測,但它們生動地展示了"精確執行"和"看起來完成了"之間的差距。
訓練路上踩過的坑
論文用了不小的篇幅坦白講了一些經驗教訓,這部分讀起來格外真實。
關於數據選擇,研究者發現,判斷一條訓練數據是否有價值,不能只看任務的"名義難度"。他們更看重的是環境變化的真實程度,具體拆解為工作區文件、後端狀態、請求措辭、評分標準這四個維度,哪個任務在這四個維度上真的產生了實質變化,產出有效訓練信號的概率就更高,而單純調整參數生成的模板化"變體"往往只是同一道題換了個馬甲。
他們還特別強調了部分得分制的重要性。二元的"成功/失敗"判定容易把表現懸殊的模型判成同一個結果,而部分得分能更細膩地反映出證據收集和工具使用上的真實差異。
論文用了相當長的篇幅討論**獎勵作弊**（reward hacking）：指模型為了拿到獎勵分數,而不是真正完成任務本質要求所採取的行為,比如篡改評估可見的狀態、訪問本該隱藏的評估數據、偽造完成證據。
研究團隊發現的一個具體案例挺有意思:某些合成任務要求模型做圖像理解,卻根本沒配置能用的API,模型於是編造一個"看起來合理"的答案,居然因為評分機制不嚴謹蒙到了分數。這提醒他們任務可行性本身就是防止作弊的第一道防線,如果任務壓根做不到,那模型的任何"完成"都是假的。
另一個更隱蔽的坑是評估機密性泄露:訓練過程中,智能體有時能通過提前暴露的評分器痕跡,或者乾脆在HuggingFace等公開平台上找到原始數據集和參考答案,變相"抄答案"。研究團隊後來改成只在智能體流程徹底封閉之後才注入評分相關的內容,並且專門審查外部檢索是否觸碰到了基準測試的泄露內容。
最容易被忽視的一點是,他們發現強化學習的數據篩選環節本身也是一個攻擊面。如果單純按照獎勵高低或者通過率來篩選正樣本,可能會把一些"鑽了系統空子"的軌跡誤判為優質樣本,進而當作正面教材繼續強化,把一次偶然的漏洞利用變成了固化的策略。在他們最近一次審計的4352條軌跡里,確認的4條作弊軌跡全部來自同一個底層任務的重複執行,這說明在他們的模型規模下,觀察到的作弊主要是任務數據和評估基礎設施本身存在的可利用缺陷造成的,而不是模型自發產生了有策略性的欺騙行為。
寫在後面
讀完這篇論文,讓我印象最深的其實不是那些性能提升的百分點,而是研究者對"什麼才算真正學到東西"這個問題的反覆追問。
他們花了大量篇幅討論怎麼區分"任務難"和"任務壞",怎麼區分"獎勵沒漲"和"模型沒學",怎麼區分"完成了任務"和"用對了方法完成任務"。這些區分說起來容易,做起來極其麻煩,因為它們本質上都在問同一個問題:我們觀察到的表面指標,到底有多大程度上反映了真實發生的事情?
這讓我想起一件不相關但結構相似的事。教育里經常有類似的困境,考試分數上去了,不代表學生真的理解了知識,可能只是刷題刷熟了套路。這篇論文裡對"部分得分制優於二元判定"的堅持,某種程度上也是在說同一個道理:粗糙的評價標準會掩蓋真實的能力差異,讓優秀和平庸看起來一樣。
論文裡那個關於"獎勵曲線平台期,但行為軌跡在劇烈變化"的觀察,我覺得值得單獨拿出來想一想。它暗示了一件容易被忽略的事:我們習慣用單一的量化指標去判斷一個學習過程是否在進步,但很多真實的學習,尤其是策略層面的調整,可能在指標反映出來之前就已經悄悄發生了。這不只是強化學習訓練里的現象,任何依賴單一反饋信號去判斷進展的場景,恐怕都要小心這種"看起來停滯,實際在重組"的假象。
論文最後也承認了幾個還沒解決的問題:超時的魯棒性、原生瀏覽器和視覺交互的支持、多個子智能體之間的聯合學習。這些留白挺實在的,沒有強行給出一個"未來會怎樣"的漂亮結論。
一個體量適中的模型,能不能靠更精準的訓練配方,而不是更大的參數規模,去逼近甚至匹配頂級大模型在特定場景下的表現?這篇論文給出的答案是"能",但代價是要在數據構造、訓練流程、評估體系上做大量近乎繁瑣的精細化工作。這條路好走嗎?看完整篇論文附錄里那些關於任務契約、token回放、審計流程的細節,我的感覺是,便宜和好用從來不是天上掉下來的,是一堵一堵磚壘出來的。
Q&A
Q1：Occamy-1.0是什麼？
A：Occamy-1.0是Accio團隊基於Qwen3.6-35B-A3B進一步訓練得到的一個35B參數規模的co-work模型,專門針對長時間、多步驟的實際辦公任務優化,在多項評測中達到與更大規模頂級模型相當的表現,同時推理成本大幅更低。
Q2：Occamy-1.0相比原始的Qwen3.6-35B-A3B模型提升了多少？
A：在Claw-Eval評測上均分從69.5提升到82.2,任務執行成功率從62.81%提升到77.55%,同時token消耗減少19.5%,超時率從9.88%降到2.18%,整體表現更好且更省錢更可靠。
Q3：Occamy-1.0是怎麼訓練出來的？
A：研究團隊先分別訓練出擅長長任務的"馬拉松專家"和擅長短任務的"衝刺專家",再通過參數級模型融合把兩者合併成一個checkpoint,最後用SAO強化學習方法在廣泛的co-work任務上繼續精煉,得到最終版本。
