為反洗錢打造具備記憶感知能力的代理框架——Oracle 的 Nacho Martinez

Oracle 的 AI 開發者推廣者 Nacho Martinez 主張，AI 代理（AI agent）之間的效能差距，主要不是來自前沿模型（frontier model），而是來自「harness」——也就是圍繞模型所建構的記憶、工具、感知與代理迴圈（agent loop）這套鷹架——因此工程師應該把心力投注在這一層，而不是忙著換模型。整場議程大部分時間都花在 harness 架構上：代理堆疊、AI 應用的四種形態、短期與長期記憶、上下文工程（context engineering，包含摘要與壓縮）、工具箱／技能箱（toolbox/skillbox）檢索模式，以及 chat-completions 請求內部的指令階層。標題點名的反洗錢（AML）銀行情境，只是工作坊的敘事框架與示範場景，並非分析主軸——這場演講本質上是一份通用的 harness 設計入門，只是拿一個詐欺偵測代理當作實作範例。

Martinez 是 Oracle 的 AI 開發者推廣者兼資料科學家，近期與 Andrew Ng 及 DeepLearning.AI 共同推出一門關於打造自適應 AI 代理的課程。本簡報的物件是實務工作者——尤其是顧問與金融服務業的工程師——他們想了解：為什麼同一個模型在不同 harness 下表現會不一樣，以及如何讓代理的上下文視窗維持得又小、又相關、又便宜。

你能掌控、也是效能勝負關鍵的地方，是 harness 而非模型

Martinez 的核心論點是：前沿模型是工程師唯一無法形塑的一層，所以槓桿落在資料層——代理迴圈、記憶、工具／技能，以及上下文工程。他表示，已有研究顯示，光是更換 harness，同一個模型在特定任務上的表現就會變好或變差。他把 harness 定位為三大元件——工具使用、記憶、感知——的鷹架，架在推理之上，而推理由前沿實驗室提供。

他把代理堆疊描述成四層：應用層（聊天機器人、行動 App、介面）、作為推理核心的模型、基礎設施，以及算力。工作坊鎖定的是資料層，因為「所有我們能操作、能繞路處理的東西，都在這一層」。在資料層裡，他放進了代理迴圈、用來接外部資料的閘道加 MCP、記憶層、負責摘要／壓縮／縮減工作上下文的上下文工程元件，以及工具與技能。

他把 AI 應用歸納成四種形態，並主張最好的系統會結合後兩種：

| 形態 | 內容 | Martinez 的評語 |
|---|---|---|
| LLM 聊天機器人 | 對話式介面 | 「非常簡單」——很多人最先做的東西 |
| RAG 應用 | 對向量儲存庫做檢索 | 「包裝得漂漂亮亮的向量搜尋」 |
| LLM 驅動的工作流程 | 自動化 | 提供自動化 |
| AI 代理 | 自主性 | 提供自主性 |

Claude Code、Codex、Pi、OpenClaw 與 Hermes agent，在他的框架裡都是第三與第四種形態的組合——也就是把自動化與自主性混在一起的「代理式系統（agentic system）」。他不滿的是，工程師天天在用這些系統，自己開發應用時卻不照同樣的方式做，反而預設回頭去寫聊天機器人或 RAG。

「harness 其實是 AI 裡最有趣的主題之一。我認為它是當今 AI 最有趣的主題，因為這些 harness 實際上掌控了 AI 代理能做的一切。」

他用一段延伸類比把代理比作人：LLM 是大腦／推理，資料庫是記憶，工具是作用於世界（在這裡是作業系統）的四肢，而有根據的輸入則是感官。上下文就是注意力——就像一個人沒辦法同時看七部電影，代理的上下文視窗有限，而且隨著塞進去的東西變多而劣化。

上下文視窗越大，表現越差——所以壓縮與摘要非做不可

Martinez 指出，注意力矩陣（也就是上下文視窗）越大，每個模型的表現都越差，而且這點不分題型皆成立。他引用研究說明：同一個問題在零 Token 時解出的準確率，遠高於已經載入 256,000 個 Token 的情況。帳面宣稱的上限大約是一百萬個 Token（受 KV 快取限制），但他警告，遠在那之前效能就已經「慘不忍睹」。

他區分兩種把視窗縮小的技巧：

• 上下文摘要（context summarization）——請模型針對視窗內所有內容產生一份簡短摘要，下一段對話就從這份摘要重新開始。
• 壓縮（compaction）——把對話切塊存進資料庫或檔案，每塊標上 ID，需要時讓代理帶著位移量（offset）依 ID 取回某一塊，「有點像從檔案裡讀取」。

他把這套做法扣回代理迴圈，並稱之為「駕駛或車子本身」。迴圈會從技能、工具、先前的對話、檔案與資料庫動態組裝上下文，進行推理，向模型發出 API 呼叫，再決定下一步——若設定成這樣，就會無限重複。在工作坊的迴圈裡，他把迭代次數上限設為八次、每次迭代的推理上限設為 60 秒，明確是為了避免燒掉 OpenAI（或其他供應商）的額度。他強調這些限制完全可以設定，取決於工程師的決定。

記憶應拆成短期與長期，長期再細分為情節、程式與語意

Martinez 把記憶視為讓代理在對的時機使用、精煉與回想資訊的機制，並表示架構怎麼設計由工程師決定。他提出一套兩層模型：

• 短期記憶就是上下文視窗本身。對話結束後大部分就消失了，新對話從零開始。容量非常有限。
• 長期記憶再分成他提出的三類：
• - 情節記憶（episodic）——發生過的一切：對話片段、工具日誌、先前對話的摘要。
• - 程式記憶（procedural）——技能與工作流程（一連串技能的執行序列）。
• - 語意記憶（semantic）——代理對你的認識：身分、偏好、慣用的框架。

他的實務建議是先從簡單做起：先只玩短期與長期記憶，當代理判斷視窗內某個東西值得保留，就以原始文字形式升級到長期儲存。之後才把它向量化，讓代理迴圈去探索。他在「觀察」與「推理」之間多畫了一步——「回想長期記憶」的呼叫——讓代理在解題前先自我檢視：如果查詢與某筆已存記憶的向量距離夠近，就拉進上下文；不夠近就丟掉。

被問到情節記憶會不會跟先前的對話混淆，他說這取決於你給它多少權重，並把答案扣回指令階層——如果情節回想很重要，就把它向量化，而不是存原始文字，同時讓各記憶元件之間界線清楚，避免彼此衝突。

工具箱與技能箱模式，讓上百個工具不必擠進上下文視窗

Martinez 提到自己已經裝了大約 100 個技能，而每個技能可能吃掉 3,000 到 5,000 個 Token。全部載入會直接爆掉帳面上限，真正的對話反而沒空間。他提出的解法是把工具與技能向量化成嵌入（embedding），迴圈需要時再跑向量相似度搜尋——拉出最相關的技能或工具，解決問題，再解除安裝回去。

在工作坊的實作裡，迴圈會從各自獨立的向量儲存庫取出前三大工具與前三大技能（k=3），每一步要做什麼則由模型自己決定。他提到一個可選的最佳化：在相似度搜尋之後加一個重排序器（reranker），從三者中挑出唯一最佳解，因為一個任務可能只需要一個技能。他強調，不管你選哪種檢索策略，「就堅持用它，一路保持一致到最後。」

他也介紹了技能蒸餾（skill distillation）：從先前的對話與執行紀錄中挖掘出可重複使用的東西——例如寫一份技能 markdown 檔放進同一個技能箱。他的例子是前端工作：把你偏好的配色風格寫成一個技能，下次你提到「配色風格」時，代理的向量搜尋就會自動把它撈出來。他把 Hermes agent 譽為用這種方式生成技能的創新者。

至於技能箱為什麼勝過單純的技能檔案：文字檔只能靠關鍵字或正規表示式（grep）比對，檔案一大，成本就呈平方成長；而預先算好的嵌入能在 384 到 1,000 多個維度上捕捉語意，實現語意搜尋。把語意搜尋與關鍵字搜尋結合起來就是混合搜尋（hybrid search），他稱之為 RRF（倒數排名融合，reciprocal rank fusion）；他在工作坊裡展示了一張視覺化圖，把關鍵字結果與語意結果並排畫出，中間那段落差，就是混合搜尋判定比任一種方法都更相關的專案。

檔案與資料庫是假二分——資料庫幾十年前就解決了多寫入者一致性

Martinez 直接回應「檔案還是資料庫」的爭論。有人主張什麼都該放檔案，代理就會神奇地變好；另一派則是「資料庫極大化主義者」。他的答案是：檔案適合某些用途（大量非結構化資料），資料庫適合另一些，應該按使用情境來選。

他舉了一個具體例子：多個代理同時寫入同一個檔案。目前的變通做法是工作樹（worktree）——這個答案還是由現場一位聽眾提供的。Martinez 說，工作樹等於把資料庫三十年前就解決過的問題重新發明一遍：有了交易式／ACID 一致性（原子性、一致性、隔離性、永續性的寫入），對同一檔案的並行寫入就不會產生工作樹現在忙著補救的排序錯亂與讀取到過期資料的問題。

「工作樹這個解法、這個變通做法，資料庫三十年前就解決了。我們卻還在用其中一些東西重新發明輪子。」

指令階層與語意快取，同時解釋了模型行為與 API 經濟學

Martinez 說明，每一個 chat-completions 請求都內建一套權重不同的指令階層。系統提示（system prompt）最重要，使用者請求排第三。工具與技能位在最底層、權重最低——「一個隨插即用的地方，你可以把東西拉進來」。他說自己和同事（Richmond）正在實驗接入外部或第三方的技能中心與工具中心（一堆 MCP 的集合），做法是預先算好嵌入，讓代理能對它們做向量搜尋。

他拆解一個典型請求的 Token 預算：系統提示大約 5,000 到 10,000 個 Token，開發者／應用程式指令，使用者查詢大約 100 到 1,000 個 Token，而工具輸出加上檢索到的檔案佔了整個請求的 80%——35,000 到 100,000 個 Token。之所以成本沒有變成四、五倍，關鍵在於語意快取（semantic caching）：如果一個請求有約 80% 與前一個相同，供應商就不會重算。他說，正是這個機制讓前沿模型的消耗在經濟上還說得過去。

談到 MCP，他的態度相當保留。對資料庫而言，MCP 解決的主要問題是避免代理每次都幻覺出 SQL——SQL 引擎很多（Postgres、Oracle Database、MySQL），各有引擎專屬的提示與眉角。解法是預先建好驗證過的 SQL 查詢，讓代理去取用，而不是每次重新生成。

持續學習有三條路，工作坊只實作非引數式那一條

被問到「凍結」的模型要怎麼變強，Martinez 列出持續學習（continual learning）的三大類：

| 類別 | 改變什麼 | 工作坊是否涵蓋 |
|---|---|---|
| 引數式記憶 | 神經網路的權重（例如 LoRA、微調） | 未涵蓋 |
| 表徵式記憶 | 嵌入／嵌入模型 | 未涵蓋 |
| 非引數式記憶 | 一切外部事物——記憶、技能、檢索 | 工作坊重點 |

他請讀者去看他與 Andrew Ng、DeepLearning.AI 合作的免費一小時課程，補足另外兩類，並表示議程結束後可以在 Oracle 攤位繼續聊。

AML 銀行示範只是框架，重點是通用的 harness 課題

工作坊設定在一家中型銀行，裡頭有橫跨五大類的大量可疑交易。他舉的可疑活動例子是：一筆 100 萬美元存款，接著連續三天每天提領 5 萬美元現金。前提是一個 24 小時全年無休運作的自主代理，負責標記並分析交易，讓銀行的人力 AML 團隊少花時間在發現問題上——同時刻意不採取破壞性動作（他強調它不會封鎖帳戶去「毀掉別人的人生」，而是把決策印出來供人檢視）。

現場示範在 Oracle Cloud Infrastructure 上跑 Grok 4.3 模型，對一個假交易資料庫運作，介面會顯示被標記的專案、客戶資料、工具呼叫軌跡、向量儲存庫的知識查詢，以及自動生成的可疑活動報告，另外還有一個檢視最近 30 筆銀行事件的畫面。工作坊本身是 notebook_student.ipynb，架在 GitHub Codespaces 上；參加者在 workshopwaitingroom.com 用 GitHub 帳號報名，系統會透過 GitHub API 自動送出 repo 邀請。Martinez 說 Codespaces 的費用他自掏腰包，並提醒參加者注意硬體規格的選擇，因為所費不貲。

他給實務工作者——尤其是顧問——的最後建議是：不要想重建 Claude Code。應該把問題簡化，然後在它旁邊接一套小而自製的 harness。金融場景的 harness 和用來硬解數學難題的 harness 限制不同：後者需要自動壓縮／摘要，還需要近乎無限的耐心，因為迴圈裡沒有人。他建議從零開始，因為「這樣你才能把 90% 用不到的東西直接砍掉。」

整場議程的主線是：harness 是一連串工程取捨——上下文大小對比準確度、檢索廣度對比 Token 成本、檔案對比資料庫、引數式對比非引數式學習——而同一個前沿模型會成功還是失敗，取決於這些取捨怎麼設定。尚未解決的張力在經濟面：工具箱／技能箱模式與重度檢索之所以還負擔得起，全靠供應商端的語意快取，這是 Martinez 有指出、卻沒有量化的一項依賴。自建 harness 的團隊應該持續觀察：當供應商調整定價與提示處理方式時，這種快取行為還撐不撐得住——因為它正是「把上下文壓小、檢索用力拉」這整套做法底下那筆安靜的補貼。