跑了 52 個 session。該改的通常是工作方式
我越來越覺得，很多人把 agent 用不順，第一反應都錯了。
先去換模型，換 prompt，換一套新框架。這些以前做過，也不是完全沒用。但如果同一種 friction 每天都在發生，問題多半已經不在那一層了。
我看到一個案例，對方讓 agent 回頭檢查 52 個 sessions，把自己最常卡住的地方拆出來。像是：
- 每次都要追問它剛剛用了什麼 skill。
- 回覆格式不固定，後面接手很痛苦。
- 更新過後規則漂移，agents 跟 user file 開始互相打架。
這種整理有價值的地方，不是 52 這個數字本身。重點是你終於把模糊的抱怨，壓成可執行的規則。
我自己比較相信的做法，是把高頻摩擦直接寫回系統檔，當成 environment 的一部分維護。比如固定 footer 要交代哪些資訊，什麼情況要先做 audit，升級之後哪些 drift check 一定要重跑。這種 pattern 一旦寫進去，後面每個 session 都會一起受益。只靠當下那句 prompt，效果通常撐不久。
Production 系統也是同一個道理。error 如果每週都重演，你不會叫 on-call 工程師下次小心一點，你會補監控、補 guardrail、補 runbook。agent 也是。真正開始有用的時間點，往往不是它第一次把事情做完，而是你開始把摩擦點系統化，讓它下一次少犯同一種錯。
說穿了，agent 不是會做事就夠。它得跟你的工作方式一起收斂，不然只是另一種比較會講話的脆弱系統。
作者：鍵盤工人