← 返回書籍首頁

Havenlon Research · 線上閱讀

執行縫隙

The Execution Gap

Execution Engineering Trilogy · Book I

繁體中文210 分鐘閱讀14 個章節
目錄

前言|問題先於答案

我最初並沒有打算寫一本關於“執行縫隙”的書,更沒有計劃一開始就寫三本。

最早擺在我面前的,只是一些具體的工程問題:一個系統裡,意圖已經被表達,審批已經完成,權限已經存在,策略也已經命中,所有能夠被檢查的東西看上去都沒有問題,可最後真正發生在現實裡的事情,仍然可能和最初想要發生的事情不是同一件事。

這種問題並不好描述。

在軟件工程裡,我們會找 bug;在安全工程裡,我們會檢查身份、權限、攻擊面和越權;在治理系統裡,我們會問審批是否完整、規則是否健全;到了 AI Agent 時代,人們又很自然地把問題歸到模型幻覺、推理錯誤或者自主性過高。

這些解釋都可能成立,卻沒有完全覆蓋我真正想問的問題:

這些分別成立的東西,為什麼最終能夠推出這一次現實動作應該發生?

HAVENLON 的工程工作讓我不斷遇到這個問題。隨著系統真正開始接觸資金、設備、賬戶和生產環境,一些原本散落在工程中的判斷逐漸匯到了一起:

Intent 不等於 Execution。

Authorization 不等於 Execution。

Policy 成立,不等於現實動作就應當發生。

一個主體是否有資格做一件事,與它這一次判斷是否正確,也不是同一個問題。

這些判斷最後共同指向了一個問題:執行縫隙。

《執行縫隙》不是從一個已經完成的理論出發,再去尋找案例證明它。過程恰恰相反。我們先遇到了一批難以歸類的工程現象,再不斷檢查:它是不是普通 bug,是不是訪問控制問題,是不是審批問題,是不是 AI 特有的問題,是不是攻擊造成的。

現實案例沒有替理論作證明,它們真正做的,是迫使理論不斷縮小自己的邊界。因為如果“執行縫隙”能夠解釋所有壞結果,它也就失去了意義。

所以這本書不僅討論什麼是執行縫隙,也認真討論:

什麼不算執行縫隙。

這項工作後來展開成三本書:《執行縫隙》討論問題是什麼,《執行控制工程》討論現實執行怎樣被控制,《對抗性完整》繼續追問,當參與控制的主體和系統本身也可能失陷時,什麼仍然必須成立。

但第一本書不會急著給出完整解決方案。因為如果一邊定義問題,一邊又用某一種方案塑造問題,最後得到的很可能只是為方案量身定做的理論。

我更希望“執行縫隙”首先能夠獨立成立。

在 AI 時代,這個問題正在變得更重要。過去的軟件更多處理信息,越來越多的 AI 系統則開始處理行動:調用工具、修改狀態、移動資金、操作設備,並最終把一個判斷變成現實。

於是安全問題不能只問它知道了什麼、有沒有權限,還必須繼續問:

是什麼讓這一次動作真正發生了?

AI 放大了這個問題,但並沒有創造它。

這本書不會回答所有問題。有些問題甚至會被刻意留下,因為這項工作始終遵守一個簡單的原則:

不知道的事情,就應該保持不知道。

在真正討論怎樣控制執行之前,我們至少應該先確認:

我們面對的究竟是什麼問題。

《執行縫隙》從這裡開始。

王林 · 2026 年 9 月 · 成都


致謝

這套工作的形成,並不是我一個人的結果。

首先要感謝吳夢婷、張勇和鄧江。作為本書的聯合作者,他們共同參與了這套理論從工程問題、研究材料到逐漸成形的過程。書中最終留下來的許多判斷,並不是某一個人在某個時刻突然想到的結論,而是在持續的工程實踐、研究討論和反覆校正中逐漸形成的。

也感謝所有參與 HAVENLON 工程與研究工作的夥伴。

很多理論判斷並不是在安靜的書桌前形成的,而是在一次次架構爭論、協議設計、硬件實現、失敗復盤和工程取捨中被逼出來的。產品不斷提出理論沒有回答的問題,理論又反過來要求產品解釋:為什麼必須這樣設計,而不是那樣設計。

感謝參與論文、資料整理、案例核驗和研究工作的同事與合作者。把一個直覺變成可以公開討論的判斷,需要大量並不顯眼的工作:尋找原始資料,確認時間線,區分事實與解釋,檢查案例邊界,然後一次次刪掉那些“聽起來合理,但材料並沒有真正證明”的句子。

我也要感謝那些留下公開記錄的人和機構。

事故調查、司法材料、監管報告、工程復盤、研究論文以及技術文檔,讓很多原本只能停留在思想實驗中的問題有了可以被檢查的現實基礎。沒有這些材料,《執行縫隙》很難形成今天的邊界。

同樣感謝那些曾經閱讀、質疑、討論或者引用過這些想法的人。

一個理論真正開始具有生命,並不是因為作者把它寫下來,而是因為別人開始拿它提出新的問題。不同意見、質疑和反例,往往比贊同更有價值,因為它們迫使一個理論解釋自己究竟能走到哪裡,又必須在哪裡停下來。

最後,我想感謝我的家人,尤其是我的小朋友。

寫書、做研究和做工程,意味著很長時間坐在電腦前,也意味著許多本來可以一起度過的晚上、週末和假期,被交給了代碼、論文、案例、圖紙和一遍又一遍的修改。

孩子當然不會關心什麼是 Execution Gap,也不需要理解我為什麼總在討論“這一次動作究竟為什麼會發生”。但正是那些和這些工作毫無關係的日常——一句突然的問題,一次打斷,一頓飯,一段陪伴——不斷提醒我,所有關於系統、執行和現實的討論,最後仍然應該回到真實的人和真實的生活。

謝謝你,在我埋頭做這些看起來有些奇怪、也有些漫長的事情時,仍然願意在旁邊長大。

也希望很多年以後,當你偶然翻到這本書時,會知道它完成的那段時間裡,你也一直在其中。

王林 2026 年 9 月 · 成都


第一章|每一環都對,結果卻錯了

本章從一個反直覺事實開始:審批、授權、策略、資格等局部判斷都可以在各自範圍內成立,卻不能因此推出端到端執行正確。執行縫隙的入口不是“結果很壞”,而是最終發生在現實裡的事情與已經成立的上游對象之間出現偏離;因此,嚴重後果、惡意或 AI 都不是它成立的必要條件。主體合法、被授權、善意或能力很強,也不足以保證某一次具體判斷正確。Robodebt 作為邊界案例進一步說明:上游決定本身錯誤但被系統忠實執行,不能僅憑後果嚴重就算作執行側偏離。於是問題被推回更早的一層:如果連“執行了”究竟指什麼都沒有拆清,就無法準確定位偏差。

現代系統裡,很少有動作憑空發生。一筆資金划走、一批貨發出、一臺機器停機、一個賬號被回收、一段生產配置被改寫——這些動作真正改變現實之前,通常已經穿過一串軟件對象:一個被記錄下來的意圖,一次審批,一次授權檢查,一條策略命中,一次資格校驗。它們有接口、有狀態、有留痕,也有各自的判據:什麼算通過,什麼算不通過,這個結論在什麼條件下才成立。

工程上,我們習慣逐項檢查這些對象:審批流走完了嗎?權限校驗通過了嗎?策略命中了應該命中的規則嗎?資格在動作發生時仍然有效嗎?每一項都能給出是或否,都能被複現,也都能寫進事故報告的時間線。

這些檢查回答的問題都很具體:誰有資格發起,誰批准了,系統此刻是否被允許動這份數據,這次變更是否仍在已經聲明的範圍內。麻煩也恰恰從這裡開始:當這些局部判斷一個個都成立,人很自然會再向前走一步——既然每一環都對,最後落到現實上的結果,也應該是對的。

這個推論不成立。

它不成立的方式還很特別。不是檢查得不夠細,也不是總有一環其實壞了,只是還沒有被查出來。可以出現這樣的情況:每一環都經得起檢查,在各自的判據下都成立,而最終發生在現實裡的事情,卻和已經成立的上游對象對不上。這裡不需要一處能夠被指認出來的局部錯誤,也不需要任何人心懷惡意。

這也是為什麼這類問題在事後復盤裡格外難處理。責任鏈上的人和系統都能拿出自己那一環成立的證據,可這些證據加在一起,仍然解釋不了已經發生的事。最後,討論很容易退回到「流程再收緊一點」,因為原有的語言裡沒有更合適的說法。

本章只做一件事:把這種局面從一種模糊的不適,變成一個可以被繼續追問的問題。

「每一環都對」承擔不了那個推論

先看那些局部判斷到底在說什麼。

審批成立,說的是:在審批系統自己的規則下,這份申請被有權批准的人批准了。授權成立,說的是:在授權系統自己的規則下,這個主體此刻持有執行這類動作所需的權限。策略命中成立,說的是:在策略引擎自己拿到的那份輸入下,這次請求匹配到了某條規則,並得到該規則規定的結論。資格校驗成立,說的是:在校驗發生的那一刻,被校驗的對象滿足了被寫下來的那些條件。

每一句都帶著自己的範圍。「在審批系統自己的規則下」「在授權系統自己的規則下」「在策略引擎自己拿到的那份輸入下」「在校驗發生的那一刻」——這些限定不是可以省掉的客套。它們恰恰是這些判斷之所以能被自動執行的前提。一個判斷之所以能交給機器給出,正是因為它的判據被收窄到了機器可以檢查的程度;收窄是它能用的原因,也是它的邊界。

於是問題出現了:這些局部判斷成立之後,通向最終結果的那一步,究竟是怎樣成立的?

「審批成立、授權成立、策略命中、資格有效,因此這次動作在端到端意義上是對的」——真正需要檢查的,是這句話裡的「因此」。它不屬於其中任何一個局部判斷,也不寫在它們各自的判據裡。

這就是問題所在。每個局部判斷都可以被驗證,但它們的成立本身,並沒有建立這個「因此」。一個系統可以在每一處局部檢查上都留下清楚的證據,同時仍然把這一步當成理所當然。

這就是本章的核心主張。寫成不等式是:

局部正確 ≠ 端到端執行正確(Local Correctness ≠ End-to-End Execution Correctness)

需要說清楚這條不等式否定了什麼,因為它很容易被讀成比它本身更多的東西。

它否定的是上面那個「因此」。它說:上游的意圖、決定、審批、授權、策略或資格在各自範圍內成立,這件事本身不足以建立最終執行與現實結果的正確性。

它沒有說存在一個可以被指出來的斷點。它沒有說「既然推不出來,那就一定有某一環其實是壞的」,也沒有說「既然推不出來,那就一定還缺了某個東西」。這兩種反向讀法都很自然,也都很常見,但它們都是錯的:「A 不足以建立 B」推不出「因此必然存在 C」。不等式只關掉一條推理通道,它不在另一頭許諾一個新的對象。

否定式在這裡是結論本身,不是一種委婉說法。如果把它改寫成正面形式——「要讓結果正確,必須再加上某某」——那就等於替它補了一個它沒有給出的答案,而且補得比它能擔保的多。本章不補。

讀到這裡,一個很自然的反應是沿著整條鏈去尋找斷點:到底是哪一環出了問題?

但這恰恰又多走了一步。

這條不等式沒有指出一個隱藏的斷點。它只說明:局部判斷的成立,本身不足以建立端到端結果的正確性。

「對」這個詞不能當對照物

緊接著必須解決一個更基礎的麻煩。

說「結果錯了」,錯在哪裡?相對於什麼而言錯了?

最省事的回答是:相對於「正確」。但這個回答是空的。「正確」在這裡不是一個已經有內容的屬性,本書也沒有一套可以用來承擔這個對照物的正面定義。

這不是遺漏。如果在這裡憑空補出一套「什麼才算正確」的標準,後面的論證就會被迫建立在一個未經建立的前提上。我們只是把問題從一個未經建立的「因此」,移到了另一個未經建立的「正確」。

更要緊的是,一旦把對照物設成「正確」,那條不等式自己就塌掉了。它會變成「局部正確不等於整體正確」,聽上去像一句同義反復,讀者順手把它讀成「軟件總會有 bug」,這本書也就沒有必要再寫下去。

所以對照物必須換。它必須是已經成立的上游對象:那個被記錄下來的意圖,那次具體的決定,那次具體的審批,那次具體的授權,那條被命中的策略,那次通過的資格校驗。

這樣一來,對照物就不再是一個抽象屬性,而是一個可以被指認的對象。它有具體內容,有發生時間,也有自己的適用範圍。我們可以把它單獨取出來,然後問一個明確的問題:

最終發生在現實裡的事情,和這個已經成立的上游對象,對得上嗎?

這個區別到了排查現場就會變得具體。

如果對照物只是「正確」,那麼「到底哪裡不對」很容易變成一場沒有固定參照的爭論。可一旦對照物變成某個已經成立的意圖、決定、審批或授權,問題就有了可以指認的落點:把它放在最終發生的事情旁邊,看兩者是否吻合。

這個比較可能很難,但至少我們知道自己究竟在比較什麼。

偏離的含義因此變窄,也變硬:不是「結果不好」,而是「最終落到現實上的東西,和那個已經成立的上游對象對不上」。

這個限定不是為了嚴謹而嚴謹。它決定了這本書的門朝哪一側開,也決定了它在哪一側關上。開著的那一側,是上游對象已經成立、而現實結果與之不符的情形——那個被記錄下來的意圖仍然在那裡,那次審批仍然有效,那條策略仍然是當初命中的那一條,而真正發生的事情與它們對不上;關上的那一側,稍後會用一個具體的例子說明。

本書討論的這個問題空間有一個名字:執行縫隙(Execution Gap)。這一章不給它下定義。要給出定義,首先得說清楚「執行」指的是什麼。

壞結果不是入口

Robodebt 恰好把這條邊界推到了一個很難迴避的位置。

在這件事情裡,一套上游規則本身違法,且證據基礎不足;它隨後被忠實地、自動地、大規模地執行了。後果嚴重,而且確實由自動化系統造成。

如果入口是「壞結果」,那麼它顯然應該進來:後果的嚴重程度、波及的規模、自動化的參與程度,三項都滿足。但入口不是壞結果。

按上一節的限定,判斷執行是否偏離,看的是最終發生的事情與已經成立的上游對象是否對得上。在這裡,這兩者對得相當好——系統忠實地執行了它被要求執行的規則,幾乎沒有走樣。問題出在那條規則本身:它的合法性,以及它的證據基礎。這首先是上游決定與權威的問題,不是執行側的偏離。

這不是為執行側開脫。忠實地執行一條不該被執行的規則,後果一點也不會因此變輕。它說的是另一件事:判斷問題落在哪一側,不能從後果的嚴重程度倒推。後果告訴你有事情出錯了,它不告訴你錯在哪一層——而這本書要處理的恰恰是「哪一層」。

把它算作執行偏離,會讓整個問題空間失去形狀。任何造成壞結果的自動化系統都可以被算進來,而「執行是否偏離」這個問題就退化成「結果好不好」的另一種問法。本書要建立的那條不等式,也會跟著退化成一句無法反駁、因而也無法使用的話。

Robodebt 在這裡的作用不是證明,而是劃邊界。它逼著我們回答一個更難的問題:如果現實後果已經明顯出了問題,但執行過程只是忠實地落實了一個本身就有問題的上游決定,這還算不算這裡所說的執行偏離?

至少僅憑壞結果,還不能這樣判斷。

這也不意味著所有「錯誤決定被忠實執行」的情形都永遠在這個問題空間之外。有些情況可能重新進入這條邊界,具體條件需要另外判斷。這裡唯一需要守住的是:現實後果嚴重,不足以單獨證明偏差發生在執行這一側。

所以 Robodebt 在這裡不是正例,也不給核心主張增加證明重量。它只負責把邊界壓得更清楚。

這裡也不需要展開 Robodebt 的完整故事。它的事實鏈、責任認定和治理後果當然重要,但那會把注意力帶向另一個問題。

在這一章裡,只需要記住它留下的那條邊界:嚴重的壞結果,不等於執行本身發生了偏離。

不需要惡意

如果每一環都對而結果錯了,還有一種很自然的解釋:有人在其中做了手腳。

這個解釋很有吸引力,因為它保住了原來的推論——只要排除惡意,每一環都對,結果就仍然應該是對的。問題也隨之有了明確的去處:找到那個惡意主體,或者找到被突破的環節。

但這個推論仍然保不住。

這裡討論的問題,並不以惡意存在為前提。

可錯與惡意不是同一回事。

可錯說的是:我們不能僅憑一個主體的身份、資格、善意或能力,證明它在某一次具體判斷上一定正確。惡意說的則是另一件事。把兩者混在一起,會把一個判斷問題誤寫成一個對抗問題。

再往下看幾層。

身份合法、憑證合法、權限合法,三者全部成立,推不出這一次動作是正確的。這三項各自都可驗證,而且都已經被工程化得相當好;它們回答的是「這個主體能不能做這類事」,不回答「這一次這麼做對不對」。把前者的成立讀成後者的成立,是這條鏈路上很容易被略過的一次跳躍——前者有自己的判據,後者沒有。

善意還要單獨拿出來說,因為它碰到的是另一個問題:它能不能成為安全邊界。

答案仍然是否定的。安全邊界必須建立在可驗證的條件上,而動機本身不可驗證。我們可以驗證一個簽名,驗證一次授權,驗證某條策略是否命中,卻無法用同樣的方式驗證一個人或一個系統「是出於好意」。

因此,善意可以存在,也可以重要,但它不能替代一個可驗證的邊界。

能力也不行。能力提高不消除可錯性。所謂可錯,指的正是無法證明這個主體未來每一次行動都正確;它首先是一個工程屬性,是主體面對不完整現實時的結構性處境,不是智能不足帶來的暫時狀態,因此不會隨著能力曲線一起被抹掉。

把這幾條合起來,得到的是一條否定式的核心。它是本書關於主體所需要的全部前提——不多,也不能更少。

一條否定式的核心

主體的合法性、授權、資格或善意成立,不足以建立其判斷正確性。

這裡有兩個判斷必須放在一起理解:

認證、授權、善意、高能力與長期穩定,都不能建立一個主體在某一次具體判斷上的正確性。

一個判斷是否正確,與這個判斷是否被賦予改變現實的權力,是兩個不同的問題。

這條核心很容易被讀過頭,所以它的邊界也必須同時保留。

它不是說所有主體必然犯錯,也不是說主體大概率會出錯。它同樣不意味著「主體不可信」。它只否定一件事:認證、授權、善意、高能力或長期穩定,都不能替某一次具體判斷的正確性作保證。

這裡也不定義「正確」,不封閉主體的範圍,也不定義權威。我們承認的是一個有限的前提,而不是在這裡建立一套完整的形式理論。

真正承重的是後半段。「是否犯錯」與「錯誤能否獲得改變現實的權力」,是兩個獨立的問題。

在工程系統裡,這兩個問題被安排在同一條鏈路上,但它們從來由不同的東西決定。一個判斷是否正確,取決於判斷者掌握的信息、它的推理,以及它面對的那部分現實;而這個判斷能不能改變現實,取決於它被接在什麼位置上——哪個服務可以調用哪個接口,哪條策略的結論可以直接生效,哪次審批之後不再有第二道檢查。後面這組安排通常是在很早的時候、出於完全不同的理由做出的,和「這一次判斷對不對」沒有關係。

把兩個問題合併,會得到一條本書不接受的推論:既然主體會犯錯,那就少讓它做事。本書不主張這個,也不打算用它來結束任何討論。可錯不等於不可信,把可錯讀成需要收回自主性,是對這條核心的典型誤用。

這個「主體」究竟包括誰?

否定式核心一旦成立,下一個問題幾乎立刻就會出現:這裡說的「主體」,究竟包括誰?

如果它只適用於普通用戶,問題還比較簡單。但同樣的追問很快會落到管理員、擁有者和根用戶身上,然後繼續落到硬件、真正執行動作的組件,甚至記錄證據的那一層。每往外走一步,同樣的追問都會重新出現:前面的那條否定式,對這個主體是否仍然成立?

到這裡必須停一下。

目前沒有一條已經建立的判據告訴我們,這個集合應該在哪裡結束。到管理員為止?到擁有者為止?執行組件算不算?硬件算不算?證據系統又算不算?

本書不打算替這個問題補一個答案。要把「主體」完整地封閉成一個嚴格集合,需要更進一步的形式化工作;而第一章真正需要的,並不是先畫出這個集合的全部邊界。

這裡需要的只有更小的一步:無論討論的是其中哪一個具體主體,它的身份、資格、授權、善意或能力,都不能單獨建立它在某一次具體判斷上的正確性。這個否定式並不要求我們先把所有主體列完,才能成立。

至於證據層,也暫時停在這裡。提到它,只說明這個問題可以繼續追到那個位置,並不等於已經確定了證據在整個結構中的最終地位。

有些問題可以被明確地留下,而不是被匆忙地解決。

知道一個問題停在哪裡,本身也是理論邊界的一部分。

AI 在這裡的位置

當執行鏈上的主體從人換成 AI Agent,一個很自然的問題隨之出現:前面建立的這些判斷,是不是也跟著變了?

核心判斷沒有變。

AI Agent 主要放大既有問題,而不是創造問題。

這句話的兩半都要緊。「放大」意味著它確實改變了什麼——規模、速度、一次判斷可以波及的範圍。「不是創造」意味著被放大的那些東西,在它出現之前就已經在那裡:上游成立推不出結果成立,這條不等式不依賴任何模型;惡意不是必要條件,這條判斷同樣不依賴任何模型。本章前面幾節的論證裡沒有出現過模型,正是因為它們用不到模型。

反過來說,把這裡討論的偏差解釋成「模型出錯」或「模型產生了幻覺」,會讓問題以一種虛假的方式消失。幻覺說的是模型輸出與事實不符;本章說的是已經成立的上游對象與最終現實結果對不上。這兩件事可以同時發生,但它們不是同一件事,也不能互相替代。更直接的反證是:在完全沒有模型參與的系統裡,本章的問題照樣成立。

如果把這類風險整體歸因於模型錯誤,問題就很容易被縮小成「模型還不夠可靠」:等待更好的訓練、更強的模型,或者下一個版本修復它。

但這裡的問題並不隨模型版本成立,也不會因為模型版本變化而自動消失。前面的那條不等式,討論的是上游對象與現實執行之間的關係,而不是模型本身的準確率。

這裡也不是在說自動化無關緊要。放大是有後果的,後果還可能很大。但後果的量級與問題的來源是兩件事;把它們混在一起,會讓人以為只要把自動化那一段做得足夠可靠,前面那條不等式就會消失。它不會。

自動化在這個問題空間裡的確切位置,需要比這裡更細的判定,那不是這一章要做的事。

先問清楚「執行了」是什麼意思

走到這裡,我們得到的仍然只是一組否定。

局部判斷成立,不足以建立端到端執行正確;壞結果本身不足以說明偏差發生在執行側;惡意不是必要條件;AI 放大這個問題,卻沒有創造它。

本章沒有告訴我們偏差究竟在哪裡,也沒有替那個缺口補上一種結構。

它只做了一件事:拆掉一個原本被默認成立的推論。

而一旦這個推論被拆開,一個更早的問題就躲不過去了。

前面一直在說「最終落到現實上的結果」,彷彿「執行」是一件不言自明的事。

其實不是。

在工程語言裡,「執行了」這三個字可能指向不同的時刻,也可能指向不同的對象。如果連這個詞究竟指什麼都還沒有分清,「偏差發生在哪裡」就無法被精確地問出來。

當我們說「這個動作執行了」,說的究竟是哪一件事?偏差又落在哪一層?


本章術語

  • 局部正確 | Local Correctness
  • 端到端執行正確 | End-to-End Execution Correctness
  • 已經成立的上游對象 | Established Upstream Object
  • 執行縫隙 | Execution Gap
  • 可錯 | Fallibility
  • 邊界案例 | Boundary Case
  • 執行 | Execution

本章案例與資料來源

Robodebt

本章使用澳大利亞 Robodebt 作為邊界案例(Boundary Case)。

Robodebt 涉及自動化福利債務識別與追繳,併產生了嚴重的現實後果。但本章引用這一案例,並不是為了把它直接歸入「執行縫隙」,也不是用它證明本章的核心判斷。

它在這裡承擔的作用,是幫助劃清問題邊界:

嚴重的現實後果本身,並不足以判斷偏差發生在執行側。

如果問題首先來自上游規則、法律基礎或證據依據,那麼即使這些規則隨後被系統忠實執行,也不能僅憑最終結果嚴重,就把它重新描述成執行偏離。本章因此只保留一個必要限定:討論執行縫隙時,對照的必須是已經成立的上游對象,而不是一個事後被稱為「正確」的結果。

至於規範性錯誤的上游決定在什麼條件下可能重新進入執行縫隙的討論,不在本章展開。

Robodebt 的完整事件背景、事實核驗、主要官方來源及其作為邊界案例的證據限制,見本書附錄 《現實失敗與邊界案例》。

資料來源

本章不在正文中重複展開 Robodebt 的完整事實鏈與書目資料。相關材料統一列入附錄 **《現實失敗與邊界案例》**及全書 《參考文獻與資料來源》。



第二章|「執行了」說的是哪一件事

本章把“執行了”拆開。執行不是一個單一瞬間:執行過程描述從進入可識別執行路徑到現實結果形成的整段過程,執行動作則指真正改變現實狀態的那一次動作;結果又是獨立對象,執行動作成立並不能自動推出結果成立。提交、調用、執行狀態、回執、結果、證據六者也不得默認等同,更不能被排成必然依次發生的六個階段;它們之間的關係必須被單獨建立。章首“設備停機但現場仍在運轉”的假設場景說明,同一句“執行了”可能只是分別指向不同對象。本章同時保留技術結果、外部狀態與業務結果之間的層次問題,不提前形式化。拆完這些對象後,問題變成:如果每一層內部都成立,偏差究竟發生在哪裡?

一個動作到底有沒有發生,在工程對話裡通常不需要解釋太多。有人問:「那條指令執行了嗎?」另一個人看一眼面板,回答:「執行了。」對話往往到這裡就結束。

問題在於,這兩個「執行」未必始終指向同一件事。

設想一次很普通的復盤。一條讓某臺設備停機的指令,事後被確認「已經執行」。做變更的人說,指令已經提交,時間戳和記錄都在;做接口的人說,調用已經發出,返回碼是成功;做運維的人說,系統狀態已經變成停機;對接外部廠商的人說,對方的回執已經收到,上面寫著「已受理並處理」。

最後有人去了現場。

設備還在轉。

前面的說法並不因此全部變成假的。提交可能確實完成了,調用確實成功返回,系統狀態確實寫著停機,外部回執也確實存在。真正暴露出來的問題是:這些人一直在用同一個「執行了」,回答關於不同對象的問題。

只要這些對象彼此吻合,這種壓縮通常不會造成麻煩。一旦它們分開,原來那個簡單的是非問題也隨之失效。「執行了嗎?」已經不能只回答一個“是”或“否”,因為回答之前,必須先知道問的是哪一件事。

上一章留下的是一個否定:上游各環分別成立,不足以建立最終執行與現實結果的正確性。要繼續追問這個問題,首先必須把「執行」這個詞內部混在一起的對象拆開。

這一章就做這件事。

「執行」不是一個單一動作

執行(Execution)不是一個只能落在某個瞬間上的詞。它覆蓋的是一段從表達、判斷與承諾進入現實變化的整體過程,而在這段過程裡,至少有兩個對象必須分開。

第一個是執行過程(Execution Process)。它指一件事進入可識別的執行路徑之後,直到現實結果形成的那一整段過程。一次跨過七個系統、持續四十分鐘、中間重試過兩次的變更,都可以被包含在這個範圍裡。

第二個是執行動作(Execution Act)。它指真正讓現實狀態發生變化的那個動作:設備斷電的那一下,錢離開賬戶的那一下,閥門閉合的那一下。

兩者之所以經常被混在一起,是因為日常語言允許我們同時說「執行一次變更」和「執行動作已經發生」。

但它們回答的其實不是同一個問題。

執行過程可以處在「正在進行」「已經走完」或「卡住」這樣的狀態;執行動作關心的則是現實是否已經被改變。一旦把兩者混寫,「已經執行到哪一步」這句話就會失去精確性——它既可能在問流程推進到了哪裡,也可能在問現實是否已經發生變化。

這個區別在時間上最容易看出來。

執行過程有長度。一次變更可以在其中停留很久:排隊、等待窗口、等待確認、失敗後重試。在這段時間裡,說它「正在執行」完全可以成立,而現實可能還沒有發生變化。

執行動作則不同。它所關心的是那個現實變化有沒有發生。動作一旦已經發生,後面的過程是否繼續、是否完成,都不能把已經發生的現實變化收回去。

這也是為什麼「現在還來不來得及」這個問題,不能只看執行過程走到了哪裡。真正決定答案的,是執行動作是否已經發生。

到這裡,拆開的還只是「執行」這個詞內部的兩個對象。接下來要處理的,是一個不能繼續塞進這個詞裡的東西:結果。

結果(Result)也必須被區分出來,但它和前面兩者的關係並不相同。執行過程與執行動作,是「執行」這個上位概念內部需要分開的兩個對象;結果不是第三層,而是另一個對象。

把結果畫在執行動作的後面、當成它的產出口,會立刻帶來一個印象:動作完成了,結果也就有了。這個印象是錯的,而且它錯得很安靜——它不會在任何一處報錯,只會在所有人都確認「執行動作已完成」之後,讓那句「所以結果成立」自動接上去。

結果不在動作的後面

結果獨立於執行動作。

這裡的「獨立」不是說結果可能偶爾偏離預期,也不是在討論系統可靠性。

它說的是一個更基礎的關係:執行動作成立,本身不足以推出結果成立。

一個動作已經發生,並不能單獨回答結果是否已經形成、形成的是不是被追問的那個結果、以及它在當前語境下是否成立。這些問題不能由「動作已經發生」這一事實代替。

工程直覺很容易把兩者連在一起。系統正常工作時,動作與結果往往同時成立,於是「動作完成,所以結果成立」逐漸變成一種默認讀法。但默認讀法不是已經建立的關係。

一旦把結果從執行動作裡分開,幾種原本聽起來彆扭的狀態就可以被準確描述。

動作已經發生,而結果仍然不能確定。

結果已經出現,但當前沒有足夠的東西把它與那個動作對應起來。

甚至可能出現動作沒有發生,而結果已經出現的情況——當同一份現實同時受到多個主體或系統影響時,這種情況並不矛盾。

這些說法之所以聽起來反常,只是因為日常語言早已習慣把動作和結果壓成同一件事。

結果還不能被那些最接近它的對象替代。

系統裡很容易出現一些「看起來已經足夠像結果」的東西:提交記錄、成功返回、外部回執。它們往往比結果本身更早可得,而且形式完整——有時間戳,有簽名,可以入庫,也可以進入報表。

如果問題只是「有沒有東西可以證明這件事已經執行」,這些對象很容易被拿來回答。但它們能說明什麼,取決於各自所代表的對象;它們的存在本身,不能替代結果。

圖 2-1 執行的三分與結果的獨立位置

圖注:圖中是三個彼此分離的對象域:執行過程、執行動作、結果。結果與執行動作並列放置而不相連——它不從動作那一側引出,不是動作的出口。圖的另一半是六個對象:提交、調用、執行狀態、回執、結果、證據。它們之間只以「≠」相連。沒有箭頭,沒有先後,沒有泳道。

六個不該被默認等同的對象

拆到這裡,可以把那條最需要被記住的否定寫出來:

提交(Commit)
≠ 調用(Invocation)
≠ 執行狀態(Execution State)
≠ 回執(Receipt)
≠ 結果(Result)
≠ 證據(Evidence)

下面不是要給六個詞逐一下定義,而是先把它們在工程語言裡通常指向什麼說清楚。只有這樣,那些不等號才不是符號遊戲。

真正需要守住的是:這六個對象不能因為出現在同一條執行鏈路裡,就被默認當成同一件事。

「提交」在工程語言裡,通常指系統內部已經把某件事記錄或確定下來。在一些系統中,提交之後後續流程會自動推進,因此它很容易被順手理解成「事情已經開始發生」。但提交首先確認的是系統這一側已經接受並記錄了這件事,並不能單獨說明現實已經發生變化。

「調用」通常指請求已經被髮送給執行它的一方。發送成功、對方收到、對方實際照做,是可以分別成立的事情。一個成功返回碼能夠說明什麼,取決於接口本身的語義;它不能僅憑“成功”二字,就替現實中的動作成立作保證。

「執行狀態」則通常是系統對這件事當前進展的記錄。狀態寫成「已完成」,並不天然等於現實已經完成:它可能來自真實動作,也可能來自超時、默認規則或其他狀態更新邏輯。

這裡還有一個很容易被抹掉的狀態:未知。

未知不能因為難以處理,就被讀成成功。

回執(Receipt)是一份來自外部的聲明,它可以說明對方聲稱自己已經接收、處理或返回了什麼。問題在於,回執裡的「已處理」究竟覆蓋到哪一步,仍然取決於對方自己的語義。它可能只表示請求已經入隊,也可能表示某個內部步驟已經完成。因此,即使一份回執格式完整、帶有簽名並且能夠通過校驗,它也不能單獨替代結果。

結果(Result)與這些對象回答的不是同一個問題。提交說明系統記錄了什麼,調用說明請求被髮出了什麼,回執說明外部一方聲明瞭什麼;這些對象都可能為判斷結果提供信息,但它們的存在本身不能替代結果。

證據(Evidence)是支持意圖、決定、執行、拒絕、恢復或結果等事實的可驗證記錄。記錄與被記錄的事實仍然是兩個對象:再完備的記錄也不能使一件沒有發生的事發生,一件已經發生的事也不會因為缺少記錄而因此沒有發生。

至於證據在因果鏈中究竟處於什麼位置,以及它如何參與後續判斷,本章不繼續展開。這裡需要守住的只有一條:證據不能和它所記錄的對象默認等同。

把這些放回前面那個停機指令的場景,五個人各自的「執行了」就有了各自的歸屬:一個說的是提交,一個說的是調用,一個說的是執行狀態,一個說的是回執,只有最後去現場看的那個人說的是結果。這不是他們誰更嚴謹,而是他們在各自的崗位上,手邊能拿到的就是那一個對象。每個人都在用自己夠得著的那個對象回答一個關於結果的問題。

這些混用不一定來自疏忽。提交、調用、執行狀態、回執和證據往往都有現成的系統表示:有狀態、有返回值、有記錄,也容易進入日誌和報表。

而「結果」能否從這些對象中被直接確認,則取決於具體系統和被追問的結果是什麼。有時還需要額外的觀察或判斷。如果討論只停留在已經可得的對象上,離結果最近的那個對象就很容易被拿來代替結果。

這裡還有一條更短的否定,值得單獨記住:**執行動作、執行狀態、回執、證據,四者互不相等。**執行動作指向現實中的動作,執行狀態是系統的說法,回執是外部來源的聲明,證據則是對相關事實的記錄。它們可能圍繞同一件事出現,卻來自不同的位置,因此不能互相替代。

它們不是六個階段

到這裡,一個很自然的讀法會出現:把這六個對象排成一條流水線——提交,然後調用,然後狀態更新,然後收到回執,然後產生結果,最後留下證據。這樣寫很順,畫出來也很整齊。

但那條不等式沒有表達這種順序。它只說一件事:這六個對象不得默認等同。

一旦把它們讀成階段鏈,就等於額外加入了一層關係:前一個到位之後,後一個應該跟著到位;某一項缺失,則意味著流程在某一步中斷。

而這些關係並沒有由那條不等式建立。回執可以早於狀態更新,也可能根本沒有出現;證據可能從一開始就在產生,也可能只覆蓋其中一部分;結果也可能已經發生,而提交一側沒有留下對應記錄。

把六個對象預先排成一條線,會把這些本來可以成立的情形提前排除掉。

階段鏈還有一個更隱蔽的後果:它很容易讓人認為,只要鏈條上靠後的對象已經成立,前面的對象也隨之成立。

這和上一章拆掉的推論有相似之處。上一章的問題是橫向的:每一環都對,因此整體也對;這裡的問題變成縱向的:後面的對象已經到位,因此前面的對象也已經成立。

兩種推理都多出了一步,而那一步都沒有被建立。

有一個很簡單的檢驗。

把六個對象重新排列:

證據、結果、回執、執行狀態、調用、提交。

只要它們之間仍然保持「≠」,原來的含義並沒有改變。順序改變而命題不變,本身就說明這不是一條依賴先後的階段鏈。

當然,這些對象之間可以存在關係,工程系統也會主動建立各種關係。例如一次調用可能對應某次提交,一份回執可能對應某個請求,一份證據也可能記錄某次動作或結果。

但這些關係需要被建立,而不能從對象同時存在這一事實中直接推出來。

這條不等式到這裡為止,只要求我們先承認:它們是不同的對象。

分層是裁決,不是發現

剛剛拆出來的這套分層,需要交代它是怎樣成立的。

在這套理論形成的早期記錄裡,「執行」這個詞曾經同時指向過程、裁決、動作和結果。那些用法並不需要被重新改寫成今天的樣子,因為它們原本就在不同的問題下使用這個詞。

現在把這些對象分開,並不意味著過去的說法當時就是錯的。真正發生的變化是:當問題轉向「偏差究竟落在哪裡」,原來那個足夠寬泛的「執行」已經不夠用了。

因此,這套分層不是從過去的用法裡發現出來的一套既有共識。

它是本書在這裡作出的理論裁決。

這個裁決受前面那些對象和邊界的約束,但它並不聲稱:人們過去其實早就以同樣的方式理解「執行」,只是沒有把它寫下來。

這一區分接下來還要承擔一個很實際的檢驗:它能不能讓「偏差落在哪裡」這個問題被更精確地提出,能不能讓不同崗位在說「執行了」時明確自己指向的是哪一個對象,也能不能讓原本含混的狀態變成可以分別討論的狀態。

如果做不到這些,這套分層本身就沒有完成它在這裡承擔的任務。

把裁決誤寫成發現,會帶來一個多餘的判斷:彷彿所有不採用這套分層的說法都因此成了錯誤。不是這樣。不同語境可以繼續使用更寬泛的「執行」,只是在本書當前的問題裡,我們需要把它拆開。

這套分層本身也不證明某一次執行正確,更不解釋偏差為何發生。它只負責提供一組可以被分別指認的對象。

「結果」內部還有一個未決問題

結果這一側還有一個問題沒有被正式解決。

當我們問「結果是什麼」時,實際可能在問不同的東西。執行方或外部系統返回的技術結果是一種對象;系統之外已經發生、或者可以被觀察到的現實狀態,又是另一種對象。到了業務語境裡,問題還會繼續變化:那筆錢到底算不算已經付出,那次停機到底算不算已經完成,已經不只是技術返回或外部狀態本身能夠單獨回答的了。

這些對象之間究竟是什麼關係,目前沒有被正式排定。

目前沒有足夠依據說明這些對象之間誰包含誰、誰能夠推出誰,也沒有依據把它們統一成一個完整層級。

因此,本書在這裡不替它們安排一個看起來整齊的結構。

原因並不只是排版謹慎。只要把幾個對象並列放在同一行、同一表格或同一層級裡,讀者就會自然地把這種並列理解成一種關係判斷:它們彼此可比、位置相近,甚至屬於同一層。

而這些關係目前都還沒有被建立。

這並不意味著這個問題不重要。

在具體系統裡,「這次執行的結果是什麼」往往需要從不同角度分別回答:系統返回了什麼,現實發生了什麼,以及這些變化在業務上究竟算不算成立。幾個問題可能得到不同答案,也可能依賴不同的觀察方式和時間尺度。

但承認這些差異,和進一步規定它們之間的正式層次,是兩件不同的事。

本書在這裡不做後一件事。要建立一個可靠的層次,需要額外的形式化工作;在依據不足的時候先給出一個看起來完整的結構,只會讓後面的論證建立在一個未經建立的前提上。

這個未決項並不妨礙本章繼續成立。結果獨立於執行動作,並不要求我們先把結果內部的所有關係都排清楚。

那麼偏差在哪裡

到這裡,我們得到的不是一個關於偏差位置的答案,而是一組可以被分別指認的對象。

執行是一個上位概念。執行過程與執行動作需要被分開;結果是另一個對象,它不能由執行動作自動推出,也不能被提交、調用或回執單獨替代。

提交、調用、執行狀態、回執、結果、證據彼此不同,也不能被讀成六個依次發生的階段。

有了這組對象,上一章的問題終於可以被問得更精確一些。

上一章說的是:每一環都對,結果卻錯了。到了這裡,「每一環」已經不只包括審批、授權、策略和資格。執行這一側也被拆開了:提交可以成立,調用可以成立,執行狀態可以成立,回執可以存在,相關記錄也都可以經得起檢查。

於是問題變得更尖銳了。

而最終被追問的結果,仍然可能與這些成立的對象對不上。

這時,問題已經不能簡單地歸結為某一個對象出了錯。每一個對象都可能在自己的範圍內成立,偏差卻仍然存在。

如果每一層內部都沒有壞,偏差究竟發生在哪裡?


本章術語

  • 執行 | Execution
  • 執行過程 | Execution Process
  • 執行動作 | Execution Act
  • 提交 | Commit
  • 調用 | Invocation
  • 執行狀態 | Execution State
  • 回執 | Receipt
  • 結果 | Result
  • 證據 | Evidence
  • 技術結果 | Technical Result
  • 外部狀態 | External State
  • 業務結果 | Business Result

本章案例與資料來源

本章未使用真實世界案例。

章首的「設備停機指令」是用於區分提交、調用、執行狀態、回執與結果的假設性工程場景,不對應特定公司、產品、事故或公開事件,因此不需要列出外部案例來源。



第三章|偏差不在某一點上

本章把排查問題從“哪個組件壞了”改成“對象之間哪一段關係沒有繼續成立”。轉換、時差、接縫和關係並不是四類新機制,而是指向同一個位置:兩個對象各自成立,並不自動保證它們之間應保持的含義、條件或對應關係仍然成立。更多日誌、更細組件和更密觀測,只能增加對象內部信息,不能自動把對象之間的斷裂顯現出來。十七個已核驗現實失敗提供了經驗背景:多個分析維度可以在同一事故中同時為 Strong,失敗並沒有穩定收縮成唯一斷點;但這些案例不是理論證明。組件故障仍然存在,關係視角只是補上組件檢查之後仍解釋不了的部分。由此下一問被逼出來:哪些關係會斷?

上一章把「執行了」拆成了一組可以分別指認的對象:提交、調用、執行狀態、回執、結果、證據。它們不能被默認當成同一件事。

接下來出現了一個更麻煩的局面。

提交可以成立,調用可以成立,執行狀態可以成立,回執可以存在,相關記錄也都經得起檢查。把這些對象一個個拿起來看,未必能找到一個明確壞掉的對象。

偏差卻已經發生了。

設想一次事後復盤。不同環節分別拿出自己的記錄:上游收到的輸入是什麼,按照什麼規則處理,向下遊交出了什麼,系統留下了什麼狀態。每一段材料單獨看都可以成立,拼在一起也彷彿覆蓋了整個過程。

但最終結果仍然對不上。

這時,繼續把已有對象拆得更細,並不自動解決問題。更多日誌、更小的單元、更密的觀測點,可以幫助我們看清對象內部發生了什麼,卻未必回答另一類問題:如果這些對象在各自範圍內都成立,偏差究竟落在哪裡?

如果每一層內部都成立,偏差發生在哪裡?

「哪個組件壞了」已經限定了搜索空間

工程排查很自然地會從組件開始:列出服務、模塊、實例或節點,然後逐項確認它們是否正常。

這種做法隱含了一個前提:偏差應該能夠落在某個組件內部。於是清單是組件清單,搜索空間也是組件集合,排查最終希望找到一個可以被指認的故障對象。

這個前提當然有它成立的時候。某個服務宕機、某段代碼執行錯誤、某個配置寫錯,確實都可以沿著組件邊界找到問題。

麻煩在於,系統本身也在強化這種搜索方式。代碼、服務、監控和日誌通常都圍繞已經劃出的組件組織;這些對象有名字、有邊界,也容易被單獨檢查。於是當我們問「哪裡出了問題」,最先進入視野的,往往就是那些已經被切出來的對象。

章首那種復盤之所以會出現,也和這種切分方式有關。

每一段材料都可以準確描述自己那個組件內部發生了什麼:收到了什麼輸入,進行了什麼處理,產生了什麼輸出。把這些材料全部拼起來,看上去像是覆蓋了整個系統,但它們真正覆蓋的,仍然是一個個已經被劃出的對象。

對象之間發生了什麼,並不會因為對象內部的材料足夠完整,就自動被記錄下來。

困難出現在組件清單已經逐項檢查,卻仍然沒有找到足以解釋結果的故障時。

這時最容易做的,是繼續提高分辨率:把組件拆得更細,增加日誌,補充鏈路追蹤,提高觀測密度。這樣做可能帶來更多信息,但它仍然沿用同一個前提——問題應該存在於某個對象內部,只是我們還沒有把那個對象看得足夠清楚。

如果真正缺失的是對象之間的關係,那麼繼續向對象內部增加細節,並不會自動把那個關係顯現出來。

當組件清單已經查完,而仍然沒有找到足以解釋結果的故障時,需要被重新檢查的,就不只是排查精度,也包括最初的提問方式。

四個詞說的是同一個位置

對這一點,已有的表述很短:

Gap 位於轉換、時差、接縫和關係中,而不只是單點漏洞。

先說清楚,這四個詞不是四個類別。

轉換、時差、接縫、關係,不是四種缺陷,也不是四類可以逐項命中的機制。如果把它們排成一張分類表,原來的組件清單隻不過會被換成另一張清單:排查仍然在尋找某一個可以被圈出來的格子。

這裡說的是位置。

它要求我們把視線從對象內部移到對象之間。

轉換最容易讓這個位置顯現出來。一個對象被表達成另一個對象時,兩端並不共享完全相同的表示方式、完整性標準和關注重點。上游認為已經表達清楚的內容,下游未必都有位置承接;下游認為自己完整接收的內容,也可能只是它能夠表示出來的那一部分。

因此,轉換可能在兩端都各自成立的情況下發生損失。

這種損失甚至不一定表現為明顯錯誤。一個判斷原本帶有成立條件,而下一端只需要一個「是」或「否」;條件留在了上游,結論繼續向下傳遞。兩邊分別檢查都可以成立,但讓兩個表達保持同一含義所需要的東西,已經沒有完整地跨過去。

接縫描述的是同一個位置的另一種可見形態。

兩個各自完整的部分拼接起來,拼接處並不因此自動屬於其中任何一邊。每一邊的檢查可以一直做到自己的邊緣,卻不能由此推出邊緣之外的連接也已經成立。

在按組件切分的系統裡,這種位置尤其容易消失在視野之外。系統圖能夠畫出兩個方框,也能夠畫出一條連接它們的線,但那條線所代表的條件,並不會因為兩個方框分別成立就自動成立。

時差讓這個問題脫離了純粹的空間直覺。

一個判斷成立於某個時點,現實動作發生在另一個時點。兩者之間經過的時間,不屬於前一個判斷的內部,也不屬於後一個動作的內部。判斷在作出時可以成立,動作在發生時也可以形式上有效,但原來使兩者能夠對應起來的事實與條件,可能已經變化。

這時的問題並不是簡單的先後順序錯誤,而是一個只在某個時點成立的判斷,被繼續當成不隨時間變化的事實使用。

轉換、接縫和時差在這裡並不組成三個機制類別。它們只是讓同一個位置更容易被看見:兩個各自成立的對象之間,仍然可能存在沒有被任何一個對象內部檢查所覆蓋的東西。

「關係」在本章裡也只用來指向這個位置,不承擔一個新的分類層級,更不是一個等待被註冊和編號的正式對象。

內部成立,之間斷裂

「偏差不在某一點上」是一個否定句。它很容易被繼續補成:「那就在另一點上。」

一旦這樣理解,問題仍然沒有改變。我們只是從一個方框移到另一個方框,繼續尋找那個真正壞掉的對象。

但這一章要表達的不是換一個地方找。

把它畫出來。

圖 3-1 每一層都成立,斷裂發生在層與層之間

圖注:每一個方框內部都表示對象在自身規則與範圍內成立;斷裂標記全部位於對象之間,而不位於對象內部。圖中斷裂的位置與數量僅用於說明關係可以失效,不表示斷裂只能發生在這些位置,也不表示一次偏差只能存在一處斷裂。下方跨越兩端的關係線表示:不相鄰對象之間同樣可能存在必須成立的關係,而這種關係同樣可能斷裂。

如果每一個方框內部都已經能夠單獨成立,那麼繼續檢查方框內部,並不能自動解釋方框之間為什麼沒有保持一致。此時需要被檢查的,不再只是對象本身,也包括對象之間原本必須成立的連接。

圖上的斷裂標記因此全部落在方框之外。

方框裡的「內部成立」不是讓步,而是這一章的前提。

這裡討論的不是某個環節已經壞掉,只是暫時沒有被發現。那種失敗當然存在。本章關心的是另一種情形:各個對象都能夠在自己的範圍內成立,也經得起單獨核驗,而最終結果仍然出現偏差。

兩類問題的定位對象不同。前一種可以繼續進入部件內部;後一種則要求把視線移到對象之間。

必須成立的關係不只存在於相鄰對象之間。承諾與最終結果之間可以隔著多箇中間對象,而每一箇中間對象都分別成立,仍然不能自動推出兩端保持著同一個含義。

時間還會進一步改變這種關係:兩端之間跨過的事實與條件可能發生變化,而這些變化不屬於任意一個端點內部的成立性。

圖中出現多個斷裂標記,只為了擋住另一種誤讀:一次偏差並不必然只有一個唯一斷點。

如果預先假設總有一個唯一、決定性的故障位置,最終仍然會回到單點模型。

本章的判斷就落在這裡:偏差不在某一點上。Gap 位於轉換、時差、接縫和關係中,而不只是單點漏洞。

把定位對象換掉

如果前面的判斷成立,定位偏差時需要改變的就不只是搜索深度,而是搜索對象。

「哪個組件壞了」檢查的是一個已經被劃出的對象;「哪一個關係斷了」檢查的,則是兩個對象之間原本必須保持成立、卻沒有被任意一端單獨保證的條件。

兩種提問面對的搜索空間不同。

組件已經被系統切分出來:它們有名字、有邊界,也通常有各自的狀態、日誌和觀測入口。因此,逐項檢查組件能夠形成一個相對明確的搜索集合。

對象之間的連接卻未必已經以同樣方式被登記。兩個端點都可以被準確指認,並不意味著它們之間那段必須保持成立的條件也已經成為一個可以直接檢查的位置。

證據要求也隨之改變。

檢查組件時,可以查看它自己的狀態:有沒有報錯,是否超時,返回了什麼。檢查對象之間的關係,則需要回答另一類問題:前一個對象中成立的內容,在進入後一個對象時是否仍然成立;作出判斷時依賴的事實,在動作發生時是否仍然有效;兩個端點此刻指向的,是否仍然是同一件事。

這類問題不能僅靠兩端各自的內部材料自動回答。記錄足夠完整,只能說明我們對對象內部知道得很多,並不能因此推出對象之間的關係也已經被驗證。

上一章已經留下了一個這樣的例子。執行動作成立,本身不足以推出結果成立。

這並不是說動作與結果之間已經存在一個被本書正式定義好的「關係對象」。它只是說明:動作成立這一事實,不能代替對結果本身的判斷。兩端都能夠分別成立,仍然不足以建立它們之間所需要的對應。

因此,「哪一個關係斷了」在這裡是一種定位方式。它要求我們檢查對象之間原本依賴的條件,而不是繼續假定所有偏差最終都能夠被壓回某個組件內部。

本書不把「關係」註冊成一個新的正式概念,也不給它編號。這裡的「關係」承擔的是位置,而不是身份。一旦把它重新做成一個帶有固定內部結構的對象,原來的問題就可能只是被換了一層名字重新出現。

十七個已經核驗過的失敗

到這裡,前面的判斷仍然只是一個關於位置的判斷。現實材料能提供的,不是對它的證明,而是另一種東西:看看已經發生過的失敗,是否反覆呈現出同樣的分佈。

現有材料裡有十七個經過事實核驗的現實失敗。每個案例都有官方、一手、司法或監管來源支撐,並按照同一組關係維度分別進行分析。

本章只取其中一個分佈事實。

在這十七個案例中,同一個失敗可以同時在多個維度上被判為 Strong。其中兩個維度在十七個案例中全部為 Strong,另外兩個維度分別在十一個和十三個案例中為 Strong。沒有任何一案能夠僅由單一組件故障完整解釋。

這個分佈值得注意的地方,不在於哪一個維度出現得最多,而在於多個維度可以在同一個失敗中同時成立。

至少在這十七個已經核驗的案例裡,失敗並沒有穩定地收縮成一個唯一斷點。

但這些數字的含義到這裡為止。

它們不能把每個案例唯一歸到某一處斷裂。Strong、Partial、None 也不是嚴重程度排序,更不是在多個候選原因中挑出一個「最重要」的答案。多個維度同時為 Strong,本身就說明這種單點式讀法並不適合這些材料。

這些案例同樣不能證明當前結構已經完備。它們只能說明:在目前這組材料中,還沒有出現迫使我們增加一級結構的證據必要。

更重要的是,這十七個案例不是這套理論的證明。

它們在這裡承擔的是經驗背景:讓「偏差不在某一點上」不只停留在抽象推理中,而能夠在一組已經核驗的現實失敗裡看到相應的分佈。

至於這些維度分別叫什麼、邊界如何劃分、彼此之間又是什麼關係,本章暫時不回答。

組件仍然會壞

這裡必須擋住一種過度解讀:把視線移到對象之間,並不意味著組件本身不再重要。

單點故障當然存在。磁盤會壞,服務會宕,代碼可能執行錯誤的分支,配置也可能寫錯。冗餘、重試、熔斷、回滾等工程手段,正是用來處理這一類問題的。

因此,核心判斷裡真正重要的是「而不只是單點漏洞」中的「不只是」。

它排除的是這樣一個默認前提:只要發生偏差,就一定能夠在某個組件內部找到一個足以解釋全部結果的故障。它並沒有否定組件會壞,也沒有否定圍繞組件建立起來的可靠性工程。

兩類問題也並不互相排斥。一個組件可以真的發生故障,同時對象之間原本需要保持成立的關係也可以出現偏差。找到一個壞掉的部件,能夠解釋其中一部分現象,卻不能自動推出整個結果已經被解釋完畢。

真正改變的是組件檢查結束之後的下一步。

當已經發現了組件故障,就處理組件故障;當組件逐項成立,而最終偏差仍然沒有得到解釋,就不能只靠繼續向對象內部拆得更細。此時需要把視線移到對象之間,檢查那些沒有被組件內部成立性覆蓋的關係。

那麼,哪些關係會斷

把視線從對象內部移到對象之間以後,至少有一件事變得清楚了。

當各個對象都能夠在自己的範圍內成立,而最終偏差仍然沒有得到解釋時,定位不能繼續默認落在某個組件內部。轉換、時差、接縫和關係所指向的,是對象之間那個原本需要保持成立的位置。

但知道位置,還不等於知道該檢查什麼。

「關係」這個詞仍然太大。系統裡的兩個對象之間可以存在許多不同的聯繫,如果沒有進一步的邊界,任何兩個對象似乎都可以被拿來檢查。這樣一來,原本無限向對象內部拆解的問題,只會變成無限向對象之間擴張。

所以,位置判斷只能告訴我們往哪裡看,還不能告訴我們搜索應該在哪裡停止。

也不能靠列一張儘可能長的連接清單解決這個問題。把能想到的對象兩兩連起來,只會得到更多候選關係;如果不知道其中哪些關係真正承擔著執行過程中的必要條件,清單本身不會產生邊界。

這正是下一步需要回答的問題。

哪些關係會斷?


本章術語

  • 轉換 | Transformation
  • 時差 | Temporal Gap
  • 接縫 | Seam
  • 關係 | Relation
  • 單點漏洞 | Single-Point Vulnerability
  • 單點故障 | Single-Point Failure
  • 內部成立 | Internal Validity

本章案例與資料來源

十七個正式核驗案例池

本章使用《執行縫隙》研究階段建立的第一、二批正式案例池,共十七個經過事實核驗的現實失敗案例。案例事實分別依據官方文件、一手材料、司法記錄或監管材料進行核驗。

這些案例在本章承擔的是案例池級背景材料,而不是對本章理論判斷的證明。本章也不把任何一個案例唯一歸入某一種關係類型,而只使用案例池中的一個聚合分佈事實:在同一個已核驗案例中,可以有多個分析維度同時被判定為 Strong;其中兩個維度在十七個案例中均為 Strong,另外兩個維度分別在十一個和十三個案例中為 Strong。

這一分佈只說明:在這組已經核驗的材料中,多個維度可以同時出現。它不代表現實失敗總體的統計頻率;Strong、Partial、None 也不是嚴重程度排名;這組案例同樣不能證明當前結構已經窮盡所有可能的關係或機制。

完整案例說明

本章正文不逐案展開這十七個案例,也不在這裡重新進行案例歸類。

十七個案例的完整說明統一收錄於本書附錄 《現實失敗與邊界案例》 中的 「十七個正式核驗案例池」 部分。每個案例將列出:

  • 案例名稱與事件時間;
  • 事件事實摘要;
  • 案例進入本書研究範圍的原因;
  • 本書使用該案例的位置;
  • 主要官方、一手、司法或監管來源;
  • 必要的證據限制、爭議或適用邊界。

讀者可以通過該附錄查看本章所稱“十七個正式核驗案例”具體指哪些事件,以及每個案例的事實依據。

資料來源

本章正文引用的是十七個案例的案例池級彙總結果。逐案事實來源與完整書目信息不在本章重複展開,統一列入附錄 《現實失敗與邊界案例》 及全書 《參考文獻與資料來源》。



第四章|五類會斷的關係

本章把“哪些關係會斷”收斂為五類直接機制族:判斷與綁定關係失效、執行路徑偏離、執行邊界失效、執行狀態與結果關係失效,以及因果鏈內證據與證明關係失效。它們不是五個互斥標籤,也不是正式編號,而是在現有證據下“條件凍結”的一級結構:若某一族可被無損吸收,或出現具有獨立對象、獨立因果位置且可重複的新機制,結構仍需重開。五類分別回答偏差通過什麼結構位置獲得繼續進入現實的條件;其中 Boundary Mutation 只是邊界失效的強 subtype,證據也只有進入當前或後續動作的因果鏈時才屬於這一族。變化與放大另有作用,但都不是第六類直接機制。

把定位對象從「哪個組件壞了」換成「哪一個關係斷了」,是上一章做完的事。

這一步改變了搜索空間。排查不再默認所有偏差最終都必須落進某個組件內部;當對象各自在自己的範圍內成立時,對象之間原本需要保持成立的關係也進入了視野。

但這個變化立刻留下了另一個困難:「關係」這個詞本身並不提供候選項。

一次事故里能夠被指認出來的關係很多。發起人與審批人之間有關係,審批與付款金額之間有關係,配置文件與解釋它的程序之間有關係,控制室的指示燈與閥門的實際位置之間有關係,一條運維命令的參數與它將要影響的容量之間也有關係。

如果「哪一個關係斷了」意味著把這些關係全部列出來逐項排查,它並沒有真正解決上一章留下的問題,只是把組件清單換成了關係清單。系統裡的兩個對象之間總可以找到某種聯繫;沒有進一步的限定,候選關係可以不斷增加,搜索也就沒有自然的終點。

所以,要讓「哪一個關係斷了」從一個位置判斷變成可以使用的定位工具,還需要繼續收窄。

並不是每一種關係變化都能解釋偏差為什麼最終到達現實。真正需要回答的是一個更具體的問題:

什麼樣的結構性失敗,使得一次偏差能夠到達現實?

當前研究中能夠回答這個問題的,是下面五類直接機制族。

五個位置

當前研究把這種結構性失敗收斂為五類直接機制族:

判斷與綁定關係的失效(Decision / Binding Relation Failure)、執行路徑的偏離(Execution Path Deviation)、執行邊界的失效(Execution Boundary Failure)、執行狀態與結果關係的失效(Execution State / Result Relation Failure),以及因果鏈內證據與證明關係的失效(In-Causal-Chain Evidence / Proof Relation Failure)。

在進入這五類之前,需要先劃清它們的使用邊界。

首先,它們不是五個正式機制編號,也不是一張可以拿來逐案填空的分類表。本書不給它們編號。編號很容易製造一種錯覺:彷彿這五類已經成為彼此獨立、邊界永久封閉的正式對象。當前研究並沒有走到這一步。

其次,本章不把它們作為互斥分類來使用。一個具體失敗究竟只能落在其中一類,還是可能同時落在幾類,是另一個問題,本章暫時不回答。

第三,這五類目前處於條件凍結狀態。

所謂條件凍結,是說在現有證據範圍內,它們已經穩定到足以承擔分析和定位,但仍然保留重新打開的條件。只有兩種情況會迫使這套結構重新檢查:一種是其中某一族能夠被另一族無損吸收,不再具有獨立存在的必要;另一種是出現一種新的失敗機制,它具有獨立的對象、獨立的因果位置,並且能夠在多個案例中重複出現。

因此,條件凍結既不是「最終定稿」,也不是「還沒有想清楚」。它表達的是一個有邊界的研究狀態:在目前材料下,不需要繼續增加一級結構;如果未來出現足夠強的新證據,這個結論仍然可以被重新打開。

這五類的用途也很有限。

它們不回答一次事故為什麼最終會發生,也不替代責任判斷。它們回答的是一個更窄的問題:偏差通過什麼結構位置獲得了繼續進入現實的條件?

於是,「哪一個關係斷了」不再要求我們檢查所有可能存在的關係,而可以繼續收窄為幾類具體追問:已經成立的判斷有沒有繼續綁定到當前動作,實際執行有沒有走在原來的路徑上,限制動作到達現實的邊界有沒有失效,局部狀態與最終結果之間有沒有繼續對應,以及參與當前或後續動作的證據有沒有失去它原本應當具有的資格或聯繫。

為什麼最後得到的是這五類,而不是另外一組?

這條區分線並不是先畫好一張分類表,再把案例塞進去。它來自對現實失敗的反覆追問:哪一個必要的對應沒有繼續成立,失敗又發生在執行鏈的什麼位置。

後面五節分別展開這五類。每一類都只回答三件事:它最小意味著什麼,現實中通常以什麼形態出現,以及什麼情況明確不屬於它。

已經成立的東西,沒有跟上

這一族關心的是一個已經成立的意圖、決定、批准、授權、策略或資格,是否仍然與當前動作的對象、參數、目標、狀態、語義、來源或範圍保持著必要的對應。

問題不在於上游對象有沒有存在過。它可以真實存在,也可以在自己的範圍內完全成立。真正發生斷裂的,是它繼續向下約束當前動作時,原本必須保持的綁定已經丟失。

這種失效可以有很多形態。舊資格被繼續用在新的對象上;批准的內容與實際載荷沒有綁定在一起;一個判斷依賴的來源集合並不完整;某一處局部放行被繼續解釋成了最終執行資格。兩端分別看都可能成立,錯的是它們之間原本必須保持的對應。

2020 年 8 月 Citibank 的 Revlon 誤付款就是一個清楚的例子。銀行原本需要處理約七百八十萬美元的利息,併為貸款結構調整進行內部賬務處理。Flexcube 中的操作需要把交易錄入為全額償還,同時通過內部 wash account 保留本金。執行人員需要選中三個界面選項,實際只選中了其中一個,兩名複核人員也沒有發現這一差異。系統隨後按照已經錄入的字段,把接近十億美元的銀行自有資金實際匯給了債權人。

這裡並不缺少真實的業務意圖,也不缺少真實發生過的複核。問題在於,被複核和被批准的工作流,並沒有繼續完整綁定到最終資金流向與金額所表達的業務含義。把這個事件壓縮成「有人按錯了一個按鈕」,反而會丟掉真正重要的部分:wash account 的賬務構造、三個選項以及兩級複核都存在,但它們沒有保證最終被執行的對象仍然是原來那個對象。

Storm-0558 展示了同一種斷裂在另一種技術結構中的樣子。攻擊者使用的是微軟真實存在的一把 2016 年 MSA consumer signing key,由它簽發的 token 在密碼學意義上可以通過驗證。問題在於,Exchange Online 的驗證邏輯沒有拒絕由 consumer key 簽發的 token 去訪問 enterprise 賬戶。

簽名可以被驗證,只能證明 token 與那把 key 之間的密碼學關係成立,不能由此推出這把 key 對當前 tenant、賬戶和時刻具有相應資格。最終被認定受到訪問的是 22 個企業組織與 503 個相關個人賬戶。至於攻擊者究竟如何取得這把 key,在相關審查完成時仍未得到確定解釋,因此本書也不使用任何早期假說去填補這一空白。

類似的結構還可以出現在完全不同的系統中。

Mars Climate Orbiter 的地面導航建模數據存在單位不一致。一組數值可以被系統正常接收、正常計算、正常向下使用,卻已經不再表示接收方以為它所表示的那個物理量。

Ariane 5 的 501 次飛行則呈現了另一種情況:被複用的軟件帶著原有設計條件進入新的運行包線,而支持這種複用的測試證據並沒有覆蓋真實系統實際面對的條件。被證明成立的對象仍然存在,但它的成立範圍沒有自動跟著新的執行環境一起擴大。

Boeing 737 MAX 的兩起事故中,也能看到事實來源資格與後續控制作用之間的錯配。一個輸入來源被賦予了超出其資格足以支撐範圍的控制作用,而系統中存在兩個傳感器這一事實,並不能自動建立獨立、正交的驗證。兩起事故共享這一關鍵結構,但它們不能因此被壓縮成完全相同的因果鏈。

這一族的邊界同樣重要。

首先,它不要求執行路徑發生改變。付款可以走正常支付系統,token 可以走正常驗證流程,數據也可以沿著正常處理鏈繼續傳播。路徑完全正常,並不保證當前動作與上游已經成立的對象仍然保持正確綁定。

更重要的一條邊界是:規範上錯誤、但被系統忠實執行的上游決定,不能僅憑結果不好就自動改寫成執行縫隙。

如果一個已經形成的決定本身存在法律、規範或判斷上的問題,而系統隨後準確執行了它,那麼首先需要被區分的是上游決定本身,因為決定與執行之間的對應關係可能恰恰沒有斷。

這條限制並不是在替錯誤結果開脫。它只是防止這一族失去自己的定位能力。如果任何不好的結果都能夠事後被解釋成「綁定失效」,那麼這個概念最終將無法區分究竟是上游對象本身有問題,還是一個已經成立的上游對象在進入執行時沒有繼續約束住同一件事。

在目前十七個經過事實核驗的案例中,這一維度均被判定為 Strong。這個數字在這裡承擔的只是經驗分佈意義:說明這種斷裂在當前案例池中反覆出現,而不是為五類機制建立重要性或穩定性排名。

這一次實際是怎麼走的

執行路徑的偏離(Execution Path Deviation)關心的不是動作最後做成了什麼,而是:這一次執行實際上是怎麼走到那裡的。

這裡的「路徑」有很具體的含義。實際執行的步驟、順序、主體、入口或鏈路,與原本應當成立的執行過程發生偏離;必要步驟被跳過,新的步驟被插入,順序被重排,舊動作被重放,主體被替換,執行進入替代入口,或者若干局部都合法的工具被組合成一條整體上未經授權的鏈路,都可能屬於這一族。

關鍵不在於過程有多少步,而在於實際發生的那條執行鏈已經不再是原來那條鏈。

Knight Capital 在 2012 年的事故提供了一個很清楚的例子。

新代碼被部署到八臺服務器,其中一臺被遺漏;與此同時,一個已經廢棄的 Power Peg 標誌又被複用於新功能。訂單進入那臺沒有完成部署的服務器時,觸發的不是預期的新邏輯,而是遺留的舊邏輯。

這裡發生的不是新代碼算錯了,而是預期路徑與實際路徑發生了分叉:同一個入口,在不同服務器上進入了不同的執行鏈。

事故處理過程中,這種路徑偏離又出現了一次。為了停止異常交易,操作人員從七臺已經運行正確代碼的服務器上卸載了新代碼。結果是,原本只在一臺服務器上存在的舊路徑,被重新暴露到了更多節點。一次意在收斂問題的操作,反而改變了系統接下來能夠走出的路徑。

SolarWinds 展示的是另一種形式。

惡意步驟被植入供應商自身的構建與更新過程,受汙染的軟件隨後沿著正常的軟件分發機制進入客戶環境。近一萬八千家客戶收到了相關更新,但收到更新並不等於都被進一步利用。

這裡值得區分兩個層次:客戶看到的分發過程可以是正常的,但在它之前,構建鏈本身已經被插入了原本不屬於那條路徑的步驟。路徑偏離發生在哪裡,不能只看最後一段傳輸是否按照正常流程完成。

這一族最容易被放寬,所以它的否定邊界必須保持嚴格。

多步驟,不等於路徑偏離。長因果鏈,不等於路徑偏離。複雜調用,也不等於路徑偏離。一個錯誤對象沿著完全正常的路徑傳播,同樣不等於路徑偏離。

AWS 2017 年的 S3 服務中斷中,運維人員使用的是既有 playbook 和正常工具,問題來自輸入參數使實際移除的服務器數量遠大於原本意圖的數量。執行鏈本身並沒有因為後果嚴重就變成另一條鏈。

Citibank 的誤付款也沿著正常的支付和電匯系統完成。錯誤發生在被綁定和複核的內容,而不是資金後來走了一條未經授權的支付路徑。

Waymo 的案例同樣如此。車輛執行低速靠邊動作時,並沒有因為最終結果錯誤,就自動說明它偏離了預定的執行流程。

因此,判斷這一族的關鍵問題不是:

這件事是不是很複雜?

也不是:

最終結果是不是很嚴重?

而是:

實際發生的執行步驟、順序、主體、入口或鏈路,是否偏離了原本應當成立的那一條路徑?

在目前十七個經過核驗的案例中,這一維度有兩例被判定為 Strong,十例為 Partial,五例不成立。

這個分佈不表示路徑偏離不重要。相反,它提醒我們必須嚴格控制這一族的適用範圍。只要把「過程複雜」或「結果嚴重」都算成路徑偏離,它就會迅速失去定位能力。

至於執行路徑的偏離與執行邊界的失效究竟是什麼關係,本章暫時不回答。

誰還能拒絕

執行邊界的失效(Execution Boundary Failure)關心的是另一件事:當一個動作正在接近現實,它原本受到的限制是否仍然存在並且有效。

這裡的重點不是這一次請求經過了哪些步驟,而是那些本來限制動作範圍、能力與最終執行的約束髮生了什麼。

邊界失效可以呈現出幾種不同形態。約束可能從一開始就不存在;也可能存在,卻沒有覆蓋真正危險的動作;還可能已經建立,卻在需要阻止動作的時刻沒有發揮作用。還有一種更強的情況:原本決定路徑、能力範圍或最終否決的規則與實施主體本身發生了改變。

這些情況都可以讓原本不應當到達現實的動作繼續向前,但它們不是同一種失效。

Knight Capital 的事故中,並不存在一道自動比較輸出訂單量與輸入父訂單量的限制。當舊邏輯開始持續生成子訂單時,沒有另一個約束根據父訂單已經完成這一事實自動阻止後續輸出。這裡首先暴露的是邊界缺失,而不是某一道已有邊界後來被突破。

AWS 2017 年 S3 服務中斷呈現的是另一種形態。運維工具本身允許一次操作在很短時間內移除遠超預期規模的服務器,而當時沒有把輸入規模與子系統能夠繼續維持運行的最低容量綁定起來。事後增加的最低容量保護、移除速度限制和故障域收窄,反過來說明了事故發生時哪些限制並沒有覆蓋這條能力。

2018 年夏威夷導彈誤報則讓這種問題落到了操作權限上。真實警報與測試模板位於同一個界面,並使用同一套登錄憑證;一個具有相應憑證的值班人員就能夠把全州警報真正發送出去。錯誤被發現之後,當時的取消操作只能停止後續轉發,不能撤回已經顯示在公眾設備上的消息,也不會自動產生更正。第一條更正在三十八分鐘後才通過同一渠道發出。

這裡值得注意的不是界面設計本身,而是:一旦那次動作已經越過現有約束進入現實,系統沒有另一道邊界把它留在測試範圍內。

Therac-25 提供了一個更鮮明的對照。導致 1986 年 Tyler 事故的競態條件,在前一代 Therac-20 上同樣存在,但 Therac-20 的獨立硬件聯鎖能夠阻止危險束流。軟件層可以出現相似的錯誤,而現實後果是否繼續形成,還取決於錯誤之外是否存在能夠阻斷危險動作的約束。

這並不意味著 Therac-25 的六起事故都來自同一個競態。1987 年 Yakima 的事故涉及另一項軟件缺陷。這個案例在這裡說明的也不是某個特定 bug,而是:不同錯誤都可能因為缺少足以阻止其繼續到達現實的限制而形成後果。

Boeing 737 MAX 在這一維度呈現的同樣不是簡單的“某個東西壞了”。單一輸入來源與能夠重複作用的控制能力落在同一條執行鏈上,而現有結構沒有把這種組合限制在不足以形成持續現實影響的範圍之內。這裡討論的是邊界失效的形態,不把兩起事故進一步壓縮成完全相同的因果鏈。

這裡必須單獨區分 Boundary Mutation。

Boundary Mutation 是執行邊界失效的強 subtype,不是執行邊界失效的同義詞。

Mutation 指的是原本決定路徑、能力範圍或最終否決作用的規則與實施主體本身被改寫。前面的 Knight、AWS、夏威夷和 Therac-25 並不需要發生這種改寫才能構成邊界失效:邊界可以從一開始就不存在,也可以覆蓋不足,或者在需要的時候沒有發揮作用。

如果把所有 Boundary Failure 都理解成 Boundary Mutation,排查就會默認尋找“到底是誰改了規則”。這樣反而會漏掉另一類失敗:什麼都沒有被改寫,只是那道本應約束危險動作的邊界原本就沒有覆蓋到這裡。

在目前十七個經過核驗的案例中,執行邊界這一維度有十一例被判定為 Strong,六例為 Partial。這一分佈描述的是當前案例池中的證據強度,不意味著十一例都發生了 Boundary Mutation。

這一族還有一條必須保持清楚的否定邊界。

執行邊界關注的是控制規則與最終拒絕能力的失效。它不能被整個併入執行路徑。

一次請求實際經過了多少個步驟、節點或入口,與系統在動作到達現實之前是否仍然存在有效限制,是兩個不同的定位問題。路徑可以沒有偏離,邊界仍然可能失效;至於這兩類失敗之間能否互相吸收,以及應該怎樣區分,是下一章要繼續處理的問題。

本章到這裡也只討論邊界如何失效。一道執行邊界在工程上究竟需要滿足哪些條件才能成立,不在本章建立。

局部完成,不是現實結果

執行狀態與結果關係的失效(Execution State / Result Relation Failure)關心的是:一次調用、一次提交、一個階段狀態、一張回執或已經形成的結果,是否仍然被正確地理解和歸屬於它原本指向的對象。

上一章已經區分過提交、調用、執行狀態、回執與結果。它們可以分別成立,卻不能因為其中一個成立,就默認另一個也已經成立。

這一族的斷裂就發生在這種對應關係上。

局部成功可能被解釋成整體完成;未知狀態可能被當成成功;回執可能被當成結果;已經發生的結果,也可能被歸到錯誤的意圖或動作上。

三哩島事故中,控制室的指示主要反映的是關閉命令,而不是閥門實際所處的位置。命令已經發出、指示已經存在,都不能由此推出物理狀態已經與它們一致。被看到的狀態,與現實中真正成立的狀態,並不是同一個對象。

Knight Capital 的事故則發生在另一處。系統某一部分已經知道父訂單成交,但這個狀態沒有進入仍在發送子訂單的那一側。於是後續動作繼續建立在一個已經不再成立的前提上。局部狀態真實存在,卻沒有繼續約束依賴它的後續執行。

Cruise 2023 年的事故中,車輛第一次停止,並不意味著現實狀態已經進入安全終態。行人位於車輛下方時,隨後發生的靠邊動作說明:某一階段動作已經完成,並不能替代對當前現實結果的判斷。

Waymo 2024 年的案例也呈現出同樣的區分。低速靠邊這一動作目標本身可以成立,但動作目標成立,並不自動說明最終形成的現實結果仍然與它保持一致。

在目前十七個經過核驗的案例中,這一維度均被判定為 Strong。這裡使用的仍然只是案例池中的分佈事實,不表示這一族比其他機制更加重要。

這一族的否定邊界也很簡單:

狀態與結果之間的關係是否成立,不等於相關證據是否存在。

三哩島的指示存在,Knight 的成交狀態也存在。真正的問題不是「有沒有記錄」,而是那個狀態或記錄究竟代表什麼,以及它是否仍然能夠代表後續判斷正在使用的那件事。

證據本身如何進入當前或後續動作,是下一族的問題。

證據推動了下一個動作

因果鏈內證據與證明關係的失效(In-Causal-Chain Evidence / Proof Relation Failure)關心的不是系統有沒有留下記錄,而是:某份證據是否正在參與當前判斷、執行、重試、恢復或下一次動作,而它與來源資格、對象、順序、前序、連續性或現實事實之間的關係已經失效。

錯誤的事實來源可以獲得判斷資格;過期或不完整的證據可以繼續推動動作;一段斷裂的記錄可以造成錯誤重試;事後形成的記錄,也可能重新進入下一輪判斷,並影響後續資格與行動。

在目前十七個經過核驗的案例中,這一維度有十三例被判定為 Strong,四例為 Partial。

CrowdStrike 2024 年的事故中,內容驗證器依據的是二十一項輸入契約,而傳感器實際提供二十項,生產解釋器隨後訪問了不存在的第二十一項並導致崩潰。觸發事件的是 Rapid Response Content 更新,不是新的內核驅動代碼,也不是網絡攻擊。內容能夠通過既有驗證與簽發,並不能證明運行時真正依賴的輸入契約已經成立。

Ariane 5 的測試材料呈現的是相近的問題:測試證據能夠支持被測試條件下的結論,但不能自動覆蓋真實系統後來實際進入的運行條件。

Challenger 則從另一個方向說明了同一件事。相關工程證據與反對意見存在,但並沒有完整進入最終決定。證據存在,與證據真正取得當前裁決資格,並不是一回事。

Knight Capital 在事故發生前收到過九十七封「Power Peg disabled」自動郵件。信號已經產生,但它們沒有被作為系統告警使用,也沒有綁定能夠阻止後續執行的動作。證據的存在本身,沒有改變執行。

Post Office Horizon 展示了證據如何繼續進入後續現實動作。系統產生的短缺記錄被用於追償、解約與起訴;後來法院認定系統存在能夠並實際造成分支賬戶短缺的缺陷。由記錄推動的行動,又會產生新的記錄,並繼續影響後面的判斷。這並不是說每一筆短缺都不存在,也不能把不同案件壓縮成同一事實鏈;這裡使用的只是記錄如何取得現實行動資格這一部分。

Cruise 的案例也說明,擁有證據與證據完整進入正式判斷並不是同一件事。完整視頻已經提供給監管機構,而法定書面報告仍遺漏了拖行動作。

這一族最重要的邊界只有一條:

只有當證據進入當前或後續現實動作的因果鏈時,它才屬於這一族。

如果執行已經完成,現實結果也已經確定,而問題只剩下事後無法觀察、無法證明、無法審計或無法追責,那麼這種證明缺失默認不屬於這裡。

判據不是記錄質量,而是因果位置。

但如果這種證明缺失隨後又造成錯誤的狀態假定、重試、恢復或下一次動作,那麼從它重新開始影響現實的那個節點起,它又進入這一族。

變化與放大,回答的是別的問題

前面五類直接機制回答的是同一個問題:什麼結構性失敗,使偏差得以到達現實?

但事故分析中還有兩個很容易與這個問題混在一起的對象:變化(Change)與放大(Amplification)。

它們都重要,卻不屬於這五類。

「什麼變了」是在追問事故過程中發生了哪些變化。這個問題可以幫助我們發現對象、狀態、參數或條件發生了移動,但它本身並沒有回答:究竟是哪一種關係失效,使偏差能夠繼續進入現實。

因此,本章只做一個區分:Change 不是第六類直接機制。

放大也是如此。

一個偏差可以傳播得更廣、更快,也可能失去更多被及時停止或糾正的機會。這些現象會改變後果的規模,卻沒有因此成為另一種與判斷、路徑、邊界、結果或證據並列的直接機制。

所以,Amplification 也不是第六類或第七類直接機制。

這裡尤其不能把放大理解成「偏差發生之後的一個階段」。它並不由時間上的前後位置定義;在本章裡,只需要保留一個邊界:放大描述的是偏差如何被擴大,而不是偏差通過哪一種結構性失敗獲得進入現實的通道。

把 Change 與 Amplification 塞進五類,看上去會讓結構更完整,實際卻會混淆幾個不同的問題:

五類機制問的是哪裡斷了;變化問的是什麼發生了變化;放大問的是已經出現的偏差如何擴大影響。

本章只建立第一類問題的定位對象。後兩類問題在這裡不繼續展開。

為什麼目前停在五類

目前這五類直接機制族,建立在十七個已經完成事實核驗的現實案例之上。案例覆蓋航天、醫療設備、核電、交易、航空、雲運維、支付、公共預警、自動駕駛、終端安全、雲身份、軟件供應鏈與司法證據等不同場景。

這些材料並沒有證明五類結構已經完備。

它們只能支持一個更有限的判斷:在當前案例池中,還沒有出現必須增加一個新的一級結構性機制才能解釋的失敗。

研究過程中,至少有三個候選曾經看起來可能需要單獨成為新的一類。

一種是證據反過來影響後續權限與資格。Cruise 與 Post Office Horizon 都能看到這種形態。但繼續拆開之後,它仍然可以由已有關係在多個輪次中的重新進入來描述:證據先影響下一次判斷,再由下一次判斷進入新的執行。這裡沒有出現一個新的基本失敗對象。

另一種是資格跨組織或跨域繼承。Storm-0558 與 SolarWinds 都出現了跨越原有邊界繼續取得作用資格的現象,但兩者實際涉及的對象並不相同。前者涉及簽名、簽發域、租戶與賬戶範圍;後者涉及供應商、發佈版本、載荷與客戶側安裝權限。繼續分析之後,它們仍然可以落回已有的綁定關係、邊界以及其他既有位置中,而沒有形成一個獨立的新機制。

第三種候選是:規範上無效的決定被系統正確執行。

這個問題與前兩種不同。它首先要求回答的是:那個上游決定是否已經具備進入執行縫隙分析的資格。也就是說,它首先是執行縫隙邊界之外的資格問題,而不是五類機制內部還缺少一個位置。

因此,目前停在五類,並不是因為已經證明不存在第六類。

真正成立的只是一個有界結論:在現有案例和證據範圍內,這三個曾經值得懷疑的候選,都還沒有形成一個具有獨立對象、獨立因果位置並能夠重複出現的新機制。

這也是「條件凍結」真正約束的地方。

如果未來出現這樣的證據,這套結構就應當重新打開。

兩個問題,從這裡分開

到這裡,讀者手裡已經有了五個可以繼續追問的定位對象。

但這五類一旦真正放回案例,立刻會留下兩個不同的問題。

第一個出現在執行路徑與執行邊界之間。

Knight Capital 的事故里,可以同時看到實際運行路徑與預期路徑發生分叉,也可以看到原本缺少限制異常訂單繼續進入市場的邊界。夏威夷誤報則從另一個方向製造了同樣的疑問:錯誤警報最終沿著真實的傳播系統被忠實送達,但真正需要追問的,又不只是消息經過了哪條鏈路。

於是問題出現了:

「這一次請求走錯了路」與「約束本身失效了」,是不是同一種失敗?

這是下一章要處理的問題。

第二個問題來自五類機制作為一個整體的性質。

同一個案例可以在不同位置反覆出現。Knight 同時涉及路徑、邊界、狀態與結果以及證據;Boeing 737 MAX 可以同時觸及判斷與綁定以及執行邊界;Cruise 的車輛動作與後續報告鏈,又分別暴露出狀態與結果、證據與證明之間的不同問題。

這種重疊並不能靠第四章直接解釋。

於是還有另一個問題:

這五類是否互斥?給定一次具體的偏差,我該如何定位它?

這將是後面的另一個任務。

這兩個問題不能合成一個。

前一個追問的是兩個具體機制族之間的邊界;後一個追問的是五類機制作為一個整體應該怎樣被使用。回答前一個問題,並不會自動得到後一個問題的答案。

第四章到這裡停下。

它完成的事情只有一件:把上一章那個過於寬泛的「哪一個關係斷了」,第一次收窄成五類可以繼續檢查的直接機制。

接下來,先處理最容易被混在一起的那一對。

「這一次請求走錯了路」與「約束本身失效了」,是不是同一種失敗?

本章術語

  • 直接機制族 | Direct Mechanism Family
  • 判斷與綁定關係的失效 | Decision / Binding Relation Failure
  • 執行路徑的偏離 | Execution Path Deviation
  • 執行邊界的失效 | Execution Boundary Failure
  • 執行狀態與結果關係的失效 | Execution State / Result Relation Failure
  • 因果鏈內證據與證明關係的失效 | In-Causal-Chain Evidence / Proof Relation Failure
  • 條件凍結 | Conditionally Frozen
  • 變化 | Change
  • 放大 | Amplification

本章案例與資料來源

十七個正式核驗案例池

本章繼續使用《執行縫隙》研究階段建立的十七個正式核驗案例池。

與上一章不同,這些案例在本章不再只承擔案例池級背景作用,而是用於展示五類直接機制在現實失敗中的具體形態。案例並不被唯一歸入某一類;同一個案例可以在不同機制位置上反覆出現,本章也不把任何一個案例固定為某一機制族的唯一代表。

正文實際使用了十七個案例池中的十六個案例:

Mars Climate Orbiter、Challenger、Therac-25、Ariane 5 Flight 501、Three Mile Island、Knight Capital、Boeing 737 MAX、AWS S3、Citibank–Revlon、2018 Hawaii False Missile Alert、Waymo、CrowdStrike、Cruise、Storm-0558、SolarWinds,以及 Post Office Horizon。

這些案例分別用於說明判斷與綁定、執行路徑、執行邊界、狀態與結果以及因果鏈內證據與證明關係可能如何失效。一個案例在正文中出現於多個位置,並不表示這些機制已經被證明互斥或形成了逐案分類體系。

本章同時引用十七個案例的聚合分析結果,包括各機制維度中的 Strong、Partial 與不成立分佈。這些結果只描述當前案例池中的證據分佈,不構成五類機制的重要性、嚴重程度或優先級排序。

完整案例說明

正文不重複展開每個案例的完整事實鏈、核驗過程與全部資料來源。

十七個正式案例的完整說明統一收錄於本書附錄 《現實失敗與邊界案例》 中的 「十七個正式核驗案例池」 部分。每個案例將列出事件背景、事實摘要、本書中的使用位置、主要官方或一手來源,以及必要的證據限制和適用邊界。

本章所使用的案例均來自該正式案例池;Robodebt、Moffatt v. Air Canada Chatbot 與 The DAO 三個邊界案例,不納入本章五類直接機制的案例展示。

資料來源

本章涉及的現實事件事實,均以相應案例已經完成的官方、一手、司法、監管或其他權威材料核驗結果為基礎。

逐案事實來源與完整書目信息不在本章重複列出,統一收錄於附錄 《現實失敗與邊界案例》 及全書 《參考文獻與資料來源》。


第五章|走錯了路,和攔不住,不是同一件事

本章把執行路徑與執行邊界徹底分開。Path 問的是“這一次請求實際怎麼走到那裡”,Boundary 問的是“這個動作能走多遠、什麼東西能夠最終限制或拒絕它”;前者關注實際行進是否偏離規範路徑,後者關注約束本身是否仍然有效,因此執行邊界不是訪問控制的另一種寫法。現實案例說明,路徑完全正常時,錯誤 Action 仍然可以沿著規範路線到達現實,所以 Path Deviation 不是執行縫隙的必要條件。Boundary Mutation 也只是 Boundary Failure 的強 subtype:邊界可以被改寫,也可以在沒有顯式改寫的情況下失效。於是“走錯了路”與“攔不住”成為兩個獨立判斷,不能互相替代。

上一章末尾留下兩個問題,第一個看上去最容易處理。路徑和邊界,一個問請求實際怎麼走,一個問什麼能夠攔住它——聽上去很像同一件事的兩種說法。走錯了路,不就是因為沒有東西攔住;攔不住,不也總會表現為請求最終走到了不該到的地方。把兩個說法合併,敘述會更簡單,需要保留的對象也少一個。

這一章要做的,就是拆掉這個合併。

它之所以值得單獨拆開,是因為這種合併非常符合直覺。我們很容易把控制想像成一條通道:請求沿著通道向前,途中設置若干關卡;一旦出事,就意味著某個東西穿過了本來應該擋住它的地方。在這個畫面裡,「走錯路」和「沒攔住」確實像是同一件事——路徑是通道,邊界是關卡,二者描述的是同一條線上的同一次穿越。既然如此,要麼加固關卡,要麼收窄通道,看上去都只是同一類工程問題。

麻煩在於,本書討論的失敗並不總是這樣發生。

偏差並不一定需要繞開某條路徑,也不一定需要從某個關卡之間溜過去。它完全可能沿著一條既有的、規範的、每天都在使用的路徑到達現實:沒有插入額外步驟,沒有繞開既有流程,也沒有換上一條未經允許的通路。事後重新展開整條鏈,每一步甚至都能在原有流程中找到自己的位置。

如果這時仍然堅持「走錯路」與「沒攔住」是同一個問題,就會出現一個危險的結果:路徑檢查給出「沒有偏離」,控制判斷也隨之被解釋成「沒有問題」——而現實結果已經發生了。

這種合併還會進一步影響事故之後的修復方向。只要問題被理解成路徑出了錯,後續改造就很容易繼續落在路徑上:增加一次校驗,多加一道確認,把鏈路收短,把入口收窄。這些措施本身未必有錯;問題在於,如果偏差根本不成立在路徑這一維,它們就沒有觸及真正需要解釋的東西。更麻煩的是,改造之後,路徑看上去確實會更規整,於是這種錯位很容易被誤認為已經得到修復。

所以真正需要分開的,是兩個更窄的問題:

「這一次請求走錯了路」與「約束本身失效了」,究竟是不是同一種失敗?

先把兩個問題分開

Path 的核心問題只有一句:某次請求如何實際行進。

它關心的是這一次實際發生的步驟、順序、主體、入口與鏈路,以及這些東西與規範路徑之間是否出現了偏離。插入一步、漏掉一步、換掉一步、改變順序、重放一次已經發生過的調用、走上另一條通路、繞過其中一段,或者把幾個各自合法的調用接成一條從未被整體授權過的鏈——這些都屬於它要檢查的東西。

它不問這個動作該不該發生,不問參數本身是否正確,也不問最後的結果落到了哪裡。它只問一件事:這一次實際是怎麼走的。

理解 Path,最直接的辦法是看它的反面,也就是路徑正常意味著什麼。

一條運維命令走的是既有操作手冊和日常使用的工具;一筆付款經過的是原本就在使用的系統和電匯通路;一段行駛軌跡由規劃器生成,再由執行器按照規劃執行。在這些情況下,沒有插步,沒有跳步,沒有替代通路,也沒有繞過其中某一段。事後把整條鏈重新展開,每一步都能在規範路徑中找到對應的位置。

這時候,Path 完全可能給出一個乾淨的答案:沒有發現路徑偏離。

這個答案必須被允許存在。因為如果一個分析對象只有在“查出問題”時才成立,那麼它就不再是一個判斷工具,而只是壞結果的另一種說法。路徑這一維查不出偏離,只說明實際行進與規範路徑之間沒有發現差異;它不能進一步替其他問題作答。

Boundary 問的是另一件事:哪些動作、路徑和能力受何種約束,誰能最終拒絕。

它的進入條件不是“請求經過了哪裡”,而是約束本身處在什麼狀態:缺失、不完整、無效,或者規則與實施主體本身被改寫。

缺失,是限定作用範圍的約束根本不存在——一個動作能影響多大的量、多少對象、哪些資源,沒有相應的限制。

不完整,是約束覆蓋了一部分情形,而這一次恰好落在沒有被覆蓋的部分。

無效,是約束存在,也覆蓋到了這次動作,卻沒有真正發揮作用。例如,一個本應獨立生效的否決沒有生效,或者一條高權限路徑始終沒有被這套約束管住。

被改寫則更強:原先決定約束如何成立的規則,或者實施這些規則的主體本身,已經發生了改變。

這四種狀態回答的是同一個問題:在這個動作到達現實之前,究竟有什麼東西在限定它能夠做到什麼、做到多遠。

這與 Path 所檢查的對象不同。Path 主要看實際行進記錄與規範路徑之間的差異;Boundary 主要看約束本身是否存在、覆蓋到了哪裡、是否有效,以及是否仍然是原來的約束。兩類判斷可能使用部分相同的事故材料,但它們從材料中尋找的東西並不相同。

因此,一次失敗完全可能在 Path 上沒有任何異常,卻在 Boundary 上成立;反過來也一樣。一個問題得到乾淨答案,並不能替另一個問題作答。

至於「誰能最終拒絕」,這裡只把它保留在 Boundary 的核心問題中,本章不繼續展開。這一章對邊界的討論止於它的失效形態,以及這些失效如何使偏差到達現實。關於那個「誰」究竟如何成立、如何獲得最終拒絕能力,本書暫時不在這裡建立結構。

還有一個容易混淆的地方必須提前切開:執行邊界不是訪問控制的另一種寫法。

訪問控制首先關心的是主體擁有什麼權限;執行邊界在這裡關心的則是一個動作的現實作用範圍受到什麼約束。兩者在具體系統中當然可能同時出現,但並不互相蘊含。一個主體可以完全擁有執行某個動作的權限,而這個動作究竟能夠影響多少對象、多少資源、走到什麼範圍,卻沒有受到充分約束。

所以真正要看的,不只是「誰有沒有權做」,而是:

這個動作能夠到多遠,什麼東西在限定它。

到這裡,Path 與 Boundary 已經可以在定義上分開。但僅僅給出兩個定義還不夠,因為定義總有被事後拉寬的可能。真正讓兩個對象不能重新滑到一起的,是它們各自還有另一條邊界:

什麼情況,還不足以讓它進入。

不足以進入的那一欄

每一個判斷對象除了進入條件,還需要另一條邊界:什麼情況不足以讓它進入。

這條邊界看起來只是限制條件,實際上比定義本身更重要。因為定義告訴我們什麼材料可以支持一個判斷,而「不足以進入」決定了什麼東西即使看上去很像,也必須被排除在判斷之外。

Path 的否定邊界是:只是存在長鏈、複雜流程或錯誤結果,不足以進入。

一次失敗可能經過二十層調用,中間穿過八個服務、三個系統邊界,最後得到一個完全錯誤的結果。這些事實全部成立,也仍然不足以說明發生了路徑偏離。

Path 要求看到的是實際行進與規範路徑之間的差異:有沒有插入原本不存在的步驟,有沒有漏掉本應發生的步驟,有沒有改變順序、替換主體、換掉入口、繞過某一段,或者走上另一條通路。

鏈很長,不等於走錯了路;過程很複雜,也不等於偏離了規範路徑。長鏈本身不構成異常。否則,只要系統足夠複雜,Path 就會失去區分能力,最後退化成「流程很多,所以過程有問題」。

Boundary 的否定邊界則不同:只因某次請求經過多個節點,不足以進入。

一條請求經過十個節點,並不自動意味著存在執行邊界失效。節點多,只說明路徑長;它沒有告訴我們任何一個約束是否缺失、不完整、無效,或者已經被改寫。

「經過了那麼多環節,居然沒有一個攔住它」很容易成為事故之後的第一反應,但這仍然不是一次 Boundary 判斷。它只是數出了多少個節點,沒有指出究竟哪一個約束應該存在、是否覆蓋到了這個動作、當時是否有效。

這兩條否定邊界,才真正阻止 Path 與 Boundary 重新滑到一起。

如果沒有它們,Path 很容易被擴張成「過程中出了問題」,Boundary 也很容易被擴張成「最後沒有被攔住」。而任何一次現實失敗都可以同時滿足這兩句寬泛的描述:過程總是存在,失敗既然已經發生,也總可以說某個地方“沒有攔住”。

問題在於,這樣的判斷沒有定位能力。

如果一個對象面對幾乎所有失敗都給出同樣的答案,它就沒有真正區分任何東西。否定邊界的作用,就是在事故敘述形成之前,把那些容易誘導判斷、卻不足以構成判斷的材料先拿掉。

鏈路很長,先拿掉。

節點很多,先拿掉。

系統很複雜,先拿掉。

結果很嚴重,也先拿掉。

剩下的材料,才用來判斷 Path 是否真的發生了偏離,Boundary 是否真的處在缺失、不完整、無效或被改寫的狀態。

剔除這些干擾之後,可能發現 Path 與 Boundary 只有一個成立,也可能兩個都成立,甚至兩個都不成立。這些答案都允許存在。重要的不是一定要找到其中一個,而是不能因為結果已經發生,就反過來強迫某個對象成立。

這就是第四列為什麼不是表格裡的補充說明。

它承擔的是每一個對象自己的邊界。如果拿掉這一列,兩個對象都會迅速向事故敘述裡最寬泛的語言滑去,最後重新合併成一句「流程失控」。而一旦所有失敗最後都可以被叫作「流程失控」,前面建立的區分也就失去了意義。

TAB-I-001|Path 與 Boundary:問的不是同一個問題

對象核心問題進入條件不足以進入的情況
Path某次請求如何實際行進實際步驟、順序、主體、入口或鏈路偏離規範路徑只是存在長鏈、複雜流程或錯誤結果
Boundary哪些動作、路徑和能力受何種約束,誰能最終拒絕約束缺失、不完整、無效,或規則與實施主體被改寫只因某次請求經過多個節點

這張表只有兩行,因為這裡討論的是兩個判斷對象,而不是兩個階段、兩個類別或者兩個控制點。

它也不是上一章五類失敗的重新分類,更不是一張窮盡表。它只做一件事:面對一次具體失敗,分別判斷 Path 是否成立、Boundary 是否成立。

兩個判斷使用不同的進入條件,也各自擁有自己的否定邊界。因此答案可以是 Path 成立而 Boundary 不成立,可以是 Boundary 成立而 Path 不成立,也可以兩者同時成立。至於兩者是否互斥,或者它們加在一起能不能覆蓋全部失敗,本章都不作判斷。

真正執行這兩個判斷時,需要看的材料也不同。

判斷 Path,要重建這一次實際發生的步驟、順序、主體、入口與鏈路,再與規範路徑逐一比較。如果找不到差異,就應當允許 Path 給出「不成立」的答案。分析不能因為事故已經發生,就強迫這一維必須查出異常。

判斷 Boundary,則要繼續追問另一類問題:在這個動作到達現實之前,有什麼東西限定著它的作用範圍?這些約束是否存在,覆蓋到了哪裡,當時是否真正有效?

有些材料甚至不會直接出現在執行記錄中。一個從未存在過的約束,不可能在日誌裡留下「我不存在」的痕跡。因此,「什麼都沒查到」不能自動被理解成控制正常;它只是意味著,接下來需要換一個對象繼續檢查。

這兩個判斷同樣不能從結果的嚴重程度倒推。

後果很嚴重,不足以證明 Path 一定發生了偏離;結果最終發生,也不足以證明 Boundary 一定成立。

結果告訴我們有事情需要解釋,但它不能替代解釋本身。

正常路徑可以承載錯誤 Action

前面的區分還停留在判斷條件上。真正把「路徑正常」與「控制正常」拆開的,是幾次已經完成事實核驗的現實失敗。

2017 年 2 月 28 日,Amazon S3 在北弗吉尼亞區域發生中斷。當天,S3 團隊正在處理計費系統速度下降的問題。一名獲得授權的團隊成員按照既有 playbook,使用正常的生產工具執行了一條命令,原本只准備移除少量服務器。由於命令中的一項輸入填寫錯誤,實際執行的動作遠遠超出了原本預期的範圍,隨後引發了 S3 服務中斷。

在 Path 這一維上,這一案的判級是 Weak / Unsupported。

這裡沒有替代路徑,沒有跳步,也沒有旁路。執行者沒有繞開既有工具,也不是一個未經授權的人闖入系統。命令沿著已有 playbook 和正常生產工具進入現實,從路徑本身看,它走的就是系統原本允許它走的那條路。

問題恰恰在這裡。

路徑正常,並沒有阻止錯誤 Action 被執行。

這一案在本章只承擔這個作用。它不證明 Boundary 必然失效,也不證明這次失敗只能屬於某一類,更不能從一個案例推出關於複雜系統的一般規律。我們在這裡關心的只是一個更窄的事實:實際行進沒有偏離規範路徑,而偏差仍然到達了現實。

2020 年 8 月,Citibank 在處理一筆貸款相關付款時發生了另一種形態的失敗。上一章已經討論過它在綁定關係上的問題;放到 Path 這一維,看到的是另一件事。

這筆付款經過的是正常的 Flexcube 流程和正常的銀行電匯通路。兩級人工複核確實發生過,操作也發生在系統原本提供的界面之內。但三個界面選項只被選中了其中一個,隨後系統按照已經錄入的字段,把接近十億美元的銀行自有資金實際匯了出去。

這裡最重要的一點不是「複核有沒有發生」,而是:

兩級複核存在,不等於金額與賬戶之間的綁定就是正確的。

而這句話本身並不涉及路徑偏離。

在 Path 這一維上,這一案同樣是 Weak / Unsupported。沒有證據表明有人繞開正常流程,也沒有一條未經授權的旁路。恰恰相反,每一個可見動作都發生在原本設計好的流程中。

所以,這一案不能被簡單敘述成「有人繞過了控制」。它也不證明覆核制度本身無效,更不能因為法院後來處理了返還問題,就把法律結論直接改寫成本書的理論結論。本章只取其中一個很窄的位置:路徑沒有發生可識別的偏離,但錯誤結果仍然發生。

第三個案例來自物理世界。

2024 年 5 月 21 日,一輛 Waymo 無人車在 Phoenix 的巷道中執行低速靠邊動作時,撞上了一根木製電線杆。車內沒有乘客,沒有其他道路使用者捲入,也沒有人員受傷;車輛本身受到損壞,之後通過軟件與地圖更新進行處置,並提交了正式召回申報。

在 Path 這一維上,這一案也是 Weak / Unsupported。

它尤其容易被誤判,因為車輛最終確實「走到了一條錯誤的位置」。但這裡必須區分兩件事:

計劃出來的路徑本身是錯的,和車輛實際執行時偏離了計劃路徑,不是同一個問題。

這輛車執行的正是規劃器已經生成的那條靠邊路徑。實際行進與計劃之間沒有發現差異。問題出在路徑的內容:被規劃出來的軌跡裡包含了一個真實存在的永久障礙物。

如果連這種情況也被算成 Path Deviation,那麼 Path 很快就會失去選擇性。任何導致壞結果的行動,事後都可以被重新描述成「走了一條錯誤的路」。這樣一來,「實際有沒有偏離規範路徑」這個問題就消失了,只剩下「結果好不好」。

這一案在本章也只承擔這個作用。它不能被拿來推出關於傳播、放大或事故規模的其他結論。

把三個案例放在一起,有意義的地方不只是它們都沒有給 Path 提供 Strong 支持,更在於它們展示了三種完全不同的「路徑正常」。

AWS 是運維路徑:獲得授權的人,使用既有工具,沿著已有 playbook 執行動作。

Citibank 是複核流程:交易經過設計好的系統和人工節點,流程本身並沒有被繞開。

Waymo 是物理執行:規劃器生成路徑,執行器按照已經生成的路徑行動,實際執行沒有脫離計劃。

三種系統的行業、時間尺度和執行主體都不相同,但它們共同暴露出同一個結構:

實際行進與規範路徑之間沒有發現偏離,並不意味著錯誤 Action 無法到達現實。

這也是為什麼 Path 不能被擴張成「凡是結果錯了,路徑就一定有問題」。

在本章的分析框架裡,可以明確得到一個更窄、也更重要的結論:

Path 不是 Execution Gap 的必要條件。正常路徑可以承載錯誤 Action。

這裡還必須守住結論的另一側。

這三個案例承擔的是壓力,不是理論證明。它們用來打破「路徑沒有問題,就說明控制沒有問題」這個直覺,但不能從三個案例推出任何普遍規律。

同樣地,從「Path 不是必要條件」也不能反推出「Boundary 就是必要條件」。三個案例也不能因此被唯一歸入某一個失敗類型。本章只取它們在 Path 這一維上的判斷;換一個問題,同一個案例還可能呈現出完全不同的結構。

這本身就是這三個案例在這裡最重要的作用:

同一個現實失敗,可以在不同的判斷對象下呈現出不同的東西。

數字說明的是適用範圍

在那 17 個已經完成權威事實核驗的案例中,Path 的分佈是 2 例 Strong、10 例 Partial、5 例 None;Boundary 在同一批案例上是 11 例 Strong、6 例 Partial。

這兩組數字的作用並不相同。

Path 的分佈說明,它必須被嚴格使用。一個對象在多數案例上只達到 Partial,還有五例完全不成立,說明它的進入條件本來就窄。如果只要過程複雜、鏈路很長或者結果出了問題就算作 Path,它很快就會退化成「過程裡有問題」的另一種說法。

所以,Path 的 Strong 數量少,不意味著它不重要,更不意味著它可以被取消或者併入 Boundary。一個嚴格適用的對象出現得少,是嚴格的結果,不是多餘的證據。

Boundary 的分佈則說明,它具有不能被 Path 或 Relation 完全吸收的獨立解釋位置。

但這兩組數字不能拿來比較誰更重要。Strong、Partial、None 是按不同維度作出的分析性判級,不是重要性排序,也不是嚴重程度。Boundary 的 Strong 更多,也不能推出 Boundary 就是 Execution Gap 的必要條件。

它們同樣不能用來給案例指定唯一歸屬。一個案例可以同時在多個維度上成立,Path 與 Boundary 也不是把上一章五類失敗重新切成兩半的分類表。

這組數字真正說明的只有一件事:

Path 與 Boundary 在同一批現實案例上的適用範圍明顯不同。

這已經足夠說明,它們不能被當成同一個判斷對象。

邊界失效,不等於邊界被改寫

關於 Boundary,還有一個容易被混淆的地方必須單獨留下。

Boundary Mutation 指的是:原先決定路徑、能力集或最終否決權的規則與實施主體本身被改寫。它是執行邊界失效的一種強 subtype,但不是所有邊界失效的同義詞。多數 Boundary Strong 的案例,也並不構成 Mutation。

這個區別很重要,因為「被改寫」太容易成為一個完整的事故故事:有人改了規則,換掉了實施規則的主體,於是原本能夠限制動作的東西失效了。這樣的失敗有明確的變化、有可以追查的痕跡,也很容易被理解成邊界失效的典型形態。

但邊界失效並不需要先發生一次改寫。

約束可能從一開始就沒有覆蓋這個動作;也可能只覆蓋了一部分,而偏差恰好落在遺漏的部分;還可能約束確實存在,卻在這一次沒有真正生效。這些情況裡,沒有人改過規則,也不需要存在一個越權主體。

如果把 Boundary Mutation 當成整類問題的代表,調查就會自然地去尋找「什麼被改了」。一旦什麼都沒找到,又很容易反過來認為邊界沒有問題。真正需要檢查的那個位置——動作的作用範圍到底受到什麼約束——反而可能被跳過去。

所以兩句話必須同時成立:

Boundary Mutation 是一種強 subtype。

Boundary Mutation 不是 Boundary Failure 的同義詞。

前一句保留它的解釋位置,後一句限制它的適用範圍。少掉任何一句,都會把這一類失敗讀窄。

兩個判斷,不能互相代替

這一章最後交出的,不是兩個定義,而是兩次獨立的判斷動作。

面對一次具體失敗,可以分別問兩件事:這一次實際是怎麼走的;以及哪些動作、路徑和能力受著什麼約束。

前一個問題看實際發生的步驟、順序、主體、入口與鏈路,並與規範路徑比較。後一個問題看約束本身是否存在、覆蓋到了哪裡、是否有效,以及規則與實施主體有沒有被改寫。

兩個判斷各有自己的進入條件,也各有自己的否定邊界。因此,它們都必須允許給出「不成立」的答案。

路徑上查得乾乾淨淨,不構成關於 Boundary 的任何結論;反過來,Boundary 上發現問題,也不意味著一定有人走錯了路。一個判斷完成,不能替另一個判斷作答。

這也是本章最重要的區別:

邊界可以失效,而路徑正常。

一次偏差完全可能沿著規範路徑到達現實。沿途每一步都對得上,執行記錄裡也找不到路徑偏離,但這並沒有回答另一個問題:在它到達現實之前,究竟有什麼東西限制著它能夠做到什麼、做到多遠。

同樣,一次失敗也可能同時進入 Path 和 Boundary。兩個對象可以重疊,卻不能因此被合併。它們之所以需要分別保留,正是因為成立一個,不足以推出另一個成立,也不足以推出另一個不成立。

到這裡,「走錯了路」與「攔不住」已經不能再被當成同一種失敗。

但把它們拆開以後,下一個問題也隨之出現。

上一章給出了五個位置,而前面的幾個現實案例並不只落在其中一個位置。如果這些對象不能互相吸收,那麼:

如果這兩類不能互相吸收,那麼這五類之間是否互斥?給定一次具體失敗,我該如何定位它?

這一章不回答。

本章術語

  • 執行路徑的偏離 | Execution Path Deviation
  • 執行邊界的失效 | Execution Boundary Failure
  • 邊界改寫 | Boundary Mutation
  • 強支持 | Strong
  • 部分支持 | Partial
  • 不成立 | None

本章案例與資料來源

三個正式核驗案例

本章繼續使用《執行縫隙》研究階段建立的十七個正式核驗案例池,並重點使用其中三個案例:

AWS S3、Citibank–Revlon,以及 Waymo。

三個案例在本章中的作用相同:用於檢驗執行路徑的偏離是否是 Execution Gap 的必要條件。它們分別對應運維路徑、複核流程與物理執行三種不同形態,但在執行路徑這一維上的判級均為 Weak / Unsupported。

這些案例不用於證明某一種機制必然成立,也不用於給案例指定唯一歸屬。它們在本章承擔的是壓力測試作用:說明一次現實失敗可以沿正常路徑發生,實際行進與規範路徑之間沒有發現偏離,並不意味著錯誤 Action 無法到達現實。

本章由此建立的限定結論是:

Path 不是 Execution Gap 的必要條件。正常路徑可以承載錯誤 Action。

十七個正式核驗案例池

除三個重點案例外,本章同時使用十七個正式核驗案例在 Path 與 Boundary 兩個維度上的聚合分析結果。

在該案例池中:

  • Path:2 例 Strong、10 例 Partial、5 例 None;
  • Boundary:11 例 Strong、6 例 Partial。

這些數字只描述當前案例池在兩個分析維度上的證據分佈。

Path 的分佈用於說明執行路徑的偏離必須保持嚴格適用;Boundary 的分佈用於說明執行邊界的失效具有不能被 Path 或 Relation 完全吸收的獨立解釋位置。

Strong、Partial 與 None 不構成重要性、嚴重程度或優先級排序,也不能據此推出 Path 可以被取消、Boundary 更重要,或兩個維度已經構成對現實失敗的互斥與窮盡分類。

完整案例說明

正文不重複展開三個案例的完整事實鏈、核驗過程與全部資料來源。

AWS S3、Citibank–Revlon 與 Waymo 的完整案例說明,統一收錄於本書附錄 《現實失敗與邊界案例》 中的 「十七個正式核驗案例池」 部分。

本章對三個案例只使用其在執行路徑維度上的核驗結果。

其中,AWS S3 不在本章展開容量設計與恢復過程;Citibank–Revlon 不以司法上的返還結論支撐本書的理論判斷;Waymo 不在本章用於討論傳播、放大、召回覆蓋範圍或事故規模。

資料來源

本章涉及的現實事件事實,均以相應案例已經完成的官方、一手、司法、監管或其他權威材料核驗結果為基礎。

逐案事實來源與完整書目信息不在本章重複列出,統一收錄於附錄 《現實失敗與邊界案例》 及全書 《參考文獻與資料來源》。


第六章|不是分類表,是三個問題

本章阻止五類直接機制被誤讀成一張互斥分類表。十七個已核驗案例中,一個事故可以同時命中多個機制維度,因此不能把每個案例唯一塞進一個格子;非互斥不是分類工作沒做完,而是現實失敗本來就可能由已有機制組合出現,組合本身也不自動產生新的一級機制。判級是分析,歸屬是另一件事,案例數量和 Strong、Partial、None 也不能被拿來做嚴重程度或機制強弱排序。為了避免繼續追求唯一歸屬,本章把分析重新拉回三個問題:什麼變了?哪個關係斷了?斷在哪裡、落在哪一層機制上?這三個問題不是新的框架或層級,只是幫助分析回到事實。放棄唯一歸類,也不等於放棄定位。下一步因此轉向第一個問題:僅僅“有東西變了”,是不是執行縫隙的成因?

設想一張事故復盤表。所有字段裡,最後有一欄叫「根因分類」:一個下拉框,必填,而且只能選一個值。填完這一欄,這次事故就有了歸宿。它可以被登記、統計、分派給某個團隊,最後以一個類別進入彙總報表。

這個要求本身並不荒唐。組織需要把一次性的事件變成可以累積的東西,而累積需要比較,比較又需要某種統一的表達。

作為一種通信約定,分類確實有用。它讓不同團隊可以用同一組詞談論同一批事情。危險出現在另一刻:當「屬於哪一類」被默認為總有答案,而且答案只能有一個。

因為一個只能填一個值的字段,實際上已經預設了兩件事:這些對象彼此可以分開,而且每一次事件都有唯一歸屬。

這就不再只是記錄方式的問題了。它開始變成關於現實本身的判斷。

當表單只允許一種填法,人很容易反過來相信世界本來就是這樣分佈的——不是因為這種結構已經被證明,而是因為記錄工具從來沒有留下別的選擇。

上一章結束在兩個對象拒絕合併的地方。「這一次請求走錯了路」與「約束本身失效了」問的不是同一件事,也不能互相代替;一條完全正常的路徑,仍然可以把一個錯誤 Action 送進現實。

而在第四章裡,我們已經留下了五個可以用來定位失敗的位置:決定與綁定關係的失效、執行路徑的偏離、執行邊界的失效、執行狀態與結果關係的失效,以及因果鏈內證據與證明關係的失效。

拿到這樣一組對象之後,下一個動作幾乎順理成章:把它們排成一列,遇到一次事故,就挑一個格子放進去——「這是路徑問題」,或者「這是邊界問題」。

這一步很誘人,因為歸類不只提供一個解釋,它還方便記錄、彙總和分派。問題在於,後面這些組織上的便利,並不能證明前面的解釋就是對的。

而這一步恰恰做不成。

不是因為五類分得還不夠細,也不是因為研究停在了半路,而是因為現實中的偏差本來就不按唯一歸屬的方式分佈。

第四章在結束時留下了兩條線:一條問路徑與邊界是不是同一種失敗,上一章已經回答;另一條問五類之間是否互斥,以及面對一次具體偏差時究竟該如何定位。

現在,兩條線在這裡合上。

十七個案例,裝不下五十八次歸屬

《執行縫隙》的第一、二批案例池中,有十七個案例完成了正式事實核驗。它們的事實基礎來自官方調查、監管申報、司法記錄,或基於一手記錄完成的獨立調查。這裡所謂「完成核驗」,指的是正文使用的關鍵事實能夠追回到相應的一手材料,而不是直接取自二手敘述。研究階段隨後對這十七個案例逐一進行了強度判定:Strong、Partial 或 None。

有些讀法很難只靠另一段說理推翻,「五類就是五個桶」就是其中之一。它完全可以承認前面的論證,然後繼續把一次事故塞進一個格子。真正能把這種讀法頂回去的,是計數;不是因為數字天然更權威,而是因為這一次,矛盾直接落在算術上。

表 I-002|17 個已核驗案例的聯合強度分佈(樣本 = 17 個 Qualified 案例)

維度StrongPartialNone
五類直接機制族
決定與綁定關係 Decision / Binding Relation1700
路徑 Path2105
邊界 Boundary1160
狀態與結果 State / Result1700
證據 Evidence1340
橫切 Modifier(不是一級機制)
放大 Amplification1241
分析維度(不是機制)
變化 Change1700

另有三個邊界案例不參與這份計數。它們有各自的用途,但其強度不進入上表。這裡必須保持同一個樣本口徑,因為下面真正要看的不是某一行自己的數字,而是行與行之間的算術關係。把口徑不同的案例混進來,或者拿這張表與另一批樣本直接比較,這個關係就失去了可比基礎。

這張表真正承重的讀法只有一條:樣本總數是十七,而決定與綁定關係有十七個 Strong,狀態與結果關係也有十七個 Strong。假如五類真是互斥的桶,一個案例只能進入其中一個,那麼單是這兩行就已經需要三十四個案例;再加上邊界的十一個 Strong 和證據的十三個 Strong,總數就變成了五十八。

十七個案例,裝不下五十八次歸屬。

這已經足以否定「五類是五個互斥分類桶」的讀法。同一個案例可以同時在多個機制位置上成立,這並不是重複計數:每一個 Strong 都是在對應維度上獨立作出的判定。兩行同時為 Strong,表示兩個不同的問題在同一次偏差上都成立,而不是同一件事被數了兩遍。

所以,第五章留下的那個問題到這裡已經有了一半答案:五類不互斥,也不是一張可以把每個案例唯一放進一個格子的分類表。 但不互斥並不意味著它們無法區分。上一章已經證明,Path 與 Boundary 不能互相吸收;這一章證明的則是另一件事——同一次事故可以讓多個彼此不同的問題同時成立。

可區分的是問題,不可唯一分配的是事故。

數字到這裡就該停下

十七個案例裝不下五十八次歸屬,這個算術足以否定「五類是五個互斥分類桶」的讀法。但數字能做的事,到這裡也差不多結束了。

Strong、Partial、None 表示的是某個分析位置在具體案例上的成立強度,不表示事故有多嚴重,也不表示哪一種機制更重要、更值得優先處理。某一行 Strong 多,只說明它在這十七個案例中更廣泛地成立;某一行 Strong 少,也不能因此把它降到次要位置。決定與綁定關係、狀態與結果關係在十七個案例中都是 17 個 Strong,這個事實同樣只能描述當前案例池。十七個案例並不是從某個總體中隨機抽取的樣本,因此不能據此推導現實世界裡哪一種失敗出現得更頻繁,也不能把這裡的分佈與另一批不同口徑的數據直接比較。

Path 那一行尤其容易被誤讀:2 個 Strong、10 個 Partial、5 個 None,是七行裡 Strong 最少的一行。但第五章已經回答過為什麼 Path 仍然必須獨立存在。它問的是「這一次請求實際如何行進」,Boundary 問的是「哪些動作、路徑和能力受到什麼約束」。兩者是否需要分別保留,取決於它們是不是在問不同的問題,而不是哪一行數字更大。出現得少,並不意味著這個問題可以被另一個問題吸收。

表裡的 Amplification 與 Change 也不能因為和前五行並排出現,就被讀成第六類和第七類機制。Amplification 是橫切的 Modifier,它可以改變偏差到達現實後的速度與規模,卻不是一條獨立的直接機制;Change 則是一個分析維度,它負責提出問題,也不是五類機制之外的另一個機制對象。因此這張表必須保持現在的三組結構:如果版式把七行處理成完全相同的層級,視覺上就會重新制造出「七類」的錯覺。

數字還有另一條邊界。它不證明五類已經窮盡所有可能的執行縫隙,也不證明這份清單永遠不會改變。五類目前處於條件凍結狀態:在當前研究版本中不再隨手增刪;只有既定的重開條件滿足,或者研究主題被明確重新開啟時,才重新檢查這份清單。

所以,這裡的計數只能否定一種讀法:五類不是五個互斥的桶。 它不能反過來證明,五類已經是一套完備而永久的分類體系,更不能要求現實案例獲得唯一歸屬。

十七個案例中,其中一個在表中七個分析位置上都被判為 Strong:2012 年 8 月 1 日的 Knight Capital 事件。如果手裡拿著的是一張只能填寫一個值的分類表,這個案例會立刻製造麻煩。問題不在於分析還不夠細,而在於同一個案例本來就可以讓多個不同問題同時成立。

這裡引用 Knight Capital,並不是為了替它完成一次「正確歸類」,而是給前面的算術增加一層現實壓力:一個案例可以同時在多個分析位置上成立,而這些判定仍然彼此有意義。案例池在這裡承擔的是壓力,而不是理論證明;它既不證明五類已經完備,也不證明三個提問必然有效,更不替任何案例決定它究竟「屬於哪幾類」。

判級是分析,歸屬是另一件事。

非互斥,不是分類還沒做完

看到五類可以同時成立,一個很自然的反應是:是不是現在還分得不夠細?如果繼續切下去,總能把這些重疊拆開,最終得到一組彼此互斥的類別。

研究過程中確實認真考慮過幾個看起來足夠特殊、似乎值得單獨立類的形態。但最後沒有這樣做,因為它們暴露出的並不是分類還不夠細,而是另一件事:複雜形態可以由已有機制組合出來。

第一個例子,是證據反過來影響後續權限。某一輪留下的 Evidence 成為下一輪判斷的依據,而那份記錄本身已經帶著上一輪的偏差,於是證據、決定與綁定、邊界以及後續 Action 跨越多個回合首尾相接。它看起來像一種新的失敗形態,但拆開以後,每一個部件都已經存在;新的只是這些機制跨越了多個回合,被連接在了一起。

第二個例子,是跨組織的資格繼承。一個組織接受另一個組織給出的資格,而這份資格進入本域以後,沒有重新核驗其成立條件。這裡同時出現資格關係、Boundary 與 Amplification,並且跨越了組織邊界。因為問題發生在兩個系統之間,這種形態很容易顯得陌生,但跨組織本身不會自動產生一種新的直接機制。變化的是已有機制的連接方式和作用範圍,而不是偏差得以抵達現實的基本方式。

這兩個例子指向同一個結論:

組合不構成新的一級機制。

現實中的複雜失敗完全可能同時涉及多個既有對象。如果每看到一種新的組合,就註冊一個新的一級類別,清單會越來越長,卻不會因此獲得更多解釋力。更重要的是,這樣做會重新制造一個前面已經否定掉的承諾:只要類別分得足夠細,最終總能找到一個唯一的格子。

問題並不在于格子還不夠多,而在於同一次失敗原本就可以讓多個不同機制同時成立。

還有一種候選形態需要反方向處理:一個在規範上無效的決定,被下游完整而正確地執行成了現實。這一次的問題不是幾個既有機制發生了組合,甚至未必還處在同一個問題空間裡。如果上游決定本身在規範上就不成立,首先需要回答的已經不是“它屬於哪一種機制”,而是這種情況究竟是否進入了 Execution Gap 的本體範圍。

把這種情況註冊成新的機制族,會把兩個問題混在一起:一個是什麼屬於執行縫隙內部的失敗結構,另一個是什麼根本不算執行縫隙。後一個問題本書後面會單獨處理,這裡只需要把邊界標出來,不繼續展開。

因此,五類之間存在重疊,並不是因為分類工作還沒有完成。它說明的恰恰是另一件事:

非互斥本身,就是這些機制在現實失敗中可以組合出現的結果。

三個問題

既然不能靠唯一歸類來定位一次偏差,接下來真正需要的就不是再造一張更細的分類表,而是換一種問法。

不挑格子,問三個問題。

什麼變了?

先把發生變化的對象找出來。它可能是 Intent,某個詞或字段的含義,被操作的對象,參數,狀態,Policy,路徑,邊界規則,結果,或者 Evidence。這個問題只負責識別變化,不負責判斷變化是否被授權,也不提前回答它是不是導致了最終偏差。它做的事情很有限:先把發生變化的東西從沒有變化的東西里分出來,讓後面的分析有一個可以檢查的落點。

事故敘述很容易在這裡變得含糊。現場看起來處處不對,但究竟是什麼和之前不同,卻沒有被明確說出來。如果連變化發生在哪裡都沒有指出,後面關於關係和機制的判斷就只能懸在空中。三個問題之間因此存在分析上的先後,但這種先後並不意味著三個階段;不是第一問“完成”以後才能進入第二問,而是前一個問題為後一個問題提供更清楚的事實對象。

哪個關係斷了?

找到變化以後,下一步檢查的是哪一條必要關係沒有成立。它可能發生在 Intent 與 Approval 之間,Approval 與 Payload 之間,Flow 與 Path 之間,Execution 與 Result 之間,也可能發生在現實與 Evidence 之間。這裡關心的不是哪個部件單獨“壞了”,而是哪兩樣東西之間本來應該保持的對應沒有保持住。

這一區別很重要,因為關係斷裂並不要求兩端至少有一端明顯失效。兩端各自都可能正常,但它們之間的關係仍然已經斷開。上一章已經說明,一條完全正常的 Path,依然可以承載一個錯誤 Action;因此,同樣是「請求最終被放過去了」,背後可能是不同的問題:一次是實際行進偏離了規範路徑,另一次則是本應限制這個 Action 的 Boundary 沒有成立。

斷在哪裡,斷在哪一層機制上?

最後才去確認,這次失敗落在判斷與綁定、Path、Boundary、狀態與結果、Evidence 與 Proof 中的哪一個機制位置,或者它根本沒有形成新的直接機制,只是在放大已經存在的偏差。這個問題不是為了給事故貼上唯一標籤,而是為了說明偏差究竟通過什麼位置進入了現實。

Amplification 在這裡尤其需要單獨區分。它不是一層直接機制,而是橫切在既有機制之上的 Modifier。它可以解釋為什麼一個已經存在的偏差傳播得更快、影響得更大,卻不能替代另一個問題:這個偏差為什麼能夠抵達現實。如果把 Amplification 當成失敗本身的落點,就會把“為什麼後果這麼大”與“為什麼偏差能夠發生”混成同一個問題。

到這裡,第四章留下的五類直接機制也就有了更清楚的位置。它們不是五個用來給事故分配歸屬的類別,而是回答後兩個問題時可以指向的對象:究竟是哪一條關係沒有成立,以及這種斷裂最終落在了哪個機制位置。

所以,第四章留下的是五個對象,不是五個分類標籤。

對象用來指認發生了什麼;標籤才用來決定一個東西屬於哪裡。

別把三個問題重新做成結構

三個問題之所以保持提問的形態,並不是因為還沒有來得及把它們整理成一套框架。恰恰相反,它們沒有編號,不構成一個體系,也不是新的機制,這是有意保留下來的限制。

把它們畫成三根座標軸、三層結構、三步流程或者一棵判定樹,看起來會更整齊,但每一種表示方式都會悄悄帶入額外的假設。座標軸暗示一次偏差最終可以獲得一組確定座標,分層結構暗示失敗總能落入某一個固定位置,三步流程則容易讓提問之間的分析順序被理解成現實中的執行階段。前面剛剛否定的,正是這種把複雜失敗重新壓回唯一位置的衝動。

三個問題的作用不是替事故分配位置,而是迫使分析回到可以核對的事實上:究竟發生了什麼變化,哪一條必要關係沒有成立,偏差又通過什麼機制位置抵達了現實。它們要求得到的是一組能夠被重新檢查的陳述,而不是一個可以直接寫進報表的標籤。

也正因為如此,三問不適合被壓縮成脫離上下文流通的工具卡片、流程圖或者打鉤模板。工具本身沒有問題,問題在於一旦形式開始替代分析,三個開放的問題就可能重新變成三個需要填寫的格子,最後只是用一種新的界面恢復了原來的分類習慣。

類別可以要求一個值,問題則要求事實。

三問不是一個新的結構,它們只是把分析重新送回事實。

不唯一歸類,不等於不用定位

三個問題本身不會替分析者作出判定。因此,放棄唯一歸類,並不意味著可以放棄定位。每一個案例仍然需要至少指出一條直接機制,用來解釋偏差究竟為什麼沒有停在前面,而是最終抵達了現實。

如果一次分析最後只能說「什麼都變了」「哪個關係都有問題」「每一層都有責任」,它實際上仍然沒有完成定位。這些判斷單獨看都可能成立,但把所有可能性同時留下,並不會自動形成解釋。非互斥只意味著一次偏差可以同時在多個機制位置上成立,並不意味著分析可以因此拒絕指出任何一個具體位置。

放棄唯一歸類,不等於放棄定位。

真正需要的是另一種約束:一次定位可以給出多條同時成立的解釋,卻至少要指出一條直接機制,並說明這條機制如何讓偏差進入現實。這個要求不會重新制造新的類別,也不會把五類重新變成一張分類表;它只是要求分析不能停留在「現場很複雜」或者「很多地方都有問題」這樣的描述上。

同樣,三個問題也不能被使用成新的檢查清單。把三項全部填寫完,並不意味著定位已經完成;真正需要留下的是能夠被別人重新核對的事實——發生了什麼變化,哪一條必要關係沒有成立,以及偏差最終通過什麼機制位置抵達現實。如果只是把三個問題改成三個需要打鉤的字段,那不過是把原來的一個下拉框換成了三個格子。

因此,這一章最終交出的並不是一套新的分類結構,而是一種分析方式:不先問事故「屬於哪一類」,而是持續追問發生了什麼變化、哪一條關係斷開,以及這種斷裂如何進入具體的機制位置。答案可以不止一個,但每一個答案都必須能夠回到事實。

到這裡,還有一個問題需要單獨留下來。

在前面的十七個案例中,Change 一行是 17 個 Strong,也就是說,在這批案例裡,每一個案例都能夠識別出某種變化。這個結果說明 Change 作為分析維度具有很高的覆蓋價值,卻不能因此進一步推出「變化就是偏差的成因」。覆蓋得廣,只說明這個問題值得問,並不說明它的答案已經解釋了因果。

第六章因此停在這裡,把下一個問題交給後面:

「有東西變了」是不是執行縫隙的成因?

本章術語

  • 直接機制族 | Direct Mechanism Family
  • 決定與綁定關係 | Decision / Binding Relation
  • 執行路徑 | Path
  • 執行邊界 | Boundary
  • 狀態與結果 | State / Result
  • 證據 | Evidence
  • 放大 | Amplification
  • 變化 | Change
  • 強度判定 | Strong / Partial / None

本章案例與資料來源

十七個正式核驗案例池

本章使用《執行縫隙》第一、二批案例池中的十七個正式核驗案例,並對五類直接機制族、Amplification 與 Change 分別進行 Strong、Partial、None 強度判定。聯合強度分佈見表 I-002。

另有三個邊界案例不參與本章計數。本章保持十七個 Qualified 案例的統一樣本口徑,不與其他批次或不同口徑的案例直接合並計算。

案例池在本章承擔的是壓力測試作用:用於檢驗五類直接機制是否能夠被理解為互斥分類,而不用於證明五類已經完備,也不用於為具體事故給出唯一歸屬。

完整案例說明

本章唯一具名案例為 Knight Capital|2012-08-01。

該案例在本章用於說明:同一個現實事件可以同時在多個分析位置上成立,而這些判定仍然彼此具有獨立意義。它不作為「正確分類」的示範,也不用於證明三個問題本身的有效性或五類機制的完備性。

十七個案例的逐案事實、證據與強度判定沿用本書正式核驗案例池,本章不重複展開完整案例敘述。

資料來源

本章案例事實依據包括官方調查、監管申報、司法記錄,以及基於一手記錄完成的獨立調查。

正文所使用的關鍵事實要求能夠追回到相應的一手材料,而不是直接取自二手敘述。


第七章|「有東西變了」不是成因

本章回答“變化是不是執行縫隙的成因”。十七個已核驗案例中都能找到變化,因此 Change 具有很高的分析覆蓋價值;但高覆蓋並不等於因果地位。存在變化卻沒有執行縫隙的情形,尤其當變化之後相關資格、綁定或當前條件已經被重新建立時,變化本身並不構成偏差。執行縫隙真正需要解釋的是:變化之後,原本必須保持的關係為什麼沒有繼續成立。於是 Change 被保留為分析維度,而不是一級根機制:它可以幫助定位、提醒重新檢查當前資格,卻不能替代對關係失效的解釋。這個結論同時留下下一問:如果“有東西變了”不是成因,那麼 AI 讓變化傳播得更快、更大,是否會成為成因?

上一章把五類機制族交到讀者手裡之後,又留下了三個提問:什麼變了;哪一個關係斷了;失敗發生在判斷、路徑、邊界、結果、證明中的哪一個位置,還是隻起了放大作用。三個問題擺在一起,第一個最容易先被拿起來,因為它通常也是最容易找到具體對象的那一個。

麻煩恰好從這裡開始。

一條執行鏈出了問題,回頭檢查時,人們很容易先去尋找前後差異:可能是一個參數被改過,一份配置被替換,一條策略剛剛更新,或者一個狀態已經發生變化。

這種解釋還有一個額外的吸引力。只要某個變化能夠對應到明確的時間點、操作、發佈或修改記錄,“發生了什麼變化”和“這次變化由誰完成”就很容易一起出現。後者當然可以是復盤的一部分,但它回答的是歸屬問題,不是執行縫隙為什麼能夠抵達現實的問題。把歸屬放進解釋的位置,並不會自動補上中間缺失的那段因果。

第一個提問因此有一種特殊的誘惑:它太容易產生結果。前面幾章一直在把注意力從單個組件移向組件之間的關係,而到了這裡,讀者第一次拿到一個可以立刻落在具體對象上的入口。越容易被操作的入口,也越容易被誤認為已經完成了分析。

本章只處理這個誤讀:「有東西變了」是不是執行縫隙的成因。

這裡所說的成因,是能夠解釋偏差為什麼沒有在中途停止、最終抵達現實的原因。

答案是否定的。變化是一個分析維度,是三個提問中的第一個,卻不是根機制。這裡要做的不是在取消這個歸屬以後再補上另一個歸屬,也不是增加新的定位對象,而只是把“變化就是成因”這條捷徑關掉,同時把“什麼變了”這個提問完整地留在原處。

第一個提問為什麼像答案

要看清這條捷徑是怎麼形成的,先得承認它並不愚蠢。「什麼變了」之所以好用,正是因為它通常很容易找到具體對象。執行鏈只要持續運行,參數、狀態、配置、策略和輸入就可能隨著時間發生差異,因此沿著“哪裡發生了變化”去查,常常能夠很快獲得一個可以繼續檢查的落點。

問題在於,一個容易得到答案的問題,很容易被誤認為已經提供瞭解釋。日常經驗裡,我們習慣用“找到了”來結束搜索:鑰匙不在口袋裡,就繼續找;一旦在口袋裡找到,問題似乎就結束了。但「什麼變了」並不是這種問題。它搜索的是執行鏈在兩個時點之間的差異,而差異本身在正常運行中也完全可以存在。找到一個變化,只能說明某個對象值得繼續檢查,並不能說明這個變化就是執行縫隙出現的原因。

因此,這裡需要區分兩種不同的提問。有些問題的作用,是不斷縮小候選範圍,直到剩下一個可以直接回答的問題;另一些問題的作用,只是指出接下來應該往哪裡看。第一個提問屬於後者。它把注意力帶到某個具體對象上——某個參數、某份策略、某個狀態——然後把解釋工作交給後面的追問。

找到一個被改過的參數以後,真正需要繼續問的是:改動之後,動作所依據的授權是否仍然覆蓋它;改動之後,原先成立的必要關係是否仍然成立。這些問題才開始進入第二個和第三個提問所處理的範圍。如果跳過這一步,直接把“發生過變化”寫進結論,就等於把定位入口當成了因果解釋。

十七個裡的十七個

有一份統計,會讓這條捷徑顯得更有說服力。

在當前正式核驗的十七個案例裡,Change 這一維全部為 Strong。十七個裡十七個。這十七次裡,沒有哪一次已經成立的執行縫隙是在「什麼都沒動過」的條件下發生的。

這個數字很容易把人往前推一步:既然變化在每一個已核驗案例裡都出現了,它是不是已經接近一種成因?

問題不在覆蓋率還不夠高。十七個裡的十七個,已經沒有繼續提高的空間。真正需要檢查的是,這個數字是從哪一側取出來的。

這十七個樣本本來就是已經被判定為執行縫隙的案例。因此,這份統計實際回答的是:在這些已經成立的縫隙裡,「什麼變了」這個問題有多少次能夠找到東西。答案是十七次。

它沒有回答另一個同樣重要的問題:在那些沒有出現執行縫隙的正常運行裡,同樣的提問是不是也能夠找到變化。

這就是為什麼,一份只從失敗一側取得的統計,無論覆蓋率多高,都不能單獨把覆蓋率變成因果。十七個案例裡的 17/17 能夠支持的結論很明確:Change 具有很高的分析覆蓋價值。 它說明這個問題適合作為定位入口,卻不能據此推出“變化導致了執行縫隙”。

還有一種更剋制的讀法,也同樣走得太遠:變化未必是直接成因,但也許它是所有執行縫隙出現的必要前提。現有材料仍然不能支持這個判斷。十七個案例就是十七個案例,不能被擴展成關於所有執行縫隙的全稱命題;即使某個特徵在每一個已知失敗裡都出現過,也不因此自動獲得因果地位。

一個特徵可能伴隨失敗出現,也可能只是為定位提供入口,還可能同時存在於沒有失敗的正常運行中。要區分這些可能性,僅靠失敗樣本本身是不夠的。

因此,17/17 並沒有削弱第一個提問的價值。恰恰相反,它說明這個入口覆蓋得很好。真正需要取消的,只是從「幾乎每次都能找到變化」到「變化就是成因」之間那一步未經證明的跳躍。

接下來要看的,正是統計沒有覆蓋的另一側:有變化,但沒有執行縫隙。

變了,但沒有縫隙

要推翻“變化本身就是成因”,不需要找到一個更高的覆蓋率,只需要確認另一件事:有沒有變化真實發生,而執行縫隙沒有出現。

至少有四種這樣的情形。

第一種,是合法修訂意圖。一個已經成立的意圖通過正當途徑被修改,一條報銷額度被正式調高,一項定價規則被正式替換,一個既定目標被有權修改它的主體換成了新的目標。變化當然發生了,而且發生在整條執行鏈的上游;但只要後續動作依據的是新的意圖,必要的對應關係仍然成立,就沒有因為“意圖發生變化”而產生執行縫隙。

真正需要解釋的情況,是意圖已經被修訂以後,仍然有動作繼續依據舊意圖發生。那時問題已經不再是“意圖變了”,而是一個已經失效的意圖仍然在支配後續動作。前者是正常修訂,後者才進入第四章已經建立的決定與綁定關係問題。兩種情形在時間上可以緊挨著,但解釋對象完全不同。

第二種,是正常狀態更新。庫存減少、餘額變動、任務從進行中變成完成、設備從待機進入運行,這些變化本身都屬於狀態記錄正常反映現實變化的方式。狀態字段之所以存在,本來就包括記錄這種前後差異。如果只因為狀態發生改變,就把它視為執行縫隙的成因,那麼正常運行本身也會不斷滿足這個條件,而這樣的條件無法區分正常狀態變化與真正的執行偏差。

狀態這一側確實有自己的失敗形態,但問題仍然不在“狀態變了”本身。例如,一個局部階段的完成被當成現實結果,或者一個未知狀態被解釋成成功,需要檢查的是狀態與結果之間的必要關係是否仍然成立,而不是把狀態變化本身當成原因。

第三種,是按授權調整參數。有權限的主體在被授予的範圍內,把一個參數從一個值改成另一個值。變化真實發生,授權與動作之間的對應也仍然成立。

這種情形尤其容易和第四章第一類失敗混在一起。兩邊都有先前已經成立的授權,也都有後續發生的參數變化,還都能在記錄中看到改動前後的值。真正區分它們的,不是“有沒有改”,而是修改完成以後,動作所依據的那份授權是否仍然覆蓋新的對象、參數或範圍。

因此,僅從「什麼變了」這一側看過去,正常的參數調整與一次綁定失效完全可能具有相似的外觀。第一個提問可以告訴我們哪裡發生了變化,卻不能單獨回答變化以後必要關係是否仍然成立;後一個問題必須繼續交給關係與機制層的分析。

變化之後,資格重新成立

第四種情形更接近執行邊界,因此需要單獨說清楚:當變化已經經過重新判斷,並且當前資格重新成立時,那次變化本身不構成執行縫隙。

這裡描述的是一種已經成立的狀態,不是一套程序。它只說:重新判斷確實發生過,當前資格也確實成立,因此與這次變化相關的必要對應已經重新建立。變化仍然存在,甚至可能發生在決定哪些動作能夠進入現實的規則上,但需要解釋的對象已經不再是「發生了變化」本身。

這句話沒有回答誰負責重新判斷,也沒有規定應該在什麼時點、依據什麼條件或者通過什麼方式完成判斷。這裡同樣不需要補上這些答案。只要開始把「當前資格是否已經重新建立」寫成一組可以逐項檢查的條件,就已經從描述一個成立狀態,走向了一套新的判定結構;而這已經超出本章的範圍。

因此,這裡只保留一條邊界:資格已經重新建立時,變化本身不是執行縫隙。

把前面的四種情形放在一起,結論就足夠明確了。合法修訂意圖、正常狀態更新、按授權調整參數,以及重新判斷後建立當前資格,都可以在變化真實發生的同時不產生執行縫隙。只要這樣的情形存在,“變化本身就是執行縫隙的成因”這一判斷就不能成立。

這裡使用的也不是四個事故案例,而是四種正常運作情形。它們之所以能夠承擔這一論證,恰恰因為變化發生了,而執行縫隙沒有出現;如果其中某一種後來真的出現了偏差,需要解釋的也會是具體哪一組必要關係失效,而不是「它發生過變化」這一事實。

變化和縫隙,看的不是同一層

繼續往下看,會發現「發生了變化」和「出現了執行縫隙」本來就在觀察不同種類的東西。

變化首先是關於一個對象自身的判斷。某個參數、某條策略、某份配置,在兩個時點之間不一樣了;要確認這件事,只需要比較同一個對象的前後狀態。它回答的是:這個東西有沒有變,以及變成了什麼。

執行縫隙則不能只靠觀察某一個對象本身來判斷。它要求檢查已經成立的那一側與實際發生的那一側之間,某一組本來必須保持的對應是否仍然成立。這個關係可能涉及意圖與動作,也可能涉及路徑、邊界、狀態與結果,或者證據與現實。具體落在哪一種關係上,需要回到第四章已經建立的五類機制中繼續判斷。

這也是為什麼「什麼變了」無法獨自承擔成因解釋。它觀察的是對象自身的前後差異,而真正需要解釋的是變化發生以後,那些必要關係是否仍然保持。一個對象可以發生很大的變化,卻因為相關關係被重新建立而沒有形成執行縫隙;另一個對象也可能只發生很小的變化,卻使原本成立的關係失效。

所以,第一個提問的能力邊界到這裡已經很清楚:它能把分析帶到發生變化的對象上,卻不能單獨判斷執行縫隙究竟發生在什麼機制位置。

第四章已經留下了五類直接機制,而 Change 與 Amplification 都不屬於這五類。這裡兌現的是其中關於 Change 的那一半:變化可以幫助定位,但不能替代對關係失效的解釋。

取消歸屬,保留提問

把變化從成因的位置上移走,並不意味著「什麼變了」這個問題也要一起被移走。被取消的是一種機制歸屬,不是這個提問在分析中的位置;如果把兩件事混在一起,這一章就會從一個錯誤的結論滑向另一個錯誤的結論。

第一個提問仍然負責把變化對象找出來:意圖、含義、對象、參數、狀態、策略、路徑、邊界規則、結果、證據,以及其他可能發生變化的對象。這裡的“以及其他”很重要,因為這不是一張完整清單。把它封成一份固定表格,就等於提前宣佈我們已經知道執行鏈裡所有可能發生變化的對象,而當前研究並沒有建立這樣的結論。

同樣,也不應該給這些對象配置正式編號。它們只是「什麼變了」這個問題可能指向的對象,不是一套分類學。一旦把這種開放式提問變成固定清單,清單本身就會開始替分析者縮小視野:沒有被預先寫進去的對象,很容易在檢查時被忽略。

三個問題之間的順序也需要這樣理解。第一個問題放在前面,是因為定位通常要先找到發生變化的對象,再去檢查變化以後哪一組必要關係不再成立,最後確認失敗落在什麼機制位置,或者是否只是起到了放大作用。這個順序是一種查找次序,不是一條因果鏈。Change 在提問上先出現,不意味著它在因果上就是起點。

因此,被否定的是變化的機制地位,而不是它的分析價值。「什麼變了」仍然是定位的入口;真正需要解釋“為什麼這一次偏差能夠抵達現實”的工作,則仍然落在第四章已經建立的五類直接機制上。

這裡還要保留另一條邊界:變化不是成因,不等於變化不重要,更不等於變化不需要被管理。 一個組織如何管理變更、如何設置審批和控制、如何判斷某次變化是否可以繼續執行,是另一層問題。本章只討論 Change 在 Execution Gap 解釋鏈中的位置,不提供這些治理問題的答案,也不建立相關判據。

把“變化就是成因”這條捷徑關掉,並沒有把變化從視野裡拿走。它仍然負責帶我們找到下一步應該檢查的位置,只是不再替後面的關係判斷提前給出答案。

第一次排除

退一步看,把變化當成成因,本質上是把最容易看見的東西,當成了最能解釋的東西。

變化很容易留下痕跡。一個參數有修改前後的值,一份配置有版本差異,一次部署有時間點,狀態更新也通常可以被記錄下來。相比之下,一組原本應該成立的關係是否仍然成立,並不會天然留下同樣清楚的“前後對照”。它需要分析者先知道那組關係本來應該是什麼,再判斷變化之後它是否仍然成立。

這就是為什麼事故說明很容易停在變化這一側。變化容易被記錄,也容易被指認,而關係是否失效需要額外論證。如果診斷只依賴那些天然容易留下痕跡的東西,它就會不斷找到真實存在的變化,卻仍然可能沒有回答真正的問題。錯誤不在於這些變化是假的,而在於它們並不自動承擔“為什麼這次偏差能夠抵達現實”的解釋責任。

本章完成的只是一次排除:把 Change 從根機制的位置上移走,同時保留「什麼變了」作為定位入口。這個入口依然有價值;在當前案例池中,它具有很高的覆蓋率,因此適合被放在分析的前面。只是從這裡開始,分析還必須繼續追問哪一組必要關係失效,以及失敗最終落在什麼機制位置。

這是本書第一次明確把一個看起來足夠像答案的東西,從成因的位置上拿開。代價並不是失去一個工具,而是接受這個工具的真實能力邊界:它負責幫助找到下一步該看哪裡,卻不負責替後面的關係判斷給出答案。

同樣的懷疑現在可以繼續向前推進。三個提問中的第三個,除了區分判斷、路徑、邊界、結果與證明等機制位置之外,也允許我們識別那些只起放大作用的因素。一個系統執行得更快、一次動作可以被複制到更大的規模,這些現象同樣顯眼,也同樣很容易被直接寫進“原因”一欄。

但顯眼仍然不是成因的證明。

如果變化不是成因,那麼「AI 讓它更快更大」是不是成因?

本章術語

  • 成因 | Cause
  • 變化 | Change
  • 分析維度 | Analytical Dimension
  • 根機制 | Root Mechanism
  • 當前資格 | Current Qualification

本章案例與資料來源

本章未使用真實世界案例。

正文中的「合法修訂意圖」「正常狀態更新」「按授權調整參數」以及「變化後重新建立當前資格」均屬於用於檢驗“變化是否構成執行縫隙成因”的假設性工程情形。它們不對應特定公司、產品、事故或公開事件,也不進入本書的正式案例池,因此不需要列出外部案例來源。

這些情形在本章中的作用,是說明 Change 可以真實發生,而 Execution Gap 並不因此必然成立。它們用於區分分析維度與直接機制,不用於證明某一種現實事故類型的發生頻率或普遍性。


第八章|AI 放大了什麼,又沒有創造什麼

本章把“成因”和“放大”分開。AI 與自動化能夠顯著改變偏差傳播的速度、規模、自主鏈路、複雜度與影響範圍,但這些變化回答的是“一個已經成立的問題後來會變成多大”,而不是“執行縫隙為什麼成立”。當前材料沒有發現 AI 或自動化獨有的一級執行縫隙機制;這是有邊界的負面發現,不等於宣稱未來絕不存在。Amplification 也不是 Execution Gap 的必要條件:沒有明顯放大,結構性偏差仍可成立。能力提升同樣不能消除主體可錯性,也不能替代執行鏈中需要獨立保持的關係。因此 AI 不是無關變量,卻應被放在放大層,而不是成因層。接下來需要反向收邊界:哪些錯誤結果根本不算執行縫隙?

「有東西變了」不是成因。這個結論一旦成立,問題很自然會換一個候選者:那麼,是 AI 嗎?

這個追問並不奇怪。AI 與自動化進入執行鏈之後,一個明顯的變化是:動作可以更快地發生,可以連續傳遞,可以觸及更多對象,也可以在更少的人工停頓中一路向前。於是,一個很有吸引力的解釋隨之出現——如果錯誤因此跑得更快、走得更遠、變得更難在中途停下來,那麼製造問題的,會不會就是 AI 與自動化本身?

真正需要檢查的,是這裡面那一步沒有被說明的跳躍。

說「自動化放大了這次偏差」,和說「自動化造成了這次偏差」,並不是同一件事。前一句描述的是偏差發生以後,它以什麼速度、規模和連續性繼續傳播;後一句則把 AI 與自動化放到了成因的位置上。兩句話在日常語言裡很容易連在一起,但在執行縫隙裡,它們必須被拆開。

本章處理的就是這條邊界:AI 與自動化究竟改變了什麼,又沒有創造什麼。

這裡的否定邊界比正面結論更重要,因為它很容易被向兩個相反方向誤讀。一種讀法把 AI 直接寫成執行縫隙的成因,於是前面建立的那些關於意圖、授權、路徑、邊界、狀態和證據的關係,被壓縮成了一個模型問題;另一種讀法則從「AI 不是成因」推出「AI 無關緊要」,好像傳播速度、自動化連續性和糾正機會的變化都不再值得處理。

這兩個結論都不成立。本章要做的,是把 AI 與自動化放回它們實際能夠承擔的位置。

放大改變的是傳播,不是縫隙的形成

本書對這件事的裁決是一條位置判斷:放大(Amplification)是一個橫切修飾項,是一個橫切於各類機制之上的放大層,它不作為一級根機制。

當前被登記在放大之下的,包括速度、規模、級聯、反饋、工具深度、自動化的連續性,以及糾正機會的喪失。

這是一份「當前包括」的清單,不是一個封閉集合。它沒有被凍結為窮盡的枚舉,也沒有被賦予任何度量、權重或先後次序。這裡不會給出一套後果範圍的度量方式,也不會給出風險分級判據,因為一旦這些放大項被放進帶刻度的結構裡,讀者就很容易繼續追問哪一項更強、更嚴重、更應該負責,而這已經不是本章要建立的東西。

這些對象描述的不是同一種變化。速度改變的是偏差從發生到落地之間還剩多少時間;規模改變的是同一個動作實際觸及多少對象;級聯描述的是一次偏差是否繼續被後續系統接收並向前傳播;反饋描述結果是否重新進入下一輪,成為新的輸入;工具深度關係到一個動作能夠進入多深的現實資源層;自動化的連續性改變的是流程中還剩多少天然停頓;糾正機會的喪失則關注,在偏差繼續向前傳播的過程中,還剩多少機會能夠發現並停止它。

它們都可能顯著改變一次偏差後續的發展,但描述的仍然是偏差成立以後,它如何繼續傳播。

所以這裡需要把兩個問題分開:執行縫隙為什麼成立,以及已經成立的偏差後來會變成什麼樣子。

放大處理的是後一個問題。它可以改變傳播速度、影響範圍、傳播深度、反饋方式以及停止機會,但它不定義最初的執行縫隙。

一次偏差之所以構成執行縫隙,需要回到前面已經建立的五類直接機制,檢查執行鏈中某一組必要關係是否失效,並解釋偏差為什麼最終能夠抵達現實。放大不承擔這部分解釋;它處理的是偏差已經成立之後,如何繼續向前傳播。

可以設想同一條執行流程的兩種形態:一種在步驟之間存在人工確認,另一種被連接成連續的自動執行鏈。如果同一個參數已經與成立的意圖脫鉤,那麼兩種流程裡的關係問題是一樣的;不同的是,前一種形態可能留下更多發現和停止它的機會,後一種則可能讓它更連續地向前執行。自動化改變的是偏差抵達現實之前還剩多少阻斷機會,而不是那條必要關係是否已經失效。

因此,降低速度、減少連續執行或者增加人工確認,可以改變偏差傳播的條件,卻不能因此被當成對成因本身的解釋。如果關係已經失效,把流程放慢並不會自動把關係重新接上;它只是改變了這次失效被發現和阻斷的可能位置。

同樣,也不能把 Amplification 直接列為第六類機制。前面的五類直接機制問的是:什麼樣的結構性失敗,使一次偏差能夠抵達現實。 放大回答的是另一個問題:一旦偏差已經成立,它會以什麼條件繼續傳播。把兩者放進同一張機制清單,會把“哪裡斷了”和“斷了以後跑得有多快”混成同一層。

變化不在那五類裡,放大也不在。前者是分析維度,後者是橫切修飾項,而那五類處理的是直接機制。

這也正是三維分析方法第三個問題裡保留「只起放大作用」這一位置的原因。被排除在一級機制之外,不等於被判定為無關。寫下「自動化放大了它」以後,分析仍然必須繼續回答:這一次,究竟是哪一組必要關係失效了。

一個沒有明顯放大的現實案例

前面的論證說明了為什麼放大不應該被放進一級機制,但要進一步判斷它是不是執行縫隙的必要條件,還需要另一種證據:有沒有一次已經成立的執行縫隙,在放大這一維上並不明顯。

這樣的案例存在。

Waymo 電線杆碰撞與召回事件(2024-05-21)在本書的案例核驗中被判定為 Qualified,核驗依據是 NHTSA 的 Part 573 召回申報 24E-049。在十七個 Qualified 案例的聯合強度分佈裡,Amplification 一項共有十二個 Strong、四個 Partial、一個 None,而這個 None 就是 Waymo。完整分佈已經在第六章出現,這裡只取與本章有關的這一行。

這個案例的重要性不在於它代表所有情況,而在於它恰好能夠檢驗“必要條件”這個判斷。如果 Amplification 是 Execution Gap 的必要條件,那麼每一個已經成立的案例裡都應該能夠找到它。只要存在一個已經成立為 Execution Gap、同時 Amplification 為 None 的案例,這個全稱判斷就不能繼續成立。

因此,Waymo 能夠支持的結論很明確:Amplification 不是 Execution Gap 的必要條件。

但這一個反例能做的事,也到這裡為止。

它不證明 Amplification 與問題無關。同一個案例池中仍然有十二個案例的 Amplification 為 Strong。一個 None 推翻的是“沒有它就不能成立”,不是“它通常不會出現”或者“它沒有工程意義”。

它也不證明 AI 與自動化可以被忽視。一個因素不是必要條件,不等於這個因素在現實系統裡不重要;這兩個判斷屬於不同層次。

這個案例同樣不能被拿來推導後果規模。核驗記錄裡有兩條必須保留的備註:它是一個非災難性正例;記錄中的 672 表示受影響設備範圍,不是事故數量。這裡不會據此建立後果範圍的度量方式,也不會建立風險分級判據。

它也不構成對整套理論的證明。一個現實案例可以對某個全稱判斷施加壓力,也可以直接推翻“必要條件”這樣的讀法,但不能因此證明整套結構已經完備。案例在這裡承擔的是反例作用,不是理論證明。

Waymo 在本書其他位置還承擔過不同的分析任務,但那部分與這裡無關。本節只使用它在 Amplification 這一維上的結果,不把其他維度重新帶進來。

這個案例的後果並不嚴重,並不會削弱它在這裡的作用。這裡需要的本來就不是一個後果足夠大的事故,而是一個已經被核驗為 Execution Gap、同時又沒有明顯 Amplification 的現實實例。它提供的正是這樣一個反例,因此足以讓“Amplification 是必要條件”這條全稱判斷失效。

當前材料沒有發現 AI 獨有的一級機制

接下來還有一個更難的問題:AI 與自動化除了放大既有的執行縫隙之外,有沒有創造一種只有它們出現以後才存在的一級機制?

就當前材料而言,答案是否定的。

在現有案例壓力測試中,沒有發現必須新增一級結構才能解釋的 Qualified 案例。研究階段曾經留下三個看上去可能超出現有結構的候選,但進一步拆開之後,它們都可以重新落回已經存在的對象與關係中。

第一個候選,是證據對權限的回饋。表面上看,它似乎形成了一種新的跨輪次機制:前一次執行留下的證據,會改變下一次動作獲得權限的條件。但繼續拆開以後,其中涉及的仍然是證據、判斷與綁定、權限與邊界,以及下一輪動作之間的組合關係,不需要為此增加一個新的一級機制族。

第二個候選,是跨組織的資格繼承。一個主體在一個域裡獲得的資格,被另一個域接受、轉換或者繼續使用,看起來很容易形成一種新的跨域機制。但現有材料仍然可以通過資格關係、邊界以及放大等已經存在的對象來表達它,而不需要新增一級結構。

第三個候選,是一個規範上無效、卻被忠實執行的決定。這個情形同樣沒有形成新的一級機制;現有材料仍然能夠用已經建立的結構解釋它。這裡不進一步判斷這類錯誤相對於執行縫隙外邊界究竟處在什麼位置,本章只保留“它沒有形成新的一級機制”這一結論。

所以,當前材料能夠支持的結論只是這一句:

當前沒有發現 AI 或自動化獨有的一級執行縫隙機制。

這不等於說 AI 與自動化什麼都沒有增加。它們確實增加了執行鏈中的複雜性:變化入口更多,實際路徑更容易發生變化,傳播速度更快,反饋更連續,能夠留給發現和糾正的機會也可能更少。一個能夠自行選擇工具、決定調用順序並改寫中間產物的系統,顯然比固定腳本帶來了更多需要被檢查的對象和路徑。

但這些增加並不自動要求增加新的一級機制。更多的變化入口,仍然落在「什麼變了」這一分析維度上;路徑可變性仍然需要檢查執行路徑;傳播速度、反饋和糾正機會仍然屬於放大面。AI 可以讓已有問題以更多方式出現,卻不因此自動創造一個新的機制位置。

這裡必須把結論和它的證據範圍放在一起讀:

「當前材料沒有發現」不等於「不存在」。

這是一條有界的負面發現,不是一個不可能性證明。它所覆蓋的範圍,是當前十七個 Qualified 案例以及現有語料。在這個範圍內,沒有出現一個必須新增一級機制才能解釋的對象;這個範圍之外,本章不作判斷。

因此,這個結論也不是永久關閉的。只要以後出現一個新的 Qualified 現實案例,而且現有結構無法解釋它,就必須重新打開“是否存在新的一級機制”這個問題。現有材料只能說明當前沒有新增一級結構的證據必要,不能說明這種結構永遠不可能出現。

同樣,這條負面發現不能被拿去降低對 AI 系統的工程要求。「沒有發現新的一級機制」只是在說問題落在哪些機制位置,並不意味著這些機制因此變得容易處理。AI 與自動化可以同時增加變化入口、路徑複雜度和傳播能力,使原本已經存在的關係在更短時間、更長鏈路和更多邊界之間被反覆檢驗。

已知這些機制是什麼,並不等於已經解決了這些機制會如何失效。

能力提高不改變什麼

把 AI 放到成因的位置上,還有一種更深的誘惑:人們很容易把執行縫隙理解成能力不足留下的問題。沿著這種理解繼續往前走,只要模型判斷得更準、推理更強、自檢更完整,問題似乎就應該逐漸消失。

這個判斷把兩件不同的事情放在了一起。

能力提高當然可以改善模型在具體任務上的表現。但本書討論的執行縫隙並不要求主體先判斷錯誤。一個判斷完全可以在自身範圍內成立,後續的意圖、授權、路徑、邊界、狀態或證據關係仍然可能在執行過程中失去原本必須保持的對應。

第一章已經固定過一條更基礎的否定式:主體的合法性、授權、資格或善意成立,不足以建立其判斷正確性。到了這裡,只需要把能力也放進同一條邊界裡。一個能力更強的模型、一條更可靠的流水線,或者一套更完整的自檢機制,都不會僅僅因為“更強”而自動建立整條執行鏈中其他必要關係的正確性。

這就是這裡所說的“能力提高不消除可錯性”。可錯性不是智能不足的另一種說法,而是主體面對不完整現實時的一種結構屬性。能力提高可以改善具體任務上的表現,卻不能把“主體可能與現實不一致”這一可能性從結構上消除。

這句話的範圍必須保持得很窄。它不是說所有主體必然犯錯,也不討論能力提高會怎樣改變某類錯誤的發生頻率,更不是在給 AI 的可靠性作悲觀判斷。它只說明一件事:能力本身不能替代執行鏈中那些需要獨立保持的關係。

也因此,執行縫隙不能被壓縮成“模型幻覺”。

幻覺描述的是一種特定的輸出失真,而執行縫隙關注的是意圖、授權、動作、路徑、邊界、狀態、結果與證據之間的關係是否仍然成立。一個系統可以在沒有幻覺的情況下出現執行縫隙,也不能因為模型輸出本身正確,就跳過對後續執行關係的檢查。

同樣,把所有風險都歸到“模型錯誤”上,也會產生相同的壓縮。這樣做等於默認只要把模型本身變得足夠正確,其餘關係就會跟著正確;但這些關係並不會因為模型能力提高而自動獲得保證。

因此,AI、Agent 與自動化在這裡仍然只能承擔它們已經被允許承擔的位置:它們可以改變執行鏈中的變化入口、路徑複雜度和傳播條件,也可以使既有關係在更高速度和更長鏈路中受到更多壓力,但不能僅憑能力這一維,被提升為執行縫隙的一級成因。

後果範圍仍然是未決問題

放大還有另外一面:當一次偏差已經到達現實以後,它究竟影響了多大的範圍。這裡討論的已經不是執行縫隙為什麼成立,而是執行縫隙成立之後,後果擴展到了哪裡。

本書把這一面稱為災難半徑(Blast Radius)。

這個位置必須保持清楚。災難半徑是放大的結果面,不是執行縫隙的成因。不能因為一次事件影響範圍很大,就反過來認為它因此更符合執行縫隙的定義;執行縫隙是否成立,要由前面那些必要關係是否失效來判斷。只有在縫隙已經成立以後,後果究竟擴展了多遠才成為一個可以繼續討論的問題。

但關於這個結果面,本書目前還有明確的未決項。

災難半徑應該如何度量,以及應該依據什麼建立風險分級,目前都沒有正式判據。與這一問題相關的八項子對象也仍然沒有被正式擁有。本章只把這些未決項保留下來,不為它們補答案,也不替它們指定新的歸屬。

這種剋制是必要的。只要在這裡給出一套後果範圍的刻度,下一步就很容易把不同事件放到同一條尺度上排序;而一旦排序出現,後果更大的事件就可能被誤讀成“更典型的執行縫隙”,放大程度也可能再次被偷偷放回成因的位置。

但兩件事必須分開:一個錯誤為什麼成為執行縫隙,和它成為執行縫隙以後造成了多大的後果,不是同一個問題。

因此,這裡沒有缺失一個應該立刻補上的答案。度量方式和風險分級目前就是未決狀態,本章能夠做的只是把這個邊界明確保留下來,而不是為了讓結構看起來完整,臨時製造一套尚未建立的判據。

不是成因,也不是無關

到這裡,本章的結論需要同時守住三個位置:Amplification 是橫切修飾項,不是一級根機制,也不是無關因素。少掉其中任何一項,前面的論證都會被帶向另一個方向。

如果只記住「AI 不是成因」,很容易繼續滑成「AI 不重要」。但同一個案例池裡,Amplification 仍然廣泛存在,AI 與自動化也確實能夠改變偏差傳播的速度、範圍、連續性以及留給糾正的機會。它們不決定執行縫隙最初為什麼形成,並不意味著它們對執行後的現實後果沒有影響。

反過來,如果因為這些影響足夠顯眼,就把 AI 與自動化重新放回成因的位置,前面建立的機制關係又會被模型能力和自動化程度覆蓋掉。一次偏差為什麼能夠抵達現實,仍然需要回到意圖、綁定、路徑、邊界、狀態、結果與證據之間那些必要關係上尋找解釋;放大描述的是這些關係失效之後,偏差如何繼續傳播。

因此,AI 的位置是放大層,不是成因層。Amplification 是橫切修飾項,不是一級根機制,也不是必要條件;而當前材料沒有發現 AI 或自動化獨有的一級執行縫隙機制。這個結論仍然受它的證據範圍約束:如果以後出現一個新的、無法被現有結構解釋的 Qualified 現實案例,這個問題必須重新打開。

到這裡,本書已經完成了兩次排除。第七章排除了 Change 的成因地位,本章排除了 Amplification 的成因地位。兩次排除都沒有取消它們的分析價值,而只是把它們從一級機制的位置上移開。

但問題還沒有因此結束。到目前為止,我們一直默認討論對象已經屬於 Execution Gap,然後在這個範圍之內判斷什麼是機制、什麼是分析維度、什麼只是放大。還有一個更基礎的問題尚未處理:這個概念本身的外邊界在哪裡。

現實中的錯誤結果,並不會因為「結果錯了」就自動成為執行縫隙。有些失敗可能根本不屬於本書正在討論的對象。接下來需要處理的,正是這一條邊界。

什麼樣的錯誤結果不屬於執行縫隙?

本章不回答這個問題。

本章術語

  • 放大 | Amplification
  • 橫切修飾項 | Cross-Cutting Modifier
  • 一級根機制 | Primary Root Mechanism
  • 必要條件 | Necessary Condition
  • 有界負面發現 | Bounded Negative Finding
  • 可錯性 | Fallibility
  • 災難半徑 | Blast Radius

本章案例與資料來源

本章使用一個真實世界案例。

Waymo 電線杆碰撞與召回|2024-05-21

本章繼續使用《執行縫隙》研究階段建立的十七個正式核驗案例池,並重點使用其中的 Waymo 電線杆碰撞與召回事件。

該案例在本章中的作用非常具體:用於檢驗 Amplification 是否是 Execution Gap 的必要條件。在十七個正式核驗案例的聯合強度分佈中,Amplification 為十二個 Strong、四個 Partial、一個 None;Waymo 是其中唯一的 None。

因此,本章只使用它承擔反例作用:一次現實事件可以在沒有明顯 Amplification 的情況下仍然成立為 Execution Gap,由此否定「Amplification 是 Execution Gap 的必要條件」這一全稱判斷。

該案例不用於證明 Amplification 與執行縫隙無關,也不用於證明 AI 或自動化可以被忽視,更不用於建立後果規模、嚴重程度或風險等級。案例記錄中的 672 表示受影響設備範圍,不是事故數量;本章同時將該事件作為一個非災難性正例使用。

本章對該案例的核驗依據為美國國家公路交通安全管理局(NHTSA)的 Part 573 Recall Report 24E-049。

正文中另外出現的人工確認流程、連續自動執行鏈以及可自主選擇工具的系統,均屬於用於說明 Amplification 與能力邊界的假設性工程場景,不對應特定公司、產品或現實事故,因此不列為正式案例,也不需要單獨列出外部案例來源。


第九章|什麼不算執行縫隙

本章從反面給執行縫隙畫出外邊界。六類情形不能僅憑結果不好就自動進入這一問題空間:普通 bug 且沒有相關執行關係失效;合法變更且當前資格已經重新建立;規範上錯誤但被系統忠實執行的上游決定;純事後證明損失;韌性與恢復成功;以及沒有執行偏離的信息優勢。它們是排除邊界,不是另一張分類表,也不等於這些問題不重要。工具調用同樣不是第六個機制位置,它是否進入執行縫隙仍取決於既有關係是否失效。純事後證據問題默認在核心本體之外,但若隨後改變狀態假定、重試、恢復或下一次動作,可從重新影響現實的節點有界回入。至此,執行縫隙的問題空間第一次真正有了形狀。

前面幾章一直在回答同一個方向的問題:一次偏差為什麼能夠進入執行鏈,並最終抵達現實。

這個問題已經被逐步拆開。執行縫隙不位於某一個孤立的錯誤點上,而存在於執行過程中原本應當保持的關係之中;這些關係的失效可以落在五類直接機制上,而且彼此並不互斥,因此分析不能停在給事件歸類,而要繼續追問:什麼變了,哪一組關係失效了,失敗發生在哪一個機制位置。第七章和第八章又排除了兩個很容易被誤認成成因的對象——Change 是分析維度,Amplification 是橫切修飾項,它們都不能單獨解釋一次偏差為什麼成為執行縫隙。

但到這裡,還有另一個方向始終沒有被完整處理:

什麼樣的錯誤結果不屬於執行縫隙?

這個問題不是對前面理論的補充說明,而是它能否保持邊界的必要條件。如果只知道哪些結構可能形成執行縫隙,卻不知道什麼應該被排除在外,那麼任何自動化系統造成的錯誤結果,都可能被重新裝進這個概念裡。軟件缺陷、錯誤決定、信息失真、證明缺失、恢復動作,最後都會因為“結果出了問題”而被叫作同一種東西。到了那一步,執行縫隙這個概念看似覆蓋得更多,實際卻失去了定位能力。

因此,本章不再繼續增加新的機制,而是處理這個問題空間的外邊界。這裡要回答的不是哪些錯誤重要、哪些錯誤不重要,而是:面對一個已經發生的壞結果,什麼條件不足以讓它自動成為執行縫隙。

六條邊界

前面的正面結構確定以後,還需要把幾處最容易被誤判為執行縫隙的情形單獨劃出來。下面六條都滿足同一個基本限定:它們不自動構成執行縫隙。

這裡必須先說明,這六條不是一套新的分類體系。它們沒有共同的劃分軸,也不要求彼此互斥;把它們列在一起,只是因為這些情形都很容易在看到錯誤結果以後,被直接歸入執行縫隙。真正承擔邊界作用的,不是每一行左邊的名字,而是右邊那句限定:為什麼它不能被自動納入,以及還需要進一步判斷什麼。

它們也不是執行縫隙之外所有情形的完整清單。不在這六條裡,並不意味著某件事就自動進入執行縫隙;同樣,落在其中一條裡,也不意味著它永遠不可能在進一步定位以後重新進入。這裡給出的只是六處需要特別防止誤判的邊界。

還有一個區分必須從一開始就守住:

「不算執行縫隙」不等於「不重要」。

一個錯誤可以造成嚴重後果,卻仍然首先屬於另外一種問題;一個事件也可以具有巨大的工程、法律或治理意義,卻沒有形成執行側的偏離。本章討論的是歸屬,不是在給現實後果分輕重。

六類不自動構成執行縫隙的情形及其排除邊界

情形排除邊界
普通 bug,不伴隨相關的執行關係失效(Ordinary bug without relevant execution relation failure)必須進一步定位它如何形成 Relation、Path、Boundary、State / Result 或因果鏈內 Evidence 失效
合法變更,且資格已重新建立(Legitimate change with qualification re-established)Change 已被重新判斷並建立當前資格時,變化本身不是 Gap
被正確執行、但在規範上錯誤的上游決定(Correctly executed but normatively bad upstream decision)首先屬於上游 Decision / Authority 的合法性或正當性問題
純事後證明損失(Pure post-execution proof loss)不影響當前或後續 Action 時,默認屬於相鄰證明或可觀察性問題
韌性與恢復成功(Resilience / recovery success)恢復成功既不自動證明早先存在 Gap,也不抹除已發生的 Gap
無執行偏離的信息優勢(Information advantage without execution mismatch)不能指明已成立 Intent / Decision 與現實執行的偏離時,不進入本體

右邊這一列不能被壓縮成簡單的「是 / 否」。第一條要求繼續定位,第四條帶有因果位置的限定,第五條同時擋住兩個相反方向的誤判。刪掉這些限定,只留下六個名字,六條邊界就會重新變成六個標籤。

這張表也不是一個檢查流程。六行沒有先後順序,不規定判斷時點,也不告訴分析者在哪一步應該執行什麼動作。它只是把六個容易發生概念誤判的位置並排放出來,讓後面的討論可以分別說明它們為什麼沒有自動進入執行縫隙。

它和第四章的五類直接機制也不能接成一張「十一項清單」。五類機制回答的是:一旦執行縫隙成立,哪一種結構關係發生了失效。 這裡的六條回答的是另一個問題:眼前這件事情,是否已經有足夠理由進入執行縫隙這個問題空間。

一個處理內部機制,一個處理進入邊界。兩者不在同一層。

普通 bug,不伴隨相關的執行關係失效

第一條最容易被當成客氣話,其實它是六條裡最不客氣的一條。

一個程序裡有缺陷,缺陷被觸發,結果錯了。這本書對它的態度是:在完成進一步定位之前,它不進來。

排除的理由寫得很具體——必須進一步定位它如何形成了綁定關係、路徑、邊界、狀態與結果,或者因果鏈內證據的失效。這句話的重心在「進一步」三個字上。它沒有說普通 bug 與執行縫隙無關,它說的是「這裡有個 bug」不是一個定位結論。

差別在實際排查裡是可感的。一段代碼把金額的小數位截斷了,這是一個 bug。它到此為止是一個實現缺陷,修掉它,事情就結束了。但如果那個被截斷的金額隨後作為已批准的付款載荷進入了支付系統,而原先成立的那次批准針對的是未被截斷的那個金額,那麼這裡就不止有一個 bug——一個已經成立的上游對象與最終落到現實上的東西對不上了,而這正是綁定關係失效的形態。同一個缺陷,在被定位之前和之後,是兩件性質不同的事情。

所以這一條的排除不是終局。它是一道要求:先做定位,再談歸屬。定位做完之後,相當一部分原本被叫作「普通 bug」的東西會進入這個問題空間,因為它們確實形成了某一類關係的失效。真正被這一條擋在外面的,是那些做完定位以後什麼關係也指不出來的缺陷——它們仍然是缺陷,仍然需要修,只是修它們的理由不在這本書裡。

反過來說,這一條擋住的其實是另一個方向的濫用:把「執行縫隙」當成 bug 的新名字。如果任何缺陷都能直接稱為執行縫隙,那這個詞就只是換了一層包裝,而前面八章建立的所有區分——關係、層級、放大與成因——會在這一步全部作廢。

合法變更,且資格已重新建立

第二條第七章已經處理過一半。

變化是分析維度,不是根機制。合法地修訂意圖、正常的狀態更新、按授權調整參數,都可以發生變化而沒有縫隙。第七章問的是「變化是不是成因」,答案是不是。

這一條問的是另一件事:一次變化,要不要被當作這個問題空間裡的事情來處理。答案取決於一個具體的動作有沒有發生——那個被改動的對象,有沒有被重新判斷並建立當前的資格。

這個限定把兩種表面相似的情形分開了。一條策略被改了,改完之後針對新的對象、新的參數、新的範圍重新走了一次判斷,當前這次動作依據的是重新建立起來的資格:這是變更,不是縫隙,哪怕改動本身很大、影響面很寬。另一種情形是,策略被改了,而作用在當前動作上的仍然是改動之前建立的那份資格——舊資格作用於新對象,這不是「發生了變化」,這是綁定關係已經斷了。

區分它們的不是變化的幅度,也不是流程上有沒有走審批,而是當前這次動作所依據的資格,是不是針對當前這個對象重新成立過。

這一條守住的是一個很實際的邊界。配置會變,策略會變,參數會變,被依賴的對象也會變。如果每一次變化都自動帶著「可能是縫隙」的嫌疑,這個問題空間會很快被正常的變更管理淹沒,而它真正要定位的那種失效反而會變得難以看見。資格有沒有針對當前這個對象重新成立過,是把這兩種情形分開的關鍵。

被正確執行、但在規範上錯誤的上游決定

一個上游決定在規範上是錯的——它可能違法,可能證據基礎不足,可能根本不該被作出。系統隨後準確地執行了它,一步沒錯。結果很壞。

排除的理由是:這首先屬於上游決定與權威的合法性或正當性問題。

「首先」這個詞承擔了這一條的全部重量。它不說這類事情永遠在門外,它說的是這類事情的第一個歸屬點在哪裡。而之所以第一個歸屬點在上游,是因為執行側該保持的那個對應關係恰恰保持住了:決定是什麼,執行的就是什麼。要判斷執行是否偏離,看的是最終發生的事情和已經成立的上游對象對不對得上;在這裡,它們對得相當好。壞的是那個被對上的東西。

Robodebt 是這一條在現實材料上的形態。一套違法且證據不足的上游規則被忠實地自動化了,後果嚴重,波及廣泛,自動化的參與程度也毫無疑問。這件事說明的正是那句限定:不能僅憑錯誤後果,把它改寫為執行偏離。

這個案例在這本書的第一章裡出現過一次,當時承擔的是對照物的壓力——逼著「偏離」這個詞說清楚它攔住了什麼。這裡用的是它的另一面:它是第三條排除邊界的具體樣子。同一個事件在兩處的用途不同,也因此不被重複計入任何強度。

它不證明的東西同樣需要說清楚。

它不證明「規範上錯誤的上游決定一律排除在這個問題空間之外」。這一條的排除是默認,不是終局;一件這樣的事情在完成進一步定位之後,仍然可能從某個具體的位置重新進來。這本書不給出那些位置的一般規則,也不假裝自己有。

它不是這一章任何主張的證明。它是一個邊界案例,作用是劃線,不是加重量。在本書核驗的二十個候選事件中,十七個進入合格案例池,另外三個被作為邊界案例單獨登記。Robodebt 屬於後者,因此不進入任何強度計數。

它也不是一個需要在這裡展開的故事。它的完整事實鏈、責任認定與後續追究都不在這一章的範圍內。本章使用它,只為了說明這一條排除邊界在現實事件中是什麼樣子。

純事後證明損失

先說那條界線在哪裡。證據在這個問題空間裡的位置,由它的因果位置決定,而不是由它的形式決定。同樣一份缺失的記錄,在因果鏈的不同位置上,歸屬完全不同:

執行之前的證據失效,如果它推動了一個錯誤的判斷或動作,屬於執行縫隙的因果鏈。

執行之中的證據失效,如果它導致了錯誤的重試、恢復或後續動作,屬於執行縫隙的因果鏈。

執行動作已經完成、現實與結果都已經確定之後,單純的無法觀察、無法證明、無法審計、無法追責——默認位於核心本體之外。

第三種情形被暫時記為事後可證明性與可觀察性失效(Post-Execution Provability / Observability Failure)。「暫時記為」是字面意思:它有一個可以指稱的名字,但沒有被創建為一個正式概念,這本書也不為它創建。它現在的狀態就是一個已登記的、未被形式化的名字。

這個默認排除帶著一個條件,而這個條件必須和它緊貼著讀:如果那次失效隨後導致了錯誤的狀態假定、重試、恢復或下一次動作,它就從重新影響現實的那個節點回入執行縫隙。

把回入條件從排除結論旁邊挪開——挪進方框、挪進腳註、挪到章末——會讓這條邊界很容易被誤讀。讀者可能只帶走「事後證明不了不算執行縫隙」這半句,然後在一個恰恰滿足回入條件的場合裡使用它。所以它留在這裡,而且必須和默認排除放在一起讀。

同時,這個條件是有界的,不是一般規則。它沒有說「凡是事後的證明缺失最終都會回來」,也沒有說「只要足夠長的時間尺度上有影響就算數」。它指定的是一個具體的回入點:那次失效重新開始影響現實的那個節點。把它讀成一條普遍原則,等於取消了這一條排除邊界本身——因為在足夠寬鬆的解釋下,任何記錄缺失都可以被說成遲早會影響什麼。

這條邊界也不是在說事後的證明缺失不重要。一個已經發生的結果無法被觀察、無法被證明、無法被追責,這在工程上和治理上都是嚴重的問題,只是它不是使偏差得以到達現實的那個結構——而這本書要定位的恰恰是那個結構。判據是因果位置,不是記錄的質量,也不是事後調查的難易程度。

事故發生以後再回頭看,各種證據問題很容易被放到一起討論,但在這裡,它們仍然需要按照因果位置區分。

韌性與恢復成功

第五條很短,但它同時擋住兩個相反方向的誤判。

一個系統出了狀況,降級、重試、回滾、切換、人工介入,最後恢復了,沒有造成實際損害。這算不算發生過一次執行縫隙?

排除邊界的表述是:恢復成功既不自動證明早先存在縫隙,也不抹除已經發生的縫隙。

前半句擋住的是一種從結果倒推的習慣——因為啟動過恢復,所以之前一定有過什麼。恢復動作的存在只說明系統的韌性機制被觸發了,它不說明觸發它的那件事在結構上是什麼。一次恢復也可能對應一個被正常處理掉的故障。把恢復動作本身當成縫隙存在過的證據,會讓韌性做得越好的系統看起來問題越多。

後半句擋住的是另一個方向:因為最後沒出事,所以什麼也沒發生過。如果一次動作確實已經以偏離的方式到達了現實,那麼這件事已經發生了;後續的補救改變的是它的後果,不是它的性質。一次已經以偏離的方式到達現實的動作,即使它的後果被完全抵消了,讓它到達現實的那個結構位置也不會因此消失。

這兩半必須同時保留。只留前半句,這一條會變成對韌性工程的懷疑;只留後半句,它又會變成一條沒有邊界的追溯理由。

無執行偏離的信息優勢

第六條處理的是這樣一種情形:一個系統在信息側確實有問題——它給出了錯誤的表示,或者它掌握、暴露、誤導了某些信息——而人依據這些信息作出了決定,結果由此產生。

排除邊界是:不能指明已成立的意圖或決定與現實執行之間的偏離時,不進入本體。

Moffatt 訴加拿大航空一案是這條邊界的現實形態。一個錯誤的表示經由人的動作進入了結果,而那個給出表示的聊天系統,並未被證明具有現實的動作權。

這裡的區分很細,但它決定了整件事落在哪一層。信息側的錯誤是真實的,它造成的後果也是真實的;缺的是另一樣東西——要說某次執行偏離了,得先有一個已經成立的上游對象,再把最終發生的事情放在它旁邊,看兩者對不對得上。當那個系統對現實動作本身沒有被證明擁有權限時,這個比對找不到它的兩端。它不是比對下來發現「沒有偏離」,而是比對的對象還沒有湊齊。

這個案例不證明信息系統永遠不具有現實的動作權。它也不證明那件事在法律上的結論可以直接搬運成理論上的結論——這是兩套不同的判斷,各有各的依據。它同樣是邊界案例,不進入強度計數,也不構成任何理論的證明。

至於「具有現實動作權」究竟意味著什麼、它由誰持有、怎樣被建立和收回——這本書不展開。它在這裡只是一個定位標籤,用來說明第六條的比對為什麼無法進行。

必須能被指認的那個上游對象

第六條的表述裡藏著一個前提,而這個前提其實管著整張表。

要判斷一次執行有沒有偏離,必須能指明一個已經成立的意圖或決定。不是「應該有的意圖」,不是「合理的人會有的意圖」,也不是「事後大家一致同意本來應該是什麼」,而是一個在事情發生之前就已經成立、可以被取出來的對象。

The DAO 說明了這個前提失效時會發生什麼。攻擊者的動作被協議按照它寫好的方式執行了;這個結果與社會和治理層面的期待嚴重衝突。而這件事不自動證明它偏離了那個行動主體的意圖——因為在這裡,主體的意圖與規範的層級都沒有被唯一地確定下來。誰的意圖算數,哪一層規範算數,這些問題本身還是開放的。

比對需要兩端。當其中一端是「哪一個意圖才是那個意圖」尚未確定時,比對無法開始。這與「比對之後發現吻合」是完全不同的結論,不能把兩者寫成同一件事。

這個案例不證明協議執行不可能構成執行縫隙。它也不證明治理爭議與執行偏離之間沒有關係。它讓人看到的是一件更窄的事:在意圖的歸屬還沒有確定的時候,執行側的偏離判斷就還沒有落腳點。意圖有哪些類型、它是怎麼形成的、多個層級的規範之間如何排序——這些問題這本書不處理。

工具調用不是第六個位置

前一章之後,一個問題很自然會被提出來:那 Tool 呢?

這裡所說的工具(Tool),是指 AI Agent 或自動化系統能夠調用的外部能力接口。

在當下的工程語境裡,Tool 是一個非常顯眼的詞。模型調用工具,工具改變外部狀態,出問題的時候,「工具調用出錯了」聽上去很像一個完整的定位。

它不是。Tool 不構成一級機制,按具體的因果位置歸類。

這個裁決不是在貶低工具的重要性,它處理的是一個語義問題:「使用了 Tool」這句話本身不說明縫隙發生在哪裡。把它當作定位結論,等於在五個定位對象之外增加一個不指向任何結構位置的第六項,並吸收掉本來應該落在其他位置上的問題。

歸屬映射是具體的。工具請求或參數被錯誤地生成、轉換,歸到變化與綁定關係;多個各自合法的工具被組合成一條整體上未經授權的路徑,歸到執行路徑;工具權限被擴張為具體的執行權,歸到權威與資格關係;動態選擇、遞歸調用,以及由此帶來的速度與深度,歸到放大層。

四行裡沒有一行的歸屬目標是新的。它們全部指向已經建立的家族,或者指向那個明確不在家族之列的放大層。這正是這個裁決的內容:工具是一個跨層的應用語境,也可以被當作路徑的一種下位形態,但它不是一個獨立的失敗對象。

第三行那個歸屬目標——權威與資格關係——在這裡只是一個位置標籤。它指的是工具被授予的權限與它實際取得的執行能力之間對不上,而不是關於權威本身的任何理論。這本書不展開它。

這一條和前一章處理的是相鄰的問題。前一章的結論是:當前材料沒有發現 AI 或自動化獨有的一級執行縫隙機制;這一條進一步說明,Tool 本身也不構成新的一級機制。

這不是對工具的輕視。工具請求、工具組合、權限擴張和動態調用會把問題帶到不同的結構位置,正因如此,分析不能停在「用了工具」這句話上,而必須繼續追問:這一次,問題具體落在哪裡。

不算,不等於不重要

這一章用到的三個案例,來自三個差異很大的領域:消費者法律、區塊鏈治理、政府福利行政。三件事都後果嚴重,也都被廣泛討論過,沒有一件是無關緊要的技術細節。

它們全部被排除在這個問題空間的核心之外。

這不是巧合。六條排除邊界如果只在抽象層面上給出,很容易讓人覺得作者只是在為自己的理論圈定一塊容易防守的區域。而這三個案例把「不算」這個判斷放在了最難說出口的位置上:即使面對嚴重後果,仍然需要區分——問題究竟是不是由執行側的偏離造成的。

只有到了這裡,「不算執行縫隙」與「不重要」的區別才真正變得清楚。

這三件事在本章承擔的是本體邊界證據的作用,不進入合格案例的強度計數,也不構成任何理論的證明。它們各自對應不同的排除理由,彼此之間不構成一個體系,與表上的六條邊界也不是一一對應。把它們排列成六條邊界的「代表案例」,反而會製造一種並不存在的對應關係。

這個區分會直接改變分析接下來往哪裡走。當進一步定位已經確認一件事不屬於執行縫隙時,並不意味著分析到此結束,而是意味著繼續在這個問題空間裡尋找原因已經沒有意義,應當回到它真正所屬的位置:檢查上游決定的合法性,檢查為什麼事後無法取得證明,或者檢查一個信息系統的表示為什麼會被當作現實行動的依據。

把「不算」讀成「不重要」,會同時傷害兩邊:執行縫隙會因為被用於解釋不屬於它的問題而失去定位能力,而那些真正需要處理的問題,也會因為被放進錯誤的問題空間而變得更難處理。

一條仍然開著的口子

這一章給出了六條邊界,但它沒有把每一條都關嚴。

第四條的回入條件,目前仍然只是一個有界條件:它指定了一個具體的回入節點,僅此而已。它沒有被擴寫成一般規則,這本書也不擴寫它。這不是遺漏。要把它寫成一般規則,還需要回答什麼樣的後續影響算數、影響到什麼程度算數、在什麼範圍內成立,而現有材料不足以支持這些判斷。為了讓邊界看起來完整而把這些答案補出來,反而會讓它失去現在已經具備的清晰度。

與它相鄰,還有一件事沒有定下來:那個被暫時記為事後可證明性與可觀察性失效(Post-Execution Provability / Observability Failure)的對象,未來會不會成為一個獨立的正式概念。這個問題目前仍然開放,屬於形式理論層面。本章不回答,也不給出傾向。

研究邊界已經明確,不等於所有問題都已經獲得答案。把這一項如實留在開放狀態,比為了獲得表面上的完整而提前給它一個定義更穩妥;因為一旦一個尚未成立的答案被寫進正文,後面的討論很容易把它當成已經確定的前提繼續向上構建。

問題空間現在有形狀了

把前面九章放在一起看,能看到的是一個清晰的輪廓。

這個問題空間從一個具體的困難開始:每一環都對,結果卻錯了。它拆開了「執行了」這句話裡被混在一起的對象,把偏差的位置從單點移到了關係上,給出了五類會斷的關係,說明了其中兩類為什麼不能互相吸收,交代了這五類不互斥、因而需要三個維度而不是一張分類表來定位。它排除了兩個最容易被當作成因的東西——變化與放大——並且指出 AI 與自動化的位置在放大層,不在成因層。這一章又從另一側給它封了口:六條邊界,加上事後證明損失的默認歸屬與它的有界回入條件,加上工具調用不是一級機制。

它有形狀了。它不是「所有出錯的事情」,也不是「所有自動化造成的壞結果」。它是一個有正面結構、有外邊界、有已登記的未決項的問題空間。

而這個形狀一旦確定,一件之前一直被繞過去的事情就浮了上來。

前面所有的分析都指向同一個位置:上游成立與現實發生之間的那一段。意圖成立了,批准成立了,策略命中了,路徑沒有走錯,邊界還在——這些都成立,最終落到現實上的那一次動作,仍然可能對不上。

那麼,讓這一次動作獲得現實效力,這件事本身是什麼?

它不是意圖,不是決定,不是授權,不是策略,不是路徑,也不是邊界——前面八章已經把這些都拆開過,它們每一個都可以完好無損地成立,而那一次動作仍然可能落在錯的地方。這本書到目前為止一直在這個位置周圍打轉,既沒有給它一個名字,也沒有說它應當被當作什麼來處理。

這一章不回答這個問題。它只是讓這個問題第一次變得無法迴避。

本章術語與用法

以下內容用於說明本章中的術語用法,不等同於完整的形式化定義。其中部分表達只是本章使用的定位標籤或臨時登記名,不因此獲得獨立的形式概念地位。

  • 執行縫隙 | Execution Gap
  • 排除邊界 | Exclusion Boundary
  • 資格 | Qualification
  • 純事後證明損失 | Pure Post-Execution Proof Loss
  • 事後可證明性與可觀察性失效 | Post-Execution Provability / Observability Failure 本章中的臨時登記名,尚未被建立為正式概念。
  • 有界條件 | Bounded Condition
  • 現實動作權 | Action Authority 本章僅作為定位標籤使用,不展開其獨立理論。
  • 工具 | Tool

本章案例與資料來源

本章使用三個真實世界案例。它們在本章中承擔的都是邊界說明作用,而不是對執行縫隙理論本身的證明。

三個案例的狀態均為 Boundary Case,在本章中承擔 Illustration(邊界說明)作用,不進入本書 Qualified 案例的強度統計,也不能據此推出六條排除邊界是一套窮盡分類。它們與六條邊界之間也不存在一一對應關係。

Robodebt

Robodebt 在本章中用於說明第三條排除邊界:被正確執行、但在規範上錯誤的上游決定。

本章關注的不是該事件完整的法律、責任或政策過程,而是其中與邊界判斷直接相關的一點:一個上游決定本身可能違法、證據不足或者在規範上存在嚴重問題,但如果執行系統忠實地執行了已經成立的上游決定,那麼錯誤後果本身並不足以證明發生了執行側偏離。

因此,該案例在本章中只用於說明一個有限判斷:

不能僅憑錯誤後果,把規範上錯誤的上游決定改寫為執行偏離。

這一排除是默認歸屬,不是永久排除。進一步定位以後,如果事件中還能指明具體的執行關係失效,它仍然可能從相應位置重新進入執行縫隙的問題空間。

Robodebt 在本書第一章已經出現過;兩處使用的是同一個現實事件,但承擔不同的分析作用,因此不重複計入案例強度。

Moffatt v. Air Canada

Moffatt 訴加拿大航空一案在本章中用於說明第六條排除邊界:無執行偏離的信息優勢。

本章使用這個案例時,只取與執行邊界相關的部分:聊天系統給出了錯誤表示,該信息隨後經由人的判斷進入現實結果,但現有材料並沒有建立該聊天系統本身具有現實動作權。

因此,這裡缺少的不是一個已經比較以後被確認“沒有偏離”的關係,而是進行執行偏離判斷所需要的兩端尚未同時成立。

該案例不證明信息系統永遠不具有現實動作權,也不意味著法律上的判斷可以直接轉換成執行縫隙理論中的判斷。它只用於說明:

不能指明一個已經成立的 Intent / Decision 與現實執行之間的偏離時,不自動進入執行縫隙本體。

The DAO

The DAO 在本章中用於說明第六條背後的一個前提:要判斷一次現實執行是否發生偏離,必須先能夠指明一個已經成立的上游意圖或決定。

在該事件中,攻擊者的動作被協議按照既有規則執行,但結果與社會和治理層面的期待發生嚴重衝突。僅憑這一結果,並不能自動證明現實執行偏離了某個已經成立的行動主體意圖,因為主體意圖及規範層級本身並沒有被唯一確定。

因此,該案例在本章中只用於說明:

當需要比較的上游對象尚未被確定時,執行偏離的判斷還沒有建立所需要的比較基礎。

它不證明協議執行不可能形成執行縫隙,也不證明治理爭議與執行偏離無關。本章不展開 Intent 的類型、形成方式,也不處理多個規範層級之間的排序問題。


正文中關於金額截斷、策略變更、恢復與重試等具體場景,均屬於用於解釋邊界的假設性工程情形,不對應特定現實事故,不進入正式案例池,也不作為獨立證據使用。工具調用部分屬於機制歸屬說明,同樣不作為現實案例或獨立證據。


第十章|執行效力應當成為一個獨立的工程對象

本章完成《執行縫隙》的理論收束。執行縫隙描述的是上游已成立對象與現實具體 Action 之間的關係失效;執行效力則是“這一次具體動作獲得現實效力、使現實狀態實際發生變化”這件事本身,兩者不能混用。偏差之所以不能靠繼續加強審批、授權、策略等上游正確性消除,是因為問題並不位於這些判斷內部。由此,本章把執行效力作為工作性稱呼,主張它需要被當作獨立工程對象單獨看待,但明確拒絕給出正式定義、控制時點、判斷依據或工程結構。這個結論也不蘊含人工逐筆審批。九項未決問題被完整交出,第一本書最終停在一個清楚邊界上:問題已被定義並交出,但解決方案尚未被建立。

上一章的最後一句話把一個問題推到了面前,然後就停住了。九章下來,執行縫隙這個問題空間的輪廓已經畫完,而畫完之後露出來的不是一個新的縫隙,而是一件此前始終沒有被單獨當作對象處理的事情:

讓這一次具體動作在現實中生效。

這裡需要先把兩個詞分開。

執行縫隙說的是偏差:已經成立的上游對象,與最終落到現實中的具體動作之間,原本應當保持的關係發生了失效。前面九章一直在界定這個問題空間——它在哪裡發生、有哪些直接機制、什麼會放大它,以及什麼不屬於它。

這一章所說的執行效力不是這個偏差的另一個名字。它指的是另一件事:這一次具體動作獲得現實效力、使現實狀態實際發生變化這件事本身。

前者描述的是一種失敗關係;後者指向的是每一次現實執行都必須經過的那件事。執行縫隙之所以能夠發生,恰恰說明:上游的意圖、決定、授權、策略、資格、路徑和邊界即使各自成立,也不能自動替代對這一次具體動作本身的處理。

這裡還不是在給「執行效力」下一個正式定義。第十章要做的更剋制:先說明為什麼這件事不能繼續被已有對象吸收,為什麼它需要被單獨看見,然後停下來。

一本書寫到結尾,敘事本身會施加一種壓力,要求它拿出一個方案——既然前面已經把問題說清楚了,總該說說怎麼辦。這一章不打算順著那個壓力走。拒絕繼續往下給方案,不是因為這個問題不重要,而是因為這本書的材料只夠走到這裡。

一本講問題的書如果不以方案結束,讀起來很容易像是沒有寫完;而一本在材料不夠的時候硬湊出方案的書,又可能顯得更加完整。兩種代價並不對稱:前一種由這本書自己承擔,後一種卻會由使用它的人承擔。

進入這一章需要的前提,前面已經給全了,而且有兩件,缺一件都不行。

一件來自第五章:邊界可以失效,而路徑正常。 一次偏差可以完全沿著規範的路線到達現實,沿途每一步都對得上。

另一件來自第九章:這個問題空間有外邊界。 六條排除邊界,加上純事後證明損失的默認歸屬與有界回入條件,使執行縫隙不再等於「所有出錯的事情」,也不再等於「所有自動化造成的壞結果」。

這兩件不是同一層的結論。前一件說明偏差可以在哪裡發生,後一件說明這個問題空間到哪裡為止。只有前一件,接下來的話很容易被讀成「所以要把邊界加固」;只有後一件,又容易被讀成「所以問題已經講完了」。

第十章正是從這兩個結論同時成立的地方開始。

那一段不在任何一項上游判斷的內部

先把位置說準。

前面九章反覆回到同一個地方:上游各項成立之後,與現實狀態真正發生變化之前的那一段。意圖是清楚的,決定是做過的,授權是有效的,策略是命中的,資格是成立的,路徑沒有走錯,邊界也仍然存在——這些都可以成立,最終落到現實上的那一次具體動作卻仍然可能對不上。

第一章看到的是一個粗糙的現象:每一環都對,結果卻錯了。第二章把「執行了」拆開,說明提交、調用、執行狀態、回執、結果與證據不能被當成同一件事。第三章以後,偏差的位置又從單點移到了關係上,五類直接機制逐步建立。

把這些結論放在一起,剩下一個此前沒有被單獨處理的問題:上游對象已經成立以後,這一次具體動作為什麼會真正進入現實。

這裡說的不是又發現了一種新的執行縫隙。執行縫隙描述的是上游已經成立的對象與現實執行之間出現的關係失效;這裡追問的,則是關係兩端之中靠近現實的那件事本身——這一次具體動作獲得現實效力。

它不在任何一項上游判斷的內部。這是一個位置判斷,不是程度判斷。

意圖處理的是「要達成什麼」,決定處理的是「要不要做」,授權與資格處理的是「能不能做」,策略處理的是「符不符合已經建立的規則」,路徑處理的是「實際怎麼走」,邊界處理的是「動作能夠到達哪裡、什麼能夠攔住它」。這些對象各自回答自己的問題,也都可能在自己的適用範圍內成立。

但「這一次具體動作現在應當發生」不是其中任何一個問題。它不能因為前面的答案全部成立,就被自動當作已經獲得了答案。

這裡最重要的是「這一次」。

上游對象可以針對某個已經成立的請求、主體、條件或範圍;而現實裡真正發生的,永遠是一項具體動作:針對具體對象,在具體狀態下,以具體參數,在具體時刻改變了現實。前面的判斷成立,與這一次具體動作最終獲得現實效力,是兩件不能直接合並的事情。

這也不是在說問題一定來自上游判斷過期。什麼算過期、過期以後意味著什麼,都屬於另外需要獨立建立的問題。本章在這裡需要確定的只有一件事:上游判斷成立,與這一次具體動作獲得現實效力,不是同一個對象。

因此,當偏差落在這兩者之間時,僅僅繼續檢查上游判斷本身,並不能把這個位置消掉。並不是那些判斷檢查得還不夠仔細,而是正在尋找的那個問題,本來就不位於它們各自的內部。

這也是為什麼復盤中會出現一種很難處理的結果:每一項上游記錄都能夠成立,流程本身也找不到明顯錯誤,但最終發生的事情仍然不對。此時,「流程是對的,結果是錯的」並不意味著什麼都沒有查出來。它至少已經指出了一件事:繼續只在那些已經成立的上游判斷內部尋找,解釋不會完整。

加強上游,在那個位置上沒有著力點

這個位置一旦被看見,就會碰到一個非常自然的工程反應:把上游做得更嚴格。

事故之後,加一道審批、收窄授權、細化策略、更頻繁地重新確認資格,都是很容易想到的修復方式。它們有一個共同點:改善的是某一項上游判斷本身的正確性。

這些改進當然有價值。一個錯誤的決定被批准下來,就應該檢查決定與審批;一次越權調用被放過去,就應該檢查授權。執行縫隙從來不意味著這些上游對象不重要。

問題只出現在另一種情形裡:那些上游判斷本身已經成立,而偏差仍然發生在它們與這一次具體動作之間。

在這個位置上,繼續提高上游判斷自身的正確性,並沒有直接觸及正在討論的問題。審批迴答的是這件事是否被批准,授權回答的是主體是否具備資格,策略回答的是條件是否滿足;而這裡留下的問題是:這一次具體動作,在它實際進入現實的這一刻,是否應當獲得執行效力。

這兩個問題不能自動互相替代。

再嚴格的審批,可以讓審批本身更可靠,但不能僅憑這一點建立這一次具體動作的現實效力。再精確的授權,可以更準確地確認資格,卻不能僅憑資格已經成立,就推出最終發生的動作與那份資格仍然保持著正確的對應關係。策略、邊界和其他上游對象也是一樣:它們做得更好,會改善各自負責的那部分問題,但不會因此自動回答另一個沒有被它們提出的問題。

第五章已經建立過最反直覺的一側:路徑完全正常,並不妨礙偏差到達現實。這裡使用的是同一個結構事實。如果一次失敗中並沒有哪一項上游判斷本身出錯,那麼單純把這些判斷再做得更嚴格,仍然沒有觸及偏差實際所在的位置。

這也是為什麼這種遺漏並不容易被發現。上游改進通常是可以直接描述的:審批增加了什麼,權限收窄了多少,策略補上了哪些條件。系統因此確實會在這些維度上變得更好。

但“這一次具體動作如何獲得現實效力”如果從來沒有被單獨當作對象處理,就沒有同樣清楚的位置可以檢查。於是一個系統可能在所有已經被命名的維度上都獲得改善,而那個尚未被單獨處理的位置仍然存在。

所以這裡需要守住範圍:這一章不是反對加強上游,更不是說審批、授權、策略或資格沒有意義。它只指出,加強這些對象所改善的是它們自身,而不能因為它們變得更正確,就假定另一件事情也已經隨之得到處理。

偏差不能靠加強上游正確性消除,因為偏差不在上游判斷內部。

這不是程度判斷,而是位置判斷。

問題空間成立,而且有界

在真正給那件事命名之前,還需要確認一件事:前面九章建立起來的,究竟是不是一個已經可以被單獨討論的問題空間。

答案是肯定的。

它首先有可以被指認的對象。第二章已經把「執行了」這個看似完整的詞拆開:提交、調用、執行狀態、回執、結果與證據並不相等,也不能被默認理解成一組依次發生的階段。

它也有明確的位置判斷。執行縫隙不必落在某一個單獨錯誤的節點上,它可以發生在原本應當保持的關係之中;這些關係的失效已經被進一步拆成五類直接機制,而且彼此並不要求互斥。

它還有明確的分析邊界。變化本身不是成因,放大本身也不是成因;AI 與自動化可以放大既有問題,卻不能僅憑它們的存在解釋執行縫隙為什麼成立。

第九章又從另一側給出了外邊界:並不是每一個壞結果都屬於執行縫隙。普通 bug、合法變更、規範上錯誤但被忠實執行的決定、純事後證明損失、恢復成功以及沒有執行偏離的信息問題,都不能僅憑結果不好就自動被裝進這個概念。

同時,這個問題空間內部仍然保留著已經明確登記的未決項。結果內部的若干層次尚未被正式建立,事後可證明性與可觀察性失效也仍然只是一個臨時登記名,其他相鄰問題同樣沒有因為這一冊結束就自動獲得答案。

所以這裡所說的「成立且有界」,不是說理論已經完成,而是說它的形狀已經可以被指認:哪些問題屬於這裡,哪些問題不能自動進入,哪些位置已經建立,哪些位置仍然保持開放。

還有兩條貫穿全書的限定需要一起留下。

第一,惡意不是執行縫隙成立的必要條件。 這本書討論的結構失效並不要求先有一個惡意主體。攻擊當然可以利用這些位置,但惡意不是這個問題空間成立的前提。

第二,AI 與自動化不是一級成因。 當前材料沒有發現只有 AI 或自動化才能產生的一級執行縫隙機制;它們在本書中的位置仍然是放大層。把執行縫隙直接縮寫成「模型出了錯」,會丟掉前面已經建立的大量非模型特定結構。

這兩條限定很重要,因為它們共同阻止這個問題空間被誤讀成「AI 安全事故」或者「惡意攻擊」的另一種說法。

有界也不等於完成。

邊界畫出來,只說明我們已經能夠區分什麼屬於這個問題空間、什麼不自動屬於它,以及哪些問題目前還沒有答案。它並不意味著這些問題已經被解決,更不意味著後續工程結構已經被建立。

研究邊界被確定,與工程問題被解決,是兩件不同的事情。

而且這個順序不能顛倒。只有當執行縫隙本身的範圍已經被限制住,第十章接下來要指認的那個對象才不會膨脹成「所有導致系統出錯的原因」。

現在,才可以問那個更窄的問題:

在一個已經有邊界的執行縫隙問題空間裡,讓這一次具體動作真正獲得現實效力的那件事,應當被當作什麼?

它不是已有對象中的任何一個

現在可以給那件事一個說法了。

本章暫且把它稱為執行效力。

這裡的「執行效力」,指的不是執行過程中出現的偏差,也不是執行結果本身,而是一個更窄的對象:這一次具體 Action 獲得現實效力,使某個現實狀態實際發生變化這件事。

這個稱呼首先需要和「執行縫隙」分開。

執行縫隙描述的是一種失敗關係:已經成立的上游對象,與最終落到現實中的具體動作之間,原本應當保持的關係發生了失效。

執行效力則不是這種失敗關係的另一個名字。它指向的是關係靠近現實的那一端——那一次具體動作真正進入現實、產生實際效力這件事本身。

當執行效力實際落到了與已經成立的上游對象不相符的地方,我們會看到執行縫隙。兩者有關,但不是同一個對象:一個描述偏差,另一個讓我們能夠單獨指認那一次現實執行本身。

這也解釋了為什麼不能繼續用「執行縫隙」來稱呼這裡的東西。如果仍然把它叫作執行縫隙,就會把問題本身和問題發生所涉及的現實執行對象重新合併起來。前面九章花了大量篇幅才把這些對象拆開,到這裡再把它們裝回同一個詞裡,前面的區分就失去了意義。

接下來還需要逐個排除幾個已經存在的對象。

執行效力不是意圖。意圖回答的是「要達成什麼」,而一次具體動作是否已經在現實中發生,不等於那個意圖本身。

它也不是決定。決定可以已經成立,但決定成立並不等於那一次具體動作已經獲得現實效力。

它不是授權或資格。授權與資格說明某個主體、對象或動作是否滿足已經建立的條件,但資格成立本身仍然不是現實狀態的變化。

它不是策略。策略可以命中,也可以給出明確判斷,但策略判斷與一次具體動作真正發生仍然是兩件事。

它不是路徑。路徑說明動作怎樣抵達執行位置,第五章已經證明路徑完全正常時偏差仍然可能存在。

它也不是邊界。邊界回答的是動作能夠到達哪裡、什麼能夠攔住它;而執行效力指向的是動作實際進入現實這件事。

最後,它也不是結果。結果是在動作已經發生以後才能被討論的東西。第二章已經把結果從「動作已經執行」這句話裡拆開,因此不能再用結果來替代那次動作獲得現實效力本身。

逐個排除這些對象,並不是為了建立一套新的分類。這裡只是在說明:前面已經建立的任何一個對象,都不能單獨吸收「這一次具體動作獲得現實效力」這件事;把它們合在一起,也不能因此把這件事重新變成其中某一個對象的副產品。

所以這裡真正需要成立的結論,比「它是一個全新的本體」要剋制得多:

「讓這一次具體 Action 獲得現實執行效力」需要被當作一個獨立的工程對象來處理。

這裡的「獨立」只表示一件事:它需要被單獨看、單獨分析、單獨討論,而不能因為前面的意圖、決定、授權、資格、策略、路徑或邊界已經成立,就認為它已經被順帶處理完成。

因此,「執行效力」在這本書裡首先是一個工作性稱呼。它讓此前一直混在「執行了」這句話裡的那件事能夠被單獨指認出來。

到這裡,我們有了名字,但還沒有正式定義。

命名到此為止

到這裡,命名已經完成,這一章也必須開始收住。

本章把「讓這一次具體 Action 獲得現實執行效力」單獨指認出來,並暫時稱為執行效力。這個動作只解決了一件事:此前混在「執行了」這句話裡的那個對象,現在終於可以被單獨談論。

但能被談論,不等於已經被正式定義。

這本書不會繼續給出執行效力的控制插入點,也不會規定它應當在鏈路中的哪一個具體時刻被判斷。前文已經能夠指出它所在的結構區間——上游對象成立之後,現實動作真正生效之前——但這與規定「系統應當在哪一刻介入」是兩件不同的事情。後者已經屬於控制結構。

這本書也不給出執行效力的判斷依據。

「憑什麼認為這一次具體動作現在應當獲得現實效力」當然是一個真實問題,但只要開始回答,就必須進一步說明哪些條件算數、如何判斷這些條件,以及這些判斷之間是什麼關係。那些內容並沒有在本書中建立。

同樣,這裡不規定執行效力應當由什麼組件、角色或機制承擔,也不規定它與現有的意圖、決定、授權、資格、策略、路徑和邊界之間應當形成什麼工程結構,更不規定當它無法成立時系統應當如何處置。

所以,本章停在一個非常明確的位置上:

執行效力已經被指認出來,但還沒有被形式化。

這裡給出的仍然只是一個工作性稱呼,而不是完整的形式定義。一個正式定義至少需要說明這個對象的邊界、成立條件,以及它與相鄰形式對象之間的關係。本書沒有完成這些工作,也不把尚未建立的答案提前寫進去。

命名的意義因此不是給出了答案,而是讓問題第一次有了可以被準確指向的位置。

第二章曾經做過類似的事情。在「執行了」被拆開之前,提交、調用、執行狀態、回執、結果和證據很容易被壓進同一個詞裡。把它們分開以後,改變的首先不是系統,而是問題終於能夠被精確地提出。

執行效力在這裡也是一樣。

在它被單獨指認之前,人們可以不斷討論意圖是否清楚、決定是否正確、授權是否有效、策略是否命中、路徑是否正常,卻仍然缺少一個詞來單獨追問:

這一次具體 Action 為什麼最終獲得了現實效力?

第十章只負責讓這個問題可以被問出來。

至於怎樣回答它,這本書到這裡為止。

這不蘊含人工逐筆審批

有一種讀法必須在這裡明確擋住,因為它太容易順著前面的論證得出來。

前面一直在說:上游對象成立,並不足以推出「這一次具體動作現在應當獲得現實效力」。那麼最直接的反應似乎就是:既然自動判斷不夠,就在每一次動作真正發生之前,再讓一個人確認一次。

這個結論不成立。

原因首先就在前面的論證裡。人工確認本身仍然是一項上游判斷。一個人可以正確地看到請求、參數、審批和當時呈現給他的狀態,也可以在自己的判斷範圍內完全合理地確認「可以執行」,但這並不會因此消除上游判斷與最終現實動作之間可能出現的關係失效。

把一個人加入鏈路,增加的是一項新的判斷,並沒有改變那個問題所在的位置。

這不是說人不應參與,也不是說人的判斷比自動判斷更不可靠。人工判斷當然可以在很多場景中發揮重要作用。本章這裡只處理一個更窄的問題:人工確認不能因為它來自人,就自動取得一種其他上游判斷所沒有的能力。

如果意圖、決定、授權、資格、策略本身都不能單獨推出這一次具體 Action 應當獲得現實效力,那麼再增加一次人工判斷,也不能僅憑「這是人確認過的」就完成這個推導。

因此,把人工逐筆審批當作這個問題的默認最終答案,只是把一個新的上游對象放到了原有缺口之前,並沒有說明那個缺口本身是怎樣被處理的。

還有一個限定必須留住。

這裡否定的是**「執行效力需要被單獨處理,所以每一次動作都必須由人逐筆確認」**這個推論,而不是否定人在系統中的任何作用。前者是本章必須擋住的誤讀,後者從來不是本章的結論。

安全也不等於每一個動作都必須由人點頭。

到這裡,否定就結束。

這本書可以說明為什麼「人工逐筆審批」不能從前面的結論中直接推出,卻不能繼續回答「那麼應當由什麼來做」。因為一旦開始指定由誰承擔、在什麼時刻判斷、依據什麼條件決定,或者失敗時系統應該怎樣處置,就已經開始建立控制結構。

而建立那套結構,不屬於這本書已經完成的工作。

所以這裡必須留下一個不完全令人滿意、但邊界清楚的結果:

執行效力需要被單獨看見,並不等於每一次執行都需要重新交給人確認。

至於它究竟應當如何被工程化處理,這本書不在這裡給出答案。

本書仍未解決的問題

到這裡,這本書要解決的都已經解決了。剩下的這一節,是把它明確不解決的東西擺出來。

這一節裡沒有任何新東西。下面九件事,每一件在前面九章裡都已經出現過——被碰到過,被停在那兒過,或者被指名說過這本書不做。把它們集中在一個地方,只是為了讓「交出」成為一個看得見的動作,而不是結尾處的一次省略。

也正因為如此,這一節不是一份待辦清單。九件事列在一起的時候,最自然的讀法是「問題已經分解完畢,剩下按項實施」——這個讀法與這本書的結論方向正好相反。有界說的是形狀確定,不是工作已經拆好。下面每一件事後面跟著的是它為什麼不在這本書裡被解決,不是它歸誰。

完整的執行控制工程結構。這本書的全部工作是定義需要被控制的問題空間,而不是建立控制它的工程結構。這兩件事之間不是詳略之別:前一件回答「要處理的是什麼」,後一件回答「怎麼處理」,後者需要的判斷依據、失敗語義與結構約束,一樣也不在這本書的材料裡。

Authority 的完整分解理論。這本書只把 Authority 作為已經成立的上游對象之一使用,並沒有對它的內部結構作進一步區分。把 Authority 拆成哪些部分、各部分之間是什麼關係,需要一份這本書沒有做過的獨立工作。憑現有材料給出一個看起來合理的分解,它會很容易被當作已經建立的結論。

證據的全部形式與治理。證據在這本書裡只出現在一個很窄的位置上:在因果鏈之內,它可以推動一次動作。證據有哪些形式、什麼樣的證據算是夠了、誰來管它、它在什麼條件下失效,全部不在這本書內回答。第三章之後那一族關係的討論始終停在因果鏈內這個限定上,不是因為其餘部分不重要,而是因為這些問題需要獨立建立。

全部失敗與降級語義。不確定、缺失、過期、衝突——這些狀態在執行層分別意味著什麼,系統遇到它們時應當如何處置,這本書不定義。它們各自的執行含義與處置方式都需要另外建立,而這本書的材料沒有走到那一步。

威脅模型、失敗矩陣、不變量與部分失陷。這本書從頭到尾沒有以存在對手作為執行縫隙成立的必要前提。它處理的那類失敗不需要惡意就可以成立。而一旦正式引入對手,就必須進一步回答在對手存在時哪些性質仍然成立,以及體系被部分攻破以後哪些結論仍然有效。那屬於另一種驗證工作,也需要另一組材料。

Intent 的類型與形成理論。意圖在這本書裡只作為規範參照出現,用來判斷這一次動作是不是對得上。它有哪些類型、如何形成、由誰持有、怎樣被改寫,這本書一律不展開。這個限定從第一章起就在,不是到結尾才加上的。

全部主體模型,以及可錯性的閉包條件。這一件與其餘幾件性質不同。這本書只使用了主體可能出錯這一否定式前提,而「在什麼條件下可以說某一類主體的可錯性已經被窮盡」這個問題,目前既沒有被建立,也沒有被裁決。不是這本書選擇不做,而是它現在沒有答案。把一個沒有答案的問題寫成已有的樣子,比把它留在開放狀態更糟。

拒絕點的那幾個屬性。誰持有它,它在什麼時候可達,覆蓋多大範圍,在什麼時機上起作用,能不能被撤銷——這些問題一個都不在這本書內回答。第五章討論邊界時已經接近「誰能最終拒絕」這個位置,然後停住了。繼續往下展開,就不再是在描述執行縫隙,而是在建立另一層結構。

技術結果、外部狀態與業務結果之間的正式層次。第二章已經指出,「結果」這個詞底下壓著的不止一樣東西,並且明說了三者之間的最小正式層次沒有被定下來。它在這裡再次出現,不是因為它換了地方——它的理論落點仍然在第二章,這裡只是回指。它與前面八件還有一點不同:它的落點甚至不在任何一本書裡,而在將來的一次形式化審閱,那件事還沒有開始。

除了這九件,還有一條要留在這裡,因為它沒有被解決,只是被處置了:讀者可能把這本書讀成「所以需要人工逐筆審批」。前面一節已經顯式地否定了這個讀法。否定不等於這條風險消失了,它是一個需要一直帶著的處置方向——每一次這本書的結論被複述,這個誤讀都會重新有機會成立。

最後,關於這九件事的歸屬,只說一句。其中有一些確實有指定的承擔者,但歸屬說的是誰負責,不是讀者必須先讀誰。把它們連成一條線,那條線是工作的分工,不是閱讀的順序,更不是邏輯上的前置關係。這本書不需要靠任何後續工作來成立;它在自己的範圍內已經完整。

到此為止

前面九章一直在回答一個問題:當上遊各項都可能成立,偏差究竟怎樣進入現實。

這一章做的是最後一步。它沒有再增加一種執行縫隙,也沒有給出一套控制結構。它只是把前面九章留下的那個對象單獨指認出來:

讓這一次具體 Action 獲得現實執行效力。

這本書暫且把這件事稱為執行效力。

到這裡,「執行縫隙」與「執行效力」之間的區別也應該已經清楚。

執行縫隙描述的是一種失敗:已經成立的上游對象與最終現實執行之間,原本應當保持的關係發生了失效。

執行效力指向的則不是這段失效,而是這一次具體 Action 真正進入現實、使現實狀態發生變化這件事本身。

前者是這本書定義的問題空間;後者是這個問題空間被一路拆開以後,最終暴露出來、需要被單獨看見的工程對象。

而這本書能夠走到的地方,也就到這裡。

它說明了為什麼這件事不能繼續被意圖、決定、授權、資格、策略、路徑、邊界或結果中的任何一個對象吸收;說明了為什麼單純加強上游正確性不能替代對它的單獨處理;也明確排除了一個最容易出現的誤讀——這並不推出每一次動作都必須由人逐筆確認。

它同時留下了大量沒有解決的問題:怎樣正式定義這個對象,它的判斷依據是什麼,它應該如何進入工程結構,不確定、缺失、過期與衝突意味著什麼,以及與它相鄰的那些形式對象最終應當怎樣建立關係。

這些問題沒有因為這本書結束而獲得答案。

於是最後留下的,是這本書從前九章一路推到這裡的那個問題:

如果偏差發生在關係中,且任何上游成立都不足以推出「這一次動作現在應當發生」,那麼「讓這一次具體 Action 獲得現實執行效力」本身,是否應當被當作一個獨立的工程對象來處理?

這本書給出的結論已經足夠明確:

它需要被這樣看待。

但怎樣真正把它作為一個工程對象接手,並不由這本書繼續解決。前面一節已經把仍然缺失的東西逐項留下;繼續往下給出結構、判斷依據或處置方式,就會跨過這本書為自己劃定的邊界。

所以《執行縫隙》的結束,不是「問題已經被解決」。

它完成的是另一件事:問題已經被定義到足夠清楚,可以被明確交出。

這兩種結束很不一樣。

前一種意味著可以停止追問;後一種意味著,從這一刻開始,後續工作至少知道自己究竟在處理什麼。

這種交出也不是把本書的完整性轉移給別的工作。這裡得到的結論在它自己的範圍內已經成立,不依賴任何後續結構來補全。即使不繼續往下讀,前面建立的判斷仍然可以獨立使用:可以用來辨認一次失敗是否真的屬於執行縫隙,可以區分偏差發生在什麼關係上,也可以排除那些雖然產生壞結果、卻不應被自動歸入這個問題空間的情形。

確實還會有別的工作繼續面對執行效力這個對象,但那是敘事上的接續,不是邏輯上的依賴。它們不是這本書成立的前提,這本書也不替它們提前規定答案。

因此,讀完《執行縫隙》之後留下來的,不是一套解決方案。

留下來的是一個已經有邊界的問題空間,和一個終於能夠被單獨指認、卻仍然沒有被完整形式化的對象。

這或許沒有方案那麼令人踏實。

但對於一個還沒有被真正建立起來的工程問題,先知道問題在哪裡、邊界在哪裡、哪些答案還沒有資格被寫下來,比過早得到一個看似完整的方案更重要。

有一件事一直在發生,每一次執行都要經過它,而它從來沒有被當作一個東西處理過——現在它有了一個說法,並且這本書到此為止。

本章術語

  • 執行縫隙 | Execution Gap
  • 執行效力 | Execution Effect
  • 執行動作 | Execution Act
  • 上游判斷 | Upstream Judgment
  • 意圖 | Intent
  • 決定 | Decision
  • 授權 | Authorization
  • 資格 | Qualification
  • 策略 | Policy
  • 執行路徑 | Execution Path
  • 執行邊界 | Execution Boundary
  • 獨立工程對象 | Independent Engineering Object
  • 人工逐筆審批 | Per-Action Human Approval

本章案例與資料來源

本章未使用真實世界案例。

章中出現的復盤、會議、審批、授權與具體動作等場景,均為用於說明執行縫隙、上游判斷與執行效力之間關係的一般性工程場景,不對應特定公司、產品、事故或公開事件,因此不需要列出外部案例來源。


附錄一|術語與用法

這本書中的詞,並不處於同一理論層級。

有一些已經在《執行控制工程術語規範》第一版中正式凍結,具有穩定的中英文名稱和最小定義;有一些承擔本書內部的理論論證,但尚未進入正式概念層;有一些只是用於定位問題的分析標籤,它們方便討論,卻不因此成為理論對象;還有一些描述的是證據強度、研究凍結程度或案例在本書中的使用角色,而不是某件事情本身是什麼。另有少數詞,本書只是暫時用它們指認一個已經出現、但尚未完成定義或形式化的對象。

如果把這些詞當成同一層級來使用,很容易得到比本書實際主張更強的結論。

因此,這份附錄首先要做的,不是擴展每個詞的含義,而是標明它在本書中的狀態,以及它能夠承擔的論證重量。

本附錄使用以下狀態:

正式概念——已在術語規範第一版中凍結,具有正式中英文名與最小定義。

Book I 理論術語——在《執行縫隙》的論證中承擔明確作用,但尚未進入正式概念層。

分析標籤——用於定位、描述和索引問題,不是失效機制,也不自動構成理論對象。

證據判級——描述某個案例對某一分析項或機制判斷的證據支持程度。

研究狀態——描述一項研究結論當前的凍結程度,而不是機制本身的屬性。

工作性稱呼——為了能夠討論某個尚未完成定義的對象而採用的臨時稱呼,不具有正式定義。

臨時登記名——研究中已經識別出的相鄰問題或候選對象,但尚未決定是否發展為正式概念。

普通工程術語——按照通常的工程含義使用,本書只在必要處限定其用法,不另行建立理論定義。

案例角色——描述某個案例在本書論證中的用途,例如正例、反例或邊界案例;它不是失效機制,也不是概念身份。

Book I 結論用語——用於表達本書已經得到的結論或明確排除的讀法,但不會僅因出現在結論中就自動升級為正式概念。

如果一個詞在本書中承擔的作用超出了其狀態所允許的範圍,那是使用上的錯誤,而不是這個詞因此獲得了更強的理論身份。


核心術語

執行縫隙 | Execution Gap

狀態:正式概念

已經成立的上游對象,與最終現實執行及結果之間,可能出現偏離的系統性空間。

這裡的“上游對象”,包括意圖、決定、審批、授權、策略與資格等已經在各自規則和範圍內成立的對象;“偏離”指最終發生在現實中的動作或結果,與這些已經成立的對象不能繼續保持原本需要成立的對應關係。

執行縫隙描述的不是某一次具體錯誤本身,也不是某一種固定失效機制。它首先指出的是:上游對象分別成立,並不足以自動建立端到端執行與現實結果的成立。

邊界:執行縫隙不等同於模型幻覺、權限缺失、審批失敗、時間差、單點故障或其他某一種具體實現缺陷。這些因素可以出現在具體案例中,但不能單獨充當執行縫隙的定義。

本書也不把所有壞結果都納入執行縫隙。若問題首先來自上游決定本身錯誤,而後續執行只是忠實地落實了該決定,僅憑現實後果嚴重,並不足以證明執行側發生了這裡所說的偏離。

範圍裁決:本書只採用一個上位含義。歷史材料中“審批到執行”“授權到執行”等較窄用法,保留為執行縫隙的具體場景或歷史入口,不與上位含義並列為第二套正式定義。

相關術語:已經成立的上游對象、局部正確、端到端執行正確、執行、結果。

執行 | Execution

狀態:正式概念(含兩項下位表達)

使表達、判斷與承諾進入現實狀態變化的上位過程。

本書在這一上位概念下區分兩個對象:

執行過程(Execution Process)——一件事進入可識別的執行路徑之後,直到現實結果形成的整個過程。

執行動作(Execution Act)——真正使現實狀態發生變化的那一次動作。

這兩個對象必須分開。執行過程可以持續、等待、重試或中斷;執行動作關心的則是現實狀態是否已經被實際改變。

邊界:執行不等同於意圖、決定、審批、授權、策略、提交、調用或結果;執行過程也不等同於執行動作。尤其需要保持一條邊界:結果是獨立對象,不是執行動作的同義詞,也不能僅由執行動作已經發生這一事實自動推出。

歷史材料中,“執行”曾同時指向過程、裁決、現實動作和結果。本書在這裡作出的區分,是為了使這些對象能夠被分別討論,並不意味著歷史材料原本已經自然形成了同樣的分層。

相關術語:執行過程、執行動作、提交、調用、執行狀態、回執、結果、證據。

結果 | Result

狀態:Book I 理論術語(內部結構未凍結)

結果是與執行動作分開的對象。

本書只建立一條必要的否定邊界:

執行動作已經發生,並不足以自動建立結果已經成立。

同樣,提交、調用、執行狀態或回執的存在,也不能單獨替代結果本身。

在具體系統中,人們談論“結果”時,實際可能指向不同對象。例如:

技術結果(Technical Result)——執行器或外部系統返回的技術性輸出;

外部狀態(External State)——系統之外已經發生、或者能夠被觀察到的現實狀態;

業務結果(Business Result)——某種現實變化在特定業務語境中是否被認為已經成立、完成或達到目標。

這裡列出這三個詞,只是為了防止它們在討論中被互相壓縮。本書並沒有建立一個由三者組成的正式結果分類,也沒有規定它們之間的層級、順序、包含關係或推出關係。

未決:什麼條件下技術結果可以被視為穩定或最終,外部狀態在什麼觀察範圍和時間尺度下能夠被確認,業務結果又由什麼規則決定,這些問題目前都沒有形成跨系統適用的統一答案。

因此,本書不把任何一個具體對象規定為“真正的最終結果”,也不從其中一個對象自動推出另一個對象。

相關術語:執行動作、執行狀態、回執、證據。

局部正確 | Local Correctness / 端到端執行正確 | End-to-End Execution Correctness

狀態:Book I 理論術語(成對使用)

這兩個詞在本書中主要用於表達一條否定關係:

局部正確 ≠ 端到端執行正確

這裡的“局部正確”,指某個意圖、決定、審批、授權、策略、資格或其他對象,在自身的規則、輸入和適用範圍內成立。

“端到端執行正確”則指向一個更大的問題:這些已經成立的上游對象,是否最終與現實執行及結果保持了本應成立的對應關係。

本書建立的並不是一套正面的“正確性”定義,而只是下面這條有限結論:

一個或多個局部對象分別成立,本身不足以建立端到端執行及現實結果的成立。

邊界:這條不等式只否定從“局部成立”到“端到端成立”的自動推出關係。它不表示局部判斷不重要,也不表示局部對象必然存在錯誤;同樣,它不推出“因此一定還缺少某個對象、機制或檢查”。

把這條否定式改寫成“只要再增加某種機制,就可以保證端到端正確”,會超出本書已經建立的結論。

相關術語:執行縫隙、已經成立的上游對象、執行、結果。

已經成立的上游對象 | Established Upstream Object

狀態:Book I 理論術語

指已經在自身規則、輸入與適用範圍內成立,並能夠作為後續現實執行之參照的上游對象。

本書中常見的這類對象包括意圖、決定、審批、授權、策略與資格。

之所以需要單獨使用這個詞,是因為“偏差”必須有參照物。判斷一次現實執行是否發生偏離,不能只問最終結果是否糟糕,而必須能夠進一步指出:

它究竟偏離了哪個已經成立的上游對象?

如果無法指出這樣的參照物,僅憑現實結果異常或後果嚴重,還不足以建立本書所說的執行偏離。

邊界:一個上游對象“已經成立”,只表示它在自己的規則、輸入和適用範圍內成立。它不表示該對象本身在更高層意義上一定正確,也不能自動推出這一次具體動作在當前對象、參數、狀態和邊界下應當發生。

不同上游對象可以同時存在,它們之間也不保證天然一致。本書使用這個術語,是為了固定偏差的參照,而不是把所有上游對象合併成一個統一的“正確來源”。

相關術語:執行縫隙、局部正確、端到端執行正確、意圖、決定、授權、策略、資格。

五類直接機制族 | Direct Mechanism Families

狀態:Book I 理論術語 研究狀態:條件凍結

本書在已核驗案例中,反覆使用五類關係來定位:已經成立的上游對象與現實執行之間,哪一種關係沒有繼續成立。

它們是:

判斷與綁定關係的失效(Decision / Binding Relation Failure)——已經成立的意圖、決定、審批、授權、策略或資格,與當前具體動作的對象、參數、目標、狀態、語義、來源或適用範圍之間,沒有繼續保持必要的對應關係,而原有判斷仍然能夠推動後續現實動作。

執行路徑的偏離(Execution Path Deviation)——實際發生的步驟、順序、主體、入口或鏈路,與該次執行所要求的路徑之間出現偏離。

執行邊界的失效(Execution Boundary Failure)——原本用於限制哪些動作、路徑或能力可以到達現實,以及哪些主體能夠阻止現實副作用的邊界,在當前動作上缺失、不完整、失效或被改寫。

執行狀態與結果關係的失效(Execution State / Result Relation Failure)——執行狀態、調用、提交、回執、外部狀態或業務結果之間原本需要被分別判斷的對象,被錯誤地壓縮、對應、歸屬或解釋,從而使某個局部表示被繼續當作另一個對象成立的依據。

因果鏈內證據與證明關係的失效(In-Causal-Chain Evidence / Proof Relation Failure)——正在參與當前判斷、執行、重試、恢復或後續動作的證據,與它所聲稱證明的對象、來源、順序、前序狀態、連續性或現實事實之間沒有保持必要的對應關係。

邊界:這五類是本書當前用於定位直接失效關係的研究結構,不是已經證明完備的普遍分類,也不表示所有執行縫隙都必須被永久限定在這五類之內。

五類之間不要求互斥。同一次失敗可以同時涉及多類關係失效,因此本書不把它們作為只能單選其一的事故分類表。

它們也不建立正式機制編號或固定順序。這裡的“五類”只表示當前研究材料中被保留下來的五個機制家族;其研究狀態為條件凍結,而不是永久封閉。

如果未來出現現有結構無法解釋的新案例,或者其中某一類被證明可以被另一類無損吸收,這一結構仍然可以重新打開。

相關術語:已經成立的上游對象、執行路徑、執行邊界、執行狀態、結果、證據、變化、放大。

變化 | Change

狀態:分析標籤

用於追問一次失敗中什麼發生了變化。

變化的對象可以是意圖、含義、表示、對象、參數、目標、狀態、上下文、策略、路徑、邊界規則、結果或證據。它的作用,是幫助定位偏差出現前後哪些對象或條件發生了不同。

邊界:變化本身不是成因。

合法修訂意圖、正常更新狀態、按既定規則調整參數,或者重新建立當前資格,都可能發生變化而不形成執行縫隙。因此,僅僅指出“有東西變了”,不足以解釋為什麼偏差能夠進入現實。

在本書已核驗的案例中,變化具有很高的覆蓋度,但這個觀察只說明它是一個有用的分析入口,不證明變化是執行縫隙成立的必要條件,也不證明變化本身造成了失敗。

對於具體案例,仍然需要繼續追問:變化之後,究竟是哪一種本應繼續成立的關係沒有保持,以及這種失效如何與現實執行發生關聯。

相關術語:五類直接機制族、判斷與綁定關係、執行路徑、執行邊界、結果、證據。

三個分析問題 | Three Analytical Questions

狀態:分析標籤

本書在案例分析中反覆使用三個追問:

什麼變了?(What Changed?) 用於識別在偏差形成前後,哪些對象、條件、表示或狀態發生了變化。

哪一個關係沒有繼續成立?(Which Relation Failed to Hold?) 用於定位兩個已經分別成立的對象之間,原本需要保持的對應關係是否發生了斷裂,例如意圖與審批、審批與載荷、規範路徑與實際路徑、執行狀態與結果、現實事實與證據之間的關係。

這種失效落在什麼位置?(Where Does the Failure Sit?) 用於進一步判斷該失效更接近判斷與綁定、執行路徑、執行邊界、狀態與結果關係、因果鏈內證據與證明關係,還是主要表現為放大效應。

邊界:這三個問題只是分析過程中的追問方式,不構成三個維度、三個層級、三個階段或三個機制類別,也沒有固定的先後順序。

同一個案例可以從三個問題同時進入分析,它們之間也不要求一一對應。尤其是“哪一個關係沒有繼續成立”與“判斷與綁定關係的失效”不能混為一談:前者是一個通用分析問題,後者是五類直接機制族中的一個具體機制家族。

本書使用這三個問題,是為了幫助定位,而不是建立一套新的座標體系。

相關術語:變化、五類直接機制族、判斷與綁定關係、放大。

放大 | Amplification

狀態:分析標籤(橫切位置,非直接機制)

描述一個已經存在的偏差,如何在後續執行中擴大影響、加快傳播、形成級聯,或者減少被發現和糾正的機會。

本書觀察到的放大因素包括速度、規模、連續自動化、反饋循環、工具調用深度、級聯傳播,以及人工或系統糾正機會的減少。這些只是當前案例中反覆出現的表現,不構成封閉枚舉。

邊界:放大不是執行縫隙成立的直接機制,也不是必要條件。

它回答的是:

一個已經形成的偏差,為什麼會變得更快、更大、更深或更難糾正?

它不回答:

這個偏差最初為什麼能夠成立並進入現實執行?

因此,放大不能與五類直接機制族並列為第六類機制。同一次失敗可以存在明顯放大,也可以在沒有明顯放大的情況下已經構成執行縫隙。

AI 與自動化在本書中的主要作用也位於這裡:它們可以增加執行速度、規模、連續性、路徑可變性和反饋強度,並減少人工糾正機會;但當前材料沒有建立由 AI 或自動化獨有的直接失效機制。

這一結論屬於有界負面發現:當前材料沒有發現,不等於未來不可能發現。

相關術語:五類直接機制族、變化、有界負面發現、災難半徑。

排除邊界 | Exclusion Boundary

狀態:Book I 理論術語

用於說明某些相鄰問題在什麼情況下不能僅憑自身就被認定為執行縫隙。

本書目前明確討論過的排除情形包括:

  • 未伴隨相關執行關係失效的普通缺陷;
  • 已重新建立當前資格的合法變化;
  • 規範上錯誤、但被後續系統忠實執行的上游決定;
  • 執行與結果已經確定之後才發生的純事後證明或觀察能力損失;
  • 已經成功阻止錯誤繼續進入現實的恢復與韌性機制;
  • 隻影響信息、表示或人的判斷,但沒有形成現實執行偏離的情形。

這些情形被列出,是為了防止“執行縫隙”膨脹成“所有壞結果”或“所有系統問題”的另一個名字。它們不構成一個已經證明完備的排除分類表。

邊界:排除並不表示這些問題不重要,也不表示它們永遠與執行縫隙無關。它只表示:

僅憑該現象存在,還不足以建立執行縫隙。

如果一個原本位於排除邊界之外的問題,隨後導致判斷與綁定、執行路徑、執行邊界、狀態與結果關係,或者因果鏈內證據與證明關係發生失效,並進一步影響現實執行,那麼應當從這個新的因果位置重新判斷。

因此,排除邊界判斷的不是問題“屬於什麼名字”,而是它在當前事件中是否已經形成了與現實執行相關的偏離關係。

相關術語:執行縫隙、五類直接機制族、邊界案例、純事後證明損失。

不完美主體 | Fallible Subject / 可錯性 | Fallibility

狀態:正式概念

不完美主體指能夠理解、判斷、授權、調用、控制或執行動作,但無法僅憑其身份、資格、善意、能力或既往表現,證明它未來每一次具體判斷都一定正確的主體。

可錯性指的正是這一有限事實:一個主體可能在某一次具體判斷中出錯,而這種可能性不能通過認證、授權、善意、高能力或長期穩定表現被徹底消除。

本書討論過的人、AI Agent、自動化程序、管理員、外部服務、策略引擎、運行時和設備,都是可能被這樣分析的典型對象。這些只是本書涉及的例子,不構成“不完美主體”的封閉集合,也不表示主體範圍已經被形式化完成。

可錯性首先是一個工程前提,不是道德判斷,也不是對主體可靠性的總體評價。

邊界:可錯不等於惡意,不等於已經失陷,不等於不可信,也不表示主體經常或必然犯錯。

它只否定一件事:

主體的身份、授權、資格、善意、能力或長期穩定表現,本身不足以替某一次具體判斷的正確性作保證。

因此,本書也不從“主體可錯”進一步推出“應當減少主體自主性”“必須由人逐筆確認”或“應當尋找一個更可信的最終主體”。

與之相連的另一條邊界是:

一個判斷是否正確,與這個判斷是否被賦予改變現實的權力,是兩個不同的問題。

相關術語:已經成立的上游對象、授權、權威、現實動作權。

執行效力 | Execution Effect

狀態:工作性稱呼(名稱凍結)

執行效力用於指認這樣一件事:

某一次具體動作最終取得現實作用,使現實狀態實際發生變化。

之所以需要單獨指認這個位置,是因為本書已經反覆表明:意圖成立、審批成立、授權成立、策略成立,以及執行鏈中的其他對象分別成立,都不能自動替代“這一次具體動作最終如何取得現實作用”這個問題。

因此,執行效力不是對已有上游對象的重新命名,也不是執行動作、執行結果或執行縫隙的同義表達。它只負責把現實動作真正取得作用這一側單獨指出來,使其能夠被獨立討論。

邊界:本書尚未為執行效力建立正式形式定義,也沒有建立它的成立條件、判斷規則、控制位置、承擔主體、權威結構或形式模型。

因此,不能從“執行效力”這一名稱進一步推出:

  • 每一次執行都必須經過一個名為“執行效力”的固定階段;
  • 系統中必然存在一個專門授予執行效力的組件;
  • 執行效力必然由某個主體、邊界、設備或控制層決定;
  • 某一種機制本身足以保證執行效力正確。

這些結論均超出 Book I 已經建立的範圍。

執行效力與執行縫隙也必須嚴格區分。

執行縫隙描述的是已經成立的上游對象,與最終現實執行及結果之間可能出現偏離的系統性空間。

執行效力則指向另一側:某一次具體動作事實上取得現實作用、使現實狀態發生變化這一事實本身。

這裡的 Effect 不表示執行產生的“結果”或“後果”,也不等同於 Result。它表達的是動作取得現實作用這一側,而不是動作發生之後所觀察到的結果。

名稱狀態:本書統一使用“執行效力 / Execution Effect”。該名稱在 Book I 範圍內凍結。名稱凍結只意味著術語寫法保持穩定,不表示該對象的形式定義、成立條件或工程結構已經凍結。

相關術語:執行動作、結果、執行縫隙、獨立工程對象。

事後可證明性與可觀察性失效 | Post-Execution Provability / Observability Failure

狀態:臨時登記名 / 未決

用於暫時指認這樣一類情形:

現實執行及其結果已經確定之後,系統才喪失對相關事實進行證明、觀察、審計或追責的能力。

本書目前把這種純事後的證明或觀察能力損失放在執行縫隙的核心問題空間之外。原因不是它不重要,而是當現實動作和結果已經完成之後才發生的證明損失,本身沒有改變那一次已經發生的現實執行。

因此,這個名稱目前只是為了能夠討論一個相鄰問題,不構成新的直接機制,也沒有建立正式概念。

回入條件:判斷它是否重新進入本書問題空間,關鍵不在於它表現為“證據問題”還是“可觀察性問題”,而在於它後來是否重新參與現實因果鏈。

如果事後證明或觀察能力的缺失,進一步導致錯誤的狀態判斷、重複執行、錯誤恢復,或者影響下一次具體動作,那麼應當從它重新影響現實執行的那個節點開始重新分析。

換句話說:

決定它是否屬於執行縫隙的,不是形式,而是因果位置。

未決:這類問題未來是否需要形成獨立概念、獨立理論對象或單獨的工程結構,本書不作決定。

相關術語:證據、執行結果、排除邊界、因果鏈內證據與證明關係的失效。


相關工程與分析術語

意圖 | Intent

狀態:正式概念

對希望發生之動作、對象、參數、條件或結果的表達。

意圖可以真實、明確、來源清楚,但這些屬性本身仍不足以自動建立後續授權、執行動作或現實結果的成立。

邊界:主觀目標、被表達的意圖、授權、現實動作與結果是不同對象。意圖在本書中作為重要的上游參照之一,但不因此成為最終執行資格的來源。本書不展開意圖的類型、形成過程或完整理論。


決定 | Decision

狀態:普通工程術語(在本書中作為上游對象使用)

指“是否要做”這一層的判斷。

本書把決定與意圖、審批、授權、策略和資格一起視為可能已經成立的上游對象,但不為“決定”單獨建立新的理論定義。

邊界:決定已經形成,不等於這一次具體動作因此已經獲得現實執行資格。


授權 | Authorization

狀態:正式概念

判斷某個主體是否被允許擁有或使用某類能力的資格邊界。

授權成立,只能說明相應資格在其適用範圍內成立;它不能自動推出某一次具體動作在當前對象、參數、狀態和邊界下應當發生。

邊界:授權不等同於權威,不等同於實際執行能力,也不等同於某一次具體動作的最終執行資格。長期授權尤其不能被自動解釋成“之後每一次具體執行都應被允許”。


權威 | Authority

狀態:正式概念

在明確範圍內,對動作、規則、狀態或邊界作出對系統具有約束力之決定的權力。

這裡的“權威”只指工程意義上的 Authority,與知識聲望、專家地位或社會權威無關。

邊界:權威不等同於許可、能力或授權;擁有權威,也不能建立持有者每一次具體判斷都正確。

本書在這裡主要守住一條否定關係:

資格、判斷與改變現實的權力,不能被默認視為同一個對象。

Book I 不完成權威分解的正式理論。


策略 | Policy

狀態:正式概念

表達執行判斷規則及其適用條件的對象。

策略可以參與裁決,但它不是事實本身,也不因被命中就自動成為某次具體動作的最終權威。

邊界:策略不能自行證明其輸入事實正確,也不能僅憑自身存在或命中,建立現實動作應當發生。


狀態 | State

狀態:正式概念

在特定時點,與某次動作能否被判斷和執行直接相關的事實與條件集合。

狀態使此前已經成立的授權、策略或判斷不能脫離當前現實條件被無限繼續使用。

邊界:這裡的狀態不是系統全部內部數據,也不是簡單的數據庫快照。哪些來源、版本、時間、新鮮度、衝突或局部可見性需要被納入,不在 Book I 中形成完整定義。


資格 | Qualification / 當前資格 | Current Qualification

狀態:分析標籤

用於描述某個主體、對象或動作是否滿足已經建立之條件。

本書使用這一說法時,重點始終落在“當前”上:某項資格曾經成立,並不能自動證明它對此刻這一次具體動作仍然成立。

邊界:本書不為資格建立獨立理論層級。資格在具體案例中的作用,需要繼續通過判斷與綁定關係、執行邊界以及當前狀態來分析。


執行路徑 | Execution Path

狀態:分析標籤

描述某一次具體執行實際上如何行進,包括步驟、順序、主體、入口和鏈路。

邊界:存在多個步驟、較長的因果鏈或複雜調用,本身並不構成執行路徑偏離。

一個錯誤對象也完全可能沿著正常路徑傳播。

只有當實際路徑與該次執行所要求的路徑之間能夠被指出存在偏離時,才應使用“執行路徑偏離”這一判斷。

路徑問的是:

這一次請求實際上怎麼走?

它不回答系統整體由誰約束,也不等同於執行邊界。


執行邊界 | Execution Boundary

狀態:正式概念

在動作成為現實之前,對其狀態、參數、資格以及允許範圍進行約束,並能夠真實允許或阻止現實副作用的邊界。

它關注的核心問題是:

哪些動作、路徑和能力受到什麼約束,以及誰能夠最終拒絕。

邊界:執行邊界不等同於登錄邊界、訪問邊界、策略邊界、工具接口或普通網絡邊界,也不必綁定某一種硬件實現。

它與執行路徑回答的不是同一個問題:

路徑問“這一次請求怎麼走”; 邊界問“什麼受到約束,以及什麼能夠阻止它進入現實”。

Book I 使用這一概念定位問題,但不回答“最終應當由誰拒絕”這一工程設計問題。


邊界改寫 | Boundary Mutation

狀態:Book I 理論術語(執行邊界失效的一種強表現)

指原本決定路徑、能力範圍或最終否決關係的規則或實施結構本身發生改變。

邊界:邊界改寫只是執行邊界失效的一種情況,不是其同義詞。

執行邊界可以因為缺失、不完整或失效而無法約束動作,並不要求原有邊界曾經在運行過程中被“改寫”。因此,不得把所有邊界失效都追認為 Boundary Mutation。


證據 | Evidence

狀態:正式概念

能夠支持關於執行前條件、執行判斷、邊界狀態、現實動作或結果之可驗證事實的材料。

證據不是日誌的同義詞,也不是任何被記錄下來的數據。

邊界:記錄存在,不等於被記錄的事實成立;回執存在,也不等於完整的執行證據成立。

證據本身同樣不決定某次動作是否應該發生。

Book I 主要關注一個有限位置:當證據進入當前判斷、執行、重試、恢復或後續動作的因果鏈時,它與所證明對象之間的關係可以直接影響現實執行。

本書不建立完整的證據形式、存儲或治理理論。


提交 | Commit

狀態:普通工程術語

指某個請求、決定或動作已經在系統一側被提交、接受或記錄這一事實。

本書使用這個詞,主要是為了避免把“已經提交”繼續壓縮成“已經調用”“已經執行”或“結果已經成立”。

名稱說明:本書統一使用“提交 / Commit”。該名稱在 Book I 範圍內凍結。


調用 | Invocation

狀態:普通工程術語

指請求已經被髮送或調用到下一執行對象。

邊界:調用成立,只能說明相應調用事實成立。請求被髮送、對方收到、現實動作實際發生以及結果形成,都可以是不同的事情。

因此,調用不能替代執行動作、執行狀態、回執或結果。


執行狀態 | Execution State

狀態:分析標籤

系統對於某次動作當前進展情況的表示或判斷。

它可以表示未執行、已提交、已調用、部分執行、已完成,也可以是未知。

邊界:執行狀態是系統對事實的表示,不等於事實本身。

尤其需要保留一個狀態:

未知。

未知不能因為難以處理,就被自動解釋成成功或完成。


回執 | Receipt

狀態:普通工程術語

來自外部來源、關於請求是否被接收、處理或返回某種狀態的聲明。

邊界:一份回執可以是真實、完整且能夠通過驗證的,但它所證明的範圍仍然取決於回執本身的語義。

因此,回執不能自動替代現實動作或結果。

本書守住的基本關係是:

執行動作 ≠ 執行狀態 ≠ 回執 ≠ 證據。

結果同樣不能被提交、調用或回執單獨替代。


轉換、時差、接縫與關係 | Transformation / Temporal Gap / Seam / Relation

狀態:分析標籤

用於描述偏差可能出現的位置。

“轉換”強調兩個對象在表達形式或語義之間發生變化;“時差”強調原先成立的條件跨越時間以後可能不再成立;“接縫”強調兩個各自成立的對象在連接處仍然需要額外關係;“關係”則是對這些位置的上位描述。

邊界:這四個詞是位置語言,不是四類失效機制。

它們幫助把視線從對象內部移到對象之間,但不能代替具體機制判斷。


單點漏洞 | Single-Point Vulnerability / 單點故障 | Single Point of Failure

狀態:普通工程術語

本書使用這兩個詞,主要為了說明:執行偏離並不只發生在能夠被圈出的單個組件、漏洞或故障點上。

組件內部故障當然可以存在,但當各個對象分別成立而結果仍然發生偏離時,僅尋找單點故障可能不足以解釋問題。

歷史材料中另有“單點災難性執行”(Single-Point Catastrophic Execution)這一表達;它與通常意義上的單點故障不是同一概念,Book I 不在這裡展開。


內部成立 | Internal Validity

狀態:分析標籤

指某項判斷、對象或狀態在它自己的規則、輸入和適用範圍內成立。

這個說法是 Book I 的重要分析語言,因為本書討論的恰恰是:

對象內部成立,並不能自動建立對象之間的關係也仍然成立。


工具 | Tool

狀態:普通工程術語(跨層應用語境)

工具本身不構成新的直接失效機制。

“發生了工具調用”也不能作為執行縫隙的分類依據。

具體工具問題必須繼續按照實際因果位置分析。例如:

  • 請求、對象或參數發生變化後,需要繼續判斷是否形成了判斷與綁定關係失效;
  • 工具調用所形成的實際路徑偏離了該次執行所要求的路徑,可以進入執行路徑分析;
  • 工具獲得的能力使原有約束無法繼續阻止現實動作,需要繼續檢查判斷與綁定關係或執行邊界;
  • 動態選擇、遞歸調用、連續自動化帶來的速度、深度與級聯,則可能主要表現為放大。

因此,工具不會因為成為 AI Agent 的重要能力,就自動形成第六類直接機制。

真正需要追問的仍然是:

它改變了什麼?哪一種關係沒有繼續成立?實際路徑怎樣形成?什麼邊界允許動作最終進入現實?


現實動作權 | Action Authority

狀態:分析標籤

用於判斷某個主體或系統是否真正具有直接改變現實狀態的能力或位置。

本書主要在邊界案例中使用這一標籤,用來區分:

影響人的判斷

與

自己能夠直接推動現實動作

這兩種不同情況。

邊界:它只是定位工具,不構成 Authority 的正式分解,也不能從中推出新的權威層級理論。

名稱說明:本書統一使用“現實動作權 / Action Authority”。該名稱在 Book I 範圍內凍結。


災難半徑 | Blast Radius

狀態:正式概念

一次錯誤、失陷或不受約束的執行可能造成的現實影響範圍。

它關注的是一個偏差如果繼續進入現實,其影響可以擴展到哪裡,而不只是最初的錯誤發生在哪裡。

邊界:災難半徑不是失敗概率,不是攻擊面,不是固定數值指標,也不等於已經發生的實際損失。

它描述潛在影響範圍,不負責直接計算損失價值,也不判斷相應風險是否可接受。


強支持 / 部分支持 / 不成立 | Strong / Partial / None

狀態:證據判級

用於描述某一個案例對某項分析判斷或機制判斷的證據支持程度。

強支持表示現有材料能夠較直接地支持該判斷。

部分支持表示存在相關證據,但不足以完整建立該判斷,或者材料本身存在重要限制。

不成立表示在當前案例和現有證據下,該判斷沒有獲得足夠支持。

邊界:這三個等級描述的是證據支持程度,不是:

  • 事故嚴重程度;
  • 風險等級;
  • 重要性;
  • 原因排序;
  • 機制優先級;
  • 責任大小。

因此,一個機制在某個案例中被判為“不成立”,只表示現有證據沒有建立該機制判斷,不表示該事故不嚴重,也不表示這個機制在其他案例中不存在。


條件凍結 | Conditional Freeze

狀態:研究狀態

表示某項研究結構在當前材料與證據條件下暫時停止隨意增加、拆分或重命名。

例如,五類直接機制族處於條件凍結狀態,表示在現有研究基礎上,暫不因為單篇材料、單個案例或敘事便利重新調整當前結構。

邊界:條件凍結描述的是研究結論當前的狀態,不是機制自身的本體屬性,也不表示該結構永久不可修改。

重新打開通常需要更強的理由,例如:

  • 出現現有結構無法解釋的新案例;
  • 某一機制被證明可以被另一機制無損吸收;
  • 新證據使原有邊界無法繼續成立。

單篇新文章、措辭差異或為了寫作方便進行結構調整,都不足以單獨構成重開理由。


有界負面發現 | Bounded Negative Finding

狀態:分析標籤

用於標記這樣一類結論:

在當前材料和證據範圍內,沒有發現某個對象、機制或現象。

它必須按照其證據邊界理解。

邊界:

當前材料沒有發現 ≠ 該對象不可能存在。

因此,本書所有類似“當前沒有發現由 AI 或自動化獨有的直接失效機制”的表述,都只在當前研究材料的範圍內成立。

把它進一步改寫成“這種機制不存在”或“不可能存在”,屬於對本書結論的實質性加強。


必要條件 | Necessary Condition

狀態:普通工程術語

本書主要使用這個概念的否定形式:

某個因素不是某類失敗成立的必要條件。

當存在一個該因素缺席、而所討論的失敗仍然成立的合格案例時,就足以否定“該因素是必要條件”這一命題。

邊界:否定必要性,不等於證明該因素不重要,也不等於證明它從不參與其他案例。


邊界案例 | Boundary Case

狀態:案例角色

用於檢查某些與執行縫隙相鄰的問題,是否應當被自動納入本書的問題空間。

邊界案例的主要作用不是證明理論,而是迫使理論說明:

什麼不能僅憑自身就被算作執行縫隙。

邊界:邊界案例不是直接機制,也不作為普通正例進入正式核驗案例池的證據強度統計。

把邊界案例與正例混合統計,會改變案例分析所表達的含義。


獨立工程對象 | Independent Engineering Object

狀態:Book I 結論用語

Book I 最後一章提出:讓某一次具體動作真正取得現實作用這件事,需要被當作一個獨立的工程對象來處理。

這裡的“獨立”只有一個有限含義:

它需要被單獨看見、單獨分析和單獨討論,而不能被視為審批、授權、策略或其他上游對象正確之後自然產生的副產品。

邊界:這一結論不表示 Book I 已經建立了一個新的正式形式對象,也不回答它應當:

  • 由誰承擔;
  • 在什麼位置判斷;
  • 在什麼時間判斷;
  • 根據什麼信息判斷;
  • 通過什麼機制實現。

這些問題屬於後續工作。


人工逐筆審批 | Per-Action Human Approval

狀態:Book I 結論用語(明確排除的讀法)

指每一次具體動作發生之前,都要求人重新確認或批准一次。

Book I 的結論不推出人工逐筆審批。

發現上游成立不足以自動建立現實執行正確,並不等於“因此每一次動作都必須重新交給人”。

邊界:排除這一讀法,也不等於否定人在系統中的作用,更不等於 Book I 已經給出了替代方案。

本書在這裡同時拒絕兩個跳躍:

主體可能犯錯,因此必須減少自主性。

以及:

自動執行存在風險,因此所有動作都必須由人逐筆確認。

兩者都不是 Book I 已經建立的結論。


一條使用說明

這份附錄中的詞並不擁有相同的理論身份,因此它們能夠承擔的論證重量也不同。

正式概念可以按照已經凍結的最小定義使用。

Book I 理論術語只在本書已經建立的範圍內承擔論證作用,不因此自動升級為全套執行控制理論的正式概念。

分析標籤用於定位、描述和索引問題,不能被當作新的機制或理論層級。

證據判級只描述案例材料對某項判斷的支持程度。

研究狀態描述的是當前研究結論的凍結程度,而不是機制本身的屬性。

工作性稱呼與臨時登記名明確標記尚未完成定義的對象或問題,它們的存在不是為了填補空白,而是為了把空白保留下來。

案例角色說明一個案例在論證中的用途,不決定案例屬於哪一種失效機制。

Book I 結論用語只能承擔本書已經推出的有限結論,不能因為出現在結論中就自動獲得正式概念身份。

如果一個詞被賦予了超出其狀態所允許的含義,本書的結論就會在轉述中被悄悄加強。

這份附錄存在的主要目的,就是防止這種升級發生。


附錄二|現實失敗與邊界案例

這份附錄是做什麼用的

書裡用到的每一個現實案例,都經過一次獨立的事實核驗:先找到官方、一手、司法或監管來源,把這些來源實際確認的事實抽出來,再單獨記錄本書可以用它說明什麼、不可以用它說明什麼。

這份附錄把事實核驗與研究映射同時攤開。它對每個案例回答四個問題:發生了什麼、本書為什麼使用它、它支持到哪裡、去哪裡核驗。

需要先說清楚案例在本書中的地位。

案例不是證明。 案例承擔的是壓力測試、邊界測試、現實背景、反例或有限的支持性證據;它們不證明本書的理論結構正確,十七個已核驗案例的集合也不證明當前結構已經窮盡現實。當前案例池能夠支持的只是一個有限的否定性觀察:在這十七個跨行業的真實失敗中,沒有出現現有五類直接機制族無法表達、因而必須新增並列機制族的情況。這是一個有界負面發現,不是完備性證明。

事實與用法必須分開。 每一條裡,"發生了什麼"只依據官方與一手材料;"本書用它說明什麼"是本書的研究映射。後者不是任何調查機構、法院或監管機構的結論,也不得被讀成它們的結論。反過來,法院、監管機構或官方報告作出的法律與治理判斷,同樣不被改寫成本書的理論結論。

證據判級不是嚴重程度。 下面出現的"強支持 / 部分支持 / 不成立"(Strong / Partial / None)描述的是某個案例對某項分析判斷或機制判斷證據支持到什麼程度,與事故的嚴重性、重要性、風險等級或原因排序無關。

邊界案例單列。 Moffatt v. Air Canada、The DAO 與 Robodebt 三個案例經過同樣的事實核驗,但它們的作用是劃出外邊界——說明哪些相鄰問題不應自動進入這個問題空間。它們不進入十七個案例的強度統計。

最後一條:有些事實,現有權威材料並沒有給出。本附錄在這些位置寫明"未獲來源支持",而不是用通行說法補齊。


一、十七個正式核驗案例

Mars Climate Orbiter|1999

案例狀態:已核驗案例

事件摘要

1999 年 9 月 23 日,NASA 的火星氣候軌道器在執行火星軌道插入時失聯,任務失敗。調查確認的根因是:地面 SM_FORCES 軟件把角動量去飽和推進器的衝量以磅力秒寫入 AMD 文件,而任務接口規範要求該字段使用牛頓秒;導航端依照規範把數值當作牛頓秒使用,因此把推進器作用低估約 4.45 倍。去飽和事件的實際發生頻率比導航團隊預期高 10 至 14 倍,誤差在九個月巡航中持續累積。跟蹤數據中的殘差可以被檢測到,航天器自身也計算並下傳了速度變化數據,但這些線索沒有被及時比較、升級並通過正式異常流程閉環。一次本可用於抬高軌跡的應急機動(TCM-5)在軌道插入前被口頭討論,卻沒有完成分析、測試、程序與明確的執行標準,最終未實施。軌道插入按命令啟動,而航天器當時所處的真實接近軌跡約比計劃低 170 公里。

在本書中的作用

作為核心案例,最清楚地展示表示與語義同物理現實的分離。強支持:變化、判斷與綁定關係的失效、執行狀態與結果關係的失效、放大。部分支持:執行路徑的偏離、執行邊界的失效、因果鏈內證據與證明關係的失效。

它支持什麼

接口規範明確要求使用牛頓秒,導航端按該規範解釋數據,航天器按命令運行,軌道插入也按計劃啟動——這些事實分別成立,仍然不能推出安全入軌。它直接支持"局部正確不等於端到端執行正確"。

它不支持什麼

不支持"所有局部組件和流程都正確":地面軟件違反了接口規範,端到端驗證、跨團隊溝通、人員交接與應急準備均被調查認定存在問題。不支持把它寫成明確的路徑繞過或替換——錯誤主要沿既定的數據鏈傳播,因此本書對執行路徑偏離只保留部分支持,不把它作為本案的主要失效位置。不支持邊界改寫。不支持意圖被替換或被惡意篡改。也不支持用它直接推出關於載荷、簽名、審批或智能體工具調用的一般結論。

航天器最終是在大氣中被毀還是穿過大氣後進入日心空間,調查沒有作出唯一確定;"失聯、任務丟失"是更穩定的表述。

主要來源

  • Mars Climate Orbiter Mishap Investigation Board Phase I Report,NASA MCO Mishap Investigation Board,1999-11-10
  • Report on Project Management in NASA by the Mars Climate Orbiter Mishap Investigation Board(Phase II),2000-03-13 https://discovery.larc.nasa.gov/discovery/PDF_FILES/mars_climate_orbiter_phaseII.pdf
  • NASA Lessons Learned Information System,Lesson 641 / Lesson 916
  • NASA/JPL、NASA Goddard 與 NSSDCA 官方任務資料

Challenger|1986

案例狀態:已核驗案例

事件摘要

1986 年 1 月 28 日,STS-51L 挑戰者號航天飛機在發射後約 73 秒解體,7 名機組成員遇難。物理原因是右側固體火箭助推器後部現場接縫密封失效,高溫燃氣穿過失效密封,破壞了助推器與外部燃料箱的結構連接。事故前的多次飛行中,現場接縫 O 形圈已經出現侵蝕和吹蝕跡象,NASA 與承包商沒有對日益嚴重的密封問題作出充分響應。發射前一晚,Thiokol 最初書面建議在低於既往最低經驗溫度 53°F 時不要發射;管理層複議後改變了建議,部分工程師仍然反對發射。總統調查委員會確認,最終決策者並不知道 O 形圈問題的完整近期歷史,也不知道最初的 No-Go 建議和持續的工程反對意見。發射當日發射場環境約 36°F,右側助推器後部接縫區域更冷。委員會認定發射決策過程存在嚴重缺陷。

在本書中的作用

核心案例,用於說明已知風險證據與最終現實放行之間的關係失效。強支持:變化、判斷與綁定關係的失效、執行狀態與結果關係的失效、因果鏈內證據與證明關係的失效。部分支持:執行邊界的失效、放大。不成立:執行路徑的偏離。

它支持什麼

工程團隊識別了風險、審批流程實際運行、助推器此前多次完成飛行、最終發射獲得組織授權——這些局部事實分別成立,仍然產生了災難性結果。風險被識別,不等於相應風險證據能夠阻止現實放行;授權成立也不能替代當前材料條件成立。

它不支持什麼

不支持"所有工程模塊都正確":接縫設計、風險處理與決策過程均有官方認定的缺陷。不支持路徑偏離——發射沿既定流程發生;安全議題繞過了關鍵管理者,但沒有充分證據證明現實動作改走了另一條執行路徑。不支持邊界改寫。不支持意圖被替換。

另需注意:"異常正常化"不是該委員會的結論,而是後來的社會學解釋框架;"摘下工程師帽子"是聽證證詞中的歷史表述,不能替代委員會的正式結論。

主要來源


Therac-25|1985—1987

案例狀態:已核驗案例

事件摘要

1985 年 6 月至 1987 年 1 月間,Therac-25 醫療直線加速器涉及 6 起已知的嚴重過量照射事故,造成嚴重傷害並涉及死亡。Therac-25 把更多安全職責交給軟件,沒有複製前代設備的全部獨立硬件保護。在 1986 年的 Tyler 事故鏈中,熟練操作員快速編輯模式與能量後觸發競態,界面顯示參數已驗證、機器可用,實際物理配置卻不安全;設備產生 Malfunction 54 這類信息量極低的提示,並允許按 P 繼續。速度是復現該競態的條件,且相關競態在 Therac-20 上同樣存在——但 Therac-20 的獨立硬件聯鎖阻止了危險束流。1987 年的 Yakima 事故來自另一項軟件錯誤,涉及共享變量與計數溢出,與 Tyler 競態不同。事故早期,製造商多次未能復現或否認機器可能造成相應過量,事故信息沒有及時形成跨站點糾正。1987 年 FDA 認定設備有缺陷,最終糾正包括獨立硬件單脈衝關斷、轉盤位置監測與聯鎖,以及軟件和界面變更。

在本書中的作用

核心案例,最清楚地展示軟件局部邏輯與獨立物理拒絕邊界之間的關係。強支持:變化、判斷與綁定關係的失效、執行邊界的失效、執行狀態與結果關係的失效、因果鏈內證據與證明關係的失效。部分支持:執行路徑的偏離、放大。

它支持什麼

輸入被界面接受並顯示為已驗證、多數硬件按控制命令動作、操作員按既有習慣對低信息量錯誤執行繼續——這些都成立,設備仍在錯誤物理配置下發出了高能束流。它最直接支持的是:當同一個軟件域既控制又約束自身時,缺少一個能獨立拒絕危險物理狀態的邊界。

它不支持什麼

不支持把六起事故歸因於同一個競態條件——1987 年 Yakima 是不同的軟件錯誤,部分早期事故的具體代碼原因並不確定;"八秒"來自特定的磁體設置窗口,不是通用閾值。不支持"Therac-25 刪除了所有硬件聯鎖"這一表述,準確的說法是未複製全部既有的獨立保護。死亡與每位患者的最終死因需要逐案表述,不能籠統寫成六人均被機器直接致死。

主要來源

該論文是本案最接近系統性一手技術調查的公開材料,基於 FDA、加拿大監管機構、醫院、製造商文件與事故證言彙編,但不等同於政府統一事故委員會報告。


Ariane 5 Flight 501|1996

案例狀態:已核驗案例

事件摘要

1996 年 6 月 4 日,Ariane 5 首次飛行在升空約 40 秒後偏離航跡、解體,並由機載中和系統銷燬。慣性參考系統中的一段對準功能來自 Ariane 4:它在進入飛行模式後仍繼續運行約 50 秒,用於 Ariane 4 延遲發射後快速重新開始;Ariane 5 並不需要該功能。軟件被複用,其中與 Horizontal Bias 相關的 64 位浮點到 16 位有符號整數轉換沒有受異常保護,因為分析假設數值範圍不會超限。起飛後約 36.7 秒,Ariane 5 更高的水平速度使該值超出 16 位範圍,產生操作數錯誤;備份與主慣性參考系統因相同原因先後停止。活躍單元隨後輸出診斷位模式,飛控計算機把它解釋為飛行數據,發出極端噴管偏轉命令,氣動載荷導致發射器解體。調查委員會把事故定性為規範與設計錯誤,並指出開發評審與測試沒有充分覆蓋完整的慣性單元與閉環飛控——系統測試中用模擬輸出替代了真實單元。

在本書中的作用

核心案例,用於說明環境假設、數值表示、異常語義與驗證證據沒有隨新的現實執行條件重新綁定。強支持:變化、判斷與綁定關係的失效、執行狀態與結果關係的失效、因果鏈內證據與證明關係的失效、放大。部分支持:執行路徑的偏離、執行邊界的失效。

它支持什麼

慣性軟件與其實現一致、主備單元都按同一設計運行、推進系統早期正常、機載中和系統正確觸發——局部都成立,任務仍然損失。它同時是一個關於冗餘的反例:兩套設備構成硬件冗餘,卻因相同軟件和相同數據範圍假設發生共同原因失效。

它不支持什麼

不支持"兩套慣性系統構成真正獨立冗餘"。不支持"所有組件均按正確規範工作"——調查明確指出規範、設計、異常處理和系統測試均存在缺陷。不支持把事故簡化為"代碼複用危險"這一條結論。不支持路徑被繞過或替換。不支持邊界改寫。

另需注意:Horizontal Bias 是與平臺感知水平速度有關的對準結果,不宜直接等同於速度值。

主要來源


Three Mile Island|1979

案例狀態:已核驗案例

事件摘要

1979 年 3 月 28 日,Three Mile Island 二號機組發生部分堆芯熔燬。事故起於主給水系統停止向蒸汽發生器供水,汽輪機與反應堆自動停機。穩壓器頂部的先導式安全閥為降低壓力按設計打開,但在壓力下降後機械卡在開啟位置。控制室的指示讓操作員認為閥門已經關閉——它反映的是關閉命令與控制狀態,而不是閥門的真實機械位置。冷卻劑持續從卡開的閥門流失;與此同時,偏高的穩壓器水位被錯誤解釋為堆芯仍被水覆蓋。隨後冷卻泵因振動被關閉,緊急注水又因擔心穩壓器充滿而被削減,堆芯逐漸裸露並過熱。美國核管會記錄事故沒有造成可歸因的死亡或傷害,場外釋放很小。官方把原因歸為設備故障、設計相關問題與人員錯誤的組合。

在本書中的作用

核心案例,最適合用來區分命令狀態、顯示狀態、推斷狀態與物理狀態這四種不同對象。強支持:變化、判斷與綁定關係的失效、執行狀態與結果關係的失效、因果鏈內證據與證明關係的失效、放大。部分支持:執行路徑的偏離、執行邊界的失效。

它支持什麼

反應堆自動停機、閥門控制邏輯按響應動作、穩壓器水位讀數真實反映穩壓器局部狀態、操作員動作符合其當時的狀態理解——全部成立。它支持兩條否定:命令狀態不等於物理狀態;局部指示不等於系統狀態。

它不支持什麼

不支持"所有儀表都錯誤"。不支持把事故歸結為單一錯誤按鈕、單純的告警洪泛或操作員失誤——官方明確使用組合解釋。不支持路徑繞過、替換或維護旁路。不支持邊界改寫。不支持"事故導致大量公眾死亡"。

主要來源


Knight Capital|2012

案例狀態:已核驗案例

事件摘要

2012 年 8 月 1 日,Knight Capital 在部署新交易功能後激活了舊的 Power Peg 代碼,約 45 分鐘內產生數百萬錯誤訂單,損失約 4.6 億美元。Power Peg 原用於自動發送子訂單;2005 年,累計成交量跟蹤被移到更早的代碼階段,Power Peg 沒有隨之重新測試。2012 年 7 月 27 日起,新的 RLP 代碼分階段部署到 SMARS 的 8 臺服務器,舊 Power Peg 標誌被複用於新功能。部署時一名技術人員漏掉一臺服務器,而當時沒有書面過程要求第二人複核,結果 7 臺運行新代碼、1 臺仍保留舊 Power Peg。開盤前系統發送了 97 封 "Power Peg disabled" 自動郵件,但它們未被設計或審查為系統告警。開盤後,212 個父訂單觸發數百萬子訂單,形成約 400 萬次成交、涉及 154 只股票、超過 3.97 億股。事故處理過程中,公司從 7 臺正確服務器卸載了新 RLP 代碼,使舊 Power Peg 在更多服務器上可被觸發,問題因此加劇。

在本書中的作用

核心案例,也是自動化放大的主案例。這是十七個案例中唯一七個分析項均為強支持的案例:變化、五類直接機制族與放大在本案中都獲得強支持。它呈現了從部署變化、路徑分叉、生命週期綁定失效和執行邊界缺失,到高速自動化放大的連續鏈。

它支持什麼

7 臺服務器獲得了新代碼、父訂單是客戶真實訂單、交易中心正常執行收到的訂單、系統確實產生了 97 封自動郵件——都成立。它支持兩點:集群中局部多數正確,不能證明每個請求進入相同版本;信號存在而未被配置為實時判斷與拒絕的依據時,證據並不控制執行。

它不支持什麼

不支持把事故解釋為單純的"軟件 bug",必須同時包含部署、路徑、狀態綁定、監控與自動邊界缺失。不支持把事故處理描述為"回滾所有服務器"——準確表述是從 7 臺正確節點卸載新代碼,這與正常的安全版本回滾不是一回事。"公司最初認定遭到網絡攻擊"這一說法未獲官方材料支持。

主要來源


Flash Crash|2010

案例狀態:已核驗案例

事件摘要

2010 年 5 月 6 日,美國股票與期貨市場在數分鐘內急跌並快速反彈,個別證券出現極端成交價。當日早些時候市場已承受負面情緒與波動,E-mini 與 SPY 的買方流動性顯著下降。14:32,一家大型基本面交易者啟動賣出 75,000 份 E-mini、約 41 億美元的對沖程序,其算法以前一分鐘成交量的 9% 為目標,不考慮價格或時間;該程序在約 20 分鐘內完成,而同一交易者此前相近規模的執行耗時超過 5 小時。高頻交易者先吸收訂單,隨後為降低庫存主動賣出,合約在自動交易者之間快速來回轉手;成交量上升又反過來推動賣出算法加快。14:41 至 14:45,E-mini 快速下跌,流動性收縮並傳播至 ETF 與股票市場。14:45:28,芝加哥商品交易所的 Stop Logic 暫停 E-mini 交易 5 秒,賣壓隨後緩解。個股市場上多個流動性提供者暫停或撤單,殘留的極端佔位報價發生成交;超過 300 只證券的 20,000 餘筆、偏離超過 60% 的交易後來被取消。

在本書中的作用

輔助案例,最適合用來壓力測試放大這一分析項,而不是作為最清晰的單主體案例。強支持:變化、判斷與綁定關係的失效、執行狀態與結果關係的失效、放大。部分支持:執行邊界的失效、因果鏈內證據與證明關係的失效。不成立:執行路徑的偏離。

它支持什麼

大額交易者有真實對沖目的、賣出算法按設定規則運行、做市與風險系統各自降低敞口、交易所保護機制按設計觸發——都成立。它支持一個特定形態:大量局部合法的策略互動,可以產生沒有任何單一參與者明確意圖的系統級現實結果。

它不支持什麼

不支持"某一個交易者是唯一原因",也不支持把那筆 75,000 份訂單寫成已被官方證明的唯一原因。不支持"所有參與者局部都正確"——成交量算法忽略價格與時間是明確的風險貢獻。不支持路徑偏離,訂單走的是正常撮合與套利路徑。不支持"全部日誌天然完整":監管機構能夠重建大量數據,但調查可重建不等於當時已有實時執行證明。後續針對個別交易者的刑事案件不覆蓋 2010 年聯合報告的系統鏈,也不能被用作唯一根因。

主要來源


Boeing 737 MAX|2018、2019

案例狀態:已核驗案例

事件摘要

2018 年 10 月 29 日的 Lion Air JT610 與 2019 年 3 月 10 日的 Ethiopian Airlines ET302 兩起 737 MAX 8 空難,分別造成 189 人與 157 人遇難,合計 346 人。MCAS 被加入飛控,功能在開發中擴展到低馬赫條件,權限和運行範圍隨之變化;原設計每次依賴兩隻迎角傳感器之一。原安全評估沒有充分包含同一迎角故障引發的多個告警與指示,也沒有充分包含重複激活對機組反應的影響。JT610 前,更換的左迎角傳感器存在錯誤校準;已有的安裝測試若正確完成本應發現問題,調查無法確認該測試得到正確執行。錯誤的單一迎角數據觸發重複的 MCAS 低頭配平;飛行員使用電動配平後,原邏輯可在持續高迎角信號下重置並於數秒後再次激活,多次增量命令累積成顯著的安定面失配,同時出現抖杆、速度與高度不一致等複雜提示。復飛整改後,新設計比較兩側迎角,差異超過閾值時禁用相關功能,每個高迎角事件只允許一次激活,並限制了配平權限。

在本書中的作用

核心案例,最清楚地展示輸入來源資格與其被賦予的控制作用之間的不匹配。強支持:變化、判斷與綁定關係的失效、執行邊界的失效、執行狀態與結果關係的失效、因果鏈內證據與證明關係的失效、放大。部分支持:執行路徑的偏離。

它支持什麼

傳感器按接口提供數值、MCAS 按原控制律響應選定輸入、飛行員能用電動配平暫時反向輸入、認證過程完成了既有的分析與合規活動——都成立。它支持的是:一個輸入來源被賦予了超出其資格所能支撐範圍的控制作用,而系統中存在兩隻傳感器這一事實本身,並不自動建立獨立、正交的驗證。

它不支持什麼

不支持把兩起事故寫成完全相同的因果鏈——它們共享關鍵結構,但維護、告警、機組動作與事故細節不同。不支持把 MCAS 描述為擁有獨立意圖的主體。不支持"軟件在任何條件下絕對取消全部人工控制"這類表述;準確說法是多次命令可形成僅靠升降舵難以抵消的安定面失配。不支持"復飛後用兩個傳感器就實現了正交驗證"——兩隻同類傳感器不自動證明理論上的正交獨立。不支持邊界改寫:事故鏈顯示的是設計時邊界不足,沒有證據表明飛行中某個原本有效的邊界被動態改寫。不支持任何單一因素是兩起事故的唯一原因。

主要來源


AWS S3 US-EAST-1 服務中斷|2017

案例狀態:已核驗案例

事件摘要

2017 年 2 月 28 日,Amazon S3 在北弗吉尼亞區域發生服務中斷。S3 團隊當時正在排查計費系統處理變慢的問題。09:37(太平洋時間),一名獲授權的團隊成員依既有操作手冊執行命令,目標是從一個計費相關子系統移除少量服務器。該命令的一項輸入填寫錯誤,導致被移除的服務器數量大於意圖數量;被移除的容量同時支撐 index 與 placement 兩個子系統。兩個子系統需要完整重啟,S3 API 及依賴 S3 的其他服務因此受到影響。AWS 認定當時的工具允許過多容量被過快移除,隨後加入了最低容量保護、減慢移除速度並縮小故障域。恢復時間還受到另一個因素影響:該區域規模增長後,相關大型子系統多年未完整重啟,重啟與元數據完整性檢查耗時超出預期。

在本書中的作用

已核驗案例,用於說明合法主體經由正常路徑實施了與其具體意圖範圍不一致的現實動作。強支持:變化、判斷與綁定關係的失效、執行邊界的失效、執行狀態與結果關係的失效、放大。部分支持:因果鏈內證據與證明關係的失效。不成立:執行路徑的偏離。

它支持什麼

操作人員身份獲授權、使用的是既有手冊與正常生產工具、命令按輸入執行、恢復流程最終恢復服務——都成立。它支持一條很乾淨的否定:獲授權的操作者加上有效的工具路徑,不等於正確的具體生產動作。它同時說明,這類失敗不要求惡意、不要求人工智能參與,也不要求災難性的永久損失。

它不支持什麼

不支持"一個拼寫錯誤搞垮互聯網"這類描述——官方只確認了一個輸入錯誤,並未把它限定為特定的鍵盤拼寫錯誤。不支持未授權人員或繞過正常工具的說法。不支持把全部恢復延遲歸於移除動作本身。不支持"數據永久丟失"——官方說明的核心後果是服務不可用與積壓恢復。不支持路徑偏離。不支持邊界改寫:這是執行範圍邊界的缺失。

需要注意來源性質:AWS 是事件責任方,其說明屬於一手自述,不是獨立調查;未公開的審批、命令與內部日誌不得推測。

主要來源


Citibank–Revlon 誤付款|2020

案例狀態:已核驗案例

事件摘要

2020 年 8 月 11 日,Citibank 作為貸款代理,原擬處理約 780 萬美元利息,併為 Revlon 的貸款結構調整進行內部賬務處理。在 Flexcube 系統中,最易或可能唯一的處理方式,是把交易錄入為全額償還,同時通過內部 wash account 留住本金。執行人員需要選中 FRONT、FUND、PRINCIPAL 三個界面選項,但只選中了 PRINCIPAL;兩名複核人員也沒有發現該錯誤。系統因而把接近 10 億美元的 Citibank 自有資金實際匯給了 2016 Term Lenders,而不是完成內部轉賬。債權人收到的結算單隻顯示應計利息,實際電匯金額卻高出百倍以上,他們也沒有收到提前還本所需的通知。Citibank 次日發出召回通知,部分收款人返還,部分拒絕。美國第二巡迴上訴法院最終撤銷了使拒絕返還方勝訴的一審判決。

在本書中的作用

已核驗案例,用於說明合法工作資格、正常工具與兩級確認都不能替代對本次具體金額、賬戶與付款結果的端到端綁定。強支持:變化、判斷與綁定關係的失效、執行邊界的失效、執行狀態與結果關係的失效、因果鏈內證據與證明關係的失效。部分支持:放大。不成立:執行路徑的偏離。

它支持什麼

相關人員具有實際工作職責、兩級複核確實發生、系統與電匯通道按錄入字段完成付款、債權人賬戶確實收到資金——都成立。它支持的是:一個被批准的工作流,不等於一次被正確綁定的付款;複核存在,不保證複核對象包含了最終的資金流向與金額語義。

它不支持什麼

不支持"一個員工按錯一個按鈕"這種壓縮——法院記錄的是三個選框的配置、特定的內部賬戶工作流,以及兩名複核者未發現錯誤。不支持"花旗白送 9 億美元且永遠無法追回"——部分資金很快返還,且上訴審撤銷了關鍵的一審結論。不支持把"系統按字段執行"讀成交易具有業務授權:技術可執行性、內部審批與客戶實際意圖不是同一事實。不支持把法院關於 discharge-for-value 規則的法律分析當作系統事故的根因。不支持路徑偏離。

主要來源


夏威夷彈道導彈誤報|2018

案例狀態:已核驗案例

事件摘要

2018 年 1 月 13 日,夏威夷緊急事務管理局發出錯誤的彈道導彈警報。當時組織意圖是進行內部演練。演練錄音的開頭和結尾包含 "Exercise, Exercise, Exercise",中間卻出現 "This is not a drill";一名值班人員相信威脅真實,其他人員則理解為演練。該人員在警報軟件的下拉菜單中選擇了真實警報模板,並在確認提示後發出了全州 EAS / WEA 消息。當時真實模板與測試模板位於同一界面、使用相同登錄憑證,真實導彈警報只需一名有憑證的值班人員即可發出。約 08:12 的取消操作只能停止後續轉發,不能撤回已顯示的消息,也不會自動生成解除警報通知。該機構沒有準備好的假警報更正協議或模板,直到 08:45 才通過同一渠道發出更正,距初始警報 38 分鐘。聯邦通信委員會認定,人類錯誤與不充分的保障措施共同造成了誤報和更正延遲。

在本書中的作用

已核驗案例,屬於非災難性正例。強支持:變化、判斷與綁定關係的失效、執行邊界的失效、執行狀態與結果關係的失效、因果鏈內證據與證明關係的失效、放大。部分支持:執行路徑的偏離。

它支持什麼

發起人擁有警報憑證、軟件按所選模板發送、傳輸提供商大體在秒級轉發、警報內容作為真實消息被忠實傳播——都成立。它支持兩點:合法的權限與可靠的傳播機制,可以把一次錯誤的事實判斷精確地變成現實公共動作;以及,恢復與更正是一條獨立的執行鏈,不是原動作的自動逆轉。

它不支持什麼

不支持"按錯按鈕"這一歸因——官方認定包括混合的演練腳本、主管溝通與監督不足、測試與生產界面未隔離、單人即可發送,以及更正協議缺失。不支持觸發者明知是演練卻誤發:官方記錄其相信威脅真實。不支持"38 分鐘內完全沒有澄清"——08:20 起已有社交媒體信息,但正式的同渠道更正確實到 08:45 才發出。不支持把取消操作等同於撤回已到達設備的警報。不支持傳播網絡被繞過——它恰好正常工作。

主要來源

該報告引用並比較了機構內部調查、演練錄音與訪談;其中來源之間的差異已在報告中說明,本附錄不消除這些差異。


Waymo 電線杆碰撞與召回|2024

案例狀態:已核驗案例

事件摘要

2024 年 5 月 21 日,一輛 Waymo 無人車在鳳凰城的一條巷道中執行低速靠邊動作時撞上一根木製電線杆。車內無乘客,沒有其他道路使用者捲入,無人受傷,車輛受損。製造商向監管機構提交的召回報告列出的觸發條件要求多個事實同時成立:一根永久性桿狀物位於道路範圍內;地圖沒有在該物體與可行駛面之間標記硬性道路邊緣;感知為該物體賦予了較低的損害評分;物體位於自動駕駛系統的預定路徑內;附近沒有會觸發規避的其他對象。召回覆蓋 672 套受影響設備,處置方式為軟件與地圖更新,所有受影響車輛在 2024 年 6 月 6 日前完成更新。

在本書中的作用

已核驗案例,屬於低損失正例,用於支持一個有限的否定結論:災難規模不是這類失敗成立的必要條件。強支持:變化、判斷與綁定關係的失效、執行狀態與結果關係的失效。部分支持:執行邊界的失效、因果鏈內證據與證明關係的失效。不成立:執行路徑的偏離、放大。

它同時是關於放大的關鍵反例:在沒有明顯放大的情況下,本案仍然成立。這直接說明放大不是必要條件。

它支持什麼

車輛確實在執行設計支持的低速靠邊動作,地圖、感知與規劃都參與了正常鏈路,碰撞條件可被明確列出。它支持的是:一個合法的動作目標,不等於一條安全的物理軌跡。它還反向約束了執行路徑這一分析項——預定路徑本身內容錯誤,不等於路徑偏離。

它不支持什麼

不支持"Waymo 看不見電線杆"這種說法——報告給出的是多個條件的組合,未聲明完全沒有感知。不支持把它寫成大規模事故:672 是受影響設備範圍,不是事故數,報告只列出一宗相關碰撞。不支持把更新完成日期當作事故日期或監管認定日期。不支持把製造商的召回描述當作監管機構已獨立完成的技術根因認定。

公開報告未給出原因說明,也未提供"哪一個算法模塊根本正確"的獨立驗證;不能把多條件的組合縮成單一的感知故障。

主要來源

該文件具有監管申報性質,但核心技術描述由製造商提供,不能當作獨立事故調查結論。


CrowdStrike Channel File 291|2024

案例狀態:已核驗案例

事件摘要

2024 年 7 月 19 日,CrowdStrike Falcon 的一次內容更新導致大量 Windows 系統崩潰。Falcon 傳感器通過 Channel Files 接收 Rapid Response Content,這是配置內容,不是新的內核驅動代碼。2024 年 2 月引入的一個模板類型定義了 21 個輸入字段,但傳感器的集成代碼只向內容解釋器提供 20 個輸入。此前的測試與最初部署在第 21 個字段上使用通配符,因此沒有觸發潛在的越界讀取。7 月 19 日部署的新模板實例在第 21 個字段使用了非通配符條件,內容驗證器按其自身的 21 輸入模型判定通過;終端隨後嘗試讀取不存在的第 21 個輸入,造成越界讀取和系統崩潰。後續改進包括編譯期字段數校驗、運行時數組邊界檢查、每個字段的非通配符測試、分階段部署與客戶部署控制。美國政府問責局把該事件概述為影響數百萬 Windows 系統、干擾航班與醫院服務的廣泛中斷,並未將其認定為網絡攻擊。

在本書中的作用

已核驗案例,是軟件化放大的最強樣本之一。強支持:變化、判斷與綁定關係的失效、執行邊界的失效、執行狀態與結果關係的失效、因果鏈內證據與證明關係的失效、放大。部分支持:執行路徑的偏離。

它支持什麼

內容由正式系統生成、驗證和發佈,早期的通配符實例確實成功運行,這次更新也不是一次傳感器代碼升級——都成立。它支持的是:驗證器的"通過"只證明內容符合它自己的輸入模型,沒有證明傳感器在運行時實際具備同一契約;而初期部署成功,不是當前新匹配條件安全的證據。

它不支持什麼

不支持"推送了有 bug 的內核驅動更新"這一描述——觸發載荷是配置內容,潛在的越界讀取存在於解釋器代碼中。不支持把它稱為網絡攻擊。不支持"驗證完全沒有發生":發生了多層驗證和測試,但它們共享同一個錯誤的輸入數假設,並未覆蓋第 21 字段的非通配符條件。不支持把"99% 傳感器恢復"讀成每個受影響業務已完全恢復——那是以周同比連接數給出的指標。不支持把高速內容路徑寫成攻擊者繞過發佈路徑。

來源性質需注意:技術細節主要來自事件方自述,本案不存在獨立監管根因認定。

主要來源


Cruise 行人拖行與事故報告|2023

案例狀態:已核驗案例

事件摘要

2023 年 10 月 2 日,一輛肇事逃逸的人類駕駛車輛先撞到一名行人,把行人拋入相鄰的 Cruise 無人車路徑。Cruise 車輛制動但未能避免碰撞,行人落到車底。車輛初次停車後又恢復移動,拖行約 20 英尺後最終停止。司法部的暫緩起訴協議說明,檢測系統沒有檢測到車底行人,因此車輛嘗試靠邊。Cruise 在 10 月 3 日與 10 月 11 日提交的法定報告敘述中,沒有寫明初次停止後的移動和拖行,直到 11 月 3 日的更新報告才首次敘述。值得注意的是,Cruise 在提交首份報告之前已經向監管機構提供了包含完整過程的視頻,監管機構仍認定書面敘述遺漏了公司已知的重要事實。監管機構的同意令包含 150 萬美元民事罰款與糾正行動,司法部的協議針對虛假報告另約定 50 萬美元刑事罰金及合規義務。

在本書中的作用

已核驗案例,提供了一個雙鏈結構:錯誤的碰撞後動作與不完整的證據分別影響現實傷害與後續判斷。強支持:變化、判斷與綁定關係的失效、執行邊界的失效、執行狀態與結果關係的失效、因果鏈內證據與證明關係的失效。部分支持:執行路徑的偏離、放大。

它也是"證據反過來影響後續權威"這一候選形態的主要案例之一。當前材料把它解釋為現有機制關係在多個輪次上的重複連接,而不是一個新的直接失效機制族。

它支持什麼

首次制動與停車發生、靠邊是系統可調用的既有動作、視頻真實包含完整事故、報告按規定渠道提交——都成立。它支持兩條否定:碰撞後的"已經停止"不是安全終態;證據存在,不等於法定報告完整——證據的內容、載體、接收方式與權威的決策對象必須分開。

它不支持什麼

不支持把 Cruise 車輛寫成首先撞擊行人的車輛。不支持"Cruise 從未提供拖行視頻"——完整視頻在首份報告前已提供,問題是兩份法定書面敘述仍遺漏了重要動作。不支持把"技術故障導致公司掩蓋"混成一條責任鏈:車輛的碰撞後動作與公司的報告行為需要分別核驗。不支持報告倒過來造成了已經發生的拖行。

拖行速度、系統內部的模型推理過程與全部溝通過程,當前官方資料未給出,不得補寫。

主要來源


Storm-0558 Exchange Online 入侵|2023

案例狀態:已核驗案例

事件摘要

2023 年 5 月至 6 月間,攻擊組織 Storm-0558 獲得了微軟 2016 年的 MSA consumer token 簽名密鑰,並用它偽造了訪問 Exchange Online 的令牌。該密鑰原本只應簽署面向消費者服務可用的令牌,不應為企業級 Exchange Online 建立資格——消費者與企業密鑰來自分離的提供方與系統。但 Exchange Online 的令牌驗證邏輯存在缺陷:未編碼拒絕該類密鑰的企業賬戶,可能接受這些令牌。微軟最終認定 22 個企業組織與 503 個相關個人賬戶受到訪問。發現後,微軟清理了下游緩存並使由該密鑰派生的憑據失效,攻擊者隨即轉向釣魚。美國國土安全部網絡安全審查委員會完成審查時,微軟仍不能證明攻擊者是如何獲得該簽名密鑰的。

在本書中的作用

已核驗案例,用於說明局部的密碼學有效性與現實訪問資格之間的分離。強支持:變化、判斷與綁定關係的失效、執行邊界的失效、執行狀態與結果關係的失效、因果鏈內證據與證明關係的失效、放大。部分支持:執行路徑的偏離。

它也是"資格跨組織傳播"這一形態的主要案例之一,該形態被判定為跨域綁定關係加邊界的組合,不是新的失效類型。

它支持什麼

令牌的密碼學簽名可被驗證、雲服務的正常令牌接受路徑正常工作、被訪問的是實際郵箱賬戶——都成立。它支持的是:簽名可以被驗證,只證明該令牌能由那把密鑰驗證,不證明這把密鑰對當前的企業租戶、賬戶和時刻具有相應資格。

它不支持什麼

不支持"攻擊者破解了微軟的密碼學"。不支持把密鑰來源寫成崩潰轉儲——審查委員會明確指出微軟仍無法證明密鑰如何取得,早期假說不是已確認事實。不支持"消費者令牌天然可訪問企業服務"——還需要驗證邏輯未拒絕該密鑰類型這一條件。不支持"所有微軟客戶被攻破"。不支持把它寫成典型的步驟跳過:攻擊使用的是正常的令牌驗證與郵件訪問路徑。

CSRB 在審查報告中明確指出,微軟尚未確定攻擊者如何獲得該簽名密鑰,這是一個必須保留的證據缺口。

主要來源


SolarWinds Orion 供應鏈入侵|2019—2020

案例狀態:已核驗案例

事件摘要

威脅主體先進入 SolarWinds 的環境並進行測試性代碼植入,隨後從 2020 年 2 月起把惡意代碼加入後來進入 Orion 更新的文件。SolarWinds 在不知情的情況下發布了這些版本,客戶通過正常的軟件更新渠道下載和安裝。惡意文件在安裝後休眠約兩週,再收集環境信息、與攻擊者基礎設施通信,並由攻擊者選擇較小的目標子集進行進一步的命令控制與附加惡意軟件安裝。SolarWinds 估計接近 18,000 名客戶收到了受汙染的更新。事件於 2020 年 12 月公開披露後,美國網絡安全和基礎設施安全局指示聯邦機構斷開受影響的 Orion 產品、保存取證數據並進行重建。

在本書中的作用

已核驗案例,變化、五類直接機制族與放大這七個分析項均為強支持,也是第二批案例中對執行路徑偏離支持最明確的正例。

它支持什麼

客戶使用的是真實產品和正常更新通道、安裝動作由其系統接受、供應鏈分發與軟件執行正常運轉——都成立。它支持的是:客戶接受的是供應商資格、簽名與標準更新通道,而實際載荷的來源和行為已經發生變化;跨組織的信任把供應商內部的載荷資格,擴展成了客戶環境中的高權限執行。

它不支持什麼

不支持"約 18,000 客戶全部被深度控制"——該數字指收到受汙染更新的客戶數,後續的選擇性利用是較小的子集。不支持把"有效簽名"表述為安全或授權結論:它最多證明發布工件滿足既有的簽名驗證關係。不支持把客戶的更新行為說成繞過了自身的正常流程——核心危險恰恰是惡意載荷借正常供應鏈資格進入。不支持"單一後門文件自動黑入所有客戶"這種單階段敘事:官方材料描述的是多階段攻擊鏈。

主要來源


Post Office Horizon|2000 年後

案例狀態:已核驗案例

事件摘要

英國高等法院在 2019 年的判決中認定,Horizon 系統存在多項缺陷,能夠並且確實造成了分支賬戶短缺,削弱了系統準確處理和記錄交易的可靠性。法院記錄了 25 個可能影響分支賬戶的問題,其中 22 個有實際持續影響的證據;而 Horizon 本身不會向分支經營者提示這些問題。郵政公司長期堅持 Horizon 可靠,未充分考慮與其立場相反的事實與專家證據。2021 年,上訴法院處理 42 名被告的上訴,最終撤銷其中 39 人的定罪,認定相關案件中的調查與披露失敗使審判不公,部分案件構成對司法的冒犯。這些人曾因系統呈現的賬面短缺被追責,現實後果包括還款、破產、失去工作、刑罰與社會損害;並非每一案的事實與法律理由完全相同。截至 2026 年 7 月 8 日,公開調查僅發佈了最終報告第一卷,聚焦人員影響與補償;主席確認其餘五卷仍在準備中,尚未發佈。

在本書中的作用

已核驗案例,是長期制度性案例,用於檢驗證據如何進入後續判斷並反覆推動現實動作。強支持:變化、判斷與綁定關係的失效、執行邊界的失效、執行狀態與結果關係的失效、因果鏈內證據與證明關係的失效、放大。部分支持:執行路徑的偏離。

它與 Cruise 一起構成"證據反過來影響後續權威"這一跨輪次候選形態的主要材料;當前分析可以用現有機制關係在多個輪次上的重複連接表達它,不需要新增直接機制族。

它支持什麼

交易記錄、系統報表、合同與調查訴訟流程都真實存在並被實際使用——都成立。它支持一條三段式的否定:系統記錄的短缺,不等於已證明的現實損失,更不等於已證明的個人不誠實。

它不支持什麼

不支持把整件事歸因於一個缺陷——法院識別的是多項問題、不同分支和不同案件。不支持"每一筆短缺都是系統虛構",也不支持"每一名被定罪者的事實完全相同"。不支持"系統記錄沒有任何證據價值"——正確的結論是,在缺少獨立核驗與充分披露時,它不能自動證明現實損失與個人不誠實。不支持把所有案件歸於單一的繞過路徑。

截至 2026 年 7 月 8 日,公開調查其餘五卷最終報告尚未發佈,不得將其寫成已經完成的認定。

主要來源


二、三個邊界案例

下面三個案例經過與正式案例相同的事實核驗,但承擔的作用不同。

它們不是用來增加執行縫隙的正例數量,而是用來檢查這個概念的外邊界:哪些問題雖然能夠產生真實後果,也與信息、自動化、代碼或制度有關,卻不能僅憑這些事實就自動被納入執行縫隙。

因此,這三個案例不進入十七個正式核驗案例的證據強度統計。

它們共同承擔一個作用:

防止“執行縫隙”逐漸膨脹成“所有壞結果”的另一個名字。

Moffatt v. Air Canada|2022 事實 / 2024 裁決

案例狀態:邊界案例(不佔用案例編號)

事件摘要

2022 年 11 月,Jake Moffatt 在親屬去世後查詢 Air Canada 的喪親票價。航空公司網站上的聊天機器人表示,已經旅行的乘客可以在票據簽發後 90 天內申請較低的喪親票價;而它所鏈接的正式網頁說明,旅行完成後不能再申請該票價。

Moffatt 依據信息購買普通機票、完成旅行,並在 90 天內提出申請。Air Canada 隨後拒絕追溯適用喪親票價。

不列顛哥倫比亞省民事解決法庭認定,Air Canada 對其網站提供的信息承擔責任,並認為其未採取合理注意確保聊天機器人信息準確,構成過失性錯誤陳述。法庭判給 Moffatt 650.88 加元損害賠償,另有利息與費用。

在本書中的作用

這是一個關於信息影響與現實執行之間邊界的案例。

本案存在一條完整的現實因果鏈:

錯誤表示 → 人的判斷 → 人的行動 → 現實結果。

但現有材料沒有顯示聊天機器人直接完成購票、扣款、出票或退款。現實購票行為仍然由人實施。

因此,本案用來區分兩件事:

一個信息系統能夠影響現實行動,

與

這個信息系統自身直接實施現實動作。

兩者不能自動等同。

它支持什麼

本案支持:錯誤的信息表示可以影響人的判斷,並通過人的後續行動產生現實後果。

它也說明,組織不能僅因為錯誤信息由聊天機器人產生,就把該信息視為與自身無關;這是本案裁決中的責任判斷。

對本書而言,更重要的是下面這條邊界:

參與現實因果鏈,不等於自身實施現實執行。

它不支持什麼

本案不支持把“信息系統影響了人的決定”自動解釋成“信息系統自身執行了現實動作”。

裁決沒有認定該聊天機器人屬於大語言模型、生成式模型或自主智能體,也沒有證據說明它直接調用購票工具、實施扣款、完成出票或授予喪親票價。

因此,不能僅因為案件中同時出現了“聊天機器人”和“現實損失”,就把它描述成 AI Agent 自主執行錯誤動作的案例。

同樣,最終產生損失也不足以單獨證明執行側發生了本書所討論的偏離。

本案裁決處理的是錯誤表示及其造成的損害,而不是要求航空公司追溯適用原票價政策。單一案件也不能支持關於類似聊天機器人損失普遍性的結論。

主要來源


The DAO|2016

案例狀態:邊界案例(不佔用案例編號)

事件摘要

The DAO 通過出售代幣籌集約 1,200 萬 ETH,目標是由代幣持有人對項目融資提案進行投票。

2016 年 6 月 17 日,攻擊者利用 The DAO 代碼中的缺陷,把約 360 萬 ETH——約佔募集資產的三分之一——轉到其控制的地址。代碼規定這些資產在 27 天內不能從該地址繼續移動,為社區應對保留了時間。

社區隨後提出並採用硬分叉。7 月 20 日,新鏈把相關資金轉入恢復地址,代幣持有人可以兌換 ETH。少數參與者沒有采用新鏈,繼續運行原有鏈,即後來的 Ethereum Classic。

美國證券交易委員會在調查報告中同時強調,通過智能合約實現自動化,並不會使相關行為脫離現行證券法。

在本書中的作用

本案用於檢查一個非常容易混淆的邊界:

現實結果在規範、治理或法律意義上不被接受,是否就意味著執行本身發生了偏離?

The DAO 的困難在於,這裡存在多個不同的參照對象:

代碼實際允許什麼;

攻擊者想做什麼;

設計者原本希望系統實現什麼;

投資者認為資金應當如何使用;

社區後來決定接受什麼狀態。

這些對象不能被壓縮成一個統一的“意圖”。

它支持什麼

本案支持把幾個對象分開:

  • 協議實際執行了什麼;
  • 攻擊者希望發生什麼;
  • 代碼設計者原本希望發生什麼;
  • 投資者參與 The DAO 的目的是什麼;
  • 社區後來決定如何處理已經發生的狀態變化。

原鏈上的記錄能夠證明相應狀態變化確實發生,但它不能僅憑這一事實回答:這種狀態在規範、治理或法律上是否應當被接受。

後續硬分叉同樣是一項新的治理與執行行為。它改變了後續被接受的鏈狀態,卻不能反向證明原來的資產轉移從未發生。

它不支持什麼

本案不支持下面這個推論:

一個現實結果在規範上不可接受,因此一定發生了執行縫隙。

從攻擊者此次具體動作來看,其有意實施相應調用,協議隨後產生了與這些調用相對應的狀態變化。

因此,僅從“攻擊者的具體調用”與“協議產生的狀態變化”之間觀察,並不能得到一個簡單的“已經成立的上游對象在執行中被變形”的結構。

真正困難的是:究竟以誰的意圖、決定或其他已經成立的上游對象作為偏差參照。

如果不先回答這個問題,任何漏洞利用、違法行為或違反治理期待的結果,都可能僅憑其不可接受性被重新描述成執行偏離。

這會使執行縫隙失去邊界。

因此,本案在這裡的作用不是證明“代碼即法律”,也不是證明協議執行沒有問題,而是說明:

規範上不可接受,與執行相對於既定參照發生偏離,是兩個不同的問題。

其他限制同樣需要保留:

不支持“攻擊者轉走了全部資金”;不支持“資金立即可以自由轉走”,因為合約存在 27 天限制;也不支持把硬分叉描述成由單一機構獨自決定,當時的公開說明明確把它作為社區選擇,且部分參與者繼續運行原鏈。

主要來源


Robodebt|2015 年起

案例狀態:邊界案例(不佔用案例編號)

事件摘要

澳大利亞 Robodebt 計劃使用僱主報送稅務機關的期間收入,把年度或期間總額平均為兩週金額,再據此與福利領取者自己報告的收入進行比較,並形成債務認定與追繳。

對於兼職和臨時工作者,實際兩週收入可能發生變化,因此平均值並不等於每一個具體兩週期間的真實收入。

舊流程會由合規人員對高風險差異進行人工調查,並可進一步向個人和僱主取證;Robodebt 流程則把解釋差異的責任更多轉移給領取者。

現有材料表明,該計劃並未獲得以平均法直接證明實際兩週收入的普遍法律基礎,除極少數最後手段情形外,以此直接形成債務的證據基礎不足。2014 年的內部法律意見已經指出,需要依據實際兩週收入,平均法與既有法律框架存在問題,但計劃仍在沒有相應立法改變的情況下推進。

多項行政上訴裁判所的一審決定也曾質疑或否定平均法的法律與證據基礎,但由於這些決定沒有形成充分公開和系統反饋,未能有效阻斷相關做法。

皇家委員會後來提出多項關於自動化決策的建議,包括建立清楚的複審路徑、披露自動化使用方式、公開業務規則與算法以供獨立審查,以及建立相應的監測與審計機制。

在本書中的作用

這是本書最重要的外邊界案例之一。

它迫使我們區分:

一個上游決定、規則或資格判斷本身存在法律、規範或證據基礎問題,

與

一個已經成立的上游對象在後續執行過程中發生偏離。

就計劃整體而言,Robodebt 更接近前一種情況。

系統大規模執行了一個本身存在法律與證據基礎問題的規則。現實後果非常嚴重,但嚴重後果本身不能告訴我們,問題究竟首先發生在上游決定,還是發生在執行相對於該決定的偏離。

它支持什麼

本案支持把代理數據與被代理的現實事實分開。

平均後的期間收入是一種代理表示,它並不自動等於每一個具體兩週期間的真實收入。系統卻將這種代理值用於後續債務判斷與追繳,因此暴露出了數據、事實、判斷與現實動作之間需要分別建立關係的問題。

本案也支持一個關於自動化規模的觀察:

自動化能夠擴大一個既有決定規則的執行速度和覆蓋範圍,卻不會因為執行得更快、更一致,就自動使該規則變得合法、證據充分或規範上正確。

另外,不公開或無法形成系統反饋的個案複審結果,也可能使已經受到質疑的規則繼續作用於後續案件。

它不支持什麼

本案最重要的限制是:

一個錯誤、違法或規範上不可接受的上游決定,被後續系統忠實執行,不能僅憑最終結果嚴重就自動被重新描述成“執行偏離了該決定”。

如果系統做的正是上游規則要求它做的事情,那麼問題首先仍然位於上游規則、決定及其事實與法律基礎。

這並不表示具體個人案件中絕不可能同時發生判斷與綁定、證據或其他執行關係失效。

但當前研究在這裡討論的是 Robodebt 計劃整體,並沒有完成所有個人案件的逐案執行鏈核驗。因此,不能根據“某些個案可能還存在獨立執行偏離”這一可能性,把整個計劃登記成執行縫隙的正式正例。

其他限制同樣需要保留:

不支持“算法自主發明了債務”;計劃來自明確的政策與行政決定。

不支持“所有數據都是假的”;問題在於期間總額或平均值不足以直接證明每一個具體兩週期間的真實收入。

不支持把自動化寫成唯一原因,也不支持把所有個案壓縮成完全相同的計算鏈和損害結果。

主要來源


三、案例池與聯合強度分佈

候選與裁決

批次候選已核驗案例邊界案例未通過
第一批8800
第二批12930
合計201730

第二批相對第一批有意擴大了樣本類型,加入了雲運維、支付、公共預警、低損失的無人駕駛事故、自動更新、聊天機器人、雲身份、軟件供應鏈、智能合約、政府自動決策與制度性證據案例,使樣本不再主要依賴經典工程災難。

十七個已核驗案例的聯合強度分佈

下面這組數字直接引用聯合審計中已經凍結的結果,不是本附錄重新統計的。

分析項強支持部分支持不成立合計
判斷與綁定關係的失效170017
執行路徑的偏離210517
執行邊界的失效116017
執行狀態與結果關係的失效170017
因果鏈內證據與證明關係的失效134017
放大124117
變化170017

這組數字說明什麼

三個滿覆蓋的分析項含義不同,不應合併。 變化用於識別對象、狀態、表示、規則或環境發生了什麼不同,它是分析入口,不是直接機制;判斷與綁定關係的失效關注已經成立的上游對象與當前具體動作之間的對應關係是否繼續成立;執行狀態與結果關係的失效則關注提交、調用、執行狀態、回執、外部狀態與業務結果是否被錯誤壓縮、對應或解釋。三項都具有滿覆蓋,不意味著它們可以合併成一個寬泛的"系統出錯"標籤。

執行路徑的偏離是覆蓋最低的分析項,而這正是它的價值。 十七案中只有 Knight Capital 與 SolarWinds 為強支持,10 案僅部分支持,5 案不成立。低覆蓋防止了對路徑概念的泛化——"最終軌跡錯誤""參數錯誤沿正常鏈傳播""驗證器錯誤批准內容""合法令牌被錯誤接受",本身都不足以建立執行路徑偏離。AWS、Citibank 與 Waymo 明確顯示了正常路徑同樣可以承載錯誤動作。

放大有一個明確的反例。 十七案中有一案(Waymo)在這一分析項上不成立,這直接說明放大不是必要條件。

執行邊界必須繼續分辨不同失效形態:邊界缺失;約束對象不完整;已有邊界無法阻止現實動作;邊界規則或實施結構被改寫。第二批多數案例屬於前三類——執行邊界失效獲得強支持,不等於發生了邊界改寫。

證據必須按因果位置區分。 在執行前,錯誤的驗證或簽名資格可以推動動作;在執行後,事實記錄只有在重新進入下一輪判斷、恢復、追責或現實動作時,才重新進入本書關心的因果鏈;代理數據被當作決定事實,則屬於另一種關係問題。這些差異決定證據問題是否進入執行縫隙,而不能把所有事後可調查性或證明能力損失都納入。

三個被主動檢驗的候選形態

研究過程中有三個候選形態看上去可能要求增加新的直接機制族,但當前材料都沒有支持這一升級:

證據反過來影響權威(Cruise、Post Office Horizon;Robodebt 提供旁證)。反饋循環真實存在,但當前材料可以把它表達為現有機制關係在多個輪次上的重複連接,沒有要求新增直接機制族。

資格跨組織傳播(Storm-0558、SolarWinds)。這是跨域的綁定關係加邊界加放大的組合。兩案的具體資格對象並不相同——前者是密鑰、簽發域、租戶與賬戶範圍,後者是供應商、發佈、載荷與客戶安裝權——共同的表面形態不應掩蓋關係對象的差異。

規範上無效或不可接受的決定被後續系統忠實執行(The DAO、Robodebt)。這不是一個新的直接機制,而是判定一個事件是否進入執行縫隙問題空間之前必須先回答的問題。

在十七個正式核驗案例中,沒有出現必須增加與現有五類直接機制族並列的新機制族的證據。這個結論只覆蓋當前案例池:它表示當前材料沒有要求增加結構,不表示現有結構已經完備。


四、證據限制

最後把幾條最容易被越過的限制集中列出。

判級不是嚴重度。 強支持、部分支持、不成立描述的是證據支持程度。它們不是嚴重程度、不是重要性、不是風險等級、不是事故等級、不是原因排序,也不是機制優先級。

案例不是證明。 案例承擔的是壓力測試、邊界測試、現實背景、反例或有限的支持性證據。"這個案例證明了理論正確"不是本書使用案例的方式。十七個案例也不證明當前結構已經窮盡現實。

不從後果反推。 結果嚴重、不可接受或違法,都不足以單獨判定一次失敗屬於這個問題空間。必須先指出哪個已經成立的上游對象構成偏差參照,以及現實執行或結果如何沒有繼續保持原本需要成立的對應關係。

不把案例唯一歸入某一類機制。 一個案例在正文中出現於多個位置,並不表示這些機制已被證明互斥,也不表示形成了逐案分類的體系。

不把法律或治理結論改寫為理論結論。 法院、監管機構與官方報告作出的是它們各自範圍內的判斷。本書的研究映射屬於不同性質的分析,不得互相替代。

不用通行說法補齊缺口。 本附錄中凡標明"未獲來源支持""未給出""至今未知"的位置,都是現有權威材料沒有給出的事實。它們保持空缺。

← 返回書籍首頁