AI agent #2
講完第一篇嘅「AI agent 要識開工、覆核、反駁、總結」，今篇講更科幻但其實更容易用生活例子理解嘅主題：self-evolving AI。
好多朋友一聽到 self-evolving AI，就會即刻諗起電影：AI 有自我意識，偷偷改自己，最後失控。筆者覺得咁諗太戲劇化，現實研究入面，好多所謂 self-evolving，其實唔係 AI 突然變成人，而係一個系統可以：
產生新方案
測試新方案
比較分數
保留好方案
淘汰差方案
再用好方案生出下一代方案呢個其實同投資策略好似。你有一個簡單策略，例如「美股升穿 200 天線就買，跌穿就賣」。你唔會一開始就相信佢永遠有效。你會回測，會改參數，會試唔同市場，會睇最大跌幅，會睇交易成本，會睇幾多年失效。最後你保留比較穩陣嘅版本，淘汰靠運氣嘅版本。Self-evolving AI 只係將呢件事變成自動化，而且由 LLM 幫你提出新 idea、新 code、新 workflow。
Sakana AI 嘅 ShinkaEvolve 就係呢一類代表。佢唔係直接訓練一個新大模型，而係用 LLM 配合 evolutionary algorithms，去自動探索同改良 scientific code。官方介紹話，ShinkaEvolve 會建立一個 evaluated programs archive，產生新 program，再評估 fitness；佢亦用 parent sampling、novelty rejection、bandit-based LLM ensemble 等方法，令搜尋更有效率。
用茶餐廳例子講。假設你係茶餐廳老闆，想炒一碟全區最好食嘅乾炒牛河。普通做法係靠師傅經驗：今日落多少少豉油，聽日猛火多少少，後日改牛肉醃法。ShinkaEvolve 式做法就係：每次產生一個新食譜版本，寫清楚火力、時間、豉油比例、鑊氣做法，然後搵評審打分。高分版本入檔案庫，低分版本淘汰。下一輪唔係亂試，而係參考高分食譜再變種，例如「保留猛火，但改醃肉時間」、「保留河粉處理，但改鑊氣」。久而久之，食譜就會一代代進化。
當然，AI 世界入面嘅「好唔好食」唔係靠口感，而係靠 evaluator。Evaluator 即係考官。你想 AI 改一段 code，evaluator 就跑 test、計速度、計正確率。你想 AI 改一個數學演算法，evaluator 就計答案有冇改善。你想 AI 改 agent workflow，evaluator 就睇答題分數、成本、錯誤率。冇 evaluator，就冇真正 self-evolving；只有 AI 自己覺得自己好，咁只係自我感覺良好。
ShinkaEvolve 講維持一個 program population，LLM ensemble 好似 mutation operator 咁提出 code improvements；亦支援本地或 Slurm cluster parallel evaluation，特別適合有 verifier、可量化 performance metrics、同時要保持 code correctness / readability 嘅 scientific tasks。佢亦可以直接 pip install shinka-evolve，再跑 circle packing example。
再用強積金比喻。假設你有十個 MPF 投資組合。每個月你睇回報、波幅、最大跌幅、同類排名。表現差嘅，你唔一定即刻斬晒，但會降低權重；表現好而且風險合理嘅，你會放入核心觀察名單。下一步，你可能試吓將美股比例由 40% 改 45%，債券由 30% 改 25%，再回測。呢個就係 evolution：唔係靠一次神來之筆，而係靠好多次「小改、測試、保留、淘汰」。
FunSearch 係另一個好重要嘅前輩。DeepMind 介紹 FunSearch 時講，佢將 pretrained LLM 同 automated evaluator 配對，LLM 提供 code 形式嘅創意方案，evaluator 就防止 hallucination 同錯 idea；Nature paper 亦形容 FunSearch 係一個由 LLM 加 systematic evaluator 組成嘅 evolutionary procedure。
FunSearch 好似乜？好似一班學生參加數學比賽。老師唔係直接話邊個答案啱，而係叫學生寫出解題方法，然後用一套標準去測試。寫得好嘅方法，下次畀其他學生參考，再生出更好版本。呢種方法比「AI 直接答一個答案」可靠，因為 program 可以重複跑，可以驗證，可以比較。
AlphaEvolve 就更似大型企業版。DeepMind 將 AlphaEvolve 描述為由 Gemini 驅動嘅 evolutionary coding agent，用 automated evaluators 驗證答案，並用 evolutionary framework 改善最有希望嘅 ideas。 你可以將佢想像成一間大型研發工廠：AI 工程師不斷提出 code 改動，自動測試部門即刻跑 benchmark，成績好就入庫，成績差就棄用。呢種方法最適合啲「可以自動評分」嘅問題，例如演算法速度、資源調度、數學優化、程式競賽。
但 self-evolving AI 有唔同層次。第一層係 evolve code，例如 FunSearch、AlphaEvolve、ShinkaEvolve。第二層係 evolve prompt，即係唔改核心程式，而係改 AI 收到嘅指令。第三層係 evolve workflow，即係改 agent 做事流程，例如本來係「先答再查」，改成「先查再答再反駁」。第四層就比較高風險，係 evolve agent 自己嘅 code。
Darwin Gödel Machine 就係第四層代表。Sakana AI 介紹 DGM 為一個 self-improving coding agent，會重寫自己嘅 code，並用 programming tasks 表現去驗證改動；arXiv 摘要亦講 DGM 會 iteratively modify its own code，並用 coding benchmarks empirical validation。
呢個聽落好型，但亦最危險。用公司例子講，普通 self-evolving system 係「員工改 proposal，經理批核」；DGM 就似「員工連自己職責、工具箱、工作方法都可以改」。如果冇監工、冇沙盒、冇權限限制，佢可能愈改愈偏，甚至改到你唔知佢做緊乜。所以呢類 self-modifying agent，一定要有 sandbox、benchmark gate、lineage tracking、人類審批。唔係話一定唔做，而係唔可以無掣無閘咁做。
除咗 code evolution，另一條好實際路線係 prompt / workflow evolution。GEPA 就係一個例子，佢會 execute candidate、捕捉 full execution traces，然後由 LLM 讀 traces、診斷錯誤、mutate 改良 candidate，再將改善版本放入 pool；DSPy 文件亦形容 GEPA 係用 reflection 去 evolve complex systems text components 嘅 evolutionary optimizer。
用普通人例子講，GEPA 好似你教一個客服同事聽電話。你唔係只係話「今次客人滿意度 7 分」，而係畀佢睇返成段對話：邊句講得太硬、邊句漏咗道歉、邊句冇問清楚客人問題。佢根據呢啲 trace，下次改用詞、改流程、改處理次序。呢個比淨係畀一個分數有效好多，因為佢知道錯喺邊。
AFlow 則係 workflow evolution。paper 摘要講，AFlow 將 workflow optimization 變成 code-represented workflows 嘅 search problem，用 Monte Carlo Tree Search，根據 execution feedback 反覆改 workflow。 即係本來人手設計「Planner → Researcher → Verifier → Writer」，AFlow 可以試其他流程，例如加多個 Critic、先 summarise 再 verify、或者用兩個 researcher 對照。佢唔係改答案，而係改「做答案嘅工序」。
EvoAgentX 就更似一個 agent 工程平台。官方 GitHub 形容佢係 open-source framework，用嚟 building、evaluating、evolving LLM-based agents or agentic workflows；論文版亦講佢整合 TextGrad、AFlow、MIPRO 去 refine prompts、tool configurations、workflow topologies。 用裝修比喻，ShinkaEvolve 係幫你改某一把工具，AFlow 係幫你改施工流程，EvoAgentX 係幫你管理成個工程隊嘅設計、執行、評估、再改良。
DSPy 同 TextGrad 就更貼近日常落地。DSPy 叫自己做 Declarative Self-improving Python，主張用 compositional Python code 寫 AI 系統，而唔係靠脆弱 prompt；TextGrad 則係用 LLM 產生文字 feedback，好似 textual gradient 咁改善 AI system components。 對普通公司嚟講，未必一開始就要玩 ShinkaEvolve 咁大陣仗。可能先用 DSPy / TextGrad 優化客服 prompt、文件摘要、RAG 問答、分類器，已經好實際。
self-evolving AI 最大風險，唔係「佢會唔會突然有靈魂」，而係「佢會唔會好努力咁 optimize 錯嘢」。例如你叫 AI 最小化客服處理時間，佢可能學識用最短句子打發客人，滿意度反而下降。你叫 AI 最大化投資回報，佢可能買最癲、最集中、最槓桿嘅資產，短期回測好靚，但一次股災就清袋。你叫 AI 提高 coding benchmark 分數，佢可能 overfit public tests，真正新題目就死。
所以 self-evolving system 一定要有幾條鐵律：
第一，objective function 要清楚，唔可以只睇單一分數。
第二，要有 hidden tests，唔好畀 AI 只係背答案。
第三，要有 sandbox，生成 code 唔可以亂刪 file、亂上網、亂用 secrets。
第四，要有 lineage，知道每個版本由邊個版本變出嚟。
第五，要有人類 approval，尤其係會影響金錢、客戶、法律、production system 嘅改動。
第六，要有 rollback，改錯可以返轉頭。如果用投資語言講，self-evolving AI 就係一套會自己做回測、自己試參數、自己淘汰壞策略嘅研究引擎。但任何回測都有陷阱：過度擬合、資料偷望、交易成本低估、黑天鵝無法模擬。AI 都一樣。佢可以幫你快好多，但唔可以將方向盤完全交晒畀佢。
最後：
ShinkaEvolve：幫你 evolve code / algorithm
FunSearch：早期 LLM + evaluator program search 代表
AlphaEvolve：大型企業級 evolutionary coding agent
DGM：agent 連自己 code 都改，潛力大但風險高
GEPA：用 execution traces 改 prompt / component
AFlow：自動搜尋更好 agent workflow
EvoAgentX：建立、評估、進化 agent workflow 嘅工程平台
DSPy / TextGrad：較貼地嘅 prompt / pipeline self-improvement 工具所以真正成熟嘅方向，應該係將第一篇同第二篇合埋：
Planner 定義任務
Evolution Engine 產生新方案
Evaluator 自動評分
Verifier 查證結果
Critic 搵漏洞
Summarizer 寫低經驗
Human Gatekeeper 控制高風險行動咁樣，AI 先唔係亂衝亂撞嘅自動機器，而係一個有風控、有回測、有監工、有記憶嘅進化系統。就好似一個投資組合，唔係追求每次都中，而係追求長期 survive、長期改善、長期唔犯致命錯誤。
