可控湧現：AVL Code 的工程範式（下）——從理論到實踐與七條工程原則

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

上篇確定了湧現的概念邊界：功能性行為可以從系統中湧現，但不能據此推斷認知。中篇給出了方法：Harness 把能力接到真實世界，Loop 在無法完全建模的對象上實施回饋控制。

方法能不能落到一個真實產品上，是另一個問題：階段邊界是否由執行環境強制，目標能否跨回合持久化，權限能否真正拒絕越界動作，異常路徑有沒有兜底。本篇把這些方法對照到 AVL Code 的具體機制。

六、從理論到實踐：AVL Code 的 Harness 與 GOAL Loop

我們做 AVL Code，不是為了給某個 LLM 套上一層桌面介面，而是要把模型能力變成一套真正能在工程現場工作的 Agent 系統。模型負責提出候選行動，工作模式劃定階段，Context 組織當輪條件，Tool 與權限管理現實動作，GOAL 維持跨回合目標，檢查門禁提供事實證據，自癒與看門狗處理異常。我們要解決的不是「怎樣讓模型再多做幾步」，而是「怎樣讓一項長任務在真實環境中持續推進，並在完成、阻塞或越界時可靠停下」。這就是 AVL Code 對 Harness 與 Loop 的工程回答。

1. 用工作模式建立階段狀態機

AVL Code 使用者手冊定義了 auto、plan、prepare、execute、assess 五種工作模式，並推薦 plan → prepare → execute → assess 的階段流程。其中 plan 與 assess 是執行環境強制唯讀，不能靠提示詞或 Hook 繞過。

這項設計的系統意義不是給介面增加五個標籤，而是把不同階段的目標和可用執行器分開：

階段	主要任務	控制作用
auto	根據任務直接組織理解、行動與回饋	自動選擇行動路徑和 Tool，適合目標清晰、風險較低、無需嚴格分階段的小任務
plan	理解問題、讀取資訊、形成方案	在事實和方案未確認前保持執行器隔離，不產生寫副作用
prepare	整理依賴、環境和執行清單	降低執行階段的不確定性
execute	編輯、執行、測試和修復	開放必要執行器，進入閉環控制
assess	唯讀驗收與回顧	把「生成結果」和「評價結果」分離，避免邊評邊改掩蓋問題

auto 並不是 plan → prepare → execute → assess 中的一個固定工序，而是面向輕量任務的一站式自主模式：執行環境允許 Agent 根據當前 Context 直接選擇回答或呼叫 Tool，減少人工切換階段的成本。任務一旦涉及較大改動、需求歧義或較高風險，顯式進入分階段流程，仍然更容易建立確認點、權限邊界和驗收證據。

模式切換同時改變助手配置和 Tool 權限集合，說明階段邊界由執行環境實施，而不只是要求模型「自覺」。工作模式與 GOAL 並不是兩套互相替代的流程：模式回答「這一階段允許怎樣工作」，GOAL 回答「圍繞什麼目標持續推進、何時繼續或停止」。

2. 用 GOAL 持久化目標，用 Context 組織當輪狀態

中篇介紹的 GOAL 是會話級穩定控制狀態：它保存 Objective、active / paused / complete / budget_limited 狀態、Token 預算、用量與連續續轉計數。Context 則是每一輪重新組裝的工作面，承載當前目標區塊、歷史訊息、Tool 結果、專案指令以及執行中的局部狀態。把二者分開，才能避免把「目標仍然存在」誤解為「目標必須原樣佔據每一輪全部提示詞」。

AVL Code 支援將 AGENT.md、AGENTS.md 或 CLAUDE.md 作為專案指令注入 Context；Skill 用於封裝領域工作流；Plan 描述階段、輸入、輸出與風險；Todo 記錄待辦、進行中、完成、跳過或失敗狀態。GOAL 負責穩定主線，這些 Context 成分負責告訴模型當前處境和可用方法。

當歷史接近上下文上限時，Compact 會壓縮早期訊息，但保留計畫、待辦、關鍵 Tool 結論、使用者決策和必要事實。工具結果還會受到大小鉗制，發送前進行上下文容量預估。這些機制解決的不是「模型參數不夠聰明」，而是長程任務中的狀態可見性與訊號品質問題。

可以把 GOAL 理解為控制環的參考輸入與持久狀態，把 Context Harness 理解為狀態估計器：前者穩定回答「最終要去哪裡」，後者持續回答「現在在哪裡、哪些觀測可信、下一步還缺什麼」。

3. 用 Tool、權限與沙箱分離「建議」和「行動」

AVL Code 把檔案、命令、版本控制、程式碼智慧、安全分析和外部服務組織為 Tool。模型提出 Tool 呼叫後，執行環境仍要根據「啟用 / 詢問 / 禁用」三態權限決定是否執行；需要審批時，使用者會看到工具名、參數和影響範圍，逾時未回應按拒絕處理。

更重要的是，部分底線獨立於普通授權存在。例如 samples/ 樣本目錄強制禁用執行類工具，破壞性命令和危險注入仍受參數校驗。這條線在真實分析裡一直生效：無論是研判 fast16 惡意程式碼、還原 Darkhotel 藏在 JPEG 裡的隱寫酬載，還是核驗 Grok Build CLI 的離線安裝套件，樣本全程待在唯讀沙箱內。這裡體現了 Harness 的關鍵原則：

模型可以建議動作，但動作的合法性、權限和副作用邊界必須由模型之外的確定性機制裁決。

這既減少了非期望湧現的破壞半徑，也使更積極的功能性湧現成為可能——只有執行邊界可信，系統才適合獲得更大的行動空間。GOAL 可以請求系統繼續推進，卻不能繞過 Tool Schema、權限審批、路徑邊界或沙箱；持續性與行動合法性由不同層分別負責。

4. 用檢查門禁為 GOAL 回合提供事實回饋

中篇的圖 5 已經給出了 GOAL 的主控制環，這裡再放一次，便於對照：

AVL Code GOAL 會話級目標自動續轉機制 — 圖 5（回顧）：AVL Code GOAL 將目標注入、Agent 回合、用量核算、停止訊號、自動續轉與人工控制組織成會話級閉環。檢查門禁位於回合終點，不是另一套平行迴圈。

在這個環上，LSP 診斷、測試、Lint、SAST 和人工驗收不是另一套平行迴圈，而是回合終點的事實觀測與證據門禁。把它們直接畫成「修改—檢查—修復」的主迴圈，會遺漏持久目標、自動續轉、預算和人工接管等更關鍵的控制狀態。

啟用自檢門禁後，執行環境可以先執行選定檢查：失敗時把結構化結果寫回 Context 並要求 Agent 繼續處理；通過或沒有適用檢查時，再把續轉權交回 GOAL。門禁區分 block 與 report，限定檢查範圍並設定連續注入上限，避免 flaky 測試或不可修問題造成無窮迴圈。

兩者分工清晰：GOAL 決定「任務是否仍應推進」，檢查門禁回答「本輪結果是否獲得足夠證據」。前者維持目標、狀態、預算、自動推進和人工接管條件，後者提高觀測品質並阻止缺少證據的「假完成」。

5. 用自癒、預算和看門狗處理非理想執行

GOAL 處理的是正常回合之間的繼續與停止，現實執行還需要處理異常路徑：上下文超限、供應商過載、網路抖動、輸出截斷、重複推理和長期無進展。AVL Code 的自修復機制會按錯誤類別選擇壓縮重試、供應商兜底、退避重試或停止並交還使用者；同一檢查反覆失敗時會提示換思路，到達上限後停止。

子任務也設定閒置看門狗和絕對時間兜底；並行任務有並行數與等待上限；長程背景任務會保存進度並支援中斷恢復（多 Agent 並行分析 Android 銀行木馬用的正是這套並行機制）。它們共同回答了閉環系統最容易被忽視的問題：

如果觀測暫時缺失，是否誤判任務已經死亡？
如果持續有輸出但沒有進展，如何識別「忙碌式失穩」？
如果自動修復無效，何時停止消耗資源？
如果系統崩潰，狀態能否恢復而不是從頭猜測？

這些機制與 GOAL 的 Token 預算、終態錯誤停轉和 50 輪自動續轉上限共同構成多層保護。沒有這些邊界，「自主」很容易退化成無限迴圈；有了這些邊界，系統才可能在長任務中保持可預測的失敗方式。

6. 一次任務中的可控湧現

以「為現有服務增加輸入校驗並通過安全檢查」為例，AVL Code Harness 可以形成如下執行鏈：

使用者用 /goal 固化任務目標並按需設定 Token 預算，GOAL 進入 active；
在 plan 模式下唯讀掃描儲存庫、專案指令和相關 Skill，形成影響範圍、測試策略與風險說明；
使用者確認計畫後切換到 execute，執行環境把 GOAL 目標區塊與當前 Plan、Todo、檔案和歷史觀測組裝進 Context；
LLM 提出編輯或 Tool 呼叫，Tool 閘道完成參數校驗、權限判斷和必要審批後才作用於工作區；
LSP、測試、Lint 或 SAST 在回合終點傳回事實觀測；失敗結果被結構化寫回 Context，由 Agent 在下一輪繼續處理；
如果任務尚未完成且沒有停止訊號，GOAL 追加隱藏續轉訊息，保持同一目標自動進入下一回合，而不是等待使用者反覆輸入「繼續」；
技術門禁通過後，可切換到 assess 唯讀檢查 Diff、需求覆蓋和風險；確認達成時以 complete 收尾；
若需要使用者決策、發生終態錯誤、達到預算或連續續轉上限，執行環境停止自動推進並交還控制權。

這裡沒有哪一步需要假設「模型產生了意識」。但從系統邊界觀察，確實出現了任何單個部分都不具備的整體屬性：在組織規則和安全邊界內，圍繞持久目標跨回合感知、行動、糾錯，並在有證據或觸及邊界時收束。

這就是 AVL Code 所體現的功能性行為湧現，也是 Harness 工程試圖控制和放大的對象。

上面是一條示意性的執行鏈。真實的鏈條長什麼樣，不必靠想像：官網公開案例把每一次會話原樣掛了出來——智甲 EPP 自動巡檢與 CVE 漏洞掃描是一條典型的長任務閉環，等保 2.0 基線核查則展示了門禁與證據如何驅動結論。它們的推理、工具呼叫、報錯與恢復全程可查，也包括判斷失誤後退回重來的那幾步。這些機制寫在使用者手冊與參考手冊裡，同一套東西也運行在這些會話中——不是發布時補寫的承諾。

七、可控湧現的七條工程原則

1. 先定義系統邊界，再談智慧

明確評價對象是裸模型、帶 Context 的模型服務、Agent，還是包含人和組織流程的工程系統。邊界不同，屬性歸屬也不同。

2. 用可驗收行為描述湧現

少問「它是否真的會思考」，多定義「它能否在指定儲存庫、權限和時間預算內完成任務，並提交哪些證據」。

3. 把軟約束與硬約束分開

專案說明、Skill 和提示詞負責提高正確行為機率；權限、Schema、沙箱、審批、門禁和預算負責阻止不可接受行為。

4. 優先改善事實回饋，而不是無限加長提示詞

真實檔案、編譯器、測試、日誌和 Tool 執行結果，構成可核驗的事實回饋，通常比模型自我斷言更有價值。高品質、低雜訊、結構化的事實回饋，是閉環收斂的基礎。

5. 所有 Loop 都必須有停止條件

至少定義成功、失敗、阻塞、風險、時間、Token、重試和人工接管條件。不能停止的 Agent 不是更自主，只是更不可控。

6. 同時做 Verification 與 Validation

測試通過證明實作滿足某些技術條件，不證明需求一定正確；使用者滿意證明方向可能正確，也不證明實作沒有缺陷。

7. 把失敗軌跡變成系統資產

保留關鍵觀測、設計決策、有效模式和失敗反模式，並經過審查後進入組織知識。可控湧現不是一次性的「靈光」，而是跨任務累積出來的工程能力。

結語

LLM 是生成式 AI 系統的重要能力源，但不是完整的工程產品。真正把機率生成轉化為生產力的，是模型周圍的 Context、Tool、State、Policy、Loop、V&V 與 Human，以及它們之間經過設計的關係。

湧現告訴我們，系統整體可以具有部分所不具有的屬性；控制工程告訴我們，能力必須放進觀測—回饋—糾偏—停止的閉環；系統工程則要求我們從利害關係人目標、生命週期、風險和證據出發管理這個整體。三者結合起來，得到的不是「證明 AI 已經像人一樣思考」，而是一條更務實的道路：

不神化模型，不否認系統能力；不追求無邊界自主，而是用 Harness 約束行動、用 Loop 驅動收斂、用系統工程驗證整體價值。

從這個意義上說，AVL Code 的工程範式不是等待智慧神秘湧現，而是主動設計條件，讓有價值的功能行為更可能出現、被真實證據檢驗，並在失敗時被安全收束。這就是可控湧現。

可控湧現：AVL Code 的工程範式（下）
——從理論到實踐與七條工程原則