一個被低估的AI Agent核心競爭力

所有人都在追逐更強大的模型，但幾乎沒人談論腳手架。這是我最近觀察到的一個奇怪現象。每當有新模型發布，科技圈就會沸騰，大家討論參數量、基準測試分數、上下文長度。但當我深入研究那些真正成功的 AI agent 產品時，我發現了一個被嚴重忽視的真相：決定 AI agent 性能的，不是你用哪個模型，而是你如何使用這個模型。同一個模型，在不同的系統架構下，性能可以相差一倍。Claude Opus 4.5 在一個腳手架下得分 42%，換另一個腳手架后得分 78%。這不是模型的問題，而是圍繞模型構建的系統的問題。

最近我讀到三位開發者——Himanshu、Viv 和 Tony Kipkemboi——分別從不同角度深入分析了 agent harness 這個概念。他們的觀點相互補充，讓我對 AI agent 的構建有了全新的理解。Himanshu 通過分析頂尖公司的實踐證明了 harness 比模型更重要；Viv 從第一性原理出發，解釋了為什么我們需要 harness 以及它應該包含什么；Tony 則清晰區分了 harness 和 framework 的概念，幫助我們理解它們各自的適用場景。這三個視角結合起來，構成了一幅關于 AI agent 構建的完整圖景。

Harness 到底是什么

在深入討論之前，我們需要先搞清楚 harness 這個概念。Tony Kipkemboi 曾在 CrewAI（一個 agent framework）工作，他對這個概念有很清晰的定義。他把 agent 開發比作一個光譜：最左邊是原始代碼，你直接調用 API，自己管理狀態，從零開始構建一切。中間是 agent framework（代理框架），給你提供結構和抽象，但你仍然需要做很多決定。最右邊是 agent harness（代理腳手架），這是最有觀點的方案，一切都已經內置好了。

Viv 則從更技術的角度給出了定義：Agent = Model + Harness。如果不是模型本身，那就是 harness。換句話說，harness 是所有不屬于模型的代碼、配置和執行邏輯。一個原始模型不是 agent，但當 harness 給它提供狀態、工具執行、反饋循環和可執行約束時，它就變成了 agent。我很認同這個定義，因為它迫使我們從系統的角度思考，而不僅僅是從模型的角度。

具體來說，harness 包括系統提示、工具和技能及其描述、捆綁的基礎設施（文件系統、沙盒、瀏覽器）、編排邏輯（子 agent 生成、交接、模型路由）、以及用于確定性執行的鉤子和中間件（壓縮、續傳、語法檢查）。這個列表乍看之下很技術化，但每一項都對應著 agent 在實際工作中會遇到的具體問題。

Framework vs Harness：關鍵區別

Tony 對 framework 和 harness 的區分讓我豁然開朗。Framework 給你提供構建 agent 的抽象。你定義角色、任務、工具。你指定 agent 如何協作，是順序工作還是層次化工作。Framework 處理管道工作——調用 LLM、路由工具輸出、管理執行循環。但你仍在做架構決策。

Framework 對構建塊的樣子有觀點，它有內存抽象、工具接口、任務結構。但這些部分是可交換的。如果你不喜歡默認的內存實現，可以插入自己的。如果想使用不同的 LLM 提供商，可以配置它。Framework 給你標準接口，但你仍在組裝系統。這種模塊化正是重點。Framework 是為想要構建 agent 的人設計的，不僅僅是使用它們。你需要理解各部分如何組合，因為你是決定使用哪些部分的人。

相比之下，harness 不給你構建塊，它給你一個完整的系統。Tony 舉的例子是 OpenClaw，幾周前在網上很火。這是一個 harness。你下載它，添加 API 密鑰，突然就有了一個可以在 WhatsApp、Telegram 和其他平臺上聊天的 agent。內存已處理。上下文管理已處理。Agent 循環已處理。工具調用、權限、狀態持久化，全都內置了。

你不是在配置內存系統，不是在決定工具如何注冊或 agent 如何從錯誤中恢復。這些決定已經由構建 harness 的人做出。你的工作是把它指向一個任務并讓它運行。這就是權衡：你得到了立即可用的東西，但不能改變它內部的工作方式。Harness 對一切都有觀點，使用它時你就是在接受這些觀點。

我的理解是，這個區別很像買家具和買宜家家具的區別。定制家具（framework）讓你選擇材料、尺寸、風格，但你需要花時間設計和等待制作。宜家家具（harness）已經設計好了，你買回家按說明書組裝就能用，但你不能改變它的基本設計。兩者都有價值，取決于你的需求和能力。

從模型的視角理解：為什么需要 Harness

Viv 的文章有一個很有意思的角度：從模型的視角出發，推導出我們為什么需要 harness。這種自底向上的思考方式讓我對 harness 的必要性有了更深的理解。

模型本身能做什么？它們接收文本、圖像、音頻、視頻等數據，輸出文本。就這樣。開箱即用，它們無法維持跨交互的持久狀態，無法執行代碼，無法訪問實時知識，無法設置環境和安裝包來完成工作。這些都是 harness 層面的功能。LLM 的結構決定了需要某種機制來包裝它們，才能做有用的工作。

舉個例子，要實現"聊天"這樣的產品體驗，我們需要把模型包裝在一個 while 循環中，跟蹤之前的消息并添加新的用戶消息。讀這篇文章的每個人都已經使用過這種 harness。關鍵思想是，我們想把期望的 agent 行為轉化為 harness 中的實際功能。這個觀點讓我意識到，harness 工程本質上是在彌合"模型能力"和"實際需求"之間的鴻溝。

Harness 的核心組件

基于 Viv 的分析，我總結了 harness 必須包含的幾個核心組件，以及每個組件存在的理由。

文件系統是最基礎的 harness 原語。我們希望 agent 有持久存儲來處理真實數據、卸載上下文窗口裝不下的信息、并在會話間持久化工作。模型只能直接操作上下文窗口內的知識。在有文件系統之前，用戶必須復制粘貼內容給模型，這體驗很糟糕，而且對自主 agent 不起作用。世界已經在使用文件系統工作，所以模型自然在數十億個 token 上訓練了如何使用它們。自然的解決方案是：harness 配備文件系統抽象和文件操作工具。

文件系統的重要性怎么強調都不為過。它讓 agent 有了工作空間來讀取數據、代碼和文檔。工作可以增量添加和卸載，而不是把所有東西都放在上下文中。Agent 可以存儲中間輸出并維護超越單個會話的狀態。文件系統還是自然的協作界面，多個 agent 和人類可以通過共享文件協調。Git 為文件系統添加版本控制，這樣 agent 可以跟蹤工作、回滾錯誤、分支實驗。

Bash 和代碼執行則是通用工具。我們希望 agent 自主解決問題，而不需要人類預先設計每個工具。今天主流的 agent 執行模式是 ReAct 循環，模型推理、通過工具調用采取行動、觀察結果、在 while 循環中重復。但 harness 只能執行它有邏輯的工具。與其強迫用戶為每個可能的動作構建工具，更好的解決方案是給 agent 一個通用工具，比如 bash。

Bash 加代碼執行是朝著"給模型一臺計算機，讓它自己搞定其余部分"邁出的一大步。模型可以通過代碼即時設計自己的工具，而不是被限制在固定的預配置工具集中。Harness 仍然配備其他工具，但代碼執行已經成為自主問題解決的默認通用策略。我認為這是一個重要的設計哲學轉變：從"提供足夠的工具"轉向"提供創建工具的能力"。

沙盒和執行環境也必不可少。Agent 需要一個有正確默認設置的環境，這樣它們可以安全行動、觀察結果并取得進展。我們已經給了模型存儲和執行代碼的能力，但這一切都需要在某個地方發生。在本地運行 agent 生成的代碼有風險，而且單個本地環境無法擴展到大量 agent 工作負載。

沙盒給 agent 提供安全的操作環境。Harness 可以連接到沙盒來運行代碼、檢查文件、安裝依賴并完成任務，而不是在本地執行。這創造了代碼的安全隔離執行。為了更高安全性，harness 可以白名單命令并強制網絡隔離。沙盒還能實現規模化，因為環境可以按需創建、分散到多個任務，工作完成后銷毀。

好的環境配備好的默認工具。Harness 負責配置工具，這樣 agent 可以做有用的工作。這包括預安裝語言運行時和包、用于 git 和測試的 CLI、用于網頁交互和驗證的瀏覽器。瀏覽器、日志、截圖和測試運行器等工具給 agent 提供了觀察和分析工作的方法。這幫助它們創建自我驗證循環，在那里它們可以編寫應用代碼、運行測試、檢查日志并修復錯誤。

內存和搜索用于持續學習。Agent 應該記住它們見過的東西，并訪問訓練時不存在的信息。模型除了權重和當前上下文中的內容外，沒有額外知識。在無法編輯模型權重的情況下，"添加知識"的唯一方法是通過上下文注入。

對于內存，文件系統再次成為核心原語。Harness 支持像 AGENTS.md 這樣的內存文件標準，在 agent 啟動時注入上下文。隨著 agent 添加和編輯此文件，harness 將更新后的文件加載到上下文中。這是一種持續學習形式，agent 從一個會話持久存儲知識，并將該知識注入未來會話。

知識截止日期意味著模型無法直接訪問新數據，比如更新的庫版本，除非用戶直接提供。對于最新知識，Web Search 和像 Context7 這樣的 MCP 工具幫助 agent 訪問超出知識截止日期的信息，比如新庫版本或訓練停止時不存在的當前數據。

對抗上下文腐爛也是關鍵挑戰。Agent 性能不應該在工作過程中降低。上下文腐爛描述的是模型在上下文窗口填滿時推理和完成任務的能力變差的現象。上下文是寶貴而稀缺的資源，所以 harness 需要策略來管理它。今天的 harness 在很大程度上是良好上下文工程的交付機制。

壓縮解決的是當上下文窗口接近填滿時該怎么辦。沒有壓縮，當對話超過上下文窗口會發生什么？一個選項是 API 報錯，這不好。Harness 必須為這種情況使用某種策略。所以壓縮智能地卸載和總結現有上下文窗口，這樣 agent 可以繼續工作。

工具調用卸載幫助減少大型工具輸出的影響，這些輸出可能會嘈雜地堆滿上下文窗口而不提供有用信息。Harness 保留超過閾值 token 數的工具輸出的頭部和尾部 token，并將完整輸出卸載到文件系統，這樣模型可以在需要時訪問它。

數據說話：為什么 Harness 比模型更重要

說到這里，我想回到 Himanshu 提供的那些令人震撼的數據。這些數字最有說服力地證明了 harness 的重要性。

CORE-Bench 的測試結果非常直接。Claude Opus 4.5 在一個腳手架下得分 42%，換另一個腳手架后得分 78%。同樣的模型，性能幾乎翻倍。Sonnet 4 的表現是 33% vs 47%。Sonnet 4.5 是 44% vs 62%。這不是小幅改進，這是質的飛躍。唯一的變量是 harness，模型完全相同，基準測試完全相同。

Cursor 的懶工具加載將 token 使用量削減了 46.9%。這是一個具有統計顯著性的數字。同樣的任務，同樣的模型，只是改變了工具的加載方式，就能節省近一半的 token。考慮到 token 成本和處理速度，這種優化的商業價值是巨大的。

更極端的案例來自 Vercel。他們刪除了 agent 80% 的工具，結果 agent 從失敗任務變成了完成任務。這個案例特別有意思，因為它挑戰了我們的直覺。我們通常認為給 agent 更多工具會讓它更強大，但事實證明，工具太多反而會降低性能。Token 從 145463 降到 67483，步驟從 100 降到 19，延遲從 724 秒降到 141 秒。這是全方位的改進，而改變的只是 harness 設計。

LangChain 的 deepagents-cli 在 TerminalBench 2.0 上的表現也很說明問題。僅通過改變 harness，分數從 52.8% 提升到 66.5%，提高了 13.7 個百分點。我反復強調這一點：模型完全沒變，只是改變了圍繞模型的腳手架。

這些數據讓我重新思考了 AI 行業的投資方向。我們看到無數公司花費數百萬甚至數十億美元訓練更大更強的模型，但可能只需要花一小部分精力優化 harness，就能獲得同等甚至更好的性能提升。這不是說模型不重要，而是說我們嚴重低估了 harness 的價值。

頂尖公司的 Harness 實踐

Himanshu 詳細分析了幾家頂尖公司的 harness 實現，每家都有獨特的設計哲學。

Claude Code 采用"模型控制循環"的理念。它是一個簡單的 while(tool_call) 循環，沒有復雜的 DAG 編排，沒有競爭的 agent 角色。模型接收消息和工具，返回文本結束循環，返回工具調用繼續循環。Anthropic 明確稱之為"模型控制循環"而不是"代碼控制模型"。這個微妙的措辭差異體現了設計哲學：給模型更大的自主權。

Claude Code 只提供約 18 個原始工具，分四類：命令行發現、文件交互、網頁訪問和編排。設計哲學是原始工具優于集成。更有意思的是，Anthropic 選擇正則表達式（ripgrep）而不是向量數據庫進行代碼搜索，理由是 Claude 的代碼理解能力足夠強，可以構建復雜正則表達式而不需要搜索索引。

Claude Code 還有一個巧妙設計：TodoWrite 工具。從功能上講它什么都不做，純粹是 harness 層面的技巧——一個無操作工具，強制 agent 明確表達和跟蹤計劃，讓它在長時間運行中保持正軌。這種設計讓我想到，有時候最有效的工具不是執行復雜操作的，而是幫助 agent 保持清晰思路的簡單機制。

Cursor 的核心決策是"文件作為基本原語"。為什么？因為文件支持強大搜索、可自然分組、可版本化。他們針對每個前沿模型專門調優 harness。不同模型得到不同工具名稱、提示指令和行為指導。這種精細化調優讓我意識到，通用方案往往不是最優方案。

Cursor 的自定義語義搜索特別值得一提。他們的嵌入模型使用 agent 會話軌跡作為訓練數據。當 agent 完成任務時，Cursor 分析哪些文件本應更早被檢索，然后訓練嵌入模型匹配這些模式。結果是搜索準確率平均提高 12.5%，在大型代碼庫上的代碼保留率提高 2.6%。這種從實際使用中學習的方法比任何理論優化都更有效。

Manus 則走了另一個極端，從推出以來已經重寫了五次框架。他們最獨特的做法是使用 logit masking 而不是動態移除工具。任何對上下文前端工具定義的更改都會使所有后續 token 的 KV-cache 失效。所以所有約 29 個工具永久加載，每步可用性通過約束輸出 token 概率控制。

Manus 團隊得出的最大教訓是：最大性能提升來自刪除東西。復雜工具定義被 shell 執行替代，"管理 agent"被簡單交接替代。如果你的 agent harness 在模型變好的同時變復雜，那就出問題了。這個觀點讓我深有感觸，真正的進步往往來自簡化和精簡。

Progressive Disclosure：關鍵但被忽視的模式

Himanshu 特別強調了 progressive disclosure（漸進式披露）這個概念，我認為這是整個 harness 設計中最被低估的模式。

Progressive disclosure 借鑒自 UI/UX 設計，1980 年代起源于 IBM Research 的 John Carroll，1990 年代由 Jakob Nielsen 推廣。核心原則：只顯示現在需要的內容，按需揭示復雜性。這直接映射到 agent 設計。就像可折疊菜單減少人類認知負荷，分層上下文加載減少 LLM 注意力分散。

數據非常有說服力。Claude-Mem 文檔顯示，靜態加載注入 25000 個 token，效率只有 0.8%。Progressive disclosure 只需 955 個 token，效率 100%。這是約 26 倍改進。Cursor 的懶加載實現 46.9% token 削減。Vercel 刪除 80% 工具后，token 從 145463 降到 67483，步驟從 100 降到 19，延遲從 724 秒降到 141 秒，agent 從失敗變成功。

各家公司實現方式不同但思路一致。Claude Code 的 SKILL.md 模式：技能存儲為 .claude/skills/ 文件，不預加載到每次對話。與每次加載的 CLAUDE.md 不同，技能只在 Claude 檢測到相關性時加載。當項目有幾十個技能時，這防止上下文膨脹。

為什么 progressive disclosure 如此重要？Liu 等人在 TACL 2024 的論文證明，LLM 性能遵循 U 型曲線——相關信息在輸入開頭或結尾時性能最高，在中間時下降。即使長上下文模型也是如此。這就是為什么 harness 重要：progressive disclosure 保持輸入較小，并將新檢索信息放在末尾。

我的理解是，這從根本上挑戰了"給模型更多上下文總是更好"的假設。上下文組織方式比數量更重要。這也解釋了為什么同一模型在不同 harness 下性能差異如此巨大。

Framework 與 Harness 的模糊邊界

Tony 指出，framework 和 harness 的界限并不總是清晰的，而且我認為它也不應該清晰。

一些 framework 正在添加類似 harness 的功能。LangChain 是個好例子。他們發布了 Deep Agents，明確稱之為"agent harness"，位于框架之上。它配備內置規劃工具、用于上下文管理的文件系統訪問、子 agent 生成和內存持久化。你仍在底層使用 LangChain，但 Deep Agents 給你開箱即用的默認設置，這樣你不必自己把所有東西連接起來。

LangChain 實際上在自己的技術棧中區分了三層。LangChain（原始庫）是 framework。LangGraph 是他們稱為"agent runtime"（代理運行時）的東西，處理執行、狀態管理和持久性。Deep Agents 是位于兩者之上的 harness。這是一家公司跨越整個光譜。用于組合 agent 的 framework，用于可靠執行的 runtime，用于開箱即用的 harness。

這是一家 framework 公司向光譜右側移動。Deep Agents 仍然是模塊化的。你可以交換后端、配置工具、調整提示。但它給你一個工作系統，不需要你組裝每一塊。

另一方面，harness 也沒有聽起來那么鎖定。拿 OpenClaw 來說，開箱即用時最有觀點，但如果你下載源代碼，可以交換實現。你可以改變內存工作方式、調整 agent 循環、修改工具處理。只是大多數人不會這樣做，因為默認已經工作了。

區別在于開始時已經決定了什么。Harness 配備內置決策。Framework 暴露選項。如果使用 harness，你接受大多數決策并在邊緣配置。如果使用 framework，你自己做決策并組裝系統。

長時程自主執行的挑戰

Viv 特別強調了長時程自主執行的重要性和挑戰。自主軟件創建是編碼 agent 的圣杯，但今天的模型存在早期停止、復雜問題分解困難、以及工作跨越多個上下文窗口時的不連貫問題。好的 harness 必須圍繞所有這些設計。

這正是早期 harness 原語開始復合的地方。長時程工作需要持久狀態、規劃、觀察和驗證，以在多個上下文窗口間持續工作。文件系統和 git 用于跨會話跟蹤工作。Agent 在長任務中產生數百萬 token，文件系統持久捕獲工作以隨時間跟蹤進展。添加 git 允許新 agent 快速了解最新工作和項目歷史。對于多個 agent 協作，文件系統也充當共享工作賬本。

Ralph Loop 是一個有意思的 harness 模式，用于繼續工作。它通過鉤子攔截模型的退出嘗試，在干凈的上下文窗口中重新注入原始提示，強制 agent 針對完成目標繼續工作。文件系統使這成為可能，因為每次迭代從新上下文開始但從上一次迭代讀取狀態。

規劃和自我驗證讓 agent 保持正軌。規劃是模型將目標分解為一系列步驟。Harness 通過良好提示和注入如何使用文件系統中計劃文件的提醒來支持這一點。完成每一步后，agent 從通過自我驗證檢查工作正確性中受益。Harness 中的鉤子可以運行預定義測試套件，在失敗時循環回模型并帶上錯誤消息，或者可以提示模型獨立自我評估代碼。驗證將解決方案建立在測試上，并為自我改進創建反饋信號。

Harness 的未來

三位作者都對 harness 的未來有自己的看法，我覺得他們的觀點很有啟發性。

Himanshu 注意到模型訓練和 harness 設計的耦合。今天的 agent 產品如 Claude Code 和 Codex 在模型后訓練時將 harness 納入循環。這幫助模型在 harness 設計者認為它們應該原生擅長的動作上改進，如文件系統操作、bash 執行、規劃或與子 agent 并行工作。

這創造了一個反饋循環。有用的原語被發現、添加到 harness，然后在訓練下一代模型時使用。隨著這個循環重復，模型在訓練時所在的 harness 中變得更有能力。但這種共同演化對泛化有有趣的副作用。它以改變工具邏輯導致模型性能下降的方式表現出來。一個真正智能的模型應該不難在補丁方法間切換，但在循環中訓練會創造這種過擬合。

但這并不意味著對你任務最好的 harness 就是模型后訓練時用的那個。Terminal Bench 2.0 排行榜是個好例子。Opus 4.6 在 Claude Code 中的得分遠低于在其他 harness 中的 Opus 4.6。通過只改變 harness 可以榨取很多價值。

Viv 認為隨著模型變得更有能力，今天存在于 harness 中的一些東西會被吸收到模型中。模型會在規劃、自我驗證和長時程連貫性上原生變好，因此需要更少的上下文注入。這表明 harness 隨時間會變得不那么重要。但就像提示工程今天繼續有價值一樣，harness 工程可能會繼續對構建好的 agent 有用。

Harness 今天確實在修補模型缺陷，但它們也圍繞模型智能構建系統以使其更有效。配置良好的環境、正確的工具、持久狀態和驗證循環讓任何模型更高效，無論其基礎智能如何。

Viv 提到 harness 工程是 LangChain 用來改進其 harness 構建庫 deepagents 的一個非常活躍的研究領域。一些開放和有趣的問題包括：編排數百個 agent 在共享代碼庫上并行工作；分析自己軌跡以識別和修復 harness 級別失敗模式的 agent；根據給定任務即時動態組裝正確工具和上下文而不是預配置的 harness。

我對 Harness 未來的思考

讀完這三位作者的分析后,我有一些自己的深度思考。

我認為 harness 工程正在成為一門獨立的學科。就像軟件工程從計算機科學中分離出來,成為一個有自己方法論、最佳實踐和工具鏈的領域一樣,harness 工程也在經歷類似的過程。我們已經看到了一些早期信號:專門的 harness 構建庫(如 LangChain 的 Deep Agents)、harness 設計模式的總結(如 12 Factor Agents)、以及用于評估 harness 質量的基準測試(如 CORE-Bench、Terminal Bench)。

這種專業化很重要,因為它降低了構建高質量 AI agent 的門檻。當 harness 工程成為一門成熟的學科時,開發者不需要從零開始摸索,可以借鑒已驗證的模式和最佳實踐。這會加速整個行業的創新速度。

我也注意到一個有趣的悖論:雖然模型在變得更強大,但對 harness 的需求不會消失,只是會轉變形式。早期的 harness 主要是在彌補模型的不足,比如給模型添加文件系統訪問、代碼執行能力等基礎功能。但隨著這些能力逐漸被模型原生支持,harness 的角色會從"能力補充"轉向"性能優化"和"可靠性保證"。

就像現代編程語言已經有了垃圾回收、類型系統等高級特性,但我們仍然需要框架和庫來構建復雜應用一樣,未來即使模型本身變得非常強大,我們仍然需要 harness 來優化性能、管理復雜性、確保可靠性。Progressive disclosure、上下文管理、錯誤恢復這些問題不會因為模型變強而消失。

從商業角度看,我認為 harness 工程能力將成為 AI 公司的核心競爭力之一。模型本身正在快速商品化,任何公司都可以通過 API 訪問最先進的模型。但如何有效利用這些模型、如何設計出讓模型發揮最大效能的系統,這才是真正的護城河。這就像云計算時代,底層基礎設施(AWS、Azure、GCP)是商品,但在這些基礎設施上構建的應用和平臺才是真正的價值所在。

我還思考了 harness 設計的一個哲學問題:應該給模型多大的自主權?Claude Code 的"模型控制循環"代表了一個極端,給模型最大的自由度。而更傳統的方法則傾向于用代碼嚴格控制 agent 的每一步。我認為最佳平衡點會隨著模型能力的提升而移動。當模型還比較弱時,需要更多的 harness 級別控制和約束。但隨著模型變強,給它們更多自主權會帶來更好的結果。這個平衡點的把握,需要深刻理解模型的能力邊界和任務的復雜度。

Tony 提出的"你解決什么問題決定你需要 framework 還是 harness"這個觀點讓我想到,也許我們需要一個更細粒度的分類。在 framework 和 harness 之間,可能還有很多中間狀態。比如"可配置的 harness"、"模塊化的 harness"、"領域特定的 harness"等等。未來可能會出現更多這樣的中間形態,讓開發者可以根據具體需求選擇合適的抽象層次。

最后,我想強調 Himanshu 提到的一個關鍵洞察:最好的團隊一直在簡化。Manus 五次重寫,每次都刪除東西。Anthropic 設計 Claude Code 是為了隨模型改進而縮小。這個趨勢告訴我們,harness 工程的終極目標不是構建一個功能齊全、無所不包的系統,而是找到最小必要集——那些真正不可或缺、無法被模型原生能力替代的部分。這需要持續的迭代、測試和勇于刪除的決心。

Agent = Model + Harness。這個簡單的等式背后,是關于如何構建真正有用的 AI 系統的深刻洞察。模型提供智能,harness 讓智能有用。在追逐更強大模型的同時,我們不應該忽視 harness 工程的價值。因為最終,沒有人購買引擎,大家購買的是完整的汽車。

結尾

也歡迎大家留言討論，分享你的觀點！

覺得內容不錯的朋友能夠幫忙右下角點個贊，分享一下。您的每次分享，都是在激勵我不斷產出更好的內容。

歡迎關注深思圈，一起探索更大的世界。

- END -

兩個“特別坑”的AI產品創業方向，你知道嗎

速度將成為AI時代唯一的護城河

a16z重磅預測：Vibe coding贏者通吃？錯了，垂直專業化才是未來