可控湧現：AVL Code 的工程範式（上）——湧現不是魔法，而是系統屬性

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

當大語言模型進入程式碼倉庫，獲得 Context、Tool、權限與事實回饋後，它開始表現出單次文字生成所不具備的能力：讀取工程、規劃步驟、修改檔案、執行測試，再根據錯誤繼續修復。面對這種現象，真正值得討論的不是「模型是否突然覺醒」，也不能用「不過是下一個 Token 預測」將其一筆抹平，而是三個更具體的問題：這些新能力屬於誰，如何產生，又怎樣被約束為可驗證、可停止、可交付的工程行為？

答案首先取決於我們怎樣劃定系統邊界。如果把研究對象從孤立的 LLM 擴大為完整的生成式 AI 系統，許多現象會清楚得多：模型生成候選內容，Context 提供當前條件，Tool 把符號輸出變成外部行動，執行環境組織循環，權限與測試約束行動邊界，人在關鍵節點確認目標與風險。單看其中任何一個部分，都沒有「自主完成軟體工程任務」的能力；這些部分按特定結構連接後，系統整體卻能表現出這種能力。

這正是「湧現」一詞在系統工程中的正常含義。本系列的核心觀點可以概括為：

湧現是系統整體產生部分所不具備的新屬性，不是偽科學，也不是對未知機制的神秘化命名；
LLM 與 Context、Tool、執行環境結合後出現的是可觀察、可測量的功能性行為湧現，不能據此直接推斷認知、意識或主體性已經湧現；
生成式 AI 的工程對象不是裸模型，而是模型外部的 Harness（挽具、駕馭層）及其包圍的完整系統；
Loop 工程把回饋、誤差、狀態、控制量與停止條件引入機率性 AI 系統，是控制工程思想在不可完全建模對象上的實踐；
Claude Code、Codex 與 AVL Code 等 Agent 的工程價值，正在於把模型能力組織成一個有階段、有工具、有回饋、有門禁、有預算、可恢復的 Harness。

其中第 1、2 點是本篇（上篇）的內容；第 3、4 點在中篇展開；第 5 點在下篇落到 AVL Code 的具體機制上。

本系列中「功能性行為湧現」與「認知性智慧湧現」是為澄清工程邊界提出的工作性區分，不是 SEBoK 已有的術語分類。

可控湧現：AVL Code 將 Context、Tool、Loop 與 V&V 組織成受控的 Agent Harness — 圖 1：AVL Code Harness 將 Context、Tool、Loop 與 V&V 組織起來，使大量局部單元形成可驗證的系統級行為。

一、湧現不是魔法，而是系統屬性

SEBoK 的 Emergence 條目將湧現概括為：某些屬性只有歸屬於整體時才有意義，而不是其組成部分各自擁有的屬性；Emergent Property 術語表進一步強調，這類屬性只有在系統組織的更高層次上才具有意義。系統級行為來自元素的屬性、元素之間的關係、系統結構以及環境刺激的共同作用。

飛機的機翼不會獨自「受控飛行」，發動機與控制系統也不會；當氣動結構、推進、控制、感測器與駕駛操作以正確關係結合時，飛行才成為飛機整體的屬性。同樣，一次北美大停電不一定源於某個設備單點損壞，也可能由系統連接方式與運轉條件共同觸發級聯失效。湧現既可能是設計者追求的能力，也可能是設計者必須抑制的風險。

因此，湧現並不是「無法解釋，所以歸因於神秘力量」。一個有工程意義的湧現命題，至少應回答五個問題：

問題	工程含義
系統邊界是什麼	被觀察的是模型、Agent 執行環境，還是包含人與組織流程的更大系統
組成部分是什麼	模型、Context、Tool、狀態、權限、測試、使用者分別承擔什麼職責
關係是什麼	資訊與控制如何在部分之間流動，哪些關係形成回饋
新屬性是什麼	系統整體比單個部分多出了什麼可觀察、可測量的能力
在什麼條件下出現	哪些任務、環境、閾值與評價指標會觸發或掩蓋該屬性

如果這些問題無法回答，「湧現」就可能只是修辭；如果能夠回答，它就是普通而嚴肅的系統科學概念。

1. 三種經常被混淆的「湧現」

圍繞大模型的討論至少混用了三種不同問題：

討論對象	所謂「湧現」	應如何驗證
模型規模	大模型在某項基準上突然超過閾值	檢查尺度、資料、指標連續性與統計方法
AI 系統	LLM、Context、Tool、Loop 組合後完成單體不能完成的任務	在系統邊界上做任務測試、消融實驗與執行觀測
認知哲學	系統是否具有理解、意向性、自我意識或主觀體驗	需要額外的認知理論與證據，不能由任務成績直接推出

關於第一種含義，Wei 等人的論文 Emergent Abilities of Large Language Models將某些小模型沒有、較大模型才出現的基準能力稱為「湧現能力」；Schaeffer 等人的 Are Emergent Abilities of Large Language Models a Mirage?則指出，部分突變可能來自非連續評價指標，換成連續指標後效能變化會變得平滑。這個爭論說明：「跨過評價閾值」與「系統產生了新的本體屬性」不是一回事。

本系列討論的重點是第二種：工程系統的功能性行為湧現。它不依賴「規模曲線是否突然跳變」，也不要求先證明機器具有心智；只要求我們誠實地描述整體系統相對於部分增加了哪些功能，並用測試與執行證據檢驗這些功能。

2. 「可控」不等於每個 Token 都可預測

SEBoK 區分了較易預測的簡單湧現、只能預期但難以精確預測其水準的弱湧現，以及在模擬、測試乃至執行期才暴露的意外湧現。它同時強調，期望的湧現通常要透過建模、迭代以及 build/test 循環逐步獲得。

所以「可控湧現」並不是聲稱工程師能預先確定模型的每一個輸出，而是指：

透過系統結構、上下文、權限、回饋、驗證、預算與人工決策，提升期望行為出現並通過驗收的機率，同時限制非期望行為的影響範圍。

控制對象不是單個 Token，而是任務軌跡與系統結果；控制目標也不是絕對確定性，而是可接受的成功率、風險、成本、延遲與可恢復性。

二、LLM + Context 湧現的是功能行為，不是認知結論

一次 LLM 生成可以抽象為：

y_t \sim P_\theta(\cdot \mid C_t)

其中，參數 $\theta$ 保存訓練形成的統計結構， $C_t$ 是本輪可見的 Context， $y_t$ 是模型生成的文字或結構化動作建議。僅憑這個過程，模型不能直接讀取一個未提供的本機倉庫，不能真正執行編譯器，不能知道命令是否成功，也不能讓錯誤修改自動回滾。

但是，當工程系統把倉庫檔案、使用者目標、專案規範、Tool Schema、執行結果與測試回饋持續寫入 Context，再由執行環境執行模型提出的動作時，系統整體可以形成這樣的軌跡：

理解目標 → 檢索倉庫 → 制定計畫 → 修改程式碼 → 執行測試
        → 讀取失敗 → 定位原因 → 再次修改 → 驗收交付

這條軌跡不是任何單個元件獨自擁有的能力：LLM 不執行命令，Shell 不理解需求，測試框架不制定修復策略，權限模組不寫程式碼。「圍繞目標進行多步軟體工程並根據真實結果糾錯」是這些部分按特定關係組合後才成立的系統級功能。

它也不是紙上推演。官網公開案例裡的每一次會話回放，都是這條軌跡在真實倉庫、真實樣本上跑完的記錄——例如把一張需求心智圖端到端做成企業級監控系統，或者在只有一個離線安裝包、沒有原始碼的前提下核驗一款閉源客戶端的資料邊界。推理、工具呼叫、報錯與恢復全程可查，包括走錯又退回的地方。

1. Context 是模型的執行條件，也是 Agent 的狀態載體

Context 對輸出分布的影響可以寫成：

P_\theta(y_t \mid C_t) \neq P_\theta(y_t \mid C_t + \Delta C)

Context、LLM、Tool 與執行環境之間的關係 — 圖 2：LLM 基於當前 Context 生成 Tool 呼叫建議，執行環境執行動作並把結果寫回 Context。

加入專案規範、相關程式碼或一次測試失敗，不會修改模型參數，卻會改變下一步輸出與行動的條件。Context 在工程系統中至少承擔三種角色：

任務條件：目標、範圍、約束、驗收標準；
狀態估計：已經做了什麼、當前做到哪一步、哪些假設已被證偽；
外部觀測：檔案內容、命令輸出、測試結果、使用者審批。

這也是為什麼「同一個模型」放進不同 Harness 後表現會顯著不同。模型能力提供可能性空間，Context 決定當前可見的局部條件，執行環境則決定哪些輸出能成為現實動作。

2. 必須把幾種「知識」分開

在 AI 討論中，「模型知道」「Context 給了知識」「系統學會了」經常被當作同一件事。工程上更適合分層描述：

層次	載體	作用	侷限
參數化統計知識	模型權重	提供語言、程式碼與任務模式的先驗	可能過時、失真，來源通常不可逐條追溯
上下文知識	當前提示與訊息	提供任務相關事實、規則與範例	受視窗容量、排序與雜訊影響
外部可驗證知識	檔案、資料庫、文件、Tool 結果	提供當前環境中的事實證據	需要權限、檢索、時效與來源校驗
執行狀態知識	Plan、Todo、呼叫結果、錯誤記錄	讓多步任務保持連續性	需要結構化保存、壓縮與恢復機制
組織知識	AGENTS.md、Skill、流程、門禁策略	固化團隊做事方式與品質標準	軟性說明仍可能被模型偏離，硬性要求需由執行環境強制執行

不同知識如何進入 Agent，並在 Context、執行狀態與長期記憶之間流動 — 圖 3：不同知識並不是同一層東西。模型權重提供先驗，外部事實與組織知識進入當前 Context，執行狀態在行動與回饋中持續更新，跨會話經驗則透過審核後的長期記憶按需召回。

知識在系統中的價值，不只取決於「有沒有」，還取決於它是否在正確時刻被召回、是否與任務相關、是否可驗證、是否能進入回饋閉環。

AVL Code 的「記憶宮殿」

如果把跨會話知識看作一座需要路線與門禁的「記憶迷宮」，那麼 AVL Code 使用者手冊中的正式名稱是「記憶宮殿」。會話結束後，HookStop 會擷取記憶候選，先放入 _pending/ 草稿盒；只有經過使用者審閱批准，候選才進入相應房間。使用者也可以用 /memorize <text> 主動寫入，用 /memory 開啟管理面板。

真正進入下一輪的不是整座宮殿，而是與當前問題相關的少量記憶：系統綜合召回次數與使用成效調整排序，減少無關注入；遇到重複或衝突時先放入待審區，而不是直接覆蓋舊知識。這個「候選—審核—入庫—召回—成效回饋」閉環，改善的是事實與經驗的回饋品質，而不是無限加長提示詞。

3. 行為能力不能直接證明認知狀態

當系統能夠解釋程式碼、呼叫工具、修復測試時，說它「表現出程式設計能力」是一個可檢驗的功能描述；說它「理解了程式碼」「知道自己犯錯」「產生了自我意識」，則引入了更強的認知與哲學主張。

Bender 與 Koller提醒研究者區分語言形式與意義，Shanahan則提醒人們謹慎使用「知道」「相信」「思考」等容易造成擬人化的詞。對這些問題可以繼續研究與爭論，但工程上應守住一條證據邊界：

能夠產生與理解相似的行為，不等於已經證明系統具有與人同類的理解機制；能夠執行智慧任務，也不等於已經證明主體性或意識湧現。

因此，本系列所說的「智慧」優先指可測量的任務能力，而不是對系統內在體驗的斷言。

小結與下篇預告

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

但「功能行為可以湧現」只回答了現象是什麼，沒有回答工程該怎麼做。如果模型只是提出建議，那麼真正決定這些建議能否變成受約束的現實動作的，是模型之外的那一層結構。中篇《Harness 工程與 Loop 工程》（7 月 17 日發布）將討論：Harness 如何把模型能力接到真實世界，以及 Loop 如何在一個無法完全建模的對象上實施回饋控制、並給出明確的停止條件。

參考資料

系統工程主要資料

補充論文

Wei, J. et al.（2022）：Emergent Abilities of Large Language Models，arXiv:2206.07682。
Schaeffer, R., Miranda, B. & Koyejo, S.（2023）：Are Emergent Abilities of Large Language Models a Mirage?，arXiv:2304.15004。
Bender, E. M. & Koller, A.（2020）：Climbing towards NLU: On Meaning, Form, and Understanding in the Age of Data，ACL 2020，DOI: 10.18653/v1/2020.acl-main.463。
Shanahan, M.（2022，2023 年修訂）：Talking About Large Language Models，arXiv:2212.03551。

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