當智慧代理自我改進時，沒有一層機制判斷這個改進能不能信

問題是什麼

代理自己改寫提示詞、接上新工具，把成功的軌跡存進記憶來影響下一次判斷。這一步已經是現實。麻煩從緊接著開始：誰來判定這個「改進」真的是改進？就算新版本把帳單類問題的準確率提上去了，它可能作為代價，悄悄把退款例外的處理弄壞了。更棘手的是代理給自己打分的時候。它給自己一個「通過」，你分不清是能力上去了，還是它背下了評分標準，也就是獎勵駭客。團隊現在手上只有事後回放日誌的可觀測性工具。等東西壞了，才在儀表板上發現。上線之前，沒有一道閘門自動擋在部署前面問：這次自我改進到底該不該進生產？

為什麼是現在

自我改進本身突然變得普及。從生產軌跡裡挖失敗樣例、自動更新提示詞的流水線，把成功軌跡累積進記憶的代理框架，用強化學習打磨工具呼叫的迴圈，全都以開源形式湧出來。建造的一側爆發了，控制的一側卻沒動。DevOps 早就把金絲雀部署與自動回滾變成標準，代理卻沒有對應物。程式碼回歸靠測試能抓住；而「語氣微妙地變得有攻擊性」「只在某一類客戶身上判斷變差」這類能力回歸，會直接穿過單元測試。再疊加監管，像 EU AI Act 對高風險系統提出的日誌、人工監督、變更歷史要求，代理每一次自我變化，都要證明「什麼變了、為什麼變、怎麼驗證的」，壓力越來越大。在台灣，當 TSMC、聯發科這些製造與晶片龍頭把代理推進良率分析、供應鏈這類高精度場景時，第一個卡住的也是這個可追溯問題。建造變容易的速度與驗證的速度之間的落差，那道縫就是市場。

怎麼構建

核心動作是把自我改進當成程式碼部署來對待。代理提出新版本時，不直接推上生產，而是讓它過三道閘。第一，held-out 閘門：隔離出一個代理永遠不能用於訓練與自評的評測集，不讓它看到評分標準，這樣才能篩掉獎勵駭客。第二，回歸偵測：把新版本與舊版本並排跑（shadow 或 A/B），按任務類型比較分數變化，一直算到統計顯著性。整體均值上去了，但某個切片掉了，也能抓住。第三，eval-as-CI：把這套評測作為閘門嵌進開發者的流水線，沒通過的自我改進自動被擋在晉升之外，回滾到上一個版本。把它定位成架在 Langfuse、Arize 這類可觀測性工具之上的「判定、晉升、回滾」層，就能自然滲進那些已經在累積軌跡的團隊。

flowchart LR
  A[Deployed Agent] --> B[Proposes Self-Improvement]
  B --> C{Held-out Eval Gate}
  C -->|Pass| D{Regression Check}
  C -->|Fail| E[Auto Rollback]
  D -->|Clean| F[Promote to Prod]
  D -->|Regression| E

成功條件

這東西一旦變成「又一個評測工具」就死了。跑離線基準的公司已經很多。要活下來，就得釘死在一個又窄又熱的問題上：在生產環境裡自我變化的代理。差異點在於事前閘門與自動回滾，擋住部署的閘，而不是事後去讀的儀表板。信任的核心是 held-out 集的完整性，所以證明評測集沒有外洩給代理的那套機制，會成為產品的心臟。風險也很清楚：如果 LangChain、Langfuse 這類可觀測性平台把這個功能吸收進去，市場就變窄。所以要先立住一條不綁死任何單一框架的橫向標準，以及一個自動留下合規證據（什麼變了、為什麼變、怎麼驗證的）的合規角度。而且誤報太多、連健康的改進也擋下，團隊就直接把閘關了。統計上的嚴謹與低誤報率，就是生存線。