文章
22 篇 · 關於 AI 應用研發、Agent 系統與工程實踐的筆記
01
Agent / Harness Engineering
關於 agent 記憶、工具設計、跨機協作和驗證面的工程筆記。
給 agent 的記憶瘦身：常駐和按需分層
記憶越攢越多，agent 每次啓動要讀的東西也越來越多，最後變成「什麼都記得，什麼都用不上」。我的做法是把記憶分成兩層：常駐層只放「我是誰、現在在幹什麼、最近動了什麼」，加起來十幾 KB；其餘都是按需檢索的主題文件。在我自己約 180 個記憶文件、三十多萬 token 的庫上，啓動時實際加載從約 7 萬 token 降到了幾百。這篇講分層的規則，以及哪些東西不該進常駐。
不懂 git，也能管住十幾個 worktree
git 是我明確的短板：多分支、rebase、衝突、讀提交圖都不熟，還闖過真實的禍。但現在我同時開着十幾個 worktree、幾個 agent 在不同分支上幹活，局面反而比以前清楚。辦法不是先把 git 學透，而是讓 AI 管 git，我只管幾條它必須遵守的紀律，以及幾個我隨時能問的問題。
兩個模型互審：合併前必須有第二意見
AI 寫代碼越快，人越審不過來。我的做法是讓另一個模型來審，但評審報告本身也是一份「自述」——照單全收，等於把另一個模型的幻覺寫進代碼。這篇講我在合併前加的這道「第二意見」：評審方怎麼選、提示詞怎麼寫、拿到結論後怎麼逐條驗證，以及幾個真實踩過的坑。
讓 AI 上夜班：定時任務、彙報口徑和幾條規矩
我用 AI 最大的變化，不是提示詞寫得更好，而是把它從「白天陪我對話」改成「我不在時也在幹活」。一台幾乎不關機的電腦上跑着十幾個定時任務：凌晨體檢、清晨查漂移並嘗試自動修復、上班前把一夜的結果匯成一份簡報。白天我只做三件事——選、看、合。這篇講這套做法：夜班怎麼排、自動修復怎麼套籠子、怎麼讓 agent 只説重點、糾正一次怎麼變成永久規則。
多 agent 並行開發：一套編排紀律
你負責定計劃、裁定、驗收，子 agent 負責寫代碼。這不是「把任務丟出去」，而是一套有紀律的編排。領地要劃在共享運行時狀態上而不是文件路徑上；任務信必須給出理由而不只是指令；執行方最有價值的輸出是「你的判斷錯了」而不是「做完了」。而整套裏最值錢的一條是：綠色不構成證據——因為你不再親手跑每一步，只能讀報告，「看起來對」和「真的對」輸出相同的風險被放大了。
一句話教你學會用 AI:寫日記
AI 回答平庸不是它不行,是它不認識你——它每次開口,都是第一次見你。解法不是背提示詞,是花 15 分鐘建一份「我的檔案」:我是誰、我要什麼、我卡在哪、我的偏好。每次提問先粘檔案,每週花五分鐘更新。這本「寫給 AI 看的日記」,就是你親手給它裝上的記憶,而且不鎖在任何一家的產品裏。
我把一個 git 倉庫做成了「工作操作系統」——AI Coding 的兩層工作流
大多數人用 AI 寫代碼，是把 AI 當一個更快的手。我的做法是分兩層：底層用一個 git 倉庫當「工作操作系統」，沉澱判斷、工具和給 AI 的行為指令；上層是一天之內收集需求、AI 執行、commit 生成日報的閉環。前者管「判斷怎麼不跑偏」，後者管「一天怎麼幹完」。
我在手機上發了條指令，另一座城市的 Mac 替我部署了博客
A2A mesh 第一次跑真實生產任務：手機經 hub 把部署任務派給 Mac 上的 agent，三個節點構建、發佈、驗證全閉環——包括一次如實回報的失敗和一次二次派單的收尾。從冒煙測試到基礎設施，差的就是這一步。
用 Telegram 給多機 AI Agent 做一個可見的指揮面
當 agent 分散在多台機器上時，真正難的不是把消息發出去，而是讓人能看見、能插話、能按設備路由。Telegram 的 supergroup、topics 和 bot 長輪詢剛好拼出了一層輕量指揮面。
我為什麼要做 Harness Engineering
AI 會寫代碼之後，真正稀缺的不是再會調一次 API，而是能把 Agent 放進一個可靠、可驗證、可協作的工程系統裏。這是我給這個 blog 定的主線。
把幾台機器上的 AI Agent 連成一張能互相調用的網
我有好幾台機器，每台都跑着 agent。讓它們能實時互相調用，最大的攔路虎不是協議，是 NAT。這是我搭一張多設備 agent mesh 的踩坑筆記。
AI Agent 工具翻車 9 次之後：我總結的 11 條設計原則
prompt 是建議，工具實現才是合約。9 次翻車後我才想明白，AI Agent 優化的主要矛盾根本不在 AI 那一側——是我沒把世界講對。
用 Git 給多個 AI Agent 同步一個會成長的大腦
Claude、Codex、Gemini、Hermes 跑在不同機器上，卻共享同一套規則、記憶與上下文——沒有插件，沒有服務器，只有一個 Git 倉庫。這是 nestwork 的設計筆記。
你的 Agent 應用，跑得贏大模型的進化速度嗎？
大模型每升一級，就可能讓你辛苦搭的 Agent 能力變成「原生開箱即用」。這是 AI 創業最核心的焦慮。我的判斷是：危險的是薄薄一層包裝，安全的是深深一口井。
02
職業轉型與能力階梯
在 AI 重畫能力邊界的這幾年裏，一個工程師對自己做的判斷和自檢。
幾個月沒手寫一行代碼，我怎麼衡量自己的產出
我已經幾個月沒手寫過一行代碼了，所有代碼都由 AI 生成，用同一個 git 身份提交。這讓舊的衡量方式全部失真：提交數大部分是機器的，代碼行數更説明不了什麼。我換了一套尺子——只看交付物，只問流向不問辛苦，把「驗、收、推、合」當成真正的瓶頸來管。這篇講這套尺子，以及它逼着我承認的幾件事。
技術貶值時代的轉型方向——從執行位挪到判斷位
「99% 崗位 3-5 年被 AI 替代」這個前提一半對一半錯，而錯的那一半恰好決定了轉型方向。真正貶值的不是技術，是按工時出售的執行；真正需要的也不是換方向，是換位置。
從前端到 Harness Engineering：我給自己定的三年方向
一個以前端為主的全棧工程師，為什麼把長期方向押在「為 AI Agent 設計能力邊界」這件還沒幾個人在做的事上。
人類相對 AI 的淨優勢——篩掉那些已經守不住的
別再用「AI 取代不了人的温度」這種話安慰自己。我試着把人類相對 AI 的優勢項一條條篩一遍，把守不住的劃掉，看看真正剩下什麼。
AI 會寫代碼了，非科班還要補 CS 基礎嗎？
我是半路出身的全棧，AI 能幫我寫一大半代碼。那還有必要回頭補計算機科班的基礎嗎？我的答案是：有必要，但要挑重點。
AI + Agent 時代，程序員的能力階梯
AI 會寫代碼之後，程序員的價值不再是「會敲」，而是沿着一條能力階梯往上走——從會提問，到會定義問題。這是我畫的兩張階梯。
03
獨立產品實驗
小工具、內容系統和真實付費場景的產品取捨。