RL 環境就是你的數據生成器，它壞掉，你的模型就壞掉

post-training 的競賽愈演愈烈，各家團隊爭相用強化學習（RL）把 base model 打磨成能幹活的 subagent。在這個過程中，有一個基礎設施層幾乎被低估到忽視：training harness，也就是 RL agent 真正生活在其中、與之互動、靠它獲得回饋的那套模擬軟體系統。它可以是一個模擬聊天機器人、一個假的 IDE、一個仿製的 SaaS 後台，總之是 agent 眼中的「世界」。Gemini RL 從業者 Auriel W 在 latent.space 的客座文章裡，直接開門見山：研究者不想要你那個搖搖欲墜的 harness，因為它會讓模型變糟，而且不是「加了點噪聲」那種糟，是「模型學了錯誤的事情、整個 training run 全毀、你的東西只能丟掉」那種糟。

這句話的力道來自一個 RL 的核心特性：在強化學習裡，environment 就是你的數據生成器。傳統監督式訓練有一個靜態數據集，品質好壞在訓練開始前就決定了。但 RL 不一樣，模型靠著與 environment 的每一次互動來自造訓練數據，每一個 action、每一個 reward，都會成為下一步的學習素材。這意味著，如果你的 environment 本身就是壞掉的軟體，它製造的每一筆互動記錄都是垃圾數據，而這些垃圾數據會被直接餵進梯度更新，把模型一步一步往錯誤方向推。靜態數據集的品質問題是一次性的，RL environment 的品質問題是持續性、累積性的，整個 training run 都泡在污染裡。

對正在替自家產品 post-train subagent 的新創而言，這不是學術問題，是工程問題，也是商業問題。你花了算力、花了人力，最後模型學到的是 harness 的 bug 模式，而不是你想要的任務能力，這個 run 的成本直接歸零。Auriel W 點出幾種她反覆看到的失效模式，值得逐一拆解。

第一，隨機丟出 traceback。Harness 偶爾崩潰、拋出未處理的例外，這在 demo 環境可能只是小瑕疵，在 RL 訓練裡卻是系統性問題：每一次崩潰都會在 trajectory 裡留下不正常的終止狀態，模型無從分辨「任務真的失敗了」還是「軟體自己壞了」，回饋信號因此失真。第二，race condition。Harness 在並發請求下出現競態條件，代表同樣的 agent 行為在不同時間點會得到不同甚至矛盾的回饋，隨機性不是探索，是噪聲。第三，輕載即倒。Production-grade 的訓練環境需要承受大量並行 rollout，一個在最小負載下就掛掉的 harness，根本無法支撐規模化訓練。第四，也是最隱蔽的：harness 裡藏著真的壞掉的程式碼。不是邏輯瑕疵，是字面意義上的 broken code，這種錯誤不一定會引發 crash，但會悄悄輸出錯誤的狀態或獎勵值，讓模型在不知情的情況下學歪。

把這四種失效模式放在更大的脈絡下對照就會看清問題的本質。過去用靜態數據集訓練時，「數據品質」這件事有獨立的 pipeline 可以把關，清洗、標注、審核，是可以跟訓練分開處理的工序。RL 打破了這個分工：environment 既是任務執行者、又是數據生產者，兩個角色合而為一，品質把關沒有辦法外包給另一個流程。這讓許多人在用 RL 範式做 post-training 時踩坑：他們帶著「先跑起來再優化」的 prototype 心態搭 harness，卻沒意識到這個 harness 同時是生產數據的工廠，prototype 品質的工廠生產不出 production 品質的數據。

這裡有一個不能迴避的現實邊界：從業者要怎麼在訓練開始之前就發現 harness 有問題？Auriel W 的文章點出的是現象清單，但系統化的驗收方法論在這篇文章的素材範圍內並沒有完整展開。這個空白本身就說明這個領域的工程規範仍在形成中。對想採購或整合外部 RL environment 的團隊來說，目前缺乏標準化的品質指標，意味著你很大程度上還是要靠「眼球看 trajectory」來判斷環境好壞，這正是 Auriel W 強調要親自讀 trajectory 的原因之一。此外，越複雜的 agentic harness（多步驟、多工具調用、跨服務 mock），潛在的失效點就越多，維護成本也成比例上升，這對資源有限的新創是真實的工程負擔。

把 RL environment 當生產級軟體而非 demo 來驗收，才是入場 post-training 賽道的正確門票。