獅山巡禮
投資雜談
https://mp.weixin.qq.com/s/KX-k9r5FOwz2Yu6NQOSD3g
Sequoia Capital 在2026: This is AGI這篇文章中斷言 AGI 就是把事情搞定（Figure things out）的能力。
如果說過去的 AI 是 Talkers 的時代，那麽 2026 年則是 Doers 的元年。轉變的核心載體正是 Long Horizon Agents（長程智能體）。這類 Agent 不再滿足於對上下文的即時回複，而是具備了自主規劃、長時間運行以及目標導向的專家級特征。從 Coding 到 Excel 自動化，原本在特定垂直領域爆發的 Agent 能力，正在向所有複雜任務流擴散。
作為LangChain的創始人，Harrison Chase 一直處於這場變革的最前沿。本文編譯了 Sequoia Capital Sonya Huang Pat Grady 訪談 Harrison Chase 的最新播客。作為站在 Agent 基礎設施最前沿的先行者，Harrison 揭示了為什麽 Agent 正迎來其爆發的第三個拐點。
核心 Insight 提煉：
Long Horizon Agents 價值在於為複雜任務提供高質量初稿；
Agent 的突破需要圍繞模型構建的、有主見的（Opinionated）軟件外殼（Harness），文件係統權限將成為所有 Agent 的標配；
通用 Agent 可能就是一個 Coding Agent；
Traces 成為新的 Source of Truth；
相比於通用模型，一個經過長時間磨合、內化了特定任務模式與背景記憶的 Agent，將形成極高的 moat；
理想的 Agent 交互是異步管理和同步協作的統一。
Long-Horizon Agents 的爆發
Sonya Huang：你怎麽看 Long Horizon Agents ？對於紅杉最新的文章，哪些觀點是你同意的，哪些你不同意？
Harrison Chase：我同意它們終於開始真正 work 了。讓LLM在一個循環中運行並自主決策，這一直是 Agent 的核心理念。AutoGPT就是這樣，它之所以能激發人們的想象力，是因為 LLM 在循環中能自主決定下一步做什麽。
問題在於，當時的模型不夠好，周圍的 Scaffolding 和 Harness 也不夠好。 現在模型變強了，我們在過去幾年也學到了什麽是好的 Harness，所以它們開始真正起作用了。我們最先在 Coding 領域看到這一點，這也是最快起飛的地方，並正在向其他領域擴散。
雖然你仍需給 Agent 下達指令、提供合適的工具，但它能運行的時間越來越長。所以 Long Horizon 這個說法非常貼切。
Sonya Huang：你最喜歡哪些 Long Horizon Agents 的例子？
Harrison Chase：Coding 領域的例子最多，我也用得最多。 除此之外，AI SREs 是個很好的例子。比如 Sequoia 投資的 Traversal，他們的 AI SRE 可以處理長時程任務，深入挖掘日誌。 Research 也是個很好的場景，因為它最終產出的是初稿。
Agent 的問題在於達不到 99.9% 的 Reliability ，但能做大量工作，並且能在更長的時間跨度上工作。需長時間運行，產出某項任務初稿的場景，就是 Long Horizon Agents 的殺手級應用。
Coding 是個典型。你通常提交一個 PR（Pull Request），而不是直接推送到生產環境，除非用戶在 Vibe Coding。這方麵變得越來越好。AI SREs 也是同理，通常是把結果提交給人審查。 生成報告也是，沒人會直接發給所有粉絲，總得自己先看一遍、改一改。
我們在金融領域已經看到了很多這類應用，這裏潛藏著巨大的機會。以前 Agent 隻做一線回複，現在有了像 Klarna 這樣的新案例，走的是人機協作路線。當一線 AI 搞不定要轉人工時，係統不會直接把爛攤子丟給人，而是有一個在後台運行的 Long Horizon Agent 生成一份前因後果的總結報告，再移交給人工。
所以，核心用例就是這些圍繞初稿概念的場景。
02.
從通用框架到 Harness 架構
Sonya Huang：關於 Why now，多大程度上是因為模型本身變得足夠強大，又有多少歸功於在 Harness 方麵做了巧妙的工程設計？深入探討前，簡單界定一下你眼中的 Harness 和模型的區別，以及 Agent 的具體構成。
Harrison Chase：好的，我得先引入 Framework 這個概念。早期我們就是這樣定義 LangChain 的，它本質上是 Agent Framework。但進入 Deep Agents 時代後，我更願意稱之為 Agent Harness。
常有人問這三者的區別：
模型：顯然就是 LLMs，輸入 Token，輸出 Token。
Framework：圍繞模型建立的抽象層，讓切換模型、添加工具、Vector Store 和 Memory 變得容易。它是 Unopinionated（無預設）的，價值在於抽象。
Harness：更像是開箱即用的。談到 Deep Agents 時，Harness 默認內置了 Planning tool，它非常 Opinionated（強預設），認為這就是做事的正確方式。
我們需要做壓縮。Long Horizon Agent 運行時間很長，雖然 Context Window 變大了，但終究有限。到某個時間點，必須對 Context 進行壓縮。問題是，怎麽壓？這方麵有很多前沿研究。我們提供給 Agent 的另一套關鍵能力是文件係統交互，無論是直接讀寫還是通過 Bash 腳本。
其實很難單純歸功於 Harness 或模型，因為現在的模型本身也是在大量此類數據（代碼、CLI）上訓練出來的。這是一種共同進化。若回到兩年前，我不認為我們能預知基於文件係統的 Harness 會是終極方案，因為那時的模型還沒針對這些場景充分訓練。
所以這是多因素疊加：模型確實變強了，特別是 Reasoning Models 功不可沒；但同時也因為我們搞清楚了圍繞壓縮、Planning 及文件係統工具的一係列 Primitives（原語）。是這兩者的結合帶來了突破。
Sonya Huang：記得在我們第一期播客裏，你把 LangGraph 形容為 Agent 的認知架構。這是否是理解 Harness 的正確方式？
Harrison Chase：沒錯。我們在 LangGraph 之上構建 Deep Agents。它是 LangGraph 的一個特定實例，但非常有主見，也更通用。
早期我們討論過通用 vs 專用架構。現在的趨勢是，以前那些為了約束模型而寫在 LangGraph 裏的特異性，正轉移到工具和 Instructions 中。複雜度沒有消失，隻是變成了自然語言。因此，Prompting、編輯 Prompt 甚至自動優化 Prompt 成了核心，而 Harness 本身的結構保持得相對固定。
Sonya Huang：Harness 層麵最難攻克的是什麽？你認為個別公司真的能在 Harness Engineering 上建立壁壘嗎？在這方麵你欣賞誰？
Harrison Chase：說實話，目前 Harness Engineering 做得最好的都是 Coding 公司。這是技術騰飛的領域。比如 Claude Code，它之所以如此火爆，很大一部分原因在於它的 Harness 設計。
Pat Grady：這是否意味著 Harness 更適合由基礎模型廠商自己構建，而不是第三方創業公司？
Harrison Chase：很難說。我想提到的另一家公司是 Factory，還有 Amp，它們都是 Coding 類公司，並且都有非常出色的 Harness。
這事各有利弊。Harness 某些部分確實與模型，或者說與模型家族，深度綁定。比如 Anthropic 的模型在某些特定工具上有過 Fine Tuning ，而 OpenAI 則在另一些工具上微調過。就像不同的模型需要與 Prompt 適配，現在 Harness 也是同理，針對不同模型家族需要微調。但共性依然存在，比如都基於文件係統。
這其實是個很有趣的現象。現在幾乎每個 AI Coding 公司都在造自己的 Harness。目前主流 Coding Benchmark，如 Terminal-Bench 2.0，會將經過 Harness 的 Agent 與模型分開列出。同一個模型的性能波動巨大，Claude Code 在榜單上也未必總是第一。這說明模型廠商未必天生更擅長此道。隻要深刻理解模型原理，第三方開發者完全能在 Harness 層麵挖掘出巨大性能提升。
Sonya Huang：你認為讓 Harness 高效運轉的關鍵是什麽？榜單頭部玩家做對了什麽？
Harrison Chase：首先是對模型訓練數據的深刻理解。OpenAI 的模型在 Bash 命令行上訓練得極多，而 Anthropic 似乎針對文件編輯工具做過專門訓練。順應模型的特性非常重要。
其次是壓縮。當任務周期變長、Context Window 滿載時，如何取舍是巨大的挑戰，也是 Harness 的核心價值。再者是 Skills、MCPs 和 Sub-agents 的運用。目前模型本身並未內化太多 Sub-agents 能力，主要靠 Harness 調度。比如在我們的 Harness 中，主模型調用 Sub-agent 時，需傳遞完整信息，並指示 Sub-Agent 何時輸出最終結果。
我們見過一些失敗案例：Sub-agent 做了一堆工作，最後隻回一句見上文，主模型沒有收到任何有效信息。協調組件工作的 Prompting 至關重要。看看現在的開源 Harness，System Prompt 動輒幾百行，就是為了解決協同問題。
Pat Grady：聊聊演變路徑。你一直處在讓模型落地現實世界的配套基建最前沿。
若簡化看過去五年的拐點，一是 Pre-training （ChatGPT）；二是 Reasoning （OpenAI o1）；最近伴隨 Claude Code 和 Opus 4.5 級別模型，迎來了 Long Horizon Agents 的第三個拐點。
在你構建的世界裏，拐點是否不同？從認知架構到 Framework 再到 Agent Harness，核心躍遷是什麽？
Harrison Chase：我認為可以分為三個時代：
第一階段是早期，即 LangChain 剛起步時。模型還是原始的 Text-in/Text-out，甚至沒有 Chat 模式，沒有 Tool Calling，沒有推理能力。大家能做的就是簡單的 Prompt 或鏈式調用。
第二階段是模型實驗室開始引入 Tool Calling，試圖讓模型學會思考和規劃。雖然當時的效果不如今天，但已經足以做決策了。這時自定義認知架構開始流行，你需要顯式地寫代碼問模型：現在該做什麽？，然後按分支走。這更像是在模型外麵搭 Scaffolding 。
第三階段的拐點，大概發生在 2025 年六七月份。Claude Code、Deep Research、Manus 集中爆發。底層架構其實一樣，把 LLM 放在循環裏運行。但它們巧妙地運用了 Context Engineering ，包括圍繞壓縮、Sub-Agent、Context Skills 的一切。核心算法沒變，但 Context Engineering 變了。這讓我們意識到這和以前不一樣了，於是我們開始做 Deep Agents。
對 Coding 社區來說，隨著 Opus 4.5 發布或大家寒假狂用 Claude Code，這種感覺尤為強烈。11、12 月發生了巨大的 Vibe Shift。大家意識到，把難題扔進去，Long Horizon Agent 真的能搞定。那一刻，模型足夠好了，我們從 Scaffolds 時代正式邁入 Harness 時代。
03.
Coding Agent 是通用 AI 的終局形態嗎
Pat Grady：接下來會怎麽發展？
Harrison Chase：我也想知道。但我確信，讓 LLM 在循環中運行並自我編排的算法，讓它自己決定把什麽拉入 Context 這一極簡且通用的 Agent 核心理念，終於實現了。
未來的手工 Scaffolds 會越來越少。目前像壓縮這類操作還很依賴 Harness 作者的手動設計。Anthropic 正嚐試讓模型自主決定何時壓縮，雖然還沒普及，但這可能是方向。
另一個重點是 Memory。在長時程任務中，Memory 其實就是長周期的 Context Engineering。核心算法很簡單：Run LLM in a loop。接下來的競爭點在於圍繞它的 Context Engineering 技巧，或是像 Anthropic 那樣把工程本身交給 LLM，又或是引入新型 Context 數據。
我現在最大的疑問是，目前成功的 Harness 大多針對 Coding。即使是非編程任務，你也可以辯稱寫代碼本身就是極好的通用手段。
Pat Grady：這正是我要問的。Coding Agents 到底是一個子類別，還是說所有 Agent 本質上都應該是 Coding Agents？因為 Agent 的工作就是讓計算機幹活，而代碼是最好的指令方式。
Harrison Chase：這是個大問題。我深信，構建 Long Horizon Agent 必須給它文件係統權限。
文件係統在 Context 管理上太有用了。比如壓縮時，把原始消息存進文件，隻留摘要在 Context 裏，模型需要時再去查閱；或者返回巨大的 Tool Call 結果時，不要全塞給模型。把它存進文件係統，讓它自己去查。其實這不一定需要真正的文件係統，也不需要它寫代碼。
我們有個虛擬文件係統的概念，底層由 Redis 等支持，穩定性更好。但顯然，代碼能做很多虛擬文件係統做不到的事。你沒法在虛擬文件係統裏運行代碼，這時候寫 Script 就非常有用了。
所有 Agent 是否最終都是 Coding Agent 也是我們目前思考的最多的問題之一。
04.
構建 Long Horizon Agent vs 構建軟件
Sonya Huang：構建 Long Horizon Agent 與構建傳統軟件有何不同？你在 X 上寫了一篇很很好的文章，能否總結並描述當今的數據與代碼開發棧？
Harrison Chase：這值得深思。大家都說構建 Agent 不同於構建軟件，但本質區別在哪？
幾點看似顯而易見，卻很重要：
構建軟件時，邏輯全寫在代碼裏，可見可控。構建 Agent 時，邏輯不全在代碼裏，很大一部分來自模型。這意味著你不能隻看代碼就推斷 Agent 在特定場景下的行為，必須實際運行。這就是最大區別。我們引入了非確定性黑盒係統，且它置於代碼之外。
這對開發者意味著，想知道 App 幹了什麽，看代碼沒用，必須看它在現實中的行為。這也是為何 LangSmith 的 Tracing 最受歡迎。Tracing 能複現 Agent 內部每一步。
這與傳統軟件的 Traces 不同。軟件通常隻在報錯時查日誌。但在 Agent 開發中，人們從第一天起就用 Trace。因為 Agent 循環運行，你根本不知道第 14 步的 Context 是什麽，因為前 13 步可能拉取了任意東西。這又回到了 Context Engineering。Trace 揭示了 Context 內容，這至關重要。
軟件的 Source of Truth（單一事實來源）是代碼；Agent 的 Source of Truth 是代碼 + Tracing。這意味著 Trace 成了你思考 Testing 的地方。你更需要 Online Testing，因為行為隻有在遇到真實世界輸入時才會湧現。
Trace 正成為團隊協作的支點。出問題時，大家不是說去 GitHub 看代碼，而是說看看 Trace。開源社區也是，用戶反饋 Deep Agents 跑偏，我們會要 LangSmith Trace 而非代碼。
還有一點，構建 Agent 更加 Iterative。 軟件是你設定好目標再迭代，發布前行為已知。 Agent 在發布前行為未知。你有個大概，但沒十足把握。為了讓它達標、通過概念上的 Unit Test，你需要更多迭代。
這也是為何 Memory 重要。Memory 是從交互中學習。如果係統能自我學習，就減少了開發者手動修改 System Prompt 的頻率。
Pat Grady：我也很好奇。現有軟件公司能活下來嗎？類比當年本地轉雲部署，鮮有成功者。你認為這次能跨越嗎？年輕創始人似乎更有白板優勢。
Harrison Chase：我們確實看到很多 Agent 團隊成員更 Junior，沒有思維定勢。
但在公司層麵，數據仍然非常有價值。 如果你想 Harness 包含什麽，就是 Prompt、Instructions 和工具。現有軟件公司擁有所有數據和 API。接入 Agent，價值巨大。但另一部分是，關於如何處理這些數據的 Instructions。這部分可能是全新的。以前這是人做的，你隻提供工具，沒嚐試自動化。
像 Rogo 這樣的垂直初創公司之所以有效，是因為很多 Agent 是由 Knowledge 驅動的。不是通用知識，而是關於如何執行 Specific Patterns 的知識。
所以，構建軟件的人是構建 Agent 的合適人選嗎？很多非常資深的開發者也采用了 Agentic Coding，所以人才上是心態問題，同時可能確實有年輕化偏差；但公司層麵，取決於數據。
05.
從人類判斷到 LLM-as-a-Judge
Sonya Huang：Trace 是 Agent 開發的核心產物。還有其他的嗎？特別是 Eval 方麵。
Harrison Chase：不算產物，應該叫組件。構建軟件和 Agent 的另一個本質區別在於 Eval。傳統軟件依賴程序化斷言，但 Agent 做的是人做的事，評判需引入 Human Judgment。這也是我們在 LangSmith 試圖解決的：如何把人類判斷帶入 Traces？
一種是直接引入人，比如 Data Labeling 公司，或者在 LangSmith 中也有 Annotation Queues。人直接去標注 Traces，比如給出自然語言反饋，包括這很好這很壞這裏應該這樣做等；有時人做的是糾正，把正確的步驟列出來。這取決於具體用例，模型公司做 RL 和應用公司構建 Agent 的需求可能不太一樣。
另一種是建立人類判斷的 Proxies，即LLM-as-a-Judge。 關鍵在於確保它與人類判斷對齊。如果不對齊，評分器就是垃圾。 LangSmith 有 Aligned Evals，即先讓人類標注一些 Trace，係統基於這些標注構建一個 LLM-as-a-Judge，進行針對性校準。LLM-as-a-Judge 包含了幾個不同層麵。 大多數人在 Evals 中用它來給 Trace 打分，比如 0 到 1 分，或者 0 到 10 分。這是通用的做法。因為有些判斷不需要 Ground Truth，做法有離線做也有在線。
但另一個被忽視的領域是，在 Coding Agents 本身就能看到這一點。 Coding Agent 工作過程遇到 Error，隨即糾正這個 Error。這實際是在評判自己之前的工作。 我們在 Memory 中也看到了，Memory 很大一部分就是反思 Trace 然後更新東西。
所以，無論是對自己的還是之前的會話，LLM 有充分的能力反思 Trace。我們在 Evals、自動糾錯、Memory 中都看到了這一點。本質上，它們是同一回事。
Sonya Huang：既然有了 Trace 和 Eval，這個 Eval 是 RL 的 Reward Signal？還是給工程師改進 Harness 的反饋？
Harrison Chase：其實是給 Agent 工程師改進 Harness 的。我們有 LangSmith MCP 和 LangSmith Fetch（一個 CLI 命令行工具）。這是大趨勢。Coding Agents 擅長用 CLI。把CLI 交給 Agent，它就可以拉取 Trace，診斷問題，自己修複代碼。這絕對是我們看好並支持的模式。對於應用類公司，我對這個模式比對 RL 更看好。
Sonya Huang：這聽起來像是真正的 Recursive Self-improvement。
Harrison Chase：是的，但仍有 Human-in-the-loop。如前所述，最理想的狀態是 Agent 產出初稿，如修改了 Prompt，然後人類進行審核，確保它不跑偏。
舉個例子，我們推出了構建 Agent 的無代碼工具， LangSmith Agent Builder。其有個很酷的功能是 Memory。 目前它的工作方式是：當你與 Agent 交互時，如果說你應該做 Y 而不是 X，它會修改它自己的 Instructions，即編輯文件。 這就是自我改進。我們正計劃增加每晚運行、查看當天 Trace 並更新自身狀態的功能，即 Sleep time compute。
06.
未來的交互與生產形態
Sonya Huang：未來呢？你談了很多 Memory。
Harrison Chase：我非常看好 Memory。讓 Agent 自我改進很酷，但並非全場景適用。ChatGPT 加了 Memory，但我沒怎麽用，也沒增加粘性，因為我去 ChatGPT 都是做 One-off 任務，如問代碼、問美食、問旅行，彼此之間沒關聯。
但在 Agent Builder 裏，你構建的是特定工作流。比如我的 Email Agent，之前積累了很多 Memory。後來我想遷移進 Agent Builder，結果丟了舊 Memory。哪怕 Prompt 和工具完全相同，新 Agent 體驗也遠不如舊的。如果不經長時間磨合，很難好用。
這就是為何我認為 Memory 是真正的 Moat。我們到了 LLM 可以查看 Traces 並修改代碼/指令的節點。問題在於如何安全、用戶可接受地落地。在垂直場景下這絕對是大勢所趨。
Sonya Huang：你認為 Long Horizon Agents 的 UI 會如何演變？
Harrison Chase：我認為需要 Sync mode（同步模式） 和 Async mode（異步模式）的結合。 Long Horizon Agent 運行時間長，默認應該是 Async 的。像 Linear、Jira 和 Kanban 看板這類工具，甚至包括 Email，對於構思如何管理這些 Agent 很有參考價值。
但對於大多數 Agent 來說，在某個節點，你一定會想切換到同步溝通模式。因為當 Agent 輸出一份研究報告，你需要針對其中的錯誤給出反饋。
唯一要補充的是，現在的 Agent 不隻是在說話，它們是在修改 State，比如文件係統裏的文件。你必須有辦法可視化這些 State，就像程序員離不開 IDE 裏看代碼。即便我用 Claude Code 跑完了任務，我依然會打開 IDE 去檢查它到底改了什麽。
Anthropic 的 Cowork 做了一個極好的範式。你設置一個目錄作為它的 Workspace。這建立了一種非常清晰的心理模型：我們在一個 Shared State（無論是本地文件、Google Drive 還是 Notion）上協作。
Hybrid Mode未來的交互形態就是這種Hybird Mode：你異步管理一堆後台運行的 Agent，但在關鍵時刻，你進入 Sync Mode 與它 Chat，同時你們都在盯著同一個 State 看。
Sonya Huang：這完全驗證了你之前的 Agent Inbox 理念，要實現 Sync Mode，Agent 必須有一個能隨時觸達到你的入口。
Harrison Chase：沒錯。一年前，我們發布了 Agent Inbox 第一版，當時的主打概念是 Ambient Agents。Agents 在後台運行，偶爾 Ping 你一下。
最初的版本沒有 Sync Mode，它 Ping 你，你回一句，然後隻能幹等它下次 Ping 你。這種體驗非常破碎。因為很多時候，比如回郵件，用戶需要的是極短時間的高頻交互，而非切出去幹等。
後來我們做了一個巨大的轉向。用戶點開 Inbox 時，會直接進入 Chat 界麵。Chat 本質上就是 Synchronous 的。我的判斷是：Pure Async（純異步）在目前是跑不通的。除非模型進化到完全不需要 Human-in-the-loop 糾錯的程度。否則我們注定要在 Async 和 Sync 之間來回切換。
Sonya Huang：你怎麽看 Code Sandboxes？每個 Agent 都要有沙箱、CLI 或 Browser 訪問權限嗎？
Harrison Chase：好問題。 目前 Code Execution 顯然比 Browser Use 更有用、更落地。
關於文件係統，我是堅定的 File System Pilled。我認為某種形式上，所有 Agent 都應該能訪問文件係統。
關於 Coding，我大概 90% 確信這是標配。對於 Long Tail 的複雜用例，Coding 能力是無可替代的。
關於 Browser Use， 目前的模型還不夠好。雖然有一些很酷的嚐試（比如給 Coding Agent 一個 CLI 來操作瀏覽器），但尚未成熟。
所以，Code Sandboxes 絕對是未來的核心組件。
