一個人累積了大量筆記，不代表系統知道他現在會什麼。讀過一篇 MCP 教學、收藏一份架構簡報、完成一次部署，三者都是紀錄，卻代表不同程度的能力。若 Personal Context 只保存文件、偏好與歷史對話，Agent 也許更了解你談過什麼，仍然不知道哪些概念只是看過、哪些操作能獨立完成、哪些能力在新的情境裡依然站得住腳。
這正是知識庫與學習系統的分界。知識庫主要回答「有哪些內容可以找回」；學習系統還要回答「這個人現在走到哪裡、下一步該練什麼、進步的判斷有什麼證據」。如果希望 Personal Context 最後能改善 Agent Experience，就不能只保存人的背景，也要保存人的變化。
Personal Context 不只描述「我是誰」，還要描述「我正如何成為下一個版本的自己」。
同一份內容，不等於同一種學習狀態
傳統內容系統很容易把「讀過」當成「知道」，再把「知道」當成「會做」。但從實務來看，學習至少有幾種不同狀態：第一次接觸、可以辨認、能夠回想、能在提示下操作、能獨立完成、能跨情境應用，以及能說明自己的判斷與限制。
這些狀態不能只靠完成百分比表示。影片看完一百％，不代表能在沒有範例時設定 OAuth；一份題庫答對，可能只是記得選項；一次專案成功，也可能是 AI 完成大部分工作，而使用者還不能診斷失敗原因。
Zimmerman 在〈Achieving Self-Regulation: The Trial and Triumph of Adolescence〉中的整理把學習看成包含事前規劃、執行監控與事後自我反思的循環。這個理論支持的不是某一組固定欄位，而是一個重要原則：學習狀態會隨目標、策略、表現與反思更新，不能被一筆靜態標籤取代。
因此，我把 Personal Context 裡的學習資訊分成三個相互連接、但不能混為一談的部分：Learning State、Capability Evidence 與 Growth Trajectory。這是本文提出的操作模型，不是既有標準的重新命名。
Learning State 記錄現在站在哪裡
Learning State 是「此刻」的狀態，不是永久的人格描述。它至少要包含：正在追求的目標、已接觸的概念、現在能完成的任務、仍需提示的環節、常見誤解、信心判斷，以及下一個合理挑戰。
例如，一位學習 Agent 架構的人可能理解 MCP 的用途，也能照文件啟動 server，但還不能獨立設計權限邊界。若系統只記得「學過 MCP」，下一次不是重複講入門，就是直接給出超過負荷的架構題。較好的 Context 會說明：概念理解已有證據，基本操作曾成功，授權設計仍是缺口，而且上次失敗發生在 token scope 判斷。
Learning State 也要允許不確定。系統可以記錄「上一次成功，但尚未跨情境驗證」，而不是把一次表現永久升格為精通。學習狀態的價值不在精密打分，而在幫助下一次任務選擇適當難度、提示量與驗證方式。
Capability Evidence 回答憑什麼說會了
能力證據不是自我感覺，也不是 Agent 對使用者的恭維。它應該連到可檢查的表現，例如：在沒有逐步提示下完成任務、符合事先定義的測試、能解釋取捨、能找出錯誤、把方法轉移到新案例，或產出被真實使用的交付物。
一筆較完整的 Capability Evidence 至少要保留：
- 任務：當時真正要完成什麼，而不只是一個主題名稱。
- 條件：可以使用哪些工具、收到多少提示、時間與風險限制為何。
- 產物：程式、文件、決策或操作結果在哪裡。
- 評估：由測試、規準、人工審閱或真實 outcome 判斷，而不是只讓原 Agent 自評。
- 範圍：這份證據能支持哪種能力，還不能支持什麼。
ISO/IEC/IEEE 39274-1-1:2025（xAPI）規範以 JSON 資料模型與 REST API 傳遞活動經驗資料至 Learning Record Store，提供跨系統記錄與存取學習經驗的基礎；但「做過某件事」仍不自動等於「已具備能力」。事件紀錄是原料，能力判斷還需要任務條件、品質標準與結果證據。
這個區分在 AI 協作裡更重要。若 Agent 幫忙完成大部分工作，系統應記錄人在哪些步驟做了判斷、修改與驗收，而不是把整份交付都算成人的能力。反過來，使用 AI 也不該被當成證據失效；能否正確分工、檢查產出、辨認風險，本身就是需要證明的能力。
Growth Trajectory 保存變化，不只保存快照
單一測驗或單次專案只能看到一個點。成長軌跡要看的是：在相似任務中，需要的提示是否減少、判斷是否更穩定、能否處理更高變異的情境、同一錯誤是否重複出現，以及原本的弱點有沒有經過練習轉成可靠能力。
軌跡也不是一條只能向上的折線。能力會因長期未使用而退化，環境改版會讓舊方法失效，換到高風險情境時也可能需要重新驗證。好的 Growth Trajectory 會保留證據時間、版本與情境，允許系統說「曾經做得到，但現在的證據已過期」。
ICAP framework把學習參與區分為被動、主動、建構與互動等模式，並提出不同參與方式與學習結果的理論關係。它提醒我們，停留時間與點擊次數是活動訊號，不是成長本身。真正有辨識力的軌跡，應優先保存使用者產生的解釋、做出的比較、修正的錯誤，以及與他人或 Agent 互相挑戰後形成的新理解。
Personal Context 如何把三者帶回下一次任務
保存學習資料不是為了做更漂亮的 Dashboard，而是為了改變下一次互動。任務開始時，Agent 可以先讀取與目標相關的 Learning State，再取回足以支持判斷的 Capability Evidence，最後根據 Growth Trajectory 決定要直接交付、給局部提示，還是先安排一次練習。
這裡需要一個界線：效率任務與學習任務不能用同一套介面。當使用者只想快速完成低風險例行工作，Agent 可以多做一些；當目標是形成能力，Agent 就不該一開始把完整答案交出來，而應保留讓人提取、判斷、實作與驗證的空間。Personal Context 要保存的，不只是「這個人喜歡簡短回答」，還包括「這次互動的目的到底是交付，還是學會」。
任務結束後，也不要把所有對話寫回長期狀態。比較穩定的更新順序是：
- 保存任務與條件，避免把不同難度的表現混在一起。
- 取得可獨立查驗的 outcome 或審閱結果。
- 判斷它是否構成新的能力證據，或只是一次未驗證的嘗試。
- 更新現在的狀態與下一個練習，而不是直接改寫永久 Profile。
- 經過多次、跨情境證據後，再調整較長期的成長判斷。
最小可行做法：先追蹤一項真實能力
不需要先建立龐大的能力模型。可以挑一項近期會重複使用、又有明確結果的能力，例如「能獨立把一個 MCP server 接到客戶端並完成權限驗證」。先定義四件事：什麼任務算數、允許多少協助、成功如何驗收、多久後需要再次確認。
每次執行只多記錄幾個欄位：任務版本、提示程度、產物、結果、卡住的位置與下一步。三到五次之後，再看系統能否回答：使用者現在能獨立做到哪裡？哪一種錯誤仍反覆出現？下一個任務應增加什麼變化？哪些證據已過期？
如果回答不了，問題通常不在模型不夠聰明，而在 Context 只保存了內容，沒有保存成長所需的狀態與證據。
Personal Context 最後要服務的，不只是個人化回答。它應讓 Agent 知道何時提供答案、何時保留練習空間、何時要求驗證，也讓使用者能看見自己的能力是如何形成。知識庫讓過去找得到；學習狀態、能力證據與成長軌跡，才讓過去真正參與下一次成長。