Daily Article

https://liao.gg/blog/agents-dont-need-memory

2026 年 10 月 3 日，Kevin Liao 在 liao.gg 寫記憶外掛實際在做的事。外掛分析人的對話，產生一千則彼此孤立的片段，塞進向量資料庫。人每下一則 prompt，它從庫裡拿出最相似的五則，附在 prompt 上。Agent 搞混了，就自己再搜，多拿幾則。他在括號裡補了一句：它本來就會搞混。他們把這個產品叫做記憶。

他沒有點名是哪一家。一千則、最相似的五則，還有文裡後來寫到的五百則、一萬筆、一千萬 token、三年，都是他描述這套做法時用的數字。

先看人要解決的是什麼，這套產品對不上。人要 Agent 懂這份專案。功能在哪裡，是它落在這份程式的哪個位置。為什麼做，是當初的理由。同意過什麼，是已經定下來的做法。在乎什麼，是人在意的事。人打下 prompt，要的是 Agent 照這些往下做。外掛交出來的卻是一場 RAG 抽獎：附上哪幾則由相似度決定，人只能盼有用的自己浮上來。

就算這次浮上來的剛好有用，Agent 手上仍是幾則從舊對話切出來的片段。他認為這不等於懂專案。整個記憶外掛的生態系解錯了問題。Agent 要的是文件。

他看到的每套，都是切片段、進庫、抽五則

他說市面上每一套記憶外掛都是同一條路。先掃一次次工作留下的對話逐字稿。再從逐字稿切出他們稱為記憶的片段。片段放進 RAG 用的資料庫。之後每一次 prompt，都取出最相似的五則，塞回這則 prompt。五則不夠用，就給 Agent 一個工具，讓它自己進庫裡再搜。

人沒有在 prompt 裡指定那五則。外掛按相似度自己附上，連同 prompt 一起送進模型。Agent 搞混了，再用工具多拿，多拿的仍是同一座庫裡的片段。他說架構就這些。

花俏加在這五步後面。有的讓 Agent 把舊逐字稿逐字搜過，一個字一個字對。有的把記憶分成短期和長期。有的在背景跑程式，做檢查、做合併，或把重複的去掉。有一種叫做 Dreamers 的，人沒在下 prompt 的時候，由它過夜把已經存進庫的記憶重寫一遍。也有人一直把上下文壓短。也有人再重排一次。這一類他沒有全部列完。

逐字搜、分層、過夜重寫、壓短、再重排，拿回來的都還是過去的對話。加料會燒 token。他認為這些功能是在補同一套、底下已經有問題的架構。所以他的判斷是，沒有一套因此就靠得住。

片段靠相似度浮出來，人稽核不了這座庫

這些外掛碰到的是同一類問題。他點了五個，還說問題不止這五個。每一套都試著修，也都沒修好。前提是同一個。

相似度只排兩段有多近。文字變成向量，距離近的排前面。近是這張排序唯一在答的事。哪一則是對的，哪一則現在還算數，哪一件該知道的事根本沒進庫，它都不答。人每次 prompt 拿到的就是這五則最像的。像，推不出該信哪一則。

片段存下來的時候，上下文不在裡面。一則 RAG 片段裝得下的字就那麼多，裝不下的留在外面。他點了留在外面的：當時的脈絡，做這件事的動機，學到的教訓，周圍的環境，還有更多。動機是當初為什麼定成這樣。教訓是上次哪裡出過事。環境是當時的程式和限制。這些被切掉之後，Agent 讀到的是一句能被搜到的舊話。

召回把過去當成現在還成立。搜逐字稿是把舊對話再找出來。搜向量庫也是。找出來的是當時說過的話。程式碼不會停在那天。他寫，程式碼每天都在改。改過之後，片段還停在改之前的那次對話。他問：身分驗證若有五百則片段，每一則現在還有多準。

搜尋工具也補不上另一個洞。工具可以交給 Agent。交出去之後，他問的是：Agent 怎麼知道現在該用。要知道該用，得先知道自己缺了一塊。Agent 不知道自己不知道的事。缺的那塊沒被它當成缺，搜尋就不會發生。庫裡就算有，也不會自己冒出來。

庫本身稽核不了。這裡的稽核，是人要能查庫裡到底有什麼。他寫，那裡有一萬筆 embedding，放在 SQLite。哪些記憶在？哪些過期了？哪些放進去之後從來沒被取回過？哪些是錯的，卻在暗中影響 Agent 怎麼做事？這四問要有人答得出來，庫才算查得了。他認為這座庫答不出。錯的那幾則人還沒看見，仍可能在下一次 prompt 裡被附上去。

人留知識是寫下來再用

他把這個生態系的前提這樣講。Agent 會忘。所以要修的是記得。要記得更好，就抓更多進來，把索引做更好，取回的時候更聰明。抓更多，庫裡的片段就更多。索引做更好，相近的就更好被撈到。取回更聰明，五則之外還可以再搜、再挑一次。三步處理的都是舊對話。

別人留知識，靠的是寫下來的紀錄。沒有人會把三年前的團隊會議再看一遍，只為了記起某個功能的限制當初怎麼定。會議當時怎麼講，人把它寫成紀錄。之後要查，人翻的是那份紀錄。限制若只活在三年前的對話裡，就得把整場再看一次才找得到。

解法不是給 Agent 一個搜尋工具，讓它到價值一千萬 token 的舊對話裡翻，把發生過的事用碎片重組起來。重組出來的仍是對話碎片。他寫的解法，是用文件當記憶。

現在這件事更急。很多人用 AI，以很快的速度灌出產品、功能，還有 slop。一行程式都不讀，也不懂。東西可以在沒人讀過程式的情況下交出去。文件就很容易被排到後面，變成事後才想起來補。他認為這時候文件該比以前更要緊。人不讀程式，功能為什麼存在、同意過什麼、人在乎什麼，Agent 還讀得到的，就是有人寫下來、並且還在維護的那些檔。

一份 AGENTS.md 留不住整份專案

人早就知道 Agent 需要脈絡，所以才有 AGENTS.md。這個檔讓 Agent 不要瞎進一份程式碼庫。他說這有用。常常，有用的結果是：整份專案的文件就這一個檔。

一個檔不夠。審查怎麼走、跟使用者討論過的規格、查過的函式庫、做過的決策、給 Agent 找檔用的索引，他要分開放，不要擠在同一份 AGENTS.md。他要一整個工作區，自己稱為 brain。brain 指的是一組有結構的檔，Agent 不必等人先開口，也可以把東西寫進去。裡面放指示、規格、決策、研究、索引，該留的都能留。

指示寫事情怎麼做。程式碼審查怎麼走，放在固定的檔。規格寫跟使用者討論過的內容。研究寫專案原本不熟的東西，一套陌生的函式庫，或一支 API。查過的結果留成檔，下次還能再用。

開工前，Agent 去這個工作區讀相關的檔。他要的脈絡是相關的，也是完整的。完整是指做法、決定、研究還在檔裡，Agent 讀到的是整份紀錄。做完才更新。他把更新的時間卡在這輪：事情剛做完，整張圖還在這輪的上下文裡。過期的檔在這時候改，缺的地方補上新文件。這輪一旦結束，那張圖就不在上下文裡了，過期的檔就不會自己改掉。

舊迴圈是下了 prompt 就做，做完這輪就忘。他要的迴圈是下了 prompt 先查文件，查出相關的檔再做，做完把文件更新。下一輪進來的 Agent 沒有上一輪的對話。它查到的，是上一輪改過的那些檔。

以前的記法，是在 Agent 旁邊再掛一座 RAG 資料庫，每次 prompt 從那座庫抽片段。他要把記憶放進這個工作區。人讀得了，改得了，也可以把檔分享出去。Agent 要懂的那四件事，寫在有人繼續維護的檔裡。下一輪要懂專案，讀的也是這些檔。

一年多前，他叫 Agent 寫進 internal

他說這個問題自己一年多前就看到了。那時他才開始用 AI 寫程式，要的是 Agent 換一個工作階段之後，還記得上一輪做過的工作。上一輪若只留在對話裡，新的一輪就接不到。他建了一個 internal/ 資料夾，叫 Agent 把規格、計畫、索引寫成檔，放在這個資料夾裡。規矩一起寫上：動手之前先讀該讀的文件和索引，做完一定更新。索引讓它知道該讀哪幾份。

那幾條一開始很粗，就是交代 Agent 的話。慢慢地，粗的指示變成一套正式做法，再變成外掛，叫做 Operator Memory。他說自己各個專案現在都固定在用。這一節是他自述這套做法怎麼長出來的：先是資料夾，後來才是這個外掛的名字。

Operator Memory 照他的說法，就是用文件當記憶。它給 Agent 一份 Markdown 工作區，留的是指示、規格、研究、索引。每次開工前一定先查，查的是跟這次工作有關的文件，查完才做。做完一定再更新這份工作區：過期的重新看過，缺了檔的地方補上。兩步中間才是做事。

他不用的東西寫得很具體。沒有向量資料庫。沒有 embedding。背景沒有做摘要的程式，沒有整理記憶的，沒有專門負責更新記憶的，沒有 Dreamers，也沒有其他會燒 token 的背景程式。沒有黑箱取回。黑箱取回指的是：命中了哪一則、為什麼命中，人看不見。他這裡要看記憶，就打開那些 Markdown，字在檔裡。

前面那座庫，他寫過一萬筆 embedding 放在 SQLite，人問不出哪些過期、哪些從未被取回、哪些是錯的。到了這套，記憶是檔。檔在不在，打開就知道。內容舊了，人看得到字。稽核做的是讀檔、改檔。

在他這套裡，每樣東西都是普通的 Markdown。人可以讀，可以改，可以 commit 進版控，也可以跟團隊分享同一份。他說這套自己用超過一年。想試的人，他說是免費、開源的。連結是他給的：https://github.com/aerovato/operator-memory

Source

Context One 是 Chroma 今年稍早推出的 20B 搜尋 sub-agent。CTO Hamad Bashir 上 Software Engineering Daily，跟主持人 Gregor Van 談 agent 已經用機器速度在查、在拆問題。舊的檢索基礎設施跟不上，也貴到划不來。Chroma 在做的，是把對的 context 塞進語言模型的那一層。

Gregor Van 做資安出身，當過資安、網路保險、一般軟體公司的 CTO，人在新加坡。Hamad 過去十年多半在機器學習、電腦視覺跟資料系統。Chroma 最早解的是電腦視覺的主動學習：線上系統每天看到一堆畫面，全標太貴，得挑哪些值得標。那是訓練時的資料挑選。語言模型起來之後，同一套問題搬到推論，變成搜尋：找出最相關的資料，讓下游應用把對的資訊送進模型。

庫、管線，再加上一個會搜的小模型

Chroma 核心要解的，就是讓模型拿到它需要的 context。平台上三塊可以拼在一起。

多數人碰到的是核心資料庫 ChromaDB。Hamad 說它現在是跟語言模型一起用得最廣的資料庫之一。資料灌進去之後，可以用向量搜尋、全文搜尋、metadata 搜尋，把可能相關的東西撈出來。

旁邊一塊叫 Sync，託管的 ETL。開發者多半不想自己做這條管線。資料要進搜尋庫，得清、轉成能向量化的形狀，最好再補 metadata，高吞吐時很煩。Sync 就是做這件事。

今年稍早他們推出 Context One。Hamad 說這多半還是研究，正在往產品化走。它是一個做 agentic search 的模型。常見的 RAG 是搜一次、把結果直接塞進 context window。Agentic search 是把一句高階的英文問題拆成對搜尋系統的低階查詢，讀文件、再發查詢、再讀，直到自己覺得夠了。人查資料也是這樣，不會打一次 Google、看前十個連結就收工。用前沿大模型做這件事很貴。Context One 用強化學習訓練，Hamad 的說法是在這套流程上跟前沿模型一樣好，成本低一個數量級，速度高一個數量級。對照 Opus 4.6，他們跑在大約每秒 400 到 500 token，Opus 大概每秒 40 到 80。品質對得上，答案來得快，也便宜。

AI 工作負載要很多小 index

他們一開始並不想做資料庫。Gregor 說他看這個領域，向量搜尋熱過一陣、冷過一陣，現在又回來；Hamad 當時用的就是市面上現成的向量搜尋。後來發現，那些系統幾乎都是為舊搜尋工作負載設計的：一個非常大的 index，一百萬份文件、十億筆資訊，全塞在一起。再加五十萬筆，就得重切 cluster、加減節點、重新平衡，操作很重。

AI 應用幾乎是反過來。index 切得很碎：每個客戶一個、每個團隊一個、每段聊天紀錄一個、每個 agent 一個。系統得存非常大量彼此獨立的 index，搜尋還得準。全塞進同一個 index，一是得一直把整坨掛在線上，二是向量搜尋擠在一起準度會掉。向量搜尋不擅長靠查詢時過濾來做分區，該在建 index 時就硬切開，邏輯上分開存。資料有這種可分區的結構，就該做很多小 index，品質跟成本的取捨會好很多。ChromaDB 就是因為沒有現成方案把這件事做好，才自己動手。

底下那層是物件儲存。AWS S3、GCP GCS、Azure 都開始支援 conditional write；Hamad 特別講 AWS，這東西 2024 年才出來。有了它，才能在物件儲存上蓋資料庫，經濟帳才撐得住「每個客戶、每個團隊、每個 agent 各有一份 index」。以前用三副本磁碟或 NVMe SSD，有些產品根本做不起來。他們先做給自己用，要在推論時決定塞什麼進語言模型。

Agent 起來之後，讀的壓力更大。Agent 會平行發五條查詢。人覺得快，大概是三十秒一次；agent 樂意每一到兩秒就查，而且每次五條、六條並行。核心架構如果是無狀態、底下是共享儲存，加節點就能消化讀。Hamad 說，當初蓋在物件儲存上，沒預料到這層彈性，事後卻很受用。

Context Rot：窗愈滿，模型愈差

Chroma 去年出過一篇 Context Rot，主持人說大約是 2025 年 6、7 月。Hamad 說，多數人憑感覺就知道 context 一肥，模型會變差；這篇是用實驗把這件事量清楚。做法很窄：反覆塞同一個詞，問模型「stop」出現在哪；或者把大海撈針的題目打亂順序，丟一堆文件進去，看它找不找得到那根針。結果在數萬 token 這個量級出現很陡的掉落，今天的前沿模型也一樣。報告出來之後又過了大約三代、或幾次小改款，掉落還在。

這逼出一件事：context window 裡放什麼，得有紀律。他們接受 context engineering 這個詞，講的就是下一輪、或下面幾輪要成功，該選什麼進去。查什麼、資料怎麼排、怎麼 prompt、模型能碰到哪些資料，都算。就算有一天 context rot 被解掉，無限把 window 拉大，成本也吃不消。這類系統很容易在很短時間把錢燒光。

這套實驗當時測了十八個模型，Anthropic 那些大的、也有很多開權重模型。Hamad 說對。當時開權重跟閉源前沿差很明顯；過去一年開權重追很快。他們內部還會在新模型出來時跑同一套，有些任務上開權重已經能勝過部分閉源。他講得很明白：這是一套很刻意、很窄的實驗，當健身房用。

干擾項一加，模型要忽略「看起來像對、但其實不是」的資訊，能力就往下掉。兩個事實沒有互相打臉、卻在講同一件事的不同面向，模型很不會拆。他舉的例子是問喬治亞的人口，文件裡同時有國家 Georgia 跟美國喬治亞州，題目已經指定要州，模型還是可能混。真實世界更常見：兩個人同名，把其中一人的工作安到另一人頭上，公司裡問錯人；寫程式的 agent 看到兩套認證系統，問的是其中一套，卻鑽進另一套。他們想量的就是：表面像、其實無關的資訊，模型能拆到什麼程度。

大模型派出的搜尋員

Context One 的用法是掛在更大的模型下面當 sub-agent。Codex、Claude Code、Cursor，還有不少開源 harness，已經會派出另一個語言模型去做一件事。這裡那件事是：把執行任務可能需要的資訊找出來，把 context 帶回來。它被設計成通用的搜尋 sub-agent，給任何大型推理模型用。

想法很傳統：把該分開的關心點分開。搜尋這件窄事，小模型就夠。要懂使用者意圖、拆成查詢、判斷文件相不相關、反覆做。多數時候要的是把這些事做很快，智力不必拉到前沿。他們用每秒多少 token 來想這件事。下一代甚至在想怎麼用平行跟分片去應付很大的語料。Sub-agent 在背景把它覺得相關的文件找回來，交給比較大的推理 agent 去做它真正要做的事。

再往前一步，大模型當編排者、規劃者，底下是一群小模型，平行派出。Hamad 說他們很信這套，寫程式的系統已經在這樣跑，他覺得接下來一年幾乎每個 agent 都會走到這條路上。Context One 要卡的就是這個位置。它的工作是搞清楚該找什麼、找到之後交出去。

主持人把工具列成向量加 BM25、hybrid search、regex-grep、讀文件，以及 prune chunks。Hamad 自己收得更短：標準的 agentic search harness 其實只要兩樣，搜，以及把結果取回來，像拿到十條藍連結再點進去。他們多加的，是自己編輯 context，也就是主動管 context。

長 context 現在主流是 compaction：coding agent 把 window 用滿了，就摘要、壓縮。小模型做這件事很容易丟東西，尤其它是被大模型派出去做一件很窄的事。他們改成邊走邊改自己的 context。Agentic search 很吃 token，碰到的文件都會進 window，很快堆出很大的量。Prune chunks 讓模型回頭把自己 context 裡的文件拿掉。這是 KV cache 連貫性跟整體 token 用量的取捨。模型判斷相不相關、把先前的資訊拿掉，這件事它本來就得會，否則搜尋做不成。

難的是：搜尋前期看起來不相干的文件，後面可能突然有用。訓練就得覆蓋夠多種相關程度，把回傳的文件擾動成夠難的例子，讓 prune 的時機準。底模是 GPT-OSS 20B。剛訓練時，prune 大約八成會選對該拿掉的文件，等於這工具對底模根本不能用，直接吃掉兩成準度。訓練完，在各種任務上大約九成五以上；內部最近的 checkpoint 接近九成七、九成八。剩下的錯，多半來自搜尋本身。模型判斷準不準、相不相關，已經相當好。

自己剪 context，整體 token 用量少很多，推論也快，因為 window 隨時壓在大約三萬二千 token。Prefill 跟 decode 都相對快。模型夠小，可以接受因為 prune 而反覆付 prefill。何時剪、剪多少，還有很多細節。他們也開始把延遲當成訓練目標，讓模型在訓練時自己找對速度也划算的 prune 策略。Harness 這邊真正多出來的想法，是模型改自己的 context、改自己的歷史。

節目裡提到，沒多久之前的數字，20B 的 Context One 在他們多數基準上對得上 Opus 4.5、Sonnet 4.5、Gemini 3.1 Pro。Hamad 接著講為什麼特化過的小模型做得到。

搜尋是一串窄任務

他把搜尋拆開之後，覺得行為比推理值錢。搜尋有一套可跟的程序，是很多很窄的子任務串起來：高階問題拆成對搜尋系統的低階查詢計畫；看一頁判相關；看一頁決定下一輪查什麼；對手上這批結果再做一次不一樣的相關判斷。這些可以分開用訓練例子練。

Context One 的課程是分階段的。早期只給一跳、兩跳就能滿足的簡單題，後面再把難度拉開。訓練也不只強化學習。前面還有一輪監督式微調，用合成資料，以及從開權重模型蒸餾出來的行為。光是把那些行為蒸進小模型，表現就會跳一截。先把「這種情況該怎麼做」的先驗塞進去，後面比較好優化。

光是教會它平行呼叫工具，就能少很多輪才找到資訊。GPT-OSS 20B 原生不會平行 tool call。做一點 SFT，從資料裡教會這個行為，強化學習還沒上，它就已經會用、而且用得很好。

這類任務不需要很多推理容量，也不需要很多細微決策。世界知識確實有幫助，對某個主題記得多，查詢會出得比較好，穩態下大模型大概永遠贏小模型。小模型卻便宜到可以用 LoRA 微調。語料夠窄，很快就能針對那份語料個人化。給它一份語料地圖，或教會它那份語料的詞彙，搜尋會準很多。人搜自己的 Google Drive 也是這樣，因為已經知道裡面有什麼。

Apache，本機就能跑

Context One 的權重用 Apache 授權開源。Chroma 是開源公司，核心資料庫也是 Apache 2.0。Hamad 說自己進 Chroma 之前不算開源死忠，這幾年才變成很堅持該開的東西就開。公司裡也有這份信念。

實際理由很直接：開源才有更多人用，才有人告訴他們哪裡好、哪裡爛，才有人把它接到他們自己接不到的地方。模型很小，本機跑得動。Chroma 當初在市場上長起來，靠的就是本機版資料庫。他們喜歡開發者在筆電、在家裡的機器上就能摸到接近前沿的東西，不必先花一大筆錢。之後每一個模型是不是都開源，他不打包票；至少現在，他看不到不繼續開的理由。他們自己訓練 Context One 就用了開權重模型，平常也在用。新聞上好像世界要被 AI 蓋過去了，他覺得還很早，現在不該用零和的方式想這件事。

開發者多半從本機嵌入式資料庫開始：pip install 一個套件，Jupyter 或 TypeScript 裡，機器上就跑起來了。原型做完，有 CLI 可以把資料推上雲。跟傳統關聯式資料庫不太一樣，這類應用常常會先整理一份知識庫或資料集，再從 staging 推到正式環境。

上正式有兩條。一條直接用資料庫，自己控切塊策略、embedding 模型、各種參數。這幾年實務慢慢收斂：稀疏向量配 splayed；dense embedding 要夠好、但不必太大。他說用不到 4096 維，比較小的維度準度差不多，成本低很多。不想自己選，就用 Sync：資料丟進 S3、上傳檔案，或接他們支援的來源，像 GitHub、網站，之後還會再加一堆上游連接器，來源跟 Chroma 會自動對上。

Context One 通常是後面才接。Agentic search 還新，多數人產品做到後期才認真想低延遲、高品質搜尋。放出來之後，有人開始用它當產品起點。一旦假設查詢是 agent 在做，產品會長得不一樣。有人問：那人幹嘛還自己改資料？已經有產品不准使用者直接改，只准透過模型改，因為他們覺得模型比較會在資訊空間裡走對路、改對地方。表單、勾選、拉桿不必樣樣都有，很多事可以直接用自然語言推進 agent。

一萬筆，Postgres 就夠

資料量小，Hamad 說丟進 Postgres 就行。只有一萬筆紀錄，大概不需要水平擴出去的 serverless 搜尋引擎。企業要不要 BYOC，是另一件事。Hamad 說 Databricks 早期做過混合部署，後來被問若重來會改哪兩件事，其中一件就是不做混合、直接走另一條。他也說這可能是事後才講得輕鬆，沒做混合，說不定根本走不到後來。Chroma 的 BYOC 是把程式部署進客戶 VPC，控制面留在自己這邊，拿回觀測資料來操作、更新、擴縮。客戶拿到託管服務的體驗，自己不用跑基礎設施。套 Terraform、跑 Helm chart 就能起來，day two 由他們團隊扛。這件事他們從第一天就打算做；不做進架構裡，後面要補非常難，整套設計都卡在這上面。團隊當初很難被說服，因為這樣蓋很痛、速度很慢，系統邊界也會畫得不自然。

除非這件事對生意成長是核心，否則他不建議做。對他們重要，是因為核心資料庫真正有用的客戶在大規模。他給 YC 那屆創辦人的建議是：做之前先確定這件事能賺很多錢、而且能重複部署，否則是很大的分心。買家這兩年開始會推，因為過得了資安跟合規。BYOC 剛出現時，網路上不少有名的人覺得這是最蠢的部署模型。它比較像組織稅：讓合規、資安睡得著，讓你保有控制感。是不是真的比較安全，還是得自己看裡面。

控制面仍在 Chroma 這邊，有客戶連遙測都不想讓他們碰。產品沒有基本遙測就跑不起來。他們這邊存的是 metadata：系統裡有什麼資料、用量、版本跟 epoch 計數，沒有直接暴露私人資訊。因為開源，控制面程式可以直接丟給客戶看 schema。Slack 上有人問存了什麼，他們把程式貼進去，叫 agent 把相關檔案走一遍，列出清單，答案對得回程式。資料平面預設不開埠，反向隧道，由資料平面向外連，他們不伸手進去。遙測先緩衝再推出去。操作也不是對資料平面發 POST，裡面有個服務在輪詢，把操作拉下來做。這是很怪的做法，零件很多，只為了在叢集裡做一件本來很單純的事。他們蓋在 Kubernetes 上，還能借宣告式的鉤子，仍然比直接發請求重很多。他說如果進公司六個月才有人說要做 BYOC，他會直接回做不到。

語言模型當 CPU，旁邊還需要一塊碟

Postgres 最近又熱，有人說 pgvector 就夠了。Hamad 的判斷是：語言模型永遠需要有人管它此刻該知道什麼。去 ChatGPT 問今天行程，就算接了 MCP，很多時候還是沒叫對工具、沒在對的時間講對的話。把對的資訊送進模型，這件事不會消失。

他拿 CPU 跟檔案系統來比。語言模型是 CPU，旁邊有一塊碟。碟裡面很複雜，介面、控制器、作業系統、韌體都在。Chroma 信的就是那層介面：一邊是用自然語言處理資訊的系統，一邊是決定模型該看到什麼、該存什麼、哪些該更新、該跟既有資訊合併的子系統。今天看起來很像資料庫。那一家做資料庫的公司為什麼自己訓練模型？因為他們覺得很快就不會再把資料庫跟智力拆成兩套，智力會跑在資料庫裡面，資料庫靠有智力的子系統做事。兩件事得一起想，為了效能，也為了懂這塊領域。

把大量資料搬來搬去、轉成各種下游要的表示、做 ETL、重排格式、重建 index、重新解析，都很貴。如果能在一個地方管完，用物件儲存、共享儲存層，把計算搬近資料，就可以在資料上跑非同步的語言模型工作，也可以讓帶查詢 index 的節點跟 GPU 放在一起，GPU 不必打遠端服務，打的是本地模型。他說今年大家當消費者用的模型，很可能跑到每秒一千 token；去年還在每秒一百。再過幾年每秒一萬，他覺得可以想像。今天的搜尋系統假設打一槍網路、等搜尋回來沒關係，因為模型很慢。模型不會一直慢。智力和資料該走低延遲路徑，將來甚至可能繞過 CPU，在 GPU 上直接起一個子 kernel 搜 index，再把資料餵回模型。

長期他們想做的，是一份非結構化資料丟進去，任何查詢都能在出口被滿足。他不覺得那套東西會長得像 Postgres，跟今天也會差很多。先把抽象跟積木放對，也許以後有資格去做那套系統。

開發者要上手，Hamad 說 pip install chromadb，再 chromadb run 就夠。想看更多，去 chroma.com。名字怎麼來的？短、好念、好記，聽起來順。