本文腦圖如下：

方法：AI Agent 的有效上下文工程

1?? 何為上下文工程 Context Engineering ？

2025 年 6 月以來，原名為「Prompt Engineering」的提示詞工程，在 AI Agent 概念日趨火熱的應用潮中，

經(jīng)由 Anthropic、LangChain、Manus 等 AI 公司，以及 Andrej Karpathy（前 OpenAI 聯(lián)創(chuàng)）、Tobi Lutke（Shopify CEO）等行業(yè)領袖的傳播下，共識成了更適應 Agent 的新概念：

——「Context Engineering」，即上下文工程。

在國內(nèi)，也對應出現(xiàn)了“Prompt 工程已死，未來屬于 context 工程”、“別再卷 prompt 了”等論調(diào)。

但，事實盡是如此？

雖然傳播一個新概念的“好”方法，就是拿它與出了名的舊事物對比、營造沖突。

但 prompt 仍是 context 工程不可或缺的子集，context 工程則是為適應 AI Agent 架構日趨復雜健全的自然發(fā)展。（Anthropic 團隊在《Effective Context Engineering for AI Agents》一文中，也提到了一致觀點）

要簡單區(qū)分兩者差異的話，可以如此理解：

• Prompt 工程，專注單輪 AI 交互的生成質量，是為獲得最佳結果而編寫和組織 LLM 指令的方法。
• Context 工程，更關心在多輪 LLM 推理過程（可通俗理解為 Agent 運行過程）中，找到并維護動態(tài)優(yōu)化整個 LLM 所接觸的上下文信息配置
• （包括系統(tǒng)指令 system instructions、工具 tools、MCP 協(xié)議、外部數(shù)據(jù)、消息歷史 message history）的策略。
• 目標是以盡可能少且必要的 tokens，最大化 LLM 生成結果，引導模型輸出我們期望的行為。

比如，Context 工程涉及的 system instruction 依舊是 prompt 工程實現(xiàn)的。并非全方位替代，只是需要根據(jù) AI 開發(fā)情景，靈活選擇實現(xiàn)深度而已

Anthropic 《Effective Context Engineering for AI Agents》：context engineering 與 prompt engineering 的差異

2?? 有限的大模型上下文空間 → Context Rot

大模型的上下文窗口有限。

從 GPT3.5 的 16K ，到 Claude 3.5 的 200K，再到現(xiàn)在 Gemini 2.5 Pro 的動輒 1M，近年來 LLM 上下文窗口大小，確實提升飛快。

這是否意味著我們可以高枕無憂，把一切 Context 都無腦地塞進去？

答案是否定的——時至今日，上下文依舊需要被視為有遞減收益邊際的有限資源。

不知道你在和 AI 聊天時，是否發(fā)現(xiàn)這么一個現(xiàn)象？

當對話長度不斷增加（即使還沒超過官方標稱的上下文窗口尺度），模型的回復質量也會有明顯的下降：

• 回答深度降低： 越來越難深入結合前文你提供的細節(jié)，提供創(chuàng)造性和細節(jié)度俱佳的回應。通常你不得不重新發(fā)送關鍵 Prompt，再次強調(diào)可能有用的細節(jié)。
• 混亂歸因：在做歸納或分析時，胡亂地把你上文中提到的不相關細節(jié)關聯(lián)起來，得出一些南轅北轍的奇怪結論。
• 忘記前序指令： 忘記了對話早期你對它的回答要求（比如不要濫用比喻句式），但隨著你自己使用了類似比喻的文風后，又開始犯軸。

——1M 上下文的 Gemini 2.5 Pro，基本在 tokens 量來到 4w 左右時，會反映為推理緩慢，質量開始有所下降。

是的，最大上下文窗口 ≠ 最佳注意力窗口。

有個專門術語來描述這個普遍的負面模型現(xiàn)象：Context Rot，上下文腐爛。

如同人類在信息過載時會思維混亂，而過長的、充滿干擾的上下文，同樣會顯著降低模型的推理能力。

而模型性能下降（上下文腐爛，context rot）的三大因素如下：

1. 1.Context 輸入越長 → 注意力被稀釋。
2. 2.問題與關鍵信息的語義相似度越低 → 模型越難匹配到答案。
3. 3.關鍵信息與周圍干擾內(nèi)容的語義相似度越高 → 干擾增強，模型難以分辨。

這三個因素會相互放大，導致性能顯著下降。

PS：反過來，控制 Context 長度、減少 Context 中的干擾項數(shù)量、提升問題與 Context 中有效信息的相似度，就能夠提升 Agent 的處理效果

這三大因素來自于 Chroma 團隊（打造了目前全球最主流的開源向量數(shù)據(jù)庫之一）名為《Context Rot》的同名實驗研究。

實驗研究古法人工濃縮如下，個人覺得會對測試 AI 產(chǎn)品有一些實用啟發(fā)。（比如測試較佳 context 長度）

如果覺得太長，也可以下滑到本段小結～

? Chroma：探究上下文對模型性能影響的關鍵要素

他們設計了一套實驗，來測試影響 LLM 長上下文性能表現(xiàn)的因素：

在傳統(tǒng) NIAH（Needle in a Haystack：即 LLM 大海撈針測試）基礎上，進一步拓展任務難度，考察大模型的語義理解層面的撈針能力，而非直接詞匯匹配。

傳統(tǒng) NIAH 任務，是評估模型長上下文能力最廣使用的基準之一：

將一個隨機事實（針信息），放在較長的上下文（干草堆）中，通過直接問答，要求模型回答某個針的信息 ，比如：

干草堆：[大量無關文本]

藏在干草堆的針信息：“我從大學同學那里得到的最好的寫作建議是每周都要寫作?！?/p>

問題 Prompt：“我從大學同學那里得到的最好的寫作建議是什么？”

此時，模型被期望能從大量干草堆中，直接找到針信息，并回答“每周都寫作”。全程無需間接推理信息，直接根據(jù)已有信息回答即可。

傳統(tǒng) NIAH 雖然很有效地考察了 LLM 的大海撈針能力，但實際問答場景往往不會如此直接清晰：

• 一方面，需要 LLM 處理“針-問題”之間的模糊語義：“我周末去了動物園，并在那里喂了長頸鹿。”，那么問題“動物園里有什么動物”
• 另一方面，真實的上下文中，往往充滿了容易誤解的干擾項。比如，“我從我大學教授那里得到的最好的寫作建議是每天寫作”，就會對上文“大學同學的寫作建議”形成干擾（就如人類讀一篇文章很快、很長時，也容易記錯細節(jié)）

  
  

Chroma 團隊實際上，也注意到了這一點，并拓展了 4 種不同 NIAH 任務：

1. 1.“針-問題對”相似度測試：構造不同語義理解難度的問題，測試不同 context 長度對回答的影響
2. 2.干擾項測試：設置“不同的數(shù)量 + 不同的放置位置”的干擾項，測試不同 context 長度對回答的影響

1. 3.“針-干草堆”相似度測試：當針信息與上下文的向量語義逐漸接近時，測試不同 context 長度對回答的影響
2. 4.上下文文本、段落結構測試：測試相同內(nèi)容含義時，邏輯連貫的結構與雜亂顛倒的結構，是否對模型推理性能有所影響

看完整體測試過程，我也總結了一些有助于理解 context 工程價值的現(xiàn)象：

1. 1.無論如何，context 長度增加時，模型完成同樣任務（即使很簡單）的能力都會下降
2. 2.針與問題之間的語義關系越難理解（相似度低），受 context 長度影響越大；且這種下降在長輸入時會被顯著放大。

   而 Context 長度較短時，模型對低相似度的問題，有更高的處理成功率

3. 3.context 越長，干擾項對模型的影響也會加劇
4. 4.針與干草堆的內(nèi)容，在語義上越接近（主題越相關），模型識別針的能力越差。 如果針在語義上與周圍內(nèi)容格格不入（邏輯不連續(xù)、主題突兀），模型反而更容易識別。就像人玩找茬游戲，對突兀的信息更敏感。

   難：在 10 篇“寫作建議”文章中找“最佳寫作建議是每周寫作”

   易：在“量子物理、烹飪、園藝”文章中找“最佳寫作建議是每周寫作”

小結：當 AI Agent 在多輪推理和更長的時間線上運行時，模型必然會面臨越來越多的 context rot 因素。

冗余的上下文將大量占用模型的思考空間，顯著降低其完成復雜任務的思考能力。

而上下文工程（Context Engineering）誕生的實質，正是在探究哪種上下文配置，最有可能引導模型輸出我們期望的結果，獲取更好的任務效果。

3?? 有效開展 Context 工程的方法

AI Agent 發(fā)展至今，已經(jīng)越來越能夠在多輪推理和更長的時間內(nèi)運行。

這些不斷在“思考-行動-觀察”中循環(huán)運行的 Agent，會在運行中不斷產(chǎn)生、積累更多對下一次循環(huán)有影響的上下文數(shù)據(jù)

（包括系統(tǒng)指令 system prompt, 工具調(diào)用 tools, MCP, 外部數(shù)據(jù), 對話歷史 message history 等）

為了避免模型性能的下降，這些數(shù)據(jù)必須被 context 工程動態(tài)優(yōu)化：

唯有效的 context 才配占據(jù)有限的上下文窗口資源。

Anthropic《Effective Context Engineering for AI Agents》：圖解 Agent 開發(fā)中，context engineering 的起效形式

想要實現(xiàn)有效的 context 工程，大體上分為三類策略：

策略之一，從寫好 System Prompt 開始

我們依舊可以從更熟悉的模塊開始學習——通過 Prompt 工程，設計清晰、簡單直接的系統(tǒng)提示。

有效的上下文，始于清晰的指令。

如果 Prompt 過于具體，使用大量示例、if-else 類的要求，則會使得模型更加僵化，缺乏處理意外情況的能力；

而 Prompt 如果要求過于模糊，或缺少足夠的背景信息，則會無法對模型輸出進行可控管理。

在 Agent 運行過程中，每一輪推理所產(chǎn)生的部分 context（工具調(diào)用返回結果、Chat 回應等） ，也需經(jīng)由 Prompt 引導其如何輸出和被精煉（Kimi 那類 Model as Agent 的路線不在此列），方可具備一定的可預測性與管理意義。

以下是一些經(jīng)過實踐檢驗、能顯著提升模型表現(xiàn)的提示詞編寫原則：

• 啟發(fā)式引導：系統(tǒng)提示 System Prompt 應當足夠靈活地為模型提供啟發(fā)式引導，使其既能具體地輸出所需的結果，又能泛化應對各類邊界情況。

  比如「利用 LLM，評估事情的重要性」：

  評估事情的重要性。比如，在 1 到 10 的刻度上，其中 1 是完全世俗的（例如，刷牙，整理床鋪）和 10 是極其深刻的（例如，大學錄取、結婚）

• 結構化提示：AI 更容易讀懂未經(jīng)精排的提示詞了，但結構化提示方法依然值得被適度應用。

  使用 或#式的 XML 標簽 / Markdown 語法，分割不同指導作用的提示詞。
  雖然隨著模型能力提升，LLM 對復雜糅合的 Prompt 理解能力有所提升，但結構化提示詞，依然有助于提升模型些許性能。

  更重要的是，大幅簡化人類工程師理解、維護 Prompt 的難度。

• 先用聰明模型寫一版最小化提示：

  寫第一版提示詞時，記得先用你能用到的最聰明模型，寫出能大致滿足要求的最小化 Prompt。

  （只有這樣，你才能知道當下 AI 的能力邊界，區(qū)分哪些是 Prompt 的問題，哪些是模型智力問題）

  最小化 Prompt 意味著用最少的提示信息量，優(yōu)先定義“有什么、做什么”，而不是“怎么做”——把我們的提示詞設計“最小化”。（詳見：）

  
  

  
  

  根據(jù) Prompt 測試過程中發(fā)現(xiàn)的問題，迭代必要的指令細節(jié)、few-shot，優(yōu)化生成效果。

  最終再遷移到最終的生產(chǎn)模型，完成細化。

• 精選最小可行的 Agent 工具集：為 Agent 準備的工具，應當是自包含、能被 LLM 充分理解，且工具之間功能重疊少的。
• • 自包含：工具自身包含了特定任務所需的所有邏輯和功能，不需要頻繁訪問外界或配合調(diào)用其他工具，即可完成任務。
  • 能被 LLM 理解、使用：如果人類都不能準確描述何時使用什么工具、如何用調(diào)用，就不要指望同樣依賴文本生成的 LLM 能夠調(diào)用好工具。

• 謹慎在 Prompt 中添加示例！

  是的，我不喜歡濫用 few-shot。過度 few-shot 提示，往往會使得 AI 生成風格容易陷入僵化。

• 一般來說，個人會盡量避免在推理模型中使用 few-shot。

  Anthropic 團隊也同樣分享了他們的觀點：

  Few-shot 是非常有效的 AI 提示實踐，但要著重避免在 prompt 中塞滿過多邊緣例子，應該設計一組足夠多樣化、規(guī)范的核心例子，有效展現(xiàn) Agent 的預期行為。

  （一些不好的 system prompt ，甚至會不給出準確、完備的背景信息、目的描述，就在那通過塞一堆“示例”，強行矯正表現(xiàn)不佳的測試結果。

  答應我，千萬別學這個！

• 不然，越是開放的復雜任務下，模型泛化越是不堪直視，回答形式也極其僵化……比如虛擬陪伴）

別忘了，system prompt，本身就是最小化的初始 context。

一個清晰、高效的 prompt，能夠用最有必要的 tokens，為后續(xù)推理交互提供重要的方向指引。

策略之二，即時上下文，讓 Agent 像人一樣地獲取上下文

考慮到在真實使用 AI 時，一方面上下文窗口有限，不可能把所有的相關 context 都塞進去。

另一方面，以往在推理前的階段采用 embedding-based 檢索的方案，常常會檢索到很多“可能相關但實際沒用”的內(nèi)容。

所以，現(xiàn)在越來越多的 AI 應用，開始采用 AI 自主探索的即時上下文方案：

• 與人類「整體回憶-深入回顧某段記憶細節(jié)-最終推理得到結論」的多步思考一樣，其實沒必要要求 Agent 在推理時，一次性回憶所需的全部上下文

• 像 Cursor 等 AI Coding 工具，就會按照用戶需求，先翻閱項目文件夾中的 readme.md，了解項目文件結構 → 在 /resource/pic 目錄找圖片、到 /component 目錄找組件代碼等。

  在這個過程中，Agent 自主導航與檢索信息，動態(tài)獲取所需信息到上下文窗口中。
  （對應的，人類會先回憶自己的待辦記在哪個備忘錄、日歷中，在到對應軟件中翻閱記錄，為大腦的上下文窗口實現(xiàn)動態(tài)掛載與減負。）

• 此外，即時上下文方案，也有助于漸進式披露上下文，為后續(xù)工作提供參考記憶。

  即使是每一次 Agent 檢索所獲取的文件名稱、大小、文件創(chuàng)建時間，這些信息也都有助于 Agent 在后續(xù)推理中，判斷信息的相關性與價值（命名規(guī)范暗示用途；文件大小暗示復雜性；創(chuàng)建時間可以作為相關性參考）（可以讓 Agent 自行記錄 memory 筆記，將這些工作記憶摘要與持久化。）

當然，請記得權衡即時上下文探索，與向量檢索/直接拼入context 等簡單方案的耗時與效果。

策略之三，為超長程任務，實現(xiàn)無限上下文

雖然模型發(fā)展必然會帶來更大的上下文窗口…

但如 Chroma 的 Context Rot 研究，無論如何，無關的 Context 占用上下文窗口時，必然會影響模型性能。

在當下的時間節(jié)點，Agent 的智能幾乎與一次性自主運行時長掛鉤。

AI Coding 中的代碼重構任務、Deep Research 任務等，往往會運行數(shù)十分鐘及以上，其產(chǎn)生的 context 必然會遠超出模型的上下文窗口限制。

為了保障此類長程任務的連貫性與目標達成，Anthropic 團隊引入了專門的上下文工程設計，在框架層面解決上下文污染與限制問題：

1）壓縮（Compaction）

最直接的思路，是在上下文接近窗口限制時，把對話內(nèi)容“有損壓縮”，拋棄冗余無用的歷史信息，并重新開啟一個新的上下文窗口。

僅保留核心決策與細節(jié)（比如整體計劃決策、執(zhí)行過程錯誤和實現(xiàn)細節(jié)），以實現(xiàn)在新對話窗口的連貫性。

• 方法： 讓模型觸發(fā)一個“總結”動作，提煉歷史對話。

  以 Claude Code 為例，模型會保留開發(fā)架構決策、未解決的錯誤和關鍵實現(xiàn)細節(jié)，同時丟棄冗余的工具輸出或過于細枝末節(jié)的消息。

• 工程調(diào)優(yōu)思路： 用于壓縮的 prompt，可以先以「最大召回率」 為目標進行編寫，確保能從歷史中提取所有相關信息；然后再迭代提示詞，逐步消除總結中的冗余內(nèi)容，提升壓縮精度。

2）結構化筆記（Structured Note-taking）

當下，越來越多的 Agent 應用采用了這種外部 memory 策略，例如 Manus 等通用 Agent 的 todo.md，MemU 等記憶框架的 memory 策略，均屬于此列：

1. 1.Agents 定期把重要記憶（如中間結論、待辦事項、用戶畫像、用戶活動）寫入到可供 Agent 讀寫的外部筆記文件
2. 2.在后續(xù)推理執(zhí)行過程中，按需將記憶拉回上下文窗口。

能夠以極小的上下文開銷，進行持久化記憶。

我之前在測試 Browser-use Agents 的 2048 游戲最高分時，也將「在每一步游戲操作后，自行反思并記錄心得與教訓」作為 Agents 的 system prompt。

AI 在游戲過程中，就會額外記錄結構化筆記，指導 AI 在新一輪游戲的操作決策，改進游戲得分。如：

- 心得 1：固定一個角落放最大塊（常用底部左/右角），盡量不要把它移出該角” - 心得 2：盡可能往同一個方向合并數(shù)字方塊

3）多智能體架構（Multi-Agents Architectures）

這是一種更積極的“分而治之”的架構思想。

將一個復雜任務分解到多個子智能體，讓專門的 Agent 專注于自己的任務與所需記憶空間，最后由一個主 Agent 在更高維度協(xié)調(diào)整體的任務計劃。

每個子 Agent 的上下文壓力都會小很多，模型性能能夠發(fā)揮的更徹底，不易 context rot。

例如，Manus 所推出的 Wide-Research 功能，就采用了類似方案，有興趣可以去試試看。因為是并行架構，所以能夠在單位時間內(nèi)開展更加廣泛、深入的 Deep Research 研究或其他復雜任務。

至此，

• 壓縮適合多輪對話交互任務；
• 結構化筆記記錄適用于持久化保存工作記憶；
• 多智能體架構則方便分解復雜任務，緩和單 Agent 的上下文壓力。

可以根據(jù) Agent 應用的類型和復雜度靈活組合，共同為超長程任務實現(xiàn)無限上下文，提供切實的可能。

4?? 總結： 精心設計你的 Context 工程

回顧上文，system prompt 編寫、即時上下文檢索、上下文架構管理，一切討論的錨點，最終都回歸到了 context 工程的核心：

找到以最小 tokens 集合，最大化引出期望 AI 結果的策略。

Context 工程本身并不神秘，只是隨著 AI Agent 架構日趨復雜、健全的自然工程發(fā)展。

理解了超長上下文如何影響 LLM 的性能表現(xiàn)，和 Agent 內(nèi)的上下文記憶運作機制，我們才能更好地開展有效 context 工程。

最后的最后，請務必、務必，把上下文窗口視為有限的資源。

Ref：

• Effective context engineering for AI agents｜By Anthropic：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Managing context on the Claude Developer Platform｜By Anthropic：https://www.anthropic.com/news/context-management
• Context Rot: How Increasing Input Tokens Impacts LLM Performance｜By Chroma：https://research.trychroma.com/context-rot

? 梳理：Anthropic 界定的 Agent 類型

Anthropic 分享了他們過去一年里，與數(shù)十個團隊、客戶合作構建智能體時，總結下來的實用建議。

關于智能體的定義劃分，往往在 workflows 和 agents 中有所混淆。Anthropic 將其統(tǒng)稱為 agentic systems，智能系統(tǒng)：

• 工作流 Workflow：把 LLMs 和工具通過代碼，預編排好執(zhí)行路徑的規(guī)則流程。
• AI 代理 Agent：由 LLMs 自主指導其執(zhí)行過程和工具使用的自主系統(tǒng)。

• 無硬性規(guī)定與優(yōu)劣，應當以解決問題為目標出發(fā)，可以用多種類型進行組合。
• 最小化設計原則，如無必要，無增實體。從簡單提示與優(yōu)秀模型開始，實驗并構筑第一個版本的「Agent」。只有智能不足時，才考慮調(diào)優(yōu)工程，添加更多步驟與 Context 指引。
• 請注意 Agent 的可解釋性與維護性，不可解釋的 Agent 無法維護，無法維護則無法針對生產(chǎn)環(huán)境的各類問題進行工程調(diào)優(yōu)。所以請保持 Agent 的規(guī)劃步驟的透明度

以下是 Anthropic 總結的 workflow 與 Agents 類型，可能為你帶來一些參考啟發(fā)：

Workflow

增強型 LLM（the augmented LLM）

• 給 LLM 配上檢索、工具、記憶等增強功能，LLM 可以主動使用，生成自己的搜搜查詢、選擇合適的工具。
• 和 Agent 的區(qū)別是，增強型 LLM 不會規(guī)劃任務流程，也無法自行決定下一步做什么，不能自主進行多輪交互。

• 提示鏈工作流（Workflow： Prompt Chaining）
• • 通過將任務分解為多個子環(huán)節(jié)，由多個 LLM 分別處理前一個環(huán)節(jié)的輸出，就像 coze、dify 一樣。
  • 示例應用：營銷文案生成 → 翻譯為其他語言；文章大綱生成 → 檢查 → 分段完成正文編寫

• 路由式工作流（Workflow：Routing）
• • 允許 LLM 分類 input，并在更合適的子任務中解決?？梢詫Σ煌愋偷娜蝿者M行分別的提示優(yōu)化，不會干擾其他任務的表現(xiàn)
  • 比如：AI 客服、Chatbot 自主切換回答模型（簡單問題就切換到小模型，類似 ChatGPT 5 網(wǎng)頁服務，優(yōu)化成本和響應速度）

• 并行式工作流（Workflow：Parallelization）
• • Sectioning：在與用戶對話時，一個模型負責處理用戶意圖，一個模型篩查問答中不適當、不合規(guī)的內(nèi)容。
  • Voting：代碼 or 內(nèi)容審計，通過不同模型/不同提示，從不同方面對內(nèi)容進行評估，甚至通過投票閾值來過濾假陽性。
  • 并行式有兩種應用角度，一是分治可并行的獨立子任務；二是多次運行同一任務獲取多樣化結果 or 進行投票
  • 什么時候使用效果更好？1）提升任務執(zhí)行性能；2）LLM 同時處理多因素任務是困難的，分解為單因素單個模型處理，會更好
  • 比如：

• 協(xié)調(diào)-執(zhí)行式工作流（Workflow：Orchestrator-Workers）
• • 中央 LLM 分解任務（相較并行式更靈活，子任務不是預先定義的），工作者 LLM 分別執(zhí)行，返回結果，綜合輸出。
  • 示例應用：對多個文件進行復雜更改的 coding 產(chǎn)品， 分解需要從多個來源收集信息的 search 任務等。

• 評估-優(yōu)化式工作流（Workflow：Evaluator-Optimizer）
• • 何時使用？——當人類清晰地表達其反饋時，LLM 的響應可以明顯改進；其次，LLM 能夠提供這種反饋
  • 比如：Search 場景、多輪文學創(chuàng)作與編輯（Evaluator 對多輪生成內(nèi)容，進行綜合反饋與建議）

Agent

Anthropic 把 Agent 定義為：LLMs autonomously using tools in a loop.

• 通常指自主智能體，不斷基于環(huán)境反饋的循環(huán)使用工具。能夠理解復雜輸入，推理與規(guī)劃，以及從錯誤中恢復。（通常會包含最大迭代次數(shù)，控制 Agent 行動何時終止）
• 常見的 Computer Use、Coding Agent 均在此列
• 隨著底層模型能力的提升，Agent 獨立解決復雜問題、處理錯誤反饋的能力也會隨之提升

Ref：

• Building effective agents｜BY Anthropic：https://www.anthropic.com/engineering/building-effective-agents

反思：止損線，亦是起跑線

“在抵達下一個階段之前，這就是我探索愿意投入的、輸?shù)闷鸬拇鷥r?！?/p>

發(fā)現(xiàn)自己在涉及到需要長期投入的重大決策時（如職業(yè)選擇、親密關系等），容易過度“憂慮未來的最終結果”。

導致因為畏懼遠期回撤心理，不自覺地壓抑當下的機會、幸福感，最終決定放棄對自己現(xiàn)階段更有價值的行動。

比如：

• 憂慮某個商業(yè)模式、變現(xiàn)機會能走多遠，導致面對送到手上的機會時，遲遲不敢下注。
• 因過度追求構建“長期可靠”的關系，而忽視在當下接觸到的人，就無法通過一段段交織的關系，成長為更好的自己。

被評價“這個人想得清楚”，看起來是件好事。但有時也會因為猶豫，錯過一些機會。

很難區(qū)分保守與激進、深思熟慮與開放靈活，孰對孰錯。

但重點在于，決策的第一步不僅僅是靠直覺、喜好，而是先明確自己當下最需要解決的問題是什么，盤算清自己愿意押注的籌碼底線。

比如現(xiàn)在有多少儲蓄，現(xiàn)在來看，最多愿意設置 xx 時間、金錢的止損線。再次之前要盡情探索自己創(chuàng)業(yè)可能性，到了止損階段后，即使回去上班，自己也能接受。

過度憂慮未來、不預分配當前階段的籌碼，混亂地做出“明智、保護自己”的投資，是對流向自己的機會的不尊重。

——未來是很重要，投注成本是很珍貴，但也請多多珍惜當下。