brainstem 引擎的三個設計決定
把第二大腦引擎抽成公開 repo 時踩定的三件事:資料不跟工具同住、散佈選最笨的機制、同一個問題只准有一個解析器。
讓 AI 安全記帳:碰錢的工程紀律
AI 能不能碰帳本,取決於帳本本身設計得多嚴。六條工程紀律:從金額格式、餘額計算、方向語意、更正路徑,到解析閘與寫入確認——每條都把一個可能出錯的地方變成機械可驗的硬約束。
只賭你控得住的:三層受控性 + retro 把失敗串回目標階層
從三層受控性切計畫、從處境加權校分數、從 retro chain 把失敗串回目標階層——三個機制合用才能讓失敗真的教給你什麼。
資料餵進去不會壞:idempotent ingestion 的三條防線
冪等性應焊在資料層,不靠流程記得自己跑過沒——從確定性指紋、永久帳本到原子驗證邊界,正式環境的三條防線。
在正式環境跑 AI agent,我學到最反直覺的一課:加上去的架構要敢拿掉
iF.ai 的 agent 編排層走過四代,主線繞了一個完整的圈:直通 → 加雙會話編排器 → 減重 → 砍掉編排器退回直通(但更成熟)。每一代都是被上線痛點逼出來的取捨。它教我的不是某個架構多漂亮,是三件可遷移的判斷:剛性限制寫進 code 不寫提示詞、用客觀關卡判定每一步、知道何時加抽象、何時果斷移除。
擋住 agent 越權:把模型的弱點交給確定性 script
模型不擅長的不是推理,而是確定性執行——日期推算、指令注入、身分邊界、安全敏感動作。這篇整理我在自有 agent 工具裡用過的四個模式:把模型弱點外包 script 並 MUST 它先跑、用 stdin JSON 擋注入、委派已登入瀏覽器繞過 CF 防護、用 exit code 硬鎖跨 repo 工具的身分與輸出邊界。
別憑感覺重構:把『該先改哪裡』變成 agent harness 的一個確定性訊號
重構最貴的不是動手改,是改錯地方。這篇實戰記一個約 800 檔的 Flutter App 怎麼把『該先改哪裡』從直覺,變成一個可重跑、可驗證的確定性訊號——churn×複雜度的 hotspot 排序,接進 agent harness 當作判斷關卡。