三週後的 Harness：從工程方法論到 AgenticOps
三週前我發表了《Harness Engineering 方法論：從 CLAUDE.md 到自進化的 AI 開發體系》，整理了我的五層架構。
文章最後列了幾個「仍在演進」的方向：Knowledge Graph MCP、自主部署驗證回滾、SBE 深化、多 Agent 協作。
今天（2026-05-04）是一個觀察自己進步的好時機。
AgenticOps：四階段持續循環
AgenticOps 的核心是一個永不停止的四階段閉環——每一輪循環結束後，系統比上一輪更聰明、更可靠。
清點三週的進展
✅ 已落地：Knowledge Graph MCP
文章中把 Knowledge Graph MCP 列為「Phase 2（50 頁時啟動）」的計畫。
現狀：知識圖譜 MCP 容器已在生產環境跑了幾週。REST API 提供全文搜尋、概念查詢、關聯圖遍歷三個端點，每次接到新需求時的第一步就是查詢確認影響範圍。wiki 頁面突破 121 頁，實體/概念/策略/系統架構/工具等分類齊全。
今天更進一步：知識庫的 export 流水線完成最後一哩路——
前端觸發 export → API 服務送到訊息佇列 → 知識庫寫入服務消費 → 寫入 vault → git commit + push 到 GitHub 這個流水線有個有趣的故事：dispatch 端（送訊息的一端）三個月前就建好了。但消費端從來沒被部署。Queue 裡積壓了幾十條訊息，每次 export 都等滿 15 秒 timeout 才失敗。「生產者已上線、消費者未實作」 的架構缺口，在這個 session 才被補上。
教訓：API 能呼叫、200 OK、沒有錯誤訊息——不代表功能正確。
✅ 已落地：自主診斷（L3 Auto-Fix Scanner）
文章中的「自主部署-驗證-回滾」被我描述為未來方向：
AI 部署後自動查詢 Prometheus 指標。如果 CPU/memory 超過閾值，自動回滾。
今天的現實更有趣，也更務實。
三週的演化路徑是這樣的：
Phase O（5/2 完成） → 全服務對齊可觀測性全家桶（OTel + Loki + Tempo + Prometheus） → Alertmanager + Telegram 整合（不再需要人工看監控面板） L0-L1（4/7 完成） → Prometheus alert → autoheal 自動重啟 → 健康監控服務（每 5 分鐘三層掃描） L2（4/7 完成） → 健康監控服務主動偵測 + Telegram heartbeat L3 Slice 1（5/3-5/4 完成） → 三路偵測：Prometheus firing + Tempo error traces + Loki ERROR logs → 雙路 AND fusion（Tempo ∩ Loki，避免 false positive） → Dry-run fix proposal 持久化到系統狀態目錄 → 排程每 15 分鐘自動觸發 L3 Slice 1 是 dry-run 階段：它偵測、分析、產提案，但不執行任何修改。這是刻意的設計——在 ≥ 5 個提案精準度 ≥ 95% + 48-72 小時觀察期之後，才進入 Slice 2 的 production mode。
這個設計有個重要洞見：自動化信任需要被賺取，不能被假設。
✅ 已落地：多 Agent 協作
文章中描述多 agent 是「當單一 agent 能力達到天花板時的下一步」。
實際上它在三週內就常態化了。今天的工作流包含：
- 並行 subagent 執行獨立的診斷任務
- Explore agent 用於大範圍 codebase 搜尋
- 三方並行審核（主程序 + Sonnet + Gemini）在重大架構決策前強制執行
重要的是：多 agent 協作不是「大任務時才用的特殊模式」，而是日常工作流的一部分。
📈 比預期走更遠：L3 的設計哲學演化
文章的「自主部署-驗證-回滾」隱含了一個假設：發現問題 → 自動修復。
但三週的實踐揭示了一個更微妙的問題：什麼叫做「問題」？
L3 scanner 的雙路 AND fusion rule 是這樣設計的：
有效 incident = Tempo error trace ∩ Loki ERROR log（同 TraceId） 今天 Tempo 出現了若干 HTTP 錯誤 traces，但 Loki 一條對應 ERROR log 都沒有。這些是 HTTP 4xx responses，是 expected behavior，不是 incident。
如果用單路偵測，會產生多個 false positive proposals。雙路 AND 過濾後，0 proposals，靜默釋放。
這個設計決策背後的思考是：過度告警的 self-healing 系統是有害的，因為它會被人類忽略。就像每次都報假警的火警系統，大家開始習慣不理它。
真正有用的自愈系統，必須「沉默時讓人信任它，發聲時讓人重視它」。
一個沒有預見到的新模式
文章描述的五層架構，有個隱含的假設：Harness 是靜態的。 它是固定的規則、固定的工作流、固定的知識結構。
三週後我發現，最有趣的演化不在任何一層，而是在層與層之間的動態連結。
今天的一個例子：
- 使用者回報「均值回歸策略的交易標的範圍設定看起來沒有生效」（Telegram）
- 診斷路徑：查日誌 → 發現個股訊號穿透到限定標的帳戶 → grep 程式碼 → 找到自動交易處理器模組缺少帳戶層的標的範圍過濾
- 修復部署
- 使用者確認行為預期，反問停損模式
- 分析停損根因（修復前的舊倉 + 市場分歧，非程式碼問題）
- 發現部位大小計算器以「當前淨值」而非「初始資金」作為建倉基準
- 使用者確認設計意圖，修復
整個流程大約 90 分鐘，橫跨了：Telegram 指令 → Loki 日誌診斷 → 程式碼 grep → 設計決策確認 → 修復部署 → 使用者驗證 → 繼續診斷 → 再修復。
這不是 skill 執行，不是 hook 觸發，也不是 wiki 查詢——它是整個系統動態協作的結果。
這讓我想到一個新定義：
Harness 的成熟標誌，不是單個機制有多強大，而是這些機制在真實問題面前能多流暢地組合在一起。
量化：今日的修復清單
以下是今天這個 session 完成的工作，可以對照文章中的原始 baseline：
| 問題類型 | 描述 |
|---|---|
| 隱性業務規則 | 結算日假日往後順延邏輯錯誤，補假後的結算日不被識別 |
| 可觀測性基礎 | Tracing 系統達到容量上限，全服務 trace 匯出失敗 |
| Dead config field | 帳戶層的交易標的範圍設定存在但未接線到執行路徑 |
| 設計意圖偏差 | 部位大小計算器使用動態淨值而非固定初始資金作為基準 |
| 架構缺口 | 知識庫寫入服務從未部署，訊息佇列積壓數十條 |
| L3 噪音過濾 | Phase 1B 裸 HTTP 方法 trace 過濾規則 |
六個不同類型的 bug，在同一個 session 內全部診斷並修復——這是 harness 成熟的直接體現：每個工具發揮它該發揮的角色，組合在一起才有這樣的效率。
最大的反思：「衡量」的層次升級
文章中的第三個核心洞見是「衡量改變了一切」，那時的衡量是手動的 friction 矩陣——每週回顧 Insights 報告，統計各類問題發生次數。
三週後，衡量本身也自動化了。
L3 scanner 每 15 分鐘做的事，本質上是：系統在衡量自己的健康狀態。Prometheus 記錄指標，Loki 收集日誌，Tempo 追蹤 error，L3 的 dual AND fusion 判斷什麼是真實問題、什麼是噪音。
從「人工定期看儀表板」到「系統持續自我觀察」，衡量的角色從被動記錄變成了主動監控。
這個轉變帶來了一個新問題：如果系統能觀察自己，下一步是什麼？
答案在 L3 Slice 2 的路線圖裡。但更重要的是，這個問題本身揭示了一個方向：Harness Engineering 正在演化成 AgenticOps——不只是讓 AI 可靠運作的工程體系，而是讓 AI 系統能自我維護的運營體系。
一個尚待突破的盲點：E2E 測試覆蓋率
在整理這些進展的同時，我注意到一個缺口：
SBE 覆蓋了需求理解，但尚未覆蓋 E2E 測試覆蓋率。
4/12 文章中提到 SBE 可以擴展到 Performance SBE、Observability SBE、Contract SBE。我們在 L3 的 Observability SBE 方向走得很深。但最近觀察到一個趨勢——許多開源 AI Coding Agent 相關專案開始強調的不只是「讓 AI 寫測試」，而是「E2E 測試對程式碼變更的覆蓋率」。
傳統的 unit test coverage 衡量「測試覆蓋了多少程式碼行」。但在 AI-assisted 開發中，這個指標有個盲點：AI 同時寫測試和實作，覆蓋率可以很高，但測試可能只是在驗證 AI 自己的假設，不是在驗證真實的業務行為。
E2E 覆蓋率的方向更有趣：
SBE 定義的例子 → 自動化 E2E 場景（Given/When/Then → Playwright / API test） → 每次程式碼變更驗證 E2E 通過 → 追蹤「哪些 SBE 例子目前有 E2E 覆蓋，哪些沒有」 這不是「測試覆蓋率」，而是「需求覆蓋率」——有多少 SBE 例子被 E2E 自動化保護。
目前我還沒有看到成熟的框架將 SBE 例子和 E2E 自動化場景自動關聯、追蹤覆蓋率。這可能是 AI-assisted 開發工具鏈的下一個演化點。
下一步
從今天的工作可以看出一些未完成的方向：
L3 Slice 2：dry-run 提案的精準度觀察期需要達到 ≥ 5 個有效提案 + 精準度 ≥ 95%。目前只有 1 個提案（近期的 Redis 重載事件）。
知識庫寫入服務的權限問題：容器以特權身份建立的檔案需要手動調整擁有者。改為非特權用戶執行可以根本解決。
L3 Slice 2 的自動執行：當觀察期結束，下一步是讓 L3 真正執行修復——而不是只寫 dry-run proposal。這是從「自我觀察」到「自我修復」的關鍵一步。
SBE + E2E 覆蓋率：將 SBE 例子和 E2E 自動化場景建立系統性關聯，追蹤「需求覆蓋率」而非只是程式碼行覆蓋率。
三週前的文章結尾說：「能衡量自己的 harness，才是能改善的 harness。」
今天的補充是：能觀察自己的系統，才是能進化的系統。
使用 Claude Code 建構與實踐。