您的 Harness，您的記憶

Agent harnesses 正逐漸成為建構 Agent 的主流方式，且這種趨勢不會改變。這些 harnesses 與 Agent 的記憶緊密相連。如果您使用封閉式的 harness——特別是當它位於專有 API 後方時——您等於選擇將 Agent 記憶的控制權交給第三方。記憶對於創造優質且具黏著性的 Agent 體驗至關重要。這會造成極高的鎖定效應（Lock-in）。記憶——以及因此而來的 harnesses——應該是開放的，這樣您才能擁有屬於自己的記憶。

Agent Harnesses 是建構 Agent 的方式，且這種趨勢不會改變

過去三年中，建構 Agent 系統的「最佳」方式發生了巨大變化。當 ChatGPT 問世時，您能做的僅僅是簡單的 RAG 鏈（LangChain）。隨後模型變得稍微強大了一些，能夠建立更複雜的流程（LangGraph）。接著它們變得更強大，這催生了一種新型的鷹架（scaffolding）——即 Agent harnesses。

Agent harnesses 的範例包括 Claude Code、Deep Agents、Pi（驅動 OpenClaw）、OpenCode、Codex、Letta Code 等等。

💡Agent harnesses 不會消失。

有時會有一種觀點認為，模型將會吸收越來越多的鷹架功能。這是不正確的。實際發生的情況（且未來將持續發生）是，2023 年所需的許多鷹架已不再需要，但它們已被其他類型的鷹架所取代。根據定義，Agent 是一個與工具和其他資料來源互動的 LLM。LLM 周圍將永遠需要一個系統來促進這類互動。需要證據嗎？當 Claude Code 的原始程式碼外洩時，裡面有 51.2 萬行程式碼。那些程式碼就是 harness。即使是世界上最強大模型的製造商，也都在大力投資 harnesses。

當像網路搜尋這類功能被內建於 OpenAI 和 Anthropic 的 API 中時，它們並非「模型的一部分」。相反，它們是位於 API 後方的一個輕量級 harness 的一部分，透過這些網路搜尋 API（僅僅透過工具呼叫）來協調模型。

Harnesses 與記憶息息相關

Sarah Wooders 寫了一篇很棒的部落格，探討為什麼「記憶不是一個 plugin（它就是 harness 本身）」，我對此深表贊同。

有時會有一種觀點認為，記憶是一個獨立的服務，與任何特定的 harness 分開。但在當前這個時間點，這是不正確的。

harness 的一項重大責任是與上下文（context）互動。正如 Sarah 所言：

要求將記憶插入 Agent harness，就像要求將駕駛功能插入汽車一樣。管理上下文，進而管理記憶，是 Agent harness 的核心能力與責任。

記憶只是上下文的一種形式。短期記憶（對話中的訊息、大型工具呼叫結果）由 harness 處理。長期記憶（跨會話記憶）則需要由 harness 進行更新與讀取。Sarah 列舉了許多 harness 與記憶緊密相連的其他方式：

AGENTS.md 或 CLAUDE.md 檔案是如何載入到上下文中的？
技能元資料（metadata）是如何呈現給 Agent 的？（在系統 Prompt 中？在系統訊息中？）
Agent 能否修改自己的系統指令？
什麼內容能在壓縮（compaction）過程中保留下來，什麼又會遺失？
互動過程是否被儲存並可供查詢？
記憶元資料是如何呈現給 Agent 的？
目前的工作目錄是如何表示的？暴露了多少檔案系統資訊？

目前，記憶作為一個概念仍處於萌芽階段。對於記憶而言，現在還非常早期。坦白說，我們看到長期記憶通常不是 MVP（最小可行性產品）的一部分。您首先需要讓 Agent 能通用地運作，然後才能考慮個人化。這意味著我們（作為整個產業）仍在摸索記憶的定義。這也意味著目前還沒有關於記憶的知名或通用抽象概念。如果記憶變得更為普及，且隨著我們發現最佳實踐，未來獨立的記憶系統或許會變得合理。但在當前這個時間點還不會。正如 Sarah 所說：「最終，harness 如何管理上下文與狀態，是 Agent 記憶的基礎。」

如果您不擁有您的 harness，您就不擁有您的記憶

harness 與記憶緊密相連。

💡如果您使用封閉式 harness，特別是當它位於 API 後方時，您並不擁有您的記憶。

這表現在幾個方面：

輕微的負面影響：如果您使用有狀態的 API（例如 OpenAI 的 Responses API，或 Anthropic 的伺服器端壓縮），您是在他們的伺服器上儲存狀態。如果您想切換模型並恢復之前的對話串，這將無法做到。

負面影響：如果您使用封閉式 harness（例如 Claude Agent SDK，它底層使用 Claude Code，而後者並非開源），這個 harness 與記憶互動的方式對您而言是未知的。也許它會在客戶端建立一些產出物（artifacts）——但它們的格式是什麼？harness 應該如何使用這些產出物？這些都是未知的，因此無法從一個 harness 轉移到另一個 harness。

💡但最糟糕的情況是——當整個 harness（包括長期記憶）都位於 API 後方時。

在這種情況下，您對記憶（包括長期記憶）完全沒有所有權或可見性。您不了解該 harness（這意味著您不知道如何使用該記憶）。更糟的是——您甚至不擁有這些記憶！也許部分內容透過 API 暴露出來，也許完全沒有——您對此毫無控制權。

當人們說「模型將會吸收越來越多的 harness 功能」時，他們指的正是這一點。他們的意思是，這些與記憶相關的部分將會被移到模型供應商提供的 API 後方。

💡這非常令人擔憂——這意味著記憶將被鎖定在單一平台、單一模型中。

模型供應商非常有動力這麼做，而且他們已經開始行動了。Anthropic 推出了 Claude Managed Agents。這將所有東西都放在 API 後方，鎖定在他們的平台上。

即使整個 harness 沒有完全放在 API 後方，模型供應商也有動力將越來越多的功能移到 API 後方——而且他們已經在這麼做了。例如：儘管 Codex 是開源的，但它會產生一個加密的壓縮摘要（在 OpenAI 生態系統之外無法使用）。

他們為什麼要這樣做？因為記憶很重要，它創造了僅靠模型本身無法實現的鎖定效應。

記憶很重要，且它創造了鎖定效應

雖然記憶領域還很早期，但每個人都清楚它很重要。它讓 Agent 能夠隨著使用者的互動而變得更好，並讓您建立資料飛輪（data flywheel）。它讓您的 Agent 能夠針對每位使用者進行個人化，並建立符合他們需求與使用模式的 Agent 體驗。

💡沒有記憶，您的 Agent 很容易被任何擁有相同工具的人複製。

有了記憶，您就建立了一個專有的資料集——一個包含使用者互動與偏好的資料集。這個專有的資料集讓您能夠提供差異化且日益智慧化的體驗。

迄今為止，切換模型供應商相對容易。它們擁有相似甚至相同的 API。當然，您必須稍微修改 Prompt，但這並不困難。

但這一切都是因為它們是無狀態（stateless）的。

一旦涉及任何狀態，切換就變得困難得多。因為記憶很重要。如果您切換了，您就會失去對它的存取權。

讓我講個故事。我在內部有一個電子郵件助理。它是建立在 Fleet 的模板之上，這是我們用於建構企業級 OpenClaws 的無程式碼平台。這個平台內建了記憶功能，因此在過去幾個月我與電子郵件助理互動的過程中，它累積了記憶。幾週前，我的 Agent 被意外刪除了。我氣炸了！我試圖從同一個模板建立一個 Agent——但體驗差太多了。我必須重新教它我所有的偏好、語氣，以及一切。

我的電子郵件助理被刪除的好處是——它讓我意識到記憶的力量與黏著性有多強。

開放記憶，開放 Harnesses

記憶需要被開放，並由開發 Agent 體驗的人所擁有。這讓您能夠建立自己真正掌控的專有資料集。

記憶（以及因此而來的 harnesses）應該與模型供應商分開。您應該希望擁有選擇權，去嘗試任何最適合您使用案例的模型。模型供應商則有動力透過記憶來創造鎖定效應。

這就是我們正在建構 Deep Agents 的原因。Deep Agents：

• 是開源的

• 與模型無關（model agnostic）

• 使用如 agents.md 和 skills 等開放標準

• 擁有連接到 Mongo、Postgres、Redis 等資料庫的 plugins，用於儲存記憶

• 可部署：(1) 透過 LangSmith Deployment（可自託管，可部署在任何雲端，可攜帶您自己的資料庫作為記憶儲存）；(2) 位於任何標準網頁託管框架後方

為了擁有您的記憶，您需要使用開放式的 Harness。

立即嘗試 Deep Agents。

感謝以下幾位人員的審閱與建議：

• Sydney Runkle，他在 Deep Agents 和記憶領域做了許多出色的工作

• Viv Trivedy，他是 Agent harnesses 領域的領先意見領袖

• Nuno Campos，他針對金融 Agent 的上下文工程（context engineering）撰寫了許多優秀的文章

• Sarah Wooders，她是 Letta 的 CTO，該公司一直處於有狀態 Agent 的最前線