LangChain 創辦人 Harrison Chase 上了 Training Data podcast 這集 Context Engineering Our Way to Long-Horizon Agents，聊了蠻多有料的觀點。所謂「Long Horizon Agent」就是能長時間自主運行、處理複雜多步驟任務的 AI Agent——不是問一句答一句，而是你丟一個任務給它，它自己規劃、自己呼叫工具、可能跑幾十甚至上百步才完成。這集從這類 Agent 為什麼現在才真正可用、Harness 跟 Framework 到底差在哪、到建 Agent 跟建軟體的本質差異，都有涵蓋。

以下是重點整理:

1. Long Horizon Agent 終於可以用了

Harrison 說 LLM 在迴圈中自主運行這件事，從 Auto-GPT 時代就是 Agent 的核心概念——當時就是因為「LLM 自己決定要做什麼」而爆紅。問題是那時模型不夠好，周圍的鷹架程式碼(scaffolding)也不夠好。

現在兩邊都進步了: 模型變強(尤其是 reasoning model)，加上大家摸索出一套有效的 harness 設計(壓縮、規劃、檔案系統工具)。而且這兩邊是共同演化的——Harrison 說如果回到兩年前，不會有人預測「檔案系統是 harness 的核心」，因為當時模型還沒有被大量訓練在檔案操作上。模型訓練的方向和 harness 的設計彼此推動，才走到今天這個狀態。

2. 殺手級應用: 都是「初稿」型任務

Harrison 提出一個很實用的判斷框架: 現在 Long Horizon Agent 最適合的場景，都是產出「初稿」的任務。Agent 還做不到 99.99% 的可靠度，但它能跑很久、做大量前期工作，人再來審查修改就好。

具體例子:

  • 寫程式: 產出 PR，不是直接 push 到正式環境(除非你在 vibe coding，這也越來越行了)
  • AI SRE: Traversal (Sequoia 投資) 做的事故調查 Agent，挖 log、跑分析、產出報告再交給人
  • 研究報告: 不管是金融研究還是 deep research，都是先出初稿再編輯。Harrison 說金融領域這塊需求超大
  • 客服升級: 像 Karn 做的是當第一線 AI 回覆搞不定、升級給真人的時候，背景跑一個 Long Horizon Agent 整理完整事件報告，交接給真人客服

如果你在評估某個場景適不適合用 Long Horizon Agent，可以問自己: 這個任務的產出可以是初稿嗎? 有人會審查嗎? 答案都是「是」的話，就很適合。

3. Harness vs Framework vs Model: 三層定義

這段定義講得蠻清楚的:

  • Model: LLM 本身，token 進 token 出
  • Framework (如 LangChain): 提供抽象層，方便切換模型、整合工具、向量資料庫、記憶等，但對「怎麼用」不太有主見
  • Harness (如 Deep Agents): 有主見的(opinionated)完整方案。內建規劃工具、壓縮策略、檔案系統存取，直接給你一套他們認為「對的做法」

編按: 這就是 Philipp Schmid 所說的「Agent 2.0」架構。他在 Agents 2.0: From Shallow Loops to Deep Agents 整理了四個支柱: 外部化的規劃(不只靠 chain-of-thought)、階層式委派(主 Agent + 子 Agent)、持久化記憶(檔案系統/資料庫)、以及極致的 context engineering(動輒上千 token 的詳細指令)，可以搭配著看。目前主流的 Harness 例子包括: Anthropic 的 Claude Code (及其底層的 Claude Agent SDK)、OpenAI 的 Codex、LangChain 的 Deep Agents、Manus，以及 Harrison 在對話中提到的 Factory 和 AMP 等 coding agent 公司，開源社群也有 OpenCode 等替代方案。

Harrison 還有一個觀察蠻值得注意: 以前需要靠客製化的認知架構(cognitive architecture)來彌補模型不足，現在模型夠強了，很多「任務專屬邏輯」從程式碼遷移到了自然語言的指令和工具裡。複雜度沒有消失，只是從 LangGraph 裡的程式碼搬到了 prompt 裡。Harness 的核心架構反而可以更通用、更固定。

他也預測: 長期來看，大多數公司不會自己建 harness，因為建 harness 其實比建 framework 更難。大家會用現成的 harness，然後在 prompt/instruction 和工具層做差異化。

編按: 這跟之前整理的不要再打造 Agent 了，打造 Skills 吧是同一個思路——Harness 用現成的就好，真正的差異化在於你為它打造的 Skills: 領域知識、專屬工具、特定工作流程的指令。

4. 什麼讓 Harness 跑得好?

Harrison 認為做最好 harness 的大多是 coding 公司。他點名了 Claude Code、Factory、AMP。幾個關鍵要素:

🔹 配合模型訓練的工具: Anthropic 訓練了專門的檔案編輯工具，OpenAI 則重度訓練 Bash。Harness 要順著模型的強項去設計，不能硬來。而且不只是跟特定模型綁定，是跟整個模型家族綁定——所有 Claude 模型有一套工具偏好，OpenAI 的又是另一套。

🔹 壓縮策略(Compaction): 長時間運行 context window 一定會滿，怎麼壓縮是大學問。Anthropic 有嘗試讓模型自己決定何時壓縮，但 Harrison 說目前還不太多人在用這個功能。

🔹 子 Agent 的協作設計: 主 Agent 踢出子 Agent 後，只拿回最終回覆。Harrison 分享了一個常見的失敗模式: 子 Agent 做完一堆工作後回覆「看看我上面做的東西」——但主 Agent 根本看不到上面的東西。這種細節需要靠 prompt 工程來處理。另外 Skills 和 MCP 目前還很新，模型還沒有被大量訓練在這些東西上。

🔹 Prompt 的品質: 這些 harness 裡的 system prompt 動輒好幾百行，品質差異直接反映在效能上。

有趣的是，Harrison 指出 Claude Code 在 Terminal Bench 2 排行榜上並不是第一名。排行榜把 harness 和模型分開列出，可以清楚看到同一個模型配不同 harness 的效能差異——這說明 harness 工程確實能帶來獨立於模型的效能增益，不是基座模型公司就一定做得最好。

5. Agent 開發的三個時代

Harrison 回顧了演化歷程:

第一代 — 文字進文字出: GPT-3 時代，模型連 chat 格式都沒有，沒有 tool calling，大家只能做單一 prompt 或簡單的 chain。

第二代 — 客製化認知架構: 模型開始支援 tool calling，但推理能力還不夠強。需要靠鷹架程式碼來引導: 「這裡你該做什麼?」走這個分支，遇到那個走那個分支。有迴圈了，但還是偏結構化的 scaffolding。

第三代 — LLM 在迴圈中跑 + Context Engineering: 2025 年中開始，Harrison 注意到 Claude Code、Deep Research、Manus 都用同一套核心架構——就是讓 LLM 跑在迴圈裡，差異化全在 context engineering 上: 子 Agent、Skills、壓縮策略等。這讓他們開始做 Deep Agents。

對更廣泛的開發者社群來說，轉折點可能更接近 2025 年底。Harrison 猜測可能跟 Opus 4/5 有關，也可能跟大家寒假回家密集用 Claude Code 有關。總之有一波明顯的 vibe shift——大家發現「丟個難題給 Agent，它真的能搞定」。

至於下一步會怎麼走? Harrison 說核心演算法已經到位了——就是 LLM 跑在迴圈裡，簡單到不行。未來的進展會在 context engineering 的各種技巧上: 壓縮可能會更多交給模型自己決定，記憶會拉進新型態的 context，模型本身也會持續進步。

6. 每個 Agent 都需要檔案系統(但不一定都是 Coding Agent)

這段討論蠻有意思的。主持人問: coding agent 是 Agent 的子類別，還是說所有 Agent 本質上都是 coding agent?

Harrison 的立場很鮮明: 他堅信不管做什麼類型的 Long Horizon Agent，都應該給它存取檔案系統的能力。原因很實際: 壓縮時可以把訊息寫進檔案、需要時再讀回來；大型 tool call 結果不用全塞進 context，放檔案系統讓 Agent 自己查就好。

但他區分了「真的檔案系統」和「虛擬檔案系統」(例如用 Postgres 實作的)。虛擬的可以做 context management，也更好擴展，但沒辦法跑程式。所以如果你需要 Agent 寫 script 來處理各種長尾任務，就需要真正的程式碼執行能力。

他的結論是: 通用 Agent 可能是一個 coding agent，但反過來不一定成立——今天的 coding agent 大多是針對寫程式高度優化的，不等於通用。「所有 Agent 是不是都是 coding agent?」是他現在最常在想的問題之一。

至於瀏覽器操作? Harrison 說模型目前在這塊還不夠好。也許可以透過給 coding agent 一個 CLI 來間接操作瀏覽器，但原生的 browser use 還沒到位。

7. 建 Agent 跟建軟體的根本差異

這段小編覺得講得特別好。Harrison 自己也說「大家都在講 building agents is different，但到底差在哪?」他想了很久，歸納出兩個核心差異:

差異一: 邏輯不全在程式碼裡

傳統軟體的邏輯 100% 在程式碼中，你看 code 就知道它會做什麼。Agent 不一樣——很大一部分邏輯來自模型這個非確定性的黑盒子。你沒辦法光看 code 就預測 Agent 在特定情境下的行為，你必須實際跑它。

這直接導致 Trace 變成 Agent 開發的核心工件。Harrison 說在傳統軟體裡，trace 是出問題才看的東西，本機開發你打個中斷點就好了。但在 Agent 開發中，大家從第一天就盯著 trace 看，因為那是唯一能告訴你「Agent 每一步到底在幹嘛」的地方。

為什麼在 Agent 裡比在單一 LLM 應用中更重要? 因為單一 LLM 應用裡，你的 prompt 是什麼、context 是什麼，都是程式碼決定的，你看得到。但 Agent 跑到第 14 步的時候，context 裡有什麼完全取決於前面 13 步拉進了什麼東西——你事先無法預測。

所以 Harrison 說: 「一切都是 context engineering，而 trace 就是讓你看清楚 context 裡到底有什麼——這太重要了。」

更進一步，Trace 正在成為團隊協作的核心。以前出問題大家說「來看 GitHub 上的 code」，現在變成「來看 LangSmith 的 trace」。他們的開源社群也是——有人反映 Deep Agents 出問題，團隊的回覆是「把 LangSmith trace 給我們看」，不再是以前的「把 code 給我看」。軟體的真相來源在程式碼裡，Agent 的真相來源在 trace 裡。

差異二: 迭代的性質不同

軟體也要迭代沒錯，但軟體出貨前你知道它會做什麼，迭代是基於「使用者到底想要什麼功能」。Agent 不一樣——你出貨前不完全知道它會做什麼。所以 Agent 需要更多迭代才能讓行為正確，而且開發者要改的不是 code，是 system prompt，改的頻率遠高於傳統軟體改 code 的頻率。

Harrison 說這也連帶引出了線上測試的重要性: Agent 的行為要到面對真實輸入時才會浮現，所以線上測試(production 環境的監控和評估)比離線測試更重要。你可以從 trace 裡建構測試案例，但最有效的還是觀察 Agent 在真實世界中的表現。

8. Eval: 判斷、校準、自我修正

評估 Agent 跟測試軟體很不一樣。軟體可以靠程式化的斷言(assertion)，但 Agent 做的很多事原本是人在做的，需要人類判斷力來評估好壞。

LangSmith 的做法分兩層:

  • 真人標註: 人看 trace、給分數、寫自然語言回饋，甚至標出正確的步驟應該長什麼樣。LangSmith 有個 annotation queue 的概念把人拉進來
  • LLM-as-judge: 用 LLM 當人類判斷的近似值。但關鍵是要跟真人判斷做校準——LangSmith 有個叫「Align Evals」的功能，讓真人先標一批 trace，再用這些資料校準 LLM 評分器。如果沒校準好，你的評分器就是爛的

Harrison 提出一個蠻有啟發的觀點: LLM-as-judge 其實不只用在 eval 裡。Coding agent 跑到一半撞到錯誤、自我修正——這是在 judge 自己的上一步。Memory 系統回顧 trace 然後更新指令——也是 judge。所以「自我判斷 → 修正 → 改善」這個模式貫穿了 eval、錯誤修正、記憶，本質上是同一件事。

他還分享了一個讓人印象深刻的 pattern: 他們做了 LangSmith MCP 和 CLI 工具，讓 coding agent 可以直接拉下 trace、診斷問題、修改程式碼。等於 Agent 在用 trace 改善自己的 harness。Harrison 說他對這個方向比 RL 更興奮，至少對建 Agent 應用的公司來說，這條路更實際。當然，改完的東西人還是會審查——又回到 first draft 的概念。

9. Memory: Agent 的護城河

Harrison 對 memory 很有感觸，他講了一個很生動的故事: 他有個跑了兩年的 email agent，累積了大量記憶。當他想把它搬到 Agent Builder 新平台時，即使 prompt 和工具一模一樣，少了那些記憶，用起來就是明顯比較差。他到現在都還沒完全切過去——因為新版本明顯比較笨。

這說明 memory 可以是真正的護城河。而且 memory 本質上也是 context engineering——只是時間跨度更長，跨越了單次對話的範圍。

Agent Builder 目前的做法是: 你跟 Agent 互動時說「你不該做 X，應該做 Y」，Agent 會去改自己的 instruction 檔案。下一步他們想做「睡眠時運算」(sleep time compute，這個詞來自 Letta): Agent 每天晚上自動回顧當天所有 trace，更新自己的指令。

Memory 還能解決前面提到的「Agent 迭代負擔」問題。因為開發者要一直調 system prompt 才能讓 Agent 行為正確，如果系統能從互動中自己學，就能大幅減少開發者的調校工作。

不過 Harrison 也務實地說，memory 不是萬靈丹。ChatGPT 的 memory 功能他就沒什麼感覺，因為他跟 ChatGPT 的互動太雜太隨機，什麼都聊。Memory 在「特定領域、重複性高」的場景才真正有價值——像他那個專門做 email 的 Agent 就是典型案例。

10. Agent UI 的未來: 非同步 + 同步的切換

Long Horizon Agent 跑很久，你不可能一直盯著看。Harrison 認為未來 UI 需要支援兩種模式的自然切換:

  • 非同步模式: 同時踢出好幾個 Agent，用類似 Linear/Jira 看板甚至 email 的方式管理
  • 同步模式: Agent 有產出了，你切到 chat 介面即時互動、給回饋

他們做的 Agent Inbox 就是這個概念的實踐。但第一版只有非同步模式——Agent 丟東西回來，你回一句，然後就只能等下次通知。用起來很卡，因為你常常只想快速回幾句就好，不想退出去等。加了同步 chat 之後才真正好用。Harrison 說純非同步模式也許未來 Agent 夠強了會可行，但現在人還是需要經常介入修正，兩種模式的切換是必要的。

另一個重點是 Agent 操作的「狀態」要看得到。很多 Agent 現在會修改檔案系統裡的東西，光看 chat 對話不夠，你需要能看到它改了什麼。就像用 Claude Code 跑完之後，Harrison 自己也會打開 IDE 看它寫的程式碼。

Anthropic 的 Claude Co-Work 有個不錯的設計: 設定 Agent 時要選一個工作目錄，框定「這是你的 workspace」。這個 workspace 概念可以推廣——可以是檔案目錄、Google Drive、Notion 頁面，總之是你和 Agent 共同協作的狀態空間。

11. 既有軟體公司能不能轉型?

主持人拿了一個類比來問: 當年從本地部署(on-prem)轉到雲端，很少公司成功轉型，因為建雲端軟體跟建本地軟體真的很不一樣。現在從傳統軟體轉到 Agent 時代，會一樣嗎?

Harrison 的看法分兩面:

公司層面 — 資料是關鍵優勢。既有公司手上有資料和 API，如果之前設計得當，要接上 Agent 的工具層其實不難。金融領域的人說「資料的價值一直在漲」。但資料只是工具層——另一半是「怎麼用這些資料做判斷、執行任務」，這以前是人在做的，現在要變成 Agent 的 instruction，需要領域知識。像 Rogo 這種金融領域的垂直新創，就是靠領域知識在 Agent 上建立優勢。Harrison 指出 Agent 的效能很大程度上是被知識驅動的——不是通用知識，而是「怎麼執行特定工作流程」的知識。

人才層面 — 偏年輕，但不絕對。Harrison 觀察到 Agent 工程團隊確實偏年輕、偏資淺，因為沒有太多既有包袱反而更容易上手。不過他也提到很多資深工程師在用 agentic coding，所以比較像是心態問題而非年齡問題。

整場對話中，Harrison 反覆強調的核心信念是: Agent 的核心演算法其實極其簡單——就是 LLM 跑在迴圈裡。我們終於到了模型夠強、可以讓這個簡單架構真正運作的時刻。而所有的差異化，都在 context engineering 上——壓縮、規劃、記憶、檔案系統、子 Agent、工具設計。他自己說得最到位: 「Context engineering 這個詞真的很好，它精準描述了我們在 LangChain 一直在做的事——只是當初我們還不知道該叫它什麼。」