前幾天，和朋友討論了一個有爭議的問題：agent開發和agent演算法有什麼區別？這應該也是很多人找工作關心的點

我理解是，把一個agent從0快速做到60是開發，做到80並不斷追高就是演算法

在這個迭代過程中，不能只靠自己視角下定義的過程指標來判斷效果，最終還是要接受上線後的真實業務指標檢驗。但上線驗證周期長、成本高，不可能每次迭代都等線上反饋。所以需要建構離線 Benchmark，儘可能對齊線上效果，用快速的離線評估來指導先驗策略迭代。最後再上線獲取真實後驗，反過來修正和補充新的先驗策略

所以我認為，一套相對完整的Agent業務迭代方法論是：Benchmark → 策略 → 上線

從一個 make sense 的方案，到真正 work，再到足夠 solid，中間還有很多方法論，後面慢慢展開

Benchmark：很多演算法實習生的第一份工作

很多演算法實習生的第一份工作，就是把 Benchmark 做 solid。比如審今年ICLR的論文，這個判斷標準天然主觀很模糊，只能專家評，很難機器一步評估，所以可以拆成寫作、創新性、實驗等多個維度，再分別定義什麼情況下應該得到高分或低分，來做的儘量可評

這個就叫Rubric，把模糊的業務目標，翻譯成能夠被沒那麼專業的人、和LLM、程序可以穩定執行的評價標準。這和 Agent 把一個模糊的自然語言目標逐步拆解成可執行的 plan / action 有點像。前者把我要什麼轉成可評估條件，後者把我要什麼轉成可執行步驟。本質上是在把模糊的業務目標，翻譯成一個可以離線執行的評價標準。類似codex、claude code是把模糊的目標，翻譯為可執行程式碼

有了Rubric後，自己的事情自己做，先由自己或者業務專家按照Rubric去看幾條case，驗證 Rubric 本身到底能不能被穩定執行。所以通常會先找一批樣本做人標，看人人一致率

如果同一個 case，兩個人按照同一套 Rubric 仍然經常得出不同結論，那很多時候不是 Judge 不行，而是 Rubric 本身還不夠清楚，需要繼續拆標準、補邊界 case。Human Judge是最可靠辦法，但又慢又相對貴不能 scaling

所以發現人可以標後，可以開始研究如何讓LLM來標。

這一步目標是讓llm儘可能復現已經穩定下來的人工判斷。一般會先用高品質的人標資料作為ground truth，通過手工 PE / AutoPE 不斷調整 Judge Prompt，還有一些超參數（比如溫度、top k、top p）。如果人\-機一致率很高，說明離線benchmark初步可用了，然後看線上的真實業務指標。

如果發現：離線漲了，線上沒漲。那問題就不一定在策略，也可能說明 Benchmark 本身沒有對齊真實業務目標，需要繼續根據線上 bad case 和後驗資料去更新 Cases、Rubric 和 Judge。所以 Benchmark 本身也不是一次性做完的，而是在跟著業務一起迭代（llm泛化性很強，一起迭代問題不大）。

這時候你會發現，每次評測都要跑一次大模型，隨著Benchmark、RL rollout規模越來越大，成本和時延可能不能接受

既然做了那麼久LLM\-as\-Judge，已經能比較好地復現人工判斷，為什麼還要再訓RM來做judge呢？因為LLM Judge解決了自動化評測，但沒有解決規模化評測

當 Benchmark、實驗和 RL rollout 的規模繼續擴大時，每次都呼叫一個大模型做 Judge，成本和時延會隨著評測量線性增長（對這個成本沒概念可以看看最近mimo的直播RL），而且這個很難通過縮減prompt長度來最佳化，所以可以把已經驗證過的評價標準蒸餾成一個低延遲、高吞吐的rm

LLM Judge 的優勢是泛化能力強，Reward Model只需要在業務對應的資料分佈裡更強，所以原理上可以用更小的基模，然後用前面已有的評測資料來訓。當然也會有Reward Hacking問題，所以RM也不能被當成永遠正確，還是需要定期人工、LLM Judge檢測新的 bad case 後補充資料，再重新訓練和校準RM。

這也是一個 scaling 的過程：Rubric 定義什麼叫好，Human 積累人工判斷的經驗，LLM Judge 把人工判斷自動化，Reward Model 再把自動化判斷規模化。

策略：從跑通 Agent 到持續提升效果

做agent策略就是做先驗，然後根據上線效果將後驗轉化為先驗（資料驅動），具體的agent策略開發流程我覺得一定是從老實琢磨prompt開始

根據和多位優秀的小同行討論經驗，大部分業務，根據專家先驗知識調好Prompt就可以先上一版，根據上線效果來覺得後續路線，所以一個合理的開發流程應該是：

2. 系統性分析prompt→response這條pipeline上的bad cases；

3. 再通過一些經典手法（RAG、few\-shot、CoT）逐步逼近效果上限；

4. 一邊做這個，一邊最佳化benchmark

很多人低估了prompt用token換精準度的潛力，大模型的能力越來越強，這意味著很多你以為很難的case，其實只是prompt沒寫好。那麼如何系統評估 prompt 是否還有最佳化空間呢？可以嘗試做 Prompt 梯度測試，在同一批樣本上逐步增強prompt，看效果是否持續提升。可以按下面的順序迭代開發：

1. 最簡單指令橫向對比多個基模，pick最合適的

2. 根據專家先驗知識加system prompt，對應上業務要求；

3. 拆一些workflow來強化PE，比如手動/自動加上下文，讓模型有參考資訊；

如果隨著agent裡面流動的prompt逐步增強，效果仍然幾乎不變，說明對當前業務，agent策略已經燃盡了，進入下一步llm策略

LLM 策略不是為了替代 Agent 策略，而是把 Agent策略中已經驗證有效的非參數化先驗，訓為模型的參數化行為。Agent 階段是在 Prompt、Context、Workflow 裡告訴模型應該怎麼做；LLM 階段則是讓模型自己學會應該怎麼做，減少每次都給prompt的成本，同時繼續提高效果和穩定性。

做agent開發過程中，如果遇到了效果、穩定性、成本瓶頸，就可以考慮進入llm策略，把 Agent 策略已經驗證有效的 60 分方案，做得更穩定、更便宜、更 scalable。

把 Agent 策略已經驗證有效的先驗，固化成模型穩定的行為模式。比如在 Agent 開發過程中，我們可能已經驗證：1、某種任務理解方式是有效的；2、某類 Few\-shot 能明顯提升效果；3、某種 Tool Routing 更穩定；4、某種輸出格式更符合下游要求；5、某種拒答邊界更符合業務預期。

這些東西一開始都可以寫在 Prompt 和 Workflow 裡，但如果它們已經經過 Benchmark驗證，而且高頻、穩定、長期不會頻繁變化，就可以進一步考慮通過 SFT 訓進參數。

所以我覺得，SFT 前最重要的問題是：哪些 Agent 階段學到的經驗，真的值得被固化進模型？

一個可以參考的原則是：高頻變化的資訊繼續留在 Context，長期穩定的行為才值得訓進model

比如即時庫存、活動規則、最新政策這種東西，即使很重要，也不適合訓進模型；但固定輸出習慣、穩定業務 SOP、Tool 呼叫方式、任務拆解範式，是適合參數化的。

因此SFT難點是資料。因為本質上就是告訴模型：遇到這種情況，以後就應該這麼做。如果同一種業務場景下，一部分資料要求拒答，一部分要求正常回答；一部分要求嚴格 JSON，一部分允許自由文字；一部分要求先呼叫工具，一部分直接憑模型知識回答，那麼模型學到的不是靈活，而是不確定性。

所以我把 SFT 的資料清洗理解為不是在清洗低品質答案，是在整理模型最終的行為分佈。這也是為什麼 SFT 資料不是越多越好，更重要的是資料質量、行為一致性。未經Benchmark 驗證的 Prompt Hack，不能因為看起來有效就直接擴資料訓進去，否則只是把一個還沒想明白的策略永久寫進參數。

SFT是教模型抄版本答案拿到好結果（codex、簿肌、自媒體、孫學、早C晚A護膚、低糖高蛋白飲食、偽素顏、雅思7\.0、拿實體黃金）

RL是放大好結果為大結果，讓模型自己想辦法拿到（來讀研 or 去實習）

前面說 SFT 難在資料質量，那麼 RL難在反饋訊號。

這也是為什麼前面說要花了那麼多時間做 Benchmark，因為到了 RL 階段，Benchmark不只是測試，是反饋。Rubric定義什麼叫好，Judge判斷好不好，這個判斷轉化成RL階段的Reward，直接影響模型往哪個方向最佳化。

RL難也在這裡了，因為你的reward可能不是業務真正需要最佳化的東西。如果Rubric沒對齊業務，Judge沒對齊人工（不穩定），Reward又只是離線指標的近似。那麼RL階段，模型學好學壞都是學，所以離線 Reward 漲了，並不等於線上業務指標一定會漲。

最後還是要回到Online Metric：上線拿到新的使用者後驗，再去更新 Benchmark、拉bad case、修 Rubric、調整資料和 Reward，然後進入下一輪迭代。

Agent 階段積累專家先驗，SFT 把穩定先驗寫進參數，RL再把業務評價標準變成reward，讓模型朝目標繼續最佳化。

reward 設計得好，模型會更穩定地朝業務目標最佳化。reward 設計錯了，模型會更極致地學錯。

分享一些llm策略有爭議maybe有價值的討論

有人說有過擬合的風險，也有人認為只要訓練集cover業務場景，過擬合反而是我們的目標...

有人說有災難性遺忘的風險，也有人認為遺忘是一種資料提純...

做agent開發的朋友說workflow才是通往AGI的道路，微調只是參數內卷、原地踏步...

做aigc的朋友認為，真正決定應用效果上限的，始終還是模型自身的能力邊界... (Datawhale)

彙整鉅亨號中所有使用「solid」關鍵字，所發布的內容 (依照時間排序，最新在前，舊的在後)`

重磅！從 Agent 開發到 Agent 演算法，進階指南來了