AI Agent 的工具已經很多：記憶系統保存對話，知識庫提供資料，Skills 封裝做法，MCP 連接外部能力，評估框架檢查結果，反思機制再把經驗寫回去。每個構件都有人研究，也都有實際專案。

可是，工具增加不等於 Agent 更了解你，更不等於它下一次會做得更好。常見狀況是：記憶保存了一堆內容，執行時卻沒有取到真正需要的資訊；Agent 能呼叫很多工具，卻不知道哪一個結果才算完成；任務結束後產生了檢討，下一次仍然重犯同一個錯誤。

真正的賣點，是打造自我掌握的 Personal Context。 它不是讓 Agent 記住更多，而是讓使用者掌握哪些脈絡可以保留、修正與延續。這些脈絡進入這一次的互動，目標是讓使用者的 Agent Experience 更好；經過真實結果驗證後再回寫，則為下一次任務結果建立更好的起點。

這條路徑還有第三層：人的能力成長。任務完成，不代表使用者已經學會；Agent 保存經驗，也不代表系統已經形成可靠能力。只有當人曾經提取、判斷、實踐與修正，而系統也把外部結果整理成可查證的學習狀態與經驗資產，這一次工作才可能同時改善下一次 Agent Experience，並支持 Human Capability Growth。

問題不在於缺少工具，而是這些工具多半各自解決單一環節。Personal Context → Agent Experience 的價值，是把個人脈絡、任務狀態、行動能力、結果驗證、反思與經驗回寫，串成一個完整的運作循環。

本文不是發明 Personal Context、Agent Experience 或 BYOC。這些概念，以及 Memory、Skills、MCP、Reflection 等構件，早已分別存在於研究、標準與產品之中。我的工作，是把分散的構件放進同一條可實作、可驗證、可治理的路徑，讓它們不再只是各自好用的小工具。

為什麼單點工具還組不成個人 Agent

一個能搜尋筆記的 Agent，不一定知道你此刻在做哪個專案；一個記得偏好的 Agent，不一定知道這次任務有哪些限制；一個能操作軟體的 Agent，也不一定能判定操作後的真實狀態。這些缺口分別落在脈絡、狀態、行動與驗證，不會因為多裝一套向量資料庫就同時消失。

CoALA 把語言 Agent 放在記憶、行動空間與決策流程的整體架構中理解；MemGPT 以分層記憶處理有限 context window；Generative Agents 則展示記錄、反思、檢索與規劃之間的關係。這些研究共同指出一件事：記憶不是孤立的儲存功能，而是決策與行動流程的一部分。

另一方面，Model Context Protocol 定義 Agent 如何透過一致介面取得 resources、prompts 與 tools；Agent Skills 規格 讓程序知識可以被漸進載入；AGENTS.md 讓專案指令能隨程式庫一起移動。它們解決的是連接與封裝，卻不會自動替使用者決定什麼該記、何時該取、結果是否正確，以及錯誤經驗能不能進入下一輪。

因此，真正需要設計的不是更多元件，而是元件之間的責任與交接。

Personal Context 不是把所有資料塞進提示詞

我把 Personal Context 當作一個工作概念：與某個人及其眼前任務相關，而且足以影響 Agent 判斷的脈絡集合。為了能實作，我先用四層工作分類整理它：

  1. Profile：相對穩定的角色、偏好、責任、權限與表達方式。
  2. State：此刻的目標、任務進度、未決事項、限制與環境狀態。
  3. Knowledge：有來源、有適用範圍、能支援判斷的領域知識。
  4. Experience：過去行動、實際結果、修正原因，以及已被驗證的做法。

自我掌握，代表擁有脈絡的控制權

「自我掌握」不是把所有資料集中到一個新平台，也不是讓每個 Agent 無限制同步全部記憶。它代表使用者能控制 Personal Context 的來源、內容、使用範圍與生命週期：知道資料從哪裡來、能修正錯誤、能撤回過期內容，也能在需要時把脈絡帶到另一個工具。

具體來說，這層控制權至少包含五件事：

  1. 自己擁有：Personal Context 的權威來源由使用者控制，不只存在某個產品的聊天紀錄裡。
  2. 可以查證：重要內容保留來源、時間、適用範圍與驗證狀態，讓人知道為什麼值得相信。
  3. 可以修改：使用者能更正、撤回或淘汰錯誤與過期內容，而不是讓模型猜測哪個版本才對。
  4. 可以帶走：脈絡能匯出並依任務選擇性授權給不同 Agent；帶走的是控制權，不是把所有私人資料全量複製。
  5. 依結果演進：新經驗必須先經外部結果驗證，再決定是否回寫，避免把一次幻覺固化成長期記憶。

因此，可查、可改、可帶走不是三個匯出功能，而是個人能否真正掌握脈絡的驗收標準。Human Context Protocol 與 Portable Memory 等提案，已經處理偏好可攜、匯出、合併與刪除治理；但尚未形成由主要平台共同採用、同時涵蓋 Profile、State、Knowledge、Experience、治理與結果驗證的通用 Personal Context schema。這是一個應該逐步實作與驗證的方向，不是已經完成的產業標準。

這四層是本文用來實作的分類，不是既有公認標準。它與 CoALA 的記憶角色、Microsoft 在 Foundry Agent Memory 中區分的 user profile、chat summary 與 procedural memory 有相近之處，但不能說成同一套模型。

Personal Context 的重點也不是「越多越好」。Anthropic 的 context engineering 說明把 context 當作有限資源，強調選取、壓縮與漸進揭露。把全部歷史一次送入模型，會增加成本，也會讓過期資訊、互相衝突的規則與無關細節一起干擾判斷。

實務上需要的是 Minimum Sufficient Context：讓 Agent 完成這次任務所需的最小充分脈絡。穩定且高頻的規則可以放在 hot context；大量歷史與完整來源留在 cold storage；只有當任務需要時，才按需取回。這不是單純的檢索技巧，而是一個治理決定：哪些資料有資格進入這次決策，誰能看見，何時失效，衝突時以什麼為準。

Agent Experience 是一條回饋循環，不是一次漂亮回答

Agent Experience 常被誤解為聊天介面是否順手。我更關心的是 Agent 面對工作環境時，是否能順利取得脈絡、採取行動、理解回饋並掌握下一個狀態。CircleCI 對 Agent Experience 的整理也把 context、action、feedback 與 state 放在同一個操作體驗中。

以這個角度看，一次完整的 Agent Experience 應包含五個連續步驟：

  1. Context：根據人、任務與風險，組出 Minimum Sufficient Context。
  2. Action：選擇工具、Skill 或工作流程，對數位或物理環境採取行動。
  3. Feedback：讀取 API 回應、測試結果、資料庫狀態或使用者確認，而不是只看模型自己寫的說明。
  4. State：判斷環境現在變成什麼狀態，任務是完成、部分完成、失敗，還是需要人介入。
  5. Next step：依真實狀態決定繼續、修正、回滾或停止。

這條循環的關鍵在於 feedback 必須指向外部結果。Agent 發出「部署成功」並不是部署成功；建置狀態完成、正式網址回應正常、主要功能能操作，才是可驗證的結果。τ-bench以環境最終狀態評量工具型 Agent，Anthropic 的 Agent 評估指南也強調多次試驗、任務結果與失敗分析。這些方法提醒我們：漂亮的推理過程不能取代 outcome oracle。

反思必須從結果開始，不能由 Agent 自我感覺良好

Reflexion探索以語言回饋協助 Agent 在後續嘗試改善，ExpeL進一步抽取可跨任務重用的經驗。它們支持「結果可以轉成後續提示與策略」這條路徑，但不代表每一段自動反思都是真的。

如果驗證訊號本身錯誤，反思只會把錯誤說得更有條理。因此順序不能顛倒：先確認 outcome，再解釋成功或失敗原因，最後才決定是否回寫。可接受的結果來源包括自動測試、資料庫最終狀態、版本差異、實現報酬、人工標註或明確的使用者核准；同一個模型對自己輸出的評分，只能是線索，不能當唯一事實來源。

實務專案已經出現不同形式的經驗回寫。Matt Pocock 的 Skills 專案展示小型、可組合的專家做法；gstack把 learn、retro 與專案知識放進開發工作流；截至 2026 年 10 月，TradingAgents的工程實作則把交易結果與反思紀錄連在一起。這些案例的效果宣稱仍需各自看證據，但都透露同一個設計方向：經驗要能被保存、選取並在下一次工作中重新使用。

經驗回寫後，應該成為不同類型的資產

不是每一次任務紀錄都該永久保存。回寫前要先分類，因為不同內容有不同生命週期：

  • Rule：穩定的限制、禁令、驗收條件與邊界。
  • Skill：可重複執行、包含步驟與資源的做事方法。
  • Memory：與特定人、專案或事件有關，會影響後續判斷的內容。
  • Eval：能重現成功或失敗、用來防止退步的測試與案例。

我把這些稱為 Experience Assets，是為了讓「學到東西」不再只是一段心得。一次失敗若只留下聊天紀錄，下次很難精準取用；若它被整理成規則、修正版 Skill 或回歸測試，就能進入真正的工程循環。Voyager以可執行技能庫累積程序能力，說明經驗可以轉為可組合資產；但 Minecraft 的研究結果不能直接被當成所有知識工作都有效的證明。

資產也必須能被撤回。規則可能過期，記憶可能衝突，Skill 可能因 API 改版失效，Eval 也可能只覆蓋舊風險。每一筆回寫至少要保留來源、形成日期、適用範圍、驗證狀態與失效條件，並讓高風險更新經過人工審閱。LongMemEval對多次對話、時間推理、資訊更新與拒答的評量，也顯示長期記憶並不是存進去就可靠。

任務做得更好，不等於人的能力已經成長

Agent 可以替使用者完成搜尋、整理、生成與操作，卻不能只從交付完成推論使用者已經具備同樣能力。要判斷 Human Capability Growth，還要保存另一組證據：使用者是否能在沒有完整答案時提取概念、是否做過關鍵判斷、需要多少提示、能否解釋取捨，以及換到新情境後能否再次完成。

因此，Personal Context 除了 Profile、State、Knowledge 與 Experience，還要能表達三種會變動的資訊：此刻正在學什麼、哪些能力已有可查驗證據，以及提示依賴、錯誤類型與跨情境表現如何隨時間改變。這些內容不能直接寫進永久 Profile，也不能只用「已讀」或一次成功表示。

人的學習與 Agent 系統的改善是兩條不同但相接的循環。人需要經過認知、實踐、驗證、反思與重新理解；Agent system 則需要 Memory、Action、Outcome、Reflection、Codification 與 Reuse。兩者在真實任務、外部結果與下一次行動交會。這套六步表述是本文採用的整合框架，不是既有公認標準，也不代表模型權重會自動更新。

從 Data 到 Wisdom提供另一個檢查角度：資料與知識只有進入行動、接受結果校正，才可能支持更好的下一次判斷。這裡的「能力成長」同樣是設計目標與待驗證假設，必須看延後提取、跨情境表現、人工介入與真實任務結果，不能由文章或系統自行宣告。

把整條路徑串起來

完整循環可以這樣理解：Personal Context 先提供 Profile、State、Knowledge 與 Experience；context engine 依任務選出 Minimum Sufficient Context；Agent 透過 Skills、MCP 或其他介面採取行動；系統用外部結果確認狀態；reflection 只針對已驗證結果整理原因；經過審閱的內容再成為 Rule、Skill、Memory 或 Eval，回到下一輪 Personal Context。同一份結果也可以在證據足夠時更新 Learning State、Capability Evidence 與 Growth Trajectory，讓下一次互動調整提示量、練習難度與人機分工。

這裡每個構件都有清楚邊界。MCP 負責連接 context 與 actions，不負責決定記憶語意；記憶系統負責抽取、保存、更新與檢索，不負責證明任務成功；reflection 負責形成候選經驗，不具有自動改寫核心規則的權力；eval 負責提供可重現的結果訊號，不負責替使用者決定價值偏好。

BYOC，也就是 Bring Your Own Context，則是這條路徑的可攜性方向：個人的脈絡與經驗不應被單一聊天視窗完全綁住。但今天還沒有跨平台通用的個人記憶 schema。MCP、Agent Skills 與 AGENTS.md 提供了部分可攜構件，不代表完整的 Personal Context 已經能在各平台無損移動。現階段更務實的做法，是先把來源、資料模型、權限與匯出邊界掌握在自己手上。

從工具清單改成循環驗收

要開始實作，不必一次換掉所有系統。先挑一個高頻、結果可驗證的任務，逐項回答：

  1. Agent 在開始前需要知道哪些個人與任務脈絡？
  2. 哪些內容要常駐，哪些只能按需取用？
  3. 它可以採取哪些行動，哪些行動必須先由人核准？
  4. 任務完成的外部證據是什麼？
  5. 失敗後要形成 Rule、Skill、Memory 還是 Eval？
  6. 誰審閱回寫內容，什麼情況必須更新或刪除？
  7. 這次成果證明的是 Agent 做到了，還是使用者也形成了可轉移的能力？

這六題會把討論從「要不要再裝一個工具」移回真正的系統問題：資訊如何進入判斷、行動如何改變環境、結果如何被確認、經驗如何在不污染未來的前提下累積。

Personal Context → Agent Experience → Human Capability Growth 不是一個宣稱所有構件已被共同驗證的新標準，而是一張整合藍圖。它的價值，要由實際任務中的成功率、錯誤記憶率、人工介入成本、可追溯性，以及使用者在延後與跨情境任務中的表現來檢驗。主張只有在這些結果面前站得住腳，才會從一篇觀點變成可採用的方案。

接下來可以從三個正在發生的入口觀察這套循環：No App 與 Agent as Interface處理互動入口，Muse 與 Muse SDK呈現個人 Agent 的平台化方向，MCP 與 MHS則把可行動範圍從數位工具延伸到物理設備。它們各自解決不同層次，不能彼此取代；也正因如此，才需要一條完整循環把它們接起來。

參考來源