2026-05-02-Agent神文沒告訴你的事

那些 Agent 神文沒告訴你的事：照著做，系統只會更爛

後設資料

• URL：https://www.youtube.com/watch?v=b_9D7T0n4RA
• 媒體：YouTube 影片（中文 / 簡體；個人頻道作者開發影片剪輯類 AI Agent 的踩坑實錄）
• 作者：未明示（自述「我們這個頻道」但無具名；自述身份 = 影片創作者 + AI Agent 開發者）
• 發表日：未明示；引用 Anthropic「最新兩篇 AI Agent 文章」（推測 = Building Effective Agents 2024-11 + Context Engineering 2025）；推測 2025 下半
• 語言：簡體中文（口述）
• 內容形式：純口述自白式踩坑分享，本頁保留 YouTube 自動字幕逐字稿（含時間戳）作為原始性記錄；要點段落改寫為可讀版本
• 全長：約 19 分鐘

一句話濃縮

「AI Agent 的設計不是傳統軟體設計——AI Agent 本身就是非確定性系統，在它上面再搭一層精緻架構等於在不確定性上再疊加一層不確定性」——作者把自己構建影片 AI Agent 的全程拆成 7 個自然成長階段（API Call → Workflow → Agent → 加工具 → Context Engineering → Memory → Observability），每個階段對應一個明確的觸發信號（一句話總結 → 多步驟但中間不需用戶介入 → 功能選項指數爆炸 → 上下文失控 → 大塊只讀內容傳遞 → debug 困難），核心紀律 =「不是這些架構不夠優雅，而是你不需要一上來就優雅；千萬不要讓優雅變成你 AI 系統設計路上的絆腳石」。本片是 vault 中第一份從踩坑路徑反推「何時升級到下一階段」的來源，與 Agent > 自主程度光譜（從固定到完全自主） 的橫向 pattern 分類形成縱向時序視角的互補。

提取要點

反直覺的開場：AI Agent 是非確定性系統，複雜架構是在不確定性上再疊加不確定性

• 作者抄 Anthropic 兩篇神文（2026-04-28-Anthropic-Building-Effective-Agents / 2026-04-28-LlamaIndex-Context-Engineering）做架構升級——上系統提示詞、上下文隔離、增加 memory、優雅的系統架構設計——結果整個系統變得更爛：token 花費更高、效果沒變好、失敗變多、且很多失敗無法 debug。
• 核心反直覺：傳統軟體設計裡「先把架構規劃好」最多是前期慢一點不會出大事；AI Agent 不一樣，它本身是非確定性系統，精緻架構在不確定性上再疊加一層不確定性。
• 典型反例（作者親身）：只是想把一段話總結成一句話 → 直接上 Plan-and-Execute 模式 → 原本一個 API Call 能完成的事被拆成「先計畫再執行」→ 任務沒變複雜，但鏈路先變複雜了。「不是 AI 不行，是你一開始就把路走複雜了。」

7 個自然成長階段（核心結構）

本片不是教你設計圖紙，是教你「問題到底是怎麼被逼著長大的」——每階段對應一個明確的升級觸發信號，沒到那個信號就不要升級。

階段	升級觸發信號	不該做什麼
0. API Call	一句話可解；輸入確定、輸出一次性給	不要為了用 Agent 而用 Agent
1. Workflow	多步驟但中間不需用戶介入（一鍵剪輯：上傳 → 字幕 → 判斷 → 剪輯方案 → 控制音視訊）	多步驟 ≠ Agent；用 N8N / Diffie 鏈式 workflow 即可
2. 對話 Agent	兩個明確信號之一觸發：(a) 流程必須讓人參與（被動 = 模型能力不夠 / 主動 = 需人偏好）；(b) 功能選項多到前端會指數型增長（不能或不想為每個功能加按鈕）	不要選最強最完整的框架（如 LongGraph）；先用集成度高的 AISDK 跑起來，先跑起來比一步到位優雅更重要
3. 加工具	Prompt 已經調到極限仍做不好 → 不是寫法問題，是任務本身需要的能力它根本沒有（如要參考網上設計但拿不到資料 / 要寫可用代碼但不能驗證）	不要在這之前再去改系統提示詞
4. Context Engineering	工具加到 3-4 個後，Agent 開始持續性變差（不是偶爾失敗，是性能持續下降 / 準確率忽高忽低 / 不是不會做而是越做越亂）——典型現象 = 上下文的注意力犧牲	不要在工具還少的時候就上 Context-Engineering；那只會增加複雜度
5. Memory（指針傳遞）	需要傳遞不能改動的長內容（如使用者貼進來的代碼），且該內容需要跨 sub-agent 共享但不該被反覆讀寫	不要讓上層 agent 把代碼當 output 再吐一遍——既為複製貼上付費，又無法保證一字不差
6. Observability（Trace）	系統有 sub-agent + 上下文隔離 + memory 後變得難以 debug；需要評估「哪裡做得好、哪裡做得差」	不要只存結果，要存過程（工具調用順序、每步 token、哪些上下文沒被用到、哪些信息不該給執行者）

階段 0 → 1：從 API Call 到 Workflow（多步驟 ≠ Agent 的關鍵判斷）

• 作者頻道一直用 AI 但用得朴素：標題（稿子 → 10 個標題挑一個）/ 封面（生成視覺主體 → 自己填字）——「為這點事專門搭一個 Agent 加工具做記憶搞編排，那就是給文字裝火箭助推器」。
• 第一條原則：「如果你的問題一個 API Call 能解決，不要用 Agent，不要為了用 Agent 而用 Agent」。
• 進入多步驟需求：剪視頻時想自動剪掉重複啰嗦處 → 一整條鏈路（轉時間戳字幕 → 判斷剪哪 → 生成剪輯方案 → 控制音視訊）。
• 多步驟 ≠ Agent 的判斷指標：「用戶不需要在中間反復參與」就大概率不需要對話 Agent——這種任務本質是確定性流程（哪怕步驟多 / 中間有 AI），用 chain workflow 即可（N8N / Diffie 已完全夠）。

階段 1 → 2：什麼時候真的需要對話 Agent

• 作者親身踩過的坑：天真地以為「一鍵生成特效」可以像「一鍵剪輯」那樣 = 點按鈕 → 一套滿意動畫——現實打臉：審美題、模型能力達不到、需要反覆試 / 反覆改。
• 如果這時還堅持用按鈕：要加「一鍵重做 / 一鍵改風格 / 一鍵改顏色 / 一鍵換模板 / 一鍵生成圖片」——最後產品變成飛機駕駛艙。
• 狹義對話式 Agent 的兩個觸發信號（明示）：
  1. 流程必須讓人參與（不管被動還是主動）
  2. 功能選項多到前端會指數型增長——不能或不想為每種功能加單獨前端 → 才需要 Agent 作為通用入口

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

• 作者初次選型：想選最強最完整的框架（如 LongGraph） → 「我這個問題很複雜，需要很長很長的鏈，那我必須上最硬核的後端框架」——後來發現是概念錯誤。
• 混淆了兩種長鏈：
  • Workflow 長鏈：一鍵跑到底，10 步 20 步全連續執行 → 需要任務分發、重試、佇列調度、並發恢復（後端橫著跑到底）。
  • 對話式 Agent 長鏈：可以被人切開——每跑完一步停一下、和用戶確認、跑幾步再停 → 整體還是長流程，但每次真正執行的片段其實可以很短 → 不需要重型調度系統。
• 作者最終選 AISDK（看似平平無奇）：集成度高 / 上手快；雖然不萬能但「先把東西跑起來」——能完成最基礎對話 + 工具調用，就能在真實任務迭代裡驗證和修正。「先跑起來比一步到位做到完美更重要」。
• 複雜架構的「誘導設計」陷阱：選了 LongGraph 等複雜後端 → 還沒跑任何東西就開始設計節點（拆 step / 數據在節點間流轉）→ 「像閉門造車，車輪畫得再遠，路多寬你都不知道」。雙重不確定性：(a) 問題能不能被模型解決；(b) 架構會不會干擾模型。
• 紀律：即使選複雜架構（不是錯的），至少要用它最簡單的用法跑一遍 baseline——知道任務底線在哪，再決定加節點 / 加更複雜編排。

階段 2 → 3：Prompt 設計的「從少到多」與何時轉向加工具

• 抄成熟 prompt 的反面教材：作者翻各種成熟項目 / 洩露的系統提示詞照抄 → 兩秒翻車：(a) 效果沒更好；(b) Token 消耗爆炸。
• 反例：只想做視覺設計 → 一句「你是一個視覺設計師，給我一個方案」就快能用 → 把專業提示詞一股腦丟進去 → 開始拆步驟、規劃流程、一步步執行 → 更慢、不一定更好。
• Prompt 第一版策略：
  1. 不要寫成複雜說明書
  2. 先寫沒有限制條件的版本 → 看它怎麼做
  3. 再不斷添加限制條件（更格式化 / 哪部分多思考 / 提供例子）
  4. 只要 Agent 能 follow 指令、一步步往上加它能照做 → prompt 這關就過了
• Prompt 已經到頂仍做不好的判斷：「很多時候它做不好不是系統提示詞寫得不夠好，而是這個任務本身需要的能力它根本就沒有」。
• 作者實例：讓 AI 做動效設計時期待參考網上流行設計 → 但它根本拿不到這些數據 → 再怎麼改 prompt 都沒用，不是寫法問題，是能力的缺失 → 正確動作是加工具（搜索、驗證 …）。

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

• 加工具初期極爽：每加一個工具明顯變聰明、之前做不了 / 做得勉強的事突然能跑通 → 忍不住繼續加 → 非常開心。
• 3-4 個工具的湧現：「它開始像一個 Agent 了——它開始自己想清楚該用哪個工具，甚至開始把工具串起來用」——這就是1+1>2 的湧現，工具之間出現協同。
• 重要紀律：在這個階段「沒有做什麼複雜架構」——還沒引入規劃、系統提示詞還是最基礎版本——Agent 已經 work。

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

• 加工具到一定程度後進入詭異階段：
  • 不是偶爾失敗，是性能持續性變差
  • 成功率下降、準確率忽高忽低
  • 開始聽不懂人說話
  • 「它不是不會做，而是越做越亂」
• 不是模型不行，是上下文開始失控：工具一多 → 每個工具背後一大段說明；任務複雜 → 輸入本身複雜；加上歷史對話 / 代碼 / 圖片各種信息一股腦塞進模型 → 太多太散，模型注意力被平均地分散掉 → 這就是上下文的注意力犧牲。
• 這時才真正需要 Context-Engineering——做某類任務時讓模型只看到它需要看到的東西。

階段 4：上下文隔離的具體判斷

• 作者用視頻 Agent 為例的兩種任務：
  • 設計任務：關心用戶意圖 / 視覺風格 / 版式 / 元素 / 氛圍——需要大量、開放、可發散的信息進行分析總結
  • 寫代碼任務：把設計實現——關心明確口令 / 接口結構 / 輸出格式 / 正確性——需要盡量少、盡量精確的信息
• 混在一起會發生什麼：任務小時可能還能跑；任務一旦複雜 → 設計信息開始擾亂代碼生成的準確性 / 代碼信息拖慢設計判斷 → 兩任務相互污染上下文 → 系統花大量時間把它理清楚。
• 上下文隔離有意義的條件：「當不同任務明顯需要不一樣的上下文時」。
• 規劃者 / 執行者結構：頂層規劃者知道全局信息 → 調度下面的執行者；執行者只負責專項任務（design sub-agent / code sub-agent），通過規劃者的控制只看到自己需要的那一小撮必要信息。
• 關鍵紀律（vault 補入 Sub-Agent）：「如果 sub-agent 和頂層規劃者看到的上下文是一樣的，那這樣的 sub-agent 就完全沒有意義」。

階段 4 → 5：上下文隔離立刻撞上的 Memory 需求

• 絕不開的問題：用戶給了一段代碼希望改它 → 頂層規劃者看到代碼但不寫代碼 → 必須把任務交給寫代碼的執行者 → 怎麼把代碼百分之百原封不動傳過去？
• 最直接但糟糕的解法：規劃者把輸入再 output 一遍給執行者——兩件糟糕的事：
  1. 為複製貼上付費：output token 是貴的（input → output 純複製只是 copy paste 卻消耗大量 output token）
  2. 無法保證一字不差：模型不擅長機械複製——哪怕你明說一行都不要改，它很可能順手改一個明顯的 bug（如把錯誤標點改正確）；問題是用戶本來就是要修 bug，你還沒傳到執行者它就被解決了——很多場景下是災難性的

階段 5：Memory 的存在意義與內存 vs 外存的直白定義

• Memory 的真正動機：「有些信息我只想存著，而不是讓模型反覆讀寫」。
• Memory 機制的本質：不是傳遞內容，是傳遞內容的指針——
  1. 頂層規劃者把代碼寫到文件系統 → 得到文件名
  2. 告訴執行者「需要改的代碼存在哪兒」
  3. 執行者用文件名讀內容 → 改代碼
  • 效果：規劃者不輸出完整代碼 → output token 成本下降；執行者不依賴規劃者輸出 → 錯誤率明顯降低
• 內存 vs 外存的直白區別（作者明示，不要把它玄學化）：
  • 內存：這輪對話結束就消失
  • 外存：多輪對話都拿得到的東西
  • 「這不是兩種神秘的能力，本質上就是說我需要做一個決定，這個東西存在哪兒、存多久」
• 為什麼有這個差別：有些信息只對這一輪有用 → 寫到外面繼續帶會變噪音 / 污染下一輪；有些信息必須跨輪保存——典型 = Claude-Code / Cursor 裡的 To-do list（任務步驟多、中間需用戶確認、引入外部狀態系統告訴 AI 走到第幾步）。
• 紀律：「不要一上來看到記憶體 / 內存 / 外存我都要用——順序永遠都是你走到這個階段、發現不用不行了你才用」。

階段 6：Observability（Trace）作為複雜系統的 debug 出口

• 系統有 sub-agent + 上下文隔離 + memory 之後：變得非常複雜、很難 debug → 「怎麼樣評價它哪裡做得好、哪裡做了差」？
• 唯一答案：「把每次運行的全過程全部存下來」——存的是過程不是結果：
  • 用了哪些工具
  • 工具調用的順序
  • 每步消耗多少 token
  • 哪些上下文根本沒被用到
  • 哪些信息不應該給到這個執行者
• 回讀這整個流程的價值：才會知道怎麼把任務規劃到更快、token 用得更少、成功率更高。

全片元命題（按重要性排序）

1. 「問題不是這些架構不夠優雅，也不是你不能選擇優雅的架構，而是你不需要一上來就優雅。千萬不要讓優雅變成你 AI 系統設計路上的絆腳石。」（如果只記一句話 = 這句）
2. 「AI Agent 是非確定性系統，在它上面再搭一層精緻架構等於是在不確定性上再疊加了一層不確定性。」
3. 「不是 AI 不行，只是你一開始就把路走複雜了。」
4. 「你的問題一個 API Call 能解決就不要用 Agent——不要為了用 Agent 而用 Agent。」
5. 「用戶不需要在中間反復參與，那你大概率不需要對話 Agent。」
6. 「先跑起來比一步到位做到完美更重要——即使你選用了複雜架構（不是錯的），至少要用它最簡單的用法跑一遍baseline。」
7. 「有些信息我只想存著，而不是讓模型反覆讀寫——這是 memory 不是優化項而是必需品的時刻。」
8. 「Anthropic 兩篇 AI Agent 神文是毕业设计的完整圖紙——當你做過中間所有實驗 / 踩過坑回頭看，會發現它設計得很完美；但第一天就照著毕业設計施工，大概率連第一根樑你都溜起來了。」

與 vault 既有概念的對位（ingest 視角）

• 與 Agent > 自主程度光譜（從固定到完全自主） 的關係：既有光譜是橫向 pattern 工具箱（你的任務該用哪個 pattern），本片的「7 階段升級路徑」是縱向時序視角（你的任務從小變大時該如何升級）——兩者互補，本片補入 vault 缺失的縱向視角，由新建 Agent複雜度演化 承接。
• 與 Anthropic「Building Effective Agents」 的「先用最簡單的解法，只在必要時增加複雜度」原則的關係：本片是該原則的個人實戰具體化——把「必要時」拆成 7 個明確觸發信號，並用「抄了反而更爛」的反例證明該原則的反面後果。
• 與 Context-Engineering / Sub-Agent / Agent-Memory 的關係：本片不是再添加新技術，而是給這些既有技術標出時機觸發點——避免 vault 的概念頁讓人誤以為「這些都是 day 1 就該上的東西」。
• 與 Prompt-Engineering 「迭代觀」的關係：本片補入「第一版不要複雜說明書 / 從無約束逐步加約束」的具體寫作策略，與既有「散彈 → 收斂 → 變體」迭代範式並列。
• 與 Augmented-LLM 的關係：本片補入「3-4 個工具的湧現」具體現象觀察，以及「prompt 到頂仍做不好 = 加工具的信號」判斷準則。

提取概念

連結到此來源衍生 / 更新的 wiki 頁：

• Agent複雜度演化（新建 — concept；7 階段升級路徑（API Call → Workflow → Agent → 加工具 → Context Engineering → Memory → Observability）+ 每階段觸發信號 + 「先跑起來比一步到位優雅更重要」紀律 + 與 Agent > 自主程度光譜（從固定到完全自主） 的縱向 / 橫向視角對位）
• Agent（更新 — 補入「複雜度演化軸（縱向時序視角）」段，指向 Agent複雜度演化；以及「對話式 Agent 的兩個觸發信號」（流程需人參與 + 功能選項指數爆炸）的明示判斷準則）
• Context-Engineering（更新 — 補入「何時該開始做 Context Engineering = 工具 3-4 個後 Agent 持續性變差、上下文注意力犧牲」時機判斷；以及「主 / 副 agent 看到一樣的 context = 毫無意義」紀律對位）
• Agent-Memory（更新 — 補入「內存 vs 外存的直白定義」（這輪結束消失 vs 多輪都拿得到）+ 「指針傳遞取代複製貼上」具體場景：output token 成本 + 模型不擅長機械複製、會順手改 bug 反而是災難）
• Sub-Agent（更新 — 補入「主 / 副 agent 看到一樣的 context = sub-agent 完全沒有意義」紀律——上下文隔離不是把 sub-agent 加上去就成立，而要實際做到信息範圍不同）
• Prompt-Engineering（更新 — 補入「第一版不要複雜說明書 / 從無約束逐步加約束」寫作策略；以及「抄成熟項目 prompt 兩秒翻車」反例——專業提示詞不是越複雜越好）
• Augmented-LLM（更新 — 補入「3-4 個工具開始湧現協同」具體現象 + 「prompt 到頂仍做不好 = 不是寫法問題、是能力缺失、該加工具」判斷準則）
• Anthropic（更新 — 補入「兩篇 AI Agent 神文是毕业設計圖紙」對位 — 抄了反而更爛的反例佐證「只在必要時增加複雜度」原則的具體現實意義）
• MOC-LLM-應用設計（更新 — 來源累積段加入本來源；新建概念 Agent複雜度演化 進「Agentic 系統」段）

Ingest 筆記

本段為 §5.1.8 規定的 ingest narrative 主體；log/2026-05.md 只放精簡決策摘要。

為何新建 Agent複雜度演化

vault 既有 Agent > 自主程度光譜（從固定到完全自主） 是橫向的 7 級 pattern 表（直接 LLM → Routing → Parallelization → Prompt-Chaining → Evaluator-Optimizer → Orchestrator-Workers → Agent），按「控制權移交」分類，目的是回答「你的任務該用哪個 pattern」。

本片明確把同一個 cluster 的工具（API Call / Workflow / Agent / 工具 / Context-Engineering / Memory / Observability）按時序成長重新排列，目的是回答「你的任務從小變大時該按什麼順序升級」——這是 vault 缺失的縱向視角。

兩者互補而非取代：

• 新頁不重述既有 7 級 pattern——只引述為「橫向選型工具箱」並指回 Agent > 自主程度光譜（從固定到完全自主）
• **既有 Agent 加一段「複雜度演化軸」**指向新頁，不在 Agent 主頁展開所有觸發信號（避免 Agent 頁臃腫）

新建頁是否會孤兒

按 §5.1.5 紀律，新建頁必須被既有頁實質連結。[[Agent複雜度演化]] 在以下既有頁有實質 outbound：

• Agent — 「複雜度演化軸」對位段
• Context-Engineering — 「何時開始做 context engineering」時機段
• Agent-Memory — 「內存 vs 外存 / 何時該引入 memory」時機段
• Augmented-LLM — 「加工具的湧現 / 何時加工具」時機段
• MOC-LLM-應用設計 — Agentic 系統段
• Anthropic — 「兩篇神文是畢業設計圖紙」對位段間接連入

→ 至少 5+ 個 inbound，符合密度要求。

Anthropic 是否需要實體更新

本片提到「最近看到 Anthropic 最新兩篇關於 AI Agent 的文章」：對應 vault 既有 2026-04-28-Anthropic-Building-Effective-Agents + 2026-04-28-LlamaIndex-Context-Engineering。本片沒有對 Anthropic 本身添加新事實（不是工程 blog、不是商業政策、不是模型發布），但提供了一個「抄文章後系統反而更爛」的反例對位，這對 Anthropic 的「Building Effective Agents 的提出者」事實有具體現實意義（讓未來讀者知道神文也有「毕业設計圖紙」副作用）。所以 Anthropic 加一段「作者神文的閱讀紀律」對位即可，不更新模型 / 政策軸。

反例對位帶來的紀律補強

本片是 vault 中第一個提供「抄概念但實作翻車」具體實證的來源。對位幾個 vault 既有頁：

• Context-Engineering 既有「容量在 100% 之前已劣化」「Compact 不能恢復品質」等紀律——這些是技術層紀律。本片加入「Context Engineering 不是 day 1 就該上」這個時機層紀律，補上「什麼時候不要做 context engineering」這一面。
• Sub-Agent 既有「自主壓縮 / 鋸齒狀 context 曲線」等技術描述——本片加入「如果主 / 副 agent 看到一樣的 context 那 sub-agent 就完全沒有意義」這個有效性紀律，避免讀者把 sub-agent 當作架構裝飾。

這兩條紀律的價值是：vault 的 LLM 應用 cluster 已經很大（21+ 概念頁、12 實體、9+ 來源），讀者容易產生「all-in 上所有技術」的錯誤印象——本片是對抗這個錯誤印象的疫苗來源。

關於作者身份

作者自述「我們這個頻道」在做影片創作 + 影片 AI Agent 開發，但全片沒有自我具名。我選擇不建立實體頁——資訊密度不足（只有「視頻創作者 + AI Agent 開發者」兩個事實），且未來如有第二個來源能識別此頻道再回頭建頁；本頁 frontmatter author 標記「未明示」並描述其自述身份。

觀察清單（密度尚不足以建頁）

• Plan-and-Execute 反模式：本片只是一個帶過例子，密度不足；如有第二個來源專門討論該反模式再考慮建頁
• AISDK / LangGraph / N8N / Diffie 等具體框架：本片提到但都是帶過；單一來源 + 工具描述為主、不是核心方法論，不適合建頁
• Agent-Observability / Trace：本片是 vault 中第一次明確處理該議題，但只有最後幾段帶過、密度不足；列入觀察清單，等下一個專門討論 trace / debug / observability 的來源 ingest 後評估獨立成頁
• 「複雜架構誘導你瞎設計」反模式：本片明示，但只是 Agent複雜度演化 中一段；未來若有第二個來源專門討論該議題再考慮獨立化

原文（YouTube 自動字幕逐字稿，含時間戳）

保留原始 ASR 逐字稿作長期保存。本片時長約 19 分鐘，逐字稿分段重組以便閱讀。

0:00  Hello，大家好啊。最近我在構建一個視頻 AI Agent，看了很多相關的文章。
0:06  當我看到 Anthropic 最新兩篇關於 AI Agent 的文章的時候，我覺得真的寫得太好了。
0:10  我當時就一個想法，抄，抄完我這個 AI Agent 就可以做到完美。
0:15  於是呢，我就開始了新一輪的架構升級。系統提示詞的升級，上下文的隔離，
0:20  讓它有了更多的 memory，做了一系列看起來很複雜但是自認為很優雅的系統架構設計。
0:27  做完之後發現整個系統變得更爛了啊。原來同樣的任務，現在不僅 Token 的花費變得更高更貴，
0:34  效果並沒有變得更好，失敗的情況比原來變得更多，而且有些失敗的例子呀，根本沒有辦法 debug。

0:42  當時我就想啊，不應該啊啊，我真的這麼弱嗎？後來我就放棄了這樣一個設計啊。
0:46  不過隨著 AI Agent 開發的逐漸深入，我慢慢意識到，
0:51  其實 AI Agent 的設計和傳統軟體的設計還是有著根本的區別的。
0:55  今天我們在網上看到的文章，大家都是把一個好的 AI Agent 的最終架構展現出來，
1:01  但是卻很少有人去提它到底是怎麼樣成長到這樣一個系統的，它到底經過了哪些坑。
1:08  那今天我們就結合自己的親身經歷跟大家去聊一聊，
1:11  AI Agent 的設計到底是怎麼樣從一個小小的 API Call 成長到一個複雜的工業系統。

1:22  我寫代碼的時候經常會想啊，這個不是在做系統設計嗎？
1:23  那我一開始把架構設計得更好，更完備，嗯，不應該更穩嗎？
1:29  說實話啊，這樣的想法在傳統的軟體設計裡面一點問題都沒有，是吧。
1:32  你做後端，你先把 Docker 這個部署模塊全部都規劃分好，最多就是前期慢一點啊，不會出什麼大事。
1:40  但是 AI 這個東西就不是這個樣子。我後來才發現一個非常反直覺的點啊，
1:43  AI Agent 本身就是一個非確定性的系統，
1:45  你在它上面再搭一層精緻的架構，等於是在不確定性上再疊加了一層不確定性。

1:52  舉個我自己幹過的蠢事兒啊：我一開始只是想把一段話總結成一句話，是吧？
1:57  結果我直接給它上了這個 Plan and execute 這樣的一個模式，
2:01  那原本一個 API Call 就能完成的事情，被拆成了先計劃再執行。
2:05  任務沒有變複雜，但是鏈路先變複雜了。
2:09  不是 AI 不行啊，只是說你一開始就把路走複雜了。

2:13  所以我們整期內容就只講一件事情：
2:14  AI Agent 是怎麼樣從一個小得不能再小的問題，一步一步被逼著長大的。
2:22  而在這條路上，到底是什麼節點，什麼樣的因素導致了我們需要給它加上這樣的一個架構。

2:29  就拿我們最近在做的視頻 AI Agent 來舉例啊。
2:33  我說過很現實的事情，我們這個頻道其實很早就開始用 AI 了，是吧，而且用得非常的朴素。
2:37  比如說這個標題，我就是一般把稿子丟進去，讓它給我生成十個標題，我會挑一個。
2:43  再比如說這個封面啊，我讓它生成一個視覺主體，然後我自己把文字填上去。
2:48  就這類任務，說白了就是一次 API Call 就能搞定。
2:52  如果要是為了這點事兒是吧，我專門搭一個 Agent 加工具做記憶、搞編排，
2:56  那就真的是給文字裝火箭助推器啊，看起來很酷，但是完全沒有必要是吧？
3:05  所以第一條原則非常簡單，非常殘酷，
3:06  如果你的問題一個 API Call 能解決，不要用 Agent，不要為了用 Agent 而用 Agent。

3:14  後來我開始有了新的 AI 需求啊，剪視頻的時候，我發現一件很瑣碎的事情，
3:17  就是我有很多的語氣詞，有些地方說得不好，那剪視頻其實就是在花時間幫自己擦屁股。
3:24  我自然就會想，有沒有辦法能夠讓 AI 幫我把這種重複的啰嗦的地方給剪掉。
3:29  這一步問題就開始升級了，你會發現這已經不是一個 API Call 能解決的問題，
3:33  你需要做的其實是一整條鏈路，先把視頻轉成在時間戳的字幕，
3:37  然後再根據字幕判斷哪些地方要剪，然後生成一個剪輯方案，回頭去控制音頻和視頻。
3:43  這是一個多步驟問題。但注意哈，多步驟不等於 Agent，
3:47  這裡就會出現第二個非常容易犯的錯誤。
3:50  很多人一看到多步驟第一反應，那我就上 Agent 啊，不一定。
3:55  因為這條鏈路有一個非常重要的特徵，就是中間過程不需要用戶的介入。
4:00  你可以想象它有一個很自然的使用方式，就是我上傳視頻點一下一鍵剪輯，拿到極好的結果。
4:05  輸入是確定的，中間步驟是固定的，輸出也是一次性給到你的。
4:10  所以這種情況下 ，Agent 反而是多餘的。
4:13  這種任務本質上是一個確定性的任務，哪怕它很長，步驟很多，中間有很多 AI，它也依然是一個流程。
4:21  所以在這種階段，應該用 Workflow 那種鏈式結構，比如說 N8N，比如說 Diffie 啊，就已經完全夠了。
4:28  不需要對話，不需要多輪交互，也不需要讓用戶中途插嘴。
4:32  一個非常重要的判斷指標，如果用戶不需要在中間反覆參與，那你大概率不需要對話 Agent。

4:39  那到底什麼時候需要 Agent 啊？我用我自己踩過的一個坑來回答你。
4:44  我當時做了一個功能啊，叫做一鍵生成特效，啊就像這個一鍵剪輯一樣，
4:49  我天真地以為我可以點一下按鈕，然後它就給我一套我喜歡的動畫效果。
4:54  但現實給了我一巴掌啊，它大概率不會一次就生成到我滿意，
4:59  有的時候風格不對，有時候節奏不對，有的時候我只想改動一個小細節，是吧？
5:04  這種任務它不是對錯題，啊它有的時候甚至是一個審美題，
5:06  或者說有的時候呢，模型它的能力達不到，人需要去指導它，教它怎麼做，
5:11  它可能會需要反覆地試，反覆地改。
5:14  但如果這個時候你還堅持用按鈕，可能會發生什麼樣的情況？
5:16  你可能需要加很多的按鈕來控制它，比如說一鍵重做，一鍵改風格，一鍵改顏色，一鍵換模板，一鍵生成圖片。
5:25  那每出現一種這種需求，你可能就會要新增加一個按鍵，
5:28  最後這個產品就會變成一個飛機駕駛艙，是吧？很多很多的按鍵。
5:33  這個時候我們才天然地需要一種通用的入口。
5:36  所以你真正需要狹義上的這種對話式的 Agent，通常只有兩個信號，
5:43  第一是你這個流程必須讓人參與啊，不管是被動的模型能力達不到，還是說是主動的，需要人的偏好。
5:50  第二就是功能選項多到前端會指數型地增長，你不能或說你不想為每一種功能都添加一個單獨的前端的時候，
6:00  你就需要用 Agent 這種通用的入口。

6:03  我確定使用 Agent 之後呢，我又馬上犯了一個特別典型的錯誤，
6:06  我一開始就想選一個最強最完整能 cover 一切情況的 Agent 框架啊，
6:11  那種簡單的技術啊，我都不想用啊，
6:15  因為我腦子裡有個幻覺啊，就是我這個問題很複雜，所以我需要一個很長很長的鏈，
6:20  那我就必須上最硬核的後端框架。
6:22  後來我才發現啊，這其實是一個概念錯誤。
6:24  鏈長並不等於你必須用複雜的調度，流程很複雜不等於後端很重啊。
6:31  我當時搞混了，其實是兩種長鏈的概念，
6:34  當你做的是 Workflow 的時候，你點一下按鈕，它就從頭跑到尾，十步二十步全部都連續執行，
6:39  這個時候你當然會考慮這個任務的分發、重試、隊列調度，還有並發恢復，
6:46  因為它會真的在後端橫著跑到底。
6:48  但是對話式 Agent 不是這麼跑的，是吧？對話式 Agent 長鏈是一種可以被人切開的那種長鏈，
6:55  它可以每跑完一步停一下，或者說跑幾步停一下，和用戶進行一個交互和確認，是吧？
7:01  它整體還是一條長的流程，但每一次真正執行的片段其實可以很短。
7:07  這就意味著啊，你很多時候根本不需要一上來就搭一個能連續跑二十步，
7:10  還要扛住各種異常的重型調度系統。

7:14  所以我最後選了一個看起來平平無奇的方案，用的 AISDK，它的集成度高，上手快啊，
7:21  有人覺得它沒有那麼無敵和萬能，但是它有一個巨大的優點，就是先把東西跑起來。
7:26  只要它能完成最基礎的對話，最基礎的工具調用，
7:29  我們就能在真實的任務迭代裡面去進行驗證和修正。
7:34  所以大家不要被後端迷了雙眼，先跑起來比一步到位做到完美更重要。

7:41  技術選型再補充一句啊，複雜架構可能還有一個坑的地方是，它會誘導你瞎設計。
7:45  當你選了一個很厲害的後端架構，比如說 LongGraph，
7:49  它會天然地誘導你做一件事情，你還沒有跑任何東西，就開始設計節點。
7:53  你會忍不住去想，這件事情應該拆成哪些 step，哪些節點應該負責什麼事情，
7:59  數據應該怎麼樣在節點之間進行一個流轉。
8:02  聽起來很專業，但是問題是，你連最簡單的那個問題能不能解決你都不知道。
8:08  這個像閉門造車似的，你車輪畫得再遠，路多寬你都不知道。
8:13  這個地方其實是有兩重不確定性的，第一個是這個問題到底能不能被模型解決，第二個就是你這個架構會不會干擾它。
8:21  所以我的建議其實很簡單，就是即使你選擇用了複雜架構，它不是錯的，
8:25  但是你至少要用它最簡單的用法去跑一遍，
8:28  先把你這個問題的 baseline 給跑出來，知道任務的底線在哪兒，
8:33  之後再決定我要不要加節點，要不要加更複雜的編排。

8:37  那在我把 AISDK 跑起來之後，下一關自然就是怎麼樣設計系統提示詞了。
8:42  我馬上踩了一個超級典型的坑，我想把 prompt 也寫到最厲害，是吧？
8:47  我當時找了各種各樣成熟項目的 prompt，那種被傳來傳去，號稱效果炸裂的。
8:53  還不夠，我還專門去翻那種某知名項目洩露出來的系統提示詞。
8:59  我當時心想啊，別人寫得這麼好，我照著抄總不會差吧？
9:03  結果兩秒鐘就翻車了。第一，效果沒有更好。第二，Token 消耗直接爆炸。
9:09  舉個例子，我只是想讓它幫我做一個視覺設計，是吧？我不給複雜的 prompt，
9:13  我就說一句你是一個視覺設計師，給我一個方案。它能給我一個快能用的結果。
9:18  那當我把那些專業的提示詞一股腦地丟進去，它開始拆步驟，規劃流程，一步步執行，
9:25  最後就是更慢，但是不一定更好。

9:28  我自己的經驗來說啊，prompt 第一版不要寫成那種很複雜的說明書。
9:32  你可以先寫得沒有什麼限制條件，然後看它會怎麼去做啊，然後再不斷地去添加你的限制條件。
9:38  比如說你想讓這個輸出更加的格式化，你想讓哪個部分進行多一點的思考，
9:43  你給它提供一些例子，讓它根據這個例子往外進行輸出。
9:47  那只要這個 Agent 能夠 follow 你的指令，讓它一步一步往上加東西，它能照著做。
9:51  說實話啊，系統提示詞這一關就已經過了。

9:54  接下來你會遇到一個非常現實的問題，就是很多時候它做不好，
9:59  不是這個系統提示詞寫得不夠好，而是這個任務本身需要的能力它根本就沒有。
10:05  舉一個例子啊，就我讓 AI 幫我做動效設計的時候，
10:09  其實我期待的是它能參考網上流行的一些設計，但問題是它根本拿不到這些數據，是吧？
10:14  這個時候你再怎麼改提示詞都沒有用，不是寫法的問題，是能力的缺失。
10:19  所以這一步正確的動作就不是再去改系統提示詞了，而是加工具。
10:23  如果我希望它能參考網上的信息，那它就必須要會搜索。
10:27  我希望它寫的代碼是可用的，它就必須能驗證。
10:30  那這個時候我們才需要真正地引入工具。

10:34  當你把三四個工具加上去之後啊，你會有一個很明確的感覺，就是它開始像一個 Agent 了，
10:42  它開始自己想清楚該用哪個工具，甚至開始把工具串起來用，
10:46  這就是所謂的湧現啊，就是工具之間出現了一加一大於二這樣的一個效果。
10:53  而且你要注意，在這個階段，其實我們沒有做什麼複雜的架構，
10:55  我們還沒有去引入這樣的一個規劃，我們的這個系統提示詞也還是最基礎的版本。

11:04  那說實話，在剛開始加工具的那段時間啊，做 Agent 的體驗就是爽爆了。
11:08  你每加一個工具，它就明顯地變得聰明一點，之前做不了的事就能做了。
11:12  之前做得很勉強的事情，現在居然能跑通了。
11:14  你就會忍不住繼續加，繼續加，繼續加，這個時候你會非常地開心。
11:19  但很快你會進入到一個非常詭異的階段，
11:22  不是偶爾的失敗，而是這個 Agent 的性能持續性地變差，
11:27  成功率開始下降，準確率忽高忽低，有的時候它開始聽不懂人說話，
11:32  而且你能明顯地感覺到啊，它不是不會做，而是越做越亂。

11:37  這個地方其實不是模型不行了啊，而是你的上下文開始失控了。
11:41  工具一多，每一個工具背後呢，都會有一大段說明。
11:44  任務複雜，輸入本身也會變得更複雜。
11:47  再加上歷史對話呀，代碼呀，圖片這種各種各樣的信息，
11:50  所有的信息一股腦地塞進模型裡面，導致太多太散，模型的注意力被平均地分散掉了。
11:58  這其實是一個非常典型的現象，上下文的注意力犧牲。

12:02  這個時候我們才真正地需要我們視頻一開始提到的 Anthropic 的第一篇文章 Context Engineering。
12:09  Context Engineering 本質上只幹一件事，就是在做某一類任務的時候，讓模型只看到它需要看到的東西。

12:21  還是拿我們這個視頻 Agent 來舉例啊，當我們想要設計某種視頻效果的時候啊，
12:24  它其實是兩種不同的任務啊。
12:27  第一種是設計，它關心用戶的意圖，視覺的風格、版式、元素、氛圍，
12:31  它需要大量的開放的、可發散的信息，然後對這些信息進行分析和總結。
12:37  第二類是寫代碼，把設計好的信息進行一個實現，
12:40  它關心的是明確的口令，接口的結構，輸出的格式以及正確性。
12:46  它需要盡量少、盡量精確的信息。

12:50  如果把這兩件事情混在一起，會發生什麼？就是任務小的時候可能還能跑一跑，
12:54  但是任務一旦複雜，設計的那些信息會開始擾亂代碼生成的準確性。
13:00  代碼的信息可能會拖慢設計的判斷，是吧？
13:03  兩個任務相互開始污染上下文，系統需要花大量的時間去把它理清楚。
13:09  當不同的任務明顯需要不一樣的上下文的時候，上下文的隔離才會有意義。

13:15  這個時候我們才會開始考慮，我是不是需要有一個頂層的規劃者，
13:19  他知道所有全局的信息，然後去調度下面的這些執行者。
13:22  但這些執行者可能只負責一些專項任務，
13:24  比如說設計的這個 sub-agent 就只負責設計相關的內容，
13:28  代碼的這個 sub-agent 就只負責代碼的內容，
13:30  並且這兩個執行者通過規劃者的控制，只看到自己需要的那一小撮必要信息。
13:39  所以其實如果我們看到一些設計啊，它雖然設計了一個 sub-agent，
13:43  但是它的這個 sub-agent 和它這個頂層的這個規劃者，他們看到的上下文是一樣的話，
13:48  那這樣的一個 sub-agent 就完全沒有意義。

13:53  那當我們開始真正使用 sub-agent 這種結構，或者說開始使用規劃者、執行者這種結構的時候呢，
14:00  會立刻遇到一個繞不開的問題啊。
14:03  我們假設用戶現在給了一段代碼，希望我們幫他改，
14:09  那這個時候呢，頂層的規劃者會看到這段代碼，
14:12  但是頂層的規劃者呢，不負責寫這個代碼，
14:14  他需要把這個任務交給下面寫代碼的這個執行者。
14:18  那問題來了，規劃者怎麼把這段代碼百分之百原封不動地交給執行者？

14:25  最直接的解決方案，你把這個輸入進來的東西，就再輸出一遍，
14:30  然後給到這個執行者。
14:31  這一步其實非常不合理啊，因為這裡發生了兩件很糟糕的事情。
14:35  第一個，你其實是在為這個複製粘貼付費的，
14:39  輸入了一段代碼，輸出了一段代碼，其實我們只是在做 copy paste，但是卻消耗了大量的 output token。
14:45  我們知道 output token 是很貴的，是吧？
14:48  第二件事情，你根本沒有辦法保證一字不差。
14:50  模型並不擅長機械複製，哪怕你明說，是吧，一行都不要改，
14:55  它也很可能會把一個明顯的 Bug 給改了，是吧？
14:57  或者說你輸入的這個代碼裡面有一個標點符號是錯的，我把這個標點符號給它改正確了。
15:05  我本來就是要去修 Bug，結果你還沒有傳到執行者這兒，是吧，你這個 Bug 就被解決了。
15:11  啊這樣的情況在很多場景下可能是災難性的。

15:14  所以在這一刻，我們意識到了一件事，
15:18  有些信息我只想存著，而不是讓模型反覆讀寫。
15:22  那到這個時候啊，我們必須得引入 memory 記憶體這個概念了。
15:26  那這方的機器系統也很簡單啊，它不是在傳遞這個內容，而是在傳遞內容的指針。
15:32  也就是說，頂層的規劃者看到這段代碼之後呢，它就把這段代碼寫到一個文件系統裡面，
15:38  然後這個文件系統對應的這個文件名是什麼。
15:41  那它告訴下面這個寫代碼的執行者的時候，它就說，
15:44  你需要改這段代碼，這個代碼存在了哪兒啊？
15:47  然後執行者需要做的一件事情是，他根據這個文件名把這個內容給讀出來，然後去改代碼就可以了。
15:54  那在這個過程裡面呢，規劃者不輸出完整的代碼，執行者不依賴於這規劃者的輸出，
16:01  從而讓輸出的 token 成本直接下降，讓錯誤率明顯地降低。

16:05  所以這一整段其實都是在講一個判斷，就是當你開始做上下文隔離的時候，
16:13  當你需要開始傳遞不能改動的長內容的時候，記憶系統就不再是優化項，而是一個必需品。

16:23  那麼我們把這個記憶系統的概念引入之後呢，我們又會聽到一個很常用的說法，
16:28  就是有內存，有外存，啊，那這兩個詞其實沒有那麼玄乎哈，它的區別也很簡單，
16:33  就是如果在這輪對話結束之後就消失的，就是內存，
16:36  如果說多輪對話它都能拿到的東西呢，就叫外存。
16:42  這不是兩種神秘的能力啊，本質上就是說我需要做一個決定，這個東西存在哪兒，存多久。
16:48  為什麼有這樣的差別？因為有些信息它就只對這一輪有用，
16:51  如果你把它寫到外面去，繼續帶著，它很有可能會變成噪音或者污染下一輪的這個行為，
16:58  所以它就應該留在內存裡。
17:00  但有些信息呢，就必須跨輪次地保存。
17:02  最典型的就是像 Cloud Code，像 Cursor 裡面的那個 To-do list，
17:08  任務的步驟比較多，中間需要用戶的確認，那你引入了一個外部的狀態系統，
17:13  來去告訴 AI，我們現在走到第幾步了，用戶給了什麼樣的輸入，我現在不該執行什麼了。
17:18  所以不要一上來看到，哦，記憶體內存、外存，我都要用，是吧？
17:22  順序永遠都是你走到這個階段，發現不用不行了你才用。

17:28  那最後，當你有了這種 sub-agent 的系統，有了上下文隔離，有了這個記憶體系統之後啊，
17:33  整個系統會變得非常的複雜，也很難地去進行調試，或者說去進行一個 debug。
17:39  這個問題就變成了我到底怎麼樣評價它哪裡做得好，哪裡做了差？
17:45  答案只有一個，我們把每一次的運行全過程全部都存下來啊。
17:51  這方要存的不是結果，要存的是過程，
17:54  存它到底用了哪些工具，工具調用得順序是什麼，每步消耗了多少 token，
17:58  有哪一些上下文根本沒有被用到，有哪些信息不應該給到這個執行者？
18:04  當你回頭去讀這樣一整個流程的時候，你才會知道
18:08  怎麼樣能夠把任務規劃到更快、token 用得更少、成功率更高。

18:13  那到這一步，你會突然發現了，原來我們之前讀的兩篇文章和這樣的一個系統才終於是對上了。
18:19  Long-run task 為什麼一定要 memory？是吧，context engineering 到底是在做什麼？
18:25  我最開始失敗的原因其實不是這兩篇文章不對，
18:28  而是我當時所處的那個階段還不需要用到這些東西啊。
18:32  它們這種比較成型的文章，更像是一個畢業設計的完整圖紙，是吧？
18:37  當你已經做過中間所有的實驗，踩過坑，回頭看的時候，
18:40  你會發現，欸它其實設計得很完美，設計得很精巧。
18:42  但是如果你第一天開始學畫這個圖，是吧，就直接照著這個畢業設計去進行一些施工，
18:48  你大概率連第一根這個梁你都溜起來了。

18:54  問題不是這些架構不夠優雅，也不是你不能選擇優雅的架構，
19:00  而是你不需要一上來就優雅。
19:02  千萬不要讓優雅變成你 AI 系統設計路上的絆腳石。

19:08  那以上就是本期視頻全部的內容。

字幕由 YouTube 自動字幕修整（去除 ASR 殘留斷句、補上標點與段落）；含義與時間戳忠於原片，可由 URL 重新取得逐字稿驗證。