在正式環境跑 AI agent,我學到最反直覺的一課:加上去的架構要敢拿掉

把 AI agent 放進正式環境之前,我以為難的是「怎麼讓它更聰明」。真正上線之後才發現,難的是另一件更反直覺的事:你為了讓它跑起來而加上去的架構,後來要敢親手拿掉。

這課是 iF.ai 教我的。它的 agent 編排層走過完整四代,而且主線繞了一個圈:直通 → 加上編排 → 減重 → 砍掉編排、退回直通(但更成熟)。 每一次轉向都不是為了架構好看,是被正式環境的真實痛點逼出來的。底下這四代,我當作這三條判斷的證據來講。

第一代:直通——能用,但用戶看不懂

最早就是把用戶直接接到底層的 AI coding 引擎,事件用 SSE 串回前端。鏈路能跑,但問題立刻浮現:開發流程裡每個審查關卡,只有工程師看得懂、答得出。一個非技術用戶看到「要不要採用這個資料庫結構」整個人就卡住了。

第二代:雙會話編排器——派一個 AI 當用戶的代理人

於是加了第二個 AI 會話當「編排器」,它的根本職責是當用戶的代理人:替用戶在那些技術審查關卡上回答、決定何時進下一步。用戶只要丟需求、用畫面調整,技術問題它代答。乾淨的抽象邊界在於——做事的那個 AI 完全不知道代理人存在,它以為自己一直在跟真人對話。

這一代立下一條到現在都沒變的原則,也是我的第一條判斷:剛性限制寫進設定檔,由引擎原生權限機制強制,不寫在提示詞裡。 iF.ai 的 tier(小白 / PM / 工程師三級)權限就是這樣做的——因為寫在提示詞的限制模型偶爾繞得過,寫進設定檔的繞不過。你給 agent 什麼權限,引擎層就硬性決定它能做什麼。

第三代:輕量編排器——別賭模型穩定吐字串

第二代用字串標記在兩個會話之間傳話,但模型偶爾就是不照格式吐,得用一堆正則加備援去補,很脆。第三代把它換成結構化的工具呼叫(走 tool use):結構化、可驗證、不會解析失敗。派工只能走一份允許清單,不在清單上的直接擋掉——清單本身就是流程步驟。

教訓很單純:agent 之間的協定要用結構化 tool call,不要賭模型每次都穩定吐出你要的字串格式。

第四代:單 AI——果斷把編排器整個拿掉

到第四代,我做了一個看起來像退步、其實是成熟的決定:把整個編排器砍掉,退回直通。

為什麼?編排那層的效果不夠好又太慢(雙會話的延遲一直疊加),而 LLM 這段時間變強了,強到可以把整套流程控制與限制內化進 system prompt / 設定檔來表達。既然如此,那層抽象就沒有存在的必要了——果斷移除,更快也更穩。

這是我的第二條判斷,也是整篇最想留下的一句:抽象可加、可換、可拿掉,判斷依據永遠是效果,不是對已經投入的架構捨不得。 退回直通不是退步,是因為那層真的不再划算了。知道何時該加抽象、何時該果斷移除,本身就是工程成熟度。

一條沒上線的平行實驗:獨立評審

主線之外,我還做過一條沒上線的實驗:依任務階段選用不同成本的模型,並用一個獨立的評審會話判斷「這個階段到底完成了沒」,完成才觸發轉場。

重點在那個「獨立」,也是我的第三條判斷:階段完成與否,不由做事的那個 AI 自己說了算。一個對錯誤答案都很有信心的東西,你不能讓它自我審查。寫的跟審的必須是兩個獨立的脈絡,才有真正的第二意見。凡是能用外部 script 卡住的把關,就留在外部當最後一道防線。

三條帶得走的判斷

四代繞完一圈,如果你也要把 AI agent 帶進正式環境,我會把這三條交給你:

剛性限制寫進 code,不寫在提示詞——繞不過的才叫限制。
每一步用客觀、可驗證的關卡把關——不讓做事的 AI 自稱「做完了」。
知道何時加抽象、何時果斷移除——判準是效果,不是沉沒成本。

模型會一直變強,會吃掉你今天寫的一部分架構。所以這層結構要薄、要解耦、要敢拿掉。走完這一圈我最確定的是:真正難、也真正值錢的,從來不是模型本身,是模型外面那層你看得見、控得住的工程——也就是 Harness。

iF.ai 是什麼、它怎麼讓非技術用戶用聊天做出軟體,我寫在另一篇〈iF.ai:讓不會寫程式的人,用聊天把軟體做出來〉。