我為什麼要做 Harness Engineering
先把話説直
我現在最想長期投入的方向，是 Harness Engineering。
這裏的 harness，不是一個漂亮的新名詞。它指的是 AI Agent 真正跑起來時外面那一整套工程框架：它能調用哪些工具、不能碰什麼；它跨會話怎麼保留記憶；多個 agent 怎麼協作；它做完一件事之後，系統怎麼知道它真的做對了，而不是隻是看起來像做對了。
模型會繼續變強，寫代碼、查資料、生成方案都會越來越便宜。越是這樣，越不能把自己的價值押在「我會讓模型多輸出一點東西」上。真正值得押的是另一件事：我能不能把模型放進一個可靠的工作系統裏。
這就是我理解的 Harness Engineering。
我的起點不是研究員，是工程師
我的主棧是 Vue 3 / TypeScript，也在往 Next.js / NestJS 全棧延伸。過去很長一段時間，我的價值主要體現在實現能力上：把需求拆開、把界面做出來、把接口接通、把系統跑起來。
但 AI 輔助編碼之後，這條路的天花板在變矮。不是前端不重要了，而是「會寫」本身越來越不稀缺。Agent 能幫我寫大量代碼，甚至能並行做多個分支任務。這個變化逼我重新問自己：三年後，我到底靠什麼和別人拉開差距？
我的答案不是去追更大的平台敍事，也不是一頭扎進模型訓練。那兩條路都不是我當前手裏的最佳牌。
我更適合從工程系統入手：把一個模糊的 agent 協作問題拆成邊界、協議、記憶、驗證、工具合約這些可落地的模塊，然後用真實項目一點點驗證。
四個真實項目，分別驗證一層
這個 blog 裏的文章不是隨手寫的觀點集合，它們背後對應的是我正在做或已經做過的實驗。
Nestwork 驗證的是記憶和協作協議。
我用 Git 給多台機器、多個 agent 同步同一套規則、策略和記憶。每個 agent 有自己的目錄，人類維護只讀的治理層，共享記憶通過 distillation 彙總。它不是為了炫技，而是在解決一個具體問題：agent 不能只靠一場對話活着，它需要跨機器、跨會話的上下文真相源。
A2A mesh 驗證的是實時互調的數據面。
Git mailbox 適合慢速交接，但不適合秒級調用。於是我把多台機器上的 agent 通過 A2A 和 worker-pull 連起來。真正的難點不是協議本身，而是 NAT、常駐、安全和結果回填。跑通之後，我更清楚地意識到：連通性只是入場券，下一層必須是驗證面。
cheat-on-content 驗證的是校準迴路。
內容創作看起來和 agent 無關，但底層問題一樣：面對一個黑箱系統，不能靠事後解釋安慰自己，而要提前預測、鎖死預測、回收數據、覆盤偏差、迭代 rubric。它是「可驗證性」在內容領域的落地。
Duovid 驗證的是小工具產品紀律。
它不是宏大的 AI 平台，而是一個很具體的問題：一次拍攝，同時產出橫版和豎版。這個項目提醒我，獨立開發不該總是被平台化誘惑帶走。小而可驗證的工具，反而更容易檢驗真實需求。
真正的主線：給智能體裝邊界和痛覺
把這些項目放在一起看，主線其實很清楚：
- Nestwork 解決「agent 怎麼記住和交接」；
- A2A mesh 解決「agent 怎麼跨機器實時互調」；
- cheat-on-content 解決「不確定系統怎麼校準」；
- Duovid 解決「一個工具型產品怎麼剋制地驗證價值」。
它們看起來分散，但都在服務同一個目標：讓我從「會用 agent」往「會設計 agent 系統」走。
其中最關鍵的一層，是驗證。
沒有驗證的 agent 系統很危險。它可以跑很久、產出很多、看起來很忙，但它錯了自己不知道。人盯着的時候還能兜底；agent 數量變多、運行時間拉長之後，人就會變成瓶頸。系統必須自己有痛覺：每個任務帶可機器判定的驗收契約，結果能回看，錯了能觸發修正。
這也是我接下來最想補的短板。
這個 blog 應該怎麼讀
如果你想看我的方向判斷，先讀這篇，再讀《從前端到 Harness Engineering》。
如果你想看具體項目，讀 Nestwork、A2A mesh、cheat-on-content 和 Duovid。
如果你想看我對 AI 時代程序員能力的判斷，讀能力階梯、CS 基礎和人類相對 AI 的淨優勢。
這不是一個已經完成的答案集。它更像一個公開的工程日誌：我把判斷寫下來，用項目去驗證，然後等現實打臉。打臉不是問題，沒有記錄、沒有校準、沒有下一步，才是問題。
Harness Engineering 對我來説也不是一個頭銜，而是一條練習路線：少講空泛的 AI 感想，多做能跑、能驗、能覆盤的系統。