個人 Agent 用得越久，累積的價值越不在某一輪回答，而在它逐漸知道你的偏好、工作方式、進行中任務、可信來源與過去經驗。如果這些內容只能留在單一產品裡，更換 Agent 就像換工作時不能帶走自己的筆記、流程與已學會的方法。

我使用 BYOC，也就是 Bring Your Own Context，來描述一個具體目標：個人應能把自己的 context 保存於可治理的層次，依任務選擇性提供給不同 Agent，並保留匯出、修正、撤回與移轉能力。

這不是宣稱創造了一個新標準。MCP、Agent Skills、AGENTS.md、Human Context Protocol、Portable Memory、UMP、UOMP 與 OpenSelf 等工作，已經分別處理能力互通、程序封裝、專案指令、可攜偏好、記憶格式與授權治理。BYOC 的工作，是把這些分散構件放進個人脈絡的移轉問題裡，說清楚還缺哪些契約，以及如何接上任務結果與經驗回寫。

BYOC 不等於把完整聊天紀錄下載成 JSON。真正的可攜性，必須連同語意、來源、權限、狀態、版本與使用目的一起移轉。

已有可攜記憶提案，但還沒有共同收斂

截至 2026 年 10 月，HCP、Portable Memory、Universal Memory Protocol（UMP）、User-Owned Memory Protocol（UOMP）與 OpenSelf 都已提出可攜、使用者控制、來源、權限或生命週期的具體做法。這表示問題已經被社群正面處理，不能再說「完全沒有 memory schema 或實作」。

更精確的缺口是：這些工作的範圍、成熟度與採用度不同，尚未形成由主要平台共同採用、同時表示個人 profile、任務 state、知識 provenance、經驗、權限、生命週期與外部 outcome 的完整 Personal Context 契約。

MCP 解決能力互通，不是個人記憶格式

MCP 架構規格定義 host、client、server 與 resources、tools、prompts 等能力，並強調伺服器隔離與 host 的授權責任。它可以讓 Agent 連到個人知識庫或記憶服務，但 MCP 本身是交換與能力協定，不規定「偏好、任務與經驗要如何共同建模」。

Agent Skills 解決程序封裝

Agent Skills specification定義 SKILL.md、scripts、references 與 assets 的可攜目錄結構。Skill 很適合保存「怎麼做」，但不負責保存「這是誰的偏好」、「哪個任務做到哪裡」或「這項經驗是否已失效」。

AGENTS.md 解決專案指令入口

AGENTS.md讓不同 coding agents 在專案中找到建置命令、測試與慣例，也提供目錄層級的指令範圍。它是可版本控制的工作脈絡，卻以 repository 為中心，不是跨生活與工作的個人 context container。

HCP 直接處理可攜偏好

Stanford Digital Economy Lab 與 Consumer Reports Innovation Lab 的 Human Context Protocol最接近 BYOC 的核心問題。HCP 將 LLM client 與 memory manager 分開，提出 schema definition、preference search 與 preference update 等高階工具，希望偏好能在不同 context 中被攜帶與選擇性使用。

HCP 是研究合作、報告與 reference implementation 路線，不應被描述成已廣泛部署的產業標準。它聚焦 preference portability，也不等於已經涵蓋任務 state、技能、eval、完整 provenance 與所有治理需求。

Portable Memory 把格式、合併與刪除治理做成提案

MacPaw 的 Portable Memory 以 .mem bundle、JSONL、manifest 與 checksums 定義供應商中立的記憶格式，並把合併、tombstone、audit trail 與 conformance fixture 放進 reference SDK。這已經比單純下載聊天紀錄更接近可驗收的記憶可攜層。

它的 repository 同時明確標示這是 open format proposal，而不是已完成的產業標準。Portable Memory 聚焦記憶如何無損移轉與驗證刪除，並不等於已經定義任務如何取得脈絡、執行動作、驗證外部結果，再決定哪些經驗可以回寫。

UMP、UOMP 與 OpenSelf 把記錄、授權與產品實作往前推

UMP specification 定義可攜 record、scope、bi-temporal time、provenance、consent 與 integrity，主要 binding 選擇 MCP；規格自稱 stable，但跨產品採用度仍需另外驗證。UOMP 則仍標示為 Draft-00，聚焦 local-first、least privilege、session isolation 與可撤回的授權。

OpenSelf 已直接以 user-owned Personal Context OS 定位產品，實作來源、時間、scope、敏感度、信任層級、bounded context compilation、MCP 與 owner-approved writes。這是重要的直接案例，但仍屬專案自己的功能說明，不能當成獨立成效證據。

這些工作讓界線更清楚：BYOC 的價值不在重新命名記憶可攜，而在把可攜與治理接上任務 state、外部結果驗證，以及 Rule、Skill、Memory、Eval 的經驗回寫循環。

可攜要分成五個層次

如果只問「能不能 export」，很容易得到一份另一個系統看不懂的檔案。以下五層是本文綜合既有提案後使用的驗收清單，不是另一套新 schema。

資料可攜

使用者能取得原始內容與附件，不受單一供應商 API 綁定。匯出應有穩定識別碼、建立與更新時間，而不是一包失去關係的純文字。

語意可攜

接收端要知道某筆內容是 profile、preference、task state、knowledge、episode 還是 candidate experience。若只有 content 欄位，不同 Agent 會以自己的方式猜測。

政策可攜

脈絡必須帶著 consent、purpose、scope、敏感度與到期條件。能匯出不表示任何 Agent 都能無限制讀取；可攜性應擴大個人控制，而不是擴大外洩範圍。

操作可攜

接收端要能搜尋、更新、撤回、合併與處理衝突。只有唯讀 dump，不能支援長期 Personal Context。

經驗可攜

規則、技能、記憶與 eval 需要連到形成它們的 evidence。否則移轉後只剩結論，不知道為何相信、在哪些條件下有效。

一筆 Personal Context 至少要帶什麼

BYOC 不必一開始追求全能 schema，但最低契約不能只包含文字。以下同樣是本文的整合驗收清單；其中 identity、scope、provenance、validity、consent 與 supersedes 等欄位，已有 Portable Memory、UMP、HCP 與 OpenSelf 的直接先例。我會要求每筆內容至少有：

  • Identity：穩定 id、owner 與 namespace。
  • Type：profile、state、knowledge、experience 或其他明確類型。
  • Content：結構化值與人可讀說明。
  • Provenance：來源、建立者、取得方式與證據連結。
  • Validity：生效時間、最後確認、到期或重查條件。
  • Policy：敏感度、同意、用途、可分享對象與可執行動作。
  • Status：觀察、候選、已審閱、已撤回或已失效。
  • Version：修改紀錄、衝突與 supersedes 關係。
  • Evidence：與 outcome、eval 或人工核准的關聯。

這些欄位不是為了把生活變成資料庫，而是避免一句「使用者喜歡簡短回答」在不同情境被無限延伸。偏好也許只適用工作報告，不適用醫療說明；版本與 scope 讓接收端知道邊界。

BYOC 不是把所有 context 同步到所有地方

Personal Context 同時包含高度敏感資料。最安全的預設不應是全量同步，而是最小揭露與按需取得。

「自我掌握」的重點也在這裡：不是把同一份資料複製到更多服務，而是由個人決定什麼可以被看見、在哪個任務使用、何時失效，以及哪一個來源有權修正它。

可以把載入策略分成三層：

  1. Hot context：這次任務一定需要、可直接使用的少量資訊。
  2. Cold context：保存在使用者控制的儲存層，預設不送入模型。
  3. On-demand context：Agent 說明目的與範圍後，經政策或使用者同意才取用。

MCP 可成為 on-demand retrieval 的一種傳輸方式，HCP 可提供 preference manager 契約，Portable Memory 與 UMP 提供可攜 record 的具體方向，UOMP 處理授權，OpenSelf 展示 context layer 的產品實作，Skills 與 AGENTS.md 則承載程序與專案規範。但如何把這些構件接上外部 outcome 與經驗回寫，仍是產品需要明確決定的部分。

可攜性最大的難題是衝突，而不是格式

當兩個 Agent 都能更新 context，就會出現分支與衝突。A Agent 認為使用者偏好早上開會，B Agent 則從近期拒絕紀錄推論下午較好。系統不能以最後寫入覆蓋一切。

每次更新應區分：

  • 使用者直接陳述，還是 Agent 從行為推論。
  • 單次情境，還是長期偏好。
  • 新內容補充舊內容，還是明確取代。
  • 衝突能否由政策合併，或必須請人確認。

使用者直接修正通常高於模型推論；有明確 scope 的新決定只應取代相同 scope 的舊內容。所有自動合併都要留下 provenance，才能在出錯後復原。

一條務實的導入路徑

BYOC 不需要等所有廠商同意同一套 schema 才能開始。可以先建立一個供應商中立的 context bundle，將資料與 adapter 分開。

第一階段，先支援唯讀匯出與來源保留，證明離開原產品後內容仍可理解。第二階段，加入類型、scope、consent 與狀態，讓另一個 Agent 能選擇性讀取。第三階段，建立雙向更新、衝突處理與 audit log。第四階段，再把 Rules、Skills、Memory 與 Evals 的 evidence graph 一起帶走。

驗收不應只看檔案能否匯入。應用相同任務比較移轉前後：新 Agent 是否取到正確偏好、是否沒有讀到未授權內容、能否延續未完成 state、是否知道過期知識要重查，以及修正後能否同步回使用者控制的來源。

個人脈絡的價值應屬於個人

Personal Context 是 Agent 長期合作後累積的工作資產。產品可以提供模型、介面與執行環境，但不應讓使用者只能用「重新開始」的代價離開。

BYOC 的主張因此很具體：context 必須可辨識、可選取、可移轉、可撤回、可驗證。MCP、Skills、AGENTS.md、HCP、Portable Memory、UMP、UOMP 與 OpenSelf 已提供重要構件，也同時提醒我們不要把局部互通或單一實作誤認成已共同採用的完整 Personal Context 標準。

真正的完成條件，不是產生一份 export，而是另一個 Agent 在最小授權下能正確理解、延續工作，並且每一次使用與修改都回到個人可以看見、修正與帶走的脈絡層。

參考來源