Orkas Orkas
首頁 博客 架構
架構

聲明完成不等於驗證完成:長程 Agent 的里程碑設計

Orkas 里早就有可持久的任務計劃里程碑,也早就在記錄每次工具呼叫到底改變了什麼的宿主側事實。但這兩半從沒被接起來,於是一步是否完成,取決於模型說了什麼。這篇講 BEACON 怎麼定位它的里程碑檢測器、真要做該分哪三層,以及一條論文里沒有的判據。

這是長程 Agent 設計手記系列的第二篇,起因是我們精讀了 BEACON(浙江大學,arXiv:2605.06078)。

第一篇的結論是:循環檢測抓不到停滯,因為重復是輸入側的信號,而進展得看輸出側。但那個結論要能成立,前提是有個東西可以拿來量進展。這一篇講的就是那個東西。

一句話版本 完成與否由檢查說了算,不是由 Agent 自己說了算 Orkas 在把一個里程碑判為完成之前會先驗證,沒解決的會明確列出來,而不是悄悄往下走。
下載 Orkas — 免費

先把問題問對

問題不是「怎麼讓 Agent 知道自己完成了一步」,而是「怎麼讓系統知道它真的完成了一步,而不是它說自己完成了」。

就差這麼一層,可信度完全是兩回事。

我們其實已經有兩半,只是沒接上

翻自家實現的時候,這點讓我們有點意外。

第一半。里程碑這個東西產品里早就有了。有個工具在維護一份可持久的任務計劃:一個長任務被拆成哪幾步、每步是什麼狀態,待辦、進行中、已完成、受阻。它的設計意圖就是給長任務提供穩定的進度錨點。但每一步是怎麼變成「已完成」的?模型自己聲明的。

第二半。每次工具呼叫結束,宿主側都會記下一批確定性事實:檔案的內容哈希有沒有真的變、命令的退出碼是多少、有沒有超時。這批資料記在宿主側,從不進模型上下文,所以模型偽造不了。

缺口就在這兒。一邊是「我完成了」,一邊是「某個檔案的哈希從 A 變成了 B」,這兩條線索從來沒被擺到一起過。

缺的不是資料結構,也不是觀測資料,就是中間那座橋。

論文里最有用的一點,不是那個公式

BEACON 最出名的是雙尺度 advantage,但真正值得拿走的是它怎麼定位檢測器 Φ。

Φ 不需要訓練模型,也不需要人工標注,只讀環境反饋里能觀測到的狀態變化。ALFWorld 里檢測物體狀態躍遷(成功拿起、加熱完成),WebShop 里檢測頁面跳轉,ScienceWorld 直接消費環境本來就給的子目標信號。

零額外模型、零額外採樣開銷。對比另外兩條路:過程獎勵模型要昂貴標注、還有被刷分的風險;蒙特卡洛估值則要在每個決策點多跑幾次 rollout。省下的就是這塊成本。

而做 Agent 產品的人有個論文場景里沒有的便宜條件:工具呼叫本來就是結構化的,成功失敗有明確返回。論文得費勁從環境里摳信號,我們的信號是現成的。

真要做,分三層

第一層:把確定性證據聚成一條流。不做任何語義判斷,只機械記錄不可逆的可驗證變化。檔案內容哈希變了、命令退出碼為零、外部介面呼叫返回成功、資料落庫成功。這些現在就有,只是散在各處,從沒被攏成「已達成事實」這麼一條東西。

第二層:把兩半接上。性價比最高的一步。模型聲明某步完成時不再無條件採信,而是去查這段時間里有沒有第一層的證據。有證據就標成已驗證完成,沒有就標成已聲明完成。這不阻止模型聲明任何東西,只是把有據和無據分開。

第三層:按能力類型分別定義 Φ。作者自己也承認 Φ 需要領域知識、難以泛化,所以別指望一套通用檢測器。寫代碼類看測試退出碼,資料分析類看產出檔案有沒有生成,發消息類看介面返回。這層得一個能力一個能力慢慢鋪。

我們自己加的一條判據:看不可逆,別看重要

這條論文里沒有。

BEACON 的里程碑之所以管用,本質是它標記了回不去的狀態躍遷,拿到鑰匙之後世界就變了。所以判據應該是這個動作有沒有產生不可逆的外部副作用,而不是這一步重不重要。

不可逆:寫檔案、提交代碼、發消息、調付費介面、資料落庫。可逆:讀檔案、搜索、抓網頁、思考。

這麼定有兩個好處。一是機械可判,動作類型直接決定歸屬,不需要任何語義理解,也就不會有「模型覺得這步很重要」這種主觀東西混進來。二是它跟恢復點本來就是一回事:只有從不可逆的地方往後恢復才有意義,可逆的動作重做一遍就完了。

論文里有兩個數,一個能壯膽,一個得當心

壯膽的那個是降級實驗。隨機丟掉一半里程碑,成績還有 82.8,比 72.8 的基線高 10 個點。降級是平滑的,不是懸崖。對想落地的人來說這才是關鍵:你不用等 Φ 設計得完美無缺才敢上,覆蓋一半就已經有得賺。

當心的那個是切分對照。

切分方式成績相比基線 (72.8)
隨機切 5 段74.2+1.4
真實里程碑91.4+17.2

第一篇也引過這組數,但放在這裡含義更直接。如果你的里程碑是拍腦袋定的,那它約等於隨機切分,白做。里程碑值錢,值錢在它跟任務的真實結構對上了。

哪些地方得打折

論文自己在附錄里把「自動里程碑發現」列成了待解決問題。三個 benchmark 的里程碑全是靠規則拿到的:模式匹配環境響應、頁面跳轉、或者環境直接給信號。而瀏覽器操作、代碼庫改造、深度研究這類真正開放的場景,壓根沒有這種現成的可驗證躍遷。

所以那套東西更像是在結構化環境里被驗證過的範式,不是能整個搬走的方案。Agent 產品能落地,靠的是工具呼叫這個結構化邊界,不是靠論文給了現成答案。

另一個坑是粒度。太稀就等於什麼都沒做,太密則段級信號變成噪聲。對應到產品就是任務拆解的粒度,而這裡反倒有個論文場景沒有的便利:計劃里的每一步本來就是給使用者看的,粒度可以用「使用者能不能看懂這一步」來錨,不用純靠算法調參。

如果只做一件事

做第二層。

成本低,因為第一層的資料本來就在,第二層只是把它跟模型的聲明對上。可獨立驗證,因為「已驗證」和「已聲明」的比例本身就是個值得盯的指標。而且它是後面所有事的前提:沒有「已驗證里程碑」這個概念,第一篇的停滯檢測、下一篇的壓縮邊界,都無從談起。

它還有個很舒服的性質:上線不改變任何行為。模型該怎麼聲明還怎麼聲明,只是多了個標記。等資料攢夠了,再決定要不要對「聲明瞭但沒證據」的那些做攔截。

下一篇聊上下文壓縮:為什麼按 token 閾值切跟「什麼該忘」基本沒關係,以及對本篇最自然的那個延伸的一處糾正——很多人會順手認為,里程碑一旦驗證通過,它前面的東西就能整段折疊掉。