來源：AI產品阿穎

刷朋友圈，偶然看到大廠朋友轉發一篇關于 Agent 的文章，還特意點評：寫得真精彩。我點進去讀了下，確實不錯，原來出自 Windsurf 團隊。

這段時間 “Agent” 成了熱詞，開會、聊天、朋友圈，大家都在聊。但每個人說的 “Agent” 其實都不一樣，聽多了反而更迷糊：究竟什么是 Agent？和我們熟悉的生成式 AI 有什么不同？

這是我目前見過最清晰解釋 Agent 的文章。

基本核心概念

可以簡單地把 Agent 系統理解為一個接受用戶輸入，并交替執行以下兩種調用的系統。

• LLM，會根據用戶輸入、可能自動檢索到的額外上下文信息，以及不斷積累的對話內容，決定下一步要采取的行動。

  推理模型會輸出：（a）一段文本，解釋接下來應該采取什么行動；以及（b）一段結構化信息，用來明確說明該行動的細節（具體是哪一個行動，該行動的輸入參數值等）。

  有時候，輸出的 “行動” 也可能是判斷 “當前沒有任何行動需要再執行”。

• 工具，指的是可以實際執行各種行動的組件，它們不一定非要與 LLM 有任何關系。這些工具根據推理模型的指令來執行任務，并生成結果，而這些結果會被納入下一次調用推理模型時所使用的信息中。推理模型的作用本質上是在可用的工具和行動之間做出選擇。

這就構成了一個基本的 Agent 循環：

真的，就是這樣。一個 Agent 系統可能會因為其 Agent 循環向用戶暴露的方式不同而呈現出不同的 “風格”，我們稍后會展開講。

但只要你理解了這個概念——這些 LLM 不是被當作一個純粹的內容生成器（比如 ChatGPT），而是被當作一個 “工具選擇的推理組件” 來使用——你其實已經掌握了大部分要點。

“推理（reasoning）” 這個詞本身也被過度使用了——但在 Agent 系統的語境下，它有一個非常具體的含義：指的是使用 LLM 來選擇下一步應該執行什么動作，也就是應該調用哪個工具、傳入哪些參數。

“推理” 這個詞也被像 OpenAI 的 o1 這樣的模型使用過，但在那里的含義完全不同。對這些 LLM 來說，“推理” 指的是 “鏈式思考提示（chain-of-thought prompting）”。

這種方法的核心理念是：模型會先輸出一些中間步驟，再嘗試給出最終答案，目的是模擬人類解決問題時的思考過程，而不是單純依賴模式匹配的魔法。

對于這些模型來說，并不會調用任何工具（不像在 Agent 系統中），而是以一種看似多次調用思考過程的方式輸出回答內容（這也是 “chain-of-thought” 這個說法的由來）。

另一個對 Agent 的誤用，是把它混淆成所謂的 “AI 工作流（AI workflows）”。

舉個例子，有人可能會構建一個自動化流程，輸入一份原始文檔，先用一個大語言模型進行目標識別（object recognition），然后對提取出的元素進行清洗，再用另一個大語言模型對這些元素進行摘要，最后把這個摘要添加進數據庫。

這個過程中雖然涉及多次調用 LLM，但這些 LLM 并不是作為 “工具調用推理引擎” 來使用的。我們事先就明確規定好了應該調用哪些 LLM、如何調用，而不是讓 LLM 在實時運行中決定要調用哪些工具。這只是一個自動化流程，不是一個 Agent 系統。

理解 “Agent 系統” 與 “非 Agent 系統” 的一個非常簡單的例子是：假設你問一個 AI 系統怎么做披薩。在非Agent 系統中，你只是把這個提示詞直接輸入給 LLM，然后它就生成一個結果。

而在 Agent 系統中，Agent 所擁有的工具之一可能是 “從某本食譜書中檢索菜譜”，而這本書中包含披薩的做法。在這個 Agent 系統中，系統會使用 LLM（也就是推理模型）來判斷：根據這個提示詞，應該調用 “菜譜工具”，并傳入 “披薩” 作為輸入，以檢索正確的菜譜。

接著系統會調用這個工具，得到對應菜譜的文本輸出；隨后，推理模型會基于這次工具調用的輸出判斷：已經沒有其他工作需要繼續執行了，于是它會結束這一輪循環。

雖然你現在可能已經理解了它們之間的區別，但你可能會問——這有什么好玩的？這不就是一種技術實現方式的細節問題嗎？

其實，這之所以有趣，有幾個原因：

想象一下，前面的例子如果再復雜一點，比如 “獲取一份使用健康食材、并符合那不勒斯風格的披薩菜譜”。

非 Agent 系統可能靠生成模型的強大能力，仍然可以給出一個差不多的答案，但當請求變得越來越復雜、層次越來越多時，單次調用一個 LLM 就很難完全滿足需求。

而 Agent 系統則可能會先推理出需要調用一個工具，讓它去描述那不勒斯是怎么做披薩的，然后再推理出應該使用另一個工具去搜索哪些食材被認為是健康的，最后才推理出應該調用檢索菜譜的工具，而前面幾個步驟的信息又可以作為最終工具的可配置輸入參數。

這種任務拆解的方式聽起來應該是很自然的，因為這本來就是人類解決問題的方式；同時也能降低生成結果的隨機性，因為 Agent 系統使用的是我們更熟悉、更可控的工具。雖然這并不意味著一定能成功，但相比非 Agent 方法，這種 Agent 路徑更有可能得到正確結果。

我們可以為 Agent 系統提供各種工具，來彌補 LLM 本身不擅長的事情。要記住，LLM 是一種基于自然語言模式運行的隨機系統。它對非文本概念沒有內在理解。

LLM 不擅長數學？那我們就加一個計算器工具。LLM 不知道當前時間？那我們就加一個系統時間工具。LLM 無法編譯代碼？那我們就加一個構建工具。

于是，在 Agent 系統中，推理模型（也就是 LLM）就不需要自己真的知道怎么做數學計算、怎么看時間或怎么編譯代碼，而只需要知道什么時候該用計算器，什么時候該查詢系統時間，什么時候該嘗試構建源代碼，并能判斷應該給這些工具傳入哪些正確的輸入。

知道怎么調用這些工具，是一個更容易處理的問題，可以基于文本上下文來做。

這些工具不僅可以提供文本響應，它們還可以真正對現實世界的狀態進行改變。

比如，回到披薩的例子，如果我們希望 AI 把披薩菜譜發給我妹妹，假設 Agent 具備訪問我的聯系人和發送短信的工具，它就可以進入一個循環——先推理出要檢索菜譜，然后推理出要獲取我妹妹的聯系方式，最后推理出要發送短信。

前兩個步驟可能靠非常聰明的 RAG（檢索增強生成）也能完成，但最后一步呢？那種 “真正采取行動” 的能力，而不僅僅是生成文本，這讓 Agent 系統具備了成為強大系統的潛力。

恭喜你，你現在已經知道什么是 “Agent” 了！不過，如果你想在 “Agent” 相關的談話中真正游刃有余，還有更多背景知識值得了解。

我們是如何走到今天這一步的，以及為什么是現在

在進入 “你可以用來與他人進行有意義討論” 的 Agent 系統心智模型之前，我們先簡單回顧一下我們是如何走到這一步的，并澄清一下不同類型的 AI 工具在 Agent 上的表現方式。

我們會以我們所處的領域——軟件工程——為背景來講，這樣就不會顯得過于抽象。

如果你還能記得幾年前的世界，那時候在生成式 AI 工具出現之前，是人類在做這些工作。這些工作可以看作是一個個連續的動作組成的時間線。在軟件工程中，這可能包括：在 StackOverflow 上查資料、運行終端命令、真正寫代碼等等：

接著，隨著 LLM 的出現，我們開始擁有了一些能很好完成特定任務的系統。比如 ChatGPT 可以用來回答問題，GitHub Copilot 可以自動補全幾行代碼等等。這些工具之所以能被信任，是因為它們同時滿足了兩個條件：

• 它們解決了用戶真正關心的問題（例如，每個開發者都討厭寫樣板代碼，所以能自動補全這類內容就非常有價值）

• LLM 技術本身已經足夠強大，能夠在某些特定應用場景中以足夠可靠的水平解決這些問題，從而讓用戶愿意信任它（比如：開發者不喜歡某個補全建議？沒關系，他可以直接繼續打字，忽略掉就行）。

第二個條件其實很重要。多年來，人們一直用 LLM 做出非常炫酷、超復雜任務的演示（demo），但大多數 demo 并不能真正落地、也難以被信任，這就導致了人們在炒作與現實之間產生了普遍的脫節，最終進入幻滅低谷期。

拿 “總結一個 PR” 這個例子來說：這對用戶來說顯然是有價值的（沒人喜歡手動寫 PR 描述），但你想想要達到用戶愿意長期信任它所需要的準確度有多高。

只要 AI 第一次總結錯了，用戶以后就會每次都手動檢查所有文件，自己寫描述，這個工具的價值也就等于被抹消了。

這個用例對系統穩健性的要求非常高，而今天的技術或許還達不到。不過話說回來，盡管當前的 LLM 技術并不完美，但它也在快速進步，因此可以穩健地完成的任務復雜度上限也在不斷提高。終有一天，AI 會足夠可靠地寫出 PR 描述。

我有點跑題了。我們剛開始看到的 “有用” 與 “可實現” 交集，其實僅限于我所說的 “類 Copilot 系統”。這些 AI 系統會對某個非常具體的任務進行一次 LLM 調用，比如響應提示詞、生成代碼補全建議等等。

人在循環中始終處于 “審閱結果” 的位置，在 “接受” 結果之前先確認，因此無需擔心 AI 失控的問題。

主要的問題反而是 “幻覺”——模型輸出了不準確的結果，這一方面是因為它們天然自信（這些模型是在互聯網文本上訓練出來的，而網上的每個人都很自信），另一方面是因為它們缺乏把答案錨定在現實上的知識（歸根結底，它們只是超級復雜的模式匹配算法）。

于是，這類 Copilot 系統逐步被更強大的 “檢索增強生成（簡稱 RAG）” 方法所改進。本質上，它的意思是：系統會先檢索與用戶問題相關的信息，用這些信息來 “增強” 原始問題，再將增強后的信息一并傳給 LLM 去生成最終回答。

這種給 AI 系統賦予 “知識訪問能力”，并且仍然只針對特定任務使用的方式，構成了基于 LLM 的應用最初那幾年發展的核心特征——也就是所謂的“Copilot 時代”：

這些類 Copilot 的非 Agent 系統，才是真正在用戶能夠長期信任的穩定水平上持續創造實際價值的系統。但這并不意味著 “Agent 系統” 這個概念是全新的。

第一個廣為人知的 Agent 框架是 AutoGPT，它其實早在 2023 年初，ChatGPT 剛發布不久后就已經問世了。它對于 Agent 系統的設計方式是：讓 Agent 循環以一種自主的方式運行——用戶只需提供一個提示詞，然后讓 Agent 自己執行一系列操作，最后再來查看結果。

本質上，由于這些系統能夠訪問工具，并進行多次 LLM 調用，它們運行時間更長，能夠完成的任務范圍也比類 Copilot 系統大得多：

然而，盡管 AutoGPT 仍是 GitHub 上最受歡迎的開源項目之一，用這個框架創建的 Agent 系統其實并沒有真正普及開來。

一年后，Cognition 推出了 Devin，一個被宣傳為能夠取代人類軟件工程師的全功能 AI 開發者。同樣是一個完全自主的 Agent 系統，具備一些非常強大的工具，但直到今天，它也只能解決相對簡單的問題。

那到底發生了什么？如果 Agent 真的那么強，為什么真正帶來價值的，還是那些 RAG 加持的、非 Agent 的 Copilot 系統？

回想一下我們之前提到的 “有價值的問題” 與 “技術是否已經足夠可靠” 之間的交集？這正是這些 Agent 系統所面臨的普遍挑戰。

雖然 Agent 系統代表著未來的發展方向，但今天的 LLM 可能還不具備足夠的能力，在沒有任何人類參與或糾正的情況下，從頭到尾完成這些復雜任務。

現實促使人們開始采取一種新的 Agent 系統方法，這種方法基于一個共識：在人類與 Agent 之間，應該存在一種合理的任務分配平衡。為了與完全自主的 Agent 方式加以區分，我們將這種方法稱為 “協作式 Agent ”，或簡稱為 “AI flows”。

具體來說：

需要有清晰的方式讓人類在流程執行過程中觀察它的行為，這樣一旦流程偏離預期，人類可以盡早進行糾正。換句話說，是將類 Copilot 系統中的人機協作機制重新引入進來。

這些流程必須運行在與人類進行實際工作的相同環境中。大多數完全自主 Agent 的嘗試，都是在與用戶操作界面完全分離的環境中運行的，因為它們本身就是 “獨立” 工作的。舉個例子，Devin 是在網頁中被調用的，而現實中開發者是會在 IDE 中寫代碼的。

如果我們真的處在一個 Agent 可以完成所有事情的世界里，這樣做也許沒問題，但由于這些自主 Agent 系統并不生活在用戶實際工作的場景中，它們就無法觀察人類是如何手動完成工作的。因此，它們會錯過很多可以通過人類行為推斷出來的隱含上下文。

比如，如果 Agent 系統是嵌入在 IDE 中運行的，那么它就能察覺到最近的手動編輯，這些信息可以隱性地告訴 Agent 接下來應該做什么。

換句話說，在這個現實中，讓人類觀察 Agent 在做什么很重要，而讓代 Agent 觀察人類在做什么也同樣重要。

回到 “有價值的問題” 與 “技術是否已經足夠可靠”之間的交集，協作式 Agent 方法所需的穩健性門檻要遠低于完全自主的 Agent 方法。這是因為人類可以隨時在中間步驟中對 AI 進行糾正，可以被要求批準 AI 的某些操作（例如執行終端命令），并且需要實時審查其所做的更改。

這正是當下所有真正創造實際價值、并廣泛可用的 Agent 應用所采用的方法，例如 Windsurf 的 Cascade、Cursor 的 Composer Agent，以及 GitHub Copilot Workspaces。在這些 flow 中，人類與 Agent 始終在同一個世界狀態下協作運行：

我們花這么大篇幅來區分 “自主 Agent” 和 “協作式 Agent”，是因為這兩種方式在構建 Agent 系統時，其實是截然不同的路徑。它們涉及到完全不同程度的人機協作、不同程度的信任需求、不同的交互方式等等。

而由于 Agent 這個詞被過度使用，人們常常在談論構建自主 Agent 的同時，又把 Windsurf 的 Cascade 這樣的 Agent 系統當作 “Agent 成功” 的例證，但實際上，這兩種方法之間的差異非常大。

如何理解一個 Agent 系統的運作方式

好了，終于到了你可能一直在等的部分——一份快速清單，結合我們上面所講的一切，幫助你（a）在對話中更好地理解 Agent 相關內容，（b）提出能切中技術核心的問題。很多問題其實本身都可以單獨寫成一篇文章，但我會盡量先提供一個有用的起點。

問題 1：我們討論的系統，真的算是 Agent 嗎？

如你所見，現在有太多人在把一些其實并不是 “Agent” 的系統貼上 “Agent” 的標簽。這個系統真的在使用 LLM 作為 “工具調用推理模型” 嗎？它真的調用了工具嗎？還是說它只是用了類似“思維鏈”之類的推理方式，只是叫 Agent，但其實是完全不同的概念？

問題 2：它是自主式的，還是協作式的？

這個 Agent 系統的設計方式，是希望 Agent 在沒有人類參與的情況下在后臺運行？還是 Agent 能夠獨立執行多個步驟，但嵌入在已有的工作系統中，并且仍然有人類參與其中？

如果是前者，那么你需要追問一個問題：當前的模型是否真的已經足夠強大，能夠以用戶可以信賴的穩定性，對相關數據和工具進行復雜、規?；耐评恚窟€是說，“構建一個自主 Agent”聽起來很美好，但在現實中卻并不實用？

問題 3：這個 Agent 擁有讓它強大的輸入和組件嗎？

這個問題開始觸及到不同 Agent 實現之間的真正區別（尤其是協作式 Agent 或 Flow），即使它們試圖解決的是相同的任務。

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

不只是工具的列表，還要考慮這些工具是如何實現的？例如，Windsurf 的 Cascade 在執行網頁搜索時采用的是對網頁內容進行分塊和解析的獨特方法。另外，是否可以輕松添加你自己開發的獨特工具？Anthropic 提出的 Model Context Protocol（MCP）等方法正試圖標準化一種接入方式，將新工具集成到現有 Agent 系統中。

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

評估 LLM 時，關鍵是看它是否擅長進行 “工具調用”——而不是看它在各種任務和領域的標準基準測試中表現是否最好。一個模型在回答編程問題上非常擅長，并不意味著它也擅長以 Agent 方式選擇合適的工具來解決這些編程任務。

沒有哪個 LLM 能在所有任務上都是 “最好的推理模型”，雖然像 Anthropic 的 Claude 3.5 Sonnet 被認為是工具調用方面表現最好的模型之一，但這些模型正在快速演進。因此，值得思考的一個問題是：這個 Agent 系統是否支持使用不同模型的靈活性？

問題 3c：Agent 如何處理現有數據？

Agent 可以訪問哪些數據源？對于這些數據源的訪問，Agent 是否遵守了對用戶而言已存在的訪問控制規則（尤其是在協作式 Agent 的場景下）？

有時問題并不僅僅是 “能否訪問數據源” 這么簡單——比如在處理代碼庫時，Agent 是否只能訪問用戶在 IDE 中當前檢出的倉庫？還是說，它也可以訪問其他倉庫中的信息來幫助增強結果的準確性？在代碼高度分布的現實環境中，后者可能更有價值，但這也使得 “訪問權限” 相關的問題變得更加重要。

總體而言，Agent 在處理數據檢索問題時帶來了新的范式。在類 Copilot 系統中，只有一次調用 LLM 的機會，因此也只有一次檢索機會，這也催生了越來越復雜的 RAG 系統。

而在 Agent 系統中，如果第一次檢索的結果不好，推理模型可以選擇重新進行一次帶有不同參數的檢索，一遍遍重復，直到確定已收集到所有足以執行操作的相關信息。這種方式與人類查找信息的行為方式更為相似。

因此，如果某次討論開始在 RAG、解析或中間數據結構上過于深入，你可以提出一個問題：我們是不是在 Agent 系統的場景中過度復雜化了這個問題？這一點我們稍后還會進一步探討……

當然，如果數據中本身是有結構的，那么詢問這些數據是如何被處理也是合理的。

舉例來說，我們日常處理的是代碼庫，而代碼本身就是高度結構化的，因此我們可以使用一些巧妙的技術，比如抽象語法樹（AST）解析，把代碼進行更智能的分塊，使得那些嘗試在代碼庫上進行推理或搜索的工具更容易處理這些信息。智能預處理和多步檢索并不沖突。

問題 3d：協作式 Agent（或 Flow）是如何捕捉用戶意圖的？

有沒有什么隱性信號（implicit signals）可以用來推測用戶真正的意圖？當然，Agent 無法知道茶水間的閑聊內容，但 “讀懂用戶意圖” 常?？梢詭砀邇r值、更具魔力的體驗。

在我們的場景中，這些意圖可能隱藏在：用戶在 IDE 中打開的其他標簽頁、他們剛剛在文本編輯器中做出的修改、他們剛剛在終端中執行的命令、他們剪貼板里粘貼的內容，甚至更多。

這又回到了 “降低使用 Agent 的激活能量” 這個問題——如果每一次都要求用戶顯式寫清楚那些其實可以從這些隱性信號中推斷出來的內容，那么用戶對 AI 結果質量的期待門檻就會變得更高。

問題 4：這個 Agent 的用戶體驗好在哪里？

到目前為止，我們討論的都是影響 Agent 輸出結果質量的各種因素。你會發現，大多數關于 Agent 系統的討論都集中在這些方面，但如果你真正想打造一個能夠被用戶廣泛采用的 Agent 系統，那就必須關注那些能讓 Agent“用起來更順暢” 的用戶體驗維度——即 Agent 理底層的功能完全沒有改變。這些用戶體驗維度并不容易實現，因此需要認真思考。

問題 4a：這個 Agent 系統的響應延遲有多高？

想象一下，有兩個 Agent 系統在處理同一個任務時能做出相同的結果，但一個要一個小時才能完成，另一個只需要一分鐘。如果你知道它們一定能完成任務，也許你不會太在意這個時間差，你可以在此期間去做別的事。

但如果這個 Agent 有可能失敗呢？你一定會更傾向于后者，因為你可以更快看到失敗結果，從而有時間修改提示詞、給予更多引導等等。

這個 “延遲” 問題其實是完全自主 Agent 系統長期以來的核心難題之一——它們完成任務所花的時間常常比人類手動完成還要長；除非它們的成功率極高，否則用戶根本不會愿意用它。

明確提出延遲問題有兩個原因。

• 第一，構建 Agent 的開發者往往會為了提升結果質量而引入復雜、緩慢的工具，卻沒有充分考慮這對用戶體驗的影響和權衡。

• 第二，優化延遲是一個非常難的問題，涉及整個技術棧的方方面面——比如如何優化模型的推理速度？如何設計提示詞，讓系統更容易命中緩存、減少重復生成？如何在工具內部并行處理任務？這些通常都需要一套完全不同的工程能力來解決。

問題 4b：用戶如何觀察并引導 Agent？

這是協作式 Agent 相較于自主 Agent 的一大優勢，但要真正落地卻并不容易。例如，如果一個代碼 Agent 會在 IDE 中對多個文件做出多次修改，開發者該如何有效地審查這些更改？這可遠比檢查一個補全建議或聊天面板里的回答復雜得多。

此外，人們會花時間積累某些任務在特定環境下的最佳實踐。那你要怎么設計用戶體驗，讓人可以引導 Agent 走向這些最佳實踐？

舉個例子，Windsurf 的 Cascade 支持用戶通過定義規則或標記已有上下文的方式來進行引導。是的，任何 Agent 的最終目標都是 “能自己完成所有事”，但如果用戶能很輕松地讓 Agent 的任務變簡單，那 Agent 就能更快地完成更高質量的工作。

問題 4c：Agent 是如何集成在應用中的？

歸根結底，這取決于調用 Agent 的方式是否流暢、以及如何使用其輸出結果。ChatGPT 的流行讓 “聊天面板” 成為調用任何 AI 系統的默認方式。雖然這種方式可行，但它不必是唯一的方式。

例如，Windsurf 的 Cascade 也可以通過其他方式調用，比如點擊一個按鈕來解釋一段代碼。并且上下文也可以通過多種方式傳給 Cascade，而無需復制粘貼文本，比如通過 Previews 將控制臺日志或 UI 組件傳入。

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

這可能是個意料之外的問題，但并不是所有事情都需要 Agent 來處理。舉例來說，如果一個開發者只是想做一個局部重構，那么使用 Command 和 Tab 這樣的組合就會非常高效且迅速。Agent 確實代表了新前沿，但擁有一把新錘子，并不意味著所有問題都是釘子！很多時候，我們應該直接問一句：“這個任務，真的需要一個 Agent 來完成嗎？”

當然，這里我們也只是觸及了表面，但這個檢查清單應該可以幫助你更深入地參與關于 Agent 的討論，提出直擊核心的問題，并為那些 “好聽但不現實” 的想法注入一點現實感。

The Bitter Lesson

但還有最后一點。我把它單獨列出來，是因為如果你從這篇文章中最終只記住一個問題，那就應該是這個：“我們是否違背了 The Bitter Lesson？”

“The Bitter Lesson（苦澀的教訓）” 來自 Richard Sutton 的同名文章，其核心觀點是：更強的算力、更大的數據規模，以及更廣泛的技術規模，最終總是會帶來比任何依賴人類設定結構或規則的系統更強的表現。

我們已經在很多地方見過這一點：比如，在計算機視覺中，卷積神經網絡（CNN）最終打敗了人類手工設計的邊緣檢測、形狀識別算法；在游戲領域，深度搜索和后來的深度神經網絡也超越了任何基于規則的系統，無論是國際象棋、圍棋，還是更復雜的游戲。

甚至 LLM 本身也是這一趨勢的體現，它們已經超越了所有 “傳統” 的自然語言處理方法。

而在 Agent 系統上，我們又一次面臨可能忘記 “苦澀教訓” 的風險。我們可能會覺得自己對某個特定用例理解更深，于是就投入大量時間去精心設計提示詞，或者謹慎挑選哪些子集工具才有價值，或者嘗試各種方式把 “我們自己知道的東西” 灌輸進去。

但最終，這些模型還會繼續進化，算力會持續變得更便宜、更強大，而我們所做的這一切努力，很可能最終都會被淘汰。

不要再次掉入 Bitter Lesson 的陷阱。