Acontext：把 agent 記憶寫成可讀的 skill 檔案
Agent Skills as a Memory Layer
秒懂
- 它是什麼？
- Acontext 用 Markdown 形式的 agent skill 檔案當作記憶層，靠 LLM 蒸餾對話與執行軌跡，再以工具呼叫做漸進式揭露。它要解決的是記憶不透明、難以檢視與修正的問題，代價是放棄向量檢索並引入一輪額外的 LLM 寫入成本。
- 適合誰用？
- 已經在用 Claude Code、OpenClaw 或自建 agent 迴圈，而且需要人工檢視與修改記憶內容的團隊，適合評估 Acontext；如果你的檢索場景需要跨語意相似度召回，或無法接受每次任務結束後多一輪 LLM 蒸餾成本，它就不是合適的工具。動手前先確認三件事：你的 LLM 是否支援 tool calling（自架預設走 gpt-4.1）、SKILL.md 的結構是否足以承載你的領域知識、以及資料落地方式（雲端 API key 或本機 docker 的 db 目錄）是否符合你的合規要求。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 63 天前。
- 用什麼語言寫的？
- 主要是 JavaScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是記憶不可檢視的問題
多數 agent 記憶方案的產物是一堆向量或一段被壓縮過的摘要，使用者看不到裡面寫了什麼，也無法直接改。Acontext 的切入點很直接：既然 agent skill 可以用檔案表示知識，記憶也可以用同樣的格式表示。README 的說法是「Skill is Memory, Memory is Skill」。
目標讀者是正在建 agent 迴圈、且已經被記憶品質困擾的開發者。他們遇到的具體狀況是：agent 重複犯同一個錯，上週調好的偏好這週又忘了，而除錯時只能盯著一段不透明的 context 猜測。Acontext 把這些學習結果落成 Markdown 檔案，於是 git、grep、掛載進沙箱這些既有工具都能派上用場。
這裡有個前提值得點出：可檢視性只有在檔案內容真的可讀時才有價值。如果蒸餾出來的 skill 檔案寫得含糊，人工檢視只是把除錯成本從讀向量換成讀檔案，並沒有消失。
Store 路徑：從對話到 skill 檔案的五段流程
README 的 mermaid 圖把寫入路徑拆成五步：Session messages、Task complete/failed、Distillation、Skill Agent、Update Skills。
輸入是會話訊息，文件說明工具呼叫與 artifacts 可選。任務從訊息流中自動抽取，或由 agent 明確回報結果。觸發點是任務被標記完成或失敗，這個判定可以來自 agent 回報，也可以是自動偵測。接著一輪 LLM 蒸餾，從對話與執行軌跡推斷哪些做法有效、哪些失敗、使用者有什麼偏好。Skill Agent 決定要寫進既有 skill 還是新建一個，然後依你的 SKILL.md schema 落筆。
最後一步是關鍵的設計分工：結構由你定義，抽取、路由與寫入由系統負責。這代表 schema 的品質直接決定記憶品質。如果 SKILL.md 沒有定義清楚命名與檔案佈局，Skill Agent 的寫入就會漂移，而漂移累積之後，可讀性優勢會被稀釋。README 給的例子是一聯絡人一檔案、一專案一檔案，透過上傳 working context skill 來達成。
Recall 路徑：用工具呼叫取代語意 top-k
讀取端只有兩步：Any Agent 呼叫 list_skills 或 get_skill，內容出現在 context 中。
Acontext 明確不採向量檢索。README 的措辭是「progressive disclosure, agent in the loop」，retrieval 靠 tool use 與推理，而不是 semantic top-k。你要做的是把 get_skill 與 get_skill_file 這兩個 Skill Content Tools 交給 agent，由它自己判斷需要什麼、去呼叫、拿回內容。
這個選擇有兩面。好處是召回不再受限於嵌入模型的語意近似，agent 可以按名稱與結構精準取用，也不會因為 top-k 把不相關的片段塞進 context。代價是 agent 必須有能力做這個判斷，而這把負擔轉移到模型的工具呼叫能力上。README 在自架段落特別提醒 LLM 必須支援 function calling，預設用 gpt-4.1，這不是隨口一提的設定，而是架構上的硬需求。
另一個實際影響是延遲與回合數：檢索變成 agent 迴圈中的一次工具呼叫，而不是一次前置查詢。對於需要在一輪內就拿到完整上下文的場景，這種做法並不划算。
安裝與啟動：從 CLI 到本機後端
雲端路線最短。README 寫的是到 acontext.io 領取免費額度，走一次點擊式 onboarding 取得以 sk-ac 開頭的 API Key，然後安裝 SDK。Python 端是 pip install acontext，TypeScript 端是 @acontext/acontext 這個 npm 套件。
初始化客戶端時，雲端與自架的差別只在參數：
import os from acontext import AcontextClient client = AcontextClient(api_key=os.getenv("ACONTEXT_API_KEY"))
自架路線由 acontext-cli 負責。README 給的下載指令是 curl -fsSL https://install.acontext.io | sh。前置條件是機器上要有 docker，以及一組 OpenAI API Key。接著：
mkdir acontext_server && cd acontext_server acontext server up
這道指令會建立或沿用 .env 與 config.yaml，並建立 db 資料夾持久化資料。啟動後兩個端點可用：API Base URL 是 http://localhost:8029/api/v1，Dashboard 在 http://localhost:3000/。
另外 README 提供一條給 coding agent 用的安裝路徑，直接請 Claude Code 或 OpenClaw 讀取 https://acontext.io/SKILL.md 並照著設定。這種「用 skill 檔安裝 skill 工具」的做法與專案本身的哲學一致，但它的可靠性取決於該網址當下的內容，這點無法從我手上的材料確認。
蒸餾成本與 schema 漂移是兩個真實限制
第一個限制寫在流程圖裡：每次任務完成或失敗都會觸發一輪 LLM 蒸餾。這不是可選的最佳化，而是寫入路徑的核心步驟。任務密度高的 agent 會因此產生穩定的額外推論支出，而且這筆支出與任務本身是否值得學習無關。README 沒有描述任何節流、批次或去重機制，是否會對相似的失敗反覆寫入同一條 skill，材料中看不出來。
第二個限制是 schema 依賴。README 把結構設計的責任完全交給使用者，系統只做抽取、路由與寫入。這意味著你的 SKILL.md 品質就是記憶品質的上限。當 skill 數量成長，Skill Agent 在「寫進既有 skill 還是新建」這個判斷上會愈來愈容易出錯，而錯誤的結果是檔案分裂或內容重複。專案本身沒有提供 schema 檢查或衝突偵測的說明。
第三點是檢索的邊界。漸進式揭露要求 agent 知道該問什麼。如果它不知道某條 skill 存在，就不會去呼叫 get_skill。語意檢索在這類「不知道自己要找什麼」的場景反而有優勢，Acontext 用工具呼叫換掉了這個能力，這是設計取捨，不是缺陷，但你必須清楚自己落在哪一側。
和向量記憶方案的差異在哪裡
把 Acontext 與一般向量資料庫記憶層對照，差別不在功能清單，而在資料的形狀與可逆性。
向量方案把記憶存成嵌入向量，檢索靠相似度，優點是能處理模糊查詢與跨語言近似，缺點是內容不可直接閱讀、不可直接編輯，模型換代時往往需要重新嵌入。Acontext 走另一條路：記憶是 Markdown 檔案，檢索靠 agent 主動呼叫工具。README 強調的「No embeddings, no API lock-in」與「no re-embedding or migration step」正是這個對比的產物，而 Export as ZIP 讓同一批 skill 檔案可以搬到別的 agent、別的 LLM 上執行。
這個差異帶來的實際後果是維護方式不同。向量方案調校的是嵌入模型與切塊策略；Acontext 調校的是 SKILL.md 的結構與檔案佈局。前者你改不動內容，後者你必須自己設計內容。兩者都需要投入，只是投入的位置不同。
如果你的團隊沒有能力持續維護一套 skill schema，向量方案的低介入特性反而更省事。
授權、版本節奏與升級成本
授權是 Apache-2.0，允許商業使用與修改，條款細節請自行閱讀全文，這裡不提供法律意見。自架情境下，資料落在 acontext server up 建立的 db 資料夾，備份與遷移的責任在使用者身上；雲端情境則是把會話與蒸餾結果交給服務方，兩種路線的合規含義不同。
版本節奏可以從 release 標籤觀察。材料列出的近期版本包含 ui/v0.1.14、sdk-ts/v0.1.21 與 package-claude-code/v0.1.3，日期集中在 2026 年 4 月 8 日。三者獨立標版，代表 UI、TypeScript SDK 與 Claude Code 套件可以各自演進。對採用者的實際含義是：升級時要分別確認這幾個元件的相容性，不能假設它們同步。所有版本號都還在 0.x，依語意化版本的慣例，這通常意味著介面仍可能變動。
升級成本的主要來源不是 API 變更，而是你的 skill 檔案。如果 schema 隨版本調整，既有記憶可能需要重新整理。目前材料沒有提供遷移工具或相容性保證的說明，這一點在評估時應該直接向專案確認。
編輯結論
已經在用 Claude Code、OpenClaw 或自建 agent 迴圈，而且需要人工檢視與修改記憶內容的團隊，適合評估 Acontext；如果你的檢索場景需要跨語意相似度召回，或無法接受每次任務結束後多一輪 LLM 蒸餾成本，它就不是合適的工具。動手前先確認三件事：你的 LLM 是否支援 tool calling（自架預設走 gpt-4.1）、SKILL.md 的結構是否足以承載你的領域知識、以及資料落地方式（雲端 API key 或本機 docker 的 db 目錄）是否符合你的合規要求。
社群筆記