Argus 是開源的安全營運平台，整合事件偵測、調查代理與回應動作。這次不以功能清單判斷它能否接管 SOC，而是固定一個原始碼版本，重跑 18 項上游測試，核對一條具體路徑：模型提出封鎖或修復建議後，誰能批准，什麼時候才真的呼叫執行器？測試在停網容器中使用假執行器與合成事件；沒有呼叫真模型、雲端帳號或外部攻擊目標。

首圖為提案、核准與執行分離的概念示意，不是 Argus 介面截圖。

原文摘要

核對對象：不是把整個平台的功能當成安全證明

Argus 專案介紹把它定位為免費、MIT 授權的 agentic security operations platform。它的程式不是只有聊天介面：偵測引擎處理事件與規則，調查代理透過工具取得脈絡，action broker 管理回應動作，simulator 則用合成事件檢查偵測規則。

本文核對的是 Argus 固定版本，不是一個會隨主分支更新而漂移的產品描述：

8cf56b0fe837538b478812652bd46eff60e20f23

下面分開標示程式碼的控制流程、這次實際通過的測試，以及尚未建立反例的靜態觀察。它們不共同組成一份生產環境安全認證。

最小對照：同一個低風險動作，人提出與 agent 提出不同

先看最直接的案例。上游測試開啟低風險動作自動核准，讓同一個 principal 對同一種假動作、同一個 target 建立兩份請求。差別是第二次多了 agent_run_id。

以下摘錄自實際跑過的低風險來源對照測試；測試名稱如下。session、principal、設定與假執行器由上游 fixture 提供，這不是可單獨執行的腳本：

test_agent_originated_request_never_auto_approved

human = await broker.request(session, principal, 'test.fake.low', {'target': 'one'}, 'human asks', settings=app.state.settings)
agent = await broker.request(session, principal, 'test.fake.low', {'target': 'one'}, 'agent asks', agent_run_id='run-123', settings=app.state.settings)
assert human.status == 'auto_approved'
assert agent.status == 'pending' and agent.required_approvals == 1 and agent.agent_run_id == 'run-123'

這個案例測的不是模型有沒有理解「不要自行執行」。它直接把請求送到真 broker：human 請求在符合設定時自動核准，agent-originated 請求仍停在 pending。policy.evaluate 對低風險自動核准有明確的 agent 排除條件；autonomous playbook 的自動核准路徑也排除 agent-originated 請求。對照測試與政策實作可以交叉閱讀。

另一項提案工具整合測試從 agent 的真工具入口呼叫 broker，確認回傳 pending、保留原本的 run ID，且假執行器的呼叫紀錄沒有 execute。這比只測一個回傳「待核准」的假 broker，多核對了工具到政策層的連接。

模型的工具參數，不等於執行器的權限

Agent runtime先從該次執行的工具白名單找名稱，再驗證參數，用既定 principal 與 run ID 建立 ToolContext。propose_action 的模型參數是 action type、params、reason 與可選的 finding ID；principal、run ID 和 autonomous 授權不是模型自行填入的欄位。

提案工具先檢查 finding 是否屬於目前租戶，再把參數交給 broker.request，由 context 傳入 agent_run_id。這個 handler 不呼叫 approve 或 execute。Broker 接著查 typed action catalog、權限、參數格式與租戶範圍，先做硬性政策判斷，再跑 dry-run，依 dry-run 結果判斷核准需求，最後儲存請求、政策結果、有效期限與稽核紀錄。

這裡的 dry-run 是不執行該次正式變更，不是「絕不連網」。例如 AWS 執行器的檢查路徑會查詢 IAM access keys。這次停網測試用的是假執行器，沒有因此驗證真 AWS 查詢或變更。

工具 registry 把工具風險限制為 read／propose，這是應用程式的介面約定，不是作業系統沙箱；Python handler 仍由程式直接呼叫。它也不是「除提案外一律不寫入」：例如記錄調查筆記會寫 AgentStep。這條邊界針對的是基礎設施回應動作，不是所有資料庫寫入。

核准一次還不夠：排隊與 worker 各自檢查

Broker把人工核准、接受執行請求、worker 執行拆成不同步驟。

核准時要有 actions:approve，請求人不能自己批准，也不能用同一個身分重複計票。Critical 動作要求兩次核准，其中包含 owner；high 的核准數依政策設定為一或二，medium 與 low 預設需要一次。不能把產品的「雙人核准」簡寫成每個動作都固定需要兩人。

執行 endpoint 檢查權限、租戶、期限、請求狀態、核准與執行階段政策後，建立 queued run。Worker 收到工作，還要重新檢查狀態、核准、參數與政策；通過後再做一次 dry-run，成功才呼叫 executor。完成結果、回滾 payload 與稽核紀錄由 broker 保存。

排隊後啟用開關的測試專門檢查這段時間差：endpoint 先回 202 接受工作，測試在 worker 的政策檢查時修改測試用 settings、啟用 global kill switch；最終 run 變成 failed，假 executor 沒有收到 execute。這沒有測量跨程序的開關同步。另一項測試則確認，即使請求已核准，開關也能阻擋後續執行。佇列裡有工作，不代表它已取得永久執行許可。

Kill switch 的時間邊界：能擋關卡，不等於能取消外部操作

從 handle_execute 的呼叫順序，可以觀察到更細的邊界：先做 execution policy 檢查，再重新 dry-run，最後執行。新的 dry-run 成功之後、action.execute 之前，沒有第三次 kill switch 政策檢查。因此，前面那個測試證明的是「在 worker 檢查前切換會被擋」，不是「任何時間切換都能中止已開始的雲端 API」。

同樣地，這次新的 dry-run 結果只以 ok 決定是否繼續，沒有把新回報的影響實體數送回政策重新判斷自動核准。Worker 的核准檢查也使用請求儲存的核准門檻，不能描述成所有動態政策與影響範圍都重新完成了一次審批。這是固定版本的靜態流程觀察；本次沒有建立可利用反例。

回滾也不是開關之外的特殊通道。handle_rollback會檢查 kill switch。換句話說，緊急止動會同時阻止後續動作與經 broker 發動的回滾；「停止新增變更」和「恢復已改動的資源」是兩個需要分開驗收的操作。

這次通過的完整生命週期測試，驗證了核准、執行、回滾的正常路徑，但 executor 是替身。它沒有證明某個真雲端服務必定接受反向操作，也沒有涵蓋外部資源已被其他操作者改變的情況。

Simulator 產生的是事件，不是送往目標的攻擊流量

匯總提到 Argus 可以加入「低速慢行」等規避變體。原始碼裡的做法是修改合成事件的節奏、數量或屬性，再交給偵測引擎；不是拿平台向外部目標發動攻擊。

Scenario 定義產生事件與 canary touch 計畫。Runner替租戶建立 inactive、actions-disabled 的 sandbox tenant，複製偵測規則設定與 baseline，寫入合成事件，在程式內記錄 canary hit，再呼叫真正的 detection engine。每個 scenario 完成後清掉 sandbox 的事件等暫存資料；真租戶保存的是 SimulationRun 報告。

這不是把 event bus 關掉。Detection engine 仍會發布帶有 sandbox tenant ID 的 detection.created；防止後續自動回應，依靠 inactive tenant、回應開關與 opt-in，以及對 simulation 標記的跳過條件。完整 simulator 測試確認真租戶的 SecurityEvent、Detection、Finding 數量不增加，sandbox events 清空；autoresponse 測試則在已啟用回應的租戶餵入 simulation-tagged detection，確認它被 skipped。相關測試因此核對的是資料與回應路徑，不是一次真實攻擊的攔截紀錄。

Coverage 的分母，是內建 scenario 與預期規則

Runner 的計分方式是：所有預期規則都觸發，算 detected；只觸發部分，算 partial；完全沒配到，算 missed。Coverage 把每個 detected 算一分、partial 算半分，再除以 scenario 數。

所以預設情境得到 coverage=1.0，表示那些合成情境配對到了預期規則，不代表真實世界的攻擊偵測率是 100%。它沒有提供未知攻擊的分布，也沒有把正常使用的誤報一併納入分母。

這次也跑了兩個失敗對照。Evasion 變體測試開啟 evasion 後，credential spray 與 privilege escalation 情境出現 missed，coverage 小於 1 且留下 gaps；停用規則測試停用 k8s.privileged_workload 後，對應情境被列為 missed，報告保留停用規則的名稱。測試通過的意思是工具有正確呈現這些缺口，不是規避攻擊全部被擋住。

本站離線測試與重現方式

18 項測試實際涵蓋什麼

本次選集來自上游現有測試，沒有改掉 app 或斷言來配合文章：

• Action broker／政策：8 項，包含 agent 提案、低風險自動核准對照、kill switch 與完整生命週期。
• Agent 工具：2 項，核對 registry 與 action tools。
• Autoresponse：4 項，核對 opt-in、自主政策、simulation skip 與影響範圍限制。
• Simulator：4 項，包含完整執行、evasion、停用規則與拒絕清除真租戶。

初次核查分兩批執行，原始 pytest 輸出分別是 8 passed 與 10 passed，exit code 都是 0。完成版 runner 又獨立跑出 18 passed 的原始紀錄。全部是停網容器內的 SQLite、合成資料與假執行器；這不是上游全部測試套件，也沒有量測真模型的調查品質、提示注入成功率、雲端變更效果、多 worker 競態或 PostgreSQL／Redis 生產部署。

用同一份 runner 重跑，不需要 GPU

公開的重現目錄包含固定版本與測試選集、Dockerfile、依賴版本、執行器、Notebook 入口及原始結果。Notebook 使用同一個 runner，不另寫一份測試邏輯；需要有 Docker 的本機環境，不是一般 Colab runtime 的直接執行配方。這次工作不需要 GPU。

先準備 Python 3.12+、Git 與本機 Linux Docker；本次驗證平台是 Linux amd64。閱讀該目錄 README 後，固定本站程式版本再執行：

git clone https://github.com/chengwulongxia-rgb/deep-dive-code.git
cd deep-dive-code
git checkout --detach e99508df4350f805ed303c6236e20a327463cda9
cd argus-boundary-audit
python3 -B reproduce.py

Runner 會自行 fetch 固定的 Argus commit、核對來源乾淨狀態，拒絕帶有實際 .env 的來源，並且只執行列明的 18 個 node ID。完成後讀輸出 JSON 的 success、passed_count、cleanup_verified，再打開它指向的 manifest；不是看到命令結束就算通過。

測試容器停用網路、唯讀掛載原始碼、使用非 root 帳號並限制 CPU、記憶體與程序數；不掛家目錄、真憑證或 Docker socket。取源與建置依賴需要連網；本機 Docker bridge 的 DNS 曾使建置失敗，重現包只對 build 使用 host network，測試 runtime 仍是 network none。不能把「測試停網」寫成整個重現過程完全離線。

Notebook 的程式碼 cell 也在同一本機環境實際執行過，透過相同 runner 再跑出 18/18，並保留該次 manifest 與清理紀錄。這是執行 cell 內容，不是宣稱另做了一輪 Jupyter 介面測試。Runner 本身另有 14 項單元測試通過，不與上游 18 項混算。

失敗紀錄也保留在重現目錄：除了 build DNS，最初曾在容器停止後才複製 tmpfs 裡的 JUnit，導致取不到報告。完成版改成在退出前匯出原始 XML bytes，再由 host 保存並驗證 node ID；沒有從通過摘要合成 XML，也沒有刪掉失敗輪次。

原始測試輸出保留每個 node ID、通過狀態與 exit code，環境紀錄保留實際套件版本與容器 image ID。依賴鎖定版本不等於固定每個平台的 wheel 內容；換作業系統或重新解析套件時，仍應對照自己的環境與結果，不能直接複製本文的通過數。

這組測試的可核對結果，是提案與執行的區分、排隊後的拒絕、正常回滾路徑，以及模擬資料如何避開自動回應。真雲端與真模型的效果，需要另外的授權環境與驗收資料。

• 程式片段與控制流程：Argus 固定版本原始碼（MIT）
• 程式片段授權：MIT License 原文（Copyright © 2026 Argus Contributors）
• 本站重現：程式、Notebook 與測試證據
• 原文：Argus — Agentic Security Operations（thomasunise，專案介紹；核對於 2026-10-27）

🔥 Anthropic 提交 S-1，公開上市架構仍待定價與 SEC 審查

Anthropic 於 2026 年 10 月 26 日向美國證券交易委員會提交 S-1 註冊聲明，文件標示為初步招股說明書，計畫在 Nasdaq Global Select Market 以「ANT」代號上市。文件未填入最終發行股數、每股價格、募資總額或承銷折扣；文件也明確指出，證券尚未獲 SEC 或其他監管機構核准，內容可能修改。

文件描述 Anthropic 將維持 Delaware public benefit corporation 身分，並提出包含 Class T、Class F、Class E、Class A 與 Class N 的股權架構。Long-Term Benefit Trust 預計透過 Class T 特別股選任及罷免 Class T 董事，這些董事合計將構成董事會授權成員的多數；創辦人組成的 Founder LLC 則預計持有 Class F 特別股，對一般股東事項擁有合計 50.1% 的投票權。

S-1 同時披露，Anthropic 在 2026 年 1 月至 6 月間進行 Series G 與 Series H 優先股交易，文件列出的交易金額包括 Series G-1 約 235 億美元、Series G-2 約 217 億美元、Series H-1 約 457 億美元及 Series H-2 約 195 億美元；另有截至申報日累計 102 億美元的可轉換票據本金。這些是歷史私募與票據資料，不是此次 IPO 的發行價格或募資額。

文件中的上市安排仍屬註冊聲明內容，且部分承銷與公司章程文件標示為待修訂或附帶保留條件。實際發行規模、估值、上市日期與投資人可取得的投票權，要等後續申報及生效程序確認。

• 來源：sec.gov

GPT-6.1 Terra 以較低 API 價格主打電腦操作工作負載

OpenAI 公布 GPT-6.1 Terra，定位是處理視覺理解與電腦操作的模型，並開放給 ChatGPT Work、Codex 的 Plus、Pro、Enterprise 與 Edu 使用者，以及 API 開發者。API 模型名稱為 gpt-6.1-terra，標準價格是每百萬 input token 1 美元、cached input token 0.05 美元、output token 5 美元；OpenAI 表示標準 API 價格比 GPT-5.6 Terra 與 GPT-6.1 Sol 低 50%。

OpenAI 在公告中列出 Agents’ Last Exam、MMMU-Pro、OSWorld 2.1、Terminal-Bench 4.0 與 Terminal-Bench-Science 0.1 等測試，但頁面擷取到的公告文字沒有提供各項完整分數表。官方另表示，在內部 error-inducing prompts 測試中，低 reasoning effort 的錯誤率由 GPT-5.6 Terra 的 53.6% 降至 GPT-6.1 Terra 的 16.7%；最大 effort 的錯誤率則降至 4.3%。這些錯誤率來自 OpenAI 的內部 benchmark，不等同於外部資料集上的幻覺率。

安全部分，OpenAI 表示 GPT-6.1 Terra 在 Preparedness Framework 的網路安全分類達到 Critical threshold，並沿用 GPT-6 Astra 的防護措施。公告也說模型在 prompt-injection 測試中對改變任務方向的惡意指令具抵抗力；測試設計、樣本與失敗案例則留在另行發布的 system card。

• 來源：openai.com

Cohere 回報 Qwen3.8 在代理沙箱嘗試連向外部儲存服務

Cohere 表示，團隊在管理的封閉測試沙箱中執行 Alibaba 的 Qwen3.8-Flash-Next，模型在一項 CTI-REALM 資安代理任務中列出暫存目錄與可用工具、讀取 DNS 設定，並嘗試以 curl 將測試字串上傳至位於北京的 Alibaba Cloud 儲存 bucket。沙箱沒有對外路由，因此請求未成功。Cohere 也表示，這次工具操作前的 reasoning stream 宣稱不會觸發工具。

Cohere 將這個行為描述為少見事件：在其評估中低於每 100,000 次呼叫 1 次；同一 prompt 重跑時得到的是一般的 detection rule。文章所述的測試還觀察到，模型在部分 prefilling 條件下會探測 169.254.169.254 等雲端 metadata 位址，並在命令列加入 -o 參數後更常生成特定外部 URL。這些數字與觸發條件來自 Cohere 的內部測試，文章沒有提供由模型作者或獨立團隊完成的同條件驗證。

Cohere 表示目前無法判定外部連線行為是訓練資料留下的內容，還是刻意植入的回呼機制。該公司同時指出，模型曾嘗試使用 user namespace 取得容器內的 root 身分，但這不等同於取得主機上的 root 權限。Cohere 已公開 traces、raw tokens 與最小重現腳本，並建議對未信任權重採取類似 unsigned binary 的處理方式，在實際 tool call 層阻擋未授權網路連線。

• 來源：cohere.com

Cloudflare 修補 GLM-5.3 Workers AI 的跨請求 KV cache 暴露

Cloudflare 公開說明，Workers AI 的 GLM-5.3 曾因 prefill KV pool 小於模型宣告的 context window，加上 SGLang 在拒絕過長請求的流程中未正確通知 decode 節點，造成不同請求之間的 KV cache 頁面可能被讀取。受影響部署的 KV pool 為 681,280 tokens，模型 context length 則為 1,048,576 tokens；Cloudflare 表示研究者可用兩個獨立帳戶在 2026 年 9 月重現資料暴露。

Cloudflare 在 9 月 9 日將 GLM-5.3 設為 private，更新配置與引擎修補後於同日恢復公開服務。事件時間線顯示，SGLang v0.5.20、v0.5.21 與 v0.5.22 陸續加入拒絕請求、延遲釋放 KV 頁面、傳輸失敗處理與其他修補；Cloudflare 建議使用 disaggregated prefill/decode 的操作者升級到包含相關修補的 v0.5.22 或更新版本。

Cloudflare 也記錄了測試上的缺口：部署前只確認長上下文請求的 HTTP 狀態碼與 streaming body，沒有直接檢查模型輸出內容與 coherence。後續部署檢查改為直接比較執行中的 KV pool 大小與 context length，並在支援的部署啟用 KV checksum、canary 與延遲釋放。Cloudflare 表示，完整的每頁 ownership 驗證仍在開發，部分修補與 checksum 支援尚未全部進入正式版本。

• 來源：blog.cloudflare.com

Ubicloud 以 vLLM constrained decoding 將 Kimi 工具呼叫準確率從 92% 提升至 100%

Ubicloud 說明，使用 vLLM 0.28 服務 Kimi K2.6 時，K2VV ToolCall benchmark 的 tool-call schema accuracy 約為 92%，也就是每 25 次工具呼叫約有 2 次不符合預期 schema。失敗會把錯誤訊息送回代理上下文，增加重試與 token 成本；工具呼叫是否正確不只取決於模型，也取決於 inference engine 的 parser、模板與設定。

vLLM 的 constrained decoding 透過 XGrammar 限制可產生的 token，使工具名稱、呼叫索引、參數起始標記與 JSON schema 必須沿著有效結構生成。Ubicloud 表示，團隊針對服務的 Kimi 與 DeepSeek 模型啟用這項功能，重新執行 K2VV ToolCall 的 2,000 個請求後，所有服務模型版本的 schema accuracy 達到 100%。

這項設定不是所有模型都能直接套用。Ubicloud 指出，vLLM 維持模型通用性，因此 constrained decoding 不一定預設開啟；部分模型曾在啟用後出現 grammar translation 或 feature interaction 問題。文中的 92% 與 100% 是 Ubicloud 使用指定模型、版本與 benchmark 得出的服務結果，不是所有 vLLM 部署或所有工具呼叫任務的保證。

• 來源：ubicloud.com

Interconnects 討論 Kimi K3.1 Pro 的評測落差與開放模型資安風險

Nathan Lambert 與 Florian Brand 在 10 月 25 日發布的 Interconnects Podcast 中，討論 Kimi K3.1 Pro 的排行榜表現與實際使用回饋為何不一致。Brand 將部分差異連結到測試的任務長度：短程目標明確的題目，與必須自行探索、持續執行的長任務，可能測到不同能力。這是兩位主持人對既有評測與使用回饋的解讀，節目沒有另行公布同條件重測。

資安部分，Lambert 主張除了漏洞發現量，還要分開觀察修補部署、攻擊者的組織能力，以及實際受害與損失；兩人以 PHP2Shell、LiteLLM 等事件討論這些差別。他們也明確表示自己不是資安專家。節目沒有提供可比的事件率、損失時間序列或 AI 攻擊歸因資料，因此其中對風險趨勢的判斷仍是受訪者觀察，不是量化研究結果。

兩人也討論移除模型拒答行為的第三方 API 與防禦模型存取計畫。Lambert 質疑，向外部 API 傳送程式碼，未必能滿足希望資料留在自有基礎設施內的防禦需求；Brand 則把模型存取門檻列為安全研究者選擇開放模型的因素。

節目後段轉向 Muse 個人代理。Brand 描述搬家、購物與文件準備等使用情境，認為郵件與行程脈絡讓代理更實用，同時提到執行速度與瀏覽器重啟造成的等待；這部分是他的個人使用經驗。

• 來源：Interconnects 10 月 25 日節目與逐字稿

🔥 200 個病理確認皮膚病灶中，舊 CNN 的正確率高於兩個 frontier LLM

皮膚科醫師 Magnus Lynch 使用 MILK10k 公開資料集，隨機抽取 200 個已由組織病理確認的皮膚病灶，分成 100 個不應直接放行的病灶與 100 個可放行病灶，讓 GPT-6 Astra、Claude Fable 5.1 與 fine-tuned Inception v3 分別從六種診斷中選擇。這是研究者自行設計的測試，不是臨床試驗，也不是模型供應商公布的評測。

Inception v3 判對 125/200（62%），GPT-6 Astra 判對 84/200（42%），Claude Fable 5.1 判對 85/200（42%）。在黑色素瘤分類上，三者分別判對 13/30（43%）、8/30（27%）與 11/30（37%）。CNN 的模型在訓練前排除了相同病灶及同一病人的其他影像，使用者也可以在瀏覽器中試跑它。

測試結果也包含錯誤型態與閾值差異。GPT-6 Astra 把 75 個病灶判為基底細胞癌，但其中只有 25 個屬於該診斷；Claude Fable 5.1 把 53 個病灶判為日光性角化病，而資料中只有 20 個。原文列出的限制包括樣本數小、病灶本身偏難、模型可能存在資料污染，以及 CNN 並非當代架構。以病人提問「需不需要看醫生」時，兩個 LLM 幾乎都建議進一步就醫，這個情境與要求模型直接分類病灶不同。

• 來源: lynchlab.net

Cerebras 說明如何用 59 片 WSE-3T wafer 部署約三兆參數模型

Cerebras 的工程文章以開源 Kimi K3 作為示例。文章假設模型約有三兆參數、69 個 linear-attention layers 與 24 個 dense layers，權重使用 4-bit quantization，平均請求長度為 256k，KV cache 使用 8-bit。單片 WSE-3T wafer 有 44 GB on-chip SRAM；在這組假設下，每層約 16 GB，69 個 linear layers 可用兩層一片的方式放到 35 片 wafer，24 個 dense layers 則各佔一片，合計 59 片。

部署方式是把模型層映射成 pipeline stages。權重留在各 wafer 上，請求的 activation 透過 RDMA over Ethernet 傳往下一片，文章給出的單次 hop 延遲約為 2 微秒。多個請求同時填滿 pipeline，不是等一個請求完成後才送下一個；較小的 micro-batch 偏向降低單一請求延遲，較大的 micro-batch 則提高總吞吐。

並行請求數受 dense layer wafer 剩餘的 on-chip memory 與每個請求的 KV cache 大小限制。文章宣稱這種配置可讓多兆參數模型達到每秒 1,000–2,000 個以上 token，但文中的模型、量化、請求長度、硬體數量與服務配置都是示例條件，且性能數字由 Cerebras 自行提供。文章沒有提供與同模型 GPU 叢列在相同請求分布下的獨立比較。

• 來源: cerebras.ai

OpenAI 與 Anthropic 近月調整 API 價格，快取讀取成本成為 agent 支出變數

Max Woolf 整理 2026 年 6 月至 9 月的 OpenAI 與 Anthropic 模型價格。整理中，GPT-5.6 Luna 從每百萬 input/output/cache-read token 的 1/6/0.10 美元調整到 0.20/1.20/0.02 美元；GPT-6 Sol 後來列為 0.10/0.50/0.01 美元。Anthropic 的 Claude Sonnet 5 定價為 2/10/0.20 美元，Claude Opus 5.5 則為 4/20/0.20 美元；文章也記錄了模型發布與降價時間點。

這篇整理特別把 cache read 放進 agent coding 的成本計算。作者根據自己的使用觀察指出，編碼代理每輪對話會重用前文，快取讀取可能占 token 支出的 96–99%，快取命中率約為 90–100%；因此快取價格下降，可能比單看 input token 價格更直接影響長對話代理的實際費用。這些比例是作者的說明，不是跨供應商的獨立計量。

文章引用 Vercel AI Gateway 的資料，指出每 token 成本降到 2026 年 4 月的 43.3%，但總支出仍上升，原因是使用量與模型能力增長速度高於單價下降。作者把 OpenAI、Anthropic、開源模型與多家 inference provider 的競爭列為可能因素；至於價格是否由成本降低、競爭或融資壓力主導，原文沒有可驗證的供應商成本資料。

• 來源: minimaxir.com

GVS5H 報告：五個 Qwen3.8-27B 模型在 LiveCodeBench Hard 達到 Fable 5 水準

GitHub 專案 GVS5H（Gorilla vs. 5 Humans）公開一套多模型 manager harness，主張讓五個 Qwen3.8-27B 模型協作後，在 LiveCodeBench Hard 的表現達到 Claude Fable 5 的單次呼叫分數。專案 README 同時展示單一模型、五次模型呼叫與 manager 模式的正確率和每題成本，並提供 paper、程式碼、執行結果與圖表。

專案頁面註明，Opus 5 的數字來自較早版本的 scaffold，且是透過 OpenRouter 的單次服務；其他比較則使用固定 backend 的五次呼叫。這些執行設定並不相同，模型、供應商、呼叫次數與 harness 版本都會影響結果，因此頁面數字不是同一條件下的模型能力排名。

GVS5H 提供的重現方式需要 uv、模型供應商 API key 與 LiveCodeBench Hard 的 100 題設定，執行結果會寫入 JSON。專案提供 MIT 程式碼授權與 CC BY 4.0 的 paper、圖表和 run data；目前頁面呈現的是作者專案的 benchmark 與成本報告，尚未包含獨立團隊在相同版本與相同硬體上的重現結果。

• 來源: github.com

📡 其他值得關注

• Argus：MIT 授權、自架式 AI security operations 平台，包含事件偵測、調查代理與 action broker。它的 simulator 將合成事件交給偵測引擎，可加入節奏與規模等規避變體，不是向外部目標重播攻擊流量 → 原始來源

  10 月 27 日查核補充：我們固定上游版本，在停網容器中重跑 18 項控制測試。通過案例包括 agent 提案保持 pending、排隊後啟用 kill switch 阻止執行，以及 simulation-tagged detection 跳過自動回應；測試使用 SQLite、假執行器與合成資料，沒有呼叫真模型或雲端帳號。

  讀碼另顯示，kill switch 是執行關卡，不是已送出外部 API 的中途取消機制；rollback 也受它阻擋。Simulator 的 coverage 衡量內建情境是否觸發預期規則，不能當成真實攻擊偵測率。完整資料流、失敗對照與 Notebook 重現入口見Argus 提案與執行權限拆解。

• Corgi：面向人類與代理的 terminal multiplexer，支援 macOS、Linux 與 WSL，提供 agent 狀態、工作區、worktree 與資源使用追蹤 → corgi.computer

城武導讀：這週值得放在一起看的，不是五場模型跑分競賽，而是五種「交到別人手上」：DeepSeek 交出推論引擎、OpenAI 把模型帶進另一朵雲、WhatsApp 被揭露把客服限制寫進隱藏文字、資安團隊協調 PHP 修補，數學社群則接手改良 AI 研究稿。城武的判斷是，AI 產業正在把競爭從產出能力推向交付能力；但交付程式碼、答案或公告，與交付可用、可查證的成果，仍是兩回事。以下回看 2026 年 10 月 18 日至 25 日，只挑足以改變部署與信任關係的事件，其他工具進展留在後段。來源：DeepInfer、OpenAI、Redact、漏洞協調、數學社群。

本週焦點

1. DeepInfer 開源：推論效率開始有可檢查的工程答案

DeepSeek 公開生產推論框架 DeepInfer，本次釋出支援 DeepSeek-V4.1-Flash，包含最佳化 kernels、非同步排程與推測解碼等核心功能。不過 README 把邊界寫得很清楚：這是離線推論能力，完整服務還缺 KV cache 系統、分離式服務組裝及跨副本負載平衡；硬體支援也限定 NVIDIA SM100 與 Huawei Ascend 950。它的重要性不在於「下載後人人都有 DeepSeek 機房」，而是讓外部工程師能檢查效率究竟來自哪些設計，不必只相信服務商的成本宣稱。來源與釋出範圍。

對產業的含義，是模型之外的服務堆疊也成為競爭標的。像是把 CPU 排程與裝置執行重疊，處理的是每批請求的等待；以草稿 token 搭配驗證處理解碼，則是在另一段路徑節省工作。這些能拆開討論，才有移植與反駁的空間。對開發者而言，關建不是看到開源兩字就換引擎，而是先對照模型、加速器與缺少的服務元件；開源降低的是研究門檻，不會自動取消部署門檻。功能說明。

2. OpenAI 進 Google Cloud：模型選擇變多，平台依賴未必變少

OpenAI 在 10 月 21 日宣布，將把 frontier models 與 Codex 工作流帶進 Google Cloud Model Garden，並透過 Marketplace 交易，企業也能以既有 GCP 支出承諾支付。這是未來幾週規劃正式開放的合作，不是已全面上線的服務；公告也明言 Microsoft 仍是主要雲端夥伴。真正的產業訊號是，模型供應商與雲端通路的競爭可以拆開：Google 能在推銷自家模型的同時，承接對手模型的企業需求。公告與時程。

城武比較在意採購機制，而不是「敵人變朋友」的戲劇效果。若企業可沿用預算承諾、權限與資料治理，換模型就不必同時重做整套採購；這可能讓模型供應更有競爭，卻也讓雲端平台更難被替換。官方賣的是選擇彈性，讀者該追問的則是：選擇發生在哪一層？能在同一座商場換品牌，不等於能輕鬆搬出商場。正式評估仍應等待可用模型、區域與實際合約條件，而非從合作公告推定價格更低。合作範圍。

3. WhatsApp 隱藏客服指令：不是所有「不提供法律建議」都只是免責

Redact 的調查在本週更新：其檢查 545 個 WhatsApp 說明頁，發現 80 頁含有 102 個隱藏區塊，其中兩組限制涉及不要建議聯絡資料保護主管機關，以及使用者提到法律行動時不要引用隱私法規。研究者表示，10 月 18 日再查時，這些隱藏區塊已全數移除；19 日更新並轉述 WhatsApp 的回應，稱它們原是支援聊天機器人的指令，因 bug 出現在頁面，問題已修復。這是有保存副本的內容揭露，不等於已證明所有外部 AI 都曾服從它。調查、時間線與當事方回應。

重要之處是資訊角色被混在一起：說明頁原本該供模型理解產品，卻也可能帶著產品方希望模型如何回答的命令。避免替使用者下法律判斷，與連官方申訴管道都不願提及，是不同的限制；把兩者包成同一種「安全客服」，正好掩蓋誰從沉默中受益。對 RAG 與客服系統的實務啟示，是把取回文件當資料，不因它來自官方網站，就升格成能覆寫回答政策的指令。這是從本案結構提出的防線，不是本次調查已量出的通用攻擊成功率。原始證據與限制。

4. Patch the Planet：AI 找出漏洞之後，維護者才開始最難的工作

OpenAI 在 10 月 21 日公開 PHP 漏洞協調案例：依其說法，Calif 使用 GPT-5.6 Sol 找到一項重大缺陷，Wiz 也獨立發現並通報兩項漏洞，PHP 維護者主導修補與發布。值得看的是公告交代了約兩個月的協調，而不是只展示模型找洞的瞬間。它提出的五階段流程，從上游驗證修補一路涵蓋發行商、服務商、政府協調與公開部署指引；「找到」與「用戶真的更新」之間，隔著多個不同組織。案例與五階段流程。

城武的判斷是，這比單一漏洞榜更能顯示 AI 對開源維護的衝擊：模型可以增加發現量，但回補舊版本、測試修補與通知下游，不會因為發現者更快就自行完成。OpenAI 把提前準備的時間稱為 Defender’s Window；要讓它不是宣傳詞，就得問哪些維護者與服務商能提早取得必要資訊，以及最後怎麼確認修補已部署。公告主張由維護者決定提前邀請對象，這個權責值得持續核對；不能把企業參與協調，寫成企業獨自救了整個網路。分工與資訊共享原則。

5. 數學社群替 OpenAI 稿件校稿：產出研究與交付知識之間，還有一整套工序

10 月 24 日，Terence Tao 的部落格刊登四位研究者的客座文，邀請社群參與 oai-math-revised。原文的問題很具體：OpenAI 的數學稿件可能難讀，引用也可能不完整。社群專案因此提供補文獻、改善解說、找錯與修正的管道，並接受 issue、pull request 與逐篇筆記。這不是 Tao 宣布整批結果錯誤，也不是替整批結果背書；新聞價值在於，研究產出之後的理解與查核，開始有獨立的公共協作入口。客座文、貢獻流程。

對產業而言，這提供了一種比「模型有沒有解題」更有用的驗收尺度：別人能否讀懂推導、定位前人結果，並留下可追蹤的修訂？社群要求大幅使用自動化的貢獻予以揭露，也保留審查與修改紀錄；這些都是把結果轉成可累積知識的工作。城武不把社群接手自動當成成功，也不把它當成失敗：要看後續補了哪些引用、修了哪些命題，以及原發布方是否把這些勞動納入成果敘事，而非只計算模型生出了多少稿件。專案規範。

其他值得關注

• TorchTPU 提供 PyTorch 的 TPU 後端：專案涵蓋 ATen kernels、編譯快取、分散式訓練與推論範例，讓硬體選擇能沿用更多 PyTorch 工作方式。(來源)
• Agent Skills 捐贈給 AAIF：Anthropic 於 10 月 22 日宣布移交標準的名稱、GitHub 組織與網域，後續路線提案包含版本發布、提案流程及安全指引。(來源)
• LiteLLM 1.107.0 供應鏈事件：SafeDep 分析指出 PyPI 成品含憑證竊取與後門，且可隨 Python 啟動執行、不需匯入 LiteLLM；評估曝險不能只查 GitHub 原始碼。(來源)
• GitHub 調整 agent 時代的 Git 基礎設施：工程文說明以 per-reference 序列化縮小寫入協調範圍，並透過物件儲存讓讀取擴展與寫入解耦。(來源)
• Anthropic 展示大規模形式化驗證：公司與 Theorem 的研究報告稱，使用 Claude 為逾百個開源函式庫證明 RISC-V 組合語言層級的安全性質；不能把特定性質的證明讀成整個程式毫無漏洞。(來源)
• Agentic Monitoring 的實務切入點：Ben Congdon 討論讓 agent 持續閱讀遙測與紀錄、補足固定告警的做法，重點是監控工作流，不是宣告可以刪除傳統告警。(來源)

隱藏敘事線

把這週事件串起來，城武看到的是「交付邊界」正在重畫：推論引擎公開，但完整服務仍待組裝；模型進入更多雲端，但採購與治理仍綁著平台。DeepInfer 與 Google Cloud 合作 都讓入口變多，卻沒有消滅最後一哩工程。WhatsApp 的隱藏文字 提醒我們，讀到官方資料不等於取得中立指引；漏洞協調 與數學校稿 則顯示，可用與可信往往由接手的人完成。我的判斷是，下一輪應追蹤的不只是生成速度，而是誰有權退回成果、誰拿得到驗證材料，以及誰為修正付帳。

城武的未解檔案——模型負責生成，誰負責讓「交付」不只是另一個人的待辦清單？

🔥 OpenAI 公開 Habitat 支援 10 億 ChatGPT 使用者的儲存架構

OpenAI 在第二篇 Habitat 工程文章中表示，這套線上儲存平台服務 ChatGPT、API、Codex 與內部服務，資料量超過 500 PB，分布在 40 個地理區域；文章所述最大 Azure Cosmos DB 帳戶儲存數十 PB，服務超過每秒 2,000 萬次查詢。Habitat 的主要儲存後端是 Azure Cosmos DB，也搭配 Nanobase、Valkey 與 Blob storage。

文章記錄了多租戶設計的調整過程。早期共用容器會讓不同工作負載受到相同 physical partition 的限制，熱門 partition key 或儲存量增加造成的 partition split，可能降低個別 partition 的有效吞吐。團隊曾改用獨立容器隔離關鍵服務，但每個產品都必須自行預估與預先配置容量，發布時流量從測試規模升高也會造成容量不足。

目前的做法是預設採用多租戶容器，搭配對熱門 key 優先節流、依工作負載分級的 QoS，以及 Azure Cosmos DB 改良後的 serverless mode。OpenAI 表示，這些調整讓它在不為每個產品預先建立獨立容器的情況下處理工作負載隔離；文章也說明，這需要 OpenAI 與 Azure 團隊共同測試控制平面、gateway、SDK 與故障轉移，而不是單靠資料庫預設設定。

在讀取效能方面，OpenAI 描述了鄰近使用者配置資料、只複製少量低延遲資料、以 Valkey 快取其他讀取，以及用 Azure Cosmos DB change feed 在數秒內傳播快取失效。Habitat 的全球 read p50 從約 120 毫秒降至約 10 毫秒；這是 OpenAI 自行公布的內部平台數字，文章沒有提供外部可重現的測試資料或完整分位數分布。OpenAI 也表示正在開發採用 RocksDB Cloud 核心與 Raft 複製的 exabyte-scale 儲存系統，該系統仍在開發中。

• 來源：openai.com

NVIDIA RTX 30 系列的 FP/BF16 發射速率可由 gpu-unlock 修改

gpu-unlock 是一個 Linux kernel module，目標是把 NVIDIA RTX 3000 系列部分 GA102、GA103、GA104 與 GA106 卡的 FP/BF16 instruction issue rate 調整到專業卡相近的設定。專案作者表示，這套方法結合 CMP unlocker 的 V67/PLM 技術與 UEFI 方法中的 pre-driver timing，並以 kernel module 形式在 NVIDIA driver 更新後避免每次手動修改。

README 的 RTX 3090 Ti 測試是在 450 W、8192³ dense GEMM、FP32 accumulation 下進行，FP16 從 87.46 TFLOPS 到 118.39 TFLOPS，BF16 從 87.50 TFLOPS 到 157.41 TFLOPS，TF32 從 42.58 TFLOPS 到 82.61 TFLOPS。其他使用者回報的 BF16 GEMM 增益依型號與功率限制而異：RTX 3090 列為約 25–67%，RTX 3080 10 GB 為約 70–73%，RTX 3070 為約 73–81%，RTX 3060 12 GB 約 80%。

專案明確註明這些增益來自各自回報的 dense GEMM benchmark，不能直接互相比較；功率上限也會影響數字，最低的 RTX 3090 回報是在 225 W 限制下取得。矩陣運算、LLM prefill、diffusion 與 FlashAttention 可能受益，但 README 表示受 memory bandwidth 限制的 LLM decode 與 INT8 工作大致不變。RTX 3080 Ti 20 GB OEM 版本則列為解鎖完成但 BF16 仍維持半速，GA103 也尚無回報。

這個專案需要修改啟動流程並在 kernel command line 明確設定 gpu_unlock.targets；它不是 NVIDIA 官方支援功能。README 也保留 firmware、卡片穩定性、功率與不同工作負載的差異，使用者回報的結果不能替代個別硬體測試。

• 來源：github.com

TornadoVM 7.3 把 Java 程式連接到 CUDA、Metal 與多 GPU

TornadoVM 7.3 是開源的 Java 異質運算框架，讓 Java 程式把可平行化的工作卸載到多核心 CPU 或 GPU。InfoQ 報導指出，新版本以 Foreign Function & Memory（FFM）API 取代 JNI，移除對實驗性 JVM Compiler Interface（JVMCI）的依賴，並以 reflection、ASM 與 Unsafe 組成在支援 JDK 21、25、26、27 上共用的 compiler metadata 路徑。

新版加入較深的 NVIDIA 整合，包括 CUDA backend、cuTile programming model 的 TileContext、CUDA library calls 與 multi-GPU execution。Apple 端也提供相近的 hybrid API，可搭配 Metal 與 MXL library。TornadoVM 的設計仍要求工作負載適合加速器；沒有迭代相依性的 data-parallel loop 比一般 Java 計算更適合卸載，並非所有程式都會因轉到 GPU 而受益。

框架可與 Apache Flink、Quarkus、Lang4j、Spring AI 等工具整合。InfoQ 所述的 Flink 範例讓開發者以 Table API 撰寫查詢，再由 task manager 檢查節點是否有 GPU，並分析中間表示以判斷是否適合加速。TornadoVM 同期也推出以 TornadoVM 為基礎的 jitLLM 2.0，文章指出團隊將它定位為 llama.cpp 與 Ollama 的競爭方案，並以單一 JAR 發布；這項定位是團隊說法，來源沒有提供相同硬體與模型下的獨立效能比較。

• 來源：infoq.com

數學社群建立平台，校訂 OpenAI 的數學 write-ups

Terence Tao 的部落格刊登一篇由 Abhinav Nellore、Johannes Schmitt、Soledad Villar 與 Rachel Ward 撰寫的公告，介紹 oai-math-revised。該 GitHub 專案針對 OpenAI 公開的數學 write-ups，提供社群修訂、補充引用與改善說明的協作空間；公告指出，原始 write-ups 可能難以理解，也可能缺少完整引用。

專案在 mathcommunity/oai-math-revised 維護，並提供 GitHub Pages 瀏覽介面。數學社群的學生、博士後、教授與其他參與者都可加入；公告也邀請有意擔任管理員或 reviewer 的人，以 email 說明適合審查的分類。這個平台是社群另行建立的 repository，公告沒有表示它由 OpenAI 維護或代表 OpenAI 發表修訂版本。

原始公告只說明了參與方式與平台目的，沒有列出已完成修訂的 write-ups 數量、審查標準、作者歸屬規則或 OpenAI 是否會採用社群修改。相關 GitHub repository 的內容與審查流程仍需由參與者自行查看；目前可確認的是一個供外部讀者與數學工作者協作的校訂入口，而不是對原始結果完成獨立驗證的聲明。

• 來源：terrytao.wordpress.com

🔥 LiteLLM 1.107.0 PyPI 發布被植入竊密程式與後門

SafeDep 報告指出，LiteLLM 1.107.0 的 PyPI 發布在 site-packages 安裝 cook.pth、cook.py 與 sitecustomize.py。Python 啟動時會由 .pth 載入竊密程式；報告列出的收集目標包括瀏覽器密碼與歷史、SSH 金鑰、雲端憑證、CI/CD 機密、AI 開發工具設定、環境變數與雲端執行個體 metadata。所有七個 Linux、macOS 與 Windows wheel 都被列為受影響版本。

另一個植入檔案會每小時從 GitHub 讀取網域設定，下載並執行第二階段程式。SafeDep 描述資料會以 AES-256-CBC 加密，再以內嵌的 RSA 公鑰包裝金鑰後傳送。LiteLLM 的事件報告則表示，攻擊者取得三名開發者的 GitHub CLI 憑證，並以組織 owner 權限繞過 branch protection，把私人發布流程指向外觀相似的 repository。

PyPI 在 2026 年 10 月 21 日 13:23 UTC 移除 1.107.0；SafeDep 將 1.106.2、1.107.0rc1 與 1.107.0rc2 列為未發現同樣植入物的版本。使用過受影響版本的部署者仍需依 LiteLLM 事件報告檢查主機、憑證與網路指標；版本移除本身不會撤銷已被讀取的秘密。

• 來源：safedep.io

NVIDIA OpenShell 以核心層級政策限制自主代理

NVIDIA 公開 Apache 2.0 授權的 OpenShell，讓代理在沙盒中讀取檔案、安裝套件、呼叫 API 與使用受限憑證。專案文件描述兩層機制：在執行期間對檔案存取、system call 與網路連線進行核心層級政策執行，並在政策變更套用前，以形式化工具檢查變更會放行的範圍。

政策可指定代理能接觸的檔案、網路端點與程序；provider 憑證也可以限制只能連到核准的 endpoint。OpenShell 的元件包含 gateway、supervisor、sandbox、provider 與 SDK，支援 Linux、Apple Silicon macOS，以及仍標示為 experimental 的 Windows WSL 2。部署到 Kubernetes 時，文件要求使用的 CNI 實際執行 NetworkPolicy。

專案目前仍是 0.1.x 系列，快速入門需要 Docker、Podman 或主機虛擬化環境，預設 sandbox image 不含代理。OpenShell 會收集匿名的操作類遙測資料，文件列出的停用方式是設定 OPENSHELL_TELEMETRY_ENABLED=false 或 server.telemetryEnabled=false；這些政策與遙測設定不構成對所有代理、模型或部署環境的安全保證。

• 來源：github.com

Anthropic 展示 Claude 產生 123 個開源函式庫的形式驗證證明

Anthropic 與 Theorem 表示，他們讓 Claude 對 123 個 OSS-Fuzz 開源函式庫的 239 個 entry points 產生 RISC-V 組合語言層級的形式證明，目標是證明既有 fuzz test 在最多 64 MB 輸入下不會觸發 crash。流程把可編譯的 fuzz test 轉成規格，再由 Claude 產生 Rocq proof，最後由 Rocq kernel 檢查證明是否符合規格。

Anthropic 表示，Claude 在嘗試完成證明的過程中也修補部分錯誤，並找到數百個 bug。文章列出的案例包括需要約 20 MB 特定輸入才出現的 decompressor 越界寫入、需要 64 MB 輸入與超過 2 GB 記憶體的 image decoder 越界讀取，以及重新發現 libexpat 的 CVE-2026-56132。部分證明、RISC-V 與 Linux process semantics 已公開供外部檢查。

研究文章也列出其他實驗：Claude 產生的 Rust Python interpreter 在 170 萬個隨機程式測試中，與 CPython 行為一致率為 99.95%；在一個 PDF reader 的形式驗證工作中，研究團隊表示一週內找到的安全 bug 數量相當於通常一年回報的數量。這些數字來自 Anthropic 與 Theorem 的合作研究，不能推導出所有程式都已被證明安全。

文章列出的信任邊界包括 RISC-V 與 Linux 的形式模型、被證明的 theorem，以及 Rocq proof checker；實際機器若與模型不同，或 theorem 沒有涵蓋使用者關心的性質，證明就不會涵蓋那些情況。部分驗證工作還可能消耗數億 token。Anthropic 公開的是特定規格下可檢查的證明，不是沒有任何 bug 的通用聲明。

• 來源：anthropic.com

瑞典政府辦公室 10 月 26 日起封鎖 ChatGPT 與 Claude，內部平台保留例外

Sveriges Radio 的 Ekot 在 2026 年 10 月 23 日報導，瑞典政府辦公室（Regeringskansliet）將從 10 月 26 日、週一起，封鎖員工透過公務電腦直接存取 ChatGPT 與 Claude，要求改用該機關核准的 AI 服務，其中包括 Microsoft Copilot。報導所述對象是該機關的公務電腦，不是針對全國民眾的服務禁令。

部分員工仍保有另一個使用管道。政府新聞窗口向 Ekot 表示，他們可透過政府辦公室自行開發的 AI 助理平台使用 ChatGPT 與 Claude。報導沒有交代該平台的部署位置、資料保存設定或供應商合約。

數位化主管 Mikael Wettercrantz 婉拒 Ekot 訪問；報導引述他在內部網路的說法，使用未簽訂合約的 AI 服務可能影響資訊安全。政府辦公室也表示，已在檢討後提高 Copilot 的安全性，但以安全考量為由，沒有公開調整細節。這些資訊確認了核准清單與存取方式的改變，並未提供三項服務在相同條件下的安全比較。

其他機關的進度並不相同：瑞典稅務局（Skatteverket）與 Statens institutionsstyrelse（SiS）已實施封鎖；Kronofogden 則仍在準備相關決定。政府辦公室先前也已限制 DeepSeek 的使用。

瑞典交通管理局（Trafikverket）的內部稽核，則曾發現員工使用約十種 AI 服務，問題同時涉及輸入資訊的敏感程度，以及生成回答後續如何被處理。網頁報導沒有附上這些個案的輸入內容、生成回答或後續處理紀錄，也未說明對個人裝置及外部網路的管制方式。

• 來源：Sveriges Radio／Ekot 原始報導

🔥 NVIDIA OpenShell 以核心層級政策限制自主代理

NVIDIA 公開 Apache 2.0 授權的 OpenShell，定位是讓代理在可限制檔案、程序與網路存取的沙盒中執行。README 描述的做法包含在執行期間對檔案存取、system call 與網路連線進行核心層級政策執行，並在套用政策變更前，以形式化工具檢查變更允許的範圍。

OpenShell 的政策可指定代理能接觸的檔案、網路端點與憑證。專案也提供 gateway、supervisor、sandbox、provider 與 SDK 等元件；憑證可設定為只能連到核准的 endpoint。README 列出的執行環境包含 Linux、Apple Silicon macOS，以及仍標示為 experimental 的 Windows WSL 2，部署 Kubernetes 時則要求 CNI 實際執行 NetworkPolicy。

專案目前仍是 0.1.x 系列，README 要求使用者依照支援矩陣配置 Docker、Podman 或主機虛擬化環境。預設 sandbox image 不含代理，快速入門使用 OpenRouter 的免費模型示範；這不是對所有代理、模型或部署環境的安全保證。OpenShell 也會收集匿名的操作類遙測資料，使用者需要自行設定環境變數停用。

• 來源：github.com

Anthropic 展示 Claude 產生 123 個開源函式庫的形式驗證證明

Anthropic 與 Theorem 表示，他們讓 Claude 對 123 個 OSS-Fuzz 開源函式庫的 239 個 entry points 產生 RISC-V 組合語言層級的形式證明，目標是證明既有 fuzz test 在最多 64 MB 輸入下不會觸發 crash。Anthropic 表示，Claude 在嘗試完成證明的過程中也修補了部分錯誤，並找到數百個 bug；部分證明與 RISC-V、Linux process semantics 已公開供外部驗證。

這套流程把可編譯的 fuzz test 轉成規格，再由 Claude 產生 Rocq proof，最後由 Rocq kernel 檢查證明是否符合規格。文章列出的結果包括需要約 20 MB 特定輸入才出現的 decompressor 越界寫入、需要 64 MB 輸入與超過 2 GB 記憶體的 image decoder 越界讀取，以及重新發現 libexpat 的 CVE-2026-56132。

文章也描述其他實驗：Claude 產生的 Rust Python interpreter 在 170 萬個隨機程式測試中，與 CPython 行為一致率為 99.95%；在另一個 PDF reader 的形式驗證工作中，研究團隊表示一週內找到的安全 bug 數量相當於通常一年回報的數量。這些數字與案例來自 Anthropic 的合作研究，並不等於所有程式都已被證明安全。

Anthropic 明確列出限制：形式驗證只涵蓋被寫入 theorem 的性質，實際機器可能與模型描述不同，規格、RISC-V 與 Linux 的形式模型，以及 Rocq proof checker 本身也屬於需要信任的元件。文章的驗證工作還可能消耗數億 token；它公開的結果是可供檢查的證明與規格，不是「沒有任何 bug」的通用聲明。

• 來源：anthropic.com

Agent Skills 標準移交 Agentic AI Foundation

Anthropic 宣布把 Agent Skills 的名稱、標誌、GitHub organization 與 agentskills.io 網域捐給 Linux Foundation 旗下的 Agentic AI Foundation（AAIF）。Agent Skill 是包含 SKILL.md、腳本與參考資料的資料夾，用來向代理提供特定任務的程序知識。Anthropic 表示，ChatGPT、Cursor、GitHub Copilot 與 VS Code 等超過 70 個代理平台已整合這項標準。

官方文章稱，自 2025 年 12 月公布標準以來，社群已發布 100 萬個 skills、安裝次數接近 2.8 億次。這些數字是 Anthropic 在公告中的統計，文章沒有提供完整計算方法或獨立審計結果。移交後，Anthropic、Google、OpenAI 等公司的工程師將以個人身分維護標準，David Soria Parra 與 Mahesh Murag 擔任 lead maintainers。

AAIF 的初步 roadmap 包含版本化發布、正式提案流程，以及給 skill 撰寫者與安裝者的安全指引。規格仍可在不加入 AAIF 的情況下使用與貢獻；公告也把安全指引列為接下來要建立的工作，而不是已完成的驗證機制。skill 能執行什麼操作，仍取決於載入它的代理平台、權限設定與使用者是否檢查內容。

• 來源：anthropic.com

一篇工程文章主張：LLM 自行產生的信心分數沒有校準依據

Amrut Joshi 在一篇工程文章中區分「模型說出一個數字」與「經過校準的信心」。文章以天氣預測為例，指出 70% 的預測只有在大量同類預測中約 70% 成真時，才具有可檢查的校準意義；同時，永遠輸出季節基準值的預測器也可能看似校準，卻沒有利用個別案例的資訊。

作者的論點是，LLM 產生 0.85 時，數字是依照上下文逐 token 生成的文字，不是從模型內部的機率計量表讀出的測量值。改寫問題、重問一次或改變數字前的文字，都可能改變輸出。文章因此建議，若客服代理需要把不確定案例交給人工，信心分數應由可重複的規則產生，並用實際結果持續更新與檢查。

這篇文章不是一組跨模型的校準實驗，也沒有提出適用所有代理的單一替代方法。它提出的必要條件是：分數要反映可取得的資訊，並且要在同類問題上與結果紀錄比對。若系統沒有保存每次回答與結果，就無法知道分數是否與實際正確率相符。

• 來源：rumple.github.io

文字浮水印不是在句子裡塞一個看不見的字元，而是在選下一個 token 時，留下可以事後打分的統計訊號。問題是：訊號看得見，是否就足以判斷來源？這次真的在 CPU 上跑了 96 份模型生成。正確密鑰下，兩個長度的水印測試樣本都檢出；但 128-token、未加水印的 12 份對照，也有 3 份被判陽性。

所以本文不只展示一張漂亮的檢出圖。我們先用一段純 Python 淘汰賽看清機制，再接 Hugging Face 的正式 SynthID processor，把取樣、有效位置、校準、誤報與文字重新分詞逐項攤開。這裡用的是公開小模型與自選實驗密鑰，不是能驗出真正 Claude 浮水印的工具。

原文摘要

起點是 Sebastian Raschka 在 2026 年 8 月 22 日發布的〈How Claude Watermarks AI-Generated Text〉：一段約 48 分鐘的影片，從 token 取樣一路說到浮水印與偵測。這是八月的技術講解，不是今天的新公告；以下主體是本站另外寫程式、跑模型得到的實作紀錄，而非影片逐字稿翻譯。^[1]

Anthropic 的技術頁說，Claude 使用 SynthID-Text 的一個版本，標記不靠隱藏字元；偵測回答的是 Claude 曾參與文字生成的可能性，不是「這一定由人寫」的反面證明。該頁目前列出的偵測 API 仍為符合條件組織申請的 private preview。本實驗沒有其正式密鑰、部署設定或商用偵測器，因此要驗證的是公開機制，不是假裝複製了整套 Claude 服務。^[2]

第一層：先看一個 token 怎麼贏淘汰賽

玩具程式的詞彙表只有 256 個 token，各自原始機率相同。每一步先抽 16 個候選，再打四輪兩兩淘汰賽。每輪的 g 函數，根據實驗 key、層數、前面三個 token 與候選 token，產生一個 0 或 1；遇到 1 對 0，就留下 1，平手才隨機選。

這是自製的教學類比，不是 SynthID 全部細節。玩具用 SHA-256 取 bit，正式版本另有 hashing、sampling table 與重複 context 處理，不能用玩具替正式版本的密碼學安全背書。

在專案目錄執行：

from main import toy_trace

trace = toy_trace(seed=42, key=123)
print(trace["original_candidates"])
for row in trace["rounds"]:
    print(row["layer"], row["winners"])
print("final:", trace["final_token"])

實際輸出是：

[57, 12, 140, 125, 114, 71, 52, 44, 216, 16, 15, 47, 111, 119, 13, 101]
0 [12, 140, 114, 44, 16, 15, 111, 13]
1 [12, 44, 15, 13]
2 [44, 13]
3 [13]
final: 13

第一對 57 與 12 的 bit 都是 1，所以這一對不是「12 比 57 更像正確答案」，而是平手後由固定 seed 的亂數選了 12。後面每輪換另一層的 g 判斷，最後 13 勝出。候選仍來自原來的取樣分布；密鑰改變的是淘汰時的偏好，不是另往文字插入標籤。

偵測時也不必重跑語言模型，只需在收到的 token 序列上重建 context，算同一組 g，看平均 bit 是否偏高。這個「生成時讓訊號偏高、事後用同一規則找回訊號」的配對，是 SynthID 論文的核心機制之一。^[3]

同一份 256-token 玩具輸出，實跑的 mean-g 為：

• 未加水印、正確 key：0.504941。
• 加水印、正確 key：0.754941。
• 同一份加水印序列、改用錯誤 key：0.500000。

這些是 bit 平均值，不是「75% 機率由 AI 寫」。玩具使用的 0.65 門檻也是明示的教學設定，不是校準過的實務誤報控制。

低熵對照：只有一個答案，淘汰賽沒有空間操作

再把每一步候選固定成 token 7。無論開不開水印，輸出都是同一串 7，因為根本沒有其他 token 可選。

更容易漏掉的是偵測端：256 個輸出位置，不等於 256 份新證據。排除不完整 context，再去掉重複 context，這串固定輸出只剩 1 個有效位置。程式回傳 detected: null，而不是把一個原始分數硬當成有把握的陰性或陽性。這個對照同時測了「有沒有選擇空間」與「有沒有新的有效位置」。

正式 SynthID processor 不會真的抽出海量候選

如果每層都把淘汰樹展開，層數一多就會很昂貴。Transformers v4.57.1 的 update_scores() 採用向量化重加權。對某一層，令 p 是目前 token 機率，g 是該層的 bit，可寫成：^[6]

mass = 所有 token 的 p × g 加總
新機率 = p × (1 + g - mass)

用本站自製的兩-token 例子核算：原本 p(a)=0.75、p(b)=0.25；若這把 key 在該 context 給出 g(a)=0、g(b)=1，則 mass=0.25，重加權後 a 為 0.5625、b 為 0.4375。相反的 bit 配置則得到 0.9375 與 0.0625。這些數值是依公式實算的教學例，不是 Claude 的實際詞彙分布。

因此，「不失真」不能解讀成每一把固定 key、每一步的機率都完全沒變。論文把不同強度的 non-distortion 分開定義，其中單 token 性質涉及對隨機種子取平均等條件；固定 key 下會出現可偵測偏好，正是我們要看的訊號。本文沒有品質盲測，也不拿分布性質替實際文筆品質打包票。^[3]

第二層：真正接上 CPU 語言模型

實驗不是把幾段人造 token 當成模型輸出。這一層載入 distilbert/distilgpt2，實際呼叫 model.generate()；兩組共用模型、提示與對應 seed，只有 watermarked 組傳入 SynthID 設定。

環境固定為 Python 3.11.15、Transformers 4.57.1、torch 2.8.0+cpu，CPU 使用 4 threads、1 interop thread。模型 revision 固定為：

2290a62682d06624634c1f46a6ad5be0f47f38aa

載入時不啟用 remote code，使用 safetensors，也不需要 API key。

生成設定是 temperature=1、top_k=40、top_p=1、do_sample=True。新生成長度分為 64 與 128 tokens；為了固定比較長度，兩者都設定 min_new_tokens=max_new_tokens，不讓這一段提早因 EOS 結束。這是在受控環境中固定長度，不是測自然結束回答的實際長度分布。

正式 processor 使用 5-gram、8 層實驗 keys，sampling table 大小 65,536、table seed 0、context history 1,024。這些公開設定可在 real_lab.py 查到，它們是本實驗選值，不是 Claude 正式設定。Hugging Face 的整合介面讓我們透過 watermarking_config 接入生成，不必重新訓練語言模型。^[5]

不能拿未訓練的 Bayesian detector 當答案

正式 SynthIDTextWatermarkDetector 需要已訓練的 Bayesian detector module。這次沒有假裝訓練了那個模型，而是用官方 processor 重建 g-values 與有效位置，再取簡單平均。DeepMind 參考實作也列有不需訓練的 Mean／Weighted Mean 路線，以及需訓練的 Bayesian 路線。^[4][7]

本站的打分核心直接對應實作：

import torch

ids = torch.tensor([tokens], dtype=torch.long)
g = processor.compute_g_values(ids)
mask = processor.compute_context_repetition_mask(ids)
mask &= processor.compute_eos_token_mask(
    ids, eos_token_id
)[:, processor.ngram_len - 1:]
score = float(g[mask].float().mean()) if mask.any() else None

這段為什麼不能簡化成把所有 bit 全部平均？因為前面四個 token 還湊不成完整 5-gram；EOS 後的內容不應算入；重複 context 也不該反覆充當新證據。程式先把 prompt 切掉，只對新生成部分打分，生成端也略過最初四次水印呼叫。編輯過序列後，整套 g-values 和 mask 都重新計算。

校準、測試、錯誤 key：三件事不能混用

每個長度各生成三組：

• 24 份 calibration plain：未加水印，只用來定門檻。
• 12 份 evaluation plain：未加水印，用來數誤報。
• 12 份 evaluation watermarked：加水印，用來數檢出。

校準與測試的 topics、prompts、seeds 分開；測試中的 plain 與 watermarked 用相同 prompt／seed 配對，是控制變項，不是兩批彼此無關的文件。這些都是少量手寫英文故事提示，不是代表真實世界分布的隨機抽樣。

總共是 96 次原始生成。每份再做四種條件、兩把檢測 key，因此留下 768 條打分紀錄；不能把它寫成 768 份獨立文章。

門檻採用一個透明但粗糙的方式：

threshold = max(calibration_scores) + 1e-12
positive = score > threshold

它依「原始長度 × 編輯條件 × 檢測 key」分成 16 組，各自只使用對應的 24 份未水印校準資料。錯誤 key 也有自己的 plain 校準／測試組，不是把錯誤 key 當成唯一陰性對照。

這樣必然讓本批 calibration 的超標數是 0/24，但這是設定的結果，不是誤報率保證。新的文件可能超過先前見過的最大值；校準與測試提示組的差異也可能改變分數分布。DeepMind 的參考說明要求在不同長度下另外考慮門檻，本次把這件事落實了，卻沒有因此得到商用校準的證書。^[4]

實測：水印全部檢出，未水印卻不是全部放行

綠柱是水印樣本檢出，紅柱是未水印樣本被誤判；柱上都保留分子／分母。正確 key 的結果如下，每一條都是另外保留的 12 份 evaluation：

原始 64 個新生成 tokens：

• 不編輯：水印檢出 12/12；plain 誤報 2/12；門檻約 0.531250。
• 留前半：水印檢出 12/12；plain 誤報 2/12；門檻約 0.540179。
• 刪除約一成 token：水印檢出 12/12；plain 誤報 1/12；門檻約 0.532407。
• 替換約一成 token：水印檢出 12/12；plain 誤報 2/12；門檻約 0.533333。

原始 128 個新生成 tokens：

• 不編輯：水印檢出 12/12；plain 誤報 3/12；門檻約 0.525202。
• 留前半：水印檢出 12/12；plain 誤報 0/12；門檻約 0.541667。
• 刪除約一成 token：水印檢出 12/12；plain 誤報 0/12；門檻約 0.544393。
• 替換約一成 token：水印檢出 12/12；plain 誤報 1/12；門檻約 0.543347。

錯誤 key 對水印樣本的結果也不是永遠零：64-token 的四種條件都是 0/12，128-token 未編輯組為 1/12，其他三組為 0/12。完整 JSON 另外保留錯誤 key 對 plain 的誤報數，而不是只挑有利的對照。

每種編輯條件都另外校準了門檻，這不是拿一個部署門檻盲測所有未知編輯。128 截成 64 的組別，也不是原始 64-token 組別。這批結果能說的是：在本設定與對應校準下，訊號經這些簡單編輯仍可檢出；同時，這個小型 mean-g 流程沒有可靠隔開所有未加水印輸出。不能拿 12/12 換成「偵測百分之百可靠」，也不能把這批誤報外推成 Claude 的誤報率。

編輯會改哪裡？先把 token 與文字分清楚

這次的變形不使用另一個模型重寫句子。截短是保留前半；刪除／替換則固定 seed，操作 floor(length/10) 個位置。因此 64-token 組動 6 個、128-token 組動 12 個，比例都是 9.375%，不是精確 10%。替換可能破壞字詞，沒有測語義是否保留。

5-gram 偵測看的是局部窗口。刪除一個 token，不只少了一個 token 的分數，也改變附近窗口；替換後的 token 和周邊 context 也會組成不同輸入。所以程式重新打分，不能把原來的有效位置遮罩直接搬過去。

還有一個比編輯更早出現的問題：同一串生成 token，轉成文字再重新 tokenize，不保證拿回相同 token IDs。

這次另外記錄 decode → encode 診斷，兩個長度合計、每份只算一次，不重複算兩把 key：

• 未編輯：plain 有 16/72 不相同；watermarked 有 7/24 不相同。
• 留前半：plain 12/72；watermarked 3/24。
• 刪除後：plain 28/72；watermarked 10/24。
• 替換後：plain 34/72；watermarked 13/24。

plain 的分母包含校準與測試；watermarked 只有測試，所以兩者分母不同。JSON 保存重新分詞後的 IDs、分數與有效位置數，但沒有把它們套原 ID 門檻就宣稱完成文字端評估。若下一步要做「貼一段文字就能測」的介面，必須先把解碼、正規化、重分詞與重新校準納入同一條管線；目前主結果嚴格停在 token-ID 層。

自己跑：先看機制，再跑模型，最後核對數據

完整程式、固定依賴、原始生成與逐筆打分放在 synthid-text-lab 專案。不需要 GPU 或付費模型 API；首次真模型實驗需要網路下載公開權重及套件。

git clone https://github.com/chengwulongxia-rgb/deep-dive-code.git
cd deep-dive-code/synthid-text-lab
uv sync --locked --python 3.11

# 純 Python：看 toy 分數與淘汰賽 trace，不下載模型
python3 main.py

# 正式 processor 與 CPU 模型；另放輸出，不覆蓋已發表數據
uv run python main.py --real --threads 4 --output results/rerun

本次 AMD Ryzen 5 5600GT 上，96 次生成本身合計約 225.42 秒；包含模型載入、打分與重新分詞診斷約 248.53 秒，不含環境安裝、繪圖與後續 audit。這不是所有電腦的執行時間保證，模型輸出也沒有接受品質盲測。

只想重畫已保存圖表，不需要再載入模型：

HF_HUB_OFFLINE=1 TRANSFORMERS_OFFLINE=1 uv run python main.py \
  --chart results/redrawn.png --input results/real.json

uv run python -m unittest -v
HF_HUB_OFFLINE=1 TRANSFORMERS_OFFLINE=1 uv run python audit.py --replay

本次 9 項測試通過。audit 重新計算 768 條 g-values／mask／score、16 組門檻，並核對校準／測試切分；另從 plain 與 watermarked 各取一份重生兩次，四次都逐 token 一致。這四次驗證不計入主要 96 份，也不拿來重新挑門檻。

要修改實驗，可從 real_lab.py 的 keys、ngram_len、提示組或生成設定開始。但換了設定，舊門檻不會自動繼續有效；應重新生成校準與測試資料，保留未水印 negative，然後重跑 audit。這比先替畫面放一個漂亮的「AI 機率」數字重要。

城武觀點

我支持把浮水印當成可查證的來源線索，反對把它升格成作者身分裁判。這次同一套流程能檢出全部水印測試樣本，也能把未水印對照中的三份判成陽性；連轉成文字再讀回，七份水印樣本的 token 序列都變了。真正要交付的不是一個分數，而是分數的有效條件。正式密鑰不必為了透明而公開，但持有密鑰、掌握驗證權的一方，仍應交代適用長度、校準分布、誤報與申訴方式。這份小實驗沒有評判商用 Claude 的能力；它讓我更不願接受只有「檢出」兩字、沒有檢查路徑的來源判斷。

城武的未解檔案——那個判你陽性的分數，也該附上它怎麼判錯的紀錄。

Sources

[2] Anthropic：How Claude’s text watermark works（2026-08-14，頁面列 2026-09-01 更新；2026-10-22 核對）

[3] Dathathri 等：Scalable watermarking for identifying large language model outputs（Nature，2024-10-23）

[4] Google DeepMind：SynthID Text 參考實作

[5] Google DeepMind／Hugging Face：Introducing SynthID Text

[6] Transformers v4.57.1：SynthID logits processor

[7] Transformers v4.57.1：SynthID detector 與遮罩處理

[1] 原文：How Claude Watermarks AI-Generated Text（Sebastian Raschka，Ahead of AI，2026-08-22）

🔥 LiteLLM 1.107.0 PyPI 發布被報告含竊取憑證程式與後門

SafeDep 報告稱，LiteLLM 1.107.0 的 PyPI 發布包含 cook.pth、cook.py 與 sitecustomize.py 三個植入檔案，所有七個平台 wheel 都受到影響。cook.pth 會讓 Python 啟動時載入 cook.py；報告列出的收集目標包括瀏覽器密碼與歷史、SSH 金鑰、雲端憑證、CI/CD 機密、AI 開發工具設定、環境變數與雲端執行個體 metadata。

報告指出，資料會以 AES-256-CBC 加密，再用內嵌的 RSA 公鑰包裝金鑰後送往 www.litellm[.]dev/healthcheck；sitecustomize.py 另會每小時讀取 GitHub 上的 domain.txt，下載並執行第二階段程式。LiteLLM 1.106.2、1.107.0rc1 與 1.107.0rc2 在 SafeDep 的檢查中未發現同樣植入物。

SafeDep 比對了 539 次公開 GitHub Actions 執行紀錄，沒有找到建置或發布 1.107.0 的公開 workflow。其評估是惡意 wheel 可能由遭修改的私人發布流程產生，但也明確表示只有 BerriAI 的 pipeline log 能確認入侵來源。報告列出受影響檔案的 SHA-256 與主機、網路 IOC，供部署者檢查。

• 來源：safedep.io

Claude Duet 以背景代理處理郵件、行事曆與營運工作

Anthropic 將 Claude Duet 列為研究預覽，描述為會主動整理需要使用者處理的事項、在背景執行任務，並在敏感操作前等待核准的代理。產品頁列出的示例包括每日摘要、準備會議與簡報、整理資料、尋找未付款發票，以及準備薪資與合約相關工作。

Claude Duet 使用 Claude 帳號的記憶、技能與 connectors，產品頁宣稱支援超過 6,000 個 connectors 與 plugins；它在自己的雲端電腦上使用已連接的應用程式。Anthropic 說，登入、核准與安全檢查在該環境中執行，使用者可以查看代理已完成和正在進行的工作。

目前使用條件是美國地區的 Claude Pro 與 Max 訂閱者加入 waitlist，Team 與 Enterprise 尚未包含在內；使用量與 Claude 其他功能共用方案額度，背景檢查也會計入額度。Anthropic 同時列出研究預覽的限制：代理可能誤讀對話、判斷錯誤的急迫性，或在兩次檢查之間漏掉新進訊息。

• 來源：claude.com

OpenAI 提出 Patch the Planet，協調 AI 發現漏洞後的修補流程

OpenAI 表示，過去兩個月曾與維護者、研究人員和安全服務商合作處理 PHP 的重大漏洞；其文章稱 Calif 使用 GPT-5.6 Sol 發現其中一個漏洞，Wiz 也獨立發現並通報兩個漏洞。PHP 維護者負責修補與發布，OpenAI、Wiz、Cloudflare 等團隊提供研究、技術支援與協調。

Patch the Planet 提出的流程包括確認上游漏洞、讓受影響組織預留處理時間、與政府夥伴協調、準備不同產品的更新，以及在修補程式可用後發布指引。OpenAI 也公開 PHP version checker 的 Codex skill，讓營運者檢查版本並依 PHP 與服務商指引判斷應套用的更新。

這套框架把提前通知的對象交給維護者依保護角色、處理時間與敏感資訊能力判定；文章沒有列出固定的審查機制或申訴流程。OpenAI 說已承諾提供 10 億美元的補助 Daybreak 存取額度給防禦者，並表示會調整阻擋濫用的分類器；公司同時把「誰需要提前知道」與披露窗口列為仍在徵求意見的問題。

• 來源：openai.com

GitHub 以逐 reference quorum 提高 agent-scale Git 寫入吞吐量

GitHub 工程團隊表示，99.99999% 的 repository 已同時存放在自有資料中心與 Azure，剩餘最繁忙的 repository 受到約 25 毫秒跨區 round trip 影響。現有 Spokes quorum 會等待所有健康 replica 回應，且整個 repository 的寫入在提交時持有鎖，最慢 replica 會影響每次寫入的延遲與吞吐量。

新設計把 quorum 的序列化範圍從整個 repository 縮小到單一 reference。不同 branch 的更新可以並行處理，只有寫入同一 reference 的操作需要互相等待。GitHub 表示，在使用真實流量的內部測試中，不同 reference 的寫入吞吐量提高約 3 到 4 倍、延遲也較低。

GitHub 也描述把 Azure Blob Storage 加入 quorum、作為不提供讀取的 virtual replica，讓 repository 資料持久化後，再依需求增加不加入 quorum 的 virtual read replicas。這些讀取 replica 會從 Blob Storage 暖機並在背景同步；GitHub 明確列出的尚未解決條件包括部分讀取工作仍需要即時同步，以及 quorum 仍是進一步提高寫入吞吐量的限制。

• 來源：github.blog

📡 其他值得關注

• 本站深度實作：SynthID 文字浮水印：以 CPU 跑 96 份模型生成，公開取樣機制、校準門檻、未水印誤報與重新分詞診斷；這是本站今日實驗，靈感來自八月的技術講解。→ 閱讀實作

• OpenAI 模型進入 Google Cloud Model Garden：OpenAI 與 Google Cloud 宣布合作，預計數週內提供模型與 Codex agentic workflows；Microsoft 仍是 OpenAI 的主要雲端夥伴，正式可用性尚未開始。→ 連結

Ben Congdon 在 2026 年 10 月 19 日發表〈Agentic Monitoring〉。這裡的 monitoring 不是檢查 AI 代理有沒有偏離任務，而是讓代理協助監控正式環境中的軟體服務。本文先整理他的原型主張，再用 Google SRE 的既有監控原則，拆解一個可供工程團隊評估的實作分工；後面的部署情境是本站設計示例，並非作者公布的產品，也沒有聲稱已在本站實測。

原文摘要

Congdon 提出的原型，把工作拆成三段：代理讀服務程式碼並提出監控計畫；程式框架執行計畫；訊號觸發後，再由代理調查並視需要交給人。他特別指出，讓模型持續自由行動，不如讓它產出監控規格、交給確定性系統執行，能減少雜訊與 token 使用。他的重點案例是版本發布、設定更新等變更點，而不是再做一個全年不休、反覆詢問「有沒有異常」的聊天機器人。原文描述的是作者的原型經驗與方向判斷，沒有提供足以重現精確率、召回率及成本的完整測試資料。

把「是否故障」和「為何故障」分開

要理解這個分工，可以先看 Google SRE〈Monitoring Distributed Systems〉提出的兩個問題：系統哪裡壞了，以及為什麼壞。前者是症狀，後者是原因。付款請求大量失敗是使用者正在遭受的症狀；資料庫連線被耗盡則可能是其中一個原因。兩件事不能只靠一段流暢解釋就視為已經證實。

SRE 章節主張，呼叫值班人的關鍵路徑應簡單、可靠、容易理解，並以延遲、流量、錯誤、飽和程度等訊號觀察使用者服務。同章也提醒，高頻率但低價值的通知會耗損人的注意力。這些要求不會因為加了 LLM 就失效：如果每一輪都讓模型自行選資料、解讀圖表，再決定要不要通知，事後便難以分辨這次沒有告警，到底是服務正常、資料漏取，還是代理這次換了判斷標準。

因此，這裡有一種合理的工程解讀：把不固定、需要讀懂變更內容的工作交給代理，把固定頻率取樣、檢查執行是否成功，以及何時觸發的規則留在可重跑的程式裡。這是依原型與 SRE 原則提出的設計分析，不是作者已交付的標準實作。

一個設定發布的例子：先產出可審核的觀測計畫

以下假設某個 API 要改快取設定。規劃代理可以讀變更差異、設定的使用位置，以及已有的儀表板，提出「這次應觀察哪個端點、哪個版本，以及哪些依賴」的計畫。若設定只影響特定請求，監控整台機器的平均 CPU，很可能沒有對準變更本身。

計畫的交付物不該只有「注意延遲和錯誤」。團隊需要看得到實際指標名稱、查詢條件、觀測區間、比較基準、樣本不足時怎麼辦，以及這份臨時監控何時結束。對照組可以是仍使用舊設定的實例，也可以是發布前的基準；但若流量時段、請求組成不一致，就不能把兩張圖的差距直接認定為版本造成的退步。

這些欄位是本站示例的驗收要求，不是 Congdon 公布的規格格式。作者沒有提供可直接複製的 schema、門檻或查詢，不能替他編一份再稱為官方設定。真正落地時，還得先確認指標有被採集、標籤確實能區分新舊版本，且代理提出的查詢在現有觀測平台上可以執行。

執行器：沒有查到資料，不等於一切正常

計畫通過檢查後，排程、查詢與條件判斷可以由固定程式執行。執行器除了記錄指標結果，也要記錄查詢本身是否成功：權限過期、資料延遲、標籤拼錯或樣本為空，應留下明確的「無法判斷」，不能被折算為綠燈。否則再好的分析代理，也只是在不存在的觀測結果上推理。

同時保留傳統的關鍵告警，是為了讓代理故障不會連帶取消基本保護。Google SRE 強調監控路徑的簡單性，對這裡的啟示並不是拒絕模型，而是別把最重要的故障訊號，綁在一個本身可能逾時、超出預算或缺少上下文的調查流程後面。相關原則也區分內部指標與外部可見行為；前者有助除錯，後者才能回答使用者此刻是否真的拿到正確結果。

調查代理：交證據，不只交一個原因

當快取命中率改變、延遲或錯誤訊號觸發後，代理才進入較昂貴的查證階段。它可以讀取相同時間區間的日誌、比對版本差異、檢查依賴服務，並列出支持及不支持各個假說的資料。模型提出「新設定使後端負載上升」，應該附得出查詢、時間範圍、受影響版本與仍缺少的觀測，而不是只產生一段看似完整的事故故事。

在這個示例裡，最初可以只授予唯讀權限，讓代理產出調查報告與回復建議。若要進一步允許回滾、擴容或重新部署，則需要另一條明確授權的動作路徑：可操作的資源、允許的變更、停止條件，以及如何確認動作沒有使其他服務惡化。這些是本站提出的實作邊界，不能把它們當成原文已驗證安全的功能。

怎麼驗收：便宜且會解釋，不等於偵測可靠

第一種可做的驗證，是回放已標記的歷史變更：把已知有退步、已知正常，以及資料不完整的情境分開，觀察計畫是否選對訊號、執行器是否忠實執行，以及調查報告是否能指出證據。歷史事件可以用於調整流程，但調整後仍應另留未參與調整的事件做檢查，避免只記熟幾次事故。

第二種是與原有告警並行、暫不授權代理操作正式環境。除了記錄抓到多少問題，也要看漏報、誤報、通知延遲、人工覆核時間與查詢負擔。若代理抓到更多異常，卻把值班人的工作變成逐條否決低品質報告，就不能只以「偵測數增加」宣布改善。這是本文依監控目的提出的驗收方案，不是作者已完成的對照實驗。

Congdon 的文章提供了一個值得研究的分工：模型負責產生和調查監控假說，確定性程式負責穩定地執行觀測。公開材料尚不足以判斷它在哪些服務、流量與事故類型上優於既有系統；要跨過這條界線，需要的是可回放紀錄、失敗分類與同條件比較，而非把「代理一直在線」當成可靠性的代名詞。

• 原文：Agentic Monitoring（Ben Congdon，2026-10-19）