Windsurf 團(tuán)隊的聯(lián)合創(chuàng)始人 Anshul Ramachandran 最近發(fā)布了一篇關(guān)于 Agent 的科普文章，對于現(xiàn)下被廣泛討論，且經(jīng)常被誤用混淆的各種 Agent 概念進(jìn)行了辨析，同時對 Agent 系統(tǒng)的核心構(gòu)成進(jìn)行了拆解。如果你想要通過一篇全面地了解關(guān)于 Agent 的基礎(chǔ)情況，這是一篇相當(dāng)不錯的資料。

以下為《What is an Agent？》全文內(nèi)容，F(xiàn)ounder Park 進(jìn)行了編譯和適當(dāng)?shù)恼{(diào)整。

Founder Park 正在搭建開發(fā)者社群，邀請積極嘗試、測試新模型、新技術(shù)的開發(fā)者、創(chuàng)業(yè)者們加入，請掃碼詳細(xì)填寫你的產(chǎn)品/項目信息，通過審核后工作人員會拉你入群～

進(jìn)群之后，你有機(jī)會得到：

• 高濃度的主流模型（如 DeepSeek 等）開發(fā)交流；

• 資源對接，與 API、云廠商、模型廠商直接交流反饋的機(jī)會；

• 好用、有趣的產(chǎn)品/案例，F(xiàn)ounder Park 會主動做宣傳。

歡迎來到 2025 年，這一年 「Agent」 一詞的使用頻率極高，其含義也變得相當(dāng)寬泛。在日常交流中，人們基于各自的理解 confidenty 地使用這個詞，反而使其原本清晰的含義逐漸模糊。

如果你是一名開發(fā)者，正在構(gòu)建與 Agent 相關(guān)的解決方案，那么本文可能并不適合你。本文更適合以下幾類人群：

在會議、討論或日常對話中聽到他人提及 AI Agent 時心存疑惑的朋友，或許你對 Agent 的定義及其與現(xiàn)有生成式 AI 能力的差異不太確定；或許你懷疑使用這個詞的人是否真正了解 Agent 的含義；又或許你在讀到本文第一句話時，才開始質(zhì)疑自己此前對 Agent 的理解是否準(zhǔn)確。

（本文在解釋某些理論概念時會提及我們的產(chǎn)品 Windsurf，但并非進(jìn)行產(chǎn)品推介。)

01

Agent 核心概念解析：

「LLM+工具」的循環(huán)

回答本文標(biāo)題的問題，我們可以將 Agent 系統(tǒng)簡單理解為一個接收用戶輸入后，交替調(diào)用以下兩部分的系統(tǒng)：

• 一個 LLM（在這里我們稱其為「推理模型」）：依據(jù)輸入、可能自動檢索到的額外上下文以及累積的對話歷史，來決定下一步的行動。推理模型會輸出一段文字，解釋采取下一步行動的原因，以及結(jié)構(gòu)化的信息，具體指定行動的細(xì)節(jié)，例如調(diào)用哪個工具、工具所需的參數(shù)值等。這里的 「行動」 也可能表示沒有更多需要執(zhí)行的任務(wù)。

• 工具（Tools） ：用于執(zhí)行推理模型指定的各種行動并產(chǎn)生結(jié)果，這些結(jié)果將納入到信息流中，供推理模型在下一次調(diào)用時使用。需要注意的是，這些工具本身未必與 LLM 相關(guān)，推理模型的主要職責(zé)是從系統(tǒng)可用的工具和行動集合中進(jìn)行選擇。

由此構(gòu)成了一個基本的 Agent 循環(huán)，核心就是如此簡單。Agent 系統(tǒng)根據(jù)該循環(huán)呈現(xiàn)給用戶的方式不同，會表現(xiàn)出多種形式，后續(xù)將詳細(xì)探討。但若你能理解這一概念，即 LLM 在此并非僅作為純粹的內(nèi)容生成器，而是更像一個負(fù)責(zé)選擇工具的 「推理」 組件，那么你就已基本掌握了 Agent 的要義。

「推理（Reasoning）」 一詞在 Agent 領(lǐng)域有著特定的含義，它指的是利用 LLM 來決定下一步要采取的行動，即確定調(diào)用哪個工具以及使用何種參數(shù)。

然而，「推理」 一詞在其他語境下也被用于完全不同的概念，例如 OpenAI 的 o1 模型所指的 「推理」，是思維鏈（CoT）提示，即模型在給出最終答案前，先輸出一系列中間步驟，模仿人類解決問題時的思考過程，而非單純依賴模式匹配的能力，這類模型并未調(diào)用外部工具，只是以一種類似串聯(lián)多個思考過程的方式生成 LLM 自身的輸出，因而得名 「思維鏈」。

另一種常見的對 「Agent」 一詞的誤用是將其應(yīng)用于所謂的 「AI工作流（AI workflows）」。例如，有人構(gòu)建一個自動化流程：先接收原始文檔，用一個 LLM 進(jìn)行對象識別，再清理提取出的數(shù)據(jù)，接著用另一個 LLM 總結(jié)數(shù)據(jù)，最后將總結(jié)添加到數(shù)據(jù)庫。盡管該流程涉及到多次 LLM 調(diào)用，但 LLM 并未作為決策調(diào)用哪個工具的推理引擎，而是在工作流中事先規(guī)定好了要調(diào)用的 LLM 及其調(diào)用順序和方式，而非讓 LLM 在實時運行中自行決定調(diào)用哪些工具，這只是一個自動化流程，并非 Agent。

以一個簡單的「披薩食譜」作為例子來進(jìn)一步理解 Agent 系統(tǒng)和非 Agent 系統(tǒng)。假設(shè)你請求一個 AI 系統(tǒng)提供披薩食譜，在非 Agent 系統(tǒng)中，你可能直接將請求輸入到一個 LLM，由其生成結(jié)果。而在 Agent 系統(tǒng)中，Agent 可能擁有的工具之一是 「從食譜書中檢索食譜」，系統(tǒng)會先使用 LLM（推理模型）進(jìn)行判斷，根據(jù)用戶請求使用 「食譜工具」，輸入?yún)?shù)為 「披薩」，以找到對應(yīng)的食譜，然后調(diào)用該工具獲取食譜文本，接著推理模型根據(jù)工具輸出判斷無需進(jìn)一步處理，結(jié)束 「循環(huán)」。

盡管你現(xiàn)在可能理解了 Agent 的區(qū)別，但你或許會問這為何有趣，看起來不過是方法上的技術(shù)細(xì)節(jié)。原因主要有以下幾點：

• 當(dāng)需求稍顯復(fù)雜，如 「要一份那不勒斯風(fēng)格的健康食材披薩食譜」 時，非 Agent 系統(tǒng)可能憑借生成模型的強(qiáng)大能力給出像樣的結(jié)果，但隨著請求越來越詳細(xì)、層層遞進(jìn)，試圖通過單次調(diào)用 LLM 完美滿足所有要求的可能性會降低。而 Agent 系統(tǒng)可能會先推理決定使用一個工具，通過 LLM 描述披薩的制作方式；接著推理決定使用另一個工具進(jìn)行網(wǎng)絡(luò)搜索來確定健康食材；然后進(jìn)行推理決定使用最終檢索食譜的工具，前幾步獲得的信息同樣可用于指導(dǎo)或配置該工具的輸入。這種將任務(wù)分解成步驟的方式，與人類處理事情的方式相似。同時，因為 Agent 使用的是人類更了解、更易控制的工具，可以降低結(jié)果的不確定性。雖然不能保證一定成功，但 Agent 方法比非 Agent 方法更有機(jī)會讓AI系統(tǒng)把事情辦對。

• 我們能為 Agent 提供的工具可以彌補(bǔ) LLM 的短板。LLM 是一個基于自然語言模式運作的隨機(jī)系統(tǒng)，對非文本概念沒有內(nèi)在理解。如 LLM 不擅長數(shù)學(xué)，可添加計算器工具；LLM 不知道當(dāng)前時間，可添加系統(tǒng)時間工具；LLM 無法編譯代碼，可添加構(gòu)建工具。這樣，Agent 系統(tǒng)中的推理模型無需內(nèi)在地掌握這些領(lǐng)域的知識，只需知道何時調(diào)用相應(yīng)工具及確定傳遞給工具的正確輸入?yún)?shù)即可，這比讓 LLM 掌握所有領(lǐng)域知識更易于實現(xiàn)，且判斷可基于文本上下文。

• 工具可改變 「世界」 的狀態(tài)，而不僅僅是提供文字響應(yīng)。在披薩食譜的例子中，若希望 AI 不僅給出食譜，還能將其發(fā)給他人，且 Agent 有權(quán)訪問聯(lián)系人及發(fā)送短信工具，它就會進(jìn)入循環(huán)：先推理決定檢索食譜，再推理決定檢索妹妹的聯(lián)系信息，最后推理決定發(fā)送短信。前兩步可能通過一些非常聰明的 RAG（檢索增強(qiáng)生成）也能實現(xiàn)，但最后一步真正采取行動的能力，是 Agent 系統(tǒng)具備更強(qiáng)大的能力的體現(xiàn)。

現(xiàn)在你已基本了解 Agent 是什么，但還有更多背景信息可助你在談?wù)?「Agent」 時更專業(yè)。

02

通過工具彌補(bǔ) LLM 自身不足，

協(xié)作式 Agent 更具潛力

在探討更好地理解 Agent 系統(tǒng)中的思維模型之前，接下來我們先簡要回顧是如何發(fā)展到今天的，并根據(jù)不同類型的 AI 工具與 Agent 方法的契合度進(jìn)行區(qū)分，同時結(jié)合軟件工程領(lǐng)域展開討論。

幾年前，在生成式 AI 工具出現(xiàn)前，人類依靠一系列行動完成工作，例如軟件工程領(lǐng)域包括在 StackOverflow 上搜索資料、運行終端命令、編寫代碼等。

隨著 LLM 的出現(xiàn)，我們擁有了能很好完成特定任務(wù)的系統(tǒng)，如 ChatGPT 用于回答問題，GitHub Copilot 用于自動補(bǔ)全代碼等。這些工具能贏得使用者的信任，是因為它們滿足了兩個條件：一是解決了用戶真正關(guān)心的問題，且 LLM 技術(shù)足夠成熟，能以足夠可靠的水平解決問題，讓用戶在特定場景下愿意信任它。二是多年來人們構(gòu)建了許多基于 LLM 的系統(tǒng)，來展示其解決復(fù)雜任務(wù)的能力，但許多成果僅停留在演示階段，無法投入生產(chǎn)環(huán)境并獲得用戶長期信任，導(dǎo)致炒作與現(xiàn)實脫節(jié)。如總結(jié)拉取請求對用戶有價值，但用戶對其準(zhǔn)確度的要求很高，若首次使用 AI 時給出的總結(jié)是錯的，那用戶可能就不再信任該工具。盡管 LLM 技術(shù)不完美，但發(fā)展迅速，因此能以足夠高的可靠性來解決任務(wù)，同時能解決任務(wù)的復(fù)雜度也在不斷提升。

最初 「有用」 與 「可能實現(xiàn)」 的交集僅限于 「Copilot 式」 系統(tǒng)，這些 AI 系統(tǒng)通過單次 LLM 調(diào)用解決非常有限的任務(wù)，如回復(fù)提示或生成自動補(bǔ)全建議等，在人類與 AI 協(xié)同工作 （human-in-the-loop）中，在采納結(jié)果前進(jìn)行審查，因此不必?fù)?dān)心 AI 「失控」。AI 主要的挑戰(zhàn)是 「幻覺」 問題，即模型給出不準(zhǔn)確的結(jié)果，這源于模型內(nèi)在的 「自信」 （這些模型是在互聯(lián)網(wǎng)文本上進(jìn)行訓(xùn)練，而互聯(lián)網(wǎng)上誰都顯得很自信）以及缺乏使回答符合現(xiàn)實的知識。因此，人們通過更強(qiáng)大的 RAG （Retrieval Augmented Generation）方法改進(jìn) Copilot 式系統(tǒng)，簡單來說，RAG 就是先檢索相關(guān)信息為查詢提供事實依據(jù)，再將整合后的信息傳遞給 LLM 生成最終響應(yīng)，這種能力定義了基于 LLM 應(yīng)用的最初幾年。

正是這些類似 Copilot 的非 Agent 系統(tǒng)，以用戶愿意長期信賴的穩(wěn)定水平創(chuàng)造了實際價值。但「Agent 系統(tǒng)」 這一概念并非新事物。

首個流行的 Agent 框架 AutoGPT 早在 2023 年初就問世了，其方法是讓 Agent 循環(huán)自主運行，用戶只需提供提示，由 Agent 自行執(zhí)行并審查結(jié)果。由于可訪問工具并進(jìn)行多次 LLM 調(diào)用，這些系統(tǒng)運行時間更長，能完成比 Copilot 式系統(tǒng)范圍更廣的任務(wù)。

盡管 AutoGPT 仍是 GitHub 上最受歡迎的倉庫之一，但用它創(chuàng)建的 Agent 并未真正普及。一年后，Cognition 公司推出 Devin，一個號稱功能齊全、能取代人類軟件開發(fā)者的 AI 開發(fā)者，這是一個完全自主的 Agent 系統(tǒng)，擁有強(qiáng)大的工具，但至今能解決的仍是相對簡單的問題。

這就引出了一個問題：若 Agent 如此強(qiáng)大，為何用戶主要從 RAG 驅(qū)動的非 Agent 的 Copilot 式系統(tǒng)中獲得價值，而非 Agent 系統(tǒng)？

這與上文提到的 「有用問題」 與 「技術(shù)足夠成熟可靠」 的交集有關(guān)，是自主 Agent 系統(tǒng)面臨的普遍挑戰(zhàn)。雖然自主 Agent 是未來發(fā)展方向，但當(dāng)前 LLM 可能在無人干預(yù)或糾正的情況下，難以端到端地完成復(fù)雜任務(wù)。

基于此，催生了 Agent 的一種新方法，即認(rèn)識到人類和 Agent 之間需要某種平衡，這類 Agent 被稱為 「協(xié)作式 Agent」（collaborative agents），或簡稱為 「AI Flows」。

具體而言：

• 必須有清晰的方式讓用戶在工作流執(zhí)行過程中觀察其進(jìn)展，以便及時糾正偏差，重新引入 Copilot 式系統(tǒng)中 「human-in-the-loop」的協(xié)作特性。

• 這些工作流必須在人類習(xí)慣工作的同一環(huán)境中運行。大多數(shù)自主 Agent 項目獨立于用戶運行，其調(diào)用界面與用戶手動完成工作時的環(huán)境是脫節(jié)的，如 Devin 通過網(wǎng)頁調(diào)用，而開發(fā)者在 IDE 中編寫代碼。若 Agent 不在人類工作的主環(huán)境中，就無法感知手動操作，會錯過許多隱式上下文。

總之，在現(xiàn)實應(yīng)用中，Agent 能觀察人類行動很重要，反過來人類能觀察 Agent 的行動也同樣重要。

協(xié)作式 Agent 方法所需的可靠性門檻顯著低于自主 Agent 方法，因為人類可以在中間步驟糾正 AI，在 AI 執(zhí)行某些行動時確認(rèn)，并負(fù)責(zé)實時審查改動。目前，所有能為用戶帶來切實價值且普通用戶可接觸到的 Agent 應(yīng)用，都采用了這種方法，如 Windsurf 的 Cascade、Cursor 的 Composer Agent 和 GitHub Copilot Workspaces，在這些工作流中，人類和 Agent 始終在同一 「世界狀態(tài)」 下協(xié)同運作。

我們?nèi)绱嗽敿?xì)地區(qū)分自主 Agent 和協(xié)作式 Agent，是因為它們是構(gòu)建 「Agent 系統(tǒng)」 的截然不同的兩種方法，這兩種方法在「human-in-the-loop」的 參與程度、所需信任水平、交互方式等方面差異巨大。由于 「Agent」 一詞被過度使用，有人熱衷于討論構(gòu)建自主 Agent，并以像 Windsurf 的 Cascade 這樣的系統(tǒng)作為 Agent 可行的證據(jù)，而實際上這兩種方法本質(zhì)上并不同。

03

全方位理解和剖析 「Agent 系統(tǒng)」

以下是一個包含所有前文內(nèi)容的速查清單，幫你理解關(guān)于 「Agent」 的對話，并提出觸及技術(shù)核心的問題。這些問題中可以分別延展成獨立的文章探討，這里我們先進(jìn)行基礎(chǔ)的探討。

問題 1：討論的系統(tǒng)真的是 Agent 嗎？

太多非 Agent 系統(tǒng)被冠以 「Agent 系統(tǒng)」 之名，需明確其中的 LLM 是否作為工具調(diào)用的推理模型，是否真的有工具被調(diào)用，還是僅為思維鏈推理或其他含義完全不同的東西。

問題 2：它是自主的還是協(xié)作式的？

該 Agent 系統(tǒng)是讓 Agent 在后臺自主工作無需人工參與，還是具備獨立完成多步任務(wù)的能力但卻嵌入到現(xiàn)有的工作系統(tǒng)中仍需要人類參與？若是前者，即自主 Agent，需要追問當(dāng)前模型是否足夠強(qiáng)大，能以用戶信賴的穩(wěn)定性水平處理數(shù)據(jù)和工具的規(guī)模及復(fù)雜性，還是構(gòu)建自主 Agent 的想法并不切實際？

問題 3：Agent 是否擁有內(nèi)在強(qiáng)大的所有輸入和組件？

• 問題 3a：Agent 可以訪問哪些工具？

不僅要了解工具列表，還要探究工具的實現(xiàn)方式，如 Windsurf 的 Cascade 采用了獨特的網(wǎng)頁內(nèi)容分塊和解析方法。以及，添加獨特工具的難易程度如何？

• 問題 3b：Agent 使用的是哪個推理模型？

評估 LLM 時，應(yīng)關(guān)注其在工具調(diào)用方面的能力，而非其在標(biāo)準(zhǔn)基準(zhǔn)測試中的表現(xiàn)，不存在勝任所有任務(wù)的最優(yōu) LLM，需考慮 Agent 是否具備使用不同類型模型的靈活性。

• 問題 3c：Agent 如何處理現(xiàn)有數(shù)據(jù)？

Agent 能訪問哪些數(shù)據(jù)源？在協(xié)作式 Agent 場景下，它對這些數(shù)據(jù)源的訪問是否遵循了用戶已有的訪問控制規(guī)則？比如對于代碼庫，Agent 是僅能訪問用戶當(dāng)前在 IDE 中檢出的倉庫，還是也能訪問其他倉庫的信息來輔助結(jié)果生成？從代碼的分布式特性來看，能訪問更多倉庫可能更有價值，但訪問控制的難度也會相應(yīng)增加。

Agent 方法改變了我們思考數(shù)據(jù)檢索的方式。在 Copilot 式系統(tǒng)里，只有一次調(diào)用 LLM 和檢索的機(jī)會，這使得 RAG 系統(tǒng)愈發(fā)復(fù)雜。而在 Agent 系統(tǒng)中，若首次檢索結(jié)果不理想，推理模型可更改參數(shù)重新檢索，直到收集到足夠的信息采取行動，這更貼近人類查找數(shù)據(jù)的模式。所以，當(dāng)討論深入到 RAG、解析及中間數(shù)據(jù)結(jié)構(gòu)時，不妨想想我們在 Agent 領(lǐng)域是否把問題想復(fù)雜了。

不過，如果數(shù)據(jù)本身有結(jié)構(gòu)，那詢問這些數(shù)據(jù)源的信息如何處理是合理的。比如 AI 編程工具處理的代碼庫是高度結(jié)構(gòu)化的，就可以利用抽象語法樹（AST）解析等技術(shù)，對代碼智能分塊，方便理解或搜索代碼的工具處理。智能預(yù)處理和多步驟檢索是可以并存的。

• 問題 3d：協(xié)作式 Agent 或 AI Flow 如何捕捉用戶意圖？

在人類用戶的手動操作中，存在一些無法明確編碼的隱式信號。雖然 Agent 不知道你在飲水機(jī)旁聊了什么，但僅通過捕捉這些隱式信號，就能創(chuàng)造出極有價值的體驗。在我們領(lǐng)域，這些用戶意圖可能體現(xiàn)在 IDE 中打開的其他標(biāo)簽頁、剛剛在文本編輯器中的編輯、執(zhí)行的終端命令、剪貼板內(nèi)容等。這關(guān)乎降低用戶使用 Agent 的「激活能壘」——若每次使用 Agent 都要用戶詳細(xì)描述本可通過隱式信號推斷的細(xì)節(jié)，那用戶對 AI 結(jié)果質(zhì)量的期望就會過高。

問題 4：這個 Agent 的用戶體驗為何特別好？

我們之前主要探討了影響 Agent 結(jié)果質(zhì)量的因素。但若想打造一款真正被用戶接納的 Agent 系統(tǒng)，僅關(guān)注結(jié)果質(zhì)量還不夠，還需關(guān)注提升用戶使用流暢度的各方面體驗，即便底層 Agent 本身沒變。這些體驗維度很多都不易構(gòu)建，需要深入思考。

• 問題 4a：Agent 系統(tǒng)的延遲如何？

假設(shè)有兩個 Agent 系統(tǒng)能完成同一特定任務(wù)，一個耗時一小時，另一個只需一分鐘。若確定兩者都能成功，你可能不太在意時間差，畢竟等待時可以做別的事。但若 Agent 有可能失敗呢？你肯定會更傾向后者，因為能更快知曉失敗，及時調(diào)整提示或給 Agent 更多指導(dǎo)。延遲問題是全自主 Agent 的主要挑戰(zhàn)之一，它們完成任務(wù)的耗時通常比人類手動操作更長，除非自主 Agent 的成功率極高，否則用戶不會選擇使用它。

特別強(qiáng)調(diào)延遲問題的原因有二：其一，Agent 開發(fā)者為提升結(jié)果質(zhì)量，常添加復(fù)雜耗時的工具，卻忽視了對用戶體驗的影響，沒做好權(quán)衡；其二，減少延遲是技術(shù)棧各環(huán)節(jié)的難題——是模型推理優(yōu)化，還是構(gòu)造提示以提高緩存命中率，或是在工具內(nèi)部實現(xiàn)并行計算？這需要不同技能的工程師協(xié)同攻克。

• 問題 4b：用戶如何觀察和引導(dǎo) Agent？

這是協(xié)作式 Agent 相較自主 Agent 的一大優(yōu)勢，但實現(xiàn)起來并不容易。例如，若編程 Agent 能在 IDE 的多個文件中多次修改代碼，開發(fā)者該如何有效審查這些改動？這和查看單個自動補(bǔ)全建議或在聊天面板審查回復(fù)完全不同。

此外，人們需要時間來建立特定環(huán)境下的任務(wù)最佳實踐上下文。你能設(shè)計出怎樣的用戶體驗，讓用戶引導(dǎo) Agent 遵循這些最佳實踐？比如，Windsurf 的 Cascade 可接受用戶定義的規(guī)則，或通過簡單方式標(biāo)記已知上下文以指導(dǎo) Agent。雖說 Agent 的目標(biāo)是能獨立完成任務(wù)，但如果用戶能輕松幫助 Agent 降低任務(wù)難度，Agent 就能更快地輸出高質(zhì)量成果。

• 問題 4c：Agent 如何集成到應(yīng)用中？

這取決于如何優(yōu)雅地調(diào)用 Agent 以及利用其輸出。如今，ChatGPT 的流行讓聊天面板成為調(diào)用 AI 系統(tǒng)的常見方式，但這不是唯一選擇。例如，Windsurf 的 Cascade 可通過一個簡單按鈕調(diào)用以解釋代碼段，并且能通過 Previews 功能將控制臺日志和 UI 組件等上下文信息傳遞給 Cascade，無需復(fù)制粘貼文本。

• 問題 4d：Agent 體驗如何與非 Agent 體驗平衡？

并非所有任務(wù)都需 Agent 來做。比如開發(fā)者進(jìn)行局部重構(gòu)時，使用 Command 和 Tab 等快捷鍵組合這類非 Agent 的「Copilot 式」體驗，既快速又高效。Agent 是新興領(lǐng)域，但不能盲目用 Agent 解決所有問題。問問自己「這個任務(wù)真的需要構(gòu)建一個 Agent 嗎？」往往很有必要。

當(dāng)然，以上只是初步探討，但這份清單能幫你更好地理解 Agent 相關(guān)對話，提出關(guān)鍵問題，為想法增加現(xiàn)實主義的視角。

04

構(gòu)建 Agent 同樣需要注意「苦澀的教訓(xùn)」

最后，有一個重要問題值得單獨列出，若你從本文只記住一個問題，那應(yīng)該是 「我們是否正在違背‘苦澀的教訓(xùn)’？」 「苦澀的教訓(xùn)」 源自 Richard Sutton 的同名文章，其核心觀點是：更多的算力、數(shù)據(jù)以及更大規(guī)模的技術(shù)，終將超越依賴人類定義結(jié)構(gòu)或規(guī)則的系統(tǒng)。這一趨勢在計算機(jī)視覺、游戲、NLP 等領(lǐng)域得到印證，如 LLM 的性能超越了傳統(tǒng) NLP 方法。

在使用 Agent 時，我們可能再次忘記 「苦澀的教訓(xùn)」，認(rèn)為對特定用例的深入了解，需花費時間精心設(shè)計提示、選擇工具集合或注入人類知識。然而，模型持續(xù)改進(jìn)，計算能力變得更便宜、強(qiáng)大，這些努力最終可能付諸東流。因此，要避免落入 「苦澀的教訓(xùn)」 的陷阱。