Agent複雜度演化

Properties2
tags狀態/草稿
aliasesAgent 複雜度演化, AI Agent 演化階段, AI Agent 複雜度升級路徑, Agent 升級路徑, Agent Maturity Model, Agent 複雜度演化路徑

閱讀時間約 18 分鐘

Agent複雜度演化

一句話定義

AI Agent 系統從最小 API Call 一路長到複雜工業系統的縱向時序視角——把 Augmented-LLM / Agent / Sub-Agent / Context-Engineering / Agent-Memory / 可觀測性等技術按何時應該引入重新排列；補位 Agent > 自主程度光譜（從固定到完全自主）「該用哪個 pattern」的橫向選型，提供「任務從小變大時該按什麼順序升級」的時序視角。核心紀律 = 「不需要一上來就優雅，千萬不要讓優雅變成你 AI 系統設計路上的絆腳石」（2026-05-02-Agent神文沒告訴你的事）。

核心命題：AI Agent 是非確定性系統

為什麼複雜度演化是 vault 必須獨立成頁的視角，而不是傳統軟體架構決策的特例：

  • 傳統軟體：先把架構設計好（如後端 Docker 模塊規劃完整）最多前期慢一點，不會出大事——確定性系統下「先優雅」是低風險。
  • AI Agent：本身是非確定性系統，在它上面再搭一層精緻架構等於是在不確定性上再疊加一層不確定性。
  • 典型反例：把「一句話總結成一句話」直接上 Plan-and-Execute → 任務沒變複雜，但鏈路先變複雜了；不是 AI 不行，是路被走複雜了。
  • 由此衍生的核心紀律：只在被逼到該升級時才升級——每個階段對應一個明確的觸發信號，沒到信號就不要升級。

7 個自然成長階段（縱向時序視角）

取自 2026-05-02-Agent神文沒告訴你的事 作者構建影片 AI Agent 的全程踩坑路徑；表格按「該升級到本階段的觸發信號」排序。

階段升級觸發信號對應 vault 概念不該做什麼
0. API Call一句話可解；輸入確定、輸出一次性給Augmented-LLM 的 LLM 部分不要為了用 Agent 而用 Agent
1. Workflow多步驟但中間不需用戶介入（一鍵跑到底）Prompt-Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer多步驟 ≠ Agent
2. 對話 Agent(a) 流程必須讓人參與；或 (b) 功能選項多到前端會指數型增長Agent不要選最強最複雜的框架（如 LongGraph）；先用集成度高的 SDK 跑 baseline
3. 加工具Prompt 已經到頂仍做不好——任務本身需要的能力沒有（要參考網上資料但拿不到 / 要寫可用代碼但無法驗證）Augmented-LLM 的 tools 部分在這之前不要再去改系統提示詞
4. Context Engineering工具加到 3-4 個後 Agent 持續性變差——不是偶爾失敗，是越做越亂、注意力被平均分散Context-Engineering / Sub-Agent不要在工具還少時就上下文隔離
5. Memory（指針傳遞）需傳遞不能改動的長內容且該內容跨 sub-agent 共享Agent-Memory不要讓上層 agent 把代碼當 output 再吐一遍（為複製貼上付費 + 模型不擅長機械複製）
6. Observability（Trace）系統有 sub-agent + 上下文隔離 + memory 後 debug 困難，需評估「哪裡做得好 / 差」（vault 觀察清單）不要只存結果——要存過程（工具調用順序、每步 token、未用到的上下文、不該給執行者的信息）

每階段的關鍵紀律

不是在介紹技術，而是在標註「何時是上這個技術的時機」。

階段 0 → 1：多步驟 ≠ Agent

  • 多步驟 + 中間不需用戶介入 = 確定性流程 → 用 chain workflow（N8N / Diffie / 純 Prompt-Chaining 編排都夠）。
  • 「用戶不需要在中間反覆參與，那你大概率不需要對話 Agent」是該階段的核心判斷指標。

階段 1 → 2：對話 Agent 的兩個觸發信號（明示判斷準則）

  1. 流程必須讓人參與——不管是被動（模型能力達不到，需人指導）還是主動（需要人的偏好）
  2. 功能選項多到前端會指數型增長——不能或不想為每種功能加單獨前端時，才需要對話 Agent 作為通用入口

飛機駕駛艙反例：每出現一種新需求就加一個按鈕（一鍵重做 / 一鍵改風格 / 一鍵改顏色 / 一鍵換模板…）→ 最後產品變成飛機駕駛艙。

階段 2：選型陷阱——「複雜架構誘導你瞎設計」

  • Workflow 長鏈 vs 對話 Agent 長鏈是兩種長鏈：
    • Workflow 長鏈一鍵跑到底 → 需任務分發、重試、佇列調度、並發恢復
    • 對話 Agent 長鏈可被人切開 → 整體仍長、但每次真正執行的片段可以很短 → 不需要重型調度系統
  • 複雜架構（如 LongGraph）的副作用：誘導你還沒跑任何東西就開始設計節點 → 像閉門造車，車輪畫得再遠路多寬都不知道。
  • 紀律：即使選了複雜架構（不是錯的），至少要用它最簡單的用法跑出 baseline——知道任務底線在哪，再決定加節點 / 加複雜編排。

階段 2 → 3：Prompt 何時轉向加工具

  • Prompt 第一版：不要寫複雜說明書 → 從沒有限制條件的版本開始 → 看它怎麼做 → 不斷加限制（更格式化 / 哪部分多思考 / 提供例子）。
  • Prompt 已經到頂仍做不好的判斷：「很多時候它做不好不是系統提示詞寫得不夠好，而是這個任務本身需要的能力它根本就沒有」→ 正確動作不是再改 prompt，是加工具。
  • 對位 Prompt-Engineering。

階段 3：加工具的「湧現」與失控前的甜蜜期

  • 3-4 個工具加上去後，Agent 開始自己想清楚該用哪個工具，甚至開始把工具串起來用——典型 1+1>2 湧現。
  • 重要紀律：在這個階段「還沒做什麼複雜架構」——還沒引入規劃、系統提示詞還是最基礎版本——Agent 已經 work。

階段 3 → 4：上下文失控的具體現象

  • 不是偶爾失敗，是性能持續性變差——成功率下降、準確率忽高忽低、聽不懂人說話、越做越亂。
  • 不是模型不行，是上下文的注意力犧牲——工具一多 + 任務複雜 + 歷史對話 + 代碼 + 圖片各種信息一股腦塞進 → 太多太散，注意力被平均分散。
  • 這時才真正需要 Context-Engineering。

階段 4：上下文隔離有意義的條件

  • 不同任務需要不同上下文才有意義——例：設計任務需要大量開放發散的信息（風格 / 版式 / 元素 / 氛圍），寫代碼任務需要盡量少且精確的信息（接口 / 格式 / 正確性）；混在一起會相互污染上下文。
  • 規劃者 / 執行者結構：頂層規劃者調度下面執行者，執行者只負責專項任務、只看到自己需要的那一小撮必要信息。
  • 關鍵紀律：「如果 sub-agent 和頂層規劃者看到的上下文是一樣的，那這樣的 sub-agent 就完全沒有意義」——上下文隔離不是把 sub-agent 加上去就成立，而要實際做到信息範圍不同。對位 Sub-Agent。

階段 4 → 5：Memory 從優化項變必需品的時刻

  • 撞牆問題：用戶給段代碼希望改 → 規劃者看到代碼但不寫代碼，需把任務交給執行者 → 怎麼把代碼百分之百原封不動傳過去？
  • 「規劃者 output 一遍給執行者」的兩個糟糕後果：
    1. 為複製貼上付費：純 copy paste 卻消耗大量 output token（input → output 純複製，且 output token 比 input 貴）
    2. 無法保證一字不差：模型不擅長機械複製，很可能順手改一個明顯的 bug（如把錯誤標點改正確）——但用戶本來就是要修 bug，bug 在還沒傳到執行者就被解決了——這在很多場景下是災難性的
  • Memory 真正動機：「有些信息我只想存著，而不是讓模型反覆讀寫」。
  • Memory = 傳遞指針而非內容：規劃者把代碼寫到文件系統 → 告訴執行者文件名 → 執行者讀內容改代碼。對位 Agent-Memory。

階段 5：內存 vs 外存的直白定義

  • 內存 = 這輪對話結束就消失
  • 外存 = 多輪對話都拿得到的東西
  • 「這不是兩種神秘的能力，本質上就是說我需要做一個決定，這個東西存在哪兒、存多久」
  • 為什麼有差別：只對這輪有用的信息寫到外面會變噪音 / 污染下一輪；必須跨輪保存的信息（如 Claude-Code / Cursor 的 To-do list 引入外部狀態告訴 AI 走到第幾步）才該進外存。
  • 紀律：「順序永遠都是你走到這個階段、發現不用不行了你才用」。

階段 6：Observability（Trace）

  • 系統複雜後 debug 難 → 需要評估「哪裡做得好 / 差」。
  • 唯一答案：把每次運行的全過程全部存下來——存的不是結果，是過程：
    • 用了哪些工具
    • 工具調用的順序
    • 每步消耗多少 token
    • 哪些上下文根本沒被用到
    • 哪些信息不應該給到這個執行者
  • 回讀這整個流程的價值：才會知道怎麼把任務規劃到更快、token 用得更少、成功率更高。
  • 該議題 vault 暫時只有此一來源，未獨立成頁（列入觀察清單，等 trace / debug / observability 第二來源再評估）。

元命題：「畢業設計圖紙」與閱讀紀律

對位 Anthropic「Building Effective Agents」 與 LlamaIndex Context Engineering 等成型文章的閱讀紀律。

  • 作者親身踩坑：抄 Anthropic 兩篇神文做架構升級（系統提示詞 / 上下文隔離 / memory）→ 整個系統變得更爛：token 花費更高、效果沒變好、失敗變多、且很多失敗無法 debug。
  • 核心比喻：「這些比較成型的文章更像是一個畢業設計的完整圖紙——當你已經做過中間所有的實驗、踩過坑、回頭看的時候，你會發現，它其實設計得很完美。但是如果你第一天就直接照著畢業設計施工，大概率連第一根樑你都溜起來了。」
  • 閱讀紀律：神文不是錯的，是閱讀時機錯了——應該按本頁的 7 階段路徑往下走，每階段被逼到對應觸發信號才回頭讀對應的神文段落。

與其他概念的關係

  • 與 Agent > 自主程度光譜（從固定到完全自主） 的互補：既有光譜是橫向 pattern 工具箱（你的任務該用哪個 pattern），本頁的 7 階段升級路徑是縱向時序視角（你的任務從小變大時該如何升級）——兩者互補而不取代。
  • 與 Anthropic「Building Effective Agents」 「先用最簡單的解法，只在必要時增加複雜度」原則的關係：本頁是該原則的個人實戰具體化——把「必要時」拆成 7 個明確觸發信號，並用「抄了反而更爛」的反例證明該原則的反面後果。
  • 與 Prompt-Engineering 的關係：階段 2 → 3 的「第一版不要複雜說明書 / 從無約束逐步加約束」是 prompt 寫作策略；該頁的「散彈 → 收斂 → 變體」迭代範式是並列具體做法。
  • 與 Context-Engineering 的關係：本頁標出「Context Engineering 不是 day 1 就該上」的時機門檻——階段 4 才該上；該頁的「容量在 100% 之前已劣化」「Compact 不能恢復品質」是技術層紀律，本頁是時機層紀律。
  • 與 Agent-Memory 的關係：本頁的「指針傳遞取代複製貼上」場景是 memory 從優化項變必需品的時刻；該頁的 C = (P, M) 演算法形式 + OpenCode memory_search / memory_get 工具拆解是技術細節。
  • 與 Sub-Agent 的關係：本頁的「主 / 副 agent 看到一樣 context = 毫無意義」紀律是該頁「自主壓縮 / 鋸齒狀 context 曲線」技術描述的有效性前提條件。
  • 與 Harness-Engineering 的關係：harness engineering 是架構的工程化載體（怎麼把 agent 馬具設計好），本頁是何時開始裝載某段馬具的時序紀律——兩者在不同抽象層。
  • 與 Augmented-LLM 的關係：階段 3 加工具的「3-4 個湧現」現象是 augmented LLM 從 0 到 1 的具體經驗點。

相關來源

備註

建頁理由：vault 既有 Agent > 自主程度光譜（從固定到完全自主） 是橫向的 7 級 pattern 表（按「控制權移交」分類，回答「該用哪個 pattern」）；本片明確把同一 cluster 的工具按時序成長重新排列（回答「任務從小變大時該按什麼順序升級」）——這是 vault 缺失的縱向視角。

獨立成頁的密度依據：(a) 與 Agent / Context-Engineering / Agent-Memory / Augmented-LLM / Sub-Agent / Anthropic / Prompt-Engineering 7 個既有頁實質連結；(b) 主來源時長 19 分鐘 + 7 個明確觸發信號 + 多重元命題，內容密度足以獨立成頁；(c) 未來若有更多「踩坑後才知道」類來源（其他工程師 blog / 社群分享），本頁是合適歸宿。

未來累積方向：(a) 該演化路徑在不同領域 agent 上的具體形態差異（影片 agent / coding agent / 客服 agent / 研究 agent …）；(b) 「回退路徑」——什麼時候該砍掉 sub-agent / 上下文隔離 / memory 重新精簡；(c) trace / observability 議題單獨成頁的觸發條件；(d) 與 Harness-Engineering 的進一步整合——harness 設計的「裝載時機」軸；(e) 「畢業設計圖紙」反例的更多案例累積（其他被誤抄的成型架構文章）。

反向連結