Direction
多 Agent 系統
研究如何給 AI Agent 設計能力邊界、記憶、協作協議和驗證迴路。
杨青峰 Qingfeng Yang
歌贼王·@songth1ef
AI 應用研發工程師 · 把 Agent 做成能上線的系統
做 AI 應用與 Agent 系統研發。日常主線是把大模型能力接進真實業務系統——從前端到後端到部署鏈路，一個人能端到端交付。
主棧 TypeScript（Next.js / NestJS / Vue 3），同時在做多機 Agent 協作：跨機共享記憶、Agent 之間的異步協作協議、可機器判定的任務驗收——已經在真實任務上連續跑通。
關心的是可驗證性和自動化槓桿：一個系統能不能自己判斷做對沒有，比它跑起來更重要。
當前主線
Projects
用真實項目驗證判斷
Nestwork、A2A mesh、cheat-on-content 和 Duovid 都是不同側面的實驗。
Writing
把經驗沉澱成可複用資產
文章不是觀點堆疊，而是把項目裏的取捨、踩坑和方法論寫清楚。
技能棧
鏈接
最近文章
全部 →給 agent 的記憶瘦身：常駐和按需分層
記憶越攢越多，agent 每次啓動要讀的東西也越來越多，最後變成「什麼都記得，什麼都用不上」。我的做法是把記憶分成兩層：常駐層只放「我是誰、現在在幹什麼、最近動了什麼」，加起來十幾 KB；其餘都是按需檢索的主題文件。在我自己約 180 個記憶文件、三十多萬 token 的庫上，啓動時實際加載從約 7 萬 token 降到了幾百。這篇講分層的規則，以及哪些東西不該進常駐。
幾個月沒手寫一行代碼，我怎麼衡量自己的產出
我已經幾個月沒手寫過一行代碼了，所有代碼都由 AI 生成，用同一個 git 身份提交。這讓舊的衡量方式全部失真：提交數大部分是機器的，代碼行數更説明不了什麼。我換了一套尺子——只看交付物，只問流向不問辛苦，把「驗、收、推、合」當成真正的瓶頸來管。這篇講這套尺子，以及它逼着我承認的幾件事。
不懂 git，也能管住十幾個 worktree
git 是我明確的短板：多分支、rebase、衝突、讀提交圖都不熟，還闖過真實的禍。但現在我同時開着十幾個 worktree、幾個 agent 在不同分支上幹活，局面反而比以前清楚。辦法不是先把 git 學透，而是讓 AI 管 git，我只管幾條它必須遵守的紀律，以及幾個我隨時能問的問題。