guildrail hooks，hooks機制 把關，改善 Agent的回答，經驗筆記

最近遇到個問題，在開發專案上，我使用了AI 知識學習庫，會跟著專案記錄錯誤與學習經驗，在做經驗萃取時，實際上遇到了很有趣的問題。

在錯誤經驗日誌中 N 筆資料中回覆了錯誤的引用，需要如何設計一個自動化的驗證流程（Evaluation Pipeline）來抓出這類錯誤？

我自己這邊的改善方式：

1.設計自動化 hooks 機制, 隨著規範與log學習經驗把關agent 的下線，定義agent 邊界。

設計資料表會請agent 先設計，再人去審核，重要的是流程有沒有辦法改善。

2.agent需要知道公司的開發範圍以及遵守事項，之後讓agent 根據手冊 和學習經驗，做個自我改善的guardrail hook 的 hooks 機制。

3. 每次執行的經驗都需要寫log和設計分類回饋器的分數，做個小型的ML 來輔助agent

4. Shadows機制

會監督是否有真的在執行，定義shadows的策略

紀錄>分類>分析>回饋>萃取>優化>更新 guardrail 

實際執行 → 記錄平行決策 → 蒸餾成規範 → 下次更好判斷

審閱 哪些會造成log 或萃取 可能會造成汙染或自我指涉

這邊我就列出在學習經驗中，在萃取時遇到的衝突：

這是在萃取經驗時，觸發了文件重複性，agent產生的報告。https://dogr2487.pintech.com.tw/test/other/review-boards.html 

會出現這個文件報告：

我在2/20 在執行某項任務 說edit 模式可以用 haiku

那在 2/25 在執行某項任務 說edit 不能用haiku

這2個都有記學習紀錄，但是要變成固有經驗的時候，到底哪個才是ok的，如果沒修正會造成agent 日誌污染，agent 不知道edit 文件的時候 到底能不能用haiku ，導致不穩。

-------

那這個報告怎麼產生，什麼時後判斷？這時候就可以定義hooks：

1.那什麼時候會偵測到「日誌有沒有污染」，什麼叫 有被污染的日誌？ 

2. 定義其他下限邊界

hooks 是在過程中，不斷從經驗中去學習+定義、shadows 也是。

PCS + SHADOW：會「監督自己做事」

----

後續可延伸的是：

* 自動QA AGENT （評估型agwnt)