Select Page
Graphify 是什麼？把專案變成 AI 可查詢知識圖譜

Graphify 是什麼？把專案變成 AI 可查詢知識圖譜

by | 7 月 15, 2026 | AI, skills, Tool

Graphify 最有價值的地方，是把「讀專案」這件事從一次性的上下文塞爆，改成可以重複查詢的知識圖譜， Codex、Claude Code、OpenCode、Cursor、Gemini CLI 這類 AI coding assistant 來說，最大的浪費常常不是寫程式，而是每次都重新理解同一個 codebase。

如果 OpenWiki 解決的是 Agent wiki 和文件記憶，Graphify 更像是把整個資料夾編譯成一張可追蹤的圖，它可以處理程式碼、SQL schema、R script、shell script、文件、論文、圖片，甚至影片和音訊，最後輸出 `graph.html`、`GRAPH_REPORT.md` 和 `graph.json`。

先講結論

Graphify 不是向量資料庫，也不是單純 RAG。官方說得很直接，它不用 embeddings，也不放 vector store，而是建立一張可以 traverse 的真實 graph，你可以問一個概念是什麼，也可以追兩個概念之間的 shortest path，或要求它回答某個問題時只返回相關 subgraph。

這對 coding agent 很重要，因為大型專案裡的關係不是只有語意相似，還有 import、call、inherit、mix in、schema、設定檔、文件註解和設計決策，Graphify 把這些關係轉成節點和邊，讓 Agent 不必每次都用 grep 或全文讀取重新猜。

Graphify 是什麼

Graphify 是一個 AI coding assistant skill，安裝後可以在支援的平台裡輸入 `/graphify .`，Codex 則使用 `$graphify`。它會掃描當前資料夾，把程式碼、文件、PDF、圖片和影片整理成知識圖譜。

官方快速開始很短，重點是 PyPI 套件名稱叫 `graphifyy`，不是 `graphify`。這點要記住，因為 README 特別提醒其他 `graphify*` 套件不是官方套件。

uv tool install graphifyy      # install the CLI (or: pipx install graphifyy)
graphify install               # register the skill with your AI assistant

之後在 AI assistant 裡執行。

/graphify .

為什麼它不是一般 RAG

一般 RAG 常見做法是切 chunk、做 embedding、進 vector store，再用語意相似度找片段。這對文件問答很好用，但對程式碼架構不一定夠。因為程式碼最重要的線索常常是顯式關係，例如某個 class 被誰繼承，某個 function 被哪裡呼叫，某個 schema 影響哪個 API。

Graphify 對 code maps 採 local-first。程式碼透過 tree-sitter AST 解析， deterministic，不需要 LLM，也不會把程式碼送出本機。文件、PDF、圖片和影片這類語義 pass 才會使用 assistant model 或你設定的 API key。

EXTRACTED 和 INFERRED 是關鍵

Graphify 很值得學的一點，是它會標記每條邊的來源。`EXTRACTED` 代表關係明確存在於來源裡，`INFERRED` 代表由 Graphify 推導出來。這比單純把答案講得很肯定更重要，因為 Agent 常犯的錯不是沒有答案，而是不知道哪些是看到的，哪些是猜的。

aivi 的整理還提到第三類 `AMBIGUOUS`，代表不確定的關係要留給人工審查。這種設計很適合放進團隊工作流，因為架構理解不該只追求自動化，也要保留可審計性。

輸出檔案怎麼看

一次執行後，最核心的是三個檔案。

檔案用途我會怎麼用
graph.html互動式圖譜快速看社群、節點和跨模組關係
GRAPH_REPORT.md摘要報告讓 Agent 先讀專案重點和建議問題
graph.json完整圖資料後續 query、path、explain 不必重讀所有檔案
Graphify 把資料夾轉成可查詢知識圖譜的流程圖
Graphify 的核心流程是偵測檔案、抽取關係、建立 graph、切分社群，最後讓 Agent 可以 query、path、explain。

最適合哪些場景

我會優先用在三種情境。

第一，接手陌生 codebase，需要先知道核心節點和模組邊界。

第二，專案同時有 app code、database schema、infra script 和文件，單純全文搜尋很難看出關係。第

三，研究資料夾裡有論文、截圖、筆記和實驗程式，需要把概念關係串起來。

這和我前面整理的 OpenWiki 可以搭配。OpenWiki 偏向替 Agent 建立 wiki 記憶，Graphify 偏向把來源資料拆成可查詢 graph。兩者放在一起，就是文件記憶加關係推理。

Benchmark 怎麼解讀

官方 README 摘要裡列了幾個 benchmark。LOCOMO recall@10 是 0.497，對照 mem0 的 0.048 和 supermemory 的 0.149，差距很大。LOCOMO QA accuracy 是 45.3%，低於 supermemory 的 49.7%，但高於 mem0 的 27.3%。LongMemEval-S QA accuracy 則是 76%，官方標註和 dense RAG tied。

Graphify benchmark 摘要圖，包含 LOCOMO recall 和 QA accuracy
這些數字適合當成方向參考。Graphify 的價值不只是單點 QA，而是能把關係路徑保存下來讓 Agent 反覆查詢。

Codex 使用要注意什麼

Graphify 支援 20 個以上 assistant 平台。對 Codex 使用者來說，官方特別提到 Codex 用 `$graphify`，不是 `/graphify`。另外如果要做 parallel extraction，需要在 `~/.codex/config.toml` 的 `[features]` 下設定 `multi_agent = true`。

這點和 Codex 作為 AI 代理 的方向很搭。Codex 如果只靠當下上下文，很容易在大型 repo 裡反覆找檔案。Graphify 可以先把核心結構整理好，讓後續任務更像查地圖，而不是每次重新探路。

可以匯出到 Obsidian、Neo4j 和 MCP

aivi 的整理提到 Graphify 有很多可選輸出，包括 Obsidian、SVG、GraphML、Neo4j Cypher、直接推送 Neo4j、MCP server 和 wiki 風格 Markdown。這代表它不是只服務某一個 assistant，而是可以把 graph 變成團隊知識資產。

如果你已經有 GraphRAG 使用本地 Ollama 的經驗，可以把 Graphify 看成更偏工程專案的知識圖譜入口。它不是取代 GraphRAG，而是把 repo、文件與工程關係先整理成一個可操作的圖。

我會怎麼導入

第一步只跑 code。因為 code map 是 local-first，不需要 LLM token，風險最低。

第二步打開 `graph.html` 看社群是否合理，再讀 `GRAPH_REPORT.md`，確認 god nodes 和 surprising connections 是否真的有幫助。

第三步才把 docs、PDF、圖片或影片加進來，並明確估算語義 pass 會用到哪個模型和多少成本。

如果是私有專案，我會先禁用媒體語義分析，只讓 tree-sitter 解析程式碼。等到確定 graph 有價值，再逐步開文件和圖片。這樣比較符合安全直覺，也不會一開始就把整個公司資料夾丟進模型。

我的判斷

Graphify 的核心價值不是炫酷的圖，而是讓 Agent 對大型專案有可追溯的結構記憶。它把「讀懂專案」變成一個可重複、可更新、可查詢的輸出，而不是每次都靠模型臨場發揮。

我會把它放進 AI coding 工作流的前置步驟。陌生 repo 先 Graphify，需求進來前先看 graph report，修改前查 path，修改後用 hook 或 watch 更新圖譜。這樣 Agent 比較不會只看局部檔案就亂改。

延伸資源

FAQ

Graphify 和 RAG 有什麼不同？

RAG 常用向量相似度找片段，Graphify 建立可 traversal 的知識圖譜。它更重視 import、call、inherit、文件引用和設計決策這類關係。

Graphify 會把程式碼送到雲端嗎？

程式碼 map 是 local-first，透過 tree-sitter AST 解析，不需要 LLM。文件、PDF、圖片和影片的語義分析才會使用 assistant model 或你設定的 backend。

Codex 可以用 Graphify 嗎？

可以。官方支援 Codex，並提醒 Codex 使用 `$graphify`。若要 parallel extraction，需要在 Codex config 啟用 `multi_agent = true`。

Graphify 適合私有專案嗎？

適合先從程式碼圖譜開始，因為 code parsing 可以本地完成。若要分析文件、圖片或影片，建議先確認使用的模型和資料外送邊界。

Grill Me 是什麼？讓 AI Agent 開工前先問清楚需求

Grill Me 是什麼？讓 AI Agent 開工前先問清楚需求

by | 7 月 9, 2026 | AI, skills

很多 AI Agent 做不好，不是因為模型太弱，而是任務在一開始就太模糊，使用者一句「幫我做一個工具」、「幫我寫一個遊戲」、「幫我規劃一個工作流」，Agent 會很認真地往前衝，但它其實是在替你補完一堆你沒有講清楚的決策。

Grill Me 這類 skill 的價值，就在於把「開工前的需求訪談」變成固定流程，它不急著執行，而是先反過來問你：目標是什麼？使用者是誰？限制在哪裡？哪些選項還沒決定？什麼事情一定不能做？這一步看起來慢，實際上是在幫你省掉後面反覆重做的時間。

如果你已經在用 Codex、Claude Code、Cursor、Windsurf 或 OpenCode 這類工具，這篇可以當成一個提醒：真正拉開成果差距的，不只是模型版本，而是你有沒有一套讓 Agent 開始前先釐清需求的工作流。站上之前整理過 OpenWork / OpenCode 桌面工作台，那偏向執行環境，這篇談的是執行前的需求對齊。

先講結論：不要太快叫 Agent 開始做事

AI Agent 最常見的失控點，是使用者以為自己已經講清楚，但其實只講了一個方向，人類同事遇到模糊需求，可能會回頭問你，Agent 則常常直接開做，做出一個看起來完整、但不是你真正想要的東西。

Grill Me 的做法很簡單：在實作前先訪談。它會針對任務目標、使用場景、輸出格式、限制條件、技術選擇、驗收標準一路追問，直到這個任務足夠明確，Agent 才開始真正執行。

這不是把 prompt 寫長而已，而是把「需求還沒完成」這件事明確暴露出來，對我來說，這是使用 AI Agent 很重要的一個分水嶺：你不是把一段模糊想法丟給模型猜，而是先和模型一起把決策樹走完。

Grill Me 是什麼？

Grill Me 來自 Matt Pocock 的 skills 倉庫，這個倉庫不是單一工具，而是一組可安裝到 AI coding agent 裡的工作流程 skill，包含需求訪談、文件對齊、規格整理、TDD、debugging、code review 等。

我在 2026 年 7 月 9 日查看 GitHub API 時，這個倉庫已經超過 16 萬顆星，授權是 MIT，README 裡的定位也很明確：這些 skill 是小型、可調整、可組合的流程，而不是把整個開發過程交給一套巨大框架接管。

Grill Me 本身很短，核心是啟動一段 grilling session，也就是讓 Agent 對你的計畫或設計進行密集訪談。它不是替你做決策，而是逼你把原本藏在腦袋裡的決策說出來。

為什麼「需求訪談」會讓結果差很多？

用「做一個側邊欄貪食蛇遊戲」這種需求來看，沒有訪談時，Agent 也能做出一個可玩的版本。它可能有開始按鈕、分數、速度調整，也能用鍵盤操作。表面上看起來不差。

但只要開始追問，需求會變得完全不一樣：這個側邊欄是 Codex 裡的小工具，還是瀏覽器側邊欄？它是一次性 demo，還是要固定留下來？等待 Agent 工作時能不能玩？鍵盤焦點可能不在遊戲上，是否需要畫面按鈕保底？撞牆要不要死亡？分數要不要保存？記錄要不要能清除？

這些問題不是細枝末節，而是產品體驗的骨架。當它們沒有被問出來，Agent 只能照自己的預設做，當它們被問出來，Agent 才能把設計、互動、資料保存、通知機制都接到同一個使用情境上。

一個好用的 Grill Me 流程，應該問哪些問題？

我會把這類訪談問題分成七組。你不一定要每次問滿，但至少要讓 Agent 在開工前碰過這些維度。

  • 目標：這次任務真正要改善什麼？成功之後看起來是什麼樣子？
  • 受眾：誰會使用這個成果？是自己用、團隊用、客戶用，還是公開產品？
  • 場景：使用者會在什麼時間、什麼裝置、什麼流程裡使用它？
  • 限制：不能用哪些技術？不能改哪些檔案？不能花太多時間在哪裡？
  • 輸出：最後要交付文章、程式、規格、PRD、測試、圖片，還是一組可執行步驟？
  • 驗收：怎樣才算完成？要不要測試？要不要截圖？要不要能回滾？
  • 禁區：哪些事情不要做？哪些語氣、設計、依賴、資料來源要避開？

站上之前寫過 CO-STAR prompt 框架，那套方法適合把指令寫得更完整；Grill Me 則更像互動式版本，讓 Agent 透過追問幫你補齊缺口。

Matt skills 倉庫才是核心資源

Matt Pocock 的 skills 倉庫。這個連結比一般工具推薦更重要，因為 Grill Me 不是孤立存在，它其實是整套工作流的一個入口。

這套 skill 大致分成 engineering 和 productivity，Grill Me 屬於 productivity，適合非程式任務或早期想法釐清；Grill with Docs 則偏 engineering，會把訪談結果延伸到專案文件、domain model、ADR 等長期維護資料。

這也呼應我之前整理的 Matt Pocock Skills 工作流：真正有價值的不是某個單點技巧，而是把訪談、規格、測試、程式碼審查變成一套固定節奏。

Grill Me 不是讓 AI 變聰明，而是讓任務變清楚

用了 Grill Me，不代表模型突然變成更高階版本，也不代表結果一定完美，它真正改善的是「任務定義品質」。

模糊任務的問題在於，Agent 會把大量隱性選擇變成自己的預設，比方說你說「做一個工具」，它要猜是網頁、CLI、桌面 app 還是瀏覽器插件；你說「幫我寫文章」，它要猜讀者是新手、工程師、主管還是 SEO 流量；你說「做得好看」，它要猜品牌、風格、資訊密度、互動狀態。

Grill Me 把這些猜測改成問題。當問題被回答，Agent 的輸出就不再只是「通用答案」，而會更貼近你的真實情境。

我會怎麼把 Grill Me 放進自己的 Codex 流程？

如果是新專案，我會把流程拆成四步。

  • 第一步，用 Grill Me 釐清需求。先不要寫程式，先讓 Agent 問到目標、限制、驗收方式都清楚。
  • 第二步，把訪談整理成規格。可以轉成 PRD、spec 或 issue，避免後面上下文掉失。
  • 第三步，用 TDD 或驗收清單鎖住品質。讓 Agent 先知道什麼叫完成，而不是做完才補救。
  • 第四步，讓 code review / debug 流程收尾。不要把「看起來能跑」當成完成。

這條路線和 用 Superpowers 建立 AI 開發紀律的方向很接近：不要把 Agent 當一次性神諭，而是把它放進一套有檢查點、有回饋、有驗收的流程。

安裝 skill 前，先想清楚你要它解決什麼問題

很多人看到 skill 倉庫，第一反應會是全部安裝。這可以，但我更建議先從自己的痛點倒推。

如果你常常覺得 Agent 做出來的東西方向不對，先試 Grill Me。若你已經有專案文件，但 Agent 老是誤解術語和架構，可以研究 Grill with Docs。若你遇到的是改一處壞三處，TDD 和 debugging 類 skill 會更有幫助。

如果你想自己建立類似流程，也可以回頭看 用 skill-creator 建立自訂技能。真正好用的 skill，通常不是把所有規則塞滿，而是把一個高頻問題變成可重複執行的流程。

可以直接拿去用的 Grill Me 提示詞

如果你還沒安裝 skill，也可以先用下面這段作為替代版，它不如正式 skill 可維護，但已經能改善很多「太快開工」的問題。

在開始執行前，請先訪談我。
你要把我的需求問清楚，而不是直接開始做。

請一次只問 1 到 3 個最關鍵的問題。
每個問題請附上你的推薦答案，以及為什麼你推薦這樣選。
當你認為需求、限制、輸出格式、驗收標準都足夠清楚後，
請先整理一份任務規格給我確認。
等我明確說「開始執行」之後，你才可以動手。

這段的重點有三個：一次不要問太多、問題要附推薦答案、最後要整理成規格再等確認，這樣做可以避免 AI 把訪談變成問卷疲勞，也能讓使用者比較快做決策。

AI Agent 的品質，常常卡在開工前

Grill Me 給我的最大提醒是：不要把所有問題都歸咎於模型。很多時候，Agent 不是不會做，而是它根本不知道你真正要的是哪一種成果。

需求訪談不是形式，它是把模糊想法變成可執行任務的過程。當目標、場景、限制、輸出和驗收都被問清楚，Agent 才有機會交出真正能用的結果。

我會把 Grill Me 放在 AI Agent 工作流的第一關。不是因為它很華麗，而是因為它解決了一個最基本、也最常被忽略的問題：開始之前，先確定大家要做的是同一件事。

延伸資源

AISA 是什麼？一個 API Key 讓 AI Agent 連上 X、YouTube、股票與支付

AISA 是什麼？一個 API Key 讓 AI Agent 連上 X、YouTube、股票與支付

by | 7 月 7, 2026 | Agent, AI, Payment, skills

AISA 最有意思的地方，不是「又多一個 API 聚合平台」，而是它把 AI Agent 真正需要的外部能力，整理成一個可以被 agent 呼叫的資源層。

以前要讓 agent 查 X/Twitter、找 YouTube 競品、讀股票資料、換不同模型、甚至呼叫付費 API，常常要準備一堆帳號、一堆 API Key、一堆 OAuth 設定和一堆帳單。

AISA 想做的事很直接：用一個 API Key，把模型、資料源、Skills 和機器支付放到同一個入口。

這個方向對 AI Agent 很重要。模型本身再聰明，如果不能拿到即時資料、不能安全地調用工具、不能控制支出，它還是停留在「回答問題」而不是「完成任務」。AISA 的定位，就是補上這一層。

AISA 是什麼？不是只有模型 Gateway

從官方頁的說法來看，AISA 是面向 Agent Economy 的能力層與交易網路。它包含模型 gateway，但不只是模型 gateway。官網 FAQ 明確提到，AISA 讓 agent 用一個 API Key 和統一帳單關係，在同一處存取模型、API、資料源、Skills，以及機器對機器支付能力。

這裡的差異很關鍵。像 OpenRouter 這類多模型統一平台，主要解決「不同模型如何用同一套 API 呼叫」；AISA 更進一步，把資料 API、封裝技能、金融資料、社群資料、搜尋能力和機器支付也放進同一個 agent 工作流。

換句話說，AISA 想解的不是「我要用哪個模型」，而是「我的 agent 要怎麼真的去外面做事」。

一個 API Key 可以接哪些能力？

官方 `llms.txt` 把 AISA 定義成 autonomous AI agents 的 unified API gateway，列出的範圍很廣：GPT、Claude、Gemini、Grok、DeepSeek、Qwen、Kimi、MiniMax、GLM 等模型，還有 100+ data APIs、Agent Skills 和 stablecoin payments。

官網頁面也把幾個能力直接列出來：Tavily 網頁搜尋、YouTube 搜尋、X/Twitter 公開資料、金融市場資料、預測市場、Agent Mail、Circle 小額支付、Machine Payments Protocol。對 agent 來說，這些不是靜態資料庫，而是可以被工作流呼叫的「手腳」。

能力類型AISA 提供的方向適合的 Agent 任務
模型 GatewayGPT、Claude、Gemini、DeepSeek、Qwen 等模型推理、寫作、程式、長上下文分析
X / TwitterTwitter API、Twitter Autopilot、X Intelligence Automation輿情監控、發文、互動、自動整理趨勢
YouTubeYouTube Search、YouTube SERP選題研究、競品內容分析、頻道資料整理
金融與市場股票、Crypto、Prediction Market、MarketPulse研報、行情追蹤、事件監控
機器支付x402、Circle Nanopayments、MPP按次付費 API、agent 自主購買資料或服務

這也回應了第一則留言裡的需求：有人正在找這類資料資源，想讓 Agent 幫忙發推文。AISA 的 X/Twitter Skills 正好對應這種場景。重點不是讓模型「想像社群趨勢」，而是讓 agent 真的去讀公開資料、整理噪音、再決定要怎麼輸出。

X、YouTube、股票資料：Agent 要有真實世界的入口

AI Agent 很容易卡在一個地方：它可以推理，但沒有即時資料。

問它今天 X 上 AI Agent 的討論方向，它如果沒有工具，就只能靠舊知識猜，問它 YouTube 上某個主題競爭激不激烈，它如果沒有搜尋能力，就只能給你方法論，問它最新財報，它可能知道公司很大，但不知道最新數字。

AISA 的價值，是把這些「資料入口」變成 agent 可以安裝和調用的 Skills，X/Twitter 可以做輿情和發文，YouTube 可以做選題研究，金融 API 可以做股票研報，搜尋 API 可以補足即時資訊。這時候 agent 才比較像一個能工作的小助手，而不是只會聊天的模型。

這條路線也可以和你站上之前整理的 Claude Code Workflow 放在一起看：Claude Code、Codex 或其他 CLI agent 是工作介面，AISA 則比較像它們背後的外部能力層。

Skills 的意義：把「會回答」變成「會操作」

AISA 文件中列出的 Skills 很多，從 Twitter Autopilot、YouTube Search、SEO Keyword Research，到 US Stock Analyst、Stock Portfolio、Perplexity Deep Research、Multi-source Search 都有。這裡真正值得看的不是數量，而是 Skills 把任務包成 agent 能理解的操作流程。

同一個問題，有沒有 Skill，結果會差很多。沒有 Skill 時，模型可能只能說「你可以去查財報」。有 Skill 時，agent 可以知道要調哪個 API、要拿哪些欄位、資料錯了要去哪裡補、最後怎麼整理成報告。

這跟前面談過的 Ornith 1.0 自己拆任務、搭 scaffold 的方向其實有點像：模型不是只輸出答案，而是要有一套能完成任務的流程。AISA 則把外部 API 和 Skills 變成這套流程可以調用的零件。

x402 與機器自主付款：很酷，但一定要有護欄

AISA 官網也把機器對機器支付列為核心能力之一，包含 Circle Nanopayments、Machine Payments Protocol，以及 x402 / HTTP 402 風格的支付流程。

HTTP 402 Payment Required 這個狀態碼很早就存在，但以前沒有真正成為日常網路支付流程。x402 類協議讓 agent 呼叫受保護端點時，可以收到付款要求，完成結算，帶著付款證明重試請求。這對付費 API、資料服務、agent-to-agent 交易很有想像空間。

用白話講，402 不是一般錯誤，而是一種「這個資源要先付費」的握手訊號。Agent 第一次呼叫付費 API 時，服務端可以回傳 HTTP 402，並附上價格、收款地址、可用付款網路、付款證明格式和過期時間。Agent 不需要猜怎麼付錢，而是照著這份付款要求完成結算，再把付款證明帶回去重送同一個請求。

AISA 與 x402 讓 AI Agent 自主付費的架構圖

這裡要分清楚一件事：不是把信用卡號交給模型，也不是讓模型任意花錢。比較安全的設計是讓 Agent 只取得「受限制的付款能力」：例如只允許特定 API、單次最高 0.05 美元、每日最高 1 美元、只讀資料可以自動付款、發文或交易則要人工確認。

AISA 在這裡扮演能力層與記帳層，幫 agent 把 API、付款握手、用量紀錄和預算控制串起來。

AI 自己付錢的 6 個步驟

AI Agent 透過 HTTP 402 與 x402 自己付錢的六步驟流程圖
  1. Agent 呼叫付費 API，例如查即時金融資料、X 資料或高價值搜尋結果。
  2. 服務端回 HTTP 402 Payment Required，告訴 agent 這次請求需要付款，並提供價格、收款地址和付款格式。
  3. AISA 或 agent runtime 檢查政策：這個服務是否在白名單內、金額是否低於單次上限、今天預算是否還夠。
  4. 若通過檢查，錢包用 USDC 或支援的付款方式簽名付款，產生 payment proof。
  5. Agent 帶著付款證明重送請求，通常會把 proof 放在 header 或協議要求的位置。
  6. 服務端驗證付款有效後回傳資料，AISA 同步記錄誰呼叫、花多少、成功或失敗。

不過這裡不能只看酷炫的一面。Agent 能自己付費，就代表它也可能亂花錢、重複呼叫、被錯誤 prompt 帶偏，甚至被惡意服務誘導。AISA FAQ 提到可以發放 API Key、監控用量、設定預算或限額，這是必要條件，不是加分功能。

  • 先用低額度測試，不要一開始就給大額預算。
  • 把可呼叫服務設白名單，尤其是會產生費用的 API。
  • 設定單次、每日、每月限額。
  • 高風險動作先要求人工確認，例如發文、寄信、交易、付款。
  • 保留完整日誌，能看出哪個 agent、哪個 skill、哪次呼叫花了多少錢。

這也是 AI Agent 進入實際工作流後一定會遇到的問題：能力越大，權限邊界就越重要。你可以把它和 自學型 AI Agent 一起看，兩者都指向同一件事：agent 不只是變聰明，還要能被管理。

怎麼開始接入？先用 llms.txt 讓 Agent 讀懂平台

AISA 官網給了一個很適合 agent 使用的入口：讓 agent 先讀 `https://aisa.one/docs/llms.txt`，再依照目前環境安全地連接、配置並使用 AISA 的 API、Skills 和 LLM。

閱讀 https://aisa.one/docs/llms.txt，幫我在這個 agent 環境中安全地連接、配置並使用 AISA 的 API、Skills 和 LLM。

實務上可以分三步走：先到 AISA Console 的 get-started 頁面註冊並取得 `AISA_API_KEY`，再把 key 放進 CLI agent 或 IDE agent 的環境變數，最後挑一個低風險 Skill 測試，例如搜尋、YouTube 研究或只讀型 X 資料整理。

如果你原本就在用 Claude Code、Codex 或本地端模型，AISA 比較像補上「外部能力」的那塊拼圖。你也可以對照 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本環境 來思考：本地模型負責推理，AISA 負責外部資料和服務。

誰適合先試 AISA？

我會把 AISA 放在三種使用者的觀察名單裡。

第一種是內容創作者。你需要查 X 熱點、找 YouTube 競品、做 SEO keyword research，這些都很適合交給有資料 Skills 的 agent。

第二種是開發者和自動化玩家。你已經在用 Claude Code、Codex、OpenClaw 或其他 CLI agent，希望讓它們接更多真實 API，而不是每個服務都重新申請 key。

第三種是想做 agent 商業流程的人，例如市場開發、資料整理、金融監控、郵件自動化。這類任務需要的不只是模型，而是資料、工具、信箱、付款和成本控制一起工作。

至於只想聊天或單純換模型的人，AISA 可能不是最輕的選擇。這種情況，單純的模型 API 聚合平台或本地模型會更直接。可以參考你站上的 ApiFree：一個 API 打通所有 AI 模型 這類文章來比較不同路線。

結論：AISA 代表 Agent 從「模型」走向「資源層」

AISA 真正值得注意的，不是它支援多少模型，而是它把 agent 做事需要的資料、API、Skills、帳單和支付，往同一個入口收斂。

這會讓 AI Agent 的下一步變得更清楚：模型只是大腦，Skills 和 API 是手腳，預算和權限是安全邊界，支付能力則讓 agent 有機會直接參與服務交易。

短期內，我會先用只讀型任務測 AISA，例如 X 輿情整理、YouTube 競品研究、股票資料摘要。等日誌、成本和準確性都穩定，再逐步開放發文、寄信、付費 API 這類高風險能力。Agent 要進化成能工作的系統，靠的不是一次把權限全打開，而是一步一步把能力和護欄一起搭好。

FAQ

AISA 是什麼？

AISA 是面向 AI Agent 的能力層與交易網路，讓 agent 透過一個 API Key 連接模型、資料 API、封裝 Skills，以及機器對機器支付能力。

AISA 可以用 X 或 Twitter 嗎？

可以。AISA 官方文件列出 Twitter API、Twitter Autopilot、Twitter Command Center、X Intelligence Automation 等 Skills，適合做公開資料搜尋、輿情整理、發文和互動自動化。

AISA 跟 OpenRouter 有什麼不同？

OpenRouter 主要解決多模型 API 統一入口；AISA 包含模型 gateway，但更大的重點是把 API、資料源、Skills、Agent Mail、金融資料、搜尋與機器支付一起包成 agent 可用的資源層。

AISA 一定要用加密貨幣嗎？

不一定。官網 FAQ 提到可以從一般 AISA 帳號、API Key 和法幣充值額度開始，加密原生結算主要用在機器支付或 x402 類工作流，不是首次整合的必要條件。

Agent 自己付款安全嗎？

不能無限制開放。AISA 官網提到可透過 API Key、用量監控、預算或限額來控制 agent 支出，實務上應該先用低額度、白名單服務、日限額和人工審核逐步放權。

HTTP 402 如何讓 AI 自己付錢？

AI Agent 先呼叫付費 API，服務端回 HTTP 402 Payment Required，並附上付款要求，Agent 檢查預算和白名單後，用錢包簽名付款，取得付款證明，再帶著證明重送請求。服務端驗證付款後，才回傳資料。

Claude Memory 與 Dreaming 是什麼? 自學型 AI Agent 的下一步

Claude Memory 與 Dreaming 是什麼? 自學型 AI Agent 的下一步

by | 7 月 6, 2026 | Agent, AI, claude

AI Agent 記憶系統與 Dreaming 流程的抽象封面圖
Memory 讓 agent 記得自己的工作經驗,Dreaming 則負責在背景整理、驗證與回填這些經驗。

AI Agent 真正難的地方,不是只會不會呼叫工具,而是能不能在長時間、多任務、多 agent 的環境裡越做越好。MCP 解決的是工具與資料接入,Skills 解決的是可重複使用的能力封裝,但如果 agent 每次醒來都像第一次接觸專案,它就很難成為真正可靠的工作夥伴。

這也是 memory 和 dreaming 這兩個概念重要的原因。Memory 是 agent 的可讀寫經驗庫;Dreaming 則像一個離線整理程序,會在任務之外回看多個 session 的 transcript,找出共同錯誤、成功策略、重複資訊與過期記憶,再把它們整理成更可靠的記憶狀態。

為什麼 Agent 需要 Memory?

現在的 agent 已經可以跑很久,有些任務會持續數小時甚至接近數天。問題是,時間拉長後,上下文管理就會變成瓶頸。Agent 需要知道任務成功條件、常見錯誤、哪些策略行不通、專案檔案怎麼組織、以前有哪些調查結果,也要能從其他 agent 的經驗中學到東西。

這一點和我之前整理 Claude Code Workflow 時看到的問題很像:當你同時開多個 agent 或多個工作階段,真正會拖慢效率的,往往不是模型不夠聰明,而是每個 agent 都在重複摸索同一批上下文。

Memory 的設計:把記憶當成檔案系統

這套 memory 設計最有意思的地方,是它沒有把記憶包成一個過度抽象的黑盒工具,而是把 memory model 成一組檔案。Agent 可以像管理專案檔一樣,用熟悉的 bash、grep、檔案讀寫去整理記憶。這和 Claude Code 擅長操作檔案系統的能力剛好接上。

從實務角度看,這比單純塞一段「長期記憶摘要」更適合大型專案。記憶可以拆成不同檔案、不同層級、不同權限:有些是組織層級的 runbook 和最佳實務,應該只讀;有些是某個團隊或某個任務的 working memory,需要 agent 持續更新。

多 Agent 系統裡,記憶不能只有「我記得」

單一 agent 記得自己的工作經驗已經有幫助,但真正的難題在多 agent。當企業裡同時有數百甚至上千個 agent 在跑,它們會接觸同一套程式碼、同一批告警、同一組 runbook。如果每個 agent 都各自學一次,成本會很高,錯誤也會一直重複。

這裡需要兩種能力。第一是權限範圍:有些 memory store 只允許讀取,有些允許讀寫。第二是並行控制:多個 agent 同時更新同一份記憶時,不能互相覆蓋。用 content hash 做 optimistic concurrency,可以讓 agent 在寫入前確認自己沒有覆蓋別人的更新。

如果把這件事放進更大的 AI 工作流來看,它其實和 用 AI 組一家公司 的概念很接近:當 AI 不再只是單一助手,而是多個角色一起工作,組織記憶就會變成基礎設施。

Dreaming 是什麼?

Dreaming 可以理解成「離線記憶整理」。它不是 agent 正在執行任務時的熱路徑,而是一個非同步 batch process。它會回看最近的 agent sessions、transcripts 和工作結果,找出共同模式、重複錯誤、有效策略,再產生一組更新後的 memory diff。

這個設計很重要,因為單一 agent 在任務中只看得到自己的局部視角。Dreaming 則可以站在更高一層,同時看多個 agent 的工作紀錄。它能發現某個錯誤是不是很多 agent 都遇到過,某個 retry pattern 是不是固定在 60 秒後發生,或某份記憶是不是已經過期。

Memory 與 Dreaming 的差別

項目MemoryDreaming
運作時間任務進行中即時讀寫任務外的非同步整理
主要目標讓 agent 記得當前與過去經驗驗證、去重、回填與組織記憶
視角單一 agent 或單一 session 為主跨多個 sessions 與多個 agents
適合解決避免重複調查、保留工作脈絡找共同錯誤、萃取模式、清理 stale memory
對效能影響在任務路徑上,要注意 token 與延遲離線執行,不增加 hot path latency

早期案例透露了什麼?

早期案例有兩個數字值得注意。Rakuten 在內部 knowledge agents 裡導入 memory 後,first-pass mistakes 降低 90%。Harvey 在法律場景 benchmark 中導入 dreaming 後,其中一個 scenario 的 task completion rate 提升 6 倍。

Memory 與 Dreaming 在 Rakuten 與 Harvey 早期案例中的改善幅度圖表
圖表只是把兩個早期案例視覺化。它們不是通用保證,但足以說明 memory 與 dreaming 對長任務 agent 的潛力。

這些數字不能直接解讀成所有 agent 系統都會有同樣改善,但方向很明確:memory 先降低重複犯錯,dreaming 再把多個 agent 的經驗整理成更乾淨、更可用的知識庫。對企業來說,這會同時影響正確率、token 效率、延遲和維護成本。

SRE Agent 的例子最容易理解

假設一個 SRE agent 收到 P1 alert,它開始查 CPU utilization、流量模式、最近部署的 PR,最後把調查結果寫進 SRE memory store。幾分鐘後同樣 alert 又出現,另一個 SRE agent 啟動時,第一件事不是從零開始查,而是先讀到前一個 agent 留下的調查結果,直接避開重複工作。

這就是 memory 的即時價值:省 token、省時間、也讓後續 agent 站在前一個 agent 的肩膀上。再往下一層,dreaming 會回看過去 7 天相關 sessions,找出多個 agent 都沒有單獨注意到的模式。例如很多 alert 都剛好在上游 CPU spike 後 60 秒發生,那可能代表 retry logic 或排程邏輯有問題。

這種模式非常適合 自我進化 AI Agent 架構。但重點不是讓 agent 無限制亂寫記憶,而是要有版本歷史、attribution metadata、審核流程和可回滾能力。

實作時最該注意的三件事

第一,記憶要可審計。誰寫了什麼、什麼時候寫、基於哪個 session 寫,這些資訊必須留下來。否則 memory 一旦被污染,後續 agent 會把錯誤經驗當成事實。

第二,記憶要分層。組織層級 best practices、團隊 runbook、專案知識、個別任務 working memory,不應該全部混在同一個檔案。這和寫 AI 開發紀律 很像:越是長期會被重複使用的規則,越要整理成穩定結構。

第三,dreaming 不應該完全無人監督。它產生 memory diff 後,可以直接套用,也可以先走檢查、PII scanning、人工 review 或外部 pipeline。對企業 production agent 來說,這種控制權比單純「模型會自動學習」更重要。

我的判斷:Memory 會成為 Agent 系統的資料庫層

如果把 MCP 看成工具層,把 Skills 看成能力層,那 memory 很可能會變成 agent 系統的資料庫層。它不只是「記住使用者喜好」這麼簡單,而是把 agent 的工作歷史、錯誤模式、成功策略與環境知識變成可管理、可審計、可演進的資產。

Dreaming 則讓這個資料庫不只是被動儲存,而是能定期整理索引、刪除過期內容、回填驗證結果、把多個 agent 的經驗濃縮成明天可以直接使用的知識。未來真正強的 agent 系統,可能不是單一模型最聰明,而是整個系統能不能把每天做過的事變成明天的能力。

FAQ

AI Agent memory 是什麼?

AI Agent memory 是讓 agent 保留工作經驗、任務策略、環境知識與常見錯誤的記憶系統。它可以幫 agent 在長任務或多 session 工作中避免每次都從零開始。

Dreaming 和一般 memory 有什麼不同?

Memory 偏向任務進行中的即時讀寫;Dreaming 則是離線整理流程,會回看多個 agent sessions,找出共同模式、去重、驗證記憶並回填更好的內容。

Memory 會不會讓 agent 學到錯誤資訊?

會有這個風險,所以 production memory 需要版本歷史、attribution metadata、權限控管、PII scanning、人工 review 或自動檢查流程。記憶不是越多越好,而是要可靠、可追溯、可清理。

什麼情境最適合導入 agent memory?

最適合長任務、多 agent、重複問題多、環境複雜的場景,例如 SRE triage、程式碼維護、企業知識問答、法務研究、客服流程與內部自動化。