直接看這套東西現在還壞著的地方，我先挑最難堪的一個。我寫了二十幾篇在講怎麼量，回頭重跑 Day 12 那個回報合格率，也就是執行者交回來的回報裡，有多少照規定的格式寫，結果從 31.2% 變成 26.3%。其中回報量最大的兩個角色，合格數是 0。原本想拿來當例子的那個恆為 0 的欄位，在 Day 15 重跑時就看到了第一筆，量到 10 月 12 日上午已經是 28 列。這次的 0 更麻煩：我說不清它是制度壞了，還是尺本身不適用在這兩個角色身上。講量測講了一整季，卻量不清自己的尺。這篇就從這裡開始。
先說這篇的「已知缺陷」指什麼：我知道它在、寫得出來，但現在沒有對策，或只有半套對策的東西。
第一組在攔截層。攔截層是我自己寫的一道檢查，指令執行前先看一眼，危險的擋下。它的維護文件裡有一段「已知不防」，一共 10 類，歸起來是四組：指令以間接形式組出、直譯器相關路徑、不經命令列的外部通道、同一使用者可自行解除的檔案保護旗標。具體條件我不寫，寫出來就成了說明書。它的前提本來就不是沙箱，而是擋模型自然產生的危險指令和意外。真要隔離得靠作業系統層的沙箱，而我手上沒有沙箱已經部署的證據。
第二組在派工。扇出是指一次派多個執行者平行去做。每個執行者做完都會發一個完成通知，逐個喚醒主控一輪；主控就是負責派工、收結果的那個主 agent。輪次和累積的上下文跟著變長。這件事我只有推論，沒有量過每次扇出多喚醒幾輪、多花多少。中層經理就是為這個設計的，由它統包一整批，主控不必被每個執行者各喚醒一次。但這只在其中一種派工模式適用，另一個直接派給執行者的入口會跳過中層。
第三組在規則本身。有一條規則是外包（把工作丟到隔離環境跑）失敗時，禁止退回本機重跑。它有規則，沒有對應事故：我翻不到觸發它的那一次，也就沒辦法用事故回頭驗證它是不是必要。照上一篇定的原則，它標成預防性。
還有一項本來想寫：紀錄入庫是不是只有一個寫入者。我翻了手上的證據，沒有紀錄，量不到，只能留一個問號。
先看回報合格率。量到 10 月 12 日上午為止，時間窗從 9 月 16 日晚上第一筆回報算起，回報共 2,499 筆，合格 656 筆，26.3%。Day 12 那次是 263 筆裡 82 筆合格，31.2%。母數大了將近十倍，比例掉了 4.9 個百分點。逐週看，最低是第 40 週，也就是 9 月 28 日到 10 月 4 日，21.4%。
拆到角色，差距才露出來。中層經理 1,269 筆，合格 0；機械類執行員 503 筆，合格 0。判斷類執行員 473 筆合格 443 筆，93.7%；審查員 241 筆合格 213 筆，88.4%。合格全部來自這兩個角色。
這個 0 有兩種讀法。一種是真的沒照格式寫：不合格的 1,843 筆裡，最大一組 1,038 筆是六個格式欄位全缺。另一種是判定口徑本來就不適用這兩個角色，尺量錯了對象。我沒去查判定是怎麼寫進去的，兩種都排除不了。還有一個細節讓我更不敢下結論：舊紀錄裡機械類執行員曾有一筆被判合格，這次是 0，可能判定邏輯改過，也可能舊資料被重判。
十列已知缺陷，對策欄只分有、部分、無、取不到四種，不打分數。第五列就是開頭那個矛盾：回報合格率 26.3%，回報量最大的兩個角色合格數為 0，原因沒查。第七列取不到證據，照實寫取不到。
第二類問題更根本，它們不是壞了，是量不到。這四項我都在前面的篇章寫過，這裡只是收在一起。等價成本是按官方 API 定價換算的金額，不是帳單，訂閱制不照它收費（Day 13、Day 14、Day 15）。額度幅度是訂閱方案顯示的用量百分比，它含同時段其他對話和裝置的消耗，又只有整數百分比，換算不回某一輪（Day 13、Day 15）。分計欄位只看得到一邊：token 是模型計算用量的單位，token 欄只記主控，金額欄連子代理，也就是主控派出去的執行者，一起算，Day 15 那 59.45% 的落差全屬這一類（Day 14、Day 15）。思考量包在輸出裡回報，量到 10 月 12 日上午，6,660 列中思考量占輸出 34.49%，但整條管線只有這一個來源（Day 14、Day 15）。
四項各回指當初寫它的那一篇。這四項都量得出一個數字，量不到的是那個數字背後的真實值，或可以拿來比對的第二個來源。
這些洞我修不掉，能改的是讀法。
回報合格率不再看總比例，一律分角色讀。排除中層經理之後，合格率是 53.3%；這只是換個母數，不代表變好，但它至少把「誰在拉低」和「整體多差」分開。0 的原因沒查清楚以前，我不把它寫成制度失敗，也不寫成尺不適用，兩種都標在旁邊。格式規格和判定欄在 Day 12 就有了，缺的是回頭查這個 0 是怎麼判出來的。在查清楚以前，這個數字只能附註使用。
成本也一樣。等價成本只當相對比較的尺，不拿去對帳單；總額用紀錄值，組成用重算值，子代理的 token 加總還沒做，就寫沒做。任何「恆為 0」都附量測日期，因為 Day 15 已經示範過，一個 0 可能幾天後就不是 0。
規則這邊沿用上一篇的原則：指得出事故的規則，標出那一次；指不出的，標明預防性，不去找一個事故來湊。
攔截層我不再把它當成牆。它擋的是意外，不是刻意繞過的人；真要隔離，那是作業系統層的事，不是在攔截層多加幾條判斷就能補上的。外部網址只能經受控入口讀取，這條規則確實存在，但那是規則，不是攔截。
這些都不是對策，只是讓我在讀數字時，不會把一個沒量過的地方，當成一個沒問題的地方。
這篇列的洞，大多目前沒有解法。攔截層那 10 類要等作業系統層的隔離；扇出喚醒要先有量測才談得上省；單一寫入者連有沒有問題都量不到；回報那個 0 連算不算問題都還說不清。
我能做的只有讓它們被看見：寫進文件，附上量測日期，標明是實測還是推論。這比修好小得多，但下一個讀這套系統的人，包括幾個月後的我，至少不會把空白讀成安全。洞也不會因為被看見就變小。被看見只代表下次有人問「這裡量過嗎」，我答得出「沒有」，而不是「應該沒問題」。
更不安的是另一件事：這份清單只收得到我列得出來的洞。列不出來的，不會出現在任何一張圖裡。
明日預告：Day 30｜回頭看：一間由 AI 組成的小公司
iThome鐵人賽
看影片追技術