可控湧現：AVL Code 的工程範式（中）—

本文是《可控湧現：AVL Code 的工程範式》系列的中篇，全系列分三天發布：上篇《湧現不是魔法，而是系統屬性》（7 月 16 日）· 中篇（本文，7 月 17 日）· 下篇《從理論到實踐與七條工程原則》（7 月 18 日）。

上篇確定了兩件事：湧現是系統整體相對於部分多出來的、可觀察可測量的屬性；LLM 與 Context、Tool、執行環境結合後湧現的是功能性行為，而不是認知結論。

但「功能行為可以湧現」只回答了現象是什麼，沒有回答工程該怎麼做。模型只是提出建議，真正決定這些建議能否變成受約束的現實動作的，是模型之外的那一層結構。本篇討論這一層：Harness 負責把能力接到真實世界，Loop 負責讓系統在多輪執行中收斂並停下來。

三、Harness 工程：把模型能力接到真實世界

Harness 原意是挽具：它不替代動力源，卻把動力連接到方向、負載和制動系統。對生成式 AI 工程來說，Harness 是包圍模型的一組工程結構，負責把機率輸出轉化為受約束的任務執行。

一個實用的 Agent 系統可以近似表示為：

Agent\ System = LLM + Context + Tool + State + Policy + Loop + V\&V + Human

Agent 執行環境透過編排、授權和外部 Tool 把模型能力接入真實世界 — 圖 4：Agent 執行環境把 LLM 的機率決策交給編排與執行層，經檢核、授權和逾時控制後呼叫外部 Tool，再把結果寫回 Context；模型能力由此成為可約束、可回饋的現實動作。

其中，Harness 通常涵蓋模型之外的主要部分：

Harness 元件	回答的問題
模型與供應商適配	呼叫哪個模型，失敗時是否切換，參數如何設定
Context 組裝	哪些指令、檔案、歷史、Skill 和 Tool 結果進入本輪
Tool 閘道	模型能提出哪些動作，參數如何檢核，結果如何回寫
狀態管理	目標、計畫、待辦、工件、檢查結果怎樣持久化
權限與沙箱	哪些動作允許、需審批或必須拒絕
Loop 控制	什麼情況下繼續、換策略、重試、暫停或停止
驗證與評估	如何判斷「做對了」和「做的是對的事」
可觀測與恢復	如何審查軌跡、定位失敗、從中斷處繼續

Harness 不是一段更長的系統提示詞。提示詞、AGENTS.md 和 Skill 主要形成軟約束，透過 Context 改變輸出機率；權限檢核、JSON Schema、路徑邊界、審批、逾時、測試門禁和沙箱屬於硬約束，由確定性程式碼在模型之外實施。

約束方式	例子	能否強制保證
軟約束	「先讀程式碼再修改」「遵守團隊命名規範」	只能提高遵循機率
結構約束	Tool Schema、狀態機、限定輸出格式	可限制表達和流轉空間
硬約束	禁止寫入、沙箱、參數檢核、審批、預算上限	可在執行期拒絕越界動作
證據門禁	編譯、測試、Lint、SAST、人工驗收	可阻止未達標準的結果被宣告完成

生成式 AI 工程的關鍵，不是要求機率模型自己變成確定性程式，而是讓確定性機制管理它與現實世界的接觸面。

四、Loop 工程：在不完全模型上實施回饋控制

如果 Harness 決定「系統由什麼組成、邊界在哪裡」，Loop 決定「系統怎樣在多輪執行中保持目標、利用回饋，並在合適的條件下繼續或停止」。它不是「模型多回答幾次」，也不等同於「修改程式碼後反覆執行測試」，而是由目標狀態、Context 更新、動作執行、結果觀測、資源預算和停止條件共同組成的執行期控制迴路。

一次 Agent 循環仍可以抽象為：

\begin{aligned} z_k &\sim \pi_\theta(\cdot \mid C_k) \\ a_k &= G(z_k, P) \\ o_{k+1} &= E(T(a_k)) \\ C_{k+1} &= U(C_k, a_k, o_{k+1}, r) \end{aligned}

其中， $r$ 是目標與驗收標準， $z_k$ 是模型給出的文字或動作建議， $G$ 按權限策略 $P$ 檢核和放行動作， $T$ 是 Tool， $E$ 是外部環境， $o_{k+1}$ 是本輪獲得的事實觀測， $U$ 則把動作、結果和任務狀態重新組織進下一輪 Context。真正困難的不是寫出這組公式，而是把「繼續還是停止」從一句模糊提示變成可執行的狀態機。

AVL Code 的 GOAL 命令正是一個具體實作。它把長任務的目標、狀態、Token 預算、用量和連續自動續轉計數保存在 Session 中，使控制迴路不依賴模型臨時「記得自己還要做什麼」。

AVL Code GOAL 會話級目標自動續轉機制 — 圖 5：AVL Code GOAL 將目標注入、Agent 回合、用量核算、停止訊號、自動續轉與人工控制組織成會話級閉環。正常終態預設繼續；完成、等待使用者、終態錯誤、預算耗盡和連續續轉上限構成明確的停止條件。

1. GOAL 把長任務變成有狀態的閉環

使用者用 /goal <目標> 建立或更新目標，用 /goal budget N 設定 Token 預算，並可透過 pause、resume、complete、clear 控制生命週期。GOAL 的持久狀態只有 active、paused、complete 和 budget_limited 四種；目標發生變化時，下一輪會收到重新對齊引導，而不是沿著舊目標慣性繼續。

當 GOAL 處於 active 時，執行環境把目標區塊注入 Context，Agent 據此讀取環境、呼叫 Tool 或子代理並完成一個回合。回合終點到達後，系統先累計自身與子代理的 Token 用量和 Tool 呼叫，再執行續轉判定：

總用量達到預算，狀態轉為 budget_limited，停止自動續轉；
回合以終態錯誤結束，停止續轉但保留 active，把控制權交還使用者；
回應末行是 <goal-status>complete</goal-status>，狀態轉為 complete；
回應末行是 <goal-status>need-input</goal-status>，等待使用者提供必要決策；
其餘情況，包括沒有輸出標籤，均預設繼續：系統追加隱藏訊息「繼續推進目標」，自動啟動下一輪。

連續自動續轉超過 50 輪時，執行環境停止自動推進並提示使用者檢查進展；真實使用者介入會將連續續轉計數歸零。這裡體現的不是「讓模型自己決定一切」，而是由模型回報語意狀態，由確定性執行環境驗證訊號、記帳、遷移狀態並實施上限。

這與控制工程的基本思想同構，但對應關係已經從抽象比喻落到了可檢查的產品機制：

控制工程概念	AVL Code GOAL 中的對應物
參考輸入	Session 中持久化的 `Objective` 與使用者驗收要求
控制器	LLM 的動作建議 + GOAL 自動續轉判定
受控對象	程式碼庫、建置環境、外部服務及任務工件
致動器	Tool、子代理以及受權限控制的執行環境動作
觀測	Tool 結果、終態回應、錯誤和用量統計
狀態估計	Context、GOAL 狀態、Plan、Todo 與歷史摘要
控制動作	目標區塊注入、隱藏續轉訊息、暫停、恢復和人工接管
保護裝置	Token 預算、終態錯誤停轉、50 輪上限、權限與審批

測試、Lint、SAST 和人工驗收仍然重要，但它們是回合終點的觀測與門禁，可以接管一次續轉判定；它們不是 GOAL 主狀態機本身。GOAL 負責「圍繞什麼目標繼續、當前處於什麼狀態、還能消耗多少資源、何時必須停」，檢查門禁負責提供「這一步是否滿足技術約束」的事實證據。

2. 它不是傳統控制器的簡單複製

AI 工程中的「控制器」具有機率性，程式碼庫和外部服務是高維、離散、時變的環境，成功標準往往含有語意判斷，感測器也只能觀察局部狀態。工程師通常既沒有受控對象的完整模型，也無法證明每次動作都單調接近目標。

所以 Loop 工程不能直接套用一組固定的 PID 參數，而要吸收更一般的控制思想：

小步執行，縮短開迴路距離：一次修改越大，失敗後越難定位因果；
提高觀測品質：優先使用編譯器、測試、靜態分析和真實 Tool 結果，而不是讓模型猜測——複雜業務系統網路故障分析是個現成的例子，一樁五年未直接定位的網路沉痾，是從 2.2 GB 流量封包的證據裡一步步走到根因的，不是靠猜；
控制回饋增益：失敗資訊應相關、結構化、不過量，避免整段日誌淹沒有效訊號；
加入阻尼與保護：對重試、輪數、時間、Token、並行和副作用設置上限；
識別振盪和失穩：連續重複同一修復、反覆改回、待辦長期不前進時應換策略或停止；
保留人工控制權：高風險動作、需求歧義和不可逆變更必須設置確認點。

Loop 的目的不是「讓 Agent 永遠執行」，而是讓它圍繞穩定目標持續獲得事實回饋，並在完成、受阻、錯誤、預算或人工邊界出現時可預期地退出。AVL Code GOAL 的價值，正在於把這種繼續與停止的控制權從提示詞願望變成執行期機制。

五、系統工程：Harness 與 Loop 之上的完整視角

Harness 工程主要處理能力接入與邊界，Loop 工程主要處理執行期回饋與收斂；系統工程則要涵蓋從需求到除役的完整生命週期。

層次	核心問題	典型產物
Harness 工程	怎樣把模型、上下文、工具、權限和狀態可靠接起來	Tool 閘道、Context 管線、權限策略、狀態機
Loop 工程	怎樣根據觀測糾偏，何時繼續、換路或停止	回饋迴路、門禁、重試策略、預算、看門狗
系統工程	為什麼建、為誰建、整體是否滿足使命、全生命週期風險如何管理	需求、架構、V&V、風險、組態、維運和演進機制

SEBoK 的 Systems Engineering Core Concepts把元件、內部網路、外部環境、邊界、行為和歷史都納入系統描述，並把湧現與回饋視為系統科學的核心概念。這提示我們：AI 產品的 System-of-Interest不應只畫成一個模型 API，而應至少包括執行環境、工作區、Tool、組織規則、使用者和外部環境。

1. 驗證與確認是兩條不同的回饋線

SEBoK 的 System Verification強調用客觀證據檢查系統是否滿足規定的要求、架構和設計屬性；System Validation則關注系統是否在預期環境中滿足特定用途和利害關係人目標。用常見的工程說法：

Verification：是否把系統做對了？ 例如程式碼能否編譯、測試是否通過、權限是否按設計生效；
Validation：是否做了正確的系統？ 例如修改是否真正解決使用者問題、結果是否適合實際工作流。

只做測試門禁可能得到「全部測試通過，但需求理解錯了」的結果；只讓使用者憑感覺驗收，又可能漏掉實作缺陷。可控湧現需要機器證據與人的目的判斷共同閉環。

2. AI 系統的 V&V 必須貫穿生命週期

SEBoK 關於 AI 系統 V&V 的條目指出，AI 子系統存在判定 oracle 缺失、不可能百分之百準確、未測試輸入行為不確定、對訓練資料高度依賴等特徵。因此，V&V 不能是上線前的一次考試，而要進入需求、設計、整合、執行和更新全過程。

對 Agent 產品而言，這意味著既要評估模型，也要評估 Context 組裝、Tool 介面、權限策略、Loop 穩定性、失敗恢復以及人在迴路的流程。模型升級後，舊 Harness 的行為可能改變；Tool Schema 變化後，舊 Skill 可能失效；權限放寬後，同一個規劃能力可能產生不同風險。系統工程負責管理這些連動，而不是只比較模型排行榜。

小結與下篇預告

Harness 回答「系統由什麼組成、邊界在哪裡」，Loop 回答「怎樣根據回饋繼續或停止」，系統工程則要求我們從利害關係人目標、生命週期、風險和證據出發管理整體。

這三層說的都是方法。它們能不能落到一個真實產品上，是另一個問題：階段邊界是否由執行環境強制，目標能否跨回合持久化，權限能否真正拒絕越界動作，異常路徑有沒有防護網。下篇《從理論到實踐與七條工程原則》（7 月 18 日發布）將把這些方法對照到 AVL Code 的具體機制——工作模式、GOAL、Tool 與權限、檢查門禁、自癒與看門狗——並給出可控湧現的七條工程原則。

參考資料

系統工程主要資料

AVL Code 主要資料

AVL Code，AVL 安全引擎，與智慧隨行。安天瀾砥團隊出品。